ソフト開発監査チェックリスト（３）トラッキングプロセス
開発プロセスチェックリストの３番目はトラッキングです
この記事では、ソフト開発監査に使う監査チェックリストの個々の項目についての紹介をしていきます。監査チェックリストは①開発プロセス ②要件管理 ③テスト ④設計と実装 に分かれていて、この記事では①開発プロセスの中のトラッキングの個々の項目について紹介します。（チェックリストそのものはソフト監査実務・チェックリストその１：開発プロセス（要件管理）の記事に載っていますので、そちらをご覧下さい）
トラッキングとは計画に対する実績の確認と修正です
計画を立てて実際の開発作業を始めたら、作業が計画どおりに進んでいるのかを確認して、もし計画からズレてきたらこれを計画どおりに戻すような工夫が必要です。日本語でいうと実績の確認と修正の実施ですね。この２つを合わせて英語圏ではトラッキングという言葉を使います。
割と便利な言葉なのと、海外の開発委託先と話しをする時に通じ易いので、グータラ親父もトラッキングという言葉を使っています。トラキングは項目番号の先頭がTR- となっている８項目です、それでは順番に見ていきましょう。
【項目番号：TR-01】
ソフトの開発は、設計・実装・テストとその殆どが人の頭の中で進む作業なので、なかなか進捗状況が判りにくいです。ただし、人が頭の中で行った設計や実装やテストの結果は、設計書やソースコードやテスト報告書という成果物として書き出されてきます。ですので、ソフトの開発で進捗状況を定量的に把握するには、これらの設計書やソースコードやテスト報告書のでき具合を計画と見比べる事で、進捗状況を把握する事ができます。
例えば、今日の時点で設計書が6種類完成している計画にたいして、４種類しか完成していなければ、2/6 で計画遅れが出ていると判断する事ができます。このように、ソフトの開発の進捗を、成果物の出来具合で判断して、遅れがあれば対策をとるような進捗管理のアクションをしているかどうかを確認します。
【項目番号：TR-02】
ソフト開発プロジェクトを計画して進めていく中で、何も問題点なく平穏無事に進むプロジェクトというのは在りません。残念ながらどんなプロジェクトでもなんらかリスクと懸案が在ります。しかし大きなリスクや懸案があっても成功するプロジェクトもあれば、大したリスクや懸案が無いのに失敗するプロジェクトもあります。
これはプロジェクトがリスクや懸案をうまく対応できたかどうか、プロジェクトのリスクや懸案の管理能力の有無で変わってきます。このリスクや懸案の管理能力を知るために、ソフト開発プロジェクトの開始時点で気づいたリスクや懸案を、一覧表などを使って管理し対策を進めるような仕組みを持っているかどうかを確認します。
【項目番号：TR-03】
ソフト開発プロジェクトの進捗を管理する方法は色々あるのですが、一番簡単な方法は重要なマイルストーンが計画どおりに実施されるように管理する方法です。そして、ソフト開発での重要なマイルストーンとしては、やはり関連する複数の部署が参加する公式レビューです。
この公式レビューの実施日程が計画から大幅に遅れたり、大幅に前倒しされたりしていると、作業の進捗に何か問題が起きていると考えて良いでしょう。問題が起きている事に気づけば、対策を行って問題を解消するアクションも起こせます。このように、重要なマイルストーンの日程管理が実施されている事を確認します。
【項目番号：TR-04】
ソフトの設計や実装の段階で品質を良くするための大切な活動はレビューです。レビューにも目的や実施の方法に様々な物がありますが、皆さんの部門ではどんなレビューをどんなタイミングで行うのか、決まっていますか？ どんな設計や実装に対してレビューを行うのか、レビューをするかどうかは誰が決めるのか、レビューの方法はどれを使うのか、レビューの参加者は誰にするのか、レビューの指摘事項はどうやって記録して対策をトレースするのか、レビューの実施状況は誰が記録するのか。
大切なレビューが必要な設計や実装に対して効率的に実施されるには、これらのレビュー計画がある程度明確になっている必要があります。そのようなレビューの計画の仕方についての基準を書いた物があるのか、その基準に従って実際のレビューが計画されて実施さてているのかを確認します。
【項目番号：TR-05】
設計レビューもコードレビューも、レビューを実施しただけでは品質は良くなりません。レビューで一番重要な事は、レビューの指摘事項に対して漏れなく対策を行って設計品質やコード品質を良くする事です。
そのためには、指摘事項を漏れなく・判り易く記録をして、その記録を元に対策が考えられ実行が済んでいるのかなど、指摘事項に関して着実にトラッキングする仕組みが必要になります。レビューの議事録を使ったり、指摘事項の一覧表を使ってトラッキングしたりトラッキングシステムを使ったりと手段はいろいろあります。どの方法が正解というのはありませんが、実際にどんな方法で指摘事項を記録してトラッキングしているのかを、確認します。
【項目番号：TR-06】
開発の進捗状況は社内の開発管理のために必要ですが、顧客向けの開発をしているのであれば、顧客との定期的な情報共有もまた大切です。当初の計画どおりに開発が進んでいるのなら問題ないのですが、残念ながら多くのソフト開発では開発の終盤になるにつれて工程遅れが見えてきます。この工程遅れが挽回できなれば、最終的にはリリース日程を後ろに遅らせる必要が出てきます。
その場合には顧客側でも様々な調整が発生するのでいろいろな社内調整が必要になります。そんな事がリリース日の直前に判明しても社内調整はとっても大変な事になります。ですので危なそうならできるだけ早めに対策をしておかないといけません。そのためには、開発の途中段階から顧客とも開発状況を共有してくのが良いので、そのような活動がでているかどうかを確認します。
【項目番号：TTR-07】
開発の状況についての情報共有は、担当者レベルだけでなく管理者層でも必要です。特に何等かの問題が起きた時には、委託元と受託先の担当者はなんとか解決しようとして努力するのですが、それでもダメな時にはもう１段上のレベルの管理者層での調整が必要になります。
そのような事態が起きた時には、かなり厳しい交渉も必要になるのですが、双方にとって良い解決策を見出すには、双方の管理者層が事態を正しく理解している事が大切です。そのために、担当者レベルほど頻繁でなくてもよいので、管理者層も情報を共有する場を定期的にもっておく事が大切です。 そのような活動を受託側が意識して実施するようになっているのか、を確認します。
【項目番号：TR-08】
開発受託先は受託した開発作業が終了したら成果物を委託元に納品します。ソフト開発業務の成果物ですので、設計書やソースコードや各種の取り扱い説明書やテスト報告書等が成果物になります。これらの成果物は委託元に納品する前に受託先の社内でレビューしておいて貰う必要があります。納品日までに間に合うように、予め社内のレビューの日程を決めて実施するようになっているか、できれば今委託している作業の成果物のレビュー日程が何時になっているかという具体的な項目を使って、受託先のレビューの計画状況を確認します。
トラッキングの次は品質保証です
トラッキングの次は品質保証についての確認項目について、次の記事で紹介します。