1．システム開発の発注準備

システム開発の発注準備では、以下の3点を事前に行う必要があります。

システム開発の依頼背景や目的を明確にする

• 開発したいシステムの概要をまとめる
• システムを開発したいきっかけ
• 解決したい課題

システムにどのような機能を求めているか

• システム開発会社の選定
• 目的のシステムに近い開発実績があるか
• コミュニケーションが円滑にとれるか
• 見積もりは相場から離れていないか

契約形態の確認と依頼業務の明確化

• 請負契約or準委任契約の選定
• 依頼業務の明確化

発注前の準備が不足していると、トラブルの原因となります。入念な準備を行いましょう。

2．提案依頼書（RFP）の作成

RFP（Request for Proposal）とは、システム開発会社に対して提案を求める文書のことです。RFPには発注者側の要求事項を詳細に記載することが求められます。具体的には以下の情報を含む必要があります。

• プロジェクトの背景や目的
• 現在抱えている課題
• 会社情報
• システム構成
• 機器情報
• 開発対象システムの概要
• 要件定義（機能要件、非機能要件など）

など

RFPを適切に作成することで、システム開発会社に発注者の真のニーズを的確に伝えられ、適切な提案を受けやすくなります。

3．オリエンテーション（要件ヒアリング）

オリエンテーションはRFP（提案依頼書）を開発者に説明するプロセスです。発注側が提示したRFPの内容を、開発者に対して詳しく説明します。

複数の開発者に見積もりを依頼する場合は、各社に対して共通のRFPを用いて説明を行います。これにより、打ち合わせの内容にばらつきが出るのを防ぐことができます。

開発者の選定に当たっては、見積もりの金額だけでなく、RFPに対する提案内容も比較検討するようにしましょう。適切な開発者を選ぶためにも、このオリエンテーション段階が重要となります。

4．見積もり評価と発注先の選定

複数社から見積もりの返信が来たら、次は見積もり内容を評価します。評価の方法は以下を参考にしてください。

• 着手から納品までの期間が明確になっているか
• 金額や工数の数字が妥当であるか
• 提案力があるか
• 責任の範囲が明確になっているか
• トラブルに対する対応が含まれているか

その他、見積もり内容について曖昧なまま発注し開発を進めてしまうと、見積もり内容と大きくずれてしまったり、そもそも前提条件の認識があっておらずやり直しになったりする危険性があります。わからない項目があった場合は、必ず質問をしましょう。

5．契約

見積もりの評価が完了したら、いよいよ発注作業に移ります。発注作業は以下の工程で進めていきます。

• 1．契約前のチェック
• 2．契約書の作成
• 3．契約書の締結

特に契約前には、プロジェクトのビジョンや各担当者の認識に不一致がないかなど、チェックリストを参考に確認していきます。自社にひな形がない場合は、IPAで入手できる「契約前チェックリスト」を活用するとよいでしょう。

チェックリストにある項目を確認せずに契約を締結してしまうと、担当者同士の認識が不一致なままプロジェクトが遂行され、失敗するリスクが高くなるため、入念に行いましょう。

期待する成果が得られない

自社の業務に必要な機能やプロセスが十分に渡らず、完了したシステムが使いにくい、あるいは期待する効果が得られない可能性があります。

追加費用や手戻りが発生

要件不明確さが原因で、後から修正や追加開発が必要となり、予算やスケジュールが大幅に超過する恐れがあります。

発注元と開発者の認識のズレ

開発者が自社の業務や課題を正確に理解できず、必要なコミュニケーションが不足していることで問題が拡大する懸念があります。

システム開発は、自社の業務を深く理解している発注元に積極的に関与していただくことが必要です。事前に目的や要件を整理し、発注後も適切なコミュニケーションを行う準備によって、スムーズなプロジェクト遂行と満足のいくシステム導入につながります。

誰に聞く？

システムを使う人全員にヒアリングするのが理想ではあるものの、まずは各部門の代表者や、業務に詳しい人に話を聞いてみましょう。

何を聞く？

• 現状の課題：今、どんなことで困っていますか？
• やりたいこと：システムで何をしたいですか？
• 期待すること：システムに何を期待しますか？
• 困っていること：システム導入で不安なことはありますか？

1．要件定義

