力量の把握と正しい要員計画
プロジェクトマネジメントにおいて、あまりにも疎かにされているのが
リソースマネジメント
（人的資源マネジメント）
です。どこの会社の計画書を見ても、リソースマネジメントと言うと、ちょっとした要員計画…と言うことで、体制図がなんとなーく書かれていたり、「役割」と「責任」が明記されていたり（でも、その通りには全く実行されていなかったり）。
しかし、『マネジメント』ってそう言うものでしょうか。
マネジメントとは、言ってみれば何がなんでも「成功」させるために、色々とやりくりすることのはずです。形骸化し、実現する気もない計画をなんとなく書くだけで、あとは現場の属人的な進め方に依存しているようでは、マネジメントなんて言葉、口が裂けても言えません。
リソースマネジメントが、企業と言う組織の中において、原理原則上、困難なモノであることはわかります。
仮に、プロジェクト成功のために、力量を定義し、その力量が備わっている人材だけを集めようとすれば、他の組織、他のプロジェクトが立ち行かなくなりますし、そんな都合のいい人材集めばかりしかしない組織では、新人なんて未経験者なわけですから、ガラクタ以下の扱いにしかなりません。でも、そんなこと現実としてはありえませんよね？
常に、ベテラン、有識者の他に、これからの成長を期待した未経験者や若手、新人などもバランスよく配置されるようにできています。そうして一時の負担、先行投資をほんの少しずつ先達が背負っていかないと、組織が回らないからです。
ですので、力量を定義するところまでは良かったとしても、その力量通りの人材を全部揃えてもらえるなんて甘えたことを考えているマネージャーには、マネジメントなんて一生かかってもできません。
先述の通り、マネジメントは"やりくりする"ことです。
であれば、力量の足りていない人材を、プロジェクトの中で足りさせていきながら（成長させながら）結果的に成功に導けるようにやりくりするのがマネジメントと言うものです。
…けれども、マネージャーは説明会などの「教育」やＯＪＴを踏まえた「育成」と言った活動を、自らが行うマネジメントの中にタスクとしては決して加えようとしません。そう言うマネージャーは、本当にとても多いのです。だから、メンバーは自己負担、自己責任の範疇で、残業などの労働時間超過を使い、不足している力量分を補わざるを得なくなっていくわけです。
そして、一定（年720h、複数月平均80h）以上の残業を行えば、コンプライアンスに抵触することになるため、それ以上要する場合は、サービス残業を要求したり、あるいはもっと赤字になってもいいからと、増員をすることになります。そこまでして周囲に、あるいはメンバーに迷惑をかけても、それでもプロジェクト内での「教育」や「育成」は絶対にしません。
そう言ったマネージャーが世の中には溢れかえっています。
今一度、リソースマネジメントの基本を押さえ、しっかりとマネジメントの土台を支えられるようになってもらいたいものです。
要員計画の最大の失敗要因
それは「スキルミスマッチ」です。
理想とするスキルと、現実にメンバーが保有しているスキル、あるいはそのレベルが一致していないのです。一言で言ってしまえばそれだけです。
けれども、「何のスキルが？」と具体性を問われると、おそらくはどのマネージャーも明確に応えることができません。ふんわりと、抽象的に
「業務を遂行する上で必要なスキルが」
と言うだけです。これでは、上手くいかないのも当然です。マネジメントに責任を持つマネージャー自身が、一人ひとりの役割に対して、どのようなスキルを必要としているのか、明確に説明できないのです。
なぜ、説明できないのでしょう？
それは、
どんな業務を
どの程度の力量であれば
どのくらいの期間で
どのような品質で…etc.
という一つひとつの役割に対する要求事項を明確にしていないからです。
「プログラマーが足りないと思うから、〇〇言語の有識者が欲しい」
「技術力？あればあるだけ」
大抵の場合、マネージャーはこの程度しか考えていないのではないでしょうか。つまるところ
具体性に欠ける
あいまいなイメージしか持っていないわけです。
仮に、社内のメンバーのプログラミングスキルを数値化すると、平均値が70だったとしましょう。そんなところに、90点のメンバーを追加したとします。そうすると、相対的に「彼は優秀だから」というだけで満足します。ひょっとすると、要求されるスキル難度は150点必要だったかもしれないのに…です。
調理で言えば、料理経験のない人が、レシピ本を見て、
「…適量？
塩味がついてさえいればいいんだから、一ビンいれてしまうか」
と言って、山盛りの塩を鍋にぶち込んでいるのと同じようなものです。具体性が伴っていないのです。
リーダーに対する要求事項
たとえば、「リーダーのできる人材が欲しい」なんてニーズがあったとします。ＩＴ業界だけかどうかはわかりませんが、どこでも"リーダー不足"なんて話はあるかも知れません。少なくとも私の身の回りではよく耳にします。
けれども、「どんなことができればリーダーなのか」に一意性はなく、具体的なリーダー像は存在しないに等しくはないですか？
「リーダーシップさえ発揮できればいいんですか？」
「技術的なフォローは必要ですか？」
「メンバーの精神的支柱になる必要は？」
「メンバーに嫌われるような性格でも大丈夫ですか？」
「能力さえあれば、ハラスメントしてもいいんですか？」
何もわかりません。
ただ、１点だけマネージャーや管理職、あるいは企業が求める「リーダー」に対して要求する共通項があるとすれば、それは
（自分たちにとって）手がかからず、無事に終わらせてくれる人材
ということだけです。まぁ、自らの役割や責任を放棄して、楽させてくれる人が欲しいわけです。これが、多くの企業が中途採用者に求める「即戦力」の正体です。
走・攻・守すべてが揃ったスーパースターなんて、そうそういるわけがないし、そんなスターが自分よりも能力の低い上司の元に就いてくれるかなんてわからないのに…それでも、自分たちが楽をするためだけに、そういった架空の理想像を欲して止まないわけです。
常にそんな夢ばかり見ているものだから、ますますマネージャーが作る計画書は"絵に描いた餅"となってしまいます。
適材を適所に置けるのか
・具体的にどんな仕事をさせたいのか？
・その仕事は、具体的にどの程度の力量（知識、技術）が必要なのか？
・その仕事は、具体的にどのくらいの期間で完了してほしいのか？
・その仕事は、具体的にどのような品質で完成していて欲しいのか？
一つひとつの業務、一つひとつの役割に対して、こうした要求事項を明確に定義していけば、自ずと何のスキルを、どの程度のレベルまで保有している人材が欲しいのか、詳細にわかってくるものです。ですが、それをしません。いえ、おそらくはできません。
マネージャーこそが、目の前のプロジェクトのことを一番理解していないからです。
プレイングマネージャーの場合、プロジェクト内容に精通していることはあると思います。ですが、自らが仕事を抱え込むために、マネジメントにまで手が回りません。
かと言って、通常のマネージャーの場合、昔取って杵柄だけで、現在は実務から離れてしまっている方がほとんどだと思います。ですから、どうしても最新の状況に疎くなってしまいがちです。もちろん、自ら学び、衰えさせなければいいだけなのですが、日本の場合、キャリアが進むとどんどん学ぶことを止めていってしまう人が増えてきます（そうでない人は大抵ひとかどの人物になっています）。
そういった事情から、マネージャーに適材適所を任せることが非常に困難な事態になってしまっているのです。
「どんな仕事を？」とは
これを特定するためには、ＷＢＳが有効です。野球のことでも、ニュースのことでもありませんよ。Work Breakdown Structure…すなわち、「Work=仕事を」「Breakdown=分解し」「Structure=構造化した」ものに落とし込むのです。
どんな仕事でも、分解していけば、最終的にシンプルなものになります。その一つひとつはおそらく新人でも説明さえ聞けば簡単にできる程度のものになっているはずです。
ＷＢＳによって仕事が分解され、“deliverable（=要素成果物）”が明確になれば、その成果物を作るための技術や知識がどんなものかが明確になります。上記の図では作業（アクティビティ）にまで分解しきれていませんが、さらに細かくしていけば、スキルらしいスキルが必要なものなんてほとんど無いことがわかります。
たとえば「現行組織・機能調査」をするとなった場合、新人ならひょっとするとオロオロしてしまうかもしれませんね。「え、何から始めればいいんですか？」とか聞かれそうです。
ですが、
「現行組織については、総務部の〇〇さんから組織図をもらう」
「機能については、現行システムの設計書を△△さんから拝領する」
「□□設計書のαページ目にある『機能一覧』を確認する」
「現行システムを操作し、一覧と一致していることを確認する」
と作業レベルまで分解されていたらどうでしょう。その気になればまだまだもっともっと詳細化できます。『仕事を分解する』と言うのはそう言うことです。普段、ふわっと一言で記述してしまっていて、まとめてあるから知識や経験がない人にはわからないのです。
つまり、新人や未経験者に足りないのは、スキルではなく、具体的な手順であることの方が多いわけです。それを、端的に記述して、「勉強してこい」「あとは空気読め」と暗に要求するから、その空気を読むスキルが不十分な新人や未経験者は苦労しているわけです。そして、それをフォローしようとしない先輩や上司、マネージャーが多いから、組織やチームのパフォーマンスが上がらないのです。
「どの程度の力量が？」とは
なんとなく必要な技術要素がわかっても、具体的にその達成に必要な力量を持っている人間を特定することは難しいでしょう。ほとんどの企業では、数値化していないからです。
では、どうすればよいのか？
一つひとつの細かいスキルに対して数値化が難しいと言うのであれば、もっとも有効なのは、以下のような基準で判断することではないでしょうか。
「実践経験年数」
「有資格」
「実績」
たとえば、このように必要なスキル群、力量群を定義してみるとどうでしょう。
全員が修得できている必要はありませんが、プロジェクトチームとして何人くらい必要なのかはざっと見当がつくと思います。このように、「力量」を定義化するため、プロジェクト活動全体を分解し、必要スキルの有無を検討できるマネージャーが、世の中にはどれくらいいるのでしょうか。
「どのくらいの期間で？」とは
期間はＷＢＳから、そのタスク単位で「スケジュール」を作成していれば自ずと明確になります。そうすることで、『重複』『適切性』などが視覚化され、余裕のないスケジュールなのか、実現性の高いスケジュールなのかがわかるようになるでしょう。そうすれば、
多少力量が不足していても妥協できるか？
を判断することが可能となります。
ここで「力量」と「人材」の関係性に対して、打算的な判断をしてしまった場合、採用してみたものの使い物にならず、要員の交換/交代ばかりで、いつまで経っても進捗が進まず、よりスケジュールは逼迫することになり、後々後悔する…こととなるわけです。
たとえば、次のようなスケジュールなら、一見して「実現性が高い」と言えるかもしれません。
すくなくとも、同一人物で作業が重複していません。一つひとつの作業に対する時間の割当が適切かどうかは吟味が必要ですが、本人が「大丈夫」と言うのであれば、任せてみてもいいでしょう。
ですが、次のような場合はどうでしょう。
複数の作業が、同じ日、同じ時間帯で重複してしまっています。これは本当に実現可能なのでしょうか。もし、スケジュールの粒度が『1日単位』となっているため、0.5人日で完了する仕事を同じ日に重複させる…と言うのであれば理解もできますが、上記のようにおそらくは『1時間単位』で表記されているグラフの場合は、重複すると言うことは、実際に同じ時間で重複させていると言うことに他なりません。
私も新人の頃に、ＰＣ２台（Windows3.1とWindows95）、キーボード２台で、右手左手それぞれ別々の仕事をしていたことがありましたが、結局…脳が１つしかないので、同時に進行することはできませんでしたよ。右手でプログラミングをしているときは、左手でメールを書く手が止まっていましたし、逆もまた然りでした。
よほど訓練すればできるようになるかもしれませんが、少なくとも私の場合、半年間続けたおかげで得られたものは、椎間板ヘルニアだけでした。
「どのような品質で？」とは
経験年数だけで見ていると、
当該プロジェクト、当該工程に参加していただけで
実際には他の作業をしていたから、何の実績もない素人
と言う要員を掴んでしまうことがあります。たとえば、経歴書上は「プログラミング工程：３年」と書いているものの、実際には『プログラミング工程に参加して、コーディング規約通りに作成されているか、他の人たちが作ったプログラムを静的検証していました』と言うようなケースです。
これでは、到底「プログラミングができる」とは言えません。
本当に重要なことは、「できるのか or できないのか」であって、盲目的に人的リソースを選定していいわけではないのです。
そんな場合は、簡単な適正テスト等を実施して評価すると良いでしょう。
その気にさえなれば、こう言ったサービスはいくらでもありますし、そのような評価方法を導入している企業だってわんさかいます。
そうは言っても現実的には…
という言い訳大会に帰結してしまいます。理由は、「必ずしも、スキルマッチした要員だけで構成されたプロジェクトチームをつくると言うのはなかなかに難しい」からです。
ではどうするのか？
と問われても、誰も回答できません。
これは、マネジメントのリスクの１つです。
たとえば、
「リソース条件が満たされなけ仕事は請けない」 → リスク回避
「スキル要求難度の高い作業を除く」 → リスク回避
「スケジュールの中に教育期間を設ける」 → リスク低減
「スキルを持つ企業に委託する」 → リスク移転
「地獄を受け入れる」 → リスク保有
と言った選択肢があるのではないしょうか。多くのマネージャーは、何も対策していない（ように見える）ので、たいていの場合は『リスク保有』政策…つまり、毒を食らわば皿まで作戦、あるいは一蓮托生作戦を取っているように見受けられます。
「実務はメンバーがするので、マネージャーは苦労しないから、
そのままテキトーに進めてればいっかぁ」
的なノリでマネジメントするケースですね。まぁそれで大トラブルになって大赤字化すれば、評価は落とされ、一生日の目を見ることは無くなるかも知れませんが…。
長らくマネジメントを行ってきた知見から言わせてもらうと、私は
「スケジュールの中に教育期間を設ける」 → リスク低減
を推奨します。と言うか、これしかしてません。そんなことをすると、「スケジュールが厳しくなる」「そんな工数、お客さまに説明して予算合意できるわけがない」と言われそうですが、そう言う盲目的な対策は、私だってしません。
CCPM…を理解されているマネージャーであればわかると思いますが、「倉庫番」や「テトリス」のようにムダなく隙間のない作業配置をおこない、また個人に余計なバッファを持たせないことで、余剰工数のコントロールを行えば、一般的なプロジェクトよりはるかにスリム化されたマネジメントが可能になるでしょう。
そうやってコントロールできるバッファを増やすことで、教育期間に充てるわけです。また、ベテランや熟練者にＯＪＴを踏まえた下位メンバーの育成に対する理解を得るよう働きかけ、多少の余剰工数を与えて実際にフォローや育成を推進してもらえば、リスクの大幅低減は可能です。
実際、大手SIerが見積った工数に対し、私はその1/10までスリム化し、潤沢なバッファを使って、多くのメンバーの育成や相互理解の機会に費やしました。結果、どの企業も匙を投げていたパートを、私たちは（それなりに苦労し）最終的に大手SIerに「大成功に終わりました！」を言わせる形にしたこともあります（まぁ、メンバーが頑張ってくれたおかげなんですけど）。
もちろん、すべてのプロジェクトでできることかどうかはわかりません。私の場合は、１年以上の大規模プロジェクトだったからこそコントロールがしやすかった…と言う背景もあります。２～３ヶ月程度の短納期プロジェクトでは、難しかったかもしれません。
ですが、少なくとも「方法論」の１つとして、そういった成功事例を作ることは可能だ、と言うことはお判りいただけたかと思います。
あとは、それぞれの現場で、それぞれのシチュエーション、それぞれのプロジェクト条件にあわせて、どのように限られた人的資源を用いて、成功に導くことが可能になるのか、それをマネジメントの観点から支援できるようになるのか、ということを考えてもらえればと思います。
むしろ、それこそがマネージャーの腕の見せ所なのではないでしょうか。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。