2012年7月7日土曜日

プロジェクト・マネージャの「やってはいけない」

プロジェクト・マネージャの「やってはいけない」

itpro.nikkeibp.co.jp | Nov 30th -0001

 子供の頃、テレビのアニメやドラマを見ていると大人が会社のオフィスで働くシーンを見ることがあった。手書きの書類を作成していたり、書類にハンコを押したりしている大人たちが働く姿をよく目にしたものだ。

 現代の仕事の主役は書類からメールに移り変わった。システム開発プロジェクトの現場でもそれは同じだ。PM(プロジェクトマネジャー)が1日に受信するメールを数えてみると、多い時には100を越えるメールを受信していることもあるだろう。

 さてそのとき、いったいどれくらいの時間を受信したメールをさばくのに費やすことになるだろうか。100通のメールのうち、8割は目を通すとして試算してみよう。メール1通の内容を見るのに30秒かかるとすると、トータルで40分ほどになる。

 さらにメール全体の2割を返信したとする。1件当たりに要する時間を平均10分とすると、返信作業に200分かかる。受信メールの確認と合わせると240分、つまり1日の業務時間の半分に当たる4時間がメールの処理に割かれていることになる。

 実際にはここまで多くはないだろうが、1日のうちにメールの処理に関わる時間は確実に増えている。システム開発プロジェクトでもコミュニケーションの手段としてメールは欠かせないからだ。1日のうちにメールに関わる時間は多くなるのは当然だろう。

 PMはこのとき、メールをさばくことを仕事にしてはいけない。進捗状況の把握、利用部門から寄せられる課題の対応状況といった、システム開発に関する本来の仕事にまで手が回らないからだ。

バックログがたまっていたKさんのケース

 Kさんはある企業の情報システム室の室長で、社内システム開発プロジェクトのPMも務めている。システム開発だけでなく運用中のシステムの障害対応や保守作業も、幅広く見ている。ここ最近は社内の各部門から依頼される保守や開発要望が増えてきたため、各部門の要望にタイムリーに応えきれていない状況だった。

 障害対応などの突発的な仕事が多いこともあり、作業のバックログがたまりにたまっている。ITエンジニアの中途採用の募集をかけてはいるものの、なかなか適切な人材が来てくれない。

 「なぜバックログがたまるのだろうか」。Kさんは自らの仕事を振り返ってみた。すると、「メールを処理する作業に費やしている時間は増えているよな」とふと思った。メール処理をしたら会議に入って、戻ってからまたメールを処理して次の会議へ…という毎日が繰り返されて1日が終わっているような気がした。

 利用部門の担当者からも、次から次へとメールは舞い込んでくる。その日の朝も、会社に着いてPCの電源を入れてメールソフトを開いたら、前日帰宅後に届いたメールが20件ほどたまっていた。これらの処理に1時間かかった。

 「バックログがたまっていくのは、私だけではなく、メンバーもメール処理で時間がかかっているからかもしれない」という考えがKさんの頭にふと浮かんだ。

 思えばここ最近、Kさんが作業を依頼したときのメンバーの応対はつれない。PCに向かいっぱなしのメンバーに依頼をすると、露骨に嫌な顔をしたり、「今、手いっぱいなので、後にしてください」と無愛想に答えたりすることが多くなっていた。メンバー間の人間関係もよくない。すぐそばにいる相手に、「ずっと前にメールで依頼したのに何でやってくれないんだ」と、声を荒げるメンバーもいる。

 Kさんはメンバーが落ち着いている時を見計らって、メールの処理に時間がかかっているかどうかを尋ねてみた。すると「そうなんですよ、Kさん。メール処理、作業、メール処理、会議、メール処理…というように作業や会議の合間にメール処理を何度も繰り返しているんです。本来やるべき作業にかけられる時間が非常に少なくて正直困ります」という答えが返ってきた。

 Kさんと同じくメンバーもメール処理に時間がかかっていることにフラストレーションをためていたのだ。「ここは実態をつかんだ上で、仕事のやり方を根本的に見直そう」。こう判断したKさんは早速、メンバー4人とともに、日々行っている仕事の棚卸しをしてみることにした。5日間、自分たちの作業時間を細かに記録。その結果を集計してみた(表1)。

表1●システム室5人の1週間(5日間)の作業時間の内訳(単位:時間)

 5日が過ぎ結果を出してみてKさんは驚いた。集計の結果、なんとメール作業が全体の37%にも達し、本来システム室がメインでやるべきシステム業務(システム開発や運用トラブル対応など)に費やしている時間の割合(32.8%)よりも多かったのだ。

 メール作業の時間が多い人は、いくつかのメーリングリストに加入していたり、プライベートなメールのやり取りが多かったりしていることも分かってきた。メール作業の時間には、TwitterやFacebookなどのSNSをやっている時間も含まれていた。

