システム開発の流れ

なぜ最初に話をするのか

同じ「受発注システムを作りたい」という相談でも、二重入力を減らしたい場合と、注文の進み具合を知りたい場合では、必要な仕組みが変わります。最初に目的や背景を確認すると、機能の話だけに偏らず、解決したい課題に沿って検討できます。

相談では、どんなことを伝えるのか

まず、事業の内容と、対象となる業務を伝えます。架空の受発注業務の例なら、「営業担当が注文をExcelに入力し、倉庫にメールで送っている」「修正のたびにファイルを送り直している」といった説明で十分です。

そのうえで、「転記を減らしたい」「最新版がわからなくなるのを防ぎたい」など、困っている場面を共有します。発生する頻度や影響がわかれば、課題の大きさも伝わりやすくなります。

時期や予算は、決まっている範囲で共有する

「繁忙期が始まる前に使いたい」「まずは一部の部署で試したい」といった条件も、進め方を考える材料になります。期限がある場合は、その理由も伝えると優先順位を考えやすくなります。

予算が未定であれば、そのまま伝えて構いません。現時点で決まっていることと、提案を受けて検討したいことを分けて共有します。

資料は、手元にあるものから

現在使っている帳票、画面、業務の説明資料などがあれば、話の助けになります。相談のために新しく仕様書を作る必要はありません。資料を見せる場合は、機密情報や個人情報を含まない見本にするなど、共有できる範囲にも配慮します。

この段階で、何が整理されるのか

相談したい業務、改善したいこと、主な制約、詳しく確認する事項を整理します。ここで機能や価格をすべて確定するのではなく、次に何を調べ、誰の話を聞くかを明らかにします。

お客様には、現状と希望をお聞かせいただきます。システムの構成や使う技術は、相談の前に決めておく必要はありません。

なぜ業務から整理するのか

個々の作業だけを見ると便利そうな機能でも、前後の仕事とつながらなければ手間が残ることがあります。受発注の例では、注文を入力しやすくしても、倉庫が別のExcelに転記していれば、二重入力はなくなりません。関係する人と情報の流れを確認することで、改善すべき場所が見えてきます。

この段階で、何が整理されるのか

対象の業務と利用者、解決したい課題、機能の候補、優先順位、制約、未確定事項を整理します。お客様には、業務上の重要度や、今回どこまでを目指すかの判断に関わっていただきます。詳細な入力条件や画面仕様は、この大枠をもとに要件定義・設計で具体化します。

見積もりでは、何が金額に影響するのか

システムの費用は、画面の数だけでは決まりません。処理の複雑さ、他のシステムとの連携、データ移行、求められる性能や運用条件などによって、必要な作業が変わります。

受発注の例でも、注文を登録・検索するだけの場合と、既存の在庫システムから情報を取得し、出荷後に会計へ連携する場合では、確認や開発の範囲が異なります。

概算と、条件を具体化した見積もりの違い

初期段階の概算は、現時点の情報と仮定をもとに、費用の規模感を判断するためのものです。詳細な要件を確認した結果、必要な作業が増減し、金額が変わる場合があります。

情報が足りないときは、調査や要件定義を先に契約し、その結果をもとに開発の見積もりを作る進め方もあります。要件定義を必ず契約前にすべて終える、という順序に限られるものではありません。

提案書・見積書で確認すること

まず、対象となる機能や作業、納品されるものを確認します。画面開発だけでなく、環境の準備、データ移行、操作説明、リリース支援などが含まれるかも確認します。

次に、前提条件と対象外の作業を見ます。お客様側で用意するデータや、別会社の協力が必要な連携などは、準備の遅れが日程に影響することもあります。

サーバーや外部サービスの利用料、保守費用など、開発後に必要となる費用についても、開発費とは分けて把握しておくと判断しやすくなります。

契約では、仕事の進め方もそろえる

費用と納期に加え、成果物、支払いの条件、確認・検収の方法、仕様変更の扱い、保守の範囲などを確認します。契約の形式によって、何を約束し、どのように作業や成果を確認するかも異なります。

不明な表現があれば、実際の場面を想定して説明を求めましょう。「途中で要望が増えたら、どう相談するか」などを確認すると、進め方を理解しやすくなります。

