メディア

プロセスはチャンスが訪れるたびに改善する/パート2：プロセスと基準（後編）：The Rational Edge（3/3 ページ）

» 2007年11月01日 12時00分公開

[Scott W. Ambler, Per Kroll，IBM]

前のページへ 1|2|3 　　　　　　

手法

　このカテゴリーの手法は、その背景に目標や報奨金を伴って情報に基づいた執行部の意思決定を促進する効率的評価指標戦略を促進する。

シンプルで関連性の高い評価指標
継続的なプロジェクト監視

シンプルで関連性の高い評価指標

　測定は、必要に応じた是正処置を取れるよう進ちょく状況を理解するために必要だ。しかし、評価指標使用時には重要な至上命令が2つある。

　 評価指標はシンプルでなくてはならない。大半の組織は、評価指標を全く使わない（訳も分からないで作業する）か、使い過ぎるかのいずれかだ。経費の金額や未解決の欠陥数といったシンプルな評価指標には2つの重要な特性がある。1つ目は、収集が簡単な評価指標であるということ、そして理想的には評価指標が自動収集できることだ。手作業による評価指標収集では遅くて障害が発生しやすい場合が多い。2つ目に、何か誤りに気付いたときに対応ができるよう評価指標は理解および解釈しやすくなくてはならない。

　評価指標は一般的でなくてはならない。評価指標は組織全体で利用されている必要がある。もしプロジェクトごとに評価指標があり、それらの評価指標をそれぞれが違った形で解釈されると、幹部による監視が不可能になる。チームは、プロジェクトに関連した新たな評価指標を課すことを余儀なくされる場合もあるが、組織全体の測定が最新に保たれている限りそれでも構わない。

　評価指標には関連性がなくてはならない。評価指標を収集する多くの組織は、結果に応じた行動をあまり起こさない。これは評価指標に十分関連性がないためである場合が多い。評価指標ごとに、特定のしきい値に応じた対応を指定する必要がある。対応を指定できないなら測定する意味はない。さらに、さほど重要でない問題に注目したり、対応したりするのではなく、絶対不可欠なものに重点を置きたいので、評価指標は最小限に抑えるべきだ。

・シンプルで関連性の高い評価指標

　適切に処理が行われれば、シンプルで関連性の高い評価指標には以下のように多くのメリットがある。

　ファクトベースのガバナンス。チームが使う開発や管理ツールによって自動的に収集された評価指標は、現状に関する正確な情報を提供する。自動化された評価指標は手作業や間違った手段によるデータの収集、分析、あるいは管理と、それに関連する測定からエラーを削減する。また、自動収集の方が手作業による作業よりも素早く頻繁に行うことができる。これらすべてがより正確かつ最新のデータに基づくガバナンス、あるいはファクトベースのガバナンスと呼ばれるものへとつながっていく。

　苦労のないガバナンス。自動収集は時間と費用の掛かる手作業による収集、分析、管理のニーズも減少させる。シンプルな評価指標は、手作業による評価指標の収集、分析、および管理を余儀なくされた場合の複雑性を低減させる。これにより、ガバナンスに関連するコストとオーバーヘッドが削減され、苦労のないガバナンスが実現する。

　積極的ガバナンス。関連性の高い評価指標は、そうでない評価指標よりも一般的に早い段階で何かがおかしいことに気付かせてくれる。例えば、欠陥が増加傾向にあることを見れば、このままいくと次の反復終了後には品質の低いビルドを配布することになることが分かるので、この反復では機能を抑えることによって品質の高いビルドの配布を保証できる。早い段階で問題を突き止めれば、事後の火消しを余儀なくされるのではなく、選択の自由を得ることができる。

　プロセスの改善。評価指標によって、何がうまく機能し、何がうまく機能しないかが理解できるようになる。これにより、過去の間違いや、将来に向けた問題回避に関するオープンな議論に必要な情報が提供される。

・トレードオフ

　評価指標の収集には以下のように重要なトレードオフが多数ある。

