【11】500 行の仕様書より 1 行のコード

アリソン・ランダル

 設計はすばらしい仕事です。問題空間と解決方法について、詳細、系統的に説明を加え、見直しをかけていくと、目から鱗が落ちるように、誤りや改善のチャンスが見えてくることがあります。仕様書は、高層ビルを建てるためのパターンを示すという意味で大切です。コンポーネント間のやり取りのようなマクロレベルでも、コンポーネント内のふるまいのようなミクロレベルでも、アーキテクチャーについて時間をかけて考え抜くことはとても大切です。

 ただ、注意しなければならないのは、設計プロセスに夢中になりすぎると、抽象的なアーキテクチャーに心を奪われてしまうことです。仕様書は、それだけでは何の価値もありません。開発プロジェクトの最終目標は、システムを本番稼動させることです。ソフトウェア・アーキテクトは、常にこの目標を見据え、設計はそのための手段に過ぎないことを忘れてはなりません。摩天楼をより美しくすることに心を奪われて、物理法則を無視した建築家は、すぐに後悔することになるでしょう。動くコードという目標を見失うと、プロジェクトは深刻な危機に直面します。

 あなたのビジョンを実装するチーム・メンバーを尊重し、彼らの言葉に耳を傾けましょう。彼らが設計書に手こずっているなら、彼らが正しくて設計が間違っているか、そうでないにしても曖昧だということです。こうなってしまったら、現実の制約に合わせて設計を書き換えましょう。チームメンバーの力を借りて、動く部分と動かない部分をはっきりさせればよいのです。最初から完璧な設計などありません。すべての設計書は、実装しながら書き直していく必要があるのです。

 もしあなたが実装もするなら、コードを書く時間を大切にして、間違ってもアーキテクトの気晴らしだと思われないようにしましょう。システムという化け物のはらわたの中で過ごした時間によって、あなたの視野はマクロ的にもミクロ的にも大きく広がっていくのです。