Stanby Tech Blog

求人検索エンジン「スタンバイ」を運営するスタンバイの開発組織やエンジニアリングについて発信するブログです。

プロダクト開発体制のこれまでとこれから

こんにちは。スタンバイで Engineering Manager(以下EM)を担当している高原です。

今回はスタンバイのプロダクト開発がとっている組織体制とそのねらいをご紹介させていただきます。
そして、現実に生じている課題、講じている対策についても触れさせていただくことで、よりリアルな開発組織の現状と今後の展望を共有させていただこうと思います。

スタンバイのプロダクト開発体制

Product Drivenを実現するための組織ビジョン

スタンバイでは会社全体として“Product Driven”を掲げており、開発組織はプロダクトロードマップの実行に責任を持ち日々開発に取り組んでいます。
プロダクトロードマップを達成するための各テーマ毎にチームを構成、役割・責任・権限を明確化することで、それぞれのチームが自らミッションや目標を定義し、メンバーが一丸となって目標に向かって取り組む体制で開発を進めています。
また、開発組織ビジョンに掲げている「自立型組織」として各チームが動けるよう、開発プロセスにおいても、は各チームで最適な手法を追求することを推奨しています。

開発組織ビジョン「自立型組織」

なお、「自立型組織」は「自律」のミスタイプではなく、「自立」で合っています!
広辞苑からそれぞれの意味を引用させていただくと次のようになります。

じりつ【自律】
自分の行為を主体的に規制すること。外部からの支配や制御から脱して、
自身の立てた規範に従って行動すること。

じりつ【自立】
他の援助や支配を受けず、自分の力で判断したり身を立てたりすること。ひとりだち。「経済的に―する」

CTO明石の言葉を借りれば、「自律」は『成人や社会人として、あたりまえの観点』という位置づけで、そのうえ更に『ひとりだち』している状態を目指すという意図を表しています。
「自立型組織」に添えてある「個々人が事業を深く理解し、個々の専門性を発揮し、自らの裁量を持って実行できている組織」は、その『ひとりだち』が実現した状態を言い換えた文章になっています。

開発組織ビジョンの図で特に該当するところを青字にしたもの

導入している組織体制と仕組み

ドメイン構成に沿ったチーム体制

ところで、現在の組織体制に変える以前は、プロダクト開発全体でLeSS(Large-Scale Scrum:大規模スクラム)を実践していました。
当時は、大半の開発メンバーが3〜5チームに分かれて所属し、全チームがスタンバイの全てのサービスの開発・運用に携われる状態(スタンバイ全体を対象範囲とするフィーチャーチーム)を目指す体制をとっていました。
しかしながら、スタンバイが提供する検索サービスはビジネスドメインも技術ドメインも広範囲に跨がっているため(下図参照)、これらを包括的に開発・運用できるフィーチャーチームの実現というのは、かなり難易度が高い状態を目指していたと言えます。

技術ドメインの構成イメージ

そのため、実際にはどのチームにも得意な技術ドメイン・サブシステムがあるいっぽうで、いつまでも触ることができない技術ドメイン・サブシステムもあるという状態を抜け出せていませんでした。いま思えば、これらの技術ドメイン全体をカバーするフィーチャーチームを目指すことは(例の“チームトポロジー”でも指摘されている)「認知負荷」が相当高い組織体制を目指していたと言うことができます。

2021年1月に現CTOの明石が就任後、この問題に着目して組織再編に着手し、新年度を迎えた2021年4月から技術ドメインに基づいたチーム体制へと移行しました。

チーム横断コミュニケーション施策

同時にこれらのチームを横断するコミュニケーション設計を行って、チームの細分化と裁量の付与によって起こりがちなサイロ化や意志決定の遅延を防止するために、相互に状況を把握したり共通の課題に対応したりするための基盤となる仕組みを導入しました。
具体的には次のようなもので、現在も(都度調整を加えながら)運用しています。

  • 最低限のルール整備と情報のフルオープン化
     ・各チームのSlackチャンネルはpublicで作成、原則全員参加
     ・横断会議体のオープン化(参加自由、議事録開示)
     ・全OKRを可視化
  • チーム横断案件の相談先とアジェンダの透明化
     ・Monthlyでプロダクト開発全体に関わる情報共有や表彰などを行う会議を開催
     ・Weeklyで全チームのOKR進捗会議を開催
     ・DailyでプロダクトマネージャとCTOといった意志決定者が揃う(議題持ち込み制の)相談時間を確保
根幹となるプロダクト開発行動指針

そして、コミュニケーションの共通言語を作るべく、プロダクト開発における行動指針を作成しました。

これは個人とチームの行動とマインドセットに関する期待を言語化したもので、「START」の5つの頭文字で構成しています(「S・T・A・R・T」それぞれが示す内容については、以前の記事『スタンバイのプロダクト本部の行動指針「START」と「Engineering Belt」とは?』をお読みいただけると嬉しいです)。