　評価指標の数。評価指標収集を始めると、多くの種類を集めたくなる。その方がもっと「厳密」に感じられるし、その余分な評価指標がいつか役に立つかもしれない。しかし、評価指標の数はまずは最小限に抑え、必要に応じて後から新たな評価指標を追加していくことを強く勧める。少ないほどよいことを基本に、評価指標の数を抑えることを推奨する。新しい評価指標を採用したら、古い評価指標は排除する。さもないと、評価指標の収集作業が複雑かつコスト高になり、それが提供する価値も減少してしまう。最近使わない評価指標を収集し続ける理由はない。

　波風を立てる。評価指標の収集は、組織内の人間が隠しておきたかった特定の真実を明らかにする場合がある。評価指標がないことは、目隠しをして車を運転していることに事実上等しい。何もチェックせずに10カ月もプロジェクトを進めることを考えてみていただきたい。順調に思え、すべてスケジュールどおりに進んでいると思っても、プロジェクトの土壇場でそれが絶望的な状況にあることが分かったらどうなるだろう？たぶん、当初からプロジェクトには成功する見込みがなかったという言い訳を考えなくてはならないし、場合によってはそれをでっち上げなくてはならないかもしれない。分析する評価指標がないので、「顧客がひっきりなしに考えを変える」「予見不可能な技術的問題があった」「技術上の非互換性があった」といった言い訳をすることになる。ところが、評価指標があれば、これらのケースで誤った部分について少なくとも客観的な見方をすることができる。これは、組織内で取り組まなくてはならない問題など、複数の要因の組み合わせである場合が多い。

　投資。評価指標はタダではできない。これを自動化したい場合は先行投資が必要になる。手作業による評価指標を採用する場合は先行投資は少なくて済むが、作業に伴い徐々に投資が膨らんでいく。

　脱線。プロジェクトにはコストや品質などの特定のパラメータが与えられており、その範囲内で運営される。もしプロジェクトがこのパラメータの範囲を外れる、もしくは外れそうになったときのために、その脱線を指摘する評価指標が手元に必要になる。

　信頼。評価指標は誠実な議論、学習、報奨のために非常に貴重なツールだ。評価指標の値が悪いことで罰してはならないが、値の悪い評価指標を無視する者は罰しなくてはならない。

　人と話し合うことも重要。評価指標は時として問題の存在を指摘するが、優れた判断を下すために必要な情報をすべて提供することは絶対にない。根本的な原因を理解するためには、定期的に人と話し合う必要がある。

・アンチパターン

　評価指標には以下のようなアンチパターンがある。

　資料ベースの達成価値。従来のガバナンスへのアプローチでは、「達成価値」の一定率を計上してから要件仕様や詳細設計書のような重要な資料の完成に向けて作業を進める。実際、大半の仕様には欠陥があるが、仕様に沿ったインプリメンテーションやテストを行うまではどのような欠陥かが分からない。従来の達成価値は、進行の安全性に対して誤った印象を与えてしまう。ソフトウェア開発プロジェクトの進展で唯一本当の基準となるのは、可動ソフトウェアの定期的な配布だけだ。

　行動を伴わない評価指標。特定のしきい値に達しても行動を伴わない評価指標の収集は、評価指標の収集コストを掛けながら何のメリットも享受していないため逆効果だ。

・推奨デフォルト

　ソフトウェア開発プロジェクトの次の分野をカバーする評価指標から着手することを推奨する。

価値。どこまで組織の価値を高めているのかを示す基準が必要だ。例えば、反復ごとに提供されるユースケース基準点など、チーム内部の機能基準に基づくプロジェクト速度は、どの程度までチームが機能をインプリメントしているのかを示す。この値は、配布された仕様ではなく、実際に機能するものを反映しなくてはならないことに注意したい。

　品質。欠陥の傾向など、アプリケーションの品質を示す基準が必要だ。

　コスト。人月（作業）や費用など、消費したリソースを示す基準が必要だ。

　これらの評価指標はプロジェクトの現状判断に便利であるだけでなく、チームが当初の期待値からどの程度逸脱したかの判断にも利用できる。期待値は業務事例レベルで時間、費用、使用リソースで設定することができ、プロジェクト全体を通じて定期的にアップデートできる。

