きっかけは庭の水やりだった
うちのベランダで小さな家庭菜園をやっているんですよね。トマトとバジルを隣同士に植えている。毎朝「水やったか？」と自分に確認する。でもある日、バジルだけ枯れかけていた。水はやっていた。問題は、トマトが育ちすぎてバジルの日光を遮っていたことだったんです。
「確認した」は事実でも、見るべきものを見ていなかった。これ、コードレビューでもまったく同じことが起きるんですよね。
確認のチェックリスト化が招く盲点
仕事でもよくある光景です。プルリクエストのレビューで「テスト通ってます」「型チェック問題なし」と確認項目を潰していく。形式的には完璧。でもデプロイしたら別のサービスが落ちる。
原因はモジュール間の依存関係だったりする。確認の粒度が「個」に閉じていて、「関係」を見ていなかったんですよね。チェックリストは安心を生むけど、安心が観察を止めるところがあります。
問い方を変えると見えるものが変わる
私が最近意識しているのは、「これは動くか？」ではなく「これが動くと、隣は何が変わるか？」という問い方です。
庭でいえば「水は足りてるか？」ではなく「この株が育つと、隣の株はどうなるか？」。コードでいえば「この関数は正しいか？」ではなく「この変更で、呼び出し元のふるまいはどうなるか？」。
問いの方向を「点」から「線」に変えるだけで、見落としがかなり減ることに気づく。
依存関係は人間関係にも似ている
あ、確かにこれは人間観察にも通じる話で。職場で誰かの業務量が増えると、隣の人の負荷も静かに変わっている。本人に「大丈夫？」と聞いても「大丈夫です」と返ってくる。でも本当に見るべきは、その人の周囲に起きている変化だったりするんですよね。
確認は「点」にしか届かない。見守るとは「線」を追うことだと思うんです。
さらっとした結論
形式的な確認をやめろという話ではないです。チェックリストは便利だし、必要です。ただ、それだけで安心してしまうと、依存関係の変化を見逃す。「問い方の設計」を少し変えるだけで、見える景色がだいぶ違ってくるんですよね。
庭も、コードも、人も、単体で完結しているものはほとんどない。そういうことだと思うんです。
—
話は変わりますが、依存関係やプログラムの構造を基礎から学び直したいとき、意外と古い実践書が役立つことがあります。[【中古】(未使用品)DirectX9実践プログラミング 書籍版 (I／O BOOKS)](https://hb.afl.rakuten.co.jp/hgc/g00tje4n.32dfvead.g00tje4n.32dfw1d9/?pc=https%3A%2F%2Fitem.rakuten.co.jp%2Fcocohouse%2Fs4875934998%2F&m=http%3A%2F%2Fm.rakuten.co.jp%2Fcocohouse%2Fi%2F10940075%2F&rafcid=wsc_i_is_f88aacae-24ae-4ba9-a32a-ec20791edb22)（参考価格 ¥14,499）は、描画パイプラインの依存構造を体感できる一冊です。モジュール同士がどう繋がるかを手を動かして理解するには良い教材だと思います。
また、お子さんがいる方には[スタディーノではじめる うきうきロボットプログラミング](https://hb.afl.rakuten.co.jp/hgc/g00tv62n.32dfv45d.g00tv62n.32dfwa04/?pc=https%3A%2F%2Fitem.rakuten.co.jp%2Fkrstlm%2Fc2310-atc-025797%2F&m=http%3A%2F%2Fm.rakuten.co.jp%2Fkrstlm%2Fi%2F10103837%2F&rafcid=wsc_i_is_f88aacae-24ae-4ba9-a32a-ec20791edb22)（参考価格 ¥2,999）もおすすめです。ロボットのパーツ同士の依存関係を、子どもと一緒に体験できる。「これを動かすと、あっちはどうなる？」という問い方の練習に、うちの子にもそのうち触らせたいなと思っています。
→ プロフィール / 他チャネルを見る
コメント