3時に寝て7時に起きた。昨日は深夜まで yubikey bio で 1password のロック解除の設定を調べていて遅くなった。また後日まとめる。

ストレッチ

今週は出張があったり、飲み会があったり、前日に深夜まで作業して疲弊していたりとあまり調子はよくなかった。いつも通りの右股関節の関節痛はあるし、腰の張りも少しあったし、右の太もも後ろの筋に違和感があるように感じた。太ももの後ろの筋を伸ばすストレッチが快適でお気に入りの1つなんだが、そこの部位でいつもとはやや違う別の張りを感じた。筋の張りの違和感をトレーナーさんにどう伝えてよいか、表現方法がわからなくて困ることが多い。今日の開脚幅は開始前156cmで、ストレッチ後158cmだった。疲労した体調を立て直すきっかけになってよかったと思う。

カフーツさん訪問

カフーツさんへ 昨年の6月以来 となる訪問をしてきた。毎月オンラインでいとうさんと話しているので身近ではあるけれど、リアルで会うのは約1年振りになる、本当に月日の流れる早さを実感する。ブログJelly Vol.132 に参加してきた。参加者は3人で18時から始まって1時半ぐらいまでお酒を飲みながらうだつの上がらない話しをしていたw ここにいる人たちと私は価値観があうのでだらだら話しているのが楽しい。

神戸と実家で2拠点生活しようと考えているという話しをしたら、実家のはなれを改修したスペースに宿泊できるなら airbnb で貸し出したらいいんじゃない？という話題が出て、たしかにそういう取り組みもできるなと感心した。そして、そのスペースにもう少し手を入れて小さいコワーキングスペースにしてもよいのかもしれない。すぐ側に田んぼもあるので農業体験なども簡単にできる。淡路島は気候もよくそこそこよい環境でコワーキングの拠点になるかはともかく、海が好きな人向けにはよいところかもしれない。実家のコワーキングスペース化という視点を今後も考えていきたい。

お酒飲んで新幹線乗ったせいか、新幹線の中であまり寝られなくて暑くていつもより移動に疲れた。その後1時に寝て何度か起きて7時に起きた。2日酔いではないが、寝起きの気分はよくなかった。

issue を作ることによるストレス軽減

昨日の打ち合わせのメモから議事録を作ったり、そこから新しい issue を作ったりしながら来週の打ち合わせの資料作りをしていた。資料を作っている途中、割り込みでメンバーのコードレビューが入ったりして、あまり資料作りは進捗しなかった。

打ち合わせした内容から issue を作る作業を、私は好きだったりする。何をやってよいかわからない状況というのは苦しい。issue を作ること、要件を言語化したり、背景を調べたり、他の issue との関連付けしたり、そういった手を動かすことがきっかけになって、その issue を明確化していく作業を積み重ねれば時間の経過とともに課題が解決するということを経験的に理解しているからだ。

大雑把に言えば、私にとって、issue さえ作れればその課題解決は優先順位付けと (解決までの) 時間の問題に置き換えられる。あれやらなきゃ、これもやらなきゃ、なにか抜け・漏れがあるんじゃないかと頭の中でもやもやしているものを issue という概念に変換することで考えなくて済むようになっていく過程がストレスを軽減している気もする。

コンテナ勉強会

先日公開したテックブログ とプラスアルファで勉強会をした。コンテナという汎用的な話題だったので CTO から社内向けにアナウンスされて (半業務命令っぽい雰囲気で) いつもより参加者は多かったように思える。10人前後は参加されていた。40分ぐらいで話し終えて20分ほど雑談の時間をとって盛り上がりは微妙だったけど、いくつか意見や質問が出たのでよかったのではないかと思う。

チームのメンバーが発表するときは私がモデレーターの役割をしている。私が発表するときはモデレーター兼発表者になってしまう。モデレーターと発表者を兼任するのはとても難しい。おそらく脳の集中力を向ける先が異なるからではないかと思う。モデレーターは質問者の質問を広げたり、コミュニケーションがうまくいくように手伝ったりする。回答から次の質問を考えたりもする。一方で発表者は自分の調べたことや伝えたいことを聴衆にわかりやすく伝えることのみに注力する。

モデレーターと発表者が同じになってしまうと、自分の説明のどこが伝わっていないのか、質問者の意図を組むにはどうすればいいかといったモデレーターの視点がなくなってしまう。以前 tenntenn さんの個人カンファレンス に参加したときに1人2役でパネルディスカッションをされていて、そのときに同僚からあまりやり過ぎると人格崩壊するから気をつけた方よいといった忠告を受けたと冗談で話されていた意味が理解できた。役者が他人になりきるように、これは兼任じゃなくて1人で2つの人格を演じないといけない。そんな器用なことはそうそうできない。

