技術選定の不確実性に向き合うためのアーキテクト思考

技術選定とは何か

米久保：「技術選定の不確実性に向き合うためのアーキテクト思考」というタイトルでお話しさせていただきます。オープニングのセッションですので、そもそも技術選定とは何かというところから入りたいと思います。

まず、「技術」の語源は古代ギリシア語の「テクネー」で、物をつくるために必要な知識やそれを使う技を意味します。ソフトウェア開発の文脈では、利用するミドルウェアやライブラリ、フレームワーク、ツール、あるいはそれらに関する知識を活用してアーキテクチャやコンポーネントを設計していく技能が該当します。「選定」を分解すると、選んで定めるということです。複数の候補の中から目的に合うものを選び、最終的に1つに絞り込んで意思決定するという行為になります。

技術選定の難しさについても触れておきます。要件を正しく捉えること自体が難しく、要件は時間の経過につれて移り変わっていきます。それを解決するための技術の選択肢も多く、変化のスピードも速い。そうした状況下で複雑かつ高度な意思決定を求められるというのが、この行為の難しさです。加えて、技術選定を行うための「技術」自体が体系化されておらず、暗黙知となっている状況もあると見ています。

本日のセッションのゴールとしては、ジュニアや若手の方にとっては技術選定に必要な原理原則や基本的な考え方を持ち帰っていただくこと。中堅やベテランの方にとっては、技術選定という営みを見つめ直して暗黙知を形式知化し、後輩に伝えていくきっかけにしていただくことを目指しています。

技術選定の本質

そもそもなぜ技術選定をするのか。それは、技術で解決したい課題があるからです。技術そのものは目的ではなく手段に過ぎません。何らかの課題を解決したいからこそ、選定を行う必要があるのです。

例えばGitを例に考えてみます。今、プロジェクトを立ち上げるときにバージョン管理システムを何にしようかと検討することはほぼありません。それほどGitは当たり前のツールになっています。しかし15年ほど前はまだGitが出たばかりで、Subversion（SVN）が広く使われていた時期がありました。SVNは中央集権型のバージョン管理システムで、最後にブランチを統合する「マージが非常に大変」という課題がありました。その課題を解決する分散型のバージョン管理システムとしてGitが普及していったわけです。

SVN → Git

Gitが急速に広まった背景には、周辺ツールの充実やGitHubのエコシステムの構築、ブランチモデルのノウハウが普及してきたことがあります。その結果、Gitを使わない理由を探すほうが難しくなり、バージョン管理システムについてはソフトウェアの選定プロセスを発動する必要がなくなりました。

一方で、Gitの周辺にはまだ技術選定の余地があります。ホスティングサービスをGitHubにするかGitLabにするか、どのプランを契約するか、リポジトリ構成をモノレポにするかマルチレポにするか、日々開発者が使うクライアントツールをどうするか。会社やプロジェクトとして標準が決まっている場合もあれば、個別の課題を解決するために検討が必要な場合もあります。

さらに、今でこそGitが当たり前のツールになっていますが、未来永劫そうとは限りません。例えばAIエージェントを使った並行開発においてgit worktreeを活用する技法がありますが、AI開発を前提としたバージョン管理ツールが必要になる可能性も十分に考えられます。

何のために技術選定をするのか、あるいはしないのかを明らかにし、目的ドリブン、課題ドリブンで技術選定を進めていくことが大切です。

見えない敵、認知バイアス

技術選定を行うのは人間です。人間の認知の仕組みをきちんと理解しておくべきだと考えています。

人間の認知の仕組み

ダニエル・カーネマン博士が提唱したシステム1とシステム2という思考の枠組みがあります。システム1は速い思考と呼ばれ、直観的かつ無意識に働く仕組みです。パターン認識によって即座に判断できる思考にあたります。一方、システム2は遅い思考で、論理的かつ意識的に動きます。複雑な分析や計算に向いている思考の方法です。

技術選定は複雑な意思決定を伴うため、本来はシステム2で行うべきです。しかしシステム2は怠け者で、システム1に任せがちな性質があります。注意して意識的に働かせないとシステム2に移行しづらく、結果としてエラーが発生するリスクを抱えています。

『ファスト＆スロー』に紹介されている事例をご紹介します。熟練した消防士が火災現場の建物に入った瞬間、何かおかしいと感じて即座に撤退を命じました。直後に床が崩落し、危機一髪だったというエピソードです。消防士は第六感が働いたと語っていますが、実は長年の経験によって高度なパターン認識がシステム1の中で構築されていたのです。現場の温度や音などの情報を総合的に処理し、異常を検知できるようになっていました。

同様のことは熟練したベテランアーキテクトにも起こります。このやり方は危険そうだという直感が働くことは良いことですが、それを個人の暗黙知にしておくのはもったいないですし、スケールしません。形式知化していく取り組みが必要です。

認知バイアスの具体例

