システム開発の失敗で一番多いのは、技術的な失敗ではありません。発注前に要件が固まっていなかったことによる、途中の仕様変更と手戻りです。
文章で書かれた仕様書を回覧して「これで合っていますか」と確認しても、現場から出てくるのは「たぶん大丈夫だと思います」です。実物を見ていないので、判断のしようがないからです。そして開発が始まってから「これは違う」が出ます。
本記事は、この構造にどう対処したかの記録です。自社の管理業務をシステム化し、大手の取引先へ提案したいという会社の案件で、当社はアドバイザーとして参加しました。本開発は外部の開発会社が担当し、当社は開発を請け負っていません。
なお、お客様が特定されないよう、企業名・業種・具体的な数値は伏せ、状況の説明にとどめています。
状況：規模の大きな発注を、文章だけで決められるか
案件の構図はこうです。
- 売り手：自社の管理ノウハウをシステム化したい会社
- 買い手候補：大手の取引先
- 開発：外部の開発会社
- 当社：アドバイザー（開発・運用は引き受けない）
売り手はこれまで、日々の記録を紙とExcelで管理してきました。現場ごとの点検記録、各種許認可の期限、対応の履歴、図面や見積、作業前後の写真。これらを買い手候補へシステムとして提案したい、という段階でした。
ここで難しいのは、提案する側も買う側も、そのシステムを見たことがないという点です。要件定義の会議を重ねても、議論が抽象論から抜け出せません。
やったこと：提案の前に、触れるプロトタイプを作る
当社が担当したのは、仕様書の作成ではなく、実際に動くプロトタイプを作ることでした。
作った範囲は、ひととおり触れる程度には広めに取っています。
- 全拠点を横断するダッシュボード。許認可の期限や、評価の悪化をアラートで表示する
- 拠点ごとの詳細画面。対象物の一覧、点検記録（段階評価と写真）、申請関係、対応の履歴
- 対応の記録は作業前と完了後を並べて表示し、提案書・報告書をPDFとCSVで出力できる
- 写真の一括アップロードと、1枚ずつのタイトル付与
- 図面の軽微な編集。PDFや画像を背景に、文字・線・番号・矢印で注記を入れて書き出す
- 拠点・写真・図面を横断する検索と、選択した分のCSV出力
アラートの設計には、少し工夫を入れました。単純な「期限の◯日前」ではなく、申請や手配にかかるリードタイムから逆算した「着手すべき期限」で判定しています。実務では、期限当日に気づいても間に合わないためです。
AIによる分類の候補出しと、書類の下書き生成も入れました。ただし安全性の評価だけはAIにさせていません。危険度の判定は人が行い、AIは候補出しと文章の下書きまでに留めています。ここは提案の場でも必ず説明している線引きです。
効果①：要望が、具体的な粒度で出てきた
プロトタイプを提案とヒアリングの土台にしたところ、先方からまとまった数の要望が上がってきました。
重要なのは件数ではなく、粒度でした。上がってきたのは「一覧のこの列は不要」「この項目の名称を変えたい」「CSVにこの条件を足したい」「この操作の順番が実務と違う」といった、実物を触らないと絶対に出てこない内容です。
文章の仕様書を回覧していたら、返ってきたのは「おおむね問題ありません」だったはずです。そしてその「おおむね」の中に、それらが隠れたまま開発に入っていました。
要望は共有シートで管理し、1件ずつ「対応区分・対応メモ・反映状況」を記入していく形にしました。運用していて気づいた点を1つ挙げておきます。先方はセルの塗り色で意思を表現していました。グレーは取り下げ、黄色は生きたコメント、という具合です。文字だけ読んでいると、取り下げられた要望に工数を使うことになります。共有シートを使う場合は、色の意味を早い段階で確認しておくことをおすすめします。
効果②：「作らない」判断ができるようになった
プロトタイプのもう1つの効果は、要望を却下する根拠が持てることでした。
便利機能の追加は、そのまま開発会社への要件の積み増しになり、見積りに跳ねます。上がってきた要望をすべて実装すれば、当然その分だけ高くなります。
そこで、1件ずつ「初回リリースに本当に要るか」を判断する形にしました。実物があると、この議論ができます。画面を見ながら「これがなくても業務は回りますよね」と確認できるからです。仕様書の箇条書きだけを見ていると、どれも必要に見えます。
線引き：モックで作り込まないと決めたこと
途中で明確にした方針があります。操作感の作り込みは、モックではやらないというものです。
理由は単純で、このプロトタイプはそのまま本番システムにならないからです。本開発は別の会社が行います。ボタンの押し心地や画面遷移の滑らかさを磨いても、本番には引き継がれません。
そこで、変更を2種類に分けました。
| 入れる | 入れない |
|---|---|
| 列の増減、項目名の変更 | 操作の心地よさの改善 |
| CSV出力の条件変更 | アニメーションや細かな表示調整 |
| 不具合の修正 | 実装しないと決めた画面の作り込み |
| 要件を確定させるための機能追加 | 管理者側の細かな作り込み |
「こう操作したい」という要望は、実装せずに要件メモとして残し、開発会社へ渡す形にしました。
もう1つ、提案の場で見せる範囲も絞っています。買い手候補に見せるのは利用者側の画面のみで、管理者向けの画面と、両者を切り替えるための機能は出しません。実際の運用では、利用者側に切り替え機能は存在しないためです。デモで見せた機能が本番にないと、後で必ず問題になります。
副産物：要件資料が、そもそも読めなかった
実務的な落とし穴も1つ共有しておきます。
先方から届く要件資料は、デザインソフトから書き出されたPDFでした。この形式のPDFは、一般的なツールでは日本語のテキストを抽出できません。フォントの埋め込み方式の問題で、文字が文字として取り出せないのです。
しかも指示の中心が、打ち消し線・バツ印・囲みといった図の要素にありました。テキストだけ抽出できても意味が取れません。
対処として、ページを画像化したうえで注記の位置情報を復元し、両方を突き合わせて読む手順を用意しました。目視だけで判断せず、必ずテキストを復元して読み合わせる形にしています。
紙やPDFでやりとりする案件では、こうした「資料が読めない」という物理的な問題が意外と時間を食います。
アドバイザーとして、あえて言うべきこと
この案件で当社が最も価値を出したのは、実装ではなかったと考えています。
プロトタイプが一段落した段階で、当社の見立てを整理してお伝えしました。要点はこうです。
この段階のものは「提案を勝たせるための、よくできた動くデモ」であって、そのまま有償の本番システムとして売れるものではない。
理由は3つでした。
- サーバー、本格的な認証、ファイル保管、運用体制が揃っていない。これは能力の問題ではなく、意図的にモックに留めている結果です
- そもそも買い手の購入が確定した商談ではない。本番化に何が足りないかを論じる前に、買い手が固まっているかが先です
- 同種の機能を備えた既製パッケージが、すでに市場に存在する。期限の自動通知、写真・書類管理、権限管理まで揃っているものがあります
3つ目が最大の論点です。「本番化に何が足りないか」以前に、わざわざ自社開発する理由があるのかを確認すべき局面でした。
アドバイザーの仕事は、作らせることではありません。作らない方がいい可能性を、判断できる材料とともに早い段階で出すことだと考えています。実装を請け負う立場だと、この助言は構造的に出しにくくなります。開発を引き受けない座組みには、そういう意味もあります。
この形が向いているケース
発注前にプロトタイプを作る進め方は、次の条件が揃うときに効きます。
1. 発注金額が大きく、手戻りのコストが高い
規模の大きな開発で仕様変更が数回出れば、プロトタイプの費用は簡単に回収できます。逆に小規模な開発では、作らずに進めた方が早い場合もあります。
2. 買い手と売り手のあいだで、業務の理解に差がある
売り手が自社の業務をシステム化する場合より、他社に使ってもらうシステムを提案する場合の方が、実物の効果が大きくなります。相手の業務は想像で埋めるしかないためです。
3. 実装する会社と、要件を決める人が別
社外に開発を出す場合、文章での伝達には限界があります。動くものがあれば、それ自体が仕様書として機能します。
4. 「作らない」判断があり得る
プロトタイプは、作るための道具であると同時に、作らない判断をするための道具でもあります。既製品で足りるかどうかは、実物を見て初めて具体的に比較できます。
まとめ
- 発注前に動くプロトタイプを作ったことで、文章の仕様書では出てこなかった要望が具体的な粒度で表面化した
- 実物があると、要望を却下する根拠も持てる。便利機能は見積りに跳ねるため、1件ずつ「初回リリースに要るか」を判断できる
- モックで作り込む範囲は限定する。要件を確定させる変更は入れ、本番に引き継がれない操作感の作り込みはやらない
- アドバイザーの価値は実装ではなく、「作らない方がいい可能性」を早期に材料つきで出せること
当社はアドバイザーとして、要件整理から発注前のプロトタイプ作成までをお引き受けしています。すでに開発会社が決まっている案件でも構いません。
他の2つの導入パターンについては、中小企業のAI導入は、実際には3つの形しかないをご覧ください。