要件定義フェーズ

要件定義は開発の最初の段階であり、システムに必要な要件を明確にするために行われます。具体的には、以下の作業が行われます。

• システムで必要な機能や性能の明確化
• 利用するハードウェア・ソフトウェアの明確化
• システムの目的や利用者ニーズの明確化

要件定義が不十分だと、後の工程で手戻りが発生したり、開発コストが膨らんだりするおそれがあります。発注者とシステム開発会社が密にコミュニケーションを取り、的確な要件定義を行うことが肝心です。

設計・開発フェーズ

設計・開発フェーズでは、要件定義フェーズで決められた仕様に基づいてソフトウェアを実際に設計・開発していきます。

主なプロセスは以下のとおりです。

1．基本設計

要件を実現するためのシステム構成や処理フロー、データ設計などを行います。

2．詳細設計

基本設計をもとに、プログラムの詳細な仕様を決定します。

3．プログラミング

詳細設計に基づいて、実際にプログラミングを行います。

4．結合テスト

単体でテストしたプログラムを組み合わせ、インタフェースなどの確認を行います。

5．システムテスト

要件に沿った総合テストを実施し、問題がないかを確認します。

設計・開発フェーズは品質を左右する重要なフェーズです。設計が適切でないと、後工程で手戻りが発生する可能性があります。

運用・保守フェーズ

ソフトウェアが無事リリースされた後は、運用と保守の段階に入ります。

運用とは、ソフトウェアを安定して継続的に稼働させることです。具体的には以下の作業が含まれます。

• 障害監視・対応
• データバックアップ
• セキュリティ対策
• パフォーマンス監視・チューニング

一方、保守とはソフトウェアの機能改善や不具合修正などを指します。主な作業内容は以下のとおりです。

• 機能追加・変更
• 不具合修正
• セキュリティパッチ適用
• OSやミドルウェアのバージョンアップ

このように運用と保守は密接に関係しており、両方を適切に実施することがシステムの長期安定運用には欠かせません。

要件定義の徹底

ソフトウェア開発において、最も重要なステップが要件定義フェーズです。この段階で、開発するシステムが満たすべき機能や性能、運用要件などを綿密に決めておかなければなりません。

要件定義が不十分だと、後工程で仕様変更が発生し、手戻りのコストがかさみます。そのため、以下の点に十分注意を払う必要があります。

• 利用者の要望を詳細に洗い出す
• 全ステークホルダーの合意を得る
• 要件の文書化と管理体制の構築

このように要件定義は、開発の成否を左右する極めて重要な工程なのです。

開発手法の選択

ソフトウェア開発においては、プロジェクトの規模や要件の複雑さに応じて、様々な開発手法が選択されます。

一般的な開発手法は、以下のとおりです。

ウォーターフォール開発

規模が大きい場合に向く。変更が難しい。要件を最初に固め、設計→実装→テストと段階を踏んで進める。

アジャイル開発

小規模で要件変更が多い場合に向く。柔軟性が高い。短いスプリントを繰り返し、要件を柔軟に変更しながら開発する。

運用・保守の計画的実施

ソフトウェア開発の運用・保守フェーズでは、システムが安定して機能するよう適切に運用・保守することが重要です。

運用・保守は以下の作業が含まれます。

• 運用テスト
• 運用作業（バックアップ・リストアなど）
• 障害対応
• 機能改修・機能追加
• ハードウェア／ソフトウェアの更新

など

これらの作業を計画的に、効率よく実施するため、以下のような取り組みが求められます。

• 運用・保守体制の構築
• 運用・保守作業の手順化
• スケジューリングと進捗管理
• ドキュメンテーションの充実

運用・保守の計画的実施により、システム稼働の安定性と信頼性を高め、長期的な視点でコスト削減と生産性向上を実現できます。

1．成果物（システムやアプリ）の条件を明確化

契約書には「どんな機能や性能を持つシステムが完成すれば納品とみなされるのか」を明記しましょう。この内容が曖昧だと、完成の基準でトラブルが起きる可能性があります。

2．費用と支払い条件を確認

