ノーコード×カスタム開発で再構築！社内経費精算システム刷新のリアル開発ノート

この開発ノートでは、ある中堅企業が抱えていた社内経費精算システムを「ノーコードプラットフォーム＋カスタムAPI連携」のハイブリッド手法で再構築した事例を、実際の現場感あふれる体験談とともにお届けします。要件定義の曖昧さが追加費用を生んだ失敗談や、ベンダーとの密なコミュニケーションで予算内に収めた成功ポイントなど、開発プロジェクト実務者や技術リーダーの方々が共感しやすい具体例を交えながら解説します。システム刷新における開発会社の選び方、予算策定時の費用相場、発注前に押さえるべき落とし穴など、発注から納品までの流れをリアルに再現しました。

プロジェクト背景と課題意識

当社が従来利用していた経費精算システムは、10年前にオフショアの開発会社へ発注したオンプレミス型。

• データ入力画面が複雑で承認ルート追加時はカスタマイズ費用が高額

• 法改正や会計基準変更への対応が遅れ、運用会社への追加相場が肥大化

• メンテナンス窓口が海外拠点であり、問い合わせから復旧までに時間を要する

これらの運用負荷とコストを解消するため、次期システムでは以下の改善を狙いにしました。

1. UI/UX最適化で操作性を飛躍的に向上

2. ノーコードプラットフォームで自社運用を実現し、発注費用を半減

3. カスタムAPI連携で基幹システムとの自動連携を維持

しかし、当初の要件定義が曖昧だったため、実装工程で追加開発が頻発し、コスト超過の危機に直面しました。以後の節では、そこからどのようにリカバリし、予算・納期を守り抜いたかを具体的に振り返ります。

ノーコードプラットフォーム選定と要件定義の工夫

社内SEチームとプロジェクトマネージャーで、候補プラットフォームを次の観点で比較検討しました。

• 実装スピード：ドラッグ&ドロップで画面遷移とビジネスロジック設計が可能か

• 費用相場感：ユーザー数やデータ量に応じたサブスクリプションモデルの予算感

• カスタマイズ性：開発会社に発注せず自社で拡張できるか

• API連携性能：標準コネクタの有無と個別開発コスト

結果、A社のローコードプラットフォームを選定。決め手は「帳票出力機能の標準搭載」と「主要クラウドDBへの自動バインド」。発注前に「データモデル設計」「ワークフロー承認パス」の2領域だけカスタマイズ要件を洗い出し、残りは自社で定義・構築可能にしたことで、開発会社への外注工数を削減し、発注費用を概算50%カットできました。

要件定義のポイント

1. ユースケースベースのストーリー作成：経費申請から承認、会計仕訳連携までの操作イメージをストーリーボード化

2. スコープを明確化：ノーコード範囲内に収まる機能と必ず外注するカスタムAPI部分を取り決め

3. 予算・費用感の見える化：自社要件に対し「作業時間×単価」で相場見積もりを算出し、ベンダー数社へRFPとして発注

この段階で「要件追加＝追加費用」のルールを明文化したため、その後の仕様変更時もコスト管理がしやすくなりました。

ハイブリッド開発の実践と試行錯誤

プラットフォームの標準UI構築と並行して、基幹システムと連携するAPIをNode.jsで自社実装。ここで直面したのが「ステージング環境とのデータ不整合」と「認証トークン更新タイミングのミスマッチ」。対応策として、以下を取り入れました。

• モックサーバによる早期検証：基幹側連携仕様確定前に挙動を模したモックを用意し、フロント側と同時並行で開発

• リトライ＆バックオフ実装：API呼び出し時のステータスコード別にリトライ回数と待機時間を設定

• CIパイプラインでの自動テスト：GitOps連携でPull Request時にE2Eテストを実行、導入前のトラブルを削減

この試行錯誤フェーズでは開発会社と週次レビューを実施し、進捗遅延・追加開発発生ポイントを早期に共有。予算・スケジュール両面の透明性を担保しました。

コミュニケーションとコスト管理の秘訣

多くのプロジェクトで課題になるのが「リモートチームとのすれ違い」です。本プロジェクトでは以下の工夫で開発会社との齟齬を最小化しました。

• 共同ワークスペース設置：Teams上に要件別チャンネルを立て、質問や仕様検討を文脈とともに蓄積

• デイリースクラム＋デモ実施：朝会＋夕会で当日のToDoと進捗を確認し、週１デモで機能完成度を可視化

• コストバーンダウン管理：残タスクを工数見積もり化し、赤字が近づくとアラートを飛ばすダッシュボードを共有

これにより、見積もり相場感と実際工数の乖離を早期に把握し、発注予算内でプロジェクトを推進できました。

発注契約の落とし穴と回避策

要件定義から見積もりフェーズで最も注意すべきは、契約書に記載する「成果物の定義」と「変更管理プロセス」です。当社は以下のポイントで痛い目に遭いました。

1. 成果物の曖昧な記載

   • 「UI画面」「API連携」とだけ書かれ、具体的な画面数やエンドポイント数が未定義

   • 言葉の解釈違いにより、想定外のカスタマイズが「追加工数」として膨らむ

