プロセス管理ツールで失敗する人しない人：プロセス改善のセキララ告白（3）（2/3 ページ）

どうして「ツール導入→現場の不評を買う→お蔵入り」となるのか。ツールに責任はない。成功の秘訣は運用上の創意工夫だった

[中山司郎 横河ディジタルコンピュータEPS事業センタ，＠IT MONOist]

ツールに期待したのが間違いだったのか？

アクション 1

　現状分析の結果、いままでの取り組みの方向性が間違っていなかったことは実証されました。しかし一方で、思っていた以上に個人に依存している部分が多いことや、見落としていたポイントが重要であったことも明らかになりました。

　例えば、WBSもその1つです。開発者個人が自分の作業を把握することはできても、管理者の状況把握という点では効果的な活用ができていないことが分かりました。WBSの粒度や階層が開発者ごとにばらばらだったために、管理の視点でプロジェクト全体の状況を大枠で見ることができなかったのです。

　また、計画は不明りょう、作業フローも大ざっぱであるという結果でした。それでも、何とかなってしまっていたために、問題の原因は短納期や変更の多発にあると思い込んでいて、計画をしっかり立てるという原点をおろそかにしていたのです。さらに、不具合や要件変更などは、その「件数」だけでも測定すれば、結果を活用できるという指摘もありました。

　このような分析結果を受けて、まずツール導入のトライアルプロジェクトを前に、WBSの「標準化」を試みました。開発者個人、リーダー、部門長それぞれが、何を見たいのかを明確にし、3階層までの構造を共通化することにしました。これなら、ツールの管理者のビューを通して、プロジェクト全体の状況把握も可能になりそうです。

　いままで、要件変更が多いからとか、一品物だからといって、敬遠しがちだった計画の標準化についても、取り組みを開始しました。ツールに用意されている標準的な項目をベースに、プロジェクト個々の特性に影響されないレベルのテンプレートを作成しました。これだけでも、計画時に押さえなければいけないポイントを見逃すことはなくなり、明りょうになるはずです。

　こうして、トライアルプロジェクトの中で、問題点を修正しながら、可視化と標準化を目指した進ちょく管理のツール運用が進んでいきました。ツール運用は、至っててうまくいっているかのように思えました。

アクション 2

　ところが、トライアルプロジェクトが進行していくと、ツールに対する要求も上がってきたのです。例えば、リーダーからは、初期計画や計画変更の際に、メンバーのスキルによる工程シミュレーションがほしいという声が上がりました。またメンバーからは、実績データを勤怠のデータにリンクしてほしいという要望も出てきました。何々の文書管理はどうするとか、個人レベルのスケジュール管理がうんぬん……、要求は日に日に多くなっていくのです。推進チームの中心であるA氏は、これらの声に耳を傾け、このツールで何とか実現できる方法がないものかと考え、試行錯誤を繰り返しました。

このツールも、やっぱりだめなのか。

　ベンダのプレゼンテーションに目がくらんでツールの選定を誤ったのか、停滞している状況から抜け出したいあまり見切り発車をしてしまったのか。A氏をはじめ、推進チームのメンバーはあらたな壁にぶつかりました。

　そのとき、A氏は、ツールベンダの言葉を思い出しました。

ツールは万能ではない。

ツールがあればうまくいくわけではない。

　ツールにすべてを求めても、うまくいくわけではないのです。このツールに求める役割と、求めるべきではない役割があるということに、A氏は気がついたのでした。そして、目的を忘れてはいけないということを思い出しました。

アクション 3

　A氏は、ツールを導入した目的をあらためて考えました。

可視化と標準化。

　例えば、勤怠と進ちょくとでは、見たいものが異なります。無理な運用をすれば、かえって手間が増えてしまってツール導入の効果がなくなってしまいます。「ここまでできるなら、これもできた方がいい」というツールへの過度の期待は、それ自体は悪いことではありません。しかし、業務の枝葉の部分にまで目を奪われて注力するより、まずは大きな目的に向かって進んだ方が満足できる結果になるはずだ、とA氏は思い直しました。

　大切なことは、いま自分たちが何を目指しているのかをメンバーに理解してもらうことだと考えた推進チームは、メンバー全員に、あらためて現在の活動に関する説明を行いました。幸いなことに、チームワークのあるこの部門のメンバーは、推進チームの説明で目的を再認識し、前向きな姿勢を取り戻しました。

　先発隊であるトライアルプロジェクトでは、ツールの中でまだ使えていない測定機能の活用に着手しました。測定する項目は、個人の作業時間に関連するもの以外に、不具合、変更といった最低限必要と思われるもののみを選んで記録していくのです。この現場では、製品の完成度に応じて、テストを3段階に分けて実施するプロセスを取っていました。それぞれの段階ごとの不具合やそれまでに発生した変更を集計して傾向をつかもうという計画です。