この段階で、何が決まるのか

着手する業務の範囲、成果物、費用、進行上の条件をそろえます。お客様には、予算や目的との整合、社内の承認、担当者や協力体制の確認を行っていただきます。未確定事項が残る場合も、その扱いを明確にしてから次へ進みます。

なぜ要件定義が必要なのか

同じ「注文を管理する」という言葉でも、「一覧で見られればよい」「変更履歴を残したい」「承認を受けてから出荷したい」では、必要な機能が変わります。

曖昧なまま開発すると、必要な作業ができなかったり、後から機能を追加して費用や日程が変わったりすることがあります。要件定義は、認識の違いを早い段階で見つけ、優先すべきことを決めるために行います。

要件定義から設計へ

要件定義で実現することをそろえた後は、画面の構成、データの持ち方、処理や連携の仕組みなどを設計で具体化します。必要に応じて両者を行き来し、実現方法と業務上の要望をすり合わせます。

この工程で、何がまとまるのか

案件に応じて、業務フロー、機能一覧、画面案、データ項目、権限、対象範囲、確認条件などをまとめます。資料の形式より、関係者が同じ内容を確認できることが重要です。

お客様には、業務上の判断や優先順位、現場で使えるかの確認に関わっていただきます。技術的な構成を一人で決める必要はありません。見積もりの前提が変わる場合は、費用や日程への影響も確認してから開発に進みます。

開発では、どのような作業をするのか

画面を作るほか、入力されたデータを保存する処理、条件に合う情報を検索する処理、外部システムとの連携などを実装します。画面に現れない仕組みも、システムを動かすために必要です。

架空の受発注業務の例なら、注文入力の画面、注文を保存する処理、担当者ごとの閲覧・編集制御、倉庫向けの一覧などを作ります。要件に応じて、通知や変更履歴なども実装します。

なぜ開発途中の共有が必要なのか

文章や画面案では気づかなかったことが、実際に動かして初めてわかる場合があります。入力の順番、情報の見つけやすさ、作業のつながりなどを確認する機会があると、完成像のずれを早めに見つけやすくなります。

開発方法によって、機能ごとに確認する場合や、一定の範囲がまとまってから確認する場合があります。確認するタイミングや対象を共有して進めます。

開発側のテストでは、何を確かめるのか

まず、個々の処理が想定どおりに動くかを確認します。例えば、必須項目が空欄のときに登録を止める、数量を変更すると金額が更新される、といった動作です。

次に、機能同士のつながりを確認します。登録した注文が倉庫の一覧に表示されるか、出荷状況を更新すると関連画面にも反映されるかなどを確かめます。

必要に応じて、性能や外部連携など、合意した条件についてもテストします。確認内容は、システムの用途やリスクに応じて検討します。

追加の要望が出たら、どうするのか

まず要望を共有し、当初の範囲との違いを確認します。費用や日程への影響を踏まえて、今回対応するか、他の機能と入れ替えるか、次の開発に回すかなどを判断します。

すでに作った部分の変更は、関連する処理やテストにも影響することがあります。小さく見える変更でも、実施前に影響を確認することが重要です。

この工程で、何を確認するのか

実装した機能とテストの状況、未解決の課題、お客様に確認いただく事項を整理します。お客様には、業務上の質問への回答や、共有された画面・動作の確認をお願いします。プログラムの中身を調べるのではなく、想定する仕事の進め方と合っているかを確認いただきます。

なぜお客様による確認が必要なのか

開発側のテストは、仕様に沿って機能が動くかを確認するものです。一方、お客様による受入テストでは、業務の流れに沿って使えるか、必要な情報や結果が得られるかを確認します。

仕様どおりに動いていても、実際の担当者が見ると、作業上の前提が伝わっていなかったことに気づく場合があります。業務を知る方の視点が重要になります。

確認する人と、場面を準備する

管理者だけでなく、日常的に操作する方にも参加いただくと、現場の使い方に沿って確認できます。どの担当者が、どの機能を、いつまでに確認するかを決めておきます。

