最近のプロジェクトマネジメント業務を振り返って、学びの言語化をします。3つ大事だと思ったことを書きます。
この記事は、AI を使っていません（AI 使ってたら、もっとそれっぽいタイトルになる）。
1. 大きな問題を防ぐために、小さな問題を出し続ける
プロジェクトでは、ある日、問題が起きます。結構大きな問題だったりします。
何でこんなことになっちゃったんだ、と頭を抱えるわけですが、実のところ、急に起きたわけではなく、問題はずっと起きていて、それがそのタイミングで明らかになっただけだったりします。明らかにならざるを得ないほどの大きさになったので、現れたとも言えます。
で、大きな問題を解決してそれで済めばいいんですが、その労力は小さくありません（問題が大きいから）。時に関係各所との連携が必要であり、自分含めた周囲のコンディションにも影響があるかもしれません。もちろん仕事というのは、日々、問題解決を行うことではありますが、なるべくなら、大きな問題の対応をしたくありません。
考えてみると、その問題は大きく "なってきた" わけで、もともとは小さかったわけです。たぶん。ということは、大きくなる前に見つけられたらいいですよね。だって大きくないんだから。
そこに、プロジェクトマネージャーの仕事があるように感じます。平たく言えば、（特に見過ごされそうな）問題を見つけること、です。
プロジェクトマネージャーは、日々チームの状況を見て、問題を見つけます。
それは時に言いにくいことだったり、波風を立てることだったりします。自分がメンバーの時だったら言えたことが、プロジェクトマネージャーだと言いにくいと感じることもあります。それはきっとプロジェクトが安定している（と思い込んでいる）ほうが、安心できるから。
しかし、問題を積極的に拾い、大きくなる前に問題を見つけられたなら、小さいうちに対応できる可能性が上がります。
そういう意味だと、むしろ積極的に失敗するのがいいのかもしれません。小さい発言一つとっても、そのまま発言せず進んで大きな問題になるよりは、さっさと恥をかいて失敗した方が後々を考えると良かったりします。
プロジェクトマネージャーとしては、むしろ何も問題が起きていない状態が続くことに、居心地の悪さを感じるくらいが良いと思ったりもします（同僚が優秀だと実際に問題はあんまり起きない時期もありますが）。
2. プロジェクトをシステムとみなし、調整し続ける
プロジェクトをシステムとみなしてみます。そこにはいくつかの構成要素があり、構成要素間に何かの関係があります。それは影響しあい、依存しあいます。プロジェクトマネージャーは、自分をそのシステムのなかの構成要素でありながら、それらの関係をよく見て、ほかの構成要素に対して、なんらかのよい影響を与える何かをします。
例えば、何かのタスクをするときに、そのための事前情報があり、それを渡すのに適切なタイミングがあります。それを、それぞれのメンバーが動いているなかで、良さげなタイミングでその情報を与えて、そのシステムがうまくいくような影響を与えます（必要な情報がなければ、そのタイミングまでに取得してきます）。
自分のタスクをどううまく行い、ちゃんと完了させるかを考えることも重要ですが、「自分が何をするか」よりも「今どこに自分が入るとプロジェクト全体が流れるか」を考えることが増えることで、プロジェクトマネジメントはうまくいく場合があります。
こういったことができるためには
- 時間軸・空間軸を意識すること
- 自分に一定余裕があること
が必要だ思います。そして何より、プロジェクトを "よく見ている" ことが大事だと思います。
※ 逆に、良い影響を与えてもらえるような言動を日々することも重要かもしれません
3. 線表は、叶えられている状態を想像するために書く
プロジェクトマネージャーの基本的な仕事として、線表を書くことがあります。これこそプロジェクトマネージャー！これ引いて意味あるんかいな、引いてる暇あるなら手を動かそうやと思っている時期がありました。
線表の意義として
- 関係者への共有、提示
- 進捗管理する
はもちろん大切な一つの機能ですが、加えて
- 叶えられている状態を想像する
ためにも有効なんじゃないかと思ったりします。
未来の線表を書くと、この日にはこうなっているとか、ここまで来ればリリースできそうだとか、ここは祝日や社内イベントがあるからできることは少ないとか、色々と具体的な想像ができます。で、そこから逆算して今何をするのかを考えることになります。
線表を書いたからといって、その通りになるとは限りません（私も日々何度と引き直しています）。それでも線表を書くと、まだ存在していない未来が一度具体的になります。すると、「じゃあ、その状態にするためには今日何をすればいいんだろう」と考えられるようになります。
これが不確実性を潰すということになっていると思います。
過去に、見積りミスって死にそうになった（ので、ポイントを3つ共有）という記事を書き見積りの重要性を書きましたが、上記の意味でも有効と思います（見積もりってのは、リリース日を当てるためだけに考えるものでもない）。
あとがき
こう書いていると、プロジェクトマネージャーに限らず、誰にでも意識できることのような気はしますね。