🤔システムの設計と組織の設計は似ている

僕は過剰に汎用化、オーバーキルな設計をしてきて最終的に技術的負債を作ってしまったことがある。

具体的には、関数を作成するときの考慮するとき。

その場ではは十分な判定の仕方があったが、長期的に見ると別の実装方法も十分に考えられる。

いままで、長期的なことを鑑みてBの選択をすることが多かった。

だけどこれによって短期的にも、長期的にも不利益が大きかった。

• 短期的にコスパの悪い実装＝時間がかかる
• スコープの増大＝バグリスクの増大＝確認スコープの増大＝企画者が意図しない機能への影響
• 不必要に複雑度が増し、必要なロジックに対して過剰なアーキテクチャ・考慮により見通しの悪いコード
• 不要な考慮により、あとから発生したイシューと考慮がミスマッチする

特に あとから発生したイシューと考慮がミスマッチする がここで伝えたいポイント。

イシューがないアプローチは避けたい

どこまで長期的に考慮すべきか？はいつもエンジニアの頭を悩ませる問題。

最近思うことは「イシューがなければその考慮は最適解かもわからない」こと。

端的的に問題を解決し、１歩先の問題を考慮した設計をしておき、長期的な考慮はイシューが発生したら考えればいい。

影響度や実装度がいまもあとも変わらないならなおさら。

組織の設計？

例えばいろんなことをルール化するか？という疑問がある。

は「どこまで考慮して具体的な設計をするか？」という前半のくだりと思考プロセスは同じだと思う。

ここで考えるべきは、「なにを解決したいのか？」「どんな目的でやるのか？」を押さえてアプローチすべきで、いま存在しないイシューを考慮したルールは、最適なルールではないことが多い。

まずはなにを解決したいのかを改めて整理した上で、解決するイシューごとにアプローチを決めていくことが不要な議論を防ぎ、過剰な細かなルールを防ぐことになると思っている。

できれば基本原則だけを定め、細かなルールはその原則の上で各メンバーが自主的に載せていくのがコスパのいい組織のあり方じゃないかと思う。