懲りずに飽きずに続けます。
執筆量にKPIが設定されているとか、そういうものはありません。
懐中電灯をひとつもって洞窟の中を歩け、みたいな世界はいけないと思います。まずは、大きな地図と小さな地図を作って方位磁針を渡して、方向性を共有しなければいけないと思うのです。
例えば、フルスタック、マルチスタックのエンジニアになるためには、何故、それが必要であるか、組織の方向性や戦略と整合させつつ、説明しなければいけません。そして、優先順位。この三ヶ月ではこれをやろう、次の三ヶ月にはこれをやろう、そして、それが終わったときに見える景色はどうであるのか、などを話合うべきだと思います。
数年前に育成を担当したときは、まずは、鉄板の入門書を軽く流して（この時点ではわからなくてもいい）、語彙や概念に触れてから、少しレベルの高い書籍に進んで、読みながら都度、入門書に戻って復習。これをやりました。
そして、効いたのはコードレビューというか、プロの書いたプログラムを一行一行読んで解説するという作業。隣の部署のオッサンが米国の某ベンダーに数百万支払って書いてもらったコードを題材にしましたが、ま、適度なクソコードで教材としてはよかったと思います。その後、リファクタリングして、機能を追加してみたいなこともできました。
ま、最初の題材にするクソコードは1000行くらいのやつがいいでしょうね。それも鼻持ちならない米国のエンジニアが書いたもの。会社の所在地はシコリン？シリコン？のやつがいいでしょう。シリコンバレエ団のやつ。
ああ、当時、解説の準備をするのに徹夜してフラフラだったりした記憶が蘇る、あの当時の体力がいまあるかわかりませんが・・・ま、鍛えているので平気でしょう。
で、やっぱり、次のステップでは何か作ってもらうのがいいんだと思います。実践ってやつですね。本当はいきなりデリバリできるものが一番なのでしょうが、それはリスクが高すぎるので、例えば部内で利用するシステムを作ってみる、とか。
例えば、設定書の自動出力とか、監視系なら、取り扱い製品に対してsnmpwalkかけて、稼働状況をみる。一定の条件を満たしたらアラートとして表示するなどなど。別に工数の集計ツールでもいいし、フレックスタイムの事前申請フォームでも、なんでもある。それをどんどんエンハンスしていく。
ぶっちゃけ、車輪の再発明になるかもしれないけど、それでもよいとする。なぜならこれは学習を兼ねているのだから。その後で、たとえば商用製品や優れたOSSを見せてあげると、フィードバックのループが回り出す。
そこまで行けば、次に製品連携をやってみるとか、周辺のツールを開発するとか、そういうことに繋がるはず。自社開発とか、自社サービスとか、そういう夢に繋がっていくことを目標にやってみる。
ああ、これで少し心の平静を取り戻し始めることができたかな・・・。
自分こそ、一歩踏み出さないと。
・・・それではこの辺で終わります。
お粗末さまでした。
前の記事：
最初の記事：