2. 変更管理ルール不備

   • 「仕様変更は別途見積もり」とだけ記載。変更申請フォームや承認フローが設けられず、口頭依頼が“正規仕様”となってしまった

   • ベンダー側が「承認記録なしでも開発着手＝追加費用請求」の根拠に

3. 予算超過の誘発

   • 変更管理が曖昧なため、相場観を超えた追加費用が頻発

   • 追加予算の社内承認に時間を要し、プロジェクト全体の納期遅延も招いた

回避策として導入したルール

• 成果物リストの明文化：画面名称×想定項目数、APIエンドポイント一覧をRFPに添付

• 変更管理のワークフロー：専用フォームによる申請→PM／事業部長承認→ベンダー見積もり提示、という3段階を契約に盛り込む

• 予算バッファ設定：プロジェクト全体予算の10%を「変更バッファ」として確保し、予算消化率をリアルタイムにモニタリング

これらを徹底したことで、余計な追加工数請求がほぼゼロに抑えられました。

テスト・QAフェーズでのコスト最適化

開発中に発見すべきバグを見逃すと、リリース後の修正費用は開発工程の5～10倍になることもあります。そこで、当社では以下の工夫を行いました。

1. 自動化テストの導入

   • ノーコード画面のE2E自動テストはSeleniumベースで自社開発

   • カスタムAPIはPostman＋Newmanで自動実行

2. テストカバレッジの明確化

   • 「申請画面→承認→帳票出力」など主要ユースケースをテストシナリオ化し、網羅率を算出

   • カバレッジ80%以上を担保し、残り20%はリリース後モニタリングでフォロー

3. バグトリアージと優先順位付け

   • 全バグを「重大度」「影響範囲」「再現性」の3軸でランク付け

   • 緊急度高の修正だけを開発会社に早急に依頼し、軽微なものはリリース後パッチで対応

この自動テスト＆トリアージ体制により、QA期間中のバグフィックス工数を30%削減し、予算内に収めることができました。

運用移行の成功ポイント

本番リリース前後には「運用移行」が最大の山場。当社が重視した点は下記です。

• 移行リハーサルの実施

  • オフピーク時に本番DBのサンドボックスを作成し、データ移行スクリプトの検証

  • 移行中のダウンタイム想定とコミュニケーションプランを事前共有

• ユーザートレーニング

  • キーマン向けワークショップを3回開催し、画面操作とトラブル想定をハンズオンで教育

  • FAQ集とショート動画マニュアルを用意し、社内ヘルプデスク負荷を軽減

• 切り戻し（ロールバック）手順整備

  • 移行失敗時に旧システムへ切り戻す手順をリスト化、PMO主導でテスト

  • 切り戻し発動基準を明確化し、決断遅延を防止

結果として、移行作業は予定ダウンタイムの60%で完了し、運用開始初期のサポート費用も当初見込みを大幅に下回りました。

利用状況のモニタリングと改善サイクル

リリース後は「継続的改善」が鍵。以下の仕組みを導入しました。

• 利用ログの可視化

  • 申請件数、承認遅延時間、エラー頻度などKPIをダッシュボード化（Tableau連携）

• ユーザーアンケートの定期実施

  • 1ヵ月／3ヵ月ごとにIT部と部門責任者へのアンケートを実施

  • フィードバック結果をバックログ化し、スプリントプランに組み込み

• 月次レビューとPDCA

  • 月初に「改善策実績」「未解決課題」「新規要望」を整理

  • QA／PMOチームとビジネス部門で優先付けし、次の1スプリントで対応

これにより、導入初年度で利用定着率は95%超、運用コストは旧システム比で約40%削減を達成しました。

スケールアウト計画と予算見直し

業務拡大に伴い、システム利用ユーザー数やデータ量はリリース後も増加します。スケールアウトに向けたポイントは下記です。

• クラウドリソースの動的アロケーション

  • サーバレスアーキテクチャ（AWS Lambda＋Aurora Serverless）でピーク対応

• 費用シミュレーション

  • ユーザー数増大シナリオを作成し、予算感を四半期ごとにアップデート

• 開発予算の再配分

  • 初期バッファ分の予算を「次期機能強化」に回し、新規開発会社への相場観を調整

こうした先を見据えた予算管理が、相場変動に柔軟に対応する秘訣です。

ナレッジ共有と自社内運営体制の強化

長期的なシステム運営には自社技術者育成が不可欠。以下を実践しました。

• 社内Wikiの整備

  • 設計資料、API仕様、運用手順書をConfluence上に集約

• ペアプログラミング制度

  • 開発会社エンジニアと社内SEがペアでバグ修正にあたり、ノウハウを移転

• 定期的な勉強会開催

  • 新機能リリース後にライトニングトーク形式で情報共有会を実施

これにより、発注先への依存度を下げ、内製化率を70%まで向上できました。

総括と今後のロードマップ

本プロジェクトを通じ、以下の教訓を得ました。

• 要件は定義し尽くすほどコストを抑えられる

• 変更管理とテスト自動化は投資対効果が高い

• 運用フェーズのKPIモニタリングが改善サイクルの原動力

次フェーズでは、

1. モバイルアプリ連携による申請UX強化

2. AIレシート読み取りの自動化

3. 海外拠点対応の多言語化

をロードマップに据え、予算・相場感を加味しつつ、引き続き「ノーコード×カスタム」のハイブリッド手法でスピード感ある開発を目指します。