人間の認知や判断には系統的な歪みがあります。経験則（ヒューリスティック）は普段は便利ですが、技術選定のような複雑な判断では落とし穴になります。認知バイアスがどのようなものか知っておくだけで、回避がしやすくなります。

具体的に3つの認知バイアスを取り上げます。

1つ目は「確証バイアス」です。自分の仮説を支持する情報ばかり集めてしまう傾向を指します。例えばマイクロサービス化すべきだという意見を持つと、成功事例や書籍ばかりに目が向き、失敗事例やモノリスのほうが適している状況の情報を集めていないということが起こりがちです。

2つ目は「バンドワゴン効果」です。みんなが使っているからそれは正しいと判断してしまうバイアスです。例えば「フロントエンドでみんなReactを使っているからうちもReactにしよう」という判断は、自社のプロジェクト特性やチームのスキルセットを十分に検討できていない可能性があります。

3つ目は「利用可能性ヒューリスティック」です。最近見聞きした情報や印象的な事例に影響を受けやすいというものです。例えば「先週のカンファレンスでRustの事例を聞いたからうちもRustで書き直そう」という判断は、印象的な情報に流されて学習コストや適用範囲の冷静な評価がおざなりになっている例です。

バイアスを回避するには

こうしたバイアスを回避するにはまず、自分の思考の癖を知ることが重要です。自分が普段どのようなバイアスに陥りがちかを分析しておくことが出発点になります。

次に、他者の振る舞いから学ぶことです。自分がバイアスに囚われていることには気づきにくいですが、他人が偏見を持っているところには気づきやすいものです。人の様子を見て自分自身を振り返ってみることが2つ目の回避策です。

3つ目はメタ思考です。一呼吸置いて自分自身を上から俯瞰してみる感覚で考えてみるとよいでしょう。

具体的な手法として、部外者テストを紹介します。

1980年代半ば、Intelはメモリ事業で日本企業との競争に苦しんでいました。CEOのアンディ・グローブが共同経営者のムーアに問いかけました。もし自分たちが会社を追い出されたら、次に来るCEOは何をするだろうか、と。ムーアは半導体メモリ事業から撤退するだろうなと答えました。それを受けてグローブは、それならば自分たちの手で撤退すべきだと考え、実際にメモリ事業から撤退してマイクロプロセッサに集中し、V字回復を遂げたのです。

このように第三者の視点に立って考えることは、有効なバイアス回避策になります。認知バイアスを自覚し、メタ思考を活用して回避していくことが大切です。

見えない死角、未知の既知

ラムズフェルドの4象限で考える

ラムズフェルドの4象限というフレームワークがあります。自分たちが知識を持っているかどうかと、そのこと自体を認識しているかどうかの掛け合わせで物事を分類する考え方です。これを技術選定に当てはめてみます。

1つ目の象限は「既知の既知」です。何を知っているかがわかっている状態で、明確な基準で比較評価が可能です。通常のトレードオフ分析で対処できる領域にあたります。

2つ目は「既知の未知」です。何を知らないかがわかっている状態です。不明点は把握しているものの、答えがまだ見つかっていない領域ですので、調査やPoCを通じて未知を既知に近づけていくことで解消できます。

3つ目は「未知の既知」です。実はその知識を持っているにもかかわらず、そのことに気づけていない状態です。組織内で知識が共有されていない場合や、認知バイアスによって盲点になっている場合がこれに該当します。

4つ目は「未知の未知」です。何を知らないのかすらわかっていない状態で、技術選定において最もリスクが高い予測不可能な領域です。これに備えるのは難しいですが、設計に柔軟性を持たせておくことや、決定自体を遅らせることで対応していく領域です。

「未知の既知」に手を打つ

未知の既知の具体例としては、何年か前にすでに同じ技術について選定を行い、結果として不採用にしたという経緯があるのに、人の入れ替わりの中で記憶が薄れて同じ検証を繰り返してしまうケースがあります。あるいは隣のチームがすでに同じ技術を導入していてハマりどころも把握しているのに、自分たちはその知見を持っていないというケースです。

見えることは気づくことです。気づくための仕組みをつくっていくことが重要になります。具体的な方法として、まずADR（Architecture Decision Record）として過去に行った判断理由を記録し、検索可能な状態にしておくことが挙げられます。次に、選定プロセスに必要なステークホルダーを早期から巻き込んで一緒に検討を進めることです。そして選定の振り返りとして、今わかっている情報をもとに当時に戻ったら同じ選定をするだろうかという答え合わせを行い、新たな気づきを得る仕組みをつくるとよいでしょう。

トレードオフ分析の要諦

Claude Code導入の意思決定を題材に

身近にあった具体例でお話しします。「開発チームにClaude Codeを導入したい」という稟議が上がってきました。弊社の場合、GitHub Copilotのように標準化されたツールであればすぐに使えますが、それ以外のツールを使う場合は申請や予算取りが必要になります。

