🚧 基本設計のプロセスモデル

Home

📕Arrow icon of a page linkサンエムシステム 上流工程標準(Preview版)

⚖️Arrow icon of a page linkサンエムシステム上流工程 標準規格

📘Arrow icon of a page link要件定義 実践ガイド

📘Arrow icon of a page link基本設計 実践ガイド

📄Arrow icon of a page linkテンプレート集

Get Started

📄Arrow icon of a page link基本設計工程のルール

📄Arrow icon of a page link基本設計書の構成を決める

🚧Arrow icon of a page link基本設計のプロセスモデル

実践ガイド

文書情報
システム方式設計
外部仕様設計
運用設計
インフラ設計
移行計画
テスト方針・計画
開発プロセス・規約
レビュー・承認

このページについて

🚨 工事中 (Work In Progress)

このページは現在執筆中です。将来完成する予定です。

読者に提供する情報

  • 基本設計工程を始める前に、プロセスモデルを決める必要がある
  • PMが決める
  • プロセスモデルの決め方
    • サンプルから1つ選び、カスタム(テーラリング)する
  • テーラリングの指針
  • テーラリングに役立つチェックリストなど

プロジェクトの特性や要件に応じて、実行すべきプロセスを選定し、進め方を決定します。


基本設計工程のプロセスモデル

プロセスモデルを決定する

基本設計工程を開始する前に、プロジェクトに適したプロセスモデルを決定する必要があります。プロセスモデルは、設計作業の進め方、各プロセスの実施順序、成果物の確定タイミングなどを定義するものです。

誰が決めるのか

プロセスモデルの決定はプロジェクトマネージャー(PM)の責任です。PMは、プロジェクトの特性、制約条件、チームのスキル、顧客の要求などを総合的に判断し、最適なプロセスモデルを選定します。

プロセスモデルの決め方

プロセスモデルは、以下の手順で決定します。

  1. サンプルのプロセスモデルから1つ選択する

    標準的なプロセスモデルのサンプルの中から、プロジェクトの特性に最も近いものを選びます。このページで提供している「プロセスモデルの例」を参考にしてください。

  2. プロジェクトに合わせてカスタマイズ(テーラリング)する

    選択したサンプルをそのまま使うのではなく、プロジェクト固有の要件や制約に応じて調整します。これを「テーラリング」と呼びます。

    • 不要なプロセスを省略する
    • 必要なプロセスを追加する
    • プロセスの実施順序を変更する
    • プロセスの詳細度を調整する

    テーラリングの具体的な指針については、このページの「テーラリングの指針」セクションを参照してください。

  3. プロセスモデルをチームで共有し、合意する

    決定したプロセスモデルは、開発チーム全体で共有し、理解を揃えます。必要に応じて、プロジェクト計画書やキックオフ資料に反映します。


プロセスモデルの例

1つ1つのプロセスモデルは、別のページにするべきかもしれない。

全体の概観(プロセスモデル)

基本設計工程は、要件定義書を入力とし、様々な設計プロセスによって実現方式と外部仕様を定め、成果を基本設計書として出力し、開発のベースラインとして確定させます。

graph LR
	%% ノード
	RS[要件定義書]
	
	subgraph BD[基本設計]
		%% プロセスノード
		SCOPE[設計対象の明確化]
		ARC[システム方式設計]
		EXT[外部仕様設計]
		DB[データベース設計]
		MIG[移行設計]
		TST[テスト計画]
		DEV[開発プロセス・規約設計]
		APP[承認]
		
		%% プロセスコネクタ
		SCOPE --> ARC
		ARC --> EXT
		ARC --> DB
		ARC --> DEV
		DB --> MIG
		EXT --> TST
		DB --> TST
		MIG --> APP
		TST --> APP
		DEV --> APP
	end
	
	BDD[基本設計書]
	
	%% コネクタ
  RS --> BD
  BD --> BDD

理想的には、プロセスは順次かつ一方通行で進みます。しかし現実には、並行作業、反復、手戻りが必ず発生します。慌てずに、現場で採用されているプロセスモデルに立ち戻りましょう。

コンセプト
  • このプロセスモデルは、IPA の「共通フレーム」を基盤に、単一システム(サブシステム分割が不要な規模)案件に限定し、外部仕様の顧客合意を重視したプロセスになっています。
  • 「共通フレーム」に対してシステム方式設計とソフトウェア方式設計を一部統合し、顧客との対話を増やしました。

テーラリングの指針?

設計順序の原則:影響が大きい設計要素から確定させる

現場では顧客側の都合やチームのスキル構成などから、計画通りの順序で設計を進めることは困難です。
何から決めていくべきか迷ったら、プロジェクトの成否に対して、影響が大きい設計要素から順に確定させていくことを推奨します。

設計要素の影響度は、案件の状況によって変化します。
以下は例にすぎませんが、影響度を比較する指針として使ってください。

設計要素のプロジェクトに対する影響度:
  • プロジェクト目的に近い要素の方が、影響が大きい
  • 合意形成すべきステークホルダーの数が多いほど、影響が大きい
  • 合意形成すべきステークホルダーの影響力が強いほど、影響が大きい
  • システムの部分よりも、システム全体が関わる要素の方が、影響が大きい
実践的な方法
ステップ1:プロジェクトに適したプロセスモデルを選択する

