見出し画像

『ろばを売りに行く親子』から学ぶ、エンジニア組織デザイン

はじめに

リテイルテックベンチャーでプロダクトマネージャーをやっているナニワです。どうも、こんにちは!
本日は、TechPlay主催のイベントに参加させてもらい、かなり為になるインサイトを頂いたので思考の整理含め、「PdM目線」でのレポートをまとめたいと思います。
※参加イベント:「10名、50名、100名規模それぞれのB2B SaaS技術組織に聞く、フェーズ別ハードシングス」 〜組織拡大中の3社が向き合うエンジニア組織デザイン〜

参加企業の紹介

オクト
建築・建設業に特化したプロダクトを開発されているベンチャーです。
最近、○○テックという言葉がそこここで叫ばれるようになりましたが、この会社でいうと「Constech(コンステック)」「Architech(アーキテック)」でしょうか、笑


ホテル業に特化した価格最適化(ダイナミックプライシング)に関連するサービスを展開されている会社だそうです。
ご存知の方も多いと思いますが、最近ではホテルの宿泊費を予約率や過去の傾向から機械が導きだすというやり方を取っているホテルが多いです。

sansan
特に説明不要かも知れませんが、法人向け名刺管理「sansan」と個人向け名刺管理「Eight」のサービスを提供しているベンチャーです。
自分は以前参加したsansanのイベント(Sansan Builders Box)でsansanの目指す世界感に共感し、sansanを好きになりました!

発表内容

登壇されたのお三方の話を箇条書きになりますが、書きます。

下司 宜治さん (株式会社オクト 執行役員 VPoE)

・建設業界のマーケットは大きい。
 日本における建設業界のマーケットはなんと、48.5兆円!
 自動車業界に次いで2番目に高い数値だそうです。

・建築業界が抱える課題は、「生産性の低さ」「少子高齢化」「現場の業務がアナログ」
 生産性の低さに関しては、IT業界が平均一人当たり7,000円程度売上を出しているのに対し、建設業界は2,700円でかなり低い

・&ANDPAD(オクトのプロダクト)は、一言で言うと「Dropbox」「Redmine」「chatbot」を足したサービス

・組織体制は大きく「CTO」「CDO」「VPoE」に分かれる

 CTO・・・既存サービス、中長期計画
 CDO・・・新規サービス、短期中期
 VPoE・・・組織マネジメント、採用

・スケール期に発生した問題(5人→50人)

・開発スピードが遅れる
・個人の特殊実装
・品質悪化

上の問題に対してどのように取り組んだか、

・品質改善プロジェクト(技術負債を解決したら寿司一貫)
 バグが多発しエンジニアが対応に追われたがモチベーションを維持する為に行ったのが、「技術負債を解決したら寿司一貫」
 寿司自体はモチベーションに繋がらなかったが、毎回品質が大事だということを伝えていたのでメンバーにも品質に対する意識が芽生えた

・チーム間異動を積極的に実施
 あるドメインに対してのみ知識が深くなるが、横串で見れない。という解決する為にやったが良かった。

・進捗会をチーム横断でやった。
 困りごとの相談をチーム横断でやったことが良かった。

・会社やプロダクトの思想についての伝搬
 CTOが会社の歴史を語ったり、第一号社員がプロダクトの思想をプレゼンすることでプロダクトのそもそもを理解してもらえるように努めた。

・顧客からの問い合わせ対応
 スケールにより顧客が1,600社、問い合わせが44,000件となり、エンジニアがものを生み出せない状況が続いた為、「テクニカルサポートチーム(CRE)」を発足。
 ただし、採用が難しい。テクニカルサポートのキャリアパスをしっかり描いてあげる事が大事。

田仲 紘典さん (株式会社空 CPO 取締役兼エンジニア)

・カルチャーは「LiveDirect」「Overachive」「Backcasting」
 特にLiveDirect(本音・本質・真実で生きる)のことは強く繰り返していました。

・ビジョン・ミッション・コアバリューは最低限、経営者同士で最低限決目ておいた方が良い。

・ミッションは共に作り上げていくサービス(世界感?)だから、
 そこまで齟齬は出ないかもしれない。
・ビジョンは将来の見えている景色の一致
・コアバリューは一緒に働くメンバーの価値基準の一致
 コアバリューは迷った時の行動の判断基準になる。

・採用について

創業当初は「面接のみ」だったか、色々な課題を経て以下の形になっている。

面談
人事面接
プレワーク
最終面談(CEO)

採用に当たってはカルチャーマッチ、スキルマッチが重要

過去には、「カルチャーマッチ高×スキルマッチ低」「カルチャーマッチ低×スキルマッチ高」の人材を採用したが、どちらも上手くいかず。
前者は、試用期間で終了。(会社の体力的と成長が合わず、開発の鈍化)
※ここでプレワークが重要だということ気づく。
後者は、結局カルチャーマッチ出来ず退社。

定期的な1on1は大事
 1on1では、業務の確認をせずにメンバーの抱えている課題、成長について、「LiveDirect(本音・本質・真実で生きる)」に話す。

谷内 真裕さん (株式会社sansan  Engineer Managementグループ)