能のサイトを眺めつつ 世界を変えた“愚か者”フラーとジョブズ をみているうちに寝落ちした。0時過ぎに寝て何度か起きて8時過ぎに起きた。休日以外に8時まわるまで寝ていたという記憶が直近数ヶ月にはないので久しぶりに寝坊した。起きたら8時10数分でそんなことあるはずないとか思ってしまって脳が現実を受け入れられなくて起きた時間を認識できなかった。明らかに8時10数分なんだけど、時計が壊れているなとか思ってしまった。

開発課題の打ち合わせ

大きく時間を使って次開発の打ち合わせ。事前にいくつか開発課題を洗い出せているが、その優先順位付けをしていかないといけない。開発メンバー + 別チームのコンサルタントにも入ってもらって各々の意見を出し合うといった会議をした。私が議題の資料を予め作っておいた。その進行に応じて議論や意見が盛り上がったのでうまくいってよかったと思う。 大項目でまとまった機能をやるよりも、個々の機能単位に優先順位付けした方がよいだろうという話しになって小さい単位で担当者を割り当てて開発を進めていくことになる。いずれはすべてやるが、開発の順番を決めていくのは意外と難しい。

話し終えてからメモをまとめ直しているうちに私自身が要件を詳細に把握できていない要件があることもわかってきた。空中戦だとわからないままふわっと進んでしまうので、文字に落とし込んで整理した上で、本当に必要なものをさらに深堀りして議論しないといけないことに気付いた。

少ない人数で会議をやる利点の1つとして、みんなの意見を順番に聞いていく余裕をもてることがあげられる。「誰一人取り残されない」とどこかの省庁がミッションにあげているように、うちのチームも課題管理を駆使して、それぞれのメンバーができることややりたいことでチームに貢献するような開発にしていきたい。もう半年やって課題管理に慣れてきているので、次開発は前回のようなやり方を教えるところからスタートにはならないはずだと思う。

打ち上げ

4月末にリリースを終えたので区切りとして打ち上げしてきた。うちのチームメンバーと偉い人の5人で行くのだと思っていたら直前に社内のメンバーにたくさん声を掛けたそうで10数人での飲み会になって送別会や部署のキックオフみたいな飲み会になった。賑やかでよかった。個人だとあまり行かないようなちょっとお値段のするコースでよいものを食べられておいしかった。日本酒もいろいろ飲んだ。神戸の酒どころに住んでいるので日本酒に関心をもつようになってきた。

• 山形 上喜元
• 愛知 醸し人九平次

18-20時と打ち上げやって、21時に新幹線を予約していたのでそのまま帰ってきた。このスケジュールの段取りもちょうどよかった。お酒を飲んで新幹線に乗ると思いの外眠れなくてそこだけ疲れた。

0時に寝て何度か起きて5時半に起きてテレビで朝のニュースを聞き流しながら7時に起きた。

資料作成

今日はメンバーの1人が休暇だったため、打ち合わせはなしで資料ばかり作っていた。今週のチーム勉強会の発表は私が担当するのでその資料を作ったり、リリースを終えて社内向けにプロダクトの説明のための資料を準備したりしていた。これまでたくさんの資料を作ってきてるので改めて作るというよりは、過去に作ったものを洗練させたり、集めてきて補足する程度の作業になりそうな雰囲気だけわかってきた。

aws app runner の情報収集

App Runner Night !! にオンラインで参加した。AWS Startup Community というコミュニティがあることも知らなかった。顧問のはらさんが LT 発表すると聞いていたのでそれをみようと思ってながらで聞いていたので他の発表はあまりちゃんとみていてない。特別に目新しいことはなかったし、発表の中でもいくつかちょっとそこ怪しいんじゃない？とか思いながら他の作業をしていた。

私も余裕があれば app runner でサービスを動かしてみてその勘所を把握しておきたい。ecs がやりたいことに比べて使いにくいという印象は私もずっと思っていた。実質 k8s 以外のコンテナプラットフォームは aws しかないので app runner がよいものかどうかに関心をもっている。

コワーキングのオンラインイベント

