稟議を通すシステム開発｜プロトタイプの使い方

新規事業のシステム開発では、企画書と見積もりだけで稟議を通そうとして行き詰まることがあります。この記事では、稟議が止まりやすい理由と、プロトタイプ（動く試作品）を判断材料として使う考え方を整理します。論点の洗い出しから稟議書への書き方、使うときの注意点まで確かめていきます。

稟議でシステム開発が止まる理由

稟議とは、担当者が起案した内容を、関係部署や決裁者が順に確認して承認していく日本企業に多い意思決定の手続きです。新規事業のシステム開発を進める場面でも、この稟議の流れで投資の可否が決まる会社は少なくありません。

ところが、新規事業のシステム開発に関する稟議は、通常の案件よりも止まりやすい面があります。理由は大きく2つあります。

稟議書は「その場にいない人」に読まれる

稟議書は、起案した人が横にいない状態で読まれます。起案者の頭の中にある構想や熱量は、書面に落とした時点で多くが抜け落ちます。

承認する側は、書かれた文章と図だけで、何を作るのか、本当に使われるのか、失敗したときの影響はどの程度かを判断しなければなりません。読み手ごとに頭の中の完成イメージが食い違うと、質問や差し戻しが増えていきます。

新規事業は判断材料がそろいにくい

既存業務のシステム更新であれば、現行の仕組みがあるため、比較の基準を置きやすくなります。一方、新規事業のシステムは前例がなく、「どんな画面で、誰が、どう使うのか」を文章で伝えるしかない場面が多くなります。

仕様が固まる前は、費用や期間の見積もりにも幅が出ます。幅のある数字を前提に承認を求めるのは、承認する側にとっても重い判断です。

企画書だけで決裁を取る難しさについては、新規事業の決裁を企画書だけで取るのが難しい理由でも詳しく整理しています。

稟議の判断材料になるプロトタイプ

そこで考えたいのが、稟議の前にプロトタイプを作り、実物を判断材料に加える進め方です。

プロトタイプとMVP・モックの違い

言葉の整理を先にしておきます。

• プロトタイプ：試作品の総称です。目的は、仮説や仕様を確かめることにあります。
• モック：見た目だけを再現した見本です。画面の見え方は目で見て確認できますが、実際の処理は動かすことができません。
• MVP（Minimum Viable Product）：必要最小限の機能で、実際の利用者に使ってもらう製品です。市場の反応の確認が目的です。

稟議の判断材料としては、画面だけでなく、主要な操作の流れが実際に動くプロトタイプが役に立ちます。それぞれの使い分けについては、プロトタイプとMVP・モックの違いを整理｜新規事業の使い分けで詳しく解説しています。

実物があると何が変わるか

動く実物があると、稟議の場で次のような変化が起こりやすくなります。

• 何ができるかを全員が同じ画面で見られる
• 質問が「想像」ではなく「実物への指摘」になり、論点が具体的になる
• 起案者と承認者の完成イメージのズレに、早い段階で気づける
• 仕様が固まっていく過程が見えるため、見積もりの前提も説明しやすくなる

大きいのは、経営陣と現場のズレが減る点です。新規事業では、決裁者と立案者が同じ目的を見ているのに、判断の材料と進む速度が違うため話が噛み合わないことがあります。ズレているのは目的ではなく進め方です。この点は新規事業で経営陣と現場がすれ違う原因は進め方のズレでも扱っています。

実物を関係者と一緒に見ながら話し合えば、「ここはこう」「これは要らない」といった具体的なやり取りになり、書面だけでは埋まらなかった認識の溝を埋めやすくなります。

稟議の質問とプロトタイプの答え方

稟議では、立場によって見る観点が異なります。会社ごとに違いはありますが、一般的には次のような質問が出やすいと考えられます。それぞれに対して、プロトタイプでどう答えられるかを整理しておくと準備しやすくなります。