プロジェクトの規模、特性、制約条件に応じて、適切なプロセスモデルを選択またはカスタマイズします。


考慮すべき観点:

  • プロジェクトの規模(大規模/中規模/小規模)
  • 開発手法(ウォーターフォール/アジャイル/ハイブリッド)
  • システムの種類(Webシステム/組込み/パッケージ導入)
  • 契約形態(請負/準委任/ラボ型)
  • 顧客の成熟度とコミュニケーション頻度
ステップ2:プロセスモデルに沿って作業を計画する

選択したプロセスモデルをベースに、WBSやスケジュールを作成します。


計画作業の流れ:

  1. プロセスモデルの各プロセスを確認する
  2. 各プロセスの工数を見積もる
  3. プロセス間の依存関係を考慮してスケジュールを組む
  4. 担当者をアサインする
  5. マイルストーンとレビューポイントを設定する
ステップ3:作業実行時にプロセスガイドを参照する

プロセスモデルで示された各プロセスを実行する際、対応するプロセスガイドを参照して具体的な作業内容を確認します。


実行時の活用例:

  • 設計作業前:該当するガイドを読み、設計の観点や考慮事項を理解する
  • 設計作業中:ガイドの内容を参照しながら、漏れなく設計を進める
  • 設計完了後:完成条件を確認し、成果物の品質をチェックする
  • レビュー時:ガイドの内容をチェックリストとして活用する
ステップ4:プロセス間の連携を意識する

プロセスモデルは、各プロセスがどのように連携するかを示しています。前工程の成果物を確認し、後工程への影響を考慮しながら作業を進めます。


連携のポイント:

  • インプット確認:各プロセスの開始前に、必要な前提条件と入力情報が揃っているか確認
  • アウトプット定義:次のプロセスで必要となる成果物の形式と内容を明確にする
  • フィードバックループ:後工程で問題が発見された場合の手戻りルートを確認
プロジェクト特性に応じたカスタマイズ

標準のプロセスモデルは、あらゆるプロジェクトに適用できる汎用的なものですが、実際のプロジェクトでは以下のようなカスタマイズが必要になる場合があります。

プロセスの追加・省略

追加が必要な場合:

  • 特殊な技術や規制対応が必要
  • 複雑な外部システム連携がある
  • 高度なセキュリティ要件がある

省略できる場合:

  • 小規模で単純なシステム
  • 既存システムの改修のみ
  • パッケージ導入案件
プロセスの順序変更

並行実施:

  • 独立性の高いプロセスは並行して実施
  • リソースの有効活用
  • 短納期対応

反復実施:

  • アジャイル開発での段階的詳細化
  • プロトタイピングによる確認
  • リスクの高い部分の先行実施
プロセスの詳細度調整

詳細化が必要:

  • 大規模プロジェクト
  • 複雑なビジネスロジック
  • 品質要求が厳しい

簡素化できる:

  • 小規模プロジェクト
  • 定型的な開発
  • 経験豊富なチーム
効果的な活用のためのチェックリスト
プロジェクト特性に合わせて適切なプロセスモデルを選定した
各プロセスに対応するガイドを特定し、チームで共有した
プロセスモデルをベースにWBSとスケジュールを作成した
各プロセスの完成条件を定義し、レビュー計画に組み込んだ
プロセス間の依存関係と成果物の流れを明確にした
必要に応じてプロセスモデルをカスタマイズし、プロジェクト固有のガイドを作成した
定期的にプロセスの進捗と品質を確認する仕組みを設けた
よくある質問
Q1. すべてのプロセスガイドを最初から読む必要がありますか?

いいえ、必要ありません。まずはプロジェクトに関連するプロセスモデルを確認し、実際に作業を行うプロセスのガイドから読み始めることをお勧めします。必要に応じて関連するガイドを参照していくアプローチが効率的です。

Q2. プロセスモデルと実際のプロジェクト計画が合わない場合はどうすればよいですか?

プロセスモデルは標準的な流れを示すものであり、すべてのプロジェクトにそのまま適用できるわけではありません。プロジェクトの特性、制約条件、リスクを考慮して、プロセスモデルをカスタマイズしてください。ただし、省略や変更する場合は、その理由と影響を記録しておくことが重要です。

Q3. プロセスガイドに記載されていない特殊な要件がある場合はどうすればよいですか?

プロジェクト固有のガイドを作成することをお勧めします。このページを複製してプロジェクト専用のガイドセクションを追加するか、別ページとして作成してリンクを追加してください。作成したガイドが他のプロジェクトでも有用な場合は、技術本部にフィードバックして標準ガイドへの反映を検討してもらいましょう。

Q4. 小規模プロジェクトでも、すべてのプロセスを実施する必要がありますか?

必ずしもすべてのプロセスを実施する必要はありません。プロジェクトの規模、リスク、品質要求に応じて、必要なプロセスを選択してください。ただし、省略したプロセスによって生じるリスクを認識し、必要に応じて代替的な品質確保策を講じることが重要です。

Q5. プロセスガイドとプロセスモデルの矛盾を見つけた場合はどうすればよいですか?

技術本部にフィードバックしてください。ガイドは継続的に改善されるものであり、実務での気づきは非常に貴重です。緊急の場合は、プロジェクト内で合理的な判断を行い、その判断理由を記録しておいてください。


次のページ →