【導入事例 Vol.2】「RFPなし」から始まった開発。なぜ予算オーバーしても「GO」が出たのか？

2026年3月30日導入事例

SaaSが適合しないなら、残る道は「カスタマイズ開発」しかない。しかし、一般的にカスタマイズ開発は「コストが高い」「期間が長い」「失敗のリスクがある」と敬遠されがちだ。

特に今回の場合、明確な要件定義書（RFP）も業務フローのドキュメントも存在しない状態から開発をスタートさせる必要があった。1,000万円超の案件でRFPがないというのは、通常であれば他のベンダーが尻込みするレベルの話だ。第2回は、TECHNOPIAN株式会社（以下、テクノピアン）がいかにしてこの難題を乗り越え、顧客が「予算を追加してでも欲しい」と思えるシステムを作り上げたのか、その開発プロセスをに迫る。

TechnoSMS編集部

「業務をシステムに合わせるのではなく、業務のためのシステムを作る」が信条。数十社以上の導入指揮経験を活かし、徹底した要件定義によって、スクール独自の複雑な運用ルールを最適なシステムにする過程をお伝えします。

「会場主体」というコロンブスの卵

前回の記事で触れた「大きな箱への詰め放題パズル」。既存のスクール管理システムが「コース（科目）」を主語にしているのに対し、テクノピアンが出した答えはシンプルかつ大胆だった。「会場」を主語にしてシステムを組み替える。

つまり、「何月何日の○○会議室」という「箱」をデータベースの起点に置き、その中に各種試験をパズルのピースのように埋め込んでいく構造だ。こうすれば、試験ごとの人数比率がどう変わろうとも、箱全体の定員を超えない限り、システムは受け付けを継続できる。1席の無駄も出さず、機会損失をゼロにする。

言われてみれば当たり前のことだが、パッケージ製品の制約に縛られていた思考からは、この「コロンブスの卵」的な発想の転換が出てこなかったのだ。

ただし、この発想の転換には大きな副作用があった。TechnoSMSの標準仕様は通常のスクール管理と同じく「コース主体」の設計だったため、そのまま使うとマスターデータの登録ステップが倍以上に膨れ上がるのだ。標準システムでは、コースごとに資格の紐づけ、スケジュール設定、会場設定…と個別に登録していく必要がある。旧システムでは28ステップで済んでいた作業が、標準機能のままでは55ステップ以上に膨らんでしまう。しかもこれは控えめな見積もりだった。

テクノピアンはこの問題を要件定義の早い段階で察知した。「このまま進めれば、検索性は改善できても、マスター登録が重すぎて『使えないシステム』と評価されるのは明白だ」と。

そこで開発したのが「コース一括登録」画面だ。会場を選び、その会場で開催する試験や講習会をまとめて設定し、スケジュールや定員もまとめて登録できる。複数のステップを一つの画面に集約することで、運用負荷を大幅に下げた。

「RFPなし」をどう乗り越えたか

今回のケースではRFPも業務フローのドキュメントもなかった。他のベンダーが手を引いた理由はまさにここにある。何をどう見積もればいいのかがわからないのだ。

テクノピアンがとったアプローチは、自ら動いて「ベース」を作ることだった。

まず、お客様よりご提供いただいた資料や画面情報をもとに、旧システムの機能一覧を自ら作成。さらに、ヒアリングをもとに業務フローを起こし、「当社のシステムを使った場合、こういう流れになりますがどうですか？」という形で提示した。営業段階、つまり受注前の持ち出しで、ここまで踏み込んだ対応をしたのだ。

お客様側の感想はこうだ。

テクノピアンとの要件定義は、打ち合わせが多くて、長くて、濃い。最低でも2時間、業務の細部にまで入り込んで聞いてくる。一方、旧システムのベンダーは「御社で資料を作ってください」というスタンスで、課題管理表のやり取りもなかったという。

この対比は極めて重要だ。「要件は顧客が出すもの」というのが業界の常識だが、テクノピアンは「要件を一緒に掘り起こす」という姿勢で臨んだ。結果として、お客様自身も気づいていなかった隠れた課題が次々と浮き彫りになった。

「要件定義書」ではなく「画面で会話する」

通常、システム開発は「要件定義書」という分厚いドキュメントを作ることから始まる。しかし、文字だけの資料で、複雑な業務フローを完全に共有することは不可能に近い。

一方、テクノピアンでは、要件定義の初期段階から画面イメージ（モックアップ）を作成することを原則としている。「この画面で、ここを押すとこう動く」という具体的な体験イメージを共有することで、開発の段階から認識のズレを最小化するためだ。

「あ、ここには受講番号も表示されないと困ります」「ここの一括処理、入金の消し込みと同時にできませんか？」

実際に画面イメージを見ながら対話することで、会議は活性化し、実際の業務に即した様々な意見や、隠れていた要望が次々と溢れ出てくるのだ。

もちろん、要望が増えれば開発スコープは広がり、見積もりは膨らむ。実際、当初の概算見積もりに対し、詳細を詰めた後の最終見積もりは増額となった。

毎日使う機能には徹底的に投資する

しかし、お客様はその増額を受け入れた。なぜか。そこに「納得感のある投資判断」があったからだ。

テクノピアンでは、機能の必要性を“利用頻度”と“業務負荷”の観点から判断する。

たとえば車の窓も、「窓がある」という要件だけを満たすなら手回しでも十分だ。しかし、毎日何十回も操作するのであれば、パワーウィンドウであるべきだ。重要なのは、すべてを豪華にすることではなく、本当に必要な部分に投資することである。

毎日使う機能には徹底的に投資し（パワーウィンドウ）、頻度の低い業務は運用でカバーする（手回しウィンドウ）。

たとえば、法人マスタの変更や法人受講情報の取り込みなど、優先度の低い機能は「運用で対応できる」と判断し、開発対象から外した。一方で、データの一括更新のように毎日の業務負荷に直結する部分は、Excelとの併用機能を実装した。ブラウザ上の画面で、Excelのデータをダウンロード&アップロードして一括登録できる仕組みだ。