この行動指針「START」が会話の端々に出るレベルに浸透するため、月次で行っている表彰の選考観点や、採用・評価・育成・人材配置の観点にしています。そして、このTech Blogなど社外に情報を発信する際の規範とするなど、常にプロダクト開発活動を照らす鏡として使うようにしています。

プロダクト開発行動指針「START」

なかでも、横断コミュニケーションの基盤として=サイロ化や意志決定の遅延を防ぐものとして次のように行動指針が対応しています。

  • Transactive memory(どこの誰が何に詳しいかの理解)を活用して協力を仰ぎながら
  • Scientific(科学的)な数字・データを共通言語として使うことで、様々な立場のメンバー間の判断のブレを無くしてコミュニケーションロスを減らし、
  • Relevantに(自分ごと化して)染み出して行動できるようにする

以上でご紹介させていただいたような仕組みを基盤として、各チームが担当ドメインにおけるプロフェッショナルへと進化し、それが更に個々人のレベルまで落とし込まれた状態の「自立型組織」を目指して、2021年の4月に現体制のスタートを切りました。

2021年4月に掲げた「目指す開発組織の姿」

生じた課題、講じている対策

このような開発体制と仕組みを導入しましたが、さすがに「全てが順調に自立型組織に向かっています!」というわけではありません。
当初「目指す開発組織の姿」で掲げていた「1年後の状態」に対して、既に1年半が経過している現状はどうか?という観点で振り返って、生じてきた課題を飾らずに書き留めておきたいと思います。

横断案件の難航

  • 複数チームが協力して実現する必要がある開発案件において、関係メンバーが皆、自チームの開発案件と掛け持ちするかたちになり、「船頭不在」状態に陥った。
  • (それでも自分ごと化して先頭に立ってくれるメンバーがいたものの)担当外ドメインの要件定義やアーキテクチャ設計が手探りになったり、意志決定機関が不明瞭でスタックしたりした。
  • 異なる時間軸で開発するチームが集まって協働する開発プロセスの確立や、共通理解をとるコミュニケーションにスピード感が出なかった。

これらの課題に対して、既に対策を講じているものをいくつかご紹介します。

  • プロダクトマネージャ直下にプロダクトマネジメントオフィス(PdMO)という独自組織を設置して、チーム横断の課題管理を行うことにした
  • チーム横断イシューをバックログ化して、各チームのバックログのEpicレベルや各チームのOKRと紐付けられるよう可視化し、全体整合性をとるようにした
  • チーム横断イシューの責任者(いわゆるプロジェクトリーダー)を指名して、複数チームで連携する開発スケジュールの見積りや進捗状況の集約する役割を明確化した
生じた課題と既に講じた対策

もちろん、これで十分とは考えていませんし、今講じている対策も含めて振り返り、UPDATEし続ける必要があると考えています。
今後に向けてまだまだ先にある目指す組織の姿に向けて加速していくために、当面は次のような課題に向き合っていかなければと考えています。

チーム間で共用できる「型」の導入
  • 各チームの専門性を活かした提案や指摘を結集して要件定義や開発計画を行える開発プロセスの前半を再定義するとともに、要件や背景の透明性と相互理解度を高める共通フォーマットを導入する
  • そうすることで、結果的にチーム間のコミュニケーションコストを下げ、そのぶん仮説検証のスピードを高めたい
事業とプロダクトの未来像の透明化
  • CxOやプロダクトマネージャらが描く事業やプロダクトの未来像の透明性(⇒メンバーの理解度と納得度)を高める仕組みと、それによって質が高まることが期待されるボトムアップ型の提案と議論のハードルを下げる仕組みを構築する
  • そうすることで、いま対策で入れている「横断イシューのバックログ」を廃止したい(バックログがあると、そこに書いてあるwhatを見がちになり、whyを見ての革新的な提案やトライアルが出にくくなるリスクを感じているため)

こうやって(改めて・再び)、チーム横断で行うトップダウン的なマネジメントを減らして、チームの自立度を高めていきたいと思います。

いま少し引いて眺めてみると、共通の「型」を持たないまま独立性の高いチーム体制で走り始めた後、チーム間で連携が必要になった際に、コミュニケーション・インタフェースをいちいち構築する必要が発生しているというのが現状のように思われます。

そのために最小限の「型」を入れようとしていますが、決してトップダウンで物事を決めたいわけではないので、今後「型」の機能レベルが高まっていけば、集中管理的な仕組みをどんどん外していくべきだと考えています。
そして、権限を分散させ、集合知を最大限に活かす、すなわち「自立型組織」に、どんどん近づけていきたいと考えています。

このようにまだまだ成長途上にあるスタンバイのプロダクト開発組織です。
これからも、ものづくり・事業づくりの効果を高めるための仕組みづくりを考え続け、トライアルし続けていきたいと考えていますので しばらく走って・・・また経過報告をさせていただければと思います!

以上、ここまでお読みいただきありがとうございました。

スタンバイのプロダクトや組織について詳しく知りたい方は、気軽にご相談ください。 www.wantedly.com