決めない技術選定

kawasima：今日の登壇資料はゲームとして作ってきましたので、ゲームプレイ実況をしていく形でお話を進めていきます。

テーマは「決めない技術選定」です。

シナリオ紹介

セッションの前半では、ゲーム内のシナリオが進行しました。ここではシナリオの概要を紹介します。ぜひアーカイブ動画や実際のゲームプレイで詳細をお楽しみください。

あるECサイトの開発現場で、マネタイズ施策をどう実装するかを巡る会話劇です。登場人物は4人。

• 施策を推進したいマーケティング／PdM担当（中島）
• 開発の意思決定を担うテックリード（佐伯）
• 実装を担うエンジニア（石田）
• 設計上の懸念を出すエンジニア（村上）

中島から、マネタイズの仕組みを今週末までに出したいという要求が出される。会員プランをゴールド、シルバー、ブロンズの3つに分け、限定コンテンツとポイント倍率で出し分けたい構成だ。佐伯は既存のStripe契約情報をそのままセッションに持たせて出し分けに使う方針を打ち出す。

ここで村上が異を唱える。プランの種類は今決めなくていい、決めるべきはプランと権限の境界だ、プランの数や名前はマーケティングの都合で変わるはずだ、という指摘だ。しかし佐伯は、今週出せるかどうかが最優先だと押し切り、3プランで実装が始まる。

実装後、ゴールド会員向けのトライアル機能を追加したいという相談が入る。村上は再び、プランはビジネスの都合で変わるが権利の制御はシステムの安定性に関わる、この2つが結びついているのが問題だと整理する。しかし設計を今ひっくり返すのは重すぎると判断され、期限の日時を持たせて分岐条件を足し、例外として吸収する方針で進む。

その後、解約済みユーザーに限定コンテンツが見えるなどの障害が発生する。さらに新規プランやキャンペーン施策が次々重なり、分岐が増えすぎて影響範囲が読めず、テストも爆発する状態に陥る。結果として、施策が来るたびに毎回リリースが綱渡りになり、売上施策がそのままリリース作業になってしまう。プランと権利を混ぜた結果がこれだ、というのがシナリオの結末である。

何が良くなかったのか――認知的閉鎖欲求

ここから先は、シナリオの結末を受けて、登場人物の佐伯と村上が振り返りを行うパート。ゲーム内では2人が論点を投げかけ、kawasimaさんがその論点を解説していく形で進行します。

kawasima：実在しそうな、やりがいのあるシナリオを書いてみたのですが、何が良くなかったのかを見ていきます。

あまり知られていませんが、認知的閉鎖の心理学の研究があります。認知的閉鎖欲求（Need for Cognitive Closure、以下NFC）はバイアスの一種で、不確実性に対する態度を扱うものです。不確実性のある状態に対して高いストレスを感じる人と、そうでない人がいます。NFCは誰しも少なからず持っていますが、人によって高低があります。

佐伯「私の行動は認知的閉鎖欲求で説明できます。」

この欲求が高い人は、不確実な状態に非常に高いストレスを感じてしまい、その結果として衝動性と永続性が見られます。未解決な状態や不確実な状況に伴う心理的苦痛が我慢ならないので、いち早く答えが欲しい、決めて楽になりたい、という衝動性が出ます。そして、せっかく決めたものがまた揺らされるとさらに強いストレスを感じるため、できるだけそれを守ろうとする永続性が出ます。NFCが高いと、この2つの行動が出てきます。シナリオの佐伯は、まさにNFCが高い人物として描いています。

高いNFCが招く行動パターン

佐伯「多様な意見の重要さは理解しているつもりでも、それで意見がまとまらない方が嫌だという感情があります。」

kawasima：佐伯は多様性が分かっていないわけではないのですが、それを揺らされる方がストレスを強く感じるため、行動としてそうなりがちです。見られる傾向として、自分と似た考えを持つ人を気に入り、暗黙的にそうした人を優遇してしまうことがあります。早く決めてどんどん前に進むことを価値に感じるため、決めた内容の良し悪しは一旦置いておいても、進めてくれるリーダーを好む性質もあります。

佐伯「一律なルールを作ってそれに従わせたい欲求もあります。」

kawasima：ソフトウェア開発の現場で同じような状態になると、問題が起きたときに、断片的な挙動から全体像を早期に推測して、不確実性による心理的苦痛を避けるために結論に早く飛びつく傾向が強くなります。また、ツールがさまざまな指標や分析を出してくれると、それが唯一の解だと思い込み、それ以上考えずに盲信してしまう傾向もあります。

不適切な抽象化と技術的負債

kawasima：高NFCの傾向が進むと、不適切な抽象化も起こります。複雑なものは不確実性の源泉になるため、非常に嫌う傾向があります。複雑な仕様を無理に単純化し、一度出した結論は守り抜きたいという心理が働きます。