この稟議に対してマネージャーとしての意思決定、つまり承認が難しかったことがありました。理由は3つあります。比較評価軸の選定基準や妥当性が曖昧だったこと。トレードオフ分析の結果と結論の間の因果関係が弱いと感じたこと。そして、選定にあたって当事者の思い込みや認知バイアスが入っている可能性を払拭できなかったことです。

最終的にどうしたかというと、AIにディープリサーチを指示してClaude Codeに関するレポートを出力させ、そのレポートを一緒に眺めながら技術選定のポイントを共有した上で選定しました。評価軸を先に設定し、AIに調査をさせ、一緒にレビューすることで知識の共有を行い、最終的な意思決定に至りました。

AIに出力させたレポートのサンプル （レポート全文）

評価軸の設定が意思決定の要

トレードオフ分析にあたっては、まず比較評価する観点や項目を洗い出す必要があります。一般的な品質特性から引き出したり、AIと壁打ちしたりしてリストアップしていきます。

重要なのは、リストアップした評価軸について優先度付けを先に行うことです。絶対に譲れない最重要項目は何か、ノックアウトファクターとなる項目はどれかを明確にしておきます。今回の例では、エンタープライズ企業として本番利用する際の厳格なセキュリティ要件をクリアすることが最重要でした。その上で、開発者が利用したい機能を十分に使えること、リーズナブルな価格体系であることが次の評価項目として挙がりました。

なぜ評価軸を先に定めるのか。それは認知バイアスとの関連があります。確証バイアスが働くと、どうしても結論ありきの評価軸設定をしてしまいがちです。それを避けるために先に決めるのです。また、各軸で点数をつけて合計点が高いものを選ぶ総合点方式もありますが、その絶対値だけで意思決定をするのは危険です。

自分たちが優先すべき評価軸は何かという検討を、ステークホルダーを含めて行い、合意形成をしていくプロセスそのものが技術選定の根幹にあたります。評価軸を先に選ぶことが、技術選定という意思決定プロセスの要です。

AI時代の技術選定

AIがもたらした変化

AIの普及によって技術選定の様相が変わってきました。ディープリサーチを使えば、高速かつ網羅的な調査を手軽に、短時間で行えるようになりました。AIエージェントの活用により、並列での実装検証も高速に進められます。

Last Responsible Moment（LRM・最終責任時点）という考え方があります。重要な意思決定は、それ以上遅らせると悪影響が出る直前まで先延ばしにするという考え方です。不確実性が高い領域では判断を遅らせることに合理性があり、AIによって調査や検証を高速化できるようになったことで、このタイミングを後ろ倒しにすることが可能になりました。

ただし、意図的に遅らせることと、考えること自体を先延ばしにすることは違います。不確実性を自分たちできちんと管理していく必要があります。そして、その管理の仕方は不確実さの性質によって、打ち手が変わってきます。

4象限で見る不確実性の管理

先ほどの4象限に不確実さの度合いを当てはめて考えます。

既知の既知は、不確実さの度合いがすでにわかっている領域です。情報の正確性が高まってから意思決定すればよく、選定時期をコントロールできます。

既知の未知は、不確実さがありそうだとわかっているものの、その度合いがわからない領域です。AIを使った調査やPoCで、何がどのくらいわかっていないかを明らかにしていくことが有効です。

未知の既知は、不確実さについて実は知見が存在しているのに、選定者の視野に入っていない領域です。AIを使って外部のディープリサーチをしたり、社内に蓄積された知見をエンタープライズサーチで横断的に検索したりすることで情報が見つかり、不確実さが減少する可能性があります。ADRやポストモーテムの結果を蓄積しておき、AIに検索させることで組織の形式知に変換していけるのではないでしょうか。

未知の未知は、不確実性の管理自体が困難な領域です。決定の可逆性を高めておくことが備えになります。設計時に抽象レイヤーを設けて、特定技術へのロックインを避けるといった対策が考えられます。

AI固有のバイアスへの注意

AIを徹底活用することで不確実性の管理可能性は高まりますが、AI自身にもバイアスが存在することには注意が必要です。

1つ目はハルシネーションです。AIは間違える前提で、チェックと訂正のプロセスを設計しなければなりません。2つ目はユーザーへの忖度です。AIはユーザーの期待に沿った回答を出しがちであり、これがユーザー自身の確証バイアスと組み合わさると危険性が増します。3つ目は平均への回帰です。AIは学習データの平均に収束しやすい特徴があるため、それを鵜呑みにしていると凡庸な技術選定をしてしまうリスクがあります。

「流されるな、選べ」

アーキテクトやテックリードとしては、エッジの効いた技術選定ができるように日々審美眼を磨き続けていく必要があります。AIの活用で不確実性の管理はしやすくなりますが、最後に選んで定めるのは人間の審美眼です。

最後に

ソフトウェア開発において不確実性は避けられないものです。しかし、見えないものを見えるようにして、正しいプロセスで意思決定をしていけば、逆境を乗り越えていくことは可能だと考えています。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画・資料はこちら

※動画の視聴にはFindyへのログインが必要です。