継続的なプロジェクト監視

　継続的なプロジェクト監視は読んで字のごとしで、自動化された評価指標収集、プロジェクト審査、あるいは口コミ情報まで駆使してITプロジェクトの健全性を定期的に監視する。多くの組織では、ある一定の時期に数十もしくは場合によって数百のITプロジェクトが進行している。各プロジェクトの現状はそれぞれ異なり、その状況はライフサイクルを通じて変化する。場所や時間帯の異なるプロジェクトもあれば、組織内に複数のソフトウェアプロセスが存在する場合もある。このような難問があっても、効果的管理には各プロジェクトの監視が必要になる。さらに、逆行する変更や今後有望な機会には早急に対処したいので、プロジェクトは継続的に監視したい。

　プロジェクトを継続的に監視する方法は以下のように複数あり、これらを組み合わせることもできる。

1　自動測定。プロジェクトに関する評価指標が、プロジェクト全体を通じて毎日利用される既存のツールから自動的な手段によって取得される。これらの評価指標は、各プロジェクトのステータスを数値化できるよう、プロジェクトスコアカードソフトウェアを使って処理および表示される。

2　プロジェクトの審査。マイルストーンの審査をはじめとするプロジェクトの審査は、反復などの管理マイルストーンの最後に定期的に行われる。これにより、可動コードが配布されたこと、既存の利害関係者のニーズを満たしていること、そしてプロジェクトが健全であることが保証される。審査の副産物として、改善分野を特定し、成功を喜ぶことができる。

3　「事後」審査。「事後」審査は、システムがうまく本番環境に配布されたか、プロジェクトがキャンセルされたかのいずれかの理由からプロジェクトの最後に行われる。プロジェクトが成功裏に進んでいれば、プロジェクトのビジョンが達成されたかどうか、システムがそのメリット達成に向けて順調に進んでいるかどうか、そして利害関係者がプロジェクトの進ちょく状況に満足しているかどうかを評価することが目標になる。プロジェクトが失敗していると思われている場合は、チームメンバーに欲求不満を解消するチャンスを与え、願わくは作業を継続させ、今後同じ過ちを繰り返さぬよう改善可能な分野を特定させることが目標になる。ただ残念ながら、プロジェクトが失敗しながらこれらの目標が達成されることはほとんどないようだ。

4　対人コミュニケーション。時には、プロジェクトの現状を判断するには人の話に実際に耳を傾けるのが最良の方法となる。プロジェクトの進行状況を探り出したかったら、そのチームのメンバーに話を聞くのだ。評価指標を見ればプロジェクトで何かが起こっていることは分かるかもしれないが、実際にチームに話を聞いてみないと、実際に何が起こっているかは絶対に分からない。

　自動化された評価指標のアプローチは、注意の必要なプロジェクトを判断するためのプロジェクト監視活動のスケーリングを可能にする。マイルストーンの審査は価値の継続的配布を保証し、プロジェクト審査は経験全体から教訓を学べるようにする。

・メリット

　継続的なプロジェクト監視には以下のような複数のメリットがある。

1　ファクトベースのガバナンス。継続的にプロジェクトを監視すれば、最新の正確な事実に基づいたガバナンス活動が可能になる。一般的に、問題を指摘するものとしては、予想値との食い違いや、欠陥の増加などといったマイナスのトレンドがある。

2　早めのフィードバック。継続的監視により、問題を早く検知できるようになり、是正処置を早めに講じられるようになる。これにより、必要に応じてプロジェクトをスケジュールどおりに進めさせたり、損失がかさまないうちに中止させることもできる。

3　効果的ガバナンス。適切な評価指標（前述の「シンプルで関連性の高い評価指標」の手法参照）を監視すれば、「測定するものがそのまま得られる」（以下参照）ため、プロジェクトチームの適切な行動が促進される。継続的な監視は、各マイルストーンだけでなく、プロジェクト全体を通じて適切な行動を誘導する。

トレードオフ

　この手法には以下のような複数のトレードオフがある。

