フィードバックを取り入れる工夫の仕方

最初はみんな教えてくれた
エンジニアがキャリアを積み10年を超えるようになると、周りからアレコレ出来て当たり前と思われるようになる。アレコレの内容も経験年数以上のより高度で難易度の高い課題や問題をファシリテーションや専門技術を駆使して解決することを期待されるようになる。
若いころは、技術的な戦力に早くなって欲しいから、マネージャも先輩エンジニアも寄って集って教えてくれる。教えてくれることも、作業をする前に教えてくれるし、途中に見にも来てくれるし、終わった後にアレコレ気づいたことを教えてくれる。

誰も教えてくれなくなった
ところが、先に書いたように若葉マークも取れて、独り立ちするようになって仕事を任されて経験を積みはじめるとアレコレ言ってくれた先輩エンジニアは段々といなくなってしまう。周りを見れば、自分のより若い後輩エンジニアが徐々に増えてきて、自分もエンジニアとして後輩エンジニアに対して先輩エンジニアがしてくれたように後輩エンジニアの面倒を見るようになっている。
キャリア、そう、経験を積めば積むほどgive and takeの関係がgive ＞ takeからgive ＜ takeになっていく。関係が変わっていくに従って、同じように、自分に教えてくれた人は同じようにいても教えてくれる機会が減っていく。
いつまでも誰かに教えてもらいたいというわけでもないが、誰かから自分で見、知ることが出来ない振る舞いに対して気付く機会でいいからそれがほしいのに。

必然を組み入れる
今の作業のプロセスに自分を客観的な視点でどう行動しているか、どのような振る舞いをしているか、知ることを区見れてしまうことが出来れば、自分を知る機会が“強制的に”作ることが出来る。自分にとって良いことも耳が痛いこともそれを知らなければ自分の頭の中の情報でしか成長のための栄養は得られない。第三者の視点は、それを受容するしないに関わらず、それを直視することで成長の糧とすることが出来る。
アジャイルのスクラムに“ふりかえり”というプロセスがある。このプロセスは、ケプトというフレームワークで行う。これは、アジャイルだけしか使えないかというとそんなことはない。システム開発だろうが定型業務だろうが作業を塊で括れば、その括りの終わりに組み入れてしまえばよい。ある作業の塊を終えたら“ふりかえり”をする。大々的に“ふりかえり”という必要もない。ただ、反省会よりはふりかえりの方が未来志向の響きがあって好感を持って受けれやすいだろう。
ポイントは、作業プロセスに組み入れてしまうことだ。これも作業プロセスを変えましょうと大げさに言い触らす必要はない。ミーティングの中で、
「気付いたことがあるのでちょっと全員で“ふりかえり”をしませんか。」
と言う様に普通の会話の中で投げかけてみたらいい。そこからはじまる。