2013-11-22

昨日、いろいろ積もり積もっていたことをドバーっとツィートしたんですが、まぁ、アレです。中二病みたいのものです。中二病って言っても中年の、ですが。(涙。

このテーマはずっと今年の春からある筋からの宿題だったわけで、途中からズッポリと別案件にかかわっていたのである意味回避できていたんですけど、そうはいってもメンバの育成のサポートについてはかれこれ感じてきたものが経験と積み重なって、でも、「誰でも応用できるそんな手軽な解決方法はないよね。」いうところに帰結して、ときどき幽霊のようにソレを思い出してしまうのでやっぱり「うんうん……。」と思い描き切れていない自分の空想をどうにかしたいなぁ、と思っていたところに、燃料が投下されたわけです。

で、どばーっと中二病垂れ流ししてしまったというか。

エンジニアは育てられません
組織には中計とか年次の事業計画とかあって、それが実行組織に落ちてくるわけです。なので、事業計画に合わせて必要な事業でのスキルセットが変わったりしちゃうと必要なコンピテンシをもったエンジニアを要しなければならんのです。はい。それがマネージャの仕事なのでね。ご苦労様です。

どうするかというと、実情は、on goingな日々の事業をしてるのだから余裕がないのが普通で、「新規事業だ！」と事業予算と人的リソースがつかない限り、「できる範囲で……。」となるのはどこもおんなじでしょう。だって、日銭も稼がないといけないんだもの。

じゃあ、幸いにも空きのリソースがあるとしたらそのリソースを割り当ててやればいいじゃんとか思うかもしれないけれど、大概、そうした空きのリソースはフィットしないことになっているのはマーフィーの法則にそうものです。

で、結局、個人の育成プランになんとか事業計画で必要な目標のスキルセットを持つエンジニアを用意するためにメンバの育成プランを「あーでもない。こーでもない。」と悩みながらプランして、誘い水を掛けてエンジニアをその気にさせるんですが、どうもエンジニアの皆さん関心が違うことに向いていることが多い。

そりゃそうです。個々のエンジニアは個々の担当するエリアの中で楽しみを見つけているか、別のところで好き勝手に好みの技術と戯れているですから。そこに割り込もうと思っても、もともといるところから、こっちの都合の良いところに出てきてもらうだけでも大変なんです。

結果、育成のフォローをしても、期末の評価をしても、思うように育っていないわけです。それって、エンジニアは“自分の興味を軸に勝手に育っちゃう”っていうことでもあるんですね。だって、事業計画なんて世の中の動向に合わせたり先読みしてみたりするからコロコロ変わるものだし、それに付き合ってみてもいいことあったなんて経験を持てるエンジニアが少ないからなんだろうなぁって、思ったりもするんですよ。

育てられるのは概念やしくみのフレームワークだけ
「じゃあ、まったく育てられないの？」と聞かれれば、それもちょっと違って、ウォーターフォールのやり方とかPMBOMの考え方とかWBSを使う狙いとかそうしたプラクティスとしてまとまった概念やフレームワークは、座学でも頭に押し込むことができます。

というか、考え方しかプラクティスを形式知として頭に詰めることはできないんですよ。だって、それを使う使い方なんて、個々のエンジニアがどう理解して、どう腹に収めて、それをふるまうか、ってところによるものに依存しちゃうんだもの。

平たく言えば、知識は詰め込めるけど、それを使うのは別です、ってことです。そこのポイントを押さえないでは、ソフトウェアはいつまでたってもエンジニアリングの部分が出来上がらないと思うんですが、これは個人的な思い。

形式知として押し込む＝育てるということと、その育てられたアセットを使えるようになるのは別のスキルで、後者については「育てようにも個人の奥深くに属するところなので育てることはできませんよ。」って思うんです。はい。

そうしたことを、やっぱり経験値から知っていないといくら頭のいい人たちで育成プランを作っても、総花的で、万遍なく、なんとなくいいようなどうも何かたびりっとしなさそうなプランにしかならんのだと思うんです。

そんな役にも立つかわからない育成プランを作っても、そこで育つのは勝手に育っているエンジニアであって、そのエンジニアはそれがなくても勝手に育っているということで、掛けたコストはどこにいっちゃうんだろうなって。

そんなことにコストをかけるより、今今のエンジニアの関わるプロセスに大鉈を振るって、重複する手順とか手続きを取っ払う方にコストをかけて働きやすくすることで余計なムダをカットする方が効果が見えやすいし、そのカットすることで得られる時間の寄せ集めをサラミのように固めて育成時間に振り分けた方がいいです。

エンジニアの育成に一番効果的なのはマネージャの育成するという意思をアサイメントで表すこと
もう、これにつきます。仕事なんだから、さ。必要なスキルセットを持ったエンジニアが必要なら、事業計画が下りてきたときに、今のチームの個々のスキルセットとあるべき姿のスキルセットのギャップを推し量って、ギャップをどのメンバにどの育成テーマを与えて伸ばすかを考えることなんです。

それも必ず、一つのテーマがあれば複数のメンバに、メンバのレベルに沿って割り振ることを考えながら、例え、同じ業務を継続するにしても、必要なスキルの得方を刷り込んで育成プランとして織り込ませて、ジョブアサイメントするんですよ。

それをプランして、トレースして、修正して、の繰り返し。それで興味を持って取り組んでくれればオーケーだし、関心を示さなければ、何度も繰り返すし、見切れれば、別のテーマを割り振るしかないです。

XP祭り2013のLT大会の終わったあとにあるスポンサーからの寄付の配布大会があって、なんだかんだでワタシに分けてもらえる順は一番最後になったときにテーブルに残っていたというとちょっとネガティブだけど、ほかの本じゃなくてこの“インターネットのカタチ”を選んだんですよ。

面白い、興味が持てなかったのどっち？って聞かれたら、もちろん前者ですね。タイトルからもう少し概念的なほんわかした感じの入門書かと思ったら全然思い違いで「あーこれ、まとめるの大変だったろーなぁ。」って思ってみたり、「でも、好きで書き始めたんだろうからそれはそれで楽しみながら書いたんだろうなぁ。」っても思ったり。

学生のころの、地図がらみのバイトの面接で面接のおじさんと会話したとき、「これからはネットワークの時代だよ。」っていうのがこびりついていまだに覚えているわけですが、もう30年近く前の話なのにそれからもずっとネットワークは興味が持てなくて……。

本のテーマとしてはインターネットですけど、まぁネットワークなので懺悔の気持ちも含めて読み切りました。はい。まったくもって、お勧めです。ネットワークを知っている人でも、インターネットってこうなっているんだ、とおさらいにもなるし、ネットワークに興味がないワタシのような人でも事件や事例があってイメージをつかみやすいのでそういった意味でも興味を持って読み進められます。