アンチパターンその2 「細かすぎるリソース管理」
西郷智史氏：アンチパターンの2つ目は、細かすぎるリソース管理です。先ほど、計画の時にもリソースというキーワードが出ましたが、みなさんはリソースの管理をどのようにしているでしょうか？
よくあるのが、日単位・時間単位でリソースの負荷調整を詳細に行うこと。IT業界でよくやっています。「何にどれぐらいの時間を使ったの？」と後で集計して、この人は設計や会議、管理などにどれぐらいの時間を使っているのか、そういった細かい管理をするケースがあると思います。
（スライドを示して）「Let's Check」の1つ目を見てください。例えば、「Aさんは、Xというプロジェクトに0.5、Yに0.3、それ以外に0.2の割合でアサイン」と、小数点を用いてリソース負荷を管理しているケースはないですか？ マネージャーはよくこのようなことになりがちです。
あとは、すべての負荷が常に1.0になることを目指してしまうことがあります。0.5などの時期があると、「この人はリソースに空きがあるんだ。だから、1.0になるようにしないといけない」と、どうしても考えてしまう。
もう1つ。初期に細かくリソースの計画をするものの、その後はぜんぜん更新されないこともあるのではないでしょうか？ この細かいリソース管理がどのような悪さをしていくのかを見ていきたいと思います。
リソースの稼働率を100パーセントにすることが目的になってしまう
例を挙げます。（スライドを示して）田中さんから斎藤さんまで、プロジェクトや保守などと書いてあります。足し算すると、4月の田中さんは1.0になるようになっています。吉田さんは0.7と0.3で1.0になります。このプロジェクトは、これぐらいの工数を割いて1.0になるようにしましょう、と計画されています。
全部足すと1.0になるのですが、それは同時にメンバーの作業に空きがないことを意味しています。みんな1.0、つまりパツンパツンで仕事が詰まっている状態です。一見して非常に生産性が高いと捉える人もいるでしょう。みんなが常にフル稼働しているので、「すごく生産性が高いじゃん」「あのチームは優秀だね」と思う人もいると思います。
そのような思考がある場合、4月の吉田さんであれば0.7で0.3の空きがあり、「これをやっておいて」と別の作業を振ることもあるのではないかと思います。これの何が問題かというと、メンバーの稼働率を上げること自体が目的になってしまっている点です。
よく考えてみてください。受注して、プロジェクトを実行して、お客さんに届ける。つまり、プロジェクトのQCDを満たすことが目的なのに、いつの間にかリソースの稼働率を100パーセントにすることが目的になってしまっています。
もしかすると、リソースの稼働状況を全部1.0にしなくても、プロジェクトのQCDを満たすことができるかもしれません。逆に、全部1.0にすることによって、QCDを満たせなくなるかもしれません。メンバーの稼働率を上げることだけに終始してしまうと、部分最適になってしまうケースがあるのです。
そうなってくると、結果的にこのPMは、プロジェクトのQCDを満たすことではなく、いかにメンバーに仕事を与えるか、いかにメンバーに空きを作らせないか、に辻褄を合わせることに翻弄されてしまいます。つまり、目的とはかけ離れた作業に追われてしまうことになってしまうのです。
最初は個人単位ではなく、チーム単位で管理する
その回避策です。私たちは、個人単位ではなく最初はチーム単位での管理に切り替えることをお勧めしています。もちろん、個人単位での管理は最終的にはやらないといけません。しかし、特に最初の段階は、チーム単位での管理に切り替えたほうがいいと言っています。
2つ目の回避策は、プロジェクトの完了ペースを上げることを最優先にすることです。人に仕事を与えることが目的なのではなくて、どうやったらプロジェクトの完了ペースやスピードを最大化できるのかを最優先とするのです。この考えを持つことが2つ目です。
最後は、傾向・トレンドを把握することです。これは見てもらったほうが早いので、後ほど説明します。
1つ目の、チーム単位での管理に切り替えるという回避策について説明します。（スライドを示して）この例では、設計担当のチームにリソースが6人います。今、各設計担当のところに「3」「1」などの数字が入っています。このようにタスクに割り当てる時に、チームごとでアサインしておきます。
個人単位ではなくチーム単位にしておくのです。ただし、これはあくまでも計画段階です。実行中、例えばどこかが3人必要な時は、最適なリソースとして6人のうちの3人を与えましょう、と判断します。最初のタスクを1人でやるのと、2人でやるのと、3人でやるのと、どれが一番完了ペースが速いかを考えます。
「6人全員で設計したらいいのでは？」と思うかもしれませんが、6人だと逆に人数が多すぎることがあります。例えば、残りの3人に教えないといけないし、管理もしないといけないので、3人が最適だ、となります。スピードが一番速いのは3人、そういった観点ではじめは「3」と入れておきます。
「3」と入れて、実行段階で「鈴木さんと佐藤さんと田中さんでやってね」と指示します。要するに、実行段階で個人名をアサインしておくことが、このプロジェクトのペースが一番速くなるリソースのアサイン方法となります。
とはいっても、計画段階では特定の人しかできないこともあると思います。例えば、該当のシステムをよく知っている・よく知らない、ネットワークはこの人が詳しい・データベースはこの人が詳しいなど、ものづくりの設計の場合にはさまざまな担当があるケースもあると思います。
絶対にその人が必要だという時には、そのうちの1人をあらかじめ押さえておく。リソースと役割で押さえておくことが一番いいと思います。
負荷のトレンド・傾向を把握しておく
あとは、トレンドを把握することが大切です。（スライドを示して）ちょっとこれを見てください。あるツールの画面なのですが、プロジェクトがこのバーだと思ってください。
1、2、3、4、と何個かあって、この中に、先ほど言ったリソースの設定をします。プロジェクト全体を足し算して、下にリソース負荷を出しています。よく見てもらうと、この単位が「チームリーダー」「システムエンジニア」などの役割の単位になっています。トレンドと言っているのは、リソースの負荷の管理において、負荷のトレンド・傾向がどうなっているかを把握しておくぐらいで十分だからです。
自分の仕事をちょっと思い返してもらいたいのですが、個人単位、かつ、リソースの細かい設定まで計画しておいて、これどおりにいくことはほぼないと思います。（スライドを示して）「プロジェクトAが忙しくなってしまって、ほぼ『1』取れないといけない」「保守で割込みがあって、ぜんぜんこちらの部署でできない」など、計画どおりに実行されないことが多いと思います。
計画を緻密に並べておいても、結果としてこうなることはほぼあり得ないので、細かく計画してもあまり有益に使えないのであれば、これぐらいざっくりと傾向として見ておくだけで十分です。
（スライドを示して）この例でいうと、この時期のシステムエンジニアのチームに180パーセント、2倍ぐらいの負荷がかかると見ておきます。そうすれば、2ヶ月後にやってくる8月のこの負荷に対して、もう少しプロジェクトを前後にずらせないか？ などと検討することができます。
もしくは、協力会社がいれば、「この時期に人が足りなくなりそうだから、人を入れることはできないかね」などと先手を打つことができます。先手を打つことに関していえば、見る時はこのぐらいのトレンドで十分だと思います。
2つ目のアンチパターンの例についてです。細かいリソース管理をして、かつ、100パーセント空きがないように人を埋めておく。これも良かれと思ってやっているはずです。
なぜなら、みなさんは生産性を上げたいからです。生産性を上げるためには、人をフル回転させればいいと考えます。しかし、後でリソース管理が不能に陥ってしまったり、もっとリソースを集中できればペースが速くなるけれど、はじめに細かい計画を立てたがゆえに完了ペースがなかなか上がっていかなかったりします。
はじめは役割で入れておいて、リソースの負荷はトレンドぐらいで見ておく。そうすれば、最適な粒度で管理でき、かつ、このプロジェクトにおいて一番速いスピードが出せる環境が作れるというのが、2つ目のアンチパターンになります。
（次回へつづく）
