技術判断が記録されないまま外注が進む。その構造が新規事業の再設計コストを生んでいる

技術判断が口頭で決まり、Slackのどこかに流れ、議事録に残らないまま外注が進む。この構造は特殊なケースではなく、技術リードがいない新規事業開発の現場では日常的に起きている。問題は開発スピードでもアイデアの質でもない。本当の詰まりは、判断が記録されないまま外注費が積み上がり、仕様変更のたびに追加請求が発生する構造にある。

「なぜこの技術スタックにしたのか説明できない」「前の担当者がいないので引き継ぎが分からない」という状況は、担当者の能力不足ではなく、判断を記録する仕組みが最初から設計されていないことが原因だ。この記事では、FDE（Forward Deployed Engineer）という役割を軸に、技術判断の空白がどこでコストになるかを分解し、AIをどの工程に入れると現場で使われる形になるかを整理する。ツールを選ぶ前に決めるべきことがある、という視点で読んでほしい。

1.技術判断の「誰かが決める」が、新規事業の再設計コストを静かに積んでいく

新規事業において、最初に壊れるのはアイデアではなく判断の記録だ。どのAPIを使うか、外注先に何を任せるか、どの機能を優先するか。これらの判断が口頭とSlackの非公式チャンネルで決まり、誰も記録しないまま実装が走る。半年後に仕様の齟齬が判明したとき、戻れる地点はゼロに近い。外注先からの追加見積もりと、内部での再設計工数が同時に発生する。

この構造で失われる損失は三つある。まず仕様変更コスト。認識の齟齬が後工程で発覚するほど修正範囲が広がり、外注費が膨らむ。次に手戻り工数。社内側で「そういう要件だったのか」という確認が繰り返され、事業担当者の時間が確認調整に消える。そして担当者交代時の引き継ぎ断絶。技術判断の根拠が誰の頭にも残っていない状態で担当者が変わると、新しい担当者は同じ確認を最初からやり直すことになる。

これらの損失は、発生した後に気づくため、予防コストより回収コストが数倍になりやすい。「今は問題なく進んでいる」と感じている段階が、実は最も損失が見えにくいフェーズだ。新規事業の開発が進んでいるように見えても、判断記録がない状態では、どこかのタイミングで誰かが同じ確認をゼロから始めることになる。

誰にしわ寄せが行くのか

この構造で最初にしわ寄せが行くのは、事業担当者だ。外注先への説明を毎回一から組み立て直し、Slackで過去のスレッドを遡って文脈を掘り起こす。次に外注先。要件が曖昧なまま着手し、後から方向修正を求められるたびに工数が膨らむ。最後に経営者。追加費用の理由を外注先に聞いても「要件変更によるものです」と返ってくるが、その変更がなぜ起きたのかを遡る記録がない。

FDEとは、Forward Deployed Engineerの略で、顧客や現場の業務フローの中に入り込み、技術と業務課題を双方向に翻訳しながら実装まで伴走するエンジニアの役割を指す。単なる開発担当ではなく、「何を解くべきか」の問い自体を現場で言語化し、それを技術的に実現可能な形に落とし込む人間だ、という点が核心にある。この役割が機能しない組織では、技術判断の空白が放置されたまま外注が進む。

2.最初にAIを入れるなら「要件整理」と「判断記録」の2工程だけに絞る

新規事業支援の現場でAIを有効活用できる工程は、大きく二つに絞られる。一つは要件整理の下書き生成、もう一つは判断・進捗の記録補助だ。この二つから始める理由は、どちらも「担当者が変わったときに業務が止まる」という属人化の根本問題に直結しているからだ。

要件整理では、経営者や事業担当者が口頭で話した内容をAIに整理させ、機能一覧・優先順位・判断理由のドラフトを作らせる。これは外注先への説明材料として使えるだけでなく、社内の認識齟齬を事前につぶす素材になる。ただし、AIが生成したドラフトをそのまま外注先に渡してはいけない。ドラフトの確認責任を担当者が持ち、渡す前に必ず一人レビューを挟む運用にしなければ、AIが整理した内容の誤りや抜けを誰も拾えないまま進む。

判断記録の補助では、会議の議事録生成、Slackの意思決定スレッドの要約、週次の進捗サマリーの下書きにAIを活用する。ここで重要なのは入力情報の品質だ。発言が録音・テキスト化されていなければAIは何も整理できない。打ち合わせがすべて口頭と非公式チャットで進む組織では、AIを入れた後も「前のやり方の方が速い」という感覚が残り、使われなくなる。ツールを入れることより先に、Notionや議事録テンプレートで発言を残すルールを整えることが先決だ。

AIに任せてよい範囲と、人間が責任を持つ範囲

AIに任せてよいのは、補助作業に限定される。要件のドラフト生成、類似事例のリストアップ、競合サービスの比較整理、会議の要約、初期コードのスケルトン生成がこれに当たる。これらは入力情報さえあれば品質が安定し、確認コストを抑えながら整理の速度を上げられる。

一方、人間が責任を持つべき範囲は明確だ。最終的な技術選定の決定、外注先との契約判断、ユーザーへの機能説明、仕様変更の承認、事業方針の転換。これらはすべて説明責任が伴う判断であり、AIの出力を根拠にすることはできない。AIが提案したアーキテクチャが標準的に優れていたとしても、自社の事業フェーズ・チームスキル・予算・拡張性の優先順位を総合した判断は、文脈を持つ人間にしかできない。

