各フェーズで誰が何を決めるか

開発が予定より遅れているとき、原因を技術に求めたくなります。しかし実際に手を止めている要因を遡ると、「誰がそれを決めるのかが決まっていなかった」という一点に行き着くことが少なくありません。仕様の質問に回答が返ってこない、二人の言うことが食い違う、一度決まったことが後から覆る。いずれも技術の問題ではなく、決裁構造の問題です。

本記事では、フェーズごとに誰が何を決めるべきかを整理します。体制そのものの作り方は少人数開発チームの体制設計に、契約との関係はアジャイル開発と契約にまとめています。

決めるべき四つの種類

まず、開発で発生する決定を種類ごとに分けておきます。混ざったまま議論すると、誰が決めるかの話も混ざります。

このうち、外部の開発パートナーに委ねてよいのは基本的に四つ目だけです。上の三つを外部に委ねると、事業の意図と成果物がずれます。逆に、四つ目まで発注側が細かく指定すると、依頼した意味が薄れ、責任の所在も曖昧になります。

プレシード・シード — 創業者が決め、決めた記録を残す

初期は、創業者が四つすべてを実質的に決めている状態が普通です。人数が少なく、事業の仮説が頭の中にあるのは創業者だけなので、この形が最も速く動きます。

この段階で気をつけたいのは二つです。

一つは、決めた内容が記録されていないことです。口頭で決まり、実装され、数週間後に「そういう意図ではなかった」となる。人数が少ないうちは記憶で回りますが、外部パートナーが入ると、この方式は破綻します。チャットでも構わないので、決定を文字にして残す習慣を早めに作ってください。

もう一つは、決めない項目が積み上がることです。「後で考える」と保留した項目が増えると、開発側はその部分を仮置きで進めます。仮置きが積み重なった状態で本来の意図が示されると、広い範囲の作り直しになります。保留した項目には、いつ決めるかを添えてください。

シード後期 — 代理を決める

顧客が増え、外部パートナーが入り、創業者が営業や採用に時間を取られるようになると、最初の詰まりが起きます。創業者の確認待ちが開発を止める状態です。

ここで必要なのは、決める人を増やすことではなく、代理を決めることです。創業者が不在のとき、誰がその場で判断してよいのかを決めておきます。

現実的な形は次のようなものです。

• 決定の影響範囲で線を引く：画面の言葉遣いや細部の挙動は開発側の判断で進めてよい。料金、顧客との約束に関わることは創業者が決める。
• 時間で線を引く：質問から一定時間返答がなければ、開発側が妥当と考える形で進め、後から報告する。
• 金額で線を引く：一定額以下の追加費用を伴う判断は、その場で進めてよい。

三つ目は外部パートナーとの間でも有効です。細かい追加作業のたびに承認を求めると、双方の時間が削られます。

想定例：ある会社が、外部パートナーと月ごとの稼働で開発を進めていました。創業者が資金調達活動に入った時期から、仕様の質問への回答が数日単位で遅れ、開発側の稼働に空白ができます。この会社の対応は、質問を「その場で進めてよいもの」「創業者の回答が要るもの」に分け、前者は開発側の判断で進めて週次で報告する形に変えることでした。決める人を増やしたのではなく、決めなくてよい範囲を明示したという整理です。

シリーズA — 優先順位の決定を切り出す

社内のチームが大きくなると、決定の種類ごとに人が分かれ始めます。特に切り出されるのが、優先順位の決定です。

この役割を担う人（プロダクト責任者）がいないと、開発の順番が「声の大きい要望」で決まります。営業が持ち帰った個別の要望、既存顧客の追加依頼、社内からの改善要望が、優先順位の議論を経ずに並びます。結果として、事業の仮説に効かない作業で稼働が埋まります。

この段階で明確にしておきたいのは、次の点です。

• 優先順位の最終決定者は一人であること。合議で決めると、誰も責任を負わなくなります。
• 決定者が「やらない」と言える権限を持っていること。追加だけできて削れない役割は、機能しません。
• 覆す権限を持つ人と条件が決まっていること。経営者が覆すのは自然ですが、頻繁に覆ると決定者の役割が形骸化します。

技術側にも同様の変化が起きます。実現方法の決定を担う技術責任者を社内に置く時期です。外部パートナーが技術判断を担い続けると、フェーズが進んだときに社内で判断ができなくなります。

シリーズB以降 — 決裁の重複を減らす

組織が大きくなると、今度は逆の問題が出ます。決める人が増えすぎて、一つの判断に複数の承認が必要になる状態です。

この段階で見直すべきは、次のような点です。

• 同じ内容を複数の場で説明していないか
• 承認が形式的になっていて、実質的な判断が行われていない承認がないか
• 決定の記録が分散していて、過去の判断理由を辿れなくなっていないか

決裁を増やすのは容易ですが、減らすのは難しい作業です。増やすときに「この承認は何のリスクを防ぐためか」を書いておくと、後から見直せます。リスクが書けない承認は、最初から要らない可能性があります。

AIに関わる決定は誰が持つか

AI機能を扱う場合、決裁の空白が生まれやすい領域があります。技術の話に見えて、実は事業判断を含んでいるためです。

発注側が持つべき決定は、顧客のデータを外部のAI APIに送ってよいか（契約と信頼の判断です）、出力の間違いをどこまで許容するか、人の確認をどこに挟むか、利用量に比例する費用の上限をいくらにするか、の四点です。開発側に委ねてよいのは、どの提供事業者のAPIを使うか、応答の速度や再試行の設計、記録や監視の実装方法といった領域です。

境界を曖昧にしたまま進めると、「そんなデータを送っているとは思わなかった」という事態が起こります。開発工程での生成AI利用についても、社内ルールを誰が決めるかを明示しておいてください。考え方は生成AIを開発工程に組み込むに整理しています。

決めない判断も、明示的に決める

最後に強調したいのは、「決めない」ことを決めるのも決裁だということです。

情報が足りず、今は判断できない項目はあります。問題は、それが「保留」として明示されているか、単に放置されているかです。明示されていれば、開発側は仮置きの範囲を小さくし、後で変えやすい形で進められます。放置されていると、開発側は勝手に前提を置き、その前提が食い違ったときに手戻りになります。

保留する項目には、いつ、何が分かれば決められるのかを添えてください。それだけで、決められない状態が惰性で続くことを防げます。

決裁の構造は、技術ではないために後回しにされがちですが、開発の速度に対する影響は技術選定より大きいことがあります。フェーズが変わるタイミングで、誰が何を決めるかを一度書き出してみることをおすすめします。

体制と決裁の整理を外部の目で確かめたい場合は、開発チーム構築支援やWebシステム開発の観点から状況を伺います。お問い合わせからご相談ください。オンラインで全国対応しており、ご相談・お見積りは無料です。