相談させない「相談して」
プロジェクトでプロジェクトマネージャが困るのが、担当のエンジニアが進捗上の問題を抱えたままタスクの期限になってしまったことをその日や前日に知らさせれることだ。
「実はこのタスクでこんな事象で困っています…」
「それ今日完了予定日だったよね」
「みんなも忙しそうだったし、自分の担当なので自分でやらないと…」
「相談してっていつもいってるじゃないか」
「すみません」
あれ、これ昨日職場で見たぞ、とデジャブ感を感じた方もいるかもしれない。そのくらいテンプレの光景だ。
ここでプロマネの気持ちではなく、報告したエンジニアの気持ちになってみよう。
- 担当している作業でやったことがない技術があった
- 自分の担当だから自分でやり始めたが知らないこともありなかなか進まなかった
- このくらいのことを一人で出来ないと思われたくなかった
- 手こずっている間に作業予定完了日になってしまった
- 未完了だとわかって怒られるのは嫌だ
昔の自分を思い出しながら気持ちを書き出してみたが、こんなことが日常茶飯事だったに違いない。すまんかった、当時のプロマネさん。
知らないことは恥ずかしくない
知っている手法、仕組み、形式知、経験知でしかエンジニアは課題を解決できない。知らないところに解決方法があったとしても、知らないのだからその解決方法に辿り着けないのは当然だ。
知ろうとしないことは知的産業に携わっている専門家としては恥ずかしいことだが、経験する機会や専門違いなどでなければ知らないことは恥ずかしいことではない。
逆に、やっとここで知る機会が得られたと喜ぶ事案だ。
1人プロジェクトじゃない
チームを編成してプロジェクトにしているのだ。だったら、誰か知らないか聞いてみよう。聞き辛いなら、聞かれることから始めてみよう。
聞かれることができれば、逆に聞きやすい環境になってきているということだ。そうなるためには、自分の得意技をチームにアピールしよう。
ピボットするタイミングは前におこう
自力で進めることは良いことだ。やってみなければ、それが独力でできるのか、できないのかは判断がつかないのだから。
でも、出来そう、つまり、完了する見込みの見通しがつけられなければならない。３日の作業ならどこで相談するか。実装の方法が複数あるならどれで進めて、うまくいかないときはどこで転換するか、ピボットの位置（日にち、時刻）を決めておこう。
業務課題を解決できないことがわかったらそれだけでも価値はある。それを見極めるタイミングは開始してすぐに判断しよう。
相談させない「相談して」
最大の問題は、プロマネが困ったことがあったら相談してという言い方だ。
その「相談して」は「相談するのは問題を可決する方法を選ばせろ」だったりする。
それは相談とは言わない。課題も解決できる見通しがついているし、あとはメリットデメリットまで整理してチョイスするだけだ。そこに辿り着くまで複数案を考えているし、できるだろうという見切れるまでのコストを使っている。
それが「相談して」なのだろうか。
もっと手前に相談して欲しいのではないか。選ぶまでコストを使わせていいのか。もっと手前で相談して欲しいのではないか。
「相談」は「解決手段の提示」ではダメなのだ。「困った」状態で「困った」と言ってもらわないといけないのだ。
なぜ、スタンドアップミーティングで、実績と予定と「困っていること」の３点を聞くのかを考えてみよう。
相談させない「相談して」より「困っている」状態を教えてもらおう。その時に教えてもらった方がプロマネとして一番安く上がるのだ。