やめた方がいいAI活用：技術選定をAIだけに委ねること

新規事業の文脈でやめた方がいいAI活用の筆頭は、技術スタックや外注先の選定判断をAIの出力だけで決めることだ。AIは汎用的な情報を整理する能力に長けているが、自社の制約条件に合った「この構成が最適」という判断を出力する文脈を持っていない。AIが提案するアーキテクチャは一般的な回答であり、数カ月後に「この構成では次のフェーズに対応できない」という再設計コストが発生する。判断の根拠を誰も説明できないまま技術負債が積まれる、というのが典型的な失敗パターンだ。技術選定でAIを使うなら、比較材料の作成と選択肢の列挙までに限定し、最終判断は必ず技術的な文脈を持つ人間が行う。

3.放置コストは外注費の明細ではなく、再設計と確認調整の工数として現れる

技術判断が記録されないまま新規事業を進めた場合のコストは、請求書に一行で出てこない。仕様変更の追加費用、認識齟齬の確認調整、担当者交代後の再ヒアリング。これらが複数の工程で同時に発生するため、何が原因かを特定しにくい。

仮定として計算すると、技術判断の確認や仕様の認識合わせに週3時間かかる事業担当者が、月20営業日稼働したとする。週3時間のうち調整が2時間、議事録や要件書の修正が1時間だとすると、月あたり12〜15時間が「既に決まったはずのことを再確認する作業」に充てられる。年間では150時間を超える。この時間が新機能の検証や事業仮説の確認に使えなかった機会損失として積み上がる。

失敗例：全工程を一気に変えようとして現場が止まる

新規事業でのAI導入で最も多い失敗は、要件定義・外注管理・進捗報告・競合調査・プロトタイプ生成を一度にAI化しようとするケースだ。各工程で「AIを使う」というルールを決めたものの、入力フォーマットが統一されていない、レビュー担当が決まっていない、AIの出力をどの精度で信用するかの基準がない、という状態で全体を動かし始めると、あらゆる工程で「確認が必要だが誰が確認するのか分からない」という状況が同時に発生する。外注先から届いた成果物の確認までAI任せにした結果、品質の問題を誰も検知しないまま次工程に進んでしまう。結果として「誰が確認したのか分からない」という状態が常態化し、最終的にAIを使うことをやめて元の手作業に戻るという逆走が起きる。広範囲を一気に変えるほど、摩擦が分散してどこで詰まっているかが見えなくなる。

効果が出る条件は単純だ。最初の2週間で1業務だけを選び、AIの出力を確認する担当者を1人決め、使われたかどうかを翌週に確認するサイクルを回す。このサイクルが1回完結した組織は次の工程に自然に広がるが、最初から全体最適を目指した組織は途中で止まる確率が高い。デジタル化・AI導入補助金などを活用する場合も、導入範囲を絞った方が審査上の説明と効果検証の両方がしやすい。

4.先送りするほど、次に選べる手が減る。最初の1工程を今週中に決める

新規事業のAI活用を先送りしたときのコストは、「導入しなかった損失」ではない。技術判断が記録されないまま外注が進み、担当者が変わるたびに同じ確認を繰り返し、仕様変更のたびに追加費用が発生するという循環が固定化されていくコストだ。1年後に「やっぱりAIを整備しよう」と決めた時点では、整理すべき判断記録がゼロの状態からスタートすることになる。先送りが長いほど、最初の整理コストが増える。

先送りして最初に失われるのは、事業初期の判断文脈だ。なぜこの機能を選んだか、なぜこの外注先にしたか、なぜこの技術スタックにしたか。この記録がない状態でスケールしようとすると、新しいメンバーや新しい外注先に説明するたびに担当者が口頭で再現するしかなくなる。これが属人化の正体であり、担当者退職時に事業が止まる直接の原因になる。

最初の2週間で着手すべき1業務

最初に手をつけるべきは、外注先への要件伝達プロセスの記録整備だ。現状どんな形で要件を伝えているか、どこで認識齟齬が起きているか、過去の差し戻し事例がどこにあるかを書き出す。その上で、次の発注で使う要件定義書のドラフトをAIに生成させ、担当者がレビューして渡す、という1サイクルだけを先に完結させる。この1サイクルが機能したなら、次の工程に広げる判断ができる。機能しなかったなら、入力データの問題か、レビュー体制の問題か、ツール設定の問題かが切り分けられる。どちらに転んでも、次の判断材料が生まれる。

弊社で新規事業・FDE支援の相談を受ける場合、最初に確認するのは「技術判断がどこに記録されているか」と「外注先とのやり取りがどのチャネルで完結しているか」の2点だ。この2点が整理されていない状態でAIツールを選定しても、現場で使われる形にはならない。業務フローの整理、AI活用箇所の選定、要件定義プロセスのプロトタイプ作成、運用ルールの設計まで、一気に全体を変えるのではなく1工程ずつ検証しながら進める伴走支援を提供している。まず今の業務の詰まりをどこから解くべきかを言語化するところから始める。次の外注発注の要件書を、今週中に1枚だけAIに下書きさせてみるところが最初の一手だ。