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

[Wayne-Turk，Open Tech Press]

解決法

　優れたビジネスルールの一つに「解決法を持たずに上司に問題提起をするなかれ」というものがある。従ってここでプロセスに関する問題についての解決法を幾つか提案しよう。プロセス主導型になってしまっている組織は、以下に提案するような解決法を組織文化に取り入れることでより良い組織になることができるだろう。

　最初の解決法は、プロセスを特化するということだ。言い換えるとプロジェクトの規模/タイプ/期間といった特定のパラメータに基づいてプロセスを調整するということだ。プロセスを特化することにより、短期間の単純なプロジェクトのために長々しい複雑な計画を用意することになるような不適切な義務が排除される。このようなプロセスの特化を得意とする企業の一つにSRA Internationalがある。SRA Internationalには新規のITプロジェクトを準備する際にプロセスを特化するというプロセスがあり、プロジェクトの規模／タイプ／期間といったさまざまなパラメータ群をスプレッドシートに入力することになっている。すると、スプレッドシートによって自動的にプロセスの特化作業の第一段階、つまり不必要な作業の削除が行なわれる。その後、プロジェクト管理者がその上司と一緒にそのほかの調整を行ない、プロセスをさらに特化する。その結果として最終的に、各プロセスごとに必要な行動やアウトプットがリストアップされる。多くの場合はそこまで手の込んだことは必要ないように思われるが、プロセスの特化という作業の存在自体は必要だろう。

　次の解決法は柔軟性を持たせるということだ。プロセスを必ずしも絶対的に不変のものとして扱うのではなく、強制力のない案内役と見なすべきだ。つまり特定の場合にはプロセスの一部を迂回したり変更したりしてもよいとしておくべきだ。といっても、このことはプロジェクト管理者やプロジェクトチームが好きな時に好きなことをしてよいと許可するものではない。既存のプロセスから外れる場合は、全体の管理者の承認を得て（そうでない場合でも全体の管理者は少なくともプロセスからの逸脱の計画について知らされるべきだ）、関係者全員に関して調整が行なわれるべきだ。典型的な例としては、緊急事態が発生し計画の変更が提案された場合などが該当するだろう。この場合、短縮されたプロセスが実行されることになるが、そのような場合にもテスト作業は必要なので行なわれるであろうが、そのほかのプロセスの一部は必須ではなく省略されることになるだろう。なおプロセスから逸脱することが頻繁である場合には、あらかじめ修正した代替案を用意しておく方がよいかもしれない。そのような代替案の方が今後の新たな改善版のプロセスとして採用される可能性さえある。

　3つめの解決法は、プロセスのレビューと継続的な改善を行うということだ。すべてのプロセスは定期的にレビューされるべきであり、プロセスが破たんしてしまってからでは遅い。改善のための変更や合理化は常に行うべきだ。状況、要求、資金、関係者、技術はどれもすべて常に変化している。そのうちのどれか一つでも変化すれば、プロジェクトにはプロセスの変更の必要性が生まれる可能性がある。「これまでこのやり方で来たから」ということだけが理由のプロセスには必ずしも今後も使用するだけの価値があるとは限らないため、変更も検討するべきだ。また最も良い方法や教訓を求めてほかの人によるプロセスを調べることも、継続的に行うべきだろう。

まとめ

　要するに、ITプロジェクトにおけるプロセスとその運用については、バランスと常識とが大切ということだ。プロジェクトには、優良で、繰り返し行うのに適していて、確固とした、実際に機能するプロセスが必要なのであり、時間やコストが余分にかかってしまうような厳格なプロセスは不要だ。企業には、結果が二の次になってよいほどプロセス主導になる余裕はないはずだ。プロセスは特化され、柔軟であり、継続的に改善する必要がある。また当然のことながらプロセスはうまく行かなければ意味がない。プロセスはプロジェクト管理者を救うこともあるが、不十分でプロジェクトにマイナス影響を与えるような構成の場合、とどめを刺すこともある。

Wayne Turkは、フリーランスの経営コンサルタント／プロジェクト管理コンサルタントで、Suss Consulting社と提携している。退役空軍中佐であり、防衛関連企業を引退後、米国防総省を含む連邦政府関係機関や非営利組織において情報技術プロジェクト、政策展開／戦略立案プロジェクトのサポートを務めた。多くの記事を発表しており、現在プロジェクト管理についての書籍を執筆中。

原文へのリンク