MDHの中にエンジニアの部署ができてそろそろ2年ほどになります。
CC:margolove
ほとんどエンジニアがいなかった頃と比べれば人数も増え、
開発範囲も格段に広がってきています。
ですが、プロダクトを作りながら、営業組織の中にエンジニア集団を
作っていく中では課題も多く出てきます。
その中でも今は特に、
「エンジニアがエンジニアリングにきちんと集中するできるにはどうするか？」
という事にフォーカスしています。
エンジニアにエンジニアリングをさせるのは普通の事なのですが、
意外とこの普通がおざなりになっていく事があるなぁと思うので書き留めておきます。
広いリラクももちろん欲しいのですが、どちらかと言うと
納得行くコードを書けるようにしていく事に心を砕いています。
(1)まとまった開発時間を毎日確保する
開発は集中を要する作業です。その為、同じ4時間で開発するにしても
2時間を2回と4時間を1回では全く違います。
朝会をやって、12時にランチMTGに行って、15時に打ち合わせ、17時に打ち合わせ。
ビジネスの人だと「今日暇だな」というスケジュールですが、
エンジニアにとっては「連続して開発時間が取りづらい日」です。
僕も最初は「っつてもMTG2個しかないじゃん」と思ってたんですが、
最近認識を改めました。
ってことで、現在はMTGは午前中にだけ実施する事にしています。
ビジネスサイドも午前しか時間が無いから前日に準備をしておけば良いのです。
毎日3時間もMTGできる時間があるのでほとんどこれで事足ります。
例外は面談とリリース計画MTGですが、それ以外は断っていいし、
場合によっては僕が横から「うちの部署では午後MTG禁止なんで」といって
日程を変更してもらいます。
オバマ大統領から頼まれてもダメです。
(2)ディレクションコストを減らす
ディレクター不在の開発ラインもあるので、ここのコストがエンジニアに転嫁される
事が多いです。では、ディレクションコストとは何でしょうか？
要件定義→設計→開発→テスト→リリース→PDCAのうち、
要件定義段階では目的の文書化、要件の確認、仕様の確定、未fix仕様の洗い出し
設計段階では依存関係の「これ大丈夫でしたっけ？」の洗い出しと
検証の進捗管理。
開発では進捗の管理の変更点の調整。
テストでは項目書の作成とバグチケットの発行。
リリースにあたっての周知とビジネスサイドのフロー構築。
そして、PDCAではデータ取得と解析です(ここは賛否あって、エンジニアが解析して
勝手に開発していくスタイルも僕は良いと思っています)。
最後に、これらを確定していくためのMTGのセットとファシリテーション。
これらをディレクションコストだと考えています。
これらのコストがエンジニアに転嫁されやすいのは
「これが無いと作れない」「これ以上は進められない」事態が起こるので、
エンジニア発信でまとめられる事が多いからだと思います。
専任のディレクター、業務委託のPMを配置する事で、
ここのコストをゼロにしていきます。
今のところは一部のラインで試していますが開発時間が増えて良好です。
(3)定期的なKPT、そして、対処するべきPは徹底的に潰す。
一週間に一回、ライン毎にKPTを実施していて、出てきたPのうち、
気になったPに対してTを設定する、という事をしています。
そして、非常に単純なのですが、このTが実行されている事を
徹底して追います。
僕が嫌いなKPTは、なんとなくみんなが吐き出すKPTです。
Tが10個とか、ありえない。と考えています。
ですので、Tを必ず実施する事を求めているし、
逆に言えば実行できるTだけに絞る事を考えて欲しいと言っています。
このPも当然ながらより良いエンジニアリングの為の障害に
絞って潰していっている感じです。
9月末にきっちりエンジニアリングが普通化される事を目指しています。