メール本数3割削減を目指して作業を合理化

 こんなことでは要員を増やしたとしても、バックログは解消されそうにない。そこでKさんは次のような「システム室改革施策」を掲げ、実態をトラッキングしながらシステム室の作業の合理化を推進した(表2)。

表2●システム室改革施策
No. 施策 内容
1 目標稼働率の設定 システム室の稼働率(システム業務とシステム業務のための打ち合わせの割合)の目標を75%に設定する(部門内部の打ち合わせ時間は含まない)。
2 メール本数の削減 一日当たりのメール本数を3割削減することを目標に掲げる
3 SNS禁止 勤務時間中はTwitterやFacebookなどのSNSは禁止とする
4 メーリングリスト厳選 加入するメーリングリストなどは、業務に直接関係するものだけに絞り込む
5 依頼方法の変更 システム室への依頼は従来のメールから、社内ポータル上の「システム室への依頼登録」というWebサイトに変更。依頼内容は一元管理する

 まずは目標設定だ。システム室本来の業務である、システム業務に割く時間を、業務全体の75%以上にする目標を掲げた。達成しているかどうかは、システム業務とそれに関する打ち合わせの時間を記録して確かめる。打ち合わせはシステム業務のためのものとそれ以外に区分けして時間を計るようにした。

 目標はもう一つ設定した。メールの本数の3割削減である。各人の1日当たりのメール本数を数えさせ、そこから3割以上削減することを目標に設定した。いろいろなメーリングリストに加入しているメンバーには、ほとんど読んでいないものはメール配信を停止するようにもした。

 さらに、TwitterやFacebookなどのSNSも仕事中には閲覧しないようメンバーと申し合わせた。「仕事の情報源としては必要だ」と言い張るメンバーもいたが、Kさんが「本来の業務に専念するため稼働率の達成を優先しよう」と説得し了解を得た。

 システム室全体でもメール件数を削減する工夫を凝らした。効果が大きかったのは、システム室への依頼をメールではなく社内ポータルで受け付けるようにしたこと。利用部門の担当者からメンバーが直接依頼を受け付けることがなくなった。一方で、依頼事項が一元管理されるため、システム室のメンバー全員で情報を共有し優先順位を付けてシステム業務を進められるようになった。

 メールを減らすという目標を掲げたことで、メンバーの行動にも変化が生じた。それまでは、すぐ近くにいてもメールでやり取りしていたメンバーが、直接相手の席に行って話をするようになった。離れたところで仕事をしている利用部門の担当者とは、メールに代わりに、電話でコミュニケーションをとるようになった。

 メンバーたちは当初、いやいやながら従っていたが、次第に「やってみると思った以上に仕事がはかどる」という手応えを感じるようになった。「プロとしてもっとシステム業務を優先すべきだ」という意識がメンバーの中で高まったこともあり、半年後にはバックログをほとんどなくすことができた。

開発業務に時間を多く割くよう見直そう

 メールをさばいてばかりいると時間がどんどん過ぎていき、すぐに就業時間の終わりを迎えてしまうことは少なくない。PM本来の仕事であるマネジメント業務がなおざりの状態になってしまう。メンバーもメールをさばくのを仕事にしてしまうと、システム開発業務に時間を割けなくなり、プロジェクトそのものも進まなくなる。

 特に、メールの確認・返信がたまりやすいPMは、プライベートな時間までメールをさばくのが仕事になってしまうことも多い。そのようなPMはKさんの採った作戦を、自分自身の仕事に適用してもらいたい。自分の作業時間を棚卸調査し、どこに無駄があるのかを把握。続いて稼働率やメール削減率など自分なりの目標を設定する。そして、その目標達成のために何をすべきかを洗い出して実行に移してみよう。

梅田 弘之(うめだ ひろゆき)
システムインテグレータ 代表取締役社長 東芝、住商情報システムを経て、1995年にシステムインテグレータを創業。前職でProActive、現職でGRANDITという二つのERPパッケージの開発に関わるほか、ECサイト構築ソフトSI Web Shopping、開発支援ツールSI Object Browserシリーズなどのパッケージ開発を手掛けている。最近は統合型プロジェクト管理システムOBPMをリリースし、IT業界の合理化をライフテーマとして活動している。

Original Page: http://itpro.nikkeibp.co.jp/article/COLUMN/20120626/405343/

Shared from Pocket



Sent from my iPad