要件定義とは、開発するシステムの目的や機能要件、非機能要件などを明確にする工程です。ここでは「なぜシステムを作るのか」「どのような機能が必要か」といった要件を文書化し、発注側と受注側の認識のずれを小さくします。

要件定義は以下の3つの作業で構成されます。

• 要件の収集
• 要件の分析
• 要件の明確化

要件定義書を作成することで、受注側は発注側の期待するシステムを確認でき、効率的な開発が可能となります。初めてシステム開発を検討する場合は、開発会社に相談しながら要件定義書を作成するとよいでしょう。

2．設計（外部設計、内部設計）

設計工程では、要件定義で整理された内容をもとに、システムの仕様を詳細に定めていきます。大きく「外部設計」と「内部設計」に分けられます。

外部設計では、ユーザーインターフェース（UI）の設計やデータベース設計などを行います。具体的には以下の作業が含まれます。

• 画面設計（画面レイアウト、操作方法の設計）
• データベース設計（テーブル設計、データ構造の設計）

一方、内部設計では、プログラムの具体的な処理手順を設計します。主に以下の作業を行います。

• プログラム設計（モジュール分割、処理フロー設計）
• テスト設計（テストケースの設計）

設計が不十分だと、後の工程で手戻りが発生する可能性があるため、この工程は非常に重要視されます。

3．開発（プログラミング、コーディング）

開発工程では、前工程の設計にもとづいて実際にプログラムのコーディングが行われます。主に以下の作業が含まれます。

• プログラミング言語の選定
• コーディングのルール策定（コーディング規約）
• ユニットテストの実施
• コード品質の確認（レビュー）

開発工程では、品質と効率を意識しながらプログラミングが行われます。

4．テスト

システム開発の重要なプロセスの1つが「テスト」です。テストには大きく分けて以下の4種類があります。

• 単体テスト：最小単位のプログラムについて動作確認を行う
• 結合テスト：複数のプログラムを組み合わせて総合的に確認する
• 総合テスト：すべてのプログラムが要件定義通りに機能するか確認する
• 運用テスト：実際の業務を想定した環境で確認する

テストは繰り返し実施されますが、上記の順番で進められていきます。テストでは不具合の有無を確認し、不具合が見つかれば原因を特定して修正作業を行います。

テストは開発の上流工程と下流工程の両方で行われますが、上流工程でしっかりと行うことで、下流工程での手戻りを防ぐことができます。

5．納品

システム開発の最終工程である「納品」は、開発が完了したシステムを発注元企業に引き渡すプロセスです。

発注元企業は、納品されたシステムが要件を満たしているかをチェックし、問題があれば開発業者へ修正を依頼します。最終的に検収が完了すれば、開発プロジェクトは終了となります。

教育・トレーニングの目的

• 新システムの操作方法の習得
• 業務フローの変更点の理解
• システム活用による業務効率化の実現

対象者と実施方法

対象者に応じて、適切な実施方法を選択します。

• エンドユーザー：集合研修、e-ラーニング
• 管理者：個別指導、ハンズオントレーニング
• 経営層：概要説明会、デモンストレーション

トレーニング内容の例

• システムの基本操作
• 各種機能の使い方
• データ入力・出力方法
• トラブルシューティング
• セキュリティ対策

教育・トレーニングの進め方

1. 事前準備：マニュアル作成、トレーニング環境の整備
2. スケジュール策定：業務への影響を考慮し、段階的に実施
3. 実施：対面またはオンラインで行い、質疑応答の時間を設ける
4. フォローアップ：理解度確認テストの実施、個別サポートの提供

効果的なトレーニングのポイント

• 実際の業務に即した具体的な事例を用いる
• 受講者の理解度に合わせてペースを調整する
• 質問しやすい雰囲気づくりを心がける
• 継続的なサポート体制を整える

お客様目線で最適なシステムをご提案

お客様の業務内容や課題を徹底的に分析し、お客様に最適なシステムをご提案いたします。

単に機能を詰め込んだだけのシステムではなく、お客様の業務効率を向上させ、利益拡大に貢献できるシステムを構築いたします。

豊富な経験と実績

これまで、様々な業種のお客様のシステム開発に携わってきた豊富な経験と実績を活かし、お客様に最適なソリューションをご提供いたします。

丁寧な対応

お客様一人ひとりに寄り添い、丁寧な対応を心がけております。

ご不明な点やご不安な点があれば、どのような些細なことでもお気軽にご相談ください。