複雑さには2種類あり、1つのデータの塊の中に含まれる複雑さと、それを分解したときに現れる要素の数があります。データの分解には時間と労力がかかるので、高NFCの欲求が働くと、複雑さを分析して構造化するよりも、「ひとまず1つのデータ構造にまとめる」方向へ判断が傾くことがよくあります。

佐伯：「技術的負債についての態度の違いも認知的閉鎖欲求の高低が関係しています。」

kawasima：今回のシナリオでは、納期のプレッシャーが非常に高いので、早く答えにたどり着きたい状態でした。そのため、必要以上に負債を抱える設計になってしまいました。決めたことは後で直せばいいと言いながら、実際には永続性が働いて守り抜こうとしてしまいます。偽りの安定性を維持しようとすると問題が起きます。

どうすればいいか――意思決定を仕組みで補正する

シナリオの問題点を整理したうえで、村上が次の論点を提示する。NFCの高低は個人の特性であり、それ自体を変えることはできない。そこで議論は、意思決定のプロセスをどう仕組みで補正するかへと進みました。

ADRと代替案、プレモーテム

村上「最終決定などというものは存在しない。この認識を仕組み化するのが大事です。」

kawasima：これも辛い話でしたが、では、どうすれば良いかを整理していきます。NFCは個人の避けられない心理的特性なので、そこを否定しても何も始まりません。そちら側に偏りすぎない仕組みを作ることが重要です。

重要な意思決定でADR（Architecture Decision Record）がよく使われます。ADRを使うときには必ず代替案を複数検討するようにしましょう。

また、プレモーテムも有効です。複数の代替案の良し悪しを評価するときに、もし認識が間違っていて、選んだ解によって良からぬことが起こるかもしれないと想定し、そのときどういうインパクトがあるかを話し合っておきます。ADRには選んだ案の影響を書くスペースがあるので、そこにプレモーテムの結果を書いておくことが1つの対策になります。

決定の固定化を防ぐ仕組み

村上「ADRは意思決定の背景を記録しますが、決めなかったことも記録すると良いです。」

kawasima：ADRは意思決定の記録と言われ、代替案を並べてどれを選んだかなどを書きます。しかし、これがもう決めたものだから動かさない、となりがちです。イミュータブルなドキュメントで、1回書いたら更新せず別の決定があれば新しいものを書けばいい、とも言われますが、だからといってそれをずっと守り切らなければいけないというものでは当然ありません。

決定が固定化するのを防ぐために、これも仕組みで補正します。決定にあまり自信がないときは、少し日付を置いてもう1回見直しましょう、と次回レビュー日を決めるのも1つの方法です。また、意思決定の時点にはコンテキストがあり、時間とともにその良し悪しは変わってきます。コンテキストがある程度変わったタイミングで、その決定の有効期限が切れていることもあり得るため、有効期限を決めておくことが有効です。期限が来たら見直しのタイミングとして再考します。

今回のシナリオで一番有効なのは、見直しのトリガーです。どんなことが起きたら一度決めたことを見直すか、という条件を並べて書いておきます。1回決めはするけれど、それは最終決定ではなく、見直すタイミングやポイントを決めておく、ということです。

チームの多様性とAIによる補正

村上「認知的閉鎖欲求の高低の多様性をチームに持たせるのも1つの方法です。欲求が高い人は決定を引き寄せてくれるし、低い人は選択肢を広げてくれます。」

kawasima：欲求が高い人があたかも悪であるかのようにシナリオを作ってきましたが、仕事上必ずしもそうとは言えない場面もあります。決定をどんどんしてくれる人がいないと仕事が前に進みません。欲求が低い人だけで構成されていると、いつまでも検討を重ねることになってしまいます。チームとしてバランスを取ることが大事です。

仕組みとして実践するなら、タスク完了後に批判的に振り返る時間を設けるのも1つの方法です。欲求が低い人がいない場合は、あえてかき乱す反対担当役を決めて話し合うのもよいでしょう。チームの中でどちらかに偏ると良くない状況になるので、NFCがバランスを取れた状態を保つようにチーム編成しましょう。

そうした人材をチームに確保できない場合は、生成AIにその役割をカバーさせるという選択肢も、今後あると考えています。こちらについてはまた別の機会で詳細を話せればと思います。

IFストーリー：もし「決めない技術選定」を実践していたら

セッションの後半は、IFストーリーへと移る。もし佐伯が認知的閉鎖欲求の知識を持っていたら、最初と同じ要求に対してどう応じていたか――というシナリオが、ゲーム内で続けて提示されました。設計の参照軸となっているのは、認知的閉鎖欲求の論文と、ADRの書き方に関する書籍です。「最終決定なんてものはない」という『達人プログラマー』の一節を起点に、kawasimaさんの解説とセリフを交えてストーリーが進行します。

kawasima：ここからはIFストーリーです。今回の話のネタになっているのは、認知的閉鎖欲求の論文とADRの書き方に関する書籍です。「最終決定なんてものはない」という名言が『達人プログラマー』に載っていて、私はその一節が好きです。

一言で言えば、“There are no final decisions”をチームのマントラにする、ということです。そうした世界です。

