POがいないシステム受託開発で起きたことと乗り越え方【受託開発あるある】

「要件が曖昧なまま、いつまでも固まらず、開発が進まない」ーー受託開発に関わったことのある方なら、一度は経験があるのではないでしょうか。

なぜ、このような事態が起きてしまうのか？これには、プロジェクトの体制に原因があります。具体的に言えば、発注側に最終判断を下せるだけの権限を持ったプロダクトオーナー（PO）がいないという体制です。受託案件では実質的な決定権を持たない「名ばかりPO」では意味をなしません。プロダクトオーナーはプロダクトに関する意思決定のスピードと質を左右する存在です。

POとは、要望を受け取って開発チームに伝えるだけの人ではありません。課題を理解し、各ステークホルダーの優先順位を把握したうえで、プロダクトの方向性を決める権限を持つ人でなければなりません。この役割が曖昧だと、開発チームは大勢の「影響力はあるけれど最終判断はしない人たち」とのコミュニケーションに消耗することになります。

決める権限を持つ人がいないと、要件定義が終わらない

要件とは、システムが何をすべきかを定めたものです。ユーザーが何を達成したいのか、業務フローがどんなステップを踏むのか、どのデータを記録するのか、ロールごとに何が許可されるのか、例外ケースをどう扱うのかといったことです。

私は以前、学校法人向けの業務システムの開発に携わっていました。日本でいう幼稚園～高校までの一貫型インターナショナルスクールに加え、お子さんの習い事（課外活動）としてのスポーツスクール部門も手広く運営している学校法人です。プロジェクトの要件は入学手続き、学費の徴収、クラス編成、日々の生徒管理といった、企業の業務と直結しており、多岐にわたりました。

しかし、このプロジェクトでは、学校法人側と開発チームをつなぐ窓口が一本化されていませんでした。開発チームは要件を確認するたびに、学校法人側の複数のステークホルダーを回る必要があったのです。

システムの運用チームは日常的にシステムを使っており、実務を隅々まで理解していました。システム切り替えで起きるだろう混乱を最小限にするため、新システムでも慣れたフローを維持したいと考える傾向がありました。
一方、各学校の各部門責任者にはそれぞれの視点がありました。入学手続き、クラス編成、学費徴収、保護者との連絡など、拠点（校舎）ごとにやり方が違いました。教育プログラムや授業の質に責任を持つ教育顧問は、より長期的な視点から課題を捉え、戦略的な要件を挙げてきましたが、短期間で実装できるものばかりではありません。経理部門は支払い、消し込み、売掛金の管理を重視しており、その優先順位は運用側のニーズとは異なるロジックで動いていました。

誰も間違ってはいませんでした。それぞれが、自分の担当する業務の重要な部分を守ろうとしていたのです。

問題は、それらの視点を一つの明確なプロダクト判断にまとめる役割の人がいなかったことです。最終判断に責任を持つ人がいないため、レビューのたびに要件が行ったり来たりしました。開発チームは新しい意見を聞いて設計の一部を修正し、その後、その意見が別のグループですでに確定していた内容と矛盾していることに気づく――ということの繰り返しでした。

外から見れば、多くのステークホルダーが要件レビューに関わるのは良いことに見えます。業務ロジックが複雑に絡み合う学校向けシステムでは、実際にあらゆる立場の声を聞く必要があります。しかし、多くの立場から意見を聞くことと、全員に決定させることは同じではありません。多くの人が意見を言えるのに最終判断に責任を持つ人がいないと、プロダクトは「全員のもの」という名目だけの共同所有状態に陥りがちです。機能に問題が起きた途端、責任の所在がぼやけます。誰もが「自分は専門的な観点から意見を述べただけ。最終的に決めたのはみんなだ」と言えてしまうのです。

プロダクト開発において、「みんなで決めたけれど誰も責任を持たない」決定は、実質的には決めていないも同然です。

一度のレビューで振り出しに戻った機能

あるとき、開発チームは生徒向けの給食（ミールプラン）申し込み機能の開発を依頼されました。

運用チームがフローを確認済みだったため、私たちは設計に着手し、APIを書き、UIを作り始めました。その時点では、要件はかなりシンプルに見えていました。

ところが、現場担当者に向けてデモを行ったところで、フローが変わり始めました。「申し込みを確定する前に保護者の承認が必要」という新たな要件が加わったのです。続いて経理部門がレビューすると、支払いフローがまた変わりました。1年分をまとめて一括請求するのではなく、学期ごとに分割しなければならないというのです。

確定したはずのフローから、機能はほぼ振り出しに戻りました。各グループの意見がまとまるのを待つだけで、チームは3日近く足止めを食らいました。作った UIは合わなくなり、APIは再設計が必要になり、運用・教務・経理の間で食い違いが生じないよう、業務ロジックの一部も見直さなければなりませんでした。

