エンドツーエンドのデリバリーとは何か
顧客が、きれいに整理されたTaskを渡してくれることはほとんどない。
「Leadの質と商談から成約までのProcessを分析し、成約率が低い原因を突き止め、改善策を提案してください」とは言わない。
もっとありそうなのは、こんな一言だ。
「最近、見込み客は多いのに、なかなか売れない。」
この言葉には、明確なInputも受け入れ基準もない。そもそも本当の問題を指しているとは限らない。
原因はLeadの質かもしれないし、対応の遅さ、価格の提示方法、Productの位置づけ、あるいは営業Teamが決められたProcessを実行していないことかもしれない。
この言葉をそのままAIに渡し、分析Reportを作らせ、顧客に転送する人もいる。Processは完了したように見える。しかし問題は、曖昧な不満から体裁の整った文書へ移されただけだ。
エンドツーエンドのデリバリーは、定義済みのTaskから始まるとは限らない。多くの場合、まだ言葉にできていない不満から始まる。その終点も、ReportやPrototype、Codeを渡すことではない。顧客が確認できる現実の変化である。
曖昧な問題から受け入れ可能な結果に至るまで、誰かが一貫してその問題を引き受ける。
それがエンドツーエンドである。
責任はどこまで及ぶのか
これまで「エンドツーエンド」は、一人ですべてのSkillを持つことだと考えられがちだった。要件整理、Design、Coding、Deploy、運用に加え、できれば営業まで自分でこなす。
もちろん、そんな人は優秀だ。しかしエンドツーエンドが示すのは、Skillの幅ではない。責任がどこまで及ぶかである。
建築の元請けが、床張りも配管も木工も自分で行う必要はない。
価値は、施主が本当にどんな家で暮らしたいのかを理解し、その希望を予算、図面、工期に落とし込み、適切な職人を集め、工事中の衝突を解決し、引き渡し前に重要な工程をすべて確認することにある。
自分では煉瓦を一つも積まなくてもよい。しかし家で水漏れが起きたとき、施主にこう言うことはできない。
「それは配管業者の問題です。」
工程は外注できても、引き渡しの責任は外注できない。
実行能力は必要なときに呼び出せる
AIが変えるのは、結果に責任を持つ人と、実行能力との関係である。
これまで一人で結果全体を引き受けられなかったのは、多くの場合、実行能力が足りなかったからだ。Codeを書けない、Designができない、Dataを分析できない、そしてTeamもいない。
今では、多くの能力を必要なときに呼び出せる。一人でもAIを使って調査し、Programを書き、Prototypeを作れる。Riskの高い工程には専門家を招くこともできる。
実行能力の供給は、次第に安くなっている。
しかし、それらの能力が自動的に、正しく、信頼でき、受け入れ可能な結果へまとまるわけではない。
だから本当に希少なものは、「自分に何ができるか」から、別の問いへ移り始める。
何をすべきか判断できるか。
誰に任せるべきか。
どの水準まで到達すれば、本当に完了したと言えるか。
責任の空白を埋める
これは、いわゆる中間層の意味も変える。
従来の仲介者は情報格差に依存していた。顧客が知らない情報を知り、顧客が知らない人とつながり、その仲介から手数料を得る。Internetはすでにこの価値を弱めており、AIはさらに弱めていく。
新しい中間層が埋めるのは情報格差ではなく、責任の空白である。
顧客はModelもSoftwareも専門家も見つけられる。顧客が本当に引き受けたくないのは、自分で問題を分解し、選択肢を比べ、衝突を調整し、品質を判断し、失敗のたびに資源を組み直すことだ。
顧客と複雑な供給側の間に立ち、言葉になっていない不満を解く価値のある問題として定義し、分散した人と機械を組織し、最終結果に責任を持つ。これができる人は、新しい中間価値を生み出す。
これは仲介ではない。元請けである。
エンドツーエンドの責任者は、少なくとも四つのことを続けて行わなければならない。
問題を定義する。約束の範囲を決める。実行を組織する。受け入れを完了する。
定義がなければ、間違った問題を真剣に解くことになりかねない。
境界がなければ、約束は成立しない。
組織化がなければ、デリバリーは異なるToolの出力をつなぎ合わせるだけになる。
受け入れがなければ、「完了」は一方的な自己申告にすぎない。
境界があってこそ責任を持てる
エンドツーエンドと最も誤解されやすいのは、「何でも引き受ける」ことだ。
顧客が成長を求めれば成長Planを生成し、Appを求めればAIにAppを書かせる。一見、守備範囲は広い。しかし問題の定義が正しいかを判断できず、最終的な成果物が信頼できるかもわからない。
これは元請けではない。人間の外見をまとったAPIにすぎない。
信頼できるエンドツーエンドの責任者は、むしろ頻繁に「引き受けられない」と言う。
どの判断が自分の能力範囲にあり、どの工程で専門家を入れるべきか、どのRiskをModelの推測に委ねてはいけないかを知っている。
境界は能力不足の証明ではない。責任を負うための前提である。
自分がどこで判断を誤る可能性があるかを知っている人だけが、顧客に代わってこう判断できる。
「これは成功した。」
この関係は、一人で営む会社だけに当てはまるものではない。
企業のFDE、Product Manager、Project責任者、そして成熟したEngineerも、このような元請けの役割を担える。
すべての工程を自分で行わなくても、顧客の言葉をSystemの変化へ翻訳し、重要な品質を守り、結果がずれたときに資源を再配置できる。
役職は違っても、仕事の中心は同じだ。
割り当てられた工程を終えるだけでなく、一つの結果に責任を持ち続ける。
AIがさらに強くなっても、実行はなくならず、専門性の深さも価値を失わない。
しかし一つの工程を実行するだけでは、安定した交渉力の土台になりにくくなる。顧客が継続して対価を払うのは、多くの場合、Codeや一枚の図、一つのPromptそのものではない。それらが生み出す現実の変化である。
だから顧客が「最近、見込み客は多いのに、なかなか売れない」と言ったとき、本当のデリバリーとは、体裁の整ったReportを渡すことではない。最終的に、次の三つの問いに答えられることだ。
問題はどこにあるのか。
何を変えると約束したのか。
実際に変わったのか。
途中の調査、Design、Coding、実装は、多くの人や機械に任せられる。
ただし最後の「この仕事は完了した」という言葉だけは、転送できない。
最初から問題を引き受けた本人が、自分で答えなければならない。