アーキテクトの仕事の大半は「選択する」ことにあり、それは物事が起きる前にされるので後から変更することができません。
アーキテクトの選択対象は静的な構造です。構造は確定すると劣化を始めます。時間軸の変化に適応する幅は小さく、一度選択されたものを変更するのには大きな代償が伴います。
もちろん、プロジェクトマネージャーもスケジュールや体制を「事前に選択」します。ただし、その選択対象は動的なプロセスです。
動的なプロセスは時間軸の中で変化に適応することができます。アジャイルなどのイテレーション（繰り返し）を含む開発プロセスは短期的なゴール選択と実績棚卸しによる適応を推奨しています。これは非常に有効な手法です。動的プロセスは事前の選択における過ちを認め、それを事後的に変更させることができます。
「Good managers do things right（優れたマネージャーは事を正しくする）」という言葉ありますが、プロジェクトマネージャーは事前の選択（予定）と事後的な活動（実績）のズレを把握し、それに対して様々なパラメタを調整して予定通りの状態に戻す作業をしているのです。
ところが、アーキテクトの選択は対象物が静的な構造なのでアジャイル的に進めることができません。
PO（Proof of concept/概念実証）やプロトタイプといった「試してみて評価する」という行為は有効です。ただ、POやプロトは未知というリスクを軽減して事前の選択を促すための手段であって、選択した結果としての事後適応を可能にするわけではありません。
では、こうした状況でアーキテクトはいかに選択をすべきなのでしょうか。
「ソフトウェアアーキテクトが知るべき97のこと」（オライリージャパン）には、「24：不確定性が潜むという感覚を磨け」というエッセイがあります。
2つの選択肢を目の前に突き出されると、ほとんどの人々は、どちらかを選ぶことが最も大切なことだと考えてしまいます。しかし、ソフトウェアに限らず、設計ではそうではありません。2つの選択肢があるということは、設計の中に不確実確定性が潜んでいると感じなければならないというシグナルなのです。
著者であるケブリンは「選択できるようになるまで決断を先延ばししろ」と書いています。これは非常に大事なことですが、もちろん、いつまでも先延ばしすることはできません。ぼーっと選択できる日を待っていては手遅れになります。
ですから、アーキテクトは「そうでしかない決定」をするために、今、できる限りのことをするということが重要になります。
選択肢があって、そこに迷いがあるということは判断の基準が定まっていないということです。その判断の基準を探すことこそが重要なのです。
そもそも、優れたアーキテクトは判断そのもの意味を小さくすることができるはずです。どちらのアーキテクチャを選択しても、なんとかする自信はある。でも、それでは「そうでしかない決定」に至ることはできません。
つまり、今、目の前にある判断基準ではない、なにか、決定に至るためのパラメタを探すのです。それは時間軸や空間軸で考えることができます。
1年後は？2年後は？3年後は？
プログラマの視点では？PMの視点では？ユーザーの視点では？運用者の視点では？
そうやってステークホルダーのビューポイントを拡げていき、判断するための基準を探すのです。想像だけじゃ分からないでしょうから聞きに行きましょう。どうすれば判断基準を引き出すことができるのか戦略を立てましょう。彼ら自身の行動原理はなんでしょうか？
そうして「そうでしかない決定」に至ることができます。
どんなに頑張っても「そうでしかない決定」に至れないとしたら、足りないのはきっと覚悟です。その選択に責任を取ること、あるいは未来へのリスクに立ち向かうことができていない。
その選択は間違っているかもしれない。でも「この選択しかない」と言い切る覚悟が必要です。「それでしかない決定」に至る努力をし続け、最後は直感にも似た僅かな差で選んだ、そこへの覚悟です。
覚悟がないと「そうでしかない決定」に至るための行動ができないのです。どんな大きさのプロジェクトであれ、アーキテクチャの決定は、そのプロジェクトに関わった多くの人々に影響します。これを背負う覚悟です。
権限は先に与えられるものではなく、責任を取る覚悟によって生まれてくるものです。覚悟をしていれば誰に向かってでも「これが正しい選択だ/それは間違った選択だ」と言い切れるのです。
未来は常に不確定です。でも、その中で事前的な選択をするしかない。そこで「そうでしかない決定」に至るのために戦略を練ることが、アーキテクトという職能の本質ではないでしょうか。
