ログを残すことが経験を共有することそのものなんじゃないかな

「プロジェクトが上手く行っていません、助けてください!」
ときどき相談がきますね、こういった感じの相談がね。プロジェクトが沢山あれば、上手く行くプロジェクトもあるし、普通にやっているプロジェクトもあるし、上手く行かないプロジェクトもあります。プロジェクトだから仕方がないんですよ。一つひとつの条件、つまり、プロジェクトを構成するパラメータが違うんですもの。


助けるためにはじめにすることは、場を作ること
場をつくります。兎に角、早く。時間が行動の価値判断を決めます。すでにもう手遅れかもしれないし、まだ、くすぶっているのかもしれない。いづれにしても、“今”どうなっているかを知るための“場”が必要です。


今“何が起きているのか”を直視する
所謂、現状把握です。だから個人的な考えは混ぜてはいけません。混ぜたら危険。事実を把握するためにインタビューしなければならないので、当事者からインタビューしなければならないですが、事実の経緯だけに配慮してもらいながら話しもらいます。そのとき、事実をインタビューできたら、当事者であるあなたの思いを聞かせてほしい、と添えます。


事実の把握は、できる限り複数の人に対して別々にインタビューします。唯一の情報としない、ということです。もし、インタビューして聴いたことが間違っていたら、その後の行動の根本が崩れるからです。別々にインタビューするのは、同時に聴くと情報が出てこない恐れがあるのと、受け止め方が違うにもかかわらず場の雰囲気で言えないこともあるからです。


問題の本質を整理する
プロジェクトが上手く行っていないことを相談されたのでした。何が原因でコトが起きているのか、何がその原因を生んだ本質なのかを推測して、対策を考え、実行に移さなければなりません。


事象の上部だけを押さえて対策を取ってしまうと、コトの本質を捉えられず間違った行動をする可能性があります。良くあるのは、もぐら叩きのような、出てくる事象に対する場当たり的な対策です。よく例え話で出てくるのは、作業をすると床が油で汚れるから掃除をする、です。掃除をするのは間違った対策です。なぜ、油で汚れるのか、汚れる理由を突き詰めて、汚れないようにすることが本当の対策です。


ワタシは助けない
相談されてもワタシは直接助けたりしません。コトの当事者はプロジェクトマネージャとメンバです。プロジェクトマネージャがどうしたいか、その意思がこれからのプロジェクトを動かすドライバーになります。それは、プロジェクトマネージャ自身がどうしようかと自分で考えなければ、プロジェクトが動かないということでもあります。


ワタシに相談されても、その当事者が自分で助かったようにしたいのです。ワタシが相談に来たプロジェクトマネージャやメンバに対してアレコレ言うのはとても簡単なのです。でも、その状態になってしまったら、次に同じようにプロジェクトが上手く行かないとき、彼らはどうしたらいいのでしょうか。釣った魚の食べ方を教えるのではなく、つり方を教えたい。つり方を教えるのがワタシの仕事であると思っているからです。


行動をロギングすることの大切さを伝える
場を作ることは、場をつくるための召集したメールやスケジューラにログとして残ります。
今“何が起きているのか”を直視するのは、スケジューラにミーティングの予定として残ります。
問題の本質を整理するは、事実をもとに整理して、問題の本質が明らかになればその整理した資料が残ります。


当事者に釣りの仕方を覚えてもらうことを意識させることや、こうしたログを残すことが経験を共有することそのものであって、育成の本質なのではないかなと思うんです。






  • 道具室(アプリとか)
  • 音楽室(PCからリンクをクリックするとき、PCにiTunesが入っているとアプリケーションが起動します)
  • 視聴覚室
  • 調達室