How to Build Business Systems

Common failure patterns

業務システム開発が失敗する3つの原因

• 要件定義が「文書上の合意」で終わっている 仕様書や打ち合わせでの合意は、実際に動くシステムを見るまで「正しい」かどうかわかりません。言葉と図で定義した要件が、実装後に「こういうイメージではなかった」と判明するのが最も多い失敗パターンです。
• 現場の声が設計に届いていない 発注担当者とベンダーだけで要件定義を進め、実際にシステムを使う現場担当者が開発後まで関与しないケースがあります。完成後に現場から「使いにくい」「業務フローが合っていない」という声が上がっても、その時点での修正は大きなコストになります。
• 完成後に発覚する仕様の抜け漏れ 要件定義を丁寧に行っても、網羅的な仕様書を作成することは本質的に難しいタスクです。業務の細部・例外処理・稀にしか発生しないケースなどは、実際に使って初めて「定義されていなかった」と気づくことが多くあります。

Point 01

完成後のシステムを想像しない——動かして確認する

「こういうシステムを作りたい」という認識が発注者とベンダーで一致しているか、文書だけで確認することには限界があります。認識のすり合わせには、実際に動くプロトタイプを使うことが最も確実です。

完全型プロトタイプ——実データを扱いながら業務フローを一通り試せる試作システム——を開発前に構築し、関係者全員で操作することで、文書の解釈のずれや仕様の漏れを開発着手前に解消できます。

Point 02

現場担当者を早期に巻き込む

業務システムを毎日使うのは現場の担当者です。発注担当者（経営者・管理部門）と現場担当者では、システムに対して異なる視点と優先順位を持っています。両者の観点が揃って初めて、使えるシステムの要件が定義できます。

プロトタイプを使ったPoCでは、現場担当者が実際に操作するセッションを設けることが重要です。「発注側の代表者が触って問題ない」という判断だけでは、現場での使いやすさは保証されません。

できれば企画段階、遅くても要件定義フェーズで巻き込むようにしましょう。

Point 03

スコープを絞り込み、段階的に拡張する

最初から全機能を詰め込もうとすることが、開発の複雑化・コスト超過・遅延の主な原因になります。業務システムの開発では、最初のリリースは「コアとなる業務フローが回ること」だけに絞り込み、追加機能は運用しながら段階的に加えていく方針が現実的です。

プロトタイプを活用した場合、PoCの段階で「必須機能」と「あると良い機能」の区別がつきやすくなります。使ってみて初めて「これは実は必要ない」「こちらの方が優先度が高い」という判断が生まれるためです。

Point 04

発注先の選定は「技術力」だけで判断しない

業務システムの開発成功には、技術力と同じかそれ以上に「業務理解力」と「コミュニケーション能力」が重要です。どれだけ優れた技術者であっても、発注者の業務を深く理解していなければ、使える業務システムは作れません。

選定の際は、実績・技術スタック・価格に加えて「要件定義の進め方」「プロトタイプを活用するか」「業務理解のための工程があるか」といった観点で評価することを推奨します。

Point 05

「完成」をゴールにせず、「定着」をゴールにする

業務システムは、リリースして終わりではありません。現場での定着・業務効率化の実現・継続的な改善の積み重ねが、導入の本当の成果です。開発段階から「使われ続けること」を意識した設計と、リリース後の改善体制を整えることが重要です。

そのためにも、開発前のPoC段階で現場担当者が前向きにシステムに関与する経験を持つことが、定着への布石になります。自分たちが検証に参加して意見を反映したシステムは、押しつけられたシステムよりも受け入れられやすくなります。

How we work

Alcogyのアプローチ：プロトタイプファースト

Alcogyのシステム開発は「プロトタイプファースト」を基本方針としています。開発の前段として完全型プロトタイプを構築し、PoC（概念実証）を実施することで、要件の精度を高めてから本開発に入ります。

システム企画・PoCフェーズ（2〜3ヶ月）では、完全型プロトタイプを使って業務フロー・UX・要件の抜け漏れを検証します。このフェーズの成果物として発注先フリーな仕様ドキュメントを納品するため、Alcogyに開発を依頼することも、別のベンダーへ発注することも可能です。

本開発フェーズでは、PoC済みの精度の高い要件をもとに開発を進めるため、手戻りのリスクを大幅に低減した状態でスタートできます。