ここでの最大のコストは、作り直した数枚の画面や数本の APIではありません。チーム全体の進捗がゼロという期間です。開発者は先に進めず、スプリント計画はずれ始め、最も重要な判断は、チームが作り始めた後になってようやく表に出てきました。

振り返ってみると、遅延の責任が誰にあったのかを特定するのは困難です。運用チームは運用の観点から確認し、教育顧問はカリキュラムの観点から要件を追加し、経理は支払いロジックに基づいて調整しました。誰もが自分の担当範囲の中では正当な理由を持っていました。

欠けていたのは、「結局のところ、プロダクトはどのフローに従うのか」を決められるだけの権限を持った一人の存在でした。

意思決定を待つうちに、プロジェクトはリズムを失う

ソフトウェアプロジェクトにおける無駄は、質の悪いコードや大量のバグ、作り直しが必要な機能からだけ生まれるわけではありません。このプロジェクトではっきりと目にした無駄があります。それが「待ち時間」です。

チームが丸一日「待ち」に費やしただけの日もありました。ワイヤーフレームの承認待ち、提案したアプローチの承認待ち、運用と経理の調整待ち、そして、ある拠点がすでに了承したロジックに別の拠点が同意するのを待つ――。それぞれの「待ち」はたいしたことがないように見えます。しかし積み重なると、チームのリズムはあっという間に崩れます。

判断が止まるたびに、プロジェクトは表面上は進んでいるように見えていました。ボード上のタスクは「レビュー中」のまま。報告書には「協議中」「フィードバック待ち」と書かれ続けます。
一方で開発側では、どのフローに従えばいいのか分からず、スプリントは計画から外れ始め、スケジュールはじわじわと遅延していきました。

終盤になると、たいていチームは失った時間を取り戻すためにペースを上げざるを得なくなります。このしわ寄せは技術的な難易度によるものではありません。意思決定のボトルネックから来るものです。

私はこれを「意思決定レイテンシ（decision latency）」と呼んでいます。進捗報告にはほとんど表れないコストです。具体的な技術的欠陥としてすぐに現れることもありません。コードはまだ間違っておらず、UIも壊れておらず、システムに障害も記録されていません。しかし、フィードバック待ちを何度か繰り返すうちに、計画はすでにずれています。チームが気づいたときには、バッファで持っていた時間は「待ち時間」に奪われているのです。

開発チームにとって最ももどかしいのは、プロダクトを丁寧に、自信を持って作れるはずの最良の時間が、全員が「フィードバック待ち」で止まっている間に過ぎ去ってしまうことです。

学校向けシステムでは、1つのフェーズを逃すと1学年分を逃すこともある

業界によっては、要件が数週間遅れても、リリース日が後ろにずれるだけで済みます。しかし教育分野では、システムが学校のカレンダーに沿って動かなければならないため、ずらせないのです。

入学シーズン、新年度の始まり、学費の徴収、クラス編成――これらはすべて決まった日程で行われます。入学申し込みに関わる機能が手続きシーズンまでに間に合わなければ、そのプロダクトは丸1年間使われる機会を失うかもしれません。そうなると、問題はもはやスプリントの遅れではありません。ビジネスが本当にシステムを必要とするタイミングを逃した、ということです。

後からパッチをリリースしても、問題は一部しか解決しません。保護者がすでに手作業で申し込みを済ませ、データが別の場所に存在し、運用スタッフがその代替手段に慣れてしまっていれば、すべてをシステムに戻すには何倍もの労力がかかります。

これこそが、学校向けシステムのデッドラインが根本的に違う理由です。入学、始業、学費徴収、クラス編成、年度末といった教育現場の自然な運営リズムに従います。そしてこれらの節目は、要件が整っていようがいまいが、予定どおりにやってきます。

教育機関向けシステムの開発では、意思決定の遅れが、ビジネスが本当にプロダクトを必要とするタイミングを逃す原因になり得るのです。

結局、開発チームがプロダクトの責任を背負うことになる

発注側がすぐには正式な POを置けないとわかったとき、チームは要件が完全に揃うのを待ち続けるわけにはいきませんでした。プロジェクトは前に進めなければなりません。そこで私たちは、自ら課題を明確にし、議論を主導する姿勢に切り替えました。

「システムをどう動かしたいですか」といった漠然とした質問をする代わりに、具体的な提案を示して全員にレビューしてもらうようにしたのです。このフローは運用に合っていますか？ 経理の観点で変えるべき点は？ 教務の観点で足りないものは？ 叩き台があることで議論の曖昧さが減り、フィードバックもより具体的で実行しやすいものになりました。

さらに、コードを書く前にワイヤーフレームやインタラクティブなモックアップを作るステップも加えました。以前は要件がある程度明確になればすぐに開発に入ることが多かったのですが、度重なる手戻りを経て、開発者が作り始める前にフローを目で確認できる中間ステップを用意したほうが効率がいいと気づきました。業務ロジックの矛盾の多くはこの段階で表面化しました。UIやバックエンドが完成した後に比べ、修正コストがずっと低いうちにです。

