キュゥべえと契約しなくてもプロジェクトマネージャが想いを叶えるために

プロジェクトマネージャが一番欲しいのは、寝ている間にアウトプットを作ってくれたりトラブルを解決してくれる妖精さんに違いない、と思うんですが、その妖精さんでさえプロジェクトマネージャが本当に必要なものを作ってくれるかどうかは妖精さん次第なのです。その妖精さんキュゥべえだとするならそれはそれでプロジェクトの進捗によりソウルジェムの混濁の度合は想像に難くなく魔女化することは避けられないのではないかと諦めざる得ないのかもしれません。いや「そんなことになるなんて聞いていないよ。」といくらプロジェクトマネージャが訴えてもそれはもう契約してしまっているのであればあとの祭りなのですよね。


大概にして、プロジェクトマネージャが“勝手に”期待している限りは「望むような現実は実現されない」と言うのが真理だと思うのです。それは、期待はその“期待”を願う人の中にだけあることが多く、その期待を実現して欲しい相手に対して伝えていないから、と言うことが背景としてあるからです。期待する側の一方的な思いは“阿吽で”とか“空気嫁”とか精神の世界でのコミュニケーションにあり、それはその世界観が共有されていないのであれば誰も察することはできないのです。そしてその勝手に、一方的に“期待”をしている方は、その伝えもしていない“期待”が実現されずに、さらに勝手に落胆するわけです。そうした情景を傍から見ていれば「なるようになったね。」という感想しかないですけど、そういう風景はいくつものプロジェクトを見ているとよく見る光景であるのも事実です。


期待を現実のものにするためにしなければならないこと
なら、どうしたらいいのか。プロジェクトマネージャもプロジェクトのメンバも同じ一つの目標に向かって進まなければならないことはここに書き記す必要もないことです。それでも、同じ目標に進んでいるとしてもプロジェクトのチームとしてどっちの方向にどのくらいのスピードで歩みたいのかは、そのプロジェクトのプランを頭の中に描いているプロジェクトマネージャしか知らないのです。


そのプロジェクトマネージャの思いはプロジェクトの方針(憲章とかチャーターとかいう)なり、プロジェクト計画書に言語化されることで初めてプロジェクトのメンバがその思いを認識することができるようになるのです。そして、その思いをアウトプットを作るための作業を分解して初めてメンバがアウトプットを作るタスクとして着手することができるのですね。


そのタスクが期待するモノであるか、期待するスピードで作られるか、期待どおり顧客が望む要件を含んでいるかは、その“期待”を伝えるところから始めないとその“期待”は伝わらずにタスクが動いてしまい、結果期待するものでないタスクのアウトプットが生産される危険があるんですね。そうならないためにはプロジェクトマネージャが期待を思っているまま伝えることが必要なのです。それも何度も。人の記憶はその人それぞれにキャパが違うし、いくらプロジェクトマネージャが「大切だ!」と思っても、それを受け止めるメンバの思いは別なところにあるのはそれが個々の独立した生き物だから、です。


だから、機会がある度にプロジェクトマネージャの思いを伝えなければならないし、伝えなければならないのです。それをしましょう。


2つの魔法
魔法と言ったって、なにか呪文を朗々と唱えれば期待することが現実になるわけではないけれど、何かをしなければ今より悪くなるか良くても現状維持が精一杯なのです。だから、プロジェクトマネージャが勝手に期待していることを現実の世界に起こすためにプロジェクトマネージャを取り巻く環境を変えるために何か唱えなければならないのです。


朝会の場を作る
その魔法が「“朝会”なの?」と思うかもしれないけれど、プロジェクトマネージャの期待の一つにタスクの進むスピードや進むことの障害があるのかないのかをタイムリーに知りたくなるものです。そう、ソウルジェムの濁りが思っているより進んでいることを1週間後に知っても遅いのです。


1週間のスパンでしか見ていなければタスクの進むスピードが期待通りでないことを知るのは1週間後だし、そのスピード感の違いを知り、キャッチアップするためにはその3倍のコストと時間が必要になることが多いのです。また、タスクの進捗を妨げる障害があることだってその障害のサイズや対策を講じることの時間とリソースも同じように3倍かかったりするんです。


プロジェクトマネージャがタスクの方向性なり進度なり障害なりを最短のスパンで知ることができれば修正は一番小さなコストで済むのです。その場として適切なのが朝会なのです。


ふりかえりの場を作る
プロジェクトの中で、プロジェクトとして作成しなければならないアウトプットを作成するプロセスの骨格はプロジェクト計画書の中でフレームワークを建てつけるものです。そのフレームワークの上で実際にアウトプットを作成するメンバが実践して作るのですが、その計画書の中で表現されるフレームワークは実践してみると、そのフレームワーク自体を直す必要が出てきたり、それを使用するメンバのスキルレベルに起因してしくみを見直さなければならないこともあるわけです。なにせ、プロジェクトマネージャが一方的な思いでプロジェクト計画書を作っていますからね。


しくみなんて、やってみてしかわからないことばかりです。だから、その計画したフレームワークの上でメンバが想定していた程度でパフォーマンスを出せているのかは使ってみて評価のフィードバックをもらわなければならないのです。また、メンバ自身のスキルレベルに依るフレームワークの調整だってメンバがそのフレームワークを使いこなせないならそうした現実に即した調整は必要なのです。


でも、そうした場を持つプロジェクトはあまり聞いたことがない。いや、やっているよと言ってもそれは本当かどうか。


朝会をやっているのは、トラブルが起きてからじゃないですか。
コトが済んだかどうかもしないうちにもう次に手を出しているのではないですか。それのどこに自ら内省をして振る舞いを正すタイミングがあるのでしょうか。


だったら、そのしくみを、場を、始めから組み入れてプロジェクトをキャリーする他ないのです。それともキュゥべえと契約するのですか。プロジェクトマネージャのみなさん?