月例のカフーツさんのオンラインイベントに参加した。先月の所感はここ 。今日は「移動」というテーマでいつも通りいとうさんがわーっと話をしていた。この2ヶ月に新しい官民の取り組みが始まったらしい。なんか空気だけでダメそうにみえる。

• 「テレワーク・ワーケーション官民推進協議会」を設立しました！

このサイトでは次の2つの用語を定義している。ブレジャーを初めて知ったけど、発音しにくくて語呂が悪いだろとか思えた。

• ワーケーション (Work + Vacation)
• ブレジャー (Business + Leisure)

このサイトにあるワーケーションの実施形態には共感するところもあって次の4つに分類している。IT 業界で多いのは合宿型とサテライトオフィス型かな。

• 福利厚生型
• 地域課題解決型
• 合宿型
• サテライトオフィス型

あとどういう文脈だったか忘れてしまったが、身体感覚で「芭蕉」を読みなおす。 『おくのほそ道』謎解きの旅 という本を紹介された。能の探求者が書いた独特の視点から松尾芭蕉を取り上げた本らしくて、なんかおもしろそうにみえたのですぐに購入してみた。紙の文庫本しかなかった。読んでみる。

少し寝ようかと思って横になった時間はあったものの、寝過ごすのが怖くて結局は新幹線の始発まで起きていた。この時期は4時を回り始めると徐々に外が明るくなっていき、5時は普通に明るくなっている。夏至も近い。

テックブログ公開

先日書いてレビューを終えた テックブログを公開した。

• Docker とは何か？

コンテンツは狙ってバズらない

私の言葉だ。多くの開発者が関心をもつ話題ではないけれど、仲間内では評判がよかったので拡散されると嬉しい、、、。と淡い期待を寄せていたが、そうでもなかった。工数をかけて丁寧に書いても関心をもたれないことはよくある。個々のコンテンツがバズらなくてもコンテンツは積み重ねることも大事なので私がよいと思う記事を今後も書いていく。

半年間の開発のふりかえり

2時間をとって半年間の開発のふりかえりをやった。課題管理システムから定量的な数字をみたり、定性的なのは、過去のマイルストーンのふりかえりのふりかえりをしたり、課題管理システムから特定の issue を取り上げて改善するにはどうしたらよいかなどを議論したりしてみた。

私もチームのファシリテーションに慣れてきて、自由に意見を求めるよりも、個人個人を指してどうですか？と尋ねる方が意見がわーっと出てきて議論が活発になることに気付いた。なにか議題があったら必ず当てられて意見を言わないといけないとメンバーも察してくれるようになっていると思う。そういう空気になってきた。そして、ちゃんと答えてくれるのでそれで問題ないと思う。大人しいというのか、消極的というのか、うちのチームのメンバーには意見を求められなければ言わないという姿勢が垣間みえる。これは開発の自律性とは反対にある価値観なのでなるべくそこから脱却して自分から議題に意見を言うようになってほしい。もしかしたら私が喋り過ぎなのかもしれない？

ふりかえりをしないチームは多いので何もしないよりはなにかしら 示唆は与えられた のではないかと思いたい。

0時に寝て何度か起きて7時に起きた。いつもなら日曜日は徹夜して翌日の早朝に出掛けるのが月曜日は行かなくて済むのでちょっと楽になった。

amqp091-go の context 制御

goroutine リークを検出するツールに uber-go/goleak がある。ずっと前から余裕のあるときに結合テストの導入しようという issue を作っていたものの、適当なタイミングがなかった。先週末に少し手が空いたので着手した。goleak は個別のテストメソッドにも TestMain にも両方に対応している。結合テストの TestMain に入れた方が保守コストが下がるのでそういった用途がよいのではないかと思う。

go の TestMain がこういうものかもしれないが、defer 文を使う終了処理があるとそのコードを直接 TestMain には実装できない。関数で wrap して m.Run() を実行した結果を返すようにしないといけない。そこに goleak を入れる場合、goleak.Cleanup を何もしない関数に置き換えて m.Run() の結果を返せばよいのではないかと思う。そして VerifyTestMain() は m.Run() を実行してからすぐに goroutine が動いていないかをチェックする。ここで結合テストを動かすための、環境構築のために http サーバーを goroutine で起動するとか、テストのための goroutine が動いているとそれも検出してしまうのでそれらの goroutine は無視できるよう、2つのオプションが用意されている。

• IgnoreTopFunction: 明示的に無視してよい goroutine のトップ関数を指定する
• IgnoreCurrent: オプションを登録した時点で稼働している goroutine を無視する