なにより大変だったのは、技術力を持った開発者が、本来なら業務に精通した要件定義の担当者が担う仕事を引き受けなければならなかったことです。要件定義の担当者も POもいない中で、彼らは自ら業務ルールを確認しに行き、複数の部署から情報を集め、矛盾を見つけ出し、ソリューションのドキュメントを書きました。

この対策でプロジェクトは前に進むことができました。しかし同時に、開発チームには大きな負荷がかかりました。開発者が開発作業から引き離される機会が増え、テックリードはプロダクト関連の質問により多く対応しなければならなくなりました。プロダクトの責任が、業務の全体像を把握しておらず、発注側に代わって決定する権限もない人たちへと移り始めたのです。

短期的には、開発チームが課題の明確化を手伝い、解決策を提案し、矛盾を指摘することはできます。しかし長期的に、あらゆるプロダクト判断が開発チームに押し付けられ続ければ、プロジェクトは「システムを作る人が、プロダクトの方向性まで推測する」という体制に依存することになってしまいます。

POの不在は「意思決定の仕組みがない」ことを意味する

そのプロジェクトを経て、私の POという役割に対する見方がガラリと変わりました。

システムの開発で POがいないということは、プロダクトに関する明確な意思決定の仕組みがないということです。多くのステークホルダー、学校カレンダーに縛られた期限を抱えるプロジェクトでは、この仕組みは技術力と同じくらい重要です。小さな変更のたびに何度も意見を集め、最終判断に責任を持つ人がいなければ、開発チームはやはり立ち往生してしまいます。

私が得た最大の教訓は「すべての役割を教科書どおりに揃える必要は必ずしもない」ということです。現実のプロジェクトがそれほどきれいに進むことはまずありません。しかし、複数の視点を「実際に作れる一つのプロダクト判断」へとまとめる一人のキーパーソン、あるいは少なくとも十分に明確な仕組みは、絶対に必要です。

その仕組みがなければ、要件は定まらないまま、チームは待ち続け、やがて開発チームがプロジェクトを存続させるためだけに POの責任を背負うことになります。日本では、PMの経験者は多い一方で、POを明確に置いているプロジェクトはまだ多くありません。組織の上位者が事実上の POだったり、PMが POを兼ねていたりして、メンバーから見て「最終的に誰が決めるのか」が分かりにくいケースをよく見かけます。また、最初は決まっていた責任者が、権限移譲や体制変更をきっかけにいつの間にか曖昧になることもあります。
体制がどう変わっても、プロダクトの最終判断を担う人の存在と役割は変わらないはずです。まずはプロジェクトに関わる全員が「この判断の責任者は誰か」を共有すること。そして PMやマネジメント層は、役職ではなく POを最終判断者として捉え、判断に必要な材料を見える形で届けること。それが、本記事のような事態を防ぐ第一歩だと考えています。

今回の事例は教育機関向けシステムの開発ですが、「意見を言う人は多いのに、決める人がいない」という状況は、業界を問わず多くのプロジェクトで起きています。あなたのプロジェクトでは、最終判断を下すのは誰でしょうか。その答えがすぐに出てこないなら、まずは決定権者と決定の記録の残し方をチームで確認するところから始めてみてはいかがでしょうか。

AI時代の開発こそ、「誰が決めるのか」の定義がますます重要にーリックソフトのコンサルティング

日本では、PMの経験者は多い一方で、POを明確に置いているプロジェクトはまだ多くありません。組織の上位者が事実上の POだったり、PMが POを兼ねていたりして、メンバーから見て「最終的に誰が決めるのか」が分かりにくいケースをよく見かけます。また、プロジェクトの進捗が思わしくなく、てこ入れをした結果、最初は決まっていた責任者が、権限移譲や体制変更をきっかけにいつの間にか曖昧になることもあります。
しかし、体制がどう変わっても、POの存在と役割は変わらないはずです。
「プロジェクトに関わる全員が最終判断の責任者を知っていること」
「PMやマネジメント層が、役職ではなく POを最終判断者として捉え、判断に必要な材料を見える形で届けること」
AIを前提に開発を進める時代だからこそ、この「誰が決めるのか」の定義はますます重要になると考えています。

リックソフトのコンサルティングサービスでは、お客さまの PMの方と対話しながら、意思決定の責任者や合意形成の進め方を整理するところからご支援しています。誰が何を決めたのかを記録し、判断に必要な情報を関係者全員が見られる状態をつくることで、手戻りや待ち時間を減らし、品質・コスト・納期（QCD）の改善につなげます。

ベトナム、シンガポールのメンバーもおり、グローバルでの IT基盤をお持ちの組織もサポートできます。

「最終判断者が分からなくなりがち」といった課題をお持ちの方は、お気軽にご相談ください。

※本記事は BiPlus社のブログ記事を翻訳・編集したものです。