リリース判定基準・懸案やリスクの管理とベースライン管理も見る
開発プロセスでは懸案やリスクの管理とベースライン管理も重要
この記事では、リリース判定でのプロセス品質の判定のためにグータラ親父が確認していた７つの項目のうち、懸案とリスクの管理、ベースラインの管理 について紹介しています。他の５項目（開発計画の立案、ソフトウエアの設計、実装テスト計画の立案、保守の体制と保守契約、ゲートプロセスの実施状況）については、前の記事や後の記事で紹介していますのでそちらをご覧ください。
４．懸案やリスクの管理
懸案とリスクについては、開発計画書の確認の項目でも少し触れてあります。開発計画書をでは、まず懸案とリスクを書き出してある事が大切ですが、それよりも大事な事は、開発プロジェクトが進んでいく中で、懸案やリスクについての管理（対応計画の作成と実施状況のトレース）を実施して、リリースの時までに懸案やリスクを解決していく事です。
ところで、懸案やリスクとはそもそも何でしょう、両者の違いはいったい何でしょうか？ 明確に答えようとすると、ちょっと詰まってしまう人も多いのではないかと思います。ソフト開発プロジェクトにおける懸案とリスクの定義も色々とありますが、グータラ親父は以下のように使い分けていました。
- 懸案 ：開発プロジェクトを進める上での問題点で、今すでに起こっている事がら
- リスク：開発プロジェクトを進める上での問題点で、将来起こる可能性が判っている事がら
懸案は既に起きてる問題点でリスクは将来起きる問題点
懸案もリスクも、ソフト開発プロジェクトを進める上での問題点です。技術上の問題点だったり、開発に使う機材の問題点だったり、納期上の問題点だったり、人員上の問題点だったり、プロジェクトを進めようとするといろいろな問題点が出てきます。
その様な問題点のうち、既に起きてしまっている問題点を懸案と呼び、将来起こるであろう問題点をリスクと呼びました。例えば、テスト人員が不足するという問題点を例に説明してみましょう。今はまだ設計作業を行っていてテストが始まっていない時期ならば、テスト人員不足するだろうというのは、計画段階で推定した将来起こるである問題点なので、リスクです。しかし、今が既にテスト作業が始まっていて、実際にテスト人員が不足しているのなら、これは既に起きてしまっている問題点なので、懸案です。
言い方を変えれば、開発プロジェクトの開始時点では、殆どの問題点がリスクです。 リスクは時間の経過とともに懸案に変わっていき、開発プロジェクトの終了時点で対策されずに残っている問題点は、全て懸案です。
懸案もリスクもリリース時に対策が済んでいる事が大事
懸案もリスクも、プロジェクト終了までに対策が必要な問題点です。リスクは、それが懸案になる前に何等かの対策を行ってリスクを無くせるのが良いです。一方で懸案は、既に発生してしまっている問題点なので、プロジェクトへの影響が拡大しないようできるだけ早急に対応を取る事が求められます。 誰が・何を・何時までに検討して対策を実施するのか、具体的な対策の計画と実施が必要です。
そのためには、どんな懸案やリスクが存在していて、それは誰が何時までに対策を検討して実施していくのか、対策の納期と責任者が明確になっていて、その進捗を適切にトレースする仕組みが必要です。これは言い換えると懸案やリスクの管理です。 懸案やリスクの対応はソフト開発プロジェクトの管理の中でも重要な項目の１つですので、その管理がしっかりっできているかは大切な点です。
懸案とリスクの対応方法は例えば、プロジェクトの定例会議で懸案とリスクの一覧表を使って対策状況を確認するとか、リスクと懸案事項の一覧表をプロジェクトメンバで共有しておき対策状況を管理職が随時確認するとか、いろいろな方法があります。 どのような方法を採用するのかは、個々のプロジェクトで決めれば良いので、何等かの懸案やリスクの対策状況の管理プロセスが、開発プロジェクトのプロセスのとして実施されていたがどうかを、開発プロセスの品質の１項目として、確認していました。
５．ベースラインの管理
管理プロセスの状況として次に確認するのが、ベースラインの管理の状況です。 ベースラインとは、ちょっと聞き慣れないという人も居られるかも知れません。 ベースラインとは、ソフトの開発のベースとなるドキュメントやソースコードや開発環境の事です。
もう少し具体的に言うと、ソフの開発を行う時に使う、仕様書や設計書のバージョンや、ソースファイルのバージョン、開発環境（Build 環境や 統合開発環境や SDKツール）のバージョンの事です。 たとえば、A-機能に関する機能設計書を使う時に、そのA-機能設計書のバージョン 2.1 を使う必要があれば、この バージョン 2.1 がその開発における A-機能設計書のベースラインです。
そのプロジェクトの関係者は全員、A-機能設計書の バージョン 2.1 を参照しなければなりません。 バージョン 1.0 を参照する人やバージョン 3.1 を参照する人が居ては、開発はとん挫します。
ソースコードにしても、A-機能のファイル Function-A.c というソースファイルがあって、そのバージョンとして Rev2.3.1 に改造を加えて機能を追加するなら、担当のコーダは全員 Rev2.3.1 を基にコーディングを進めなければいけません。
また、ソフトの開発環境（コードの登録・Build・デバッグ等）に使うツールがあるなら、全員が同じバージョンのツールを使っている必要があります。
文書にすると、すごく当然の事です。ですが、少し規模が大きなソフト開発では、ベースラインの管理のための仕組みをちゃんと考えてそれを確実に運用しないと、ベースラインが乱れて人によって違う設計書やソースファイルや開発環境を使って作業をしていた、という様な事態も起こり得ます。
例えば30人のソフトエンジニアが参加しているソフト開発プロジェクトで、15本の設計書と 50本のソースファイルを使って、XXX-Develop-Tool の上で開発が進んでいたと仮定してみましょう。
当然の事ながら、設計書もソースファイルも、ソフトの開発が進むにしたがって、バージョンが改訂されていきます。 時には設計や実装の間違いに気付いて、一つ前のバージョンにバージョンダウンする場合もあります。XXX-Develop-Tool も開発プロうジェクトの途中で改訂バージョンがリリースされるかも知れません。
30人全員が常に正しいバージョンの設計書とソースファイルを見ている事を保証するには、どうすれば良いでしょうか？バージョン変更の都度全員にメールで通知する、常に最新バージョンをサーバに置いておきローカルに保持しないようにする、定期的に全員が参照している設計書とファイルのバージョンを確認する、バージョン管理システムを導入する、色々な対策方法があります。
また、開発環境について考えると、30人全員が同じバージョンの XXX-Develop-Tool を使っている事を保証するには、どうすれば良いでしょうか？ 開発環境は誰か１人の人が準備して全員がこれを使うとか、定期的に全員が使っているツールのバージョンを確認するとか、こちらも色々な対策方法があります。
どの様な方法でも良いのですが、設計書やソースファイルや開発環境のベースラインをどんな仕組みを使って管理していたのか？ という事も、ソフト開発プロセスの確認として大切な部分です。