これらを踏まえて TestMain で goleak を使うと次のようなコードになった。しかし、おそらくこの使い方はあまりよくない。いくつか goroutine を無視する設定を追加したために、そこに意図しない goroutine リークが隠蔽されてしまう懸念がある。

func main(m *testing.M) int {
    defer myTearDown()

	var code int
	goleak.VerifyTestMain(
		m,
		goleak.Cleanup(func(exitCode int) {
			fmt.Println("skip goleak cleanup", exitCode)
			code = exitCode
		}),
		goleak.IgnoreTopFunction("net/http.(*persistConn).readLoop"),
		goleak.IgnoreTopFunction("net/http.(*persistConn).writeLoop"),
		goleak.IgnoreTopFunction("internal/poll.runtime_pollWait"),
		goleak.IgnoreCurrent(),
	)
	return code
}

func TestMain(m *testing.M) {
	os.Exit(main(m))
}

さらにこの調査をしているときに amqp091-go の api も context 受け取った方がシンプルでいいんじゃない？と思って提案の pr を送ってみた。context 使わなくても自前でキャンセルする api は提供されているため、開発者の考え方によってこの提案を拒否するのも妥当な判断だと思える。次のメジャーバージョンとか、互換性を維持しなくてよいタイミングから取り入れようという考え方もあるかもしれない。

• Add Channel.ConsumeWithContext to be able to cancel delivering #192

0時に寝て何度か起きて7時に起きた。雨降りだったので午前中はドラクエタクトしてた。午後から雨が小さくなったのをみて、オフィスで出張前の資料作りをしてた。夕方には雨がやんでお土産を購入するために出掛けたらすみよさんさんに偶然会った。

ソフトウェアライセンス事業を加速させる OSS 戦略

ビジネス法務 2023年6月号 という雑誌に寄稿したとなかいさんのタイムラインをみかけたので読んでみた。電子版は年間契約でないと購入できないようで仕方なく紙の雑誌を購入した。ライセンス契約の特集の中の1記事らしい。3ページの記事だったので OSS というソフトウェアのビジネス形態の紹介といった記事のようにみえる。OSS や web 業界の開発者からみたら目新しい内容ではないが、こういった雑誌に紹介されること自体がすごいことだと思いながら読んでみた。自社ソフトウェアを OSS とする戦略の特徴として次の3つをあげていた。

• ユーザーの開発者が動作を確認したり、カスタマイズできる
• 製品の透明性を証明できる (ソースコードを読めるから)
• 技術力のアピールできる

うちも近いうちに OSS でプロダクト開発を始めるので参考にしながらやろうと思う。うちは OSS で儲けようと考えていないが、うちで作るものは原則として OSS で公開していく方針で考えている。

近況報告の資料作り

4月末にリリース できているのでそれほど重要ではないけど、毎月出張したタイミングで報告会をしているので急にやめるのもどうかな？という気がして資料を作って打ち合わせする。リリースして GW を挟んで次の開発への準備期間という隙間時間がいまになる。ある種のゆとりになっていて、これはパッケージベンダーだからこそなのか、中小企業ゆえの労務管理や目標管理の緩さからなのか、いずれにしてもこういう隙間時間を使って自分で考えて、自分で調査して、自分でふりかえるといった自律性を養うのによいかもしれない。私もゆっくり考える時間を取れてよかった。

0時に寝て何度か起きて6時に起きた。朝からなんとなくだらだらしていた。午後から日記を書きながら外をみると雨降りでのんびり過ごした一日だった。

ストレッチ

今週も資料作りをしていただけでプレッシャーやストレスなどは皆無なので体調よいのだろうと思っていたけど、思いの外、腰の張りはあったので想定したよりは疲れていたかもしれない。もしかしたら、その前の週が連休だっただけに連休明けの週だから身体的に余計に疲れたのかもしれない。今日の開脚幅は開始前155cmで、ストレッチ後159cmだった。いつも通りの数値。初めて縦方向に開脚するストレッチをしてみたら、股関節の可動域のよくないところがきつかった。家でも意識して伸ばしてみようと思う。

0時に寝て6時に起きた。昨日の夜に展望の資料を作りやるつもりがバテて寝てしまったので朝から作ってた。日中はふりかえりの資料を作っていて、それも作り終えたので来週の東京出張の準備は概ね終わった。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今日の議題はこれら。

• デザイナーさんとの契約の話し
• 第5期の展望