　適切な評価指標を特定する必要がある。測定するものがそのまま得られる。つまり、チームは評価指標として追跡を命じられたものを重要なものとして理解するため、測定されるものに必ず重点が置かれる。この心理的要因は、必ず正しいものを測定しなければならないことを意味する。最初は、投資、配布機能、そして欠陥の傾向から測定するのがよい。これらのシンプルな評価指標はプロジェクトチームの効率を判断するのに利用できるからだ。このコンセプトに関するさらなる詳細は「シンプルで関連性の高い評価指標」の手法を参照。

　柔軟になる必要がある。評価指標と、それによって明らかになる傾向はプロジェクト全体を通じて関連性が変化する。例えば、プロジェクトの「推敲」フェーズでは、各種技術の連携について学ぶ間に欠陥傾向の割合がしばらく高まる場合がある。また、その後の「構築」や「移行」では、欠陥傾向の割合が着実に低下することが予想される。プロジェクトのフェーズによって評価指標がどのように変化するかを理解することで、実際の異常を一段とうまく検知する体制が整う。

　「危険信号」は危険信号にすぎない。プロジェクトはそれぞれが異なり、どのプロジェクトチームも変化の激しい環境で作業をしている。対応の必要な長期的難問を示唆する危険信号もあるし、ガバナンス面の注意が不要な短期的障害を示唆する信号もある。プロジェクト関係者間の政治的な変化や、チームに一時的な問題を引き起こす新しい法律の議会通過など、しばしば「いろいろなことが起こる」のだ。

　自動化には投資が必要。短期的に見て、関心のある評価指標を自動的に収集するツールへの投資は必要になる。

　人との会話は必要。評価指標は危険信号を提供するだけであり、チームが直面している問題（あるいは機会）の種類を正確に指摘することはできないし、チームの支援に必要な情報を提供することもできない。プロジェクトを効果的に管理するには積極的にチームに関与し、密接に連携する必要が出てくる。

・アンチパターン

　プロジェクト監視には以下のようなアンチパターンがある。

　評価指標による管理。根本的な原因を適切に理解せず、報告された評価指標に基づいて兆候を修正する是正措置を取る。例えば、チームで報告された欠陥が1回の反復で57％増加したと仮定する。これは、チームが問題を抱えているか、もしくは優秀な調査テスターを採用しただけか、あるいは要件管理用に従来の欠陥レポートに加えて欠陥追跡ソフトウェアを使い始めた（その結果、プロセスが合理化され、全体の生産性が向上した）ことを示唆しているかのいずれかかもしれない。だが、チームと意見交換すれば、リリースを遅らせるべきか、通常どおり作業を継続すべきかが分かる。

　評価指標のはんらん。自動化された評価指標収集で一般的な問題が、簡単だからといって多数の評価指標を収集してしまうことだ。もちろん、膨大な数値は得られるが、これらは実際にどのような意味を持ち、どうすれば効果的に利用できるのだろうか？少数でも貴重な情報を提供する関連性の高い評価指標を持つことは、使い方のよく分からない評価指標をいくつも持つことよりはるかに重要だ。これらを収集すること事態が良いことだと考えられているようだ。量より質を目標にすべきである。

・推奨デフォルト

　「シンプルで関連性の高い評価指標」の手法を参照することから始めていただきたい。この手法は、評価指標をプロジェクトスコアカードソフトウェア経由で自動的に取得および表示するのに役立つからだ。プロジェクトが予想される方向から逸脱しているように思えるときは、プロジェクトチームのメンバーと話し合って評価指標が意味する内容を判断し、チームの方向性を改善したい。

パート3の予告

　連載の最後となる次回のパート3は、開発ガバナンスの学習に関連するポリシーと標準そして役割と責務をカバーする。ご期待いただきたい。

本記事は「The Rational Edge」に掲載された「Best practices for lean development governance Part II: Processes and measures」をアットマーク・アイティが翻訳したものです。

著者プロフィール

Scott W. Ambler,

Practice Leader, Agile Development,

Rational Methods Group, IBM

Per Kroll

Manager of Methods, IBM Rational, IBM

「The Rational Edge」バックナンバー