非IT系スタートアップ代表Bさんの成功物語:開発会社選定から納品までの舞台裏

事例概要:スタートアップY社と代表Bさんの背景
Y社代表のBさんは、元々飲食業界で店舗運営を行っていた非IT系起業家です。顧客管理や予約管理を手作業で行ううちに業務が肥大化し、「システム 開発会社 選び方」すらイメージできないまま、社内SEとしても未経験の状態でプロジェクトを立ち上げました。限られた人員で最大限の効果を狙うべく、「予算」「費用 相場」を押さえつつ、まずは現状課題の洗い出しから着手。発注後に失敗しないよう、Bさんは自ら学びながら戦略を練り上げていきました。
プロジェクト発起:課題認識と初期ゴール設定
Bさんが最初に行ったのは、紙とExcelで行っていた予約管理の工程を可視化し、どの部分をデジタル化すべきかを明確にすることでした。以下のようにゴールを設定しました。
-
月間予約数の10%アップを実現する仕組み構築
-
顧客接点のデータを一元管理し、リピート率を20%向上
-
初期「予算」は300万円以内、リリースまで半年以内
これらのゴールを社内で共有し、「発注」前の基準を固めることで、開発会社との認識ずれを最小限に抑えました。
開発会社リサーチと評価軸
Bさんはまず、複数のシステム開発会社をWeb検索と知人紹介でリストアップし、独自の評価軸を設定しました。主な評価項目は以下のとおりです。
-
実績・事例:同規模スタートアップ支援経験の有無
-
技術力:使用フレームワークや独自ツールの保有状況
-
コミュニケーション:レスポンスタイムや日本語対応の質
-
費用透明性:見積もり内訳の開示レベル
これらの基準で各社をスコア化し、上位3社をヒアリング対象に絞り込みました。
見積もり比較と予算交渉のコツ
見積もりを比較する際は、単に総額を見るのではなく「工数×単価」の分解が不可欠です。Bさんが実践したコツは以下の通りです。
-
共通フォーマット依頼:フェーズごとに内訳を揃える
-
前提条件明示:除外項目や想定を文書化して齟齬を防止
-
予算上限設定:必要な機能とリザーブ予算をあらかじめ提示
これにより、A社300万円、B社350万円、C社280万円という提示額のうち、最終的にC社に絞る判断材料が整いました。
契約形態の決定と発注プロセス
要件確定度合いを踏まえ、Bさんは「固定価格+追加工数上限設定」のハイブリッド契約を選択。こうすることで、基本機能は定額で抑えつつ、要件変更時のリスクを限定的に管理できます。契約書には以下を盛り込みました。
-
主要マイルストーン:要件定義完了、設計完了、開発完了、検収完了
-
追加工数上限:全体工数の15%以内
-
検収基準:不具合件数および処理速度の明文化
このプロセスにより、発注後の「予算」増大リスクを低減しました。
キックオフ:チーム編成とコミュニケーション設計
プロジェクト開始時にはY社と開発会社C社のキックオフを実施。参加メンバーは以下の通りです。
-
Bさん(プロジェクト責任者)
-
社内SE兼PM役1名
-
C社側プロジェクトマネージャー
-
フロントエンド/バックエンド各担当エンジニア
コミュニケーションはSlackで専用チャンネルを立ち上げ、週次定例会は必ずオンライン参加必須とし、議事録も自動で共有。こうしたルールを初期段階で定めたことで、進捗報告と迅速な意思決定が可能になりました。
要件定義の初期トラブルと改善
キックオフ翌週、Bさんは早速要件定義レビューでつまずきました。用語の解釈違いにより、「予約ステータス切替」の仕様が曖昧になり、画面設計が二転三転。失敗から以下の教訓を得ました。
-
業務フロー図の重要性:実際の操作手順をフロー図で可視化
-
サンプルデータ共有:入力例や想定ケースをExcelで事前提供
-
仕様レビューチェックリスト:画面毎に確認項目をリスト化
これらを追加し、以降の要件定義では一度も大きな仕様変更が発生しませんでした。
開発進捗管理と品質チェック
開発フェーズでは、日々の進捗と品質を以下の方法で管理しました。
-
ガントチャート更新:マイルストーンと実績を週次で比較
-
QA環境レビュー:ステージング環境で週次で機能動作確認
-
バグトラッキング:Jiraを用い、優先度と工数見積もりを可視化
これにより、想定外の遅延や追加コストを発生前に察知し、都度調整を行う仕組みが整いました。
テスト・検収フェーズの戦略
テスト・検収は開発会社からの「納品」をスムーズに受け入れるための要です。まず、テスト項目を機能ごとにリスト化し、受入基準を数値化します。これにより、ベンダーがどこまで完了させれば検収OKなのかが明確になります。
-
ユニットテスト:各モジュールの単体動作を自動化
-
結合テスト:複数機能連携時のデータフローをチェック
-
受入テスト:実際の業務シナリオをベースに担当者が検証
数値化された合格ラインを共有しておけば、「費用 相場」を超えるバグ修正を未然に防ぎやすくなります。
リリースと納品準備
リリース直前には、ステージング環境と本番環境の差分を最終確認します。データベースのマイグレーション手順やロールバックシナリオを文書化し、万一の障害時にも迅速に復旧できるように準備しておきます。さらに、納品物(ソースコード、設定ファイル、手順書、マニュアルなど)を一覧化してチェックリストを作成します。これらの準備を徹底することで、納品後に想定外の追加費用を請求されるリスクを抑えられます。
ユーザートレーニングとサポート体制
新システムの使い方を定着させるため、ユーザートレーニングは必須です。Bさんは社内キーユーザーを集めたハンズオントレーニングを2回実施し、以下のポイントを押さえました。
-
基本操作のデモンストレーションとハンズオン
-
よくあるトラブルのQ&Aと対処フロー
-
サポート窓口と問い合わせ手順の明確化
加えて、FAQページと操作マニュアルPDFを社内ポータルにアップし、初期問い合わせを50%以上削減できたことで、運用コストも大幅に抑えられました。
納品後のフォローアップ・運用定着
納品後1か月は、開発会社とA社の連携を継続し、24時間以内に障害対応ができる体制を整えました。週次で運用レポートを共有し、以下をモニタリングします。
-
障害発生数と対応時間
-
システム稼働率とレスポンスタイム
-
ユーザーからの改善要望
このフォローアップを契約時に予算化しておくことで、追加請求を防ぎつつ、安定運用を実現しました。
プロジェクト振り返りと学び
プロジェクト終了後、Bさんは振り返りワークショップを社内外メンバーと実施し、下記の学びを得ました。
-
要件定義における業務フロー図とサンプルデータの重要性
-
定例ミーティングとコミュニケーションルールの効果
-
追加工数上限設定による予算管理の安定化
-
テスト自動化が長期的なコスト削減につながること
これらの知見は社内テンプレート化し、次回以降の「システム 開発会社 選び方」や「予算」策定にも活かされています。
次への展望とアドバイス
成功体験を踏まえ、Bさんは次のステップとしてAIチャットボット連携機能の開発を計画中です。ポイントは、PoC(概念実証)フェーズを短期予算内で実施し、結果を基に本格開発か否かを判断すること。また、TCO(総所有コスト)を見据え、運用・保守フェーズの費用相場と保守契約を早期に取り決めることをお勧めします。こうした段階的アプローチが、非IT系起業家でも安心して発注できる鍵です。