ソフトウェア開発プロジェクトでのチェックリスト

ソフトウェア開発プロジェクト全般で、チェックしなければいけないことを確認できます。

images/cards/project-g99c29da3d_640.webp

目次

0. Introduction

  • 対象となる読者
    • ソフトウェア開発プロジェクトを任されている方
  • 本記事の価値
    • ソフトウェア開発プロジェクト全般で、チェックしなければいけないことを確認できます。
  • 前提
    • 特になし

1. ソフトウェア開発プロセスの形態

ビジネスの現場では、どの開発手法を選択するか、という問題ではなく、それぞれの特徴を理解し、プロジェクトの特性を鑑みて臨機応変に使い分けることが得策です。そのためには、それらの手法の違いを正確に掴み、その特徴を理解する必要があります。以下に代表的な開発手法を列挙します。

1-1. ウォーターフォール開発型開発プロセス

以下のフェーズに分割し、上流から下流へ順に進めます。上流である「要件定義」フェーズから、下流の「テスト」フェーズまで、ちょうど水が流れるように作業が進み、決して逆行することはありません。 一つ一つのフェーズの区切りで、フェーズ毎に生成される成果物を厳格にレビューし、不十分な場合は先に進めません。後戻りがなく、開発が進められる利点があります。

  • 要件定義
  • 機能設計
  • 詳細設計
  • プログラム制作
  • 単体テスト
  • 組み合わせテスト
  • 総合テスト

1-2. スパイラルモデル

ウォーターフォール型開発プロセスにおける決定を補う目的で考案されました。プログラム開発を小さなフェーズに分割してフェーズ毎にプロトタイピングによるデモンストレーションを行い、顧客からの評価内容をフィードバックします。FS(feasibility study)を行いながら、作業を進めることができます。

メリット

  • 顧客の要望を早い段階から理解し取り込むことができ、最終的に顧客のイメージに近いものが出来上がる。
  • 顧客の参加意識を醸成、顧客の協力を得やすい。
  • 後工程への「しわ寄せ」が集中するリスクを低減

デメリット

  • 度重なるプロトタイピングにより、予想外に作業量が増えて、当初のスケジュールから大幅に遅延するリスクあり

1-3. 反復型開発プロセス

独立させても意味がある機能範囲を分離独立させて、これを「反復」と呼ぶ単位で管理します。反復毎に機能要件が整理され、開発、提供が可能となります。「積み上げ方式」とも呼ばれ、このような「反復」をインクリメンタルに提供します。

メリット

  • スパイラルモデルのメリット
  • 部分的な完成時期をコントロールできる
  • 契約を分割することができるので、部分的な納品ができ、契約不履行や瑕疵のリスクが低減される

デメリット

  • あまり細かく分割すると、分割のための作業や管理業務が増える可能性がある
  • 全体像が見えにくくなり、最終的な完成図が掴みづらくなる
  • 変化が激しい環境では、既納品との整合性を保つ努力が必要である
  • 単独の機能ではなく一括して稼働することが必要なシステムでは、分割することにより意味がなくなり、分割することが不可能な場合がある。

1-4. アジャイルプロセス

Wikipediaによれば、人間・迅速さ・顧客・適応性に価値を置くソフトウェア開発です。典型的なアジャイルソフトウェア開発では、チーム主導で設計・実装・デプロイを短期間に繰り返してユーザーが得た価値を学習し適応する、すなわちトライアルアンドエラーで開発が行われます。「アジャイルの価値」として、以下が挙げられます。

  • プロセスやツールよりも、個人や相互作用
  • 分かり易いドキュメントよりも、動くソフトウェア
  • 契約上の駆け引きよりも、顧客とのコラボレーション
  • 計画を硬直的に守るよりも、変化への対応

アジャイルソフトウェア開発を可能にする開発手法には、以下の様々なソフトウェア開発方法論があります。

  • エクストリームプログラミング(eXtreme Programing, XP)
  • 適応型ソフトウェア開発
  • クリスタル
  • スクラム
  • ユーザ機能駆動型開発（FDD）

