丸投げ開発がもたらす悲劇の現場
長年、システム開発会社の人間として多くのフルスクラッチ開発現場に携わってきました。その中で、痛感させられる悲しい現実があります。それは、発注元企業の多くが意図せずして仕様策定を「丸投げ」にしてしまっているという事実です。
プロジェクトが始まると、顧客から「社内規定を見ておいて」「既存システムを解析して同じものを作って」「この手順書を読んでおいて」と大量のドキュメントを渡されます。発注側の意図としては親切心や情報共有のつもりかもしれません。しかし、システム開発の観点から言えば、これは「自分たちでも整理できていない業務を、そのまま丸投げしている」状態に過ぎないのです。
結果として何が起きるか。開発が進んでから「実はあの計算ロジックが違う」「この画面では現場の運用が回らない」といった手戻りや変更要求が次々と噴出します。修正が増えれば納期は遅れ、追加費用は跳ね上がります。お互いに時間と予算を浪費し、最終的には「高い金を払ったのに使いにくいシステム」「引き受けたものの利益が出ないプロジェクト」となり、発注元も開発企業も双方が損をする悪循環に陥ってしまうのです。この光景を、私は何度も見てきました。
要件定義の常識を捨て、まずExcelを開け
「自社主導で仕様を固める」と言うと、多くの方は難しいシステム要件定義書や複雑な業務フロー図を作成しなければならないと考えがちです。しかし、専門的なドキュメントを目指す必要はありません。
私が提案したい最もシンプルで強力な手順、それは「まず自社でExcelを開き、実際のデータを打ち込んでみること」です。「専門的なフルスクラッチシステムを作るのに、なぜExcelなのか？」と疑問に思われるかもしれません。しかし、これこそが丸投げを防止し、自社主導で仕様を完璧に固める最強のツールなのです。
手始めに、自社で日常的に扱っている現場のデータ（顧客情報、受注データ、商品マスターなど）をExcelに一部入力してみます。すると、「そもそもこの業務を開始するにはどのデータが必須なのか」が明確になります。データを打ち進めると、「このデータとあのデータを組み合わせなければ、目的の請求書や分析数値が出力できない」ということに気づきます。不足している要素を補うためにシートを追加していくと、「取引先シート」「受注履歴シート」「商品価格シート」といった形で、必要なデータの種類に応じてExcelのシートが自然と増えていきます。
Excelの構造はデータベースそのものである
実は、このExcel上で作り上げた構造こそが、そのままシステム設計の根幹（アーキテクチャ）になります。
具体的に言えば、増やしていったExcelの「シートの数」は、システム内で管理すべき「データベースのテーブル（データの種類）」に直結します。そして、シート内に並べた各列の見出し（カラム名）は、そのまま「データベースのカラム（項目）」に相当します。データの桁数や日付の形式、必須項目かどうかといったフォーマットまで、Excel上で入力欄を作ることで自ずと定まります。
計算式こそが業務ロジックの正体である
さらに決定的なのは「計算式」の存在です。
「どのセルの値とどのセルの値を掛け合わせ、どう割り引いて、端数をどう処理し、税金を計算して帳票のこの枠に出力するか」。Excelのセル内に組まれた数式は、システム開発で言うところの「業務（ビジネス）ロジック」そのものです。
Excel上で「データの入力・参照・計算・帳票出力」までの一貫した整合性が取れていれば、システム化はほぼ100%成功します。仕様の曖昧さが排除され、業務の仕組みが目に見える形で可視化されているからです。
ベンダー頼みを脱却し、確実に成功へと導く
ここまでExcel上でデータ構造、業務ロジック、帳票出力の一貫性が組み上がっていれば、あとはプログラミング言語を用いてWebシステムやアプリへと構築し直すだけです。これは単なる技術的な置き換え作業であり、開発ベンダー側でロジックの解釈違いや迷いが生じる余地がありません。管理すべきデータも計算式も明確になっているため、開発において失敗しようがないのです。
要件定義をITベンダーに丸投げしても、自社の業務の本質や計算ロジックを最も深く理解しているのは自社の社員です。フルスクラッチ開発を検討している経営者や事業責任者の皆様には、まず社内でExcelを開き、データと計算式、そして帳票を再現することから始めてみてはいかがでしょうか。
自社主導でここまで整理する手順を踏めば、フルスクラッチ開発はもちろんのこと、将来的なパッケージシステムの選定や適用範囲の判断においても、迷うことのない強固な指針となるはずです。