今決めないと困ることだけ決める

佐伯「最終決定なんてものは存在しない。急いで全部決めたつもりで後から全部作り直しになったら、来月の施策も止まる。だからどうせ変わるものは最初から変えられる形にしておく。決めないんじゃなくて、決めなくていいことを決めないんだ。」

kawasima：ここがIFストーリーの起点です。納期は変えない、ただし今決めなくていいことは決めない、というスタンスをチームで共有します。

良い仕様の制限性と一般性

佐伯「良い仕様には2つの性質がある。1つは制限性。まずい実装を全部排除できるくらい十分に絞り込まれていること。もう1つは一般性。望ましい実装まで排除しないこと。」

kawasima：これは「リスコフの置換原則」を提唱している方の本に載っている話で、良い仕様の書き方として、制限性と一般性を同時に満たすのがいい仕様だとされています。制限性とは、関数やメソッドが受け入れられない実装をきちんと受け取らないようにすることです。型で守るのがより良い設計だと考えています。

インターフェースが決まったうえで、許容可能な入力と出力が決まっている状態で、許容可能な実装が排除されない。つまり、実装の選択肢を狭めるような仕様を書いてはいけない、ということです。制限と一般性の両方を満たす設計を目指します。

シナリオに当てはめると、プランと権限を混ぜないという境界は制限的に決める、しかしプランの数を3つと決め打つのは過剰指定で一般性を殺している、という整理になります。

機能のYAGNIと決定のYAGNI

石田：「それってYAGNI^[1]じゃないのでは。今必要じゃないものを作るなって話と矛盾してませんか。」

kawasima：先読みした設計に見えるので、それと矛盾するのではないか、というよくある反応です。

佐伯「いい質問だ。YAGNIは『今必要じゃないものを作るな』だろう。俺が言ってるのは『今必要じゃない決定をするな』だ。」

kawasima：機能に対してはもちろんそうですが、決定に関しても同じで、今必要じゃない決定はしてはいけない、ということです。

村上「じゃあ何を決めて何を決めないか、そこから整理しませんか。」

佐伯「プランは売るためのラベルだからマーケティングの都合で頻繁に変わる。権限は何ができるかで仕組みとして安定させたい。だからプランを見て分岐はしないようにしよう。」

kawasima：プランは売るためのラベルなので変わる前提、権限は何ができるかという仕組みとして安定させたい。だからプランを見て分岐はしない設計にする、というのが結論です。この形にしておけば、キャンペーンで一部のユーザーにだけゴールドの機能を解放したいとなったときも、プランを増やさずに権限を一時的につけ、期限が来たら外すだけで済みます。

決めないと曖昧にするは違う

村上「1つだけ。決めないのと曖昧にするのは違います。」

kawasima：ここは非常に重要な話で、決めないと曖昧にすることの違いをチームで認識しなければいけない、ということです。

村上「プランの種類は決めない。これだけだとテストする時困りますよね。3つなのか5つなのか分からない。何をもってテストしたかが分からなくなったら、結局決めてないのと同じになります。だから決めないことを明示する。ADRに何を決めたかと何を決めていないかの両方を書きましょう。」

kawasima：決めていないことまできちんと書けると、曖昧なものと決めていないことの違いがはっきりします。

村上「曖昧と柔軟さの違いはここがはっきりしてるかどうかです。」

kawasima：こちらも非常に重要なところで、「柔軟な設計にしましょう」という話と、「結果として曖昧な設計になっている」のは大きな違いです。柔軟というのはサポートする仕様の範囲が明確な状態を指します。

一方で、何でも入る、テーブルにデータを突っ込めば画面の処理がさまざまに切り替わる、何をサポートしているか分からない、というのは曖昧な仕様です。ここで曖昧さと柔軟さを区別します。NFCが高い人にこの違いを共通認識として持ってもらえると、設計が進めやすくなります。

ADRに見直しのトリガーを入れる

佐伯「もう1つ、ADRに見直しのトリガーを入れよう。最終決定は存在しないから、どの決定も覆る条件を持つ。」

kawasima：ADRに見直しのトリガー、つまり、どんなことが起きたら決定を見直すかという条件を書いておく、という話です。これを決めておけば、お試しのような追加要求が来たときに、一度立ち止まるきっかけになります。

佐伯「ここまで書いておけば俺が当時は最適だったと言って変更を止めることができなくなる。最終決定などというものは存在しない。なら最初からそのつもりで決める。」

kawasima：自分で決定の固定化を防ぐ仕組みを作る、ということです。最終決定などというものは存在しない、なら最初からそのつもりで決める。これが今日の一番伝えたいことです。

まとめ

kawasima：今日の話を一言でまとめると、“There are no final decisions”ということになります。

今回の登壇資料はゲームとして公開しています。皆さんの現場で、特に認知的閉鎖欲求が強い方がいたら、ぜひプレイしていただけると良いと考えています。

アーカイブ動画

イベント本編は、アーカイブ動画を公開しています。あわせてご覧ください。

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