小手先のプロジェクトマネジメント

プロジェクトを運営する時は現場と適切な距離を取ることが重要です。

現場に近づけば、メンバーのワークロードやプロジェクトの細かい問題が見えてくるというメリットがある一方、細かい意思決定に拘泥してしまい大局的な判断や優先付けができなくなる、というリスクがあります。現場から離れるた場合はその逆のことが起こります。

メンバーのワークロードや抱えている問題にアンテナを張りつつ、大局的な優先付けができること。つまりカラダは近く、アタマは遠くに。これが理想的な距離です。

感覚を現場に近づけるためにはまず現場に密着することです。メンバーとコミュニケーションを取り、彼らが抱えている問題を理解し、彼らのワークロードと、それぞれの力量を把握する。プロジェクトを進めるに当たっては不可欠の情報です。

情報が多すぎるならフィルタすればいいわけです。フィルタするのはアタマの仕事。メンバーが細かい問題で悩んでいる。そんなことで作業が止まっているのか、とあきれることもある。でも何も入ってこないとどうしようもない。なんか細かいことをぐだぐだやってるな。チッ。と斜に構えるマネージャーには、誰にも相談なんてしません。メンバーの立場にカラダを運んで話を聞いて、カラダでメンバーの話を聞いて、アタマで現場の状況をつかむべきです。

しかしアタマの能力が優れた人＝抽象的思考能力に長けた人がプロジェクトマネジメントの経験を積むと、どうしても現場の技術的な問題や判断は軽視しがちになる傾向があります。要するにこういうことだろ。だったらこうすればいいじゃないか。

でも抽象的な因果関係ではプロジェクトは動かない。下っ端メンバーはそれが体で分かっている。うまく行くはずがうまく行かない。思ってもみなかった障害が発生して慌てふためく。

そこにこざかしいマネジメントが入って*事後的に*何だドキュメントを読み込んでなかったのが原因じゃないか。何で前もってドキュメントを読まないんだ。サポートに聞けば分かったことだろう。どうしてあの時確認しなかったんだ。などとを言えば、メンバーのモチベーションは下がって行くばかりです。だからメンバーが細かいカオスの中でどうあがいているのか、マネジメントは知っておくべきなのです。

エンジニアを信頼してゆったり構える。それができるかどうかでそのマネジメントの優劣が決まります。目指す要件（設計）は共有できている。認識もあっている。どうせ細かい技術的なことは分からないんだし、任せてしまおう。信頼した以上、そいつがミスした後の始末をするのがオレの仕事だ。腹を括ること。これがマネジメントの取るべき態度の一つです。事後的に賢しらに説教すれば、メンバーの心はどんどんと離れて行くだけ。

一番マズいのは現場感覚も経験もないマネジメントです。いや、それだけではありません。多少経験を積んだとしてもこざかしい理屈でプロジェクト回そうとするマネジメントも問題だ。

何せシステムを構築する、という感覚が分かっていない、あるいはその感覚を忘れていてアタマにあるのは「ああすればこうなる」のキレイごとばかり。だからプロジェクトがどう回っているのか、定性的に評価できない。こうなってくると頭の良さ＝抽象的思考能力の優秀さなどむしろ邪魔なだけです。個々のタスクの重みが分からない。メンバの仕事が正しいのかも分からない。メンバがふと気を緩めている時に何をなすべきか分からない。こんな時に彼らが思いつくのが「見える化」とか「数値化」というダメダメ方法論です。現場を取り仕切るマネジメントがこんなものを信じちゃいけません。この手の方法論は、システムの構築を分かっていないお客さんに「見せる」ためのフィクションに過ぎません。マネジメントはプロジェクトの進捗を定性的に把握した上で、顧客には定量的にその進捗を見せる能力が必要です。でもプロジェクトが分かってないから自分も数値の方を信用してしまう。顧客と一緒に数値が全てだとと思い込んでしまう。WBSが全てだと思ってしまう。

何を言ってる。数値化もしないで、WBSもなしでどうやって管理するんだ。ごもっともな反論ですな。しかし同じことを現場感覚のあるマネジメントが言うのと、こざかしいマネジメントが言うのとでは天と地ほどの違いがある。

すぐれたマネジメントはWBSや数値をプロジェクトを進めるための手段として使うことができる。逆にダメなマネジメントにはそれらが目的となってしまう。

すぐれたマネジメントはWBSを使って顧客に進捗を説明し、重要なタスクに人を割り当て、不要なタスクをリストラします（これが重要かつ困難）。ダメなマネジメントはWBS上の数字のつじつま合わせにしか意識が向かない。

ツールを作ったら作りっぱなし。単に進捗をトラッキングするだけ。遅延が出れば優先度もなにもあったものではない、徹底的にエンジニア締めつけるだけです。優先度を評価して洗い変えることもしません。というかできない。定性的に評価ができないから。タスクを消すなどもってのほか。タスクを減らす？そんなことが説明できるわけがない。むしろ増やした方が安心する。そしてどんどんタスクを作り、エンジニアに投げるだけ。

すぐれたマネジメントは数値を利用してうまく顧客の目を重要な課題に向け、どうでもよいタスクからフォーカスを外します。

ダメなマネジメントは障害の件数をカウントして上から目線でグラフ化するだけ。課題が"1"件あったとして、その"1"が気になってしょうがない。課題の内容などどうでもいい。その"1"件が消えないことだけが引っかかる。そしてそれを消せとやはりプレッシャーをかける。でも自分で消すという判断はできない。

WBSなど各種の管理ツールの裏にある、実体としてのプロジェクトが分かっていないと、まともにプロジェクトの運営ができるはずもありません。管理ツールを作り、それをメンテナンスするだけでプロジェクトを運営していると思い込んで安心する。そんな小手先のプロジェクトが幸せな結末を迎えるはずがありません。

現場を見ること。次に管理ツールを*手段として*有効に使うこと。それがプロジェクトを上手く回すコツだと私は思います。
.