開発の進め方

私たちは、「作ること」よりも
お客様が納得して判断できることを大切にしています。

このページは、 「システム開発がどのように進むのか不安な方」 「途中で引き返せるのかを事前に知りたい方」 向けに、当社の開発プロセスと考え方を説明するページです。

私たちの開発の基本方針

私たちは、

• 案・仮説・計画をもち
• 試作品や資料、さまざまな代替案など判断材料を提供しつつ
• お客様のレビュー・意思決定を尊重する

という進め方を大切にしています。

システム開発は、「作ること」よりも「判断の連続」 です。

だからこそ、 お客様が納得して判断できる節目・機会を、 意図的に設けています。

全体の流れ（フェーズ概要）

※ 開発ベンダーは、規模に応じて貴社内製／当社のみで進めるケースもあります。 ※ プロジェクトによって工程は分割したり、省略する場合もあります。

フェーズ0：事前相談・ヒアリング

目的

• 目的の理解
• 制約条件の確認（期限・予算・体制）
• 当社の支援範囲の認識あわせ

この段階で行うこと

• 現状の困りごとの共有
• 目的・背景の確認
• ご相談内容の整理

※ 売り込みは行いません。 ※ この段階で終了しても問題ありません。

フェーズ1：初期診断（業務整理）

目的

• 現状業務とその課題定義
• 作らない選択肢も含めて整理する

主な内容

• 現行業務整理・業務フロー整理
• 現行システム・Excel 資産の整理
• ToBe 案・優先順位の整理
• 技術選定の考え方整理
• セキュリティ観点の整理
• 新システムに向けたロードマップ（たたき台）
• RFPドラフト（提案依頼書たたき台）

このフェーズの特徴

• 固定価格
• 成果物を残す
• 次に進まない判断も OK

フェーズ2：PoC / 小規模試作

目的

• 実際に触って業務が回るか判断する
• 言葉にできない要件を見える化する
• システム化対象業務、技術方式の確定

主な内容

• 重要部分の試作および評価
• 新業務フローの確定
• 画面イメージ作成
• 操作フロー確認
• データ構造の検討
• 技術方式（方式設計）の承認

このフェーズの特徴

• 小さく作る
• 気づきを要件に反映する
• 方向性を明確にする
• 継続・縮小・中断を判断する

フェーズ3：本番開発

目的

• 業務で使える状態に仕上げる

主な内容

• 機能拡張・バッチ組込
• 権限・セキュリティ設計
• テスト・受入支援
• 運用設計
• 現行システムからのデータ移行

契約形態

• 当社では、試作や要件整理を伴うアジャイルな進め方を前提としているため、準委任型を推奨しています。
• 仕様が確定しており、成果物の範囲・品質基準が明確な場合に限り、プロジェクト型（準委任 成果物型）での対応が可能です。

フェーズ4：段階的リリース・運用

目的

• 安全に使い始める
• 業務に定着させる

主な内容

• 旧→新へのデータ転送による低負担並列稼働
• 本番カットオーバー支援（切り戻し・自動検証）
• 初期運用フォロー
• 問題点の洗い出し

フェーズ5：保守・内製化支援（任意）

目的

• 長く使える状態を保つ
• 自分たちで改善できるようにする

主な内容

• ローコード内製化レビュー
• 設計・品質レビュー
• 詰まりポイント相談
• 保守・運用の伴走支援
• セキュリティパッチ対応
• バックアップ・リストア訓練

「途中でやめられる」について

私たちは、

途中でやめられることは、失敗ではない

と考えています。

• 目的が変わった
• 優先順位が変わった
• 今は作らない判断をした

これらは、 正しい判断の結果です。

その判断ができるように、 フェーズごとに区切りを設けています。

お客様と当社の役割分担

お客様にお願いすること

• 業務内容の共有
• 現場の声の橋渡し
• 提案された内容のレビュー・承認

当社が担うこと

• 整理・設計
• 技術選定・提案
• 計画・進行管理
• 成果物の作成・実装

よくある不安について

Q. 途中で方向転換できますか？

はい。可能です。 そのためのPOCやローコード開発です。 むしろ、早めの方向転換を歓迎しています。

Q. 途中で止めた場合、何が残りますか？

各フェーズの成果物が残ります。 判断材料として、社内で活用できます。