エンジニアリングの普通化

テーマ:

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月末にきっちりエンジニアリングが普通化される事を目指しています。

 

 

 

AD

自分がやっている事に名前をつけると、

強くてニューゲームできるよ、という話

 

「強くてニューゲーム」という言葉があります。

 

いわゆるネットスラングなのですが、元々はアクションゲームなどで

ゲームオーバーになった時にパワーアップしたままの状態で

もう一度ゲームを始められるところから来た言葉です。

 

ステージ1をパワーアップした状態で始められるし、

次に何が来るかもわかっているので攻略の難易度が下がります。

 

これに転じて、今の知識のまま小学生に戻ったら

「強くてニューゲームだよな」なんて感じに使われます。

 

この、「強くてニューゲーム」、個人的にはビジネスでは可能だと思っています。

 

私は今まで2-3年に1度部署を変わってきました。

本体にも、子会社にもいたし、プロフィットセンターにもコストセンターに

いた事もあります。

 

それを通じて面白いなと思っているのは、

「組織課題は再現する」という事です。

 

組織課題は大きく、組織構造が起こす問題、組織規模が起こす問題、

そして人の相性や能力が起こす問題があります。

 

前2つは面白い事に全然違う事をやっている組織でも再現します。

要するに、コストセンターAが30名の時に起こった規模に由来する問題は、

プロフィットセンターBでも起こるのです。

 

代表格は横軸組織を作った時に起こる課題とかがそうです。

 

で、これまた面白いのが全然違う組織のはずなのに、

解決策が依然として有効である場合も多いです。

 

その前提にたつと、今自分が経験している組織課題を解決していく事は、

非常に貴重な経験であることが分かります。

 

組織課題にぶつかり、それを社内の人のアドバイスや、

社外の方の経験談などを聞きながらなんとか自分達の組織に適用できるように

工夫して解決していくこれは、自分の財産になっていきます。

 

そこで僕がやっているのは、「施策に名前をつける」事です。

 

「この問題を解決する為にはこうしよう」と決めた時に実行する施策、

これに名前をつける事で以下の事が整理されます。

 

・何故やるのか?

・とどのつまり、何なのか?

・何が成功なのか?

 

こうすることで、自分の中で「私はAという課題を解決する為にBをやる。

成功は、Cである」という感じで整理されます。

 

これをやることによって、自分の中でこの施策を再現する事が可能になります。

 

そうして経験を自分の実感と結びつけていくと、

次に同じような課題が持ち上がった時に自分の引き出しが使えます。

 

同じ組織構造、同じ規模、同じ市場、同じ人達と仕事をする事は

人生において2度無いと思いますが、同じ規模の組織に属することや

同じ組織構造の組織に属する事は何度でもあるでしょう。

 

そういう時に強くてニューゲームができるようになるのではないかと思います。

 

 

 

 

 

AD

YUG

テーマ:

広告プロダクトの開発をする上での障害のひとつに、

ドッグフーディングが難しいというものがあります。

 

Google や Facebook のように個人が格安でも出稿できるとなると

別ですが、基本的には toB のプロダクトなので、

日常で生活している限りは決して触ることのないものである事がほとんどです。

 

この、ドッグフーディングが難しい事は、

「使用者も気づかなかったけどすげー便利な機能」

が出てくる可能性を著しく狭めます。

 

かつて、かのマリッサ・メイヤーが部下のプロジェクトマネージャーに

「私、いつもこのプロダクトを使っているの。どこにバグがあるかも分かっている」

と言い放ったような事がやっぱり起こりづらいわけですね。

 

というわけで MDH のエンジニア達で YUG という取り組みをしています。

YUG は「山口運用ジム」の略で、山口さんという方がリードしてくれているので

この名前がついています。

 

 

やっている事そのものは非常にシンプルで、他社を含めたプロダクトを自分達で

運用してみて、どういう施策をうったのか?何に気づいたのか?

実際に運用してみて取り入れたいという思う事は何か?

を共有するという事をやっています。

 

自分達のプロダクトの使いやすさ、やさしさの足りないところや、

逆に自分達の優れているところを再発見する機会になっています。

 

MDHに来るエンジニアは元々広告の経験や広告運用の経験がない事が

ほとんどですので、楽しそうに入稿しています。

(但し、二週目くらいからは新鮮味が無くなってほとんど作業になる)

 

AD