後者の資料を昨日の夜に作ろうと思いながら帰って晩ご飯食べたら疲れて家でのんびりしてしまった。最近あまりよくない傾向として、晩ご飯を食べに家に帰ると戻って来れなくなることが多い。たまに日記でも書いているが、23時や24時に晩ご飯を食べると寝ているときに胃酸が逆流して吐き気を催したり、最悪、吐いたりする。そうなると夜中に1-2時間は眠れなくなって辛いので夜遅くに食べるのを避けるため、19時前後に家に帰って晩ご飯を食べるようにし始めた。おそらく身体的には晩ご飯なんかもう食べなくてよいはずなのに食べてしまうのはストレスや糖質への依存症なのかもしれない。これはまた別の話し。

オフィスから家が近いので晩ご飯を外食せずに済むことはよいことなのだが、本来なら晩ご飯を食べて20-21時頃にオフィスへ戻って作業の続きをするのが望ましい。このモチベーション管理がとても難しい。本当の意味では、オフィスに戻って作業しなくてもよいと頭で理解してしまうとついついさぼってしまう。それは私のモチベーションが低いだけでしかない。さぼると多少の自己嫌悪があってさらにモチベーション管理が難しくなる。

閑話休題。今朝7時からオフィスへ出掛けて資料を作り始めた。期ごとのふりかえりや展望を毎年やっていることには意味があって、昨年の資料を見返すきっかけになる。昨年立てた展望がどうなったかというふりかえりにもなるし、できていないことは今季も継続するのか、やめてしまうのかという判断材料にもなる。毎年の積み重ねとして気付きを溜めていくという見方もできる。どんなことでも継続していると役に立つ。

起業したときにざっくり10年の計画を3つのステージに見立てた。そして、最初のステージは想定通り進捗し、今季は2つ目のステージへの過渡期となる。起業してもう4年目、4年も経ったんやなぁと思う。年月は早い。マイルストーンの1つとしていた 経営セーフティ共済 の積立が完了する。

昨年からマーケティングの施策をやっていこうと立案したが、jjug ccc で発表したこと以外は目立った成果をあげていない。日々のお仕事にいっぱいいっぱいになっていて、最低限のことをやっていくだけで生活に余裕はあまりない。その余裕のなさは、先にも書いたモチベーション管理からきているのか？体力的なものなのか、それらが加齢によるものなのかはまだよくわからない。普通に考えると40歳を超えると、いろんな要素が下り坂になっていくことは想定されるので元気のあるうちに新しい施策や行動につなげるのが安全な考え方ではないかと思う。

0時に寝て何度か起きて7時に起きた。今日も一日資料作りをしていた。

gitlab issues の解析

ふりかえりの資料を作っていて gitlab issues の解析を始めた。gitlab にも分析系機能は提供されているが、大半が有償機能で free では使えない。実質 free で役に立ちそうなレポートを私はみつけられなかった。

• Analyze GitLab usage

gitlab は glab cli というツールを提供している。試しに glab を使って issues の解析ができないかとやってみたが、グループ単位ではなくプロジェクト単位でしか操作できないようにみえた。そこで rest api を呼び出すための便利ツールとして使うことにした。要は rest api で任意のデータを取得してそれを使ってローカルで解析することにした。例えば、次のようにして特定ラベルを除外した特定グループのマイルストーンごとの issues をすべて取得できる。

$ mygrpid="xxx"
$ milestones="2022-11 2022-12 2023-01 2023-02 2023-03 2023-04"
$ for i in $milestones; do echo $i; glab api --paginate "groups/${mygrpid}/issues?milestone=${i}&not[labels]=Duplicate,Invalid,Wontfix" | jq -c '.[]' > "${i}-issues.json"; done

あとはこの json データをそのまま分析のためのデータベースに取り込む。今回は mongodb にインポートしてみた。mongodb だとスキーマを定義しなくても json データをそのままインポートできてアドホックな分析に便利そうに思えた。オブジェクトの入れ子構造をもつ json データのようなものを rdbms にインポートするのはひと工夫必要なことから json データをそのままインポートできるドキュメントデータベースの有効性を理解できた。インポートしたら MongoDB Shell を使うとてっとり早い。例えば、マイルストーンごとの issues の件数などは次のようにして集計できる。

gitlab> db.issues.aggregate([{ $group: { "_id": "$milestone.title", count: { "$sum": 1 } } }, { $sort: { _id: 1 }}])
[
  { _id: '2022-11', count: 348 },
  { _id: '2022-12', count: 346 },
  { _id: '2023-01', count: 338 },
  { _id: '2023-02', count: 357 },
  { _id: '2023-03', count: 347 },
  { _id: '2023-04', count: 336 }
]

