前章では、判断をコードに残す方法として、 名前・型・境界という具体的な手段を見てきました。

しかし、実際の開発は一人では行われません。 判断は、必ずチームの中で扱われます。

この章では、 判断を属人化させず、チームで扱える状態にするにはどうすればよいか をテーマに掘り下げていきます。

設計が属人化する本当の理由

設計が属人化している現場では、よく次のような状態が見られます。

  • あの人しか触れないコードがある
  • 変更前に必ず特定の人に確認が必要
  • レビューが形式的になっている

これは単に「その人が優秀だから」ではありません。

多くの場合、 判断がコードの外に置かれている ことが原因です。

  • なぜそうなっているのか
  • どこを壊してよいのか
  • どこは触ってはいけないのか

これらが共有されていなければ、 設計は必然的に人にひもづきます。

レビューは、正解探しではなく判断の確認である

コードレビューというと、

  • 書き方が正しいか
  • パフォーマンスに問題がないか
  • 規約に違反していないか

といった点に目が向きがちです。

もちろん重要ですが、 それだけでは設計レビューにはなりません。

設計レビューで確認すべきなのは、

  • この変更で、どんな判断を置いたのか
  • 既存の判断は変わっていないか
  • 判断の置き場所は適切か

という点です。

レビューとは、 判断の共有と再確認の場 です。

設計の会話は「構造」ではなく「理由」から始める

設計の相談や議論が噛み合わないとき、 話題がいきなり構造から始まっていることがあります。

  • このクラスを分けるべきか
  • モジュールを切るべきか
  • 共通化した方がよいか

こうした問いは、 理由が共有されていない状態では平行線になります。

先に共有すべきなのは、

  • 何が変わりやすいのか
  • 何を守りたいのか
  • 今回はどこを優先するのか

という判断の前提です。

理由が共有されていれば、 構造の選択肢は自然に絞られます。

暗黙知を減らすための小さな工夫

判断をすべてドキュメント化する必要はありません。

しかし、 暗黙知のままにしないための小さな工夫 は有効です。

  • PR の説明に「今回置いた判断」を一行書く
  • レビューコメントで「ここはあえて分けていない理由」を残す
  • 名前を変えるときに、責務の境界が分かる名前にする

これだけでも、 判断は少しずつコードの外に漏れにくくなります。

判断が共有されると、責任も分散される

判断が共有されていないチームでは、

  • 設計ミスの責任が個人に集中する
  • 変更が怖くなる
  • 新しい提案が出にくくなる

という問題が起きがちです。

判断が共有されていれば、

  • 設計はチームのものになる
  • 壊すことへの心理的負担が減る
  • 改善の提案がしやすくなる

設計は、 個人技からチームプレイへ 変わっていきます。

チームで設計するとはどういうことか

チームで設計するとは、 全員が同じ答えを持つことではありません。

  • どこに判断があるか分かる
  • どこを変えればよいか議論できる
  • 違いを前提に合意できる

この状態を作ることが目的です。

設計とは、 合意形成のための共通言語 でもあります。

まとめ

  • 設計が属人化する原因は、判断が共有されていないことにある
  • レビューは判断を確認し、更新する場である
  • 構造ではなく理由から会話を始める
  • 判断が共有されることで、設計はチームのものになる

次章では、 これまでの内容を踏まえ、 設計者の責任とは何かを改めて考えます。