はじめに
先日、開発部の打ち合わせで部長が「設計」の話をしてくれた。
「設計って、不確実性を100から30まで落とす作業なんだ」
数字で言われた瞬間、腑に落ちた。
この記事は、私を含めた部長レイヤーが普段考えていることを、AI協働の実践者としてまとめたものです。テーマは「不確実性の減らし方」。
📌 3秒でわかるこの記事の要約
- 対象読者:
- 設計の「終わりどころ」や実装に入るタイミングに悩んでいるエンジニア
- AIをチームの開発プロセスにどう組み込むべきか模索しているリーダー・マネージャー
- この記事の結論:
- 設計とは不確実性を0にする作業ではなく、「致命傷にならない30」まで落とす作業である。
- 不確実性を効率よく下げる秘訣は、「毎朝生まれ変わる新人（AI）」のために前提をリポジトリに残し、未決事項を隠さず周囲を巻き込むこと。
100から30に落とすとは、どういうことか
新しい機能や仕組みを考え始めたとき、頭の中は霧に包まれている。
何が要件か、どこに落とし穴があるか、どの順で作るのが正解か。全部わからない。
この霧の量を「100」だとする。
設計とは、この霧を「30」まで晴らす作業である。
ゼロにする必要はない。ゼロにしようとすると永遠に作り始められない。
一方で「70」のままコードを書き始めると、途中で前提が崩れてやり直しになる。
だから30。実装に入っても致命傷にならない程度。
「わからないことは残っているが、進めながら埋められる」ラインが30、というイメージ。
ただし現実は、順風満帆に30まで下がるわけではない。
設計を進めると、それまで見えていなかった問題が浮き上がる。
100だと思っていた霧が、実は120あった。30まで下げたつもりが、50までしか下がらない。
これは失敗ではない。
むしろ未決事項として曝露できたこと自体が、全体の不確実性を下げている。
不確実性を可視化して下げている状態こそ、エンジニアリングできている証だと、私は理解している。
図: 上段は「100→30」の理想。下段は 予期せぬ発見で 総不確実性が 100→120 に拡大し、目標も 30→50 へ 一時的に増える現実。曝露できた分だけ 全体は 減っている。
私はこの数字を聞いて、過去ハマった失敗を思い出した。
ある経営会議向けの資料を、初稿で「提出できる」と信じ込んで出した。
実際は霧が「70」残っていた。ツッコミどころが多すぎて議論が発散し、決裁が1ヶ月遅れた。
最近は別のアプローチを試している。ある方針資料を、AIと壁打ちしながら8回書き直した。
1回目は60点、5回目で90点、8回目でようやく100点になった。
「何回まわせば通るか」が肌感覚でつかめると、途中で心が折れなくなる。
100点を目指すのではなく、「今日は霧を10下げられた」で満足する。それがループを回し続けるコツだった。
AIはチームメンバーだが、毎朝生まれ変わる
部長がもうひとつ強調していたのが、AIとの向き合い方だ。
「AIはただの検索エンジンじゃない。チームメンバーだ。
ただし、セッションが終わるたびに記憶を失う新人である」
これも数字で考えると理解が早い。
普通の新人が3ヶ月かけて覚える「うちのチームのやり方」を、AIはセッションが切れるたびに忘れる。
毎朝出社してくる、頭脳明晰で手の速い新人。ただし前日の会話はゼロ。
この前提を受け入れると、やることが変わる。
リポジトリに前提を置く。これに尽きる。
- チームのルールをドキュメントにする
- 過去の決定と、その理由を書き残す
- 「これは触るな」の禁止事項も明記する
Slackや口頭で伝えた話は、AIには届かない。会議室のホワイトボードもだ。
リポジトリの中にテキストで置いた瞬間、AIは翌朝からその前提で動いてくれる。
私は業務メモをドキュメントとして残している。
「あの人はこう言った」「先月こう決まった」を書き残しておくと、新しいセッションのAIも、私が覚えていない過去の議論を持ち出してくれる。
気づけば、自分の判断ミスが体感で半分になっていた。
「毎朝生まれ変わる新人」に説明できる形で残す、というのは、人間の後輩に対しても効いた副産物だった。
これはAI協働の話に見えて、実は「チームで働くことの基本」に戻る話でもある。
記録が残らないチームは、人が抜けた瞬間に崩壊する。AIも同じ。
DESIGN.mdは「未決を未決と書いて出す」場所
不確実性を減らすには、書き出す必要がある。
私たちの組織で推奨しているのが、実装前に「DESIGN.md」というドキュメントを書くことだ。
書き方のコツは3つある。
1. アクターを主語にする
「ユーザーが〜する」「管理者が〜する」で書く。
システム主語(「システムが判定する」)ばかりだと、何のための機能か見失う。
2. 具体例を混ぜる
「価格が変動する場合」ではなく「Aプランで月額500円が翌月から700円に上がる場合」。
抽象語だけの設計書は、読み手が全員違うものを想像する。
3. 未決事項を「未決」と明記して出す
ここが一番難しい、と正直に言いたい。
しかしここをしっかり洗い出して、未決を書いてレビューに出すと、レビュアーは「じゃあそこ、一緒に考えよう」と動いてくれる。
黙って持ち帰って一人で悩む時間より、圧倒的に早く霧が晴れる。
「未決を書く」を実践し始めてから、チームのDESIGN.mdは変わるのである。
例えば
修正前は「バッチ処理の起動タイミングは◯◯を採用します」と書いていた(実は迷っている)。
修正後は「起動タイミングは◯◯を第一案としますが、△△案の運用コスト比較が未決です。レビュー時に議論したいです」に変える。
出した瞬間、周りが動く。「△△案なら過去に検討した資料あるよ」「運用コストならこの数字が使える」。一人で抱えていた30分の悩みが、5分のやりとりで消える。
「わからない」を出す勇気は、チームの速度を上げる装備である。
レビュアーも確認ポイントを押さえられるのでとても助かる。
100から30に落とすまでの手順、まとめると
3つのステップに整理する。
- 数値で捉える。今、霧はどのくらい濃いか。100か、70か、30か。
- 前提をリポジトリに置く。毎朝生まれ変わるチームメンバーが読める場所に。
- 未決を未決と書いて出す。一人で30まで下げようとしない。人とAIを巻き込む。
この3つを回すだけで、設計フェーズの体感が変わる。
「いつ実装に入っていいかわからない」問題が、「霧が30切ったから入ろう」で決着する。
みなさんの現場では、設計フェーズの「霧」をどう数値化していますか。
コメントで教えてもらえたら嬉しいです。
Discussion