2. プロジェクト開始時のチェック

2-1 システム化の目的と範囲及び要件について

  • プロジェクトの目標がユーザの課題解決方針に合致していることを確認したか
  • 定義した要件を実現すればユーザの課題が解決することが確実か
  • プロジェクトの完了と成功の基準が明確か
  • 必要な機能や性能が実現可能であることを確認したか
  • 必要な機能や性能が実現に必要な前提条件を確認したか
  • 作業範囲や作成する成果物を第三者が見ても正しく理解できるように文書化したか

2-2 見積について

  • 見積の前提条件を文書化しているか
  • 工数の見積もり根拠が妥当で客観的に説明できるか
  • プロジェクト管理費用を十分に見積もったか
  • ユーザは要件変更に必要な予備費用をプールしているか

2-3 プロジェクト体制とスキルについて

  • プロジェクト体制をユーザや外注先も含めて文書化したか
  • プロジェクト外の部門や要因に必要な協力を依頼し了承されているか
  • ベンダ側のプロジェクトマネジャーは一次発注先か
  • メンバの役割と責任が明確で実施可能か
  • メンバのスキルは充分か、あるいは育成可能か
  • ベンダの実績、経験を弱みも含めて共有し、必要な対応について合意しているか
  • ユーザのシステム開発に関わるスキル・知識を把握し、ベンダに求められる支援を明確にしているか
  • 対象業務についてベンダの知識やユーザレベルを把握し、ユーザの協力事項を明確にしているか
  • ユーザ固有の作業標準についてのベンダ知識レベルを把握し、ユーザの協力事項を明確にしているか
  • プロジェクト責任者（予算と要件について決定権限をもつ人）と定期的にコミュニケーションできるか
  • メンバは必要な工数をプロジェクトに割けることが確実か
  • メンバの健康状態に問題はないか、プライベートも含めてメンバに心配事はないか

2-4 スケジュールとリスクについて

  • プロジェクト計画時に想定されるリスクへの対応を見込んだスケジュールか
  • ハードウェアやソフトウェアその他設備等購入品の納期遵守は確実か
  • マイルストーンの遵守を妨げるリスクをすべて洗い出し対応策を検討しているか
  • 規制・法令・認証・認定に準拠した作業および成果物か
  • 他のプロジェクトからの影響を受けるリスクへの対応方針を確定し実現可能であるか
  • 予定通りにリリースできなかった場合のユーザの経営的リスクを算定し、経営層の了解を得ているか

3. プロジェクト管理に関わる定期的なチェック

3-1 進捗について

  • WBS などを元に進捗を定期的に管理しているか
  • プロジェクトの進捗は予定通りか
  • 次のマイルストーンの終了予測（前倒し/遅延）を日数で予測できるか
  • 上項目の遅延が予測される場合の対策を立てて、ユーザとベンダで合意したか
  • 遅延を回復できなったときの影響を把握し、ユーザとベンダで共有したか

3-2 要員の工数について

  • WBS や要員計画を元に工数を定量的に管理しているか
  • 工数の最終予測ができるか
  • 工数の消化が多過ぎる、あるいは少なすぎる場合、その原因を特定し妥当な対策を立てているか
  • 工数オーバーの原因がユーザにある場合、ベンダはユーザに追加見積りを行ったか。また、ユーザはベンダからの見積もりを正当な理由なく受け取り拒否していないか

3-3 リスクについて

  • 定期的にリスクの洗い出しを行い、対策とその発動基準についてユーザとベンダで合意したか
  • 定義しているリスク対応策は、妥当なものか
  • リスク対応策をタスク（WBS など）に反映されているか
  • 既出のリスク対応策の進捗を監視しているか

3-4 課題について

  • 定期的に課題の洗い出しを行い、対策についてユーザとベンダで合意したか
  • 定義している課題対応策は、妥当なものか
  • 課題対応策をタスク（WBS など）に反映されているか
  • 既出の課題対応策の進捗を監視しているか

