システム開発を発注したことがある方なら、一度は「思っていたものと違うものが出来上がってきた」「仕様書では問題ないと思っていたのに、実物を見たら使いにくかった」という経験があるのではないでしょうか。この問題は仕様書をどれだけ精緻に書いても根本的には解消できません。発注者と開発者が同じ言葉から異なる完成像をイメージしてしまう、という構造的な限界があるからです。
この構造的な問題に対する一つの答えが「並走型システム開発」です。本記事では、並走型開発とは何か、従来型の受託開発と何が違うのか、なぜ「動くプロトタイプを発注前に見られる」ことが決定的に重要なのか、そしてどんな企業に向いているのかを徹底解説します。
結論:並走型システム開発とは「契約前に動くものを確認できる開発手法」
並走型システム開発とは、開発者と発注者が並走してプロトタイプを作り、契約前に実際に動くものを触ってから本契約に進める開発手法です。最大の特徴は3つあります。
- 契約前にプロトタイプ(動くものの試作品)を実際に操作できる
- 稼働開始までは費用が発生しない(開発側がリスクを負担)
- 稼働後も継続的に改善を支援する伴走関係を前提とする
従来型の受託開発が「仕様書で合意 → 開発 → 納品」という一方向の流れだったのに対し、並走型開発は「ヒアリング → プロトタイプ → 確認・調整 → 本契約 → 稼働 → 継続改善」という双方向のサイクルで進みます。
従来型受託開発と並走型開発の決定的な違い
両者の違いを表で整理します。
| 項目 | 従来型受託開発 | 並走型システム開発 |
|---|---|---|
| 契約のタイミング | 要件定義の段階で契約 | プロトタイプを確認してから契約 |
| 初期費用 | 300万円〜が一般的 | 0円(標準ケース) |
| 仕様変更への対応 | 追加費用が発生しやすい | 稼働前なら自由に変更可能 |
| 「思っていたのと違う」リスク | 納品後に発覚しやすい | プロトタイプ確認時点で解消 |
| 開発期間 | 3〜6ヶ月以上 | プロトタイプは1〜2週間、本実装は1〜3ヶ月 |
| 稼働後の関係 | 保守契約に移行(別費用) | 月額費用に改善対応を含む |
| 途中でやめた場合 | 初期費用は返還されない | 稼働前は費用ゼロ |
最大の違いは「契約のタイミング」です。従来型では情報量が少ない段階で大きな金額の契約を結ぶことになりますが、並走型では実物を確認した上で契約判断ができます。発注者の意思決定に必要な情報量が圧倒的に違います。
なぜ「動くプロトタイプ」が決定的に重要なのか
仕様書では認識齟齬を防げない構造的な理由
システム開発のプロジェクトが失敗する最大の原因は、技術的な難しさではなく「発注者と開発者の認識齟齬」です。IPA(情報処理推進機構)の調査でも、上流工程である要件定義の不十分さが失敗要因の上位に常に挙げられています。
仕様書に「シンプルなUI」と書いたとき、発注者がイメージする「シンプル」と開発者がイメージする「シンプル」は同じではありません。「使いやすい」「直感的に」「業務に合った」といった言葉も同様です。言葉は誰もが知っているのに、それが指す具体的なイメージは人によって異なります。これは仕様書をどれだけ詳細化しても、図解を加えても、完全には埋まりません。
プロトタイプは100ページの仕様書よりも雄弁
動くプロトタイプがあれば、認識のすり合わせは劇的に早くなります。実際にボタンを押して画面遷移を見て、入力フォームに値を入れて、データの流れを目で追える。この「触れる」体験は、どんな仕様書よりも具体的です。「ここはイメージと違う」「この機能は要らない」「むしろこの機能が欲しい」という調整が、認識齟齬を残したまま開発が進んでしまう前に行えます。
結果として手戻りもコスト膨張も起きにくい
「思っていたのと違う」が納品後に発覚すると、修正には大きな追加費用と時間がかかります。これは発注者にとっては予算超過の痛みであり、開発者にとっては利益を圧迫する重い手戻りです。並走型開発では、この最も痛い手戻りが構造的に発生しにくくなります。
並走型システム開発の具体的なプロセス
オルアナで実際に提供している並走型開発の流れを、5つのステップで解説します。
Step 1:初回ヒアリング(30〜60分)
現状の業務フロー、抱えている課題、理想の状態をお聞きします。この段階では仕様書の作成は求めず、口頭での説明や手書きのメモレベルで構いません。むしろ「言語化しきれていない部分」こそが価値があります。
Step 2:プロトタイプ作成(1〜2週間)
ヒアリング内容をもとに、実際に動くプロトタイプを作成します。完成品の見た目と主要動作の8割程度を再現したもので、ブラウザ上で実際に操作できる状態です。AI を活用した開発手法により、従来であれば数週間かかっていたこの工程を1〜2週間に短縮しています。
Step 3:プロトタイプ確認・調整(1〜2週間)
プロトタイプを実際に触っていただき、調整点を出していきます。「画面の項目を増やしたい」「この処理は自動化したい」「業務フローに合わない」といった具体的なフィードバックを反映します。この時点まで費用は一切発生していません。
Step 4:本契約と稼働開始(1〜3ヶ月)
プロトタイプにご納得いただけた段階で初めて本契約を結びます。残りの実装、テスト、データ移行、現場メンバーへの導入支援を行い、業務でご利用いただける状態にします。月額費用の発生はこの稼働開始のタイミングからです。
Step 5:稼働後の継続改善
システムは作って終わりではなく、業務の変化に合わせて改善し続ける必要があります。並走型開発では月額費用の範囲内で継続的な改善対応を行います。新機能の追加、業務フロー変更への対応、ユーザーからのフィードバック反映などを継続的に支援します。
並走型システム開発が向いている企業・向いていない企業
向いている企業の特徴
- Excel管理に限界を感じているが、何から手をつけていいか分からない中小企業
- 過去にシステム導入で「思っていたのと違う」を経験した経営者
- 初期に大きな投資をするのは難しいが、月額なら継続支払いが可能な企業
- 業務が変化していくため、システムも継続的に改善していきたい企業
- 担当者が変わると業務が止まる、属人化を解消したい組織
向いていない企業の特徴
- 厳密な仕様書を事前に固めて、その通りに作ってもらいたい企業(公共調達系など)
- 業務内容が極めて特殊で、汎用的な技術スタックでは対応できない要件がある企業
- 稼働後の改善は不要で、一度作ったら長期間そのままで使いたい企業
- システムを内製化したいが、開発者の育成期間中だけ外部支援が欲しい企業(短期完結型)
向いていない条件に該当する場合、無理に並走型を選ぶ必要はありません。私たちオルアナでも、こういった条件のお客様には別の選択肢をお勧めすることがあります。ご相談の段階で正直にお伝えします。
よくある質問
Q. 並走型開発はアジャイル開発と何が違いますか?
アジャイル開発が「短いサイクルで開発を回す手法」を指すのに対し、並走型開発はそれに加えて「契約前にプロトタイプを確認できる」「稼働前は費用ゼロ」「稼働後の継続改善が月額に含まれる」というビジネスモデルの特徴を持ちます。アジャイル開発の一形態と捉えていただいて構いませんが、ビジネス面でのリスク配分が大きく異なります。
Q. プロトタイプを見せてもらった後、契約しなくても本当に問題ないですか?
はい、稼働開始前に終了されても費用は一切発生しません。「やはり今は導入時期ではない」「思っていた方向性と違った」というご判断であれば、その時点で終了していただいて構いません。私たちにとってもプロトタイプ段階での見極めは健全なプロセスと考えています。
Q. プロトタイプはどの程度のクオリティで作ってもらえますか?
完成品の8割程度の見た目と動作を再現したものをお見せします。ダミーデータを入れた状態で実際に画面操作できるレベルです。紙のモックアップやスライドではなく、ブラウザ上で動くものを提供することを基本としています。
Q. 月額費用の中で、どこまで改善対応してもらえますか?
業務フローの変更に伴う調整、画面項目の追加、データ集計の見直し、軽微な機能追加などは月額の範囲内で対応します。大規模な機能追加や別システムとの連携など、新規開発に近い規模のものは別途お見積もりをご相談させていただきますが、ヒアリング段階で必ず明示します。
Q. 開発が小規模体制とのことですが、継続性は大丈夫ですか?
オルアナでは汎用的な技術スタックのみを使用してシステムを構築しています。特定ベンダー独自のクラウドサービスや独自言語ではなく、業界標準の技術を採用しているため、万が一の場合も他のベンダーや内製化への移行が容易です。ソースコードもお客様にお渡しします。
まとめ:並走型開発は「情報量を揃えてから意思決定する」開発手法
並走型システム開発の本質は、システム導入における意思決定の構造を変えることにあります。従来型では情報が少ない段階で大きな投資判断を強いられていたのに対し、並走型では実物を確認した上で判断できます。これにより、システム開発の最大の失敗要因である認識齟齬が構造的に解消されます。
もちろん並走型開発がすべての企業・すべての案件に最適というわけではありません。本記事で示した「向いている企業」「向いていない企業」を参考に、自社にとって適した開発手法を選んでいただければと思います。「初期費用ゼロ」については別記事で詳しく解説していますので、興味があればご一読ください。
関連記事:「初期費用0円のシステム開発」は本当に得なのか?仕組みと条件を正直に解説
関連記事:「言った言わない」が起きるシステム開発の典型パターンと、認識齟齬を防ぐ5つの方法
関連記事:Excel管理を脱却する3つのステップ|現場が定着する業務システムへの移行方法
関連記事:「使われないシステム」を作らないために発注者が確認すべき7つのチェックポイント
無料相談のご案内
並走型システム開発について、30分のオンライン無料相談を実施しています。「うちの業務でプロトタイプを作るとしたらどんなものになるか」「他社の事例も知りたい」など、具体的な質問にお答えします。
毎月2社限定の受付となっておりますので、お早めにご相談ください。