不確定性が潜むという感覚を磨け

2つの選択肢を目の前に突き出されると、ほとんどの人々は、どちらかを選ぶことがもっとも大切なことだと考えてしまいます。しかし、ソフトウェアに限らず、設計ではそうではありません。2つの選択肢があるということは、設計の中に不確定性が潜んでいると感じなければならないというシグナルなのです。「不確定性が潜んでいるぞ」という感覚を磨くことで、詳細に踏む込むのを待つ箇所、あるいは設計の判断が大きく影響しすぎないように分割や抽象化をする箇所がどこかを見抜くことができます。最初に思いついたことをコードに埋め込んでしまうと、その判断に縛り付けられてしまいます。思いつきの判断に引きずられて、ソフトウェアの柔軟性が失われてしまうのです。

アーキテクチャーについてのもっとも単純でもっとも建設的な定義は、グラディ・ブーチによるものでしょう。「すべてのアーキテクチャーは設計だが、すべての設計がアーキテクチャーだというわけではない。アーキテクチャーとは、システムの形を左右する重大な設計の判断である。その重大さの度合いは、変更のためにかかるコストによって計測できる」この考えをさらに進めると、効果的なアーキテクチャーとは、設計上の判断が持つ意味を軽くできるアーキテクチャーである、と言うことができます。出来の悪いアーキテクチャーは、重大性を増幅させます。

設計の判断として2つの選択肢のどちらを選んでもよさそうな感じがするときには、アーキテクトは1歩下がって考えなければなりません。選択肢AとBのどちらを選ぶかではなく、AとBのどちらを選んでも、それほど重大な意味を持たないようにするために、どう設計するかを考えるのです。もっとも重要なことは、AとBのどちらを選ぶかではなく、AとBという選択肢が存在し、正しい選択が自明ではない、あるいは、場合によって答えが変わるという事実なのです。

アーキテクトは、めまいを起こして二者択一に踏み込む前に、堂々巡りの内側に入らなければなりません。ホワイトボードの前に立って、選択肢について同僚と熱く討論を重ねますか？何かのコードの前で「うーむ」とうなり、どちらの実装を試すべきか迷って立ち止まりますか？新しい要件が加わった結果、あるいは要件を明確にした結果、現在の実装の妥当性に疑問が投げかけられるようなら、それは不確定性です。そんなときは、最終的に設計の判断によって左右されるのは避けられないとしても、その影響を小さくするためには、どのような分割やカプセル化をすればよいかを考えましょう。このような感覚がなければ、面接で緊張してしどろもどろになった人のように、不確定性を埋めるために疑わしくて重大な影響を持つ選択をいくつも重ねて、コードをとんでもない方向にゆがめてしまいます。でなければ、根拠のない自信によって、後ろを振り返ることなく、猛スピードで間違った方向に突き進んでしまいます。

判断のための判断を下せという圧力を感じることがよくあります。このようなときこそ、不確定性の感覚を織り込んだ思考が役に立ちます。システム開発が今後進むべき方向が何種類かあって、どれを選ぶべきかがはっきりしない場合には、判断をしないという判断をしましょう。実際的な知識に基づいて、今よりも責任を持って判断を下せるようになるまで、実質的な判断を先延ばしにするのです。ただし、判断を下すのが遅くなりすぎると、その知識を活用できなくなりますので、注意が必要です。

アーキテクチャー設計と開発プロセスは絡み合っています。だからこそ、アーキテクトは、開発サイクルとアーキテクチャーに対して経験主義的なアプローチを取り、不確定性が存在するという見通しに基づいてシステムとスケジュールを分割してフィードバックを引き出す必要があるのです。