• 経営陣：「この事業はどんな形になるのか」「システムは事業の中でどんな役割か」。主要な利用の流れを実際に動かして見せることで、事業の姿を共有できます。
• 経理・財務部門：「何に、どれだけの投資が必要か」。実物で機能の範囲を確認しておくと、作る範囲と作らない範囲を線引きしやすくなり、見積もりの前提を説明しやすくなります。
• 情報システム部門：「既存の仕組みや社内ルールと整合するか」。他システムとの連携が必要な箇所や、データの扱いに関する論点を、動く実物を見ながら洗い出せます。
• 法務・コンプライアンス部門：「個人情報や契約まわりに問題はないか」。画面上でどんな情報を扱うかが見えるため、確認すべき点を具体的に指摘してもらえます。
• 現場部門：「実際の業務や顧客対応で使えるのか」。触ってもらうことで、使い勝手に関する率直な意見を早めに集められます。

ここで大切なのは、プロトタイプですべての質問に答えようとしないことです。実物で答えやすい質問と、別の資料で答えるべき質問を分けて考えると、準備の焦点が定まります。

稟議に向けたプロトタイプの進め方

ここからは、稟議を見据えてプロトタイプを使う手順を、5つに分けて説明します。

1. 稟議で問われる論点を先に書き出す

最初に作るのは、プロトタイプではなく論点の一覧です。承認者になりそうな人の立場ごとに、「何が分かれば判断できるか」「どこが不安か」を書き出します。可能であれば、事前に軽く意見を聞いておくと、手戻りが減ります。

2. プロトタイプで確かめる範囲を絞る

論点が見えたら、プロトタイプで確かめる範囲を絞ります。すべての機能を作ろうとすると、時間もかかり、肝心の論点がぼやけます。

選ぶ基準は、「この流れが動かなければ事業が成り立たない」という中核の部分です。管理画面や細かい設定のように、後からでも決められる部分は、思い切って対象から外します。

何を作り、何を作らないかを決める作業は、要件定義そのものでもあります。抜け漏れやズレを防ぐ進め方は、要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方で解説しています。

3. 実物を見せる場を作る

プロトタイプができたら、承認者に見てもらう場を用意します。稟議書に画面の写真を貼るだけでなく、可能なら、実際に触れる機会や、操作の流れを説明するデモの時間を設けます。

稟議は回覧で進むことが多いため、その場に来られない人向けに、短い操作動画や、操作手順の説明を添えておく方法もあります。見た人によって解釈が分かれないよう、「このプロトタイプで確認できること」と「まだ確認できていないこと」を最初に明記しておくと、後々の誤解を防ぎやすくなります。

4. 稟議書に「見た結果」を書く

稟議書には、プロトタイプを作ったという事実だけでなく、見て分かったことを書きます。たとえば、次のような項目です。

• 目的と背景：何のための事業で、システムはどんな役割を持つか
• プロトタイプで確認した内容：どの流れを、誰が触って、どんな反応だったか
• 見つかった課題と、その対応方針：「これじゃない」と分かった点をどう直すか
• 本開発の範囲：実物をもとに決めた機能と、後回しにする機能
• 費用と期間の見込み：前提と幅が出る要因
• 判断事項：何を、いつまでに誰が決めるか

企画書の言葉だけで説明するより、確かめた結果を示したほうが、承認者は判断しやすくなります。うまくいかなかった点を正直に書いておくことも、稟議書の信頼感を高めます。

5. 判断を二段階に分けて考える

もう一つは、稟議の判断を二段階に分けます。

• 第一段階：プロトタイプを作り確かめるか
• 第二段階：実物を見たうえで、本開発に進むかどうかを決める

最初から「本開発を進めてよいか」を問うと、承認する側の負担は大きくなります。判断を分けることで、第一段階では確かめたい論点に集中でき、第二段階では実物にもとづいた判断ができます。社内の規程に合わせて、どの金額や範囲から、どの承認が必要かを確認しておくと、進行がスムーズです。

アイデアを動くシステムで確かめる具体的な手順は、新規事業のアイデア検証方法｜動くシステムで確かめる手順にまとめています。

