回り道をしていないかチェックする

プロジェクトが予定通りに進まないと参加するメンバーのモチベーションはどんどん低下してしまいます。一方、仕事が順調にあるいは前倒しで進んでいくとモチベーション高く仕事を進めることができます。

そのため、プロジェクトがうまく進むようにメンバーに働きかけるのはプロジェクトマネージャーやリーダーの重要な仕事の１つです。

よくリーダーになると部下やメンバーのモチベーションを上げることそのものをタスクとしようとします。その結果として1on1などを導入している企業も少なくありませんがあまり効果は出ていないのではないでしょうか。これはいうなれば「腹を壊すほどマズい飯を食わせておいて、腹下しを飲ませれば済むと思っている」ようなものです。おそまつな対症療法というヤツです。

プロジェクト全体の生産性をあげるためにリーダーは、各メンバーに細かく仕事を分解して計画を立てさせ、その通りに進められているのか確認しましょう。

環境を整え、進行を阻害する要因を取り除き、十分に準備をしてプロジェクトを開始したら、個々のメンバーが能力を発揮できるようになり、プロジェクトは順調に進んでいくはずです。

しかし、現実はそう簡単ではありません。

プロジェクトのメンバーはあっちに寄り道し、こっちに寄り道し、ときには穴に落ちたり、違う方向に向かって走り始めたりします。

プロジェクトリーダーの役割は、こうした回り道をしているメンバーや落とし穴にはまっているメンバーを見つけて救出することです。マネージャーの役割は回り道のしにくいプロセスを構築し、落とし穴にはまりにくい環境を整えてリスクを低減させることです。

そしてこうしたメンバーを発見するために、

　メンバーが本来はどのような状態でいるべきか

を常に把握している必要があります。

プロジェクト計画書において「スコープ」や「スケジュール」、「品質」、「コミュニケーション」マネジメントと呼ばれている部分はおおよそこのために存在していると言っても過言ではありません。

進捗管理のあり方

プロジェクト管理の中でもっともマネージャーが意識しようするのは、進捗管理ではないでしょうか。プロジェクトが順調に進んでいるかどうかは、マネージャーが上司や顧客にも説明する必要のある重要な要素でもあります。

プロジェクトを観察し、問題があれば分析し、できるだけ被害が大きくなる前に早く修正をしていきましょう。

ただし、進捗が遅れたことで上司や顧客に叱られ、責任を追求される状況であったとしてもメンバーの責任を追求するような姿勢は慎まなければいけません。

20年ほど前。私が新米プロジェクトリーダー／マネージャーの頃には、プロジェクトが遅れたときの対処がうまくできていなかったと思います。遅れたことを叱り、責任の追求をしてしまうこともありました。そしてプロジェクト進行中の責任追求はチームワークを大きく損ない、プロジェクトの生産性を大きく落としていくことになったのです。

今になって考えると、これはプロジェクトの進捗管理の目的からは外れていたと思います。

進捗管理は責任を追及する場ではありません。
問題行動を分析し、修正することは重要なことです。

もしメンバーが問題行動を認めなかったり、分析や修正に積極的に取り組まない場合には行動を修正させる必要があるかもしれません。

ですが、進捗が遅れたことはチーム全体の責任です。メンバーだけのせいにすること自体、大きな間違いです。役割分担の際にスキルミスマッチがあったのかもしれませんし、お客さまと詰めた仕様の説明が悪かったのかもしれません。原因はメンバーだけでなくリーダーやマネージャーにもあると考えるべきなのです。

メンバーの計画をレビューする

プロジェクトの進捗管理に対してとても大きな影響を与えるのが、

　メンバーの予想外の行動

です。メンバーが本来は必要のない仕事をしてしまい時間を取られたり、作業がやり直しになったりするとあっという問に時間がなくなってしまいます。

原因はインプットの品質が悪かったり、指示や仕様の勘違いによるものがほとんどです。さらにその真因はコミュニケーションの問題であったり、想像力不足だったりがほとんどです。

こうした勘違いはメンバーだけが原因とは言えません。仕組みやルールによってリーダー／マネージャー側でもある程度は防ぐことができるからです。

リーダーおよびマネージャーはこのような状況をできるだけ早めに発見し対処することが、自分の仕事だととらえる必要があります。ですからメンバーの状態をきちんと観察し、把握する努力をしましょう。それができない人は、リーダーシップの本質的な素養が不足しています。

一番良いのは実際に間違った行動をしてから発見するのではなく、計画の段階や実行の段階で発見することです。力量の足りていないメンバーに対しては計画が大雑把でないかをチェックしましょう。仕事がきちんと分解されていないようであればどのように進めるかを一緒に考え、仕事の分解を促しましょう。

面倒ではありますが、間違った方向に進んでしまうと大幅に遅れが出てしまうことになります。より早い段階で問題を発見するために、計画のレビューはとても役に立つはずです。

とはいえ自分で予定通りに進めていく力があり信頼できるメンバーには、かなり大雑把な計画でも構いません。おそらく彼らの頭の中にはきちんとした計画ができていて、自分で方向を修正していくことができるはずです。あまり細かいことを言うと制約されているような気持ちになり、かえって創造性や自主性を奪ってしまいます。

レビューの機会をこまかくたくさん作る

実際にメンバーが行動し始めたら、自分が思っている方向に進んでいるかを繰り返しチェックしましょう。

万一、違う方向に進んでいた場合や回り道をしている場合には、少しでも早く見つける必要があります。

私はこれまでいろいろなリーダーやマネージャーを観察する機会がありましたが、プロジェクト管埋がうまいリーダーやマネージャーは、こうしたチェックを負担のかからない粒度で、負担と感じさせない程度に、早め早めの実施を心掛けています。

チェックをするためには成果をレビューする機会を作るのが良いでしょう。

たとえば、設計の後にはドキュメントレビューを実施し、コーディングの後にはソースコードをレビューし、テスト項目を作ったら項目をレビューするというようにレビューの機会を作ります。

システム構築の仕事でも設計書や手順書を作ってもらってレビューをするとか、完成品のテストをするなど、プロジェクトのあちこちにレビューの機会を作ります。

場合によってはそのレビューをするために手順や仕事が増えてしまうかもしれません。

しかし、そうした手間よりも手戻りのリスクの方がずっと大きいのです。
勇気を持って、レビューをする機会を作りましょう。

　レビュー工数で100万ケチって、
　それが原因のトラブルで1000万消耗する

なんてことは現実では往々にしてよくあります。ほんのちょっとチェックを怠るだけ、コミュニケーション機会を怠るだけで７～８桁の数字はあっという間に吹っ飛ぶのです。

私は、若手が「仕事がうまくいかない」と相談しに来たときには、どのような段取りで仕事をしてきたのかを順を追ってこまかく聞くようにしています。

そうすると自分で説明しているうちに、勘の良い部下は自分で問題点に気づくことができます。多くの問題・課題は「言語化」することで解決の糸口が見つかります。細かく順を追って聞いていくと問題になっている行動が浮かび上がってきますので、間違っている部分を教えたり、足りない知識を教えて勉強することを促しています。

こうすることが部下や若手層の成長にもつながるからです。

レビューは

　成果物に対する失敗や問題を早期に摘み取ることができ、
　且つメンバーのスキルアップに大きく貢献でき、

そして何よりも、

　コミュニケーション不良と言う組織レベルの問題を野放しにしておかない

と言う点からも『確実に実施すべき工程』と呼んでも良いものなのです。