確認用のデータやアカウントも準備します。実際の個人情報や機密情報を使う必要があるかは慎重に判断し、見本のデータで確認できる範囲を検討します。

具体的には、どのように確認するのか

架空の受発注業務の例なら、営業担当が注文を登録し、倉庫担当が内容を確認し、出荷状況を更新するまでを一通り操作します。各担当者が必要な情報を確認できるかも見ます。

通常の流れに加えて、数量変更、取り消し、入力の不足など、要件定義で整理したケースも確認します。帳票や集計がある場合は、表示されるだけでなく、数値や内容が期待する結果と合っているかを確かめます。

気になる点は、再現できる形で共有する

問題があったときは、操作の順番、期待した結果、実際の結果を記録します。画面や時刻、使用した確認データなども、原因を調べる手掛かりになります。

そのうえで、合意した仕様と異なる動作なのか、仕様の認識がずれているのか、新たな要望なのかを整理します。必要な修正後は、該当する操作をもう一度確認します。

検収では、何を判断するのか

契約で定めた成果物や確認条件をもとに、納品内容を確認します。残る事項がある場合は、その内容、業務への影響、対応方法を共有し、契約に沿って扱います。

確認結果や対応事項を記録しておくと、リリースの判断や、その後の運用にもつながります。受入テストや検収、リリースの順序・区切りは案件によって異なるため、あらかじめ進め方をそろえておくことが大切です。

なぜリリースの準備が必要なのか

確認用の環境で動いたシステムを、そのまますぐに使えるとは限りません。実際のアカウント、ネットワーク、外部サービスとの接続など、本番環境で必要な設定や確認があります。

現場の担当者が新しい仕組みを使える状態にすることも重要です。システムを公開する作業と、業務を始めるための準備をあわせて進めます。

この工程で、何がまとまるのか

利用開始日、実施する作業、担当者、確認方法、問題発生時の連絡・判断の流れを整理します。移行の手順や操作案内などは、必要に応じて用意します。

お客様には、業務上の切り替え判断、利用者への案内、移行データの確認などに関わっていただきます。どちらが何を準備するかをそろえ、必要な確認を終えてから利用を開始します。

保守と運用では、何を行うのか

一般に、保守では不具合の調査・修正や、ソフトウェアの更新など、システムの状態を維持するための対応を行います。運用では、アカウントの管理、データの確認、問い合わせへの対応など、日常的に使い続けるための作業を行います。

ただし、呼び方だけで対応範囲は決まりません。開発会社とお客様のどちらが担当するかも含め、具体的な作業ごとに確認することが大切です。

なぜリリース後の対応を決めておくのか

利用者やデータ量が増えたり、連携先のサービスが変わったりすると、当初は問題がなかった部分にも対応が必要になる場合があります。

架空の受発注業務の例なら、担当者の異動による権限変更、取引先の追加、繁忙期の処理増加などが考えられます。困ったときに誰が判断し、どこへ相談するかを決めておくと、状況を整理しやすくなります。

保守契約で確認すること

対象となる機能や環境、問い合わせ窓口、受付時間、費用、対象外の作業などを確認します。障害の調査や修正、更新作業、バックアップの確認などが、どこまで含まれるかも見ておきます。

問い合わせへの初動と、原因の特定・復旧にかかる時間は同じではありません。必要な対応水準を業務への影響とあわせて検討し、契約内容を確認します。

不具合や困りごとが出たとき

発生した時刻、操作、表示内容、影響を受ける業務などを整理して共有します。毎回起きるのか、特定の担当者だけなのかといった情報も、原因を調べる手掛かりになります。

原因がシステム本体、通信環境、外部サービス、操作などのどこにあるかで、対応する相手が変わることもあります。まず事象を共有し、調査や対応の範囲を確認します。

現場の声を、次の改善につなげる

使い始めてから、「検索条件を増やしたい」「入力をまとめて行いたい」といった要望が出ることもあります。要望を集め、利用頻度、業務への影響、費用などを踏まえて優先順位を考えます。

お客様には、困っている場面や業務の変化をお知らせいただきます。保守に含まれる対応か、追加開発として検討する内容かを確認し、必要に応じて見積もりや仕様の整理につなげます。