こんにちは。
Engineering Manager vol.2 Advent Calendar 2018の12/18を担当する、里山と申します。
5月から株式会社ビデオマーケットというVODの会社で、プロダクトマネージャとVP of Engineeringをやっています。
近年プロダクトマネージャとVP of Engineeringは共にとても注目度の上がっている領域ですが、エンジニア出身のプロダクトマネージャなら、組織文化の改革と効率的なプロダクト開発進行は事業責任を負う上で、当たり前に改善していかないといけない部分だと認識できると思います。そういう意味では、責任範囲も広いですが、うまく使い分けながらどちらも前向きに遂行出来ています。
私は半年前に現在の会社に入社し、現在までのあいだに、事業成果を最大化するために、組織文化をアグレッシブにアップデートしていきました。そのときに行った凝り固まった組織文化改革への5つのアプローチをお伝えします。
現場の意見の吸い上げ
入社したとき、最初に気になったのが、メンバーの「諦めムード」。案件一個一個に対して、「自分が考えたことではないが言われたからやった」みたいな言葉を何度も聞きました。
おそらく絶対的に足りないのは「自分ごと化」の考えであろう事はすぐにわかりました。
まずは、経営層から現場への直接の指示を禁止し、展開した上で部門全員に対して「1on1」を実施し、以下のような事を聞きました。
- 自分の今やっている事
- 3年後のキャリア
- そのために1年後すべき事
- やりづらい事
結果、以下のような事が共通する話題でした
- メンバーのキャリア感は高い
- 現場自体は現在のシステムやプロダクトをよりよく改善していきたいと思っている
- 経営層へ思っている事を言えない
- 案件優先順位や内容の説明が薄く、納得性が低い案件が多い
実際に離職率も高く、毎月誰かが入り、誰かが辞めていました。
トップダウンに対抗でき得るための「ボトムアップの仕組み作り」が最優先であると認識しました。
（トップダウンを否定するものではありません。バランスの問題です。）
案件の流れを整理する
上記、実際の業務を見てみると、メンバーのマイナス意識を促す制度が、「プロジェクト制度」でした。入社当時弊社では、開発に関わるほぼ全ての施策が、プロジェクトベースで行われていました。プロジェクトには、プロジェクトマネージャが立てられて強力に推進するものの、同じプロダクトに複数のプロジェクトが並行し、それらの情報共有が甘いので、画面UIひとつとっても統一感のない、いびつなものとなっていました。当然莫大な数のバグを抱えていました。
また、プロジェクトはリリースがゴールとされ、解散するとメンバーは別のプロジェクトへアサインされていくため、プロダクトのバグが見つかっても、誰も責任持って対応出来ない、悪夢のようなことも起きていました。
これらはメンバーの「自分ごと化」を欠落させる要因のひとつとなっており、そこを整理する必要がありました。
そこで始めたのがプロダクトへ意識を持てる制度作りです。経営層とプロジェクト制を廃止することを握り、プロダクトに対して人をアサインするように変えました。
スクラムを導入し、全ての案件をバックログにまとめ、プロジェクトに関わらず優先度に応じて改善していくのも、プロダクト基準での進め方の浸透のため改革したことのひとつです。
現在は1番大きな規模で、20名以上でひとつのスクラムで回していますが、今後はラージスケール化も必要となりそうです。
根拠を集める
BtoCの自社サービスをやっている中で、数値によるDailyの意志決定をしていない、すなわちサービスグロースに対する考え方の弱さもまた、現場がボトムアップで戦えないことのひとつです。
ざっくりとでも、メンバーレベルが現状のアクティブユーザ数や、売上に関する知識を持ち、他社比較出来るくらいの考え方があれば、ボトムアップする際の武器となるはずです。現場で数字が取れていないのだから、トップから降りてくる施策もそのレベルの数字が追えていないわけなので、当然案件の納得度に対して議論が起こるようになります。それがボトムアップへの第一歩になりうるわけです。
まだまだ数値の精度を細かくしていく必要がありますが、取れる数字はダッシュボード化し、毎朝スタンドアップMTGで共有するような運用を始めました。
マーケ施策や改善などで数値が変動することをメンバー自身が理解できるようになり、特にクラッシュ率などは、毎日見ることで課題感があらわになり、アプリ自体の品質は半年前とは大きく異なる改善を遂げています。
未来像をすり合わせる
メンバーの目線を上げるために、未来に向かって約束をする事は何よりも大事です。
私はメンバーと3つの約束をしました。
・メンバーの未来の姿を握る（行動指針）
・プロダクトの未来を握る（コアバリュー）
・未来のプロダクトを自分のものにする（リニューアル）
行動指針(ビジョンやミッション)は、メンバーへの信頼と承認を伝えることに主眼を置きました。「プロダクトの未来は我々の手で作る」というような文脈です。
また、本来コアバリューは定性・定量調査の上でユーザに対して与える価値を定義するものですが、今回はその数値やデータを取れる状況になかったため、今プロダクトに不満を持っているメンバーの目線で作りました。具体的なものは今回は伏せますが、ユーザに対する安定的なサービス提供がメインの、現状のフェーズとしては地に足がついたものになっていると思います。
また、最後に、それを絵に描いた餅にしないために、サービスのフルリニューアルを経営層と握りました。過去のしがらみをひきずりながら無理するより、未来に向いて進むほうが目線は上がります。現在はサービス開発の真っ只中ですが、メンバーのモチベーションは総じて高いです。
モチベーションの高い人を集めるために
これはまだ成果としてこれから出したいところですが、技術選択において「くせ」をつけるというのが大事なのではないかと考えています。
今まで弊社の採用サイトでの募集職種は、LAMPエンジニア（PHP）、Android、iOSでした。採用も担当している私個人としては、これだけだと、ピンからキリまで広すぎる範囲の人が来てしまう懸念を感じていました。
直近、前段のようにリニューアルを選択することで2点の大きな選択が出来ました。
ひとつが、アプリ側でクロスプラットフォーム技術のFlutterを採用するという事です。これは、Androidエンジニアの離職によりピンチになったことで私が決断したのですが、今年のGoogleI/Oに行った時の現場での盛り上がりを知っていたことも、個人的な意志決定を後押ししました。
もうひとつが、GCP✖️マイクロサービスアーキテクチャ✖️サーバサイドKotlinの採用です。これは現場からどうしても採用してきたいと強く言ってきたもので、現場のボトムアップを承認する機会が作られた事は私自身もさらに前向きになるきっかけをもらいました。
また、同時期に、私が兼務している他部門でも現場主導でGCP✖️マイクロサービスアーキテクチャ✖️Goの構成の新システム開発が動き出しました。会社自身が前向きに変わりつつあるきっかけのような出来事です。
しっかりとモダンなノウハウを積み上げられれば、採用文脈での会社の特徴も変わってくると思っています。結果、感度の高い人を効率的に採用出来るように、TechBlogの運用も準備しています。
結果会社は変わったのか
私個人の評価としては、「変わっている（ところ）」という認識です。私の考え方に賛同してくれる沢山の仲間が増えました。ただ道半ばです。
まだまだ私自身、社員全員に信用されているわけではないですし、私が関わる部門とそれ以外の部門での軋轢を感じることもあります。（陰口を叩かれることも沢山あります）
「それでも」やっていかないといけません。
個人としては、仕事が仕事である以上、また会社が利益を追求する団体である以上、後ろ向きな仕事や、安定し続ける仕事はないと考えているので、「課題を課題と認識」し「泥臭くても面倒くさがらずに一歩前に進める」事がボトムアップの文化の本質だと考えていますし、そこにしか未来がないと思います。
ちょっとエモくなりましたが、私は基本的には、エンジニアの質の差は意識の差以外にないと思っているので、ベンチャーであろうが、カチカチに固まっている会社であろうが、仕組みとやる気次第で変わると考えています。
参考になるかどうかはわかりませんが、ちょっとでも今回の話が意識のどこかに引っかかってもらえるとありがたいです。