プロセスはITプロジェクトにとって最善の策とは限らない
しかしその一方でプロセスが過度に厳格である場合や不十分な構成である場合やコスト/スケジュール/品質にマイナスの影響を与える場合など、プロセス自体がむしろ思わぬ落とし穴となっている場合もある。以下では、プロセスを敵ではなく味方に付けるための定番で実用的なアイデアを紹介する。
ITの世界におけるプロセスの利点についてはおそらくご存じのことだろうが、ここで復習しておこう。
- プロセスは一般的にIT製品の品質と生産性を高める。
- プロジェクトチームが事後対応型ではなく事前対応型になる。
- プロジェクト間で人員を異動する場合や一人で複数プロジェクトを抱える場合に、プロジェクトの一員として働くことができるようになるまでの時間が短縮される。
- 規模の拡大/縮小が容易になる。
- 計画が改善される。
- 問題解決が迅速になる。
- リスク管理が改善する。
- 資金管理が強化される。
- 意思決定の改善に役立つ、有益な判断材料を収集しやすくなる。
- 仕事の位置付けや方法が把握しやすいため、チームのやる気や自信が強化される。
- ITプロジェクトにとって最重要プロセスの一つであるテストにおいて、テスト結果の品質が向上し製品が初版から問題なく機能するようになる。
- プロセスは、機能することが確認された後（場合によっては少しの変更を加えて）何度でも再使用することができる。
上記のような利点があるため、プロセスによってITプロジェクトは資金削減と時間短縮を実現できるはずだ。ところが常にそのようにうまく行く訳ではない。過度に強固であるプロセスについてよく聞かれる不満には、面倒で非能率的であることや、書類を多用すること、そして製品を出荷するための実際的な作業以外のことに多くの時間が費やされてしまうということなどがある。また別の不満には、プロセスが時としてあまりに厳格で融通が効かないということがある。
例えば6人と300時間のみが与えられた完了まで2週間というプロジェクトで、プロセス上義務づけられているからといって、プロジェクト管理計画や構成管理計画や品質保証計画等々の大掛かりな文書をいくつも作成するのはばかげている。もちろんこれは明らかに極端な例だが、しかし真実味のかけらもないという訳でもない。数人のプロジェクト管理者に尋ねてみれば、おそらく間違いなく似たような義務のある同じくらいばかばかしい現実のプロジェクトの話を聞くことができるだろう。
レビューのために多くのリソースや時間が必要となるプロセスもある。理論的には必ずしもそうではなかったとしても実際的には必ずそうなる。優れたプロセスはスケジュールを縮めることができるはずだが、実際に短縮が実現できることは稀だ。
プロジェクト管理の実務家兼著述家のQuaidとWardは、次のように指摘している。「プロセスは新しいこと、創造的なこと、予期しないことを行なうには著しく不適である。プロセスは未来のブレークスルーを生み出すためではなく、過去の成功例を再現するためのものである」。またプロジェクト管理者から共通して聞かれるその他の不満の一つとして、プロセスは変更することができないということがある。どのプロジェクトにおいても必ず緊急事態や不測の事態やその他の問題が次々に発生するので、厳格で融通の効かないプロセスでは対応が不可能であり、プロジェクトを成功に導くためには、ある程度の柔軟さが必要となる。QuaidとWardはまた、プロセスに対して過度に依存することから生まれる問題をさらに2点指摘している。つまり、プロセスに依存した組織は失敗を毛嫌いする（このことは常に得策であるとは限らない）という問題点と、個人の責任の範囲を限定する（一部の人にメリットを与えることになる）という問題点だ。
その他にも過度に強固なプロセスに伴う問題点として以下のようなものがある。
- 従業員側に、仕事に対するコントロール、創造力、仕事の楽しさが失われるという不安が存在する。
- 経営者側に、仕事に対するコントロールが失われるという不安が存在する（一見矛盾するように思われるかもしれないが、実は従業員側も経営者側もどちらも仕事に対するコントロールが失われることを懸念している）。
- 特定のプロジェクトにはプロセスが適さない恐れがある。
- 余分で不必要な作業が義務づけられる恐れがある。
これらに加え、プロセス主導型になってしまっている組織が抱える最大の潜在的問題点として、製品よりプロセスが重視されるということがある。言い換えると実質ではなく形式が重視されるということでもある。これは起こる可能性のある中でも最悪の筋書きだと言えるだろう。ITのプロジェクト管理について特に言及した訳ではないものの、チャーチル英元首相が次のように完璧に要約している。「戦略がどれほど立派なものであろうと、時には結果を顧みるべきだ」。
焦点が最終結果や製品ではなくプロセスのみに当てられてしまうと、誰もが損をする。品質保証部門や構成管理部門の担当者たちは文書や手続きや構成部品といった事柄に陶酔しているのかもしれないが、実際には品質は落ち、目標達成までの時間が長くかかり、エンドユーザは望むものや必要とするものを得ることができないという結果になる。品質保証や構成管理のためのプロセスは基本的には有益だが、真に重要なことから焦点が外れていてマイナスの影響がある場合などには有益ではなくなる。
解決法
優れたビジネスルールの一つに「解決法を持たずに上司に問題提起をするなかれ」というものがある。したがってここでプロセスに関する問題についての解決法をいくつか提案しよう。プロセス主導型になってしまっている組織は、以下に提案するような解決法を組織文化に取り入れることでより良い組織になることができるだろう。
最初の解決法は、プロセスを特化するということだ。言い換えるとプロジェクトの規模/タイプ/期間といった特定のパラメータに基づいてプロセスを調整するということだ。プロセスを特化することにより、短期間の単純なプロジェクトのために長々しい複雑な計画を用意することになるような不適切な義務が排除される。このようなプロセスの特化を得意とする企業の一つにSRA Internationalがある。SRA Internationalには新規のITプロジェクトを準備する際にプロセスを特化するというプロセスがあり、プロジェクトの規模/タイプ/期間といった様々なパラメータ群をスプレッドシートに入力することになっている。すると、スプレッドシートによって自動的にプロセスの特化作業の第一段階、つまり不必要な作業の削除が行なわれる。その後、プロジェクト管理者がその上司と一緒にその他の調整を行ない、プロセスをさらに特化する。その結果として最終的に、各プロセスごとに必要な行動やアウトプットがリストアップされる。多くの場合はそこまで手の込んだことは必要ないように思われるが、プロセスの特化という作業の存在自体は必要だろう。
次の解決法は柔軟性を持たせるということだ。プロセスを必ずしも絶対的に不変のものとして扱うのではなく、強制力のない案内役とみなすべきだ。つまり特定の場合にはプロセスの一部を迂回したり変更したりしてもよいとしておくべきだ。と言っても、このことはプロジェクト管理者やプロジェクトチームが好きな時に好きなことをしてよいと許可するものではない。既存のプロセスから外れる場合は、全体の管理者の承認を得て（そうでない場合でも全体の管理者は少なくともプロセスからの逸脱の計画について知らされるべきだ）、関係者全員に関して調整が行なわれるべきだ。典型的な例としては、緊急事態が発生し計画の変更が提案された場合などが該当するだろう。この場合、短縮されたプロセスが実行されることになるが、そのような場合にもテスト作業は必要なので行なわれるであろうが、その他のプロセスの一部は必須ではなく省略されることになるだろう。なおプロセスから逸脱することが頻繁である場合には、あらかじめ修正した代替案を用意しておく方がよいかもしれない。そのような代替案の方が今後の新たな改善版のプロセスとして採用される可能性さえある。
3つめの解決法は、プロセスのレビューと継続的な改善を行なうということだ。すべてのプロセスは定期的にレビューされるべきであり、プロセスが破綻してしまってからでは遅い。改善のための変更や合理化は常に行なうべきだ。状況、要求、資金、関係者、技術はどれもすべて常に変化している。そのうちのどれか一つでも変化すれば、プロジェクトにはプロセスの変更の必要性が生まれる可能性がある。「これまでこのやり方で来たから」ということだけが理由のプロセスには必ずしも今後も使用するだけの価値があるとは限らないため、変更も検討するべきだ。また最も良い方法や教訓を求めて他の人によるプロセスを調べることも、継続的に行なうべきだろう。
まとめ
要するに、ITプロジェクトにおけるプロセスとその運用については、バランスと常識とが大切ということだ。プロジェクトには、優良で、繰り返し行なうのに適していて、確固とした、実際に機能するプロセスが必要なのであり、時間やコストが余分にかかってしまうような厳格なプロセスは不要だ。企業には、結果が二の次になってよいほどプロセス主導になる余裕はないはずだ。プロセスは特化され、柔軟であり、継続的に改善する必要がある。また当然のことながらプロセスはうまく行かなければ意味がない。プロセスはプロジェクト管理者を救うこともあるが、不十分でプロジェクトにマイナス影響を与えるような構成の場合、とどめを刺すこともある。
Wayne Turkは、フリーランスの経営コンサルタント/プロジェクト管理コンサルタントで、Suss Consulting社と提携している。退役空軍中佐であり、防衛関連企業を引退後、米国防総省を含む連邦政府関係機関や非営利組織において情報技術プロジェクト、政策展開/戦略立案プロジェクトのサポートを務めた。多くの記事を発表しており、現在プロジェクト管理についての書籍を執筆中。
NewsForge.com 原文