・事業が急成長
 谷内さんが入社された2015年は200名で、現在550名以上。部長、副部長以外はフラットな組織になっている。

・開発体制は、7名1チーム
 PM、DE、エンジニア複数。バックログからPMがやることを決めて、DE、エンジニアへ依頼。やることについてはPMとPO(CEOの寺田さん)とコンセンサスをとる。

・組織拡大に伴う困難

サイロ化による様々な問題
 ・プルリクが燃える
 ・手戻り(機能間(チーム間)の仕様不一致)
 ・意志決定の難易度が上がる。
 責任の所在が不明確
 ・実行責任
 ・説明責任
 ・協業先
 ・報告先
 ・・・etc.

とりあえずマネージャーに報連相するしかない状況。

ユーザーの為になっているか。
(プロダクトマネジメント/プロジェクトマネジメント目線」)

 プロダクトマネジメント
 ・正しい優先度となっているか
 ・大切なことに集中できているか
 ・仮説検証のフローが成り立っているか
 ・ユーザーに価値を提供できているか
 ・勝ち筋は見えているのか
 プロジェクトマネジメント
 ・しっかり計画が立てられているか
 ・見積もりの精度
 ・しっかり実行できているか
 ・集中できる環境か
 ・持続可能なペースで進んでいるか。

仕事に向き合ったら、仕事を楽しめる?

 手応え・実感が欲しい
 ・自分いる意味あるんだっけ?とならないようにメンバーのどこに価値を感じているかを伝える。
 コンテキストを共有したい
 ・目指す理想像は何か。
 ・これからの組織はどうなっていくのか。
 ・これから私達はどうしていくのか。
 ・何を大切にして仕事をするのか。
 ・どのように変化していくのか。

・これらの困難に対してどう乗り越えていっているか。
(組織体制(10倍にスケールする組織へ))

 グループ
 ・グループごとにミッションを持つ。
  プロダクト、インシデント、エスカレーション、QA、組織デザインの各グループ
 チーム
 ・既存チーム体制の解体
  今はPdM、DEは複数のチームを掛け持ちとなっている。
 役割
 ・PdMについて、配置換えを実施した。
   エンジニア経験のある人を必ずPdMにすることとした。
   (エンジニアコミュニケーションコスト、エンジニアの気持ちを汲み取るという面においてもこの形が良いとなった。)

プロダクト/プロジェクトマネジメント

 プロダクトマネジメント
 ・開発プロセスの再構築
 ・バックログ一本化
 ・短期/中期、長期目線を明確化
 ・揉めない優先度
 ・顧客フィードバックの仕組み
 ・事業ニーズに先手を打つ。  
 プロジェクトマネジメント
 考え方としては、「当たり前のことを当たり前にやること」が大事。
 ・プロジェクトの責任を明確化。
 ・QCD
 ・進捗管理
 ・計画レビュー
 ・プロジェクト管理しないものを定める
 ・プロジェクトの振り返り&プロセス改善
 可視化
 ・全社にバックログを公開
 ・誰が何をしているのかわかるようにする
 ・手応えのある仮説/検証/改善
 ・APM
 ・NPS
 ・データ分析基盤

開発プロセスについては、1ヶ月ほど議論して現状下記のような形になっている。

画像1

組織マネジメント

 戦略
 各チームに任せていたのが、組織が大きくなると立ち行かなくなる。
 ・開発の理想時間(本当に開発できる時間)を出す。
 ・生産性の計測
 ・チーム構成や配置
 ・組織体制の将来像
 ・会社や事業ニーズを押さえる
 ・経営戦略や目標を実現するための戦術
 育成・評価・採用
 採用に関しては、人事部任せにしないことを心がけている。
 環境
 ・情報伝達の設計や開発ナレッジの共有には力を入れている。

・大切にしたいこと

大切にしたいことということでいくつかご紹介いただきましたが、どれも為になる話でした。

画像3

視座が異なる役割(いち社員とマネージャーなど)の場合、各々役割で見えている世界、見えていない世界が異なるということです。
なので、積極的にコミュニケーションを取りに行きましょう。

画像4

「ろばを売りに行く親子」が一番自分の中で響きました。
上のスライドではロバと親子が3パターン描かれていますが、どれが正しいか問われた時に意見が分かれると思います。

結論、「誰もが正しいし、誰もが間違っている。誰も正しくないし、誰も間違っていない」です。

私自身、PdMとしての業務の中でこのような状況に追い込まれることがありますが、自分の中で大切にしていること、また、それをエンジニアに説得できることが重要だと思ってます。

まとめ

各社の話を「PdM目線」でお聞きして感じたことは以下の2点です。

「自分の大切にしていることは何か?」

いちPdMとして、誰も答えを知らない世界を描いていかなければならない、そんな時に判断の基準になるポイントだなと感じました。

「透明性のある組織」

チーム内での積極的なコミュニケーション、またチーム横断でのコミュニケーションで解決される課題が多くあるなといった印象です。
否が応でも情報が集まってくるPdMなので、各ステークホルダーの潤滑油となるよう努めていく必要があると感じました。

長い文章でしたが、ここまで読んでくださりありがとうございました!


この記事が気に入ったらサポートをしてみませんか?