リソースを管理する
こんにちは。安藤大輔です。
子供が産まれてバタバタしているうちに、ずいぶん間が空いてしまいました。さて、前回のコラムでは「目標を管理する」ことをテーマにしました。今回はリソース管理のお話です。
復習すると、プロジェクトの目標を達成するために必要なリソース（ヒト・モノ・カネ）を活用し、QCDを満足するためのコスト管理、タイム管理、組織管理といった活動が求められる、ということを述べました。
■リソースは足りないもの？（PMに就く以前に考えていたこと）
リソース、と聞いて皆さんは何を思い浮かべますか？
ヒト・モノ・カネといった形あるもの、及び情報・知識・ブランドといった形のないものが存在すると思います。
PMに就く以前は、とにかく人的資源に悩まされました。単純にどこかから（ここではあえて「どこか」と表現しておきます）提示された計画ではヒトが足りない（あるいはスケジュールが短い）、アサインされたヒトのスキルが足りない、日本語が通じずコミュニケーションを取ることが難しいなど、IT業界（に限らないのかもしれませんが）の未成熟さをたっぷりと味わうことができました（このあたりの話に関しては、他の方のコラムなどにも多く書かれていますので割愛させていただきます……）。
また、コストに関してPMに就く以前は、プロジェクトに対してのコストが自身の管理下になかったせいか、とにかく残業・徹夜の連続で納期に間に合わせる、といったことも多数経験しました。このときプロジェクトに対してどの程度のコストがかかっていたかを今考えると、空恐ろしくなります（もちろんチーム丸ごと同じ状況だったため、自分だけがこのような状況に置かれたわけではありませんし、モチベーションなどさまざまな観点から眺めるともっと大変な状況だったと思います）。
話が少し逸れてしまいましたが、ITを専門にする、特にソフトウェア受託開発を行う会社にとって、仕事のほとんどはプロジェクトの形態を取るため、カネに関してはスポンサーが出す、というそもそも限られたものと見なします。そのため、リソースのほとんどはヒトで占められていることが一般的かと思います（組み込み系開発などではハードウェア費用も大きく関わることと思います）。そのため、よく聞かれる「リソースが足りない」ということは、ほぼ「ヒトが足りない」ということと同じ意味で使われることになります。
わたしがPMに就く以前は上述したように「頭数が足りない」「スキルが足りない」などの理由によって、どのようなプロジェクトでも慢性的に「リソースが足りない」状況になっていました。そのため、リソースといえば足りないもの、という単純な図式が頭の中ででき上がっていました。従って、「リソースを管理する」と言われても、足りないものをどうやって管理するのか、人員は増やせず（増やせないと命令される）、結局自分でなんとかするしかないものをどうするのか、まったく理解できないことでした。
■実際に体験したこと（計画フェイズ：段取り八分）
現在はこのような状況が晴れ、「リソースとは管理可能なもの」という認識をようやく得ることができました。プロジェクトの計画段階から想定したことと、実施段階での進ちょく管理などを通して、リソースがどのように推移し、コストがどのように消費されていくか見えるようにすることや、チーム、自社の経営（上司）陣、顧客とのコミュニケーションを密に取ることで、問題が発覚する前や発覚直後にそれらに対処することができるようになりました。
リソースに限った話ではありませんが、管理するために必要なことは何はともあれ計画です。「計画なきところに管理なし」「段取り八分」とはよく言われることで、これがなければプロジェクト進行中に計画との比較ができないため、「何に対して」「どうして」リソースが不足（あるいは充足）しているか、ということが分からない状態になってしまいます。
以前はリソースと言えば「足りないもの」と考えていた、と述べましたが、これは果たして本当にそうだったのか、実はよく分かりません。それは計画がなかった（あるいはメンバーには見えないところにあった）からだと現在は考えています（とはいえ、残業と徹夜が続いている状態は明らかに異常なのですが……）。
さて、実際にPMに就いた感想は、計画段階で考えることが非常に多いということです。プロジェクトに必要なスキルセットは何か、どの段階でどんなスキルの人間が必要か、それらは社内で十分にまかなえるのか、社外を活用する必要があるのか、またコストはどの程度まで許容できるのか、新人を入れた場合の教育はどのようにするのか、チームが計画通りのパフォーマンスを出せなかった場合どのような対処をしたらよいかなど、リソース1つ取っても、考えればきりがないほど出てきます。
この「どこまで考えるか」ということも非常に重要です。確かに考え出せばきりがありませんが、考えすぎると余計なことにまで時間を使うことになってしまいます。計画フェイズから実施フェイズに移行するタイミングをどこと見極めるか、ということは経験がないとなかなか判断がつかないことだということがよく分かりました（経験があれば、ある程度のところで「そろそろだな」ということが分かります）。
特に、リスクに関しては重要なものだけに、対応策を検討しておくことが大切です（計画段階ではほぼ重要なものしか出ませんが）。重要度・影響度で重み付けを行い、ある一定のラインを超える項目に対して事前に対応策を検討しておく、というものです（対応策は回避・受容・軽減・転嫁のパターンが基本です）。これをすべてのリスク項目に対して実施してしまうと、「考えすぎ」になってしまいます。ただし、リスクを定量的に評価して見積もることは欠かせません（これはバッファなどで表現されたりします）。
わたしがPMを経験してきた中で、とくに重要だと感じた点は、メンバー全員（人数が多い場合は主要メンバー）で計画を立てるということです。できれば見積もり段階から参加することが望ましいと思います。そのようにすると、ある程度メンバーの頭の中で初期設計ができ上がり、より精度の高い計画ができ上がります。リスクも適切に管理することができるようになります。
さらに、プロジェクトが現場主導になりやすく、トップダウンの「やれやれ」マネジメント（どこかから計画が提示されるなど……）からチームが解放され、自律的なチームが構成されることにもつながります。
■実際に体験したこと（実施フェイズ：継続管理）
プロジェクト実施フェイズでのリソース管理は、計画に対してどの程度リソースが消費されているか計測する、ということがメインになります。
さんざん頭を悩ませて計画フェイズを終えましたが、プロジェクトは100％の確率で計画通りには進みません（段取り八分なので、二分が残っているわけです……）。従って、プロジェクト実施フェイズでは、立てた計画と実際の進行度合いがどの程度かい離しているのか、常に気を配る必要が出てくることになります。
ここで気をつけなければならないことは、「状況の変化を素早く捉える」ということになります。例えば、仕様変更はよく発生することですが、お客さま側からの仕様変更だけでなく、開発上の都合による仕様変更も多く発生するかと思います。これらの変更が入った場合、どのようなプロセスで（これは計画フェイズで決めているものですが）、どのくらいのコストで（予算の追加確保が必要かどうかなど）、いつ（までに）対応するか決めていく必要があります。これをなんとなく開発チームに投げてしまって管理せずにいると、いつの間にかコストが超過していたり、スケジュールが間に合わない状況になっていたり、開発チームのモチベーションが低下してしまったり、ということになりがちです。しかも、こういう場合、得てしてプロジェクト終盤の取り返しのつかない状態になってから気付くものです。すると、最終的にはシステムの品質が低下して、顧客満足度も低下する、という結果になってしまいます。
リソースに関して着目すると、誰がどのくらいの時間働いているか（働き過ぎていないかどうか）、各人（あるいはチーム）が期待している通りの成果を上げているか、計画した通りの期間体制を組むことができるか、各人モチベーション高くプロジェクトに関わることができているか、などを管理します。
これらはなるべく数値で管理すると、計画と実績のかい離を把握しやすくなります。かい離が大きくなったら（例えば、計画のプラスマイナス20％など）、計画フェイズやリスク発生時に決めておいた何らかの対処を行う、というような方法につながります。
計画フェイズでも特筆してリスクに関してよく検討しておく必要があると述べましたが、実施フェイズについても同じことが言えます。上記の状況の変化を素早く捉えるということと同じことですが、リスクに関しては直接プロジェクトの成否に関わるものが多いため、特に敏感になる必要があります。
プロジェクト実施フェイズでは、計画フェイズで洗い出したリスク項目の状況が刻々と変化することに加え、リスク項目自体も増減します。リソース面では「計画通りの成果が出ない」ということがリスク項目としてよく挙がりますが、開発が進むにつれてこのリスクは減少していく傾向にあります（チームが熟成されていくためです）。逆に、突発的に予定していたリソースが予定期日になっても投入できない、あるいは予定よりも早くリソースを空けなければならない、ということなども発生します。
このようなリスクの変化は日々の状況の変化を正確に把握していないと見逃してしまいます。特にPM専業でない（プレーヤーでもある）場合は、状況把握を怠りがち（周りが見えなくなりがち）です。開発チームのみならず、お客さまやプロジェクトに関わるすべてのチームとしっかりとコミュニケーションを取り、少しでも変化を感じたらすぐにその影響を検討する、というような姿勢が大切になります。
最近はプロジェクト実施フェイズで朝会や夕会を行う場合も多いと思います。その際にしっかりとチームメンバーがリスクを言える環境を作り、対処法の検討・実施を適切なタイミングで行っていくことで、開発をスムーズに進めていくことができると思います。
この実施フェイズの話題に関しては次回、詳しく触れたいと思います（テーマ「活動を管理する」）。
■まとめ
リソースに限らず、プロジェクトは「段取り八分」です。