3-5 成果物の構成管理について

  • 構成管理計画とベースラインを適切に作成して、それに基づく管理を行っているか
  • 成果物をプロジェクトの定める構成管理ツールで管理しているか
  • 成果物の変更時にベースラインを更新し、プロジェクト承認者の承認を得ているか
  • 最新のモジュールであることを確認しているか

3-6 メンバのスキル育成について

  • 計画したスキル育成を予定通りに実施しているか
  • 期待したスキルアップができているか。できていない場合、その対策を立てているか
  • 上項の対策に必要なユーザとベンダの協力項目は明確で実現可能か
  • プロジェクトの進行に伴い、新たな必要スキルを洗い出しているか

3-7 外注管理について

  • プロジェクトで適用する作業標準や手順を外注先の活動に対しても適用しているか
  • 外注先でもベンダ内部と同様のプロジェクト管理を行っていることを確認できるか
  • 外注先と定期的に打合せを行っているか
  • 外注先成果物の受入れ基準を明確に文書化しているか
  • 外部委託先に関する課題・リスク・依存関係は適切に管理されているか
  • 外部委託先の評価を行う予定か

4. 要件変更に伴うチェック

  • 要件追加・変更・削除の影響をトレーサビリティマトリクスで確認したか
  • 影響調査と追加・変更・削除の検討およびその結果を文書化したか
  • 要件追加・変更に伴って追加コストがある場合、ベンダをこれを見積もったか
  • 要件追加・変更・削除についてはユーザ及びすべてのステークホルダの了承を得たか
  • 要件追加・変更・削除に伴ってプロジェクト計画を正しく変更したか
  • 変更したプロジェクト計画は実現可能か
  • 要件追加・変更・削除に伴って要件定義書を更新し、成果物レビューを再実施したか
  • 要件追加・変更・削除を行ってもシステム開発の目的が達成できることを確認したか

5. 組織による品質保証に伴うチェック(各工程の完了時等に実施)

  • プロジェクトで実施している作業は、組織やプロジェクトで定めた標準や基準を守っているか
  • チェック時点までにつくるべき成果物や管理帳票等を漏れなく作成しているか
  • 作成した成果物は必要な成果物レビューを受けているか
  • 作成した成果物や管理帳票、報告資料に必要な承認を得ているか
  • 作成した成果物はプロジェクトで定めた場所に格納され、適宜更新されているか
  • 定量的管理の手法や方法に誤りや誤解がないか
  • 前回チェック時点で指摘があった場合、これにすべて対応できているか
  • 機密情報等を厳密に管理しているか
  • ユーザとベンダの会議やプロジェクト内の会議を計画にしたがって実施しているか

6. リリースに伴うチェック

  • 開発環境と本番環境に障害を発生させるような違いがないことを確認したか
  • 上項の違いがある場合、その対策についてユーザとベンダが検討し合意したか
  • リリース後に、必要なインフラ（ハードウェア、ソフトウェア、ネットワーク）を構築済か
  • 障害発生時の復旧計画の必要性の可否は検討済みか
  • 運用上の制約がある場合、エンドユーザやオペレータも含めて承認済か
  • ユーザー側の準備（ワークフロー定義、トレーニング、マニュアル、ヘルプデスク）に問題はないか

7. 検収に伴うチェック

  • プロジェクトの目的と整合の撮れた検収基準があるか
  • 検収基準は検証可能か
  • 検収時の残存バグについての対応方針についてユーザとベンダが合意しているか
  • 瑕疵担保責任の対象となる瑕疵の定義が明確であるか
  • リリース後の保守契約を締結しているか、締結が確実であるか
  • リリース後のベンダ側窓口が明確で、連絡可能であるか
  • 製品の安全面に対する対策の確定度は高いか、対策が考慮されているか

参考文献

  • 「なぜ、システム開発は必ずモメるのか？49 のトラブルから学ぶプロジェクト管理術」 細川義洋著,日本実業出版社
  • 「実践的ソフトウェア工学 第 2 版」, 浅井治著, 近代科学社

関連記事