プロセスはITプロジェクトにとって最善の策とは限らない：マネジャーの教科書（1/2 ページ）

ITプロジェクトの成功には、優良で、繰り返し行うのに適していて、確固とした「プロセス」が必要不可欠だ。しかし一方で、プロセス自体がむしろ思わぬ落とし穴となっている場合もある。以下では、プロセスを敵ではなく味方につけるための定番で実用的なアイデアを紹介する。

[Wayne-Turk，Open Tech Press]

　ITプロジェクトの成功には、優良で、繰り返し行うのに適していて、確固とした「プロセス」（工程、マニュアル）が必要不可欠だ。確固としたプロセスがあるからこそ、プロジェクトというパズルの各ピースが組み合わさり、全体として1つのアウトプットを出すことができる。プロセスがあることによって仕事が毎回同じ方法で進められると期待することができ、それによってチームのメンバーや顧客は、何かが欠けている可能性を心配する必要もなく、信頼性が高く実用的で使い物になる結果を得ることができると確信することができる。

　しかしその一方でプロセスが過度に厳格である場合や不十分な構成である場合やコスト／スケジュール／品質にマイナスの影響を与える場合など、プロセス自体がむしろ思わぬ落とし穴となっている場合もある。以下では、プロセスを敵ではなく味方につけるための定番で実用的なアイデアを紹介する。

　ITの世界におけるプロセスの利点についてはおそらくご存じのことだろうが、ここで復習しておこう。

• プロセスは一般的にIT製品の品質と生産性を高める
• プロジェクトチームが事後対応型ではなく事前対応型になる
• プロジェクト間で人員を異動する場合や一人で複数プロジェクトを抱える場合に、プロジェクトの一員として働くことができるようになるまでの時間が短縮される
• 規模の拡大／縮小が容易になる
• 計画が改善される
• 問題解決が迅速になる
• リスク管理が改善する
• 資金管理が強化される
• 意思決定の改善に役立つ、有益な判断材料を収集しやすくなる
• 仕事の位置づけや方法が把握しやすいため、チームのやる気や自信が強化される。
• ITプロジェクトにとって最重要プロセスの一つであるテストにおいて、テスト結果の品質が向上し製品が初版から問題なく機能するようになる。
• プロセスは、機能することが確認された後（場合によっては少しの変更を加えて）何度でも再使用することができる。

　前記のような利点があるため、プロセスによってITプロジェクトは資金削減と時間短縮を実現できるはずだ。ところが常にそのようにうまく行く訳ではない。過度に強固であるプロセスについてよく聞かれる不満には、面倒で非能率的であることや、書類を多用すること、そして製品を出荷するための実際的な作業以外のことに多くの時間が費やされてしまうということなどがある。また別の不満には、プロセスが時としてあまりに厳格で融通が効かないということがある。

　例えば6人と300時間のみが与えられた完了まで2週間というプロジェクトで、プロセス上義務づけられているからといって、プロジェクト管理計画や構成管理計画や品質保証計画などなどの大掛かりな文書を幾つも作成するのはばかげている。もちろんこれは明らかに極端な例だが、しかし真実味のかけらもないという訳でもない。数人のプロジェクト管理者に尋ねてみれば、おそらく間違いなく似たような義務のある同じくらいばかばかしい現実のプロジェクトの話を聞くことができるだろう。

　レビューのために多くのリソースや時間が必要となるプロセスもある。理論的には必ずしもそうではなかったとしても実際的には必ずそうなる。優れたプロセスはスケジュールを縮めることができるはずだが、実際に短縮が実現できることは稀だ。

　プロジェクト管理の実務家兼著述家のQuaidとWardは、次のように指摘している。「プロセスは新しいこと、創造的なこと、予期しないことを行うには著しく不適である。プロセスは未来のブレークスルーを生み出すためではなく、過去の成功例を再現するためのものである」。またプロジェクト管理者から共通して聞かれるそのほかの不満の1つとして、プロセスは変更することができないということがある。どのプロジェクトにおいても必ず緊急事態や不測の事態やそのほかの問題が次々に発生するので、厳格で融通の効かないプロセスでは対応が不可能であり、プロジェクトを成功に導くためには、ある程度の柔軟さが必要となる。QuaidとWardはまた、プロセスに対して過度に依存することから生まれる問題をさらに2点指摘している。つまり、プロセスに依存した組織は失敗を毛嫌いする（このことは常に得策であるとは限らない）という問題点と、個人の責任の範囲を限定する（一部の人にメリットを与えることになる）という問題点だ。

　そのほかにも過度に強固なプロセスに伴う問題点として以下のようなものがある。

• 従業員側に、仕事に対するコントロール、創造力、仕事の楽しさが失われるという不安が存在する。
• 経営者側に、仕事に対するコントロールが失われるという不安が存在する（一見矛盾するように思われるかもしれないが、実は従業員側も経営者側もどちらも仕事に対するコントロールが失われることを懸念している）。
• 特定のプロジェクトにはプロセスが適さない恐れがある。
• 余分で不必要な作業が義務づけられる恐れがある。

　これらに加え、プロセス主導型になってしまっている組織が抱える最大の潜在的問題点として、製品よりプロセスが重視されるということがある。言い換えると実質ではなく形式が重視されるということでもある。これは起こる可能性のある中でも最悪の筋書きだといえるだろう。ITのプロジェクト管理について特に言及した訳ではないものの、チャーチル英元首相が次のように完璧に要約している。「戦略がどれほど立派なものであろうと、時には結果を顧みるべきだ」。

　焦点が最終結果や製品ではなくプロセスのみに当てられてしまうと、誰もが損をする。品質保証部門や構成管理部門の担当者たちは文書や手続きや構成部品といった事柄に陶酔しているのかもしれないが、実際には品質は落ち、目標達成までの時間が長くかかり、エンドユーザーは望むものや必要とするものを得ることができないという結果になる。品質保証や構成管理のためのプロセスは基本的には有益だが、真に重要なことから焦点が外れていてマイナスの影響がある場合などには有益ではなくなる。