プロトタイプを稟議に使う注意点

プロトタイプは便利な判断材料ですが、使い方を誤ると、かえって話がこじれることがあります。注意したい点を整理します。

プロトタイプは本番のシステムではない

動く実物を見ると、「もうほぼ完成している」と受け取られることがあります。そのため、本番運用に必要な部分（セキュリティ、大量のアクセスへの対応、保守の体制など）は別に検討が必要になることを、あらかじめ伝えておく必要があります。関係者の期待値を揃えておかないと、本開発の段階になってから「想定と違う」という話になりかねません。

事業としての需要は別に確かめる

プロトタイプで確かめられるのは、主に「何を作るのか」「使いやすいか」という点です。実際に顧客がお金を払って使うのか、という市場における需要は、顧客へのヒアリングや試験的な提供など、別の方法でも確かめておく必要があります。プロトタイプは、そのための対話の材料としても使えますが、それだけで需要の証明になるわけではありません。

作り込みすぎない

稟議を通すことが目的であるのに、見た目や細部まで作り込んでしまうと、時間がかかり、検討の機会を逃します。確かめたい論点に絞り、それ以外は作り込まず割り切るのが基本です。

実データや個人情報の扱いに気をつける

デモに実際の顧客データや個人情報を使うと、情報管理上の問題になることがあります。見せる際は、ダミーのデータを使うなど、社内の情報管理のルールに沿って準備します。

AIで作る場合も、人の確認は欠かせない

近年は、AIを活用した開発により、プロトタイプを作る時間を短くしやすくなっています。その流れについては、AI駆動開発で新規事業の立ち上げはどう変わるかでも整理しています。ただし、AIが作ったものを、そのまま稟議の材料にしてよいわけではありません。動作や内容を人が確認し、品質に責任を持つ視点が必要です。その理由はAI開発でも品質には人の確認が必要な理由で詳しく解説しています。

外部に依頼する場合は、認識合わせを丁寧に

プロトタイプづくりを外部の開発会社に依頼する場合は、何を確かめたいのかを最初に共有することが重要です。依頼の流れや、失敗を防ぐ考え方はシステム開発の外注ガイド｜依頼の流れと失敗の防ぎ方に、完成後の認識のズレを防ぐ方法はシステム開発の認識のズレを防ぐ、実物を見ながらのすり合わせにまとめています。必要に応じてご覧ください。

仕様がまだ固まっていない段階でも、相談自体は可能です。進め方は仕様が決まってないシステム開発の相談は可能かで説明しています。

まとめ

新規事業のシステム開発で稟議が止まりやすいのは、承認する側が、書面だけでは「何ができるのか」を同じイメージで持ちにくいためです。ズレているのは目的ではなく、判断材料と進め方であることが多いと私たちは考えます。

プロトタイプ活用のポイントは、こちらです。

• 稟議で問われそうな論点を、先に立場ごとに分けて書き出す
• 事業の中核となる流れに絞って、プロトタイプで実際に動かしながら確かめる
• 実物を見た結果と、見つかった課題を稟議書に整理して書く
• 判断を二段階に分け、本開発に進むかどうかの判断は実物を見てから行う
• 本番ではないこと、需要は別に確かめることを、事前に共有する

システムそのものが事業になる新規事業では、システムの形が見えないまま投資を判断するのは難しいものです。システムを軸に事業の形を描く考え方は、新規事業のシステム設計とビジネスモデルの作り方も参考になります。MVPやプロトタイプの進め方全体は、MVP開発・プロトタイプ開発の進め方｜新規事業の判断法で確認できます。

JustFitは、株式会社LEGAREAが運営する完全オーダーメイドの受託開発サービスです。「先に作って、後から決める（PROTOTYPE FIRST）」という考え方で、構想をもとに約1ヶ月で、実際に動くプロトタイプを先に開発します。実物を見てから契約を判断できるため、稟議を通す前の段階や、仕様が固まっていない段階でもご相談いただけます。詳しくはご相談ください。