エンジニアはマネージャに話を聴いて欲しがっている

気がかりなメンバが二人いた。一人は中堅どころのエンジニアである。もう一人は中堅に入ったばかりで本来であれば自分で独り立ちして欲しいエンジニアである。

気掛かりなこととは、担当するプロジェクトの業務に流されて１年間終わった後に経験知しか残らないことである。

エンジニアに必要なスキルは、基礎スキルと技術スキルだ。

基礎スキルは、定性的なスキルかもしれない。なぜなら、エンジニア自身の仕事の仕方に深く結び付いているからだ。

基礎スキルには、仕事をやり切るとか意思伝達とか交渉とか後進育成などが含まれ、技術スキルには方法論、手法、言語、技術の適用などが含まれる。

業務による経験知の習得ではよくないのは、基礎スキルにしても技術スキルにしても体験したことが本人の内面で、それも成功体験だけが強調して記録される。

その経験知に足らないものが術や手法、それと方法論などである。

業務に流されてしまうと、その不足部分を欠いたまま1年歳を取ってしまい、それが繰り返されると外からプラクティスやパターンを取り入れることができないエンジニアが出来上がってしまう。

これが気掛かりなのだ。

目標管理制度を導入している組織では、目標設定、中間、評価と最低3回の場を持つ。この3回が曲者だ。なぜなら、目標の進捗から軌道修正をさせるタイミングが中間の1回しかチャンスがないためだ。

目標設定時から中間までに目標の進捗に手がついていないエンジニアが中間の1回の機会で軌道修正できるか。できるわけがない。できるなら最初から手をつけているはずだ。と言うことは、手法や方法論を身につけることの大切さを伝えるには回数が必要なのだ。

回数を増やすのはどうしたらいいか。

例えば目標設定時、中間、評価でそれぞれ1時間をミーティングに使っていたら、エンジニアの目標に年間3時間しか使っていないことになる。そのうち、軌道修正のタイミングは1時間しか取れていない。1時間で修正できないなら、時間を増やすしかないがただ増やせはいいと言う問題ではない。必要なのは繰り返し伝えることと取り組んでいなければその障害を取り除くことが必要になる。

さて、この要件は何かに似ていないだろうか。

そう、進捗管理である。ただ、作業の進捗管理と違うのは、やらなかったら評価にプラスにならないと言うことだけだ。もちろん、業務はプロジェクトで進捗管理しているので計画と実績から様々なアクションが取られる。

それでどうしたかというと、アジリティを働かせた。