意思決定のトレーサビリティ・因果関係の連続性が今後ますます大事という話。
システム開発の現場は、乱暴に言えば2種類に分けられます。
A. 仕様を決めるのはクライアントである
B. 仕様を形作るのは市場であり、会社やチームが仕様を決める
Bは要は自社開発。受託開発はAであることが多いです。例外もありますが。
今のシステム開発の文脈は非常にAの前提で語られていますが、今回はBの話です。
多くの現場では当てはまらないと思うので注意してください。
「仕様を形作るのは市場であり、会社やチームが仕様を決める」の基本
これはリーン開発、アジャイル、スクラム開発が基本になります。
説明は割愛（暇があれば書く）
「会社やチームが仕様を決める」現場
自社サービスというのは非常に特殊な存在です。
一見すると創作物みたいなもので、変更容易性があり、無料の部分と有料の部分があります（最近のクリエイティブ界隈も似た様相を呈してきましたが）
この特徴があるので、我々は「試行錯誤」ができ、これが現代のソフトウェアサービスの発展に大きく貢献しています。
ただ、試行錯誤をチームでやるというのは結構ハードです。なのでシンプル化するために色んな工夫があるわけですが。例えば簡単に言ってしまえば以下のように話は進みます。
目的 → 課題 → 仮説 → 企画 → 要件定義・仕様 → 実装 → テスト
多くのシステム開発をしている人にとって、スタートは「要件定義」ですよね。そこからのシステム開発でさえ大変なことを知ってるはずです。それで手一杯なはずなのに、更に上流（コンサル領域）までとなると、その大変さがわかると思います。
我々エンジニアはたいてい上流を見て見ぬふりをします、眼の前で手一杯なので。それはデザイナーやQAもそうだと思います。
「誰かが決めてください」「誰が決めるんですか？」これはAパターンの振る舞いです。
しかしそれができない現場もあります（私はむしろそっちの方が慣れてるんですが）
仕様漏れが起きた時に起こること
例えばQA工程で、仕様漏れが発覚したとき。詳しく書けば以下のようなフローをたどるかもしれません。
-
【起点】QA工程にて「仕様漏れ」が発覚
-
挙動の不整合、または考慮不足の発見
-
-
【確認】仕様書の再検証
-
記述の有無を確認
-
→ 記載なし：正式に「仕様決定フェーズ」へ移行
-
-
【立案】整合性を考慮した解決案の策定
-
既存の他機能との整合
-
上流（目的・課題・仮説・企画）との一貫性確認
-
-
【調査】多角的影響範囲の評価（フィジビリティスタディ）
-
実装・デザインの実現可否など
-
マーケティング・法務・ビジネス上のリスク確認
-
-
【判断】意思決定または前提の再定義
-
案がある場合： 複数案から最適解を選択（評価と決定）
-
解決困難な場合： 目的の再考、前提条件の変更、妥協、またはリリース延期の判断
-
-
【着地】仕様確定・通常開発フローへ合流
-
仕様書更新 → 実装 → 再テスト
-
実際はもっと複雑です。問えばシステム開発における評価軸だけで沢山あります。
例
-
Usability（ユーザビリティ）：使いやすさ
-
Reliability（信頼性）：壊れず正しく動き続ける
-
Availability（可用性）：サービスが止まらない
-
Performance（性能）：応答速度・処理能力
-
Scalability（拡張性）：負荷増加への耐性
-
Maintainability（保守性）：修正・改善のしやすさ
-
Testability（テスト容易性）：品質保証のしやすさ
-
Security（セキュリティ）：不正アクセス等への耐性
パット見で分かるように、それぞれのプロがたくさん会議をしたうえで多角的に判断して仕様が決まることがわかります。つまり意思決定を沢山しているわけですが。
この意思決定が難しくて、専門分野が違う同士のプロが一つの答えを出すには評価軸が共有化されていないという観点で大変で、高コストです。最後はエイヤで決めてしまうことも多いでしょう。（そしてあとから違った〜となる）
意思決定フローが複雑なのはしょうがない、でも二度手間は避けたい
上記のフローを一回やるのはしょうがないんですが、何となくで会議していると、あとあと似たような問題（仕様漏れなど）が上がってきた時に、「あれ〜前にも同じようなこと話したなあ」「これってどう意思決定したんだっけ？」となり、二度手間になります。これが非常に高コストで、上流に行くほど致命的です（例えば、仮説への誤解があったとか、仮説はあってたが企画への誤解があるとか。数カ月のロスになる）
これが、「意思決定のトレーサビリティ・因果関係の連続性が大事」という理由です。
意思決定のトレーサビリティをどう実現するか？
ごめんなさい、このHowの部分は私もまだ作りきれていません。非常に難しいです。
アイディアとしてあるのは、次の結論が「自動的に決まること」と「意思決定すること」があると思っていて、意思決定することはすなわち、「よってたかって案を出して評価する行為」だと思っていて、この「案」「評価」「評価の理由」が会議であり、その記録が迷子になる（あるいは読み解けない）と、二度手間になるというあたりまでは考えています。
最強の解決策：天才プロダクトオーナー
そのプロダクトに心血を捧げ、すべての評価軸を把握し、すべての経緯を把握し、すべての仕様を理解して、一瞬で仕様漏れに回答を出す。
そういう人間が１人いれば、割と解決してしまします。
スタートアップ企業において、大抵これはCEOです。あるいは最近はPO,PdMという役割も登場しました。
現実：天才プロダクトオーナーはいない
要は、天才漫画原作者がいないけど、オリジナルアニメを作らなきゃいけないような状況です。
これはちなみに天才プロダクトオーナーが「立ち上げ期にはいた」場合でも、グロースフェーズでその神通力が使えなくなるみたいなケースもありますし、離脱するみたいなケースもあります。プロダクトライフサイクル の全てにおいて天才POでいられる人は稀です。
AIを天才POに育てる
今後のチームが目指すべきはここになると思っています。
むしろこれ以外許されなくなる。
現状、もう要件定義から先の実装工程はAIのおかげでだいぶ早くなってきました。相対的に、意思決定部分が非常に高コストのまま残っている。となると、ここを圧縮したチームがイテレーションを素早く回せるので有利になります。
そのためには意思決定のトレーサビリティを実現する必要があり、そのための交通整理が今後1〜5年の課題になってくると考えています。
その結果AIに全部奪われるのでは！？という心配もありそうですが、まあ当分無いので大丈夫です。
＿＿＿＿
メモ：もう一個の解決策として、仕様を簡単にする（すぐ意思決定ができるようにする）があります。それは逆も然りで、AIに適当に頼むと仕様が複雑化していくので、AI導入でコントロールできず暴走するチームも出始めるんじゃないかと予想しています（コーディイングが早い→調子に乗って仕様を複雑化する→死ぬ）
