リリース判定基準・開発管理プロセスはまず開発計画を見る
開発管理プロセスの品質は計画と実績の突き合わせで判定する
リリース判定で開発管理プロセスの品質の善し悪しを判定するには、どんな項目をどんな観点で見るのが良いでしょうか？ 良いメトリクスがあれば数値化して開発管理プロセスの良し悪しを判定できるのですが、都合の良いメトリクスはなかなかありません。そこでグータラ親父は定性的な方法になりますが、重要な開発管理プロセスを６つ決めて、それらの開発管理プロセスについて主に以下の２つの視点でそのプロセスの状況を見て問題の有無や良し悪しを判定していました。
- 開発の計画に抜け漏れや問題点は無いか
- 計画された個々の管理プロセスは問題なく実施されているか
計画と実績は６つの重要な開発管理プロセスで確認する
重要な開発管理プロセスとしてグータラ親父が注意していたのは以下の６つのプロセスです。
- 開発計画の立案
- ソフトウエアの設計と実装
- テスト計画の立案
- 懸案やリスクの管理
- ベースラインの管理
- 保守の体制と保守契約
- ゲートプロセスの実施状況
また、重要な管理プロセスと重なるのですが、ゲートプロセスが着実に実施されているかという点も、管理プロセスの状況を確認する上で注意していた点です。ゲートプロセスについては後で説明しますので、まずは重要な開発管理プロセスについて、計画と実施の両面でどんな点を確認していたのか、順番に紹介していきましょう。
１．開発計画の立案
ソフトウエア開発にとって一番重要なのが開発計画です。 開発計画が無いとプロセスの品質を考える以前の問題になってしまいますので、ここでは開発計画は有るものだという前提で話を進めます。 現実には開発計画が無いプロジェクトもあるかも知れませんが、そのような場合には、ぜひ頑張って開発計画を作って下さい。
開発計画は開発計画書として内容が書きだされているのが通常ですので、開発計画の立案プロセスの品質は、開発計画書を見れば判定できます。 それでは開発計画書にはどんな項目が記載されていれば良いのでしょうか？
開発計画書の書き方にもいろいろあるので、これが正解というのはありませんが、グータラ親父は以下のような項目が開発計画書に具体的に書かれているかどうかを確認していました。
（１）開発の範囲や分担と責任者
開発計画書では、まず今回の開発の範囲が具体的に書かれている必要があります。 ソフトウエアの開発には、色々なプロセスがあります。 ソフトウエアのワイフサイクルに沿って例をあげると、製品企画/要求仕様設計/構造設計/機能設計/詳細設計/実装/単体テスト/結合テスト/システムテスト/妥当性検証/沿リリース/保守 といった所でしょうか。
これらのプロセスの中で、今回のソフトウエア開発プロうジェクトはどれを含んでどれは含まないのか、が明確に書かれていないと何の作業をして良いのか判りません。
また、要求仕様やソフトウエアの基本設計やテストのような重要なプロセスについては、責任者が明確になっている事も大切です。
（２）懸案とリスクの一覧
開発計画を検討している段階で気づいている懸案（既に発生している問題点）やリスク（将来発生する問題点）が整理されていて書き出されている事も大切です。 開発を進める中で、個々の開発作業と並行して、懸案とリスクに対する対策を実行する事が重要ですので、まずは開発計画書に懸案とリスクが書き出されているかを確認していました。
（３）他部署との連携点となるマイルストンが判る工程表
工程表は必須ですが、開発作業という線が一本書かれているだけの工程表では、工程の進捗管理ができません。 工程表は、少なくとも重要なマイルストンが書かれていて、そのマイルストンの達成状況で進捗の進みや遅れが判るような粒度が必要です。
例えば、基本設計は何月何日までに完了するのか、とか、実装は何月何日までに完了するのか、とか、システムテストは何時から開始されて、リリース判定は何月何日に実施予定なのか、というようなマイルストンについて、具体的な日程が判る必要があります。
それと同時に、ソフトウエア開発に関連する他部門とタイミングを合わせるマイルストンも明確になっている事が大切です。 例えば、工場で製造する製品に搭載するソフトウエアの開発計画なら、最終版のソフトウエアを工場の製造ラインに提供する日付は、他部門の工程に影響するのでソフトウエア開発のマイルストンとしても重要です。
また、新製品の初期開発のように、ハードウエアとソフトウエアの開発が並行している場合には、ハードウエアの初品がソフトウエア開発チームに提供される時期と数量がとても大切です。 このマイルストンが、実機テストを開始できる開始点になるで、テストとデバッグの工程に大きく影響します。
工程表には、このような他部門と連携するマイルストンも明記してある必要があります。 工程の開始と終了を表す線表の中に、このように重要なマイルストーンも明記されているかどうかを確認していました。
（４）工程管理と品質管理の方法や目的
工程と品質は重要な管理対象です。 この二つについては、具体的な管理の方法と目標値が計画書に書いてある必要があります。
工程の進捗管理の例では、どんなツールを使って工程管理をするのか、最初の段階で明確になっていないと、作業の進捗状況が判らなくなります。
ガントチャートを作るのか、作業一覧を表にしたようなWBS（Work Breakdown Structure) を使うのか、何等かの進捗管理システムを使うのか、進捗管理に使うツールの選定が記載されていて、それをどんな頻度で（毎週とか隔週とか）、工程実績を誰が記入して、工程進捗を誰が確認して、遅れが発生した時の対策を誰が進めるのか、という具体的な計画まで記載されていると、より安心です。
品質管理の例では、どんな品質管理のメトリクス（ソフトウエアの品質指標）を品質管理に使うのかが、開発の最初の段階で明確になっている必要があります。
例えば、設計段階ではレビューの指摘率を監視する、実装段階ではコード修正の回数を監視する、テスト段階ではバグ密度をk雀士する、というように各々の開発フェーズでどんなメトリクスを使ってソフトウエアの品質を監視するのかが、決まっている必要があります。
そして、工程の進捗管理と同様に、どんな頻度で（毎週とか隔週とか）、品質の実績を誰が収集して、品質の実績を誰が確認して、品質悪化時の対策を誰が進めるのか、という具体的な計画まで記載されていると、より安心です。
（５）外注管理の方法
ソフトウエアの開発では、開発プロセスの一部や全部を社外に業務委託する事もよくあります。 外部注文、略して外注と表現される事も多いですね。 設計や実装やテストなど、一部分を外注する事も有れば、要求仕様書の作成からテストまでの一連の開発プロセスを全部外注する事もあります。
委託した業務が納期・品質ともに問題無く納品されれば良いのですが、いざ納品の時期になって、委託した業務が終わっていないとか品質が不足している、となると大変です。 そのようにならないように、委託先での業務の進捗や品質の状況を監視・管理する必要があります。
この業務委託先の管理・監視がちゃんと機能するためには、委託元である自社組織と委託先である外注との間で、相互の責任者が明確になっていて、監視・管理の具体的な方法が決まっている必要があります。
委託した業務の監視・管理の方法には色々あります。 例えば、毎週１回の定例会議を開いて、工程表や課題管理表で業務の状況を報告してもらうとか、月１回業務状況の報告書を提出してもらうとか、委託元/委託先のルールや慣習によって様々な方法が考えれれます。
どのような方法を使うのでも構わないのですが、業務計画書には、どんな方法を使って委託した業務の監視・管理を行うのかは、書いてある必要があります。
以上のように、ソフトウエア開発プロジェクトにとって大切な項目が、開発計画書に具体的に書かれていれば、計画がちゃんと検討されていると判定して良いと思います。
（次の記事）リリース判定基準・開発管理プロセスは設計と実装とテスト計画を見る に続く