担当者別に Enhance ラベルが付いた issues の件数を数えるときには次のようになる。sql を使えないというデメリットを json データをそのままインポートできるメリットの方が上回るときは mongodb のクエリを学ぶ機会になる。私も mongodb の aggregation の実行方法をドキュメントみながらやってた。全然わからないので慣れが必要になる。

gitlab> db.issues.aggregate([{ $group: { "_id": { assignee: "$assignee.username", enhance: {$in: ["Enhance", "$labels"]} }, count: { "$sum": 1 } } }, {$match: {"_id.enhance": true}}, { $sort: { _id: 1 }}])
[
  { _id: { assignee: 'bob', enhance: true }, count: 84 },
  { _id: { assignee: 'john', enhance: true }, count: 143 },
  { _id: { assignee: 'mary', enhance: true }, count: 53 },
  { _id: { assignee: 'parks', enhance: true }, count: 78 }
]

1時に寝て7時に起きた。来週は出張なのでその準備もいるし、連休明けから急に忙しくなってきた。今日も一日中資料を作成していた。来週に東京出張して集中的に打ち合わせする。その叩き台の資料を作っていた。

建物の登記

登記の専門家として 土地家屋調査士 という士業があるらしい。相続に関して土地家屋調査士さんと話したので少し書いておく。相続のやり取りで実家の建物を母が相続する段取りで進めていたが、どうやらうちの建物はすべて未登記らしい。土地家屋調査士さんが言うには、未登記の建物は相続できないという。いまは建物を建てると原則として法務局に不動産として登記することが義務付けられている。昔もそうだったかもしれないけど、昔はいまよりも適当だったので未登記の建物がたくさんあるという。

最近は法律が改正され、未登記だと10万円以下の過料を支払うという罰則が設けられた。しかし、歴史的経緯によって現実として世の中に未登記の建物がたくさんあるとわかっていて、本当にすべての建物に10万円以下の過料を行政が取り立てるのか？というと、土地家屋調査士さんもそれは懐疑的だという。おそらく過渡期においてはなんらかの救済措置が取られるのではないかといった話しもされていた。

建物が未登記であっても固定資産税の支払いはできるために、実質的に登記というのは誰がその建物を所有しているかを第3者向けに証明するのみに過ぎない。例えば融資を受ける場合には必須となる。他人が住んでいる建物を自分のものだと主張して裁判になるといったことは、普通に生活していて起きることではない。未登記でも実質的に困ることはない。何十年も昔から未登記でそんなことは1度も起こっていない。固定資産税は地方自治体が管理している固定資産税評価額に基づいて支払うため、その金額に基づいて相続税も申告して支払える。土地家屋調査士さんによれば、未登記の建物は相続できないのに。これは行政の管轄の違いによって起きていると推測される。

そして、いま未登記だということは、祖父から父への相続がなされていないという解釈になるという。そのため、登記にあたって父ではなく、祖父の相続人に対しての確認をした上でいくつかの手順を踏んで登記の手続きを進めないといけないという。

• 未登記建物がもたらすリスクとは？登記方法と相続する場合の手続きも解説

表題登記を行うためには、司法書士への依頼費用が2〜3万円ほど、土地家屋調査士へ依頼する費用が8〜12万円ほど必要です。

調べていると、なぜ未登記の建物が多いかというと士業への費用を節約するためだという。士業の方々に登記を依頼するとそれなりの費用がかかる。この費用を支払っても得られるメリットがないときにこれまで未登記が選択されてきたという。土地家屋調査士さんに「このまま未登記で困ることありますか？」と聞いたら、親族でお金に困った人が出てきたときにその建物の所有権を主張して云々みたいな話しを始めたので、途中で嫌になって「そのリスクは受け入れます。」と遮ってしまった。ほとんど資産価値のない、田舎にある老朽化した建物を、お金に困った人が所有権を主張するとは現実的に考えにくい。

うちにとっては未登記の建物のデメリットは事実上ないようにみえる。土地家屋調査士さんの作業だけで登記できるならやってもらって構わないが、祖父からの相続を考慮して親戚をまわって念書と印鑑証明を集めて登記するといったことは、デメリットに対して労力が大き過ぎると私は判断した。相続税は支払うが、建物は未登記／未相続で進めてもらってよいという主旨の回答をした。士業の方々がその要件に納得するかどうかはまだわからない。