開発費用の総額や支払いスケジュール、追加費用が発生する条件を事前に確認しておきましょう。予算オーバーを防ぐためには、明確な合意が必要です。

3．納期とスケジュール

納品日とその間の進捗確認のタイミングを契約書で押さえておきましょう。これにより、開発が遅れて困るのを回避できます。

4．運用・保守のサポート内容

納品後のサポート（不具合対応や機能追加）の範囲や費用についても確認してください。導入後のトラブルに迅速に対応してもらえるかが重要です。

請負契約と準委任契約の違い

請負契約は、ベンダーが「成果物（システムなど）」を給付することが契約の目的です。一方、準委任契約は、ベンダーが「役務を行うこと」自体が契約の目的となります。

したがって、請負契約ではベンダーは結果の達成を約束しますが、準委任契約ではそれを約束しません。成否は発注者側のリスクとなり、ベンダーは役務提供に専念するだけです。

再委託に関する規定

システム開発委託契約においては、受託者が第三者に業務を再委託することについての規定を設けることが重要です。

準委任型の委託契約では、民法上、受任者が再委託するには「委任者の承諾」または「やむを得ない事由」が必要です（民法656条、644条の2第1項）。

一方、請負契約型では再委託は原則自由ですが、委託者として知らないところで第三者に開発を遂行されたくない場合は、契約で「委託者の事前承諾なく再委託できない」と定める必要があります。また、同意の有無をめぐる紛争を防ぐため、「書面による承諾」を要件とするのが無難です。

さらに、再委託先が第三者に再々委託されるリスクを防ぐため、「再委託先は第三者に再々委託できない」と規定するのが賢明です。

検収基準と責任分界点

検収は、委託先が納品したソフトウェアの機能や品質が、契約で定めた要求水準を満たしているかどうかを確認する重要な作業です。検収基準は、検収判定の判断材料となる明確な基準を、契約時に定めておく必要があります。

例えば、以下のような基準を設けることができます。

• 機能要件への適合性
• 非機能要件（性能、セキュリティなど）の充足度
• テスト結果の合格率

また、検収の合否によって責任分界点が明確になります。検収に合格すれば、開発責任は委託先から発注者へ移転します。合格しない場合は委託先の責任で修正を行う必要があります。

ソフトウェア開発依頼前の準備1：プロジェクトの目的と期待する成果の明確化

• ビジネス目標の設定
• 具体的な成果指標（KPI）の決定
• ステークホルダーの特定と期待の把握

ソフトウェア開発依頼前の準備2：要件の洗い出しと優先順位付け

• 機能要件の列挙
• 非機能要件（性能、セキュリティなど）の特定
• 要件の優先順位付け（MoSCoW法の活用）
• 予算と期間の設定
• 概算予算の算出
• 開発期間の見積もり
• リスク対策費の考慮

ソフトウェア開発依頼前の準備3：開発手法の選択

• ウォーターフォール型とアジャイル型の比較
• プロジェクトの特性に合わせた手法選定

ソフトウェア開発依頼前の準備4：開発リソースの確認

• プロジェクト管理者の選定
• 社内の技術リソースの把握
• 外部委託範囲の決定

なぜIPAのテンプレートがおすすめ？

• 専門家が作成：ITに詳しい専門家によって作成されているため、契約書に記載すべき項目が網羅されている
• 無料で利用可能：誰でも無料でダウンロードして利用できる
• 汎用性が高い：様々なシステム開発に適用できる汎用的なテンプレート

ソフトウェア開発で契約書のテンプレートを使うメリット

• 契約内容の漏れを防ぐ：重要な項目が抜けるのを防ぎ、トラブルを未然に防ぐ
• 契約交渉の効率化： 契約書の作成に時間をかけずに済む
• トラブル発生時の安心感：標準的な契約書に基づいて契約を結んでいるため、トラブルが発生した場合に、より客観的な判断材料に

IPAのテンプレートの使い方

1）IPAのウェブサイトからダウンロード

2）ダウンロードしたテンプレートの内容を自社向けにカスタマイズ

3）必要に応じて弁護士など専門家のリーガルチェックを受ける