納得度の高いプロダクト開発とは何だったのか。前編

こんにちは。武田（@tkdn）です。今日は「納得度の高いプロダクト開発とは何だったのか」というお題で開発チームが現場でどう変わろうとしているかという話をします。

簡潔に申し上げれば、技術的な取り組みを推進するものの直接事業目標にコミットできていなかった開発チームが、プロダクトマネージャー・プロダクトオーナーの役割を部分的に剥がして目標となる KR に対してコミットできる開発チームへと変わろうとしている話になります。

「納得度の高いプロダクト開発」という言葉自体かなり主語が大きく、人それぞれの主観でとらえ方が変わりそうですので、あくまで我々の開発チームにとって、という冠はつけさせてください。

また私個人が所属する開発チームにおける現時点の取り組みに至るまでの変遷ですので、mediba 全プロダクトチームに該当しない点はあらかじめお断りしておきます。

内容が膨れてきてしまったため前編と後編に分けています。この前編についてはだいぶ観念的な部分が多く実践を知りたいという人は後編だけ読まれるのをお勧めします。

前編は組織変遷と組織形態に対する一般的な解釈に並行し、分業・標準化について考え、今ある課題への取り組みについてお話します。そのあとに個人が勝手に抱えたチームの課題感について触れていきます。

後編は前編で明らかとなった開発チームの課題を解決するべく、今チームはどう取り組みどういった変化が起きているか、具体的な事例について話します。

ものづくり再解釈

弊社 VPoE 新井の記事にもあるとおり、組織構造はここ数年で大きく変わりました。2018 年中期に機能別組織としての開発本部はなくなり縦割りの事業部制組織へ変更されたあと、2020 年にビジネス、テクノロジー、クリエイティブ部門レイヤとなる横串の組織体ができていわゆるマトリクス型組織に変化しています。

テクノロジー部門では、定期の活動報告会が開催される（オンライン・ニ◯◯コ動◯風なコメント付きで）、数年眠っていた勉強会が再開される（クソゲーを大量に作って品評する）、などマトリクス型となった開発横組織の活動の一部はこのブログでもお伝えしたとおりです。先日の Agile Tech EXPO での報告にもあるシニアマネージャー森實のセッションでも取り組みの一部が垣間見えるのでぜひ御覧ください。

組織体の変遷、一エンジニアからの雑感

ここ数年思いつきで組織が変わっているわけではありません（私の知る限りにおいては）。変遷の中でそれぞれの組織体で求められたこと、その変遷をざっくり振り返ってみます。

組織体種別/特徴分業のスタイルアウトプット標準化対象
機能別組織直列的統合的スループットコントロール（プロセス）
事業部制組織並列的加算的アウトプットコントロール
機能別組織事業部制組織

技術基盤が固まった、機能別組織

機能別組織では各作業工程が直列でチェインしており、ビジネスや企画やディレクション、デザインそして開発から品質管理といった工程の分割が行われます。直列分業により前工程のアウトプットが次工程のインプットとなり、前工程に依存したコンテキストを持つ、リレー的協働が多くなるでしょう。全工程のアウトプットが最終的な成果として統合され、組織の経営成果となるのが特徴です。

機能別組織を成す目的は予測された目標をクリアするためです。 作るものがはっきりしている場合に有効で、最終的な成果統合のために、機能別組織であった開発本部でも予測可能な目標設定を持つことになります。

たとえば事業スキームの形成とそのシステム化が目的であった場合、予測されたゴールはシステムのリリースになるでしょう。リリース後一定の経済効果を生み出すために安定したシステムを提供することも、この組織体の目標になるかもしれません。

直列した工程の最終的なアウトプットであるシステムリリースや安定した運用を目標として、開発組織はものを作るためのプロセス、マニュアル、そしてインフラを整備し標準化してきました。具体的に言えば全社通してのインフラ AWS 移管、それらを利用するにあたっての知見集約やマニュアル化、技術的プラクティスの伝播などが標準化にあたるでしょう。これらは作業工程のプロセスコントロールであり、標準化の対象はスループットになります。

当時の CTO を中心に、機能別組織の中で技術的躍進や文化形成などに十分投資できたおかげで、AWS をはじめとしたクラウドを当然のように利用できているという現状があります。

作り物のゴールや成すべき作業目標が明確かつ予測可能である一方で、機能追加やリリースだけを前提としているため、作ったあとの価値提供や事業成長について考える観点がどうしても抜けてしまいます。ものを作ること自体・作る数を達成目標にするということは、プロダクトマネジメントでも「ビルドトラップ」として言及されていますね（機能別組織だから頻出するわけではありません、事業部制でも・だからこそ生じる問題ではあります）。

成長のための事業部制組織

予測可能な目標ではなく変化する市場やニーズをかんがみて、ユーザー体験・価値提供とビジネス価値のバランスに重点を置き、mediba は CXO を中心としてユーザー体験にフォーカスしていくと同時に事業部制組織へと組織体を変えていきます。

機能別組織と違い異なる職能がひとつのチームを形成し、その事業部ごとの複数のプロダクトチームは並列で開発しプロダクトを成長させます。

事業部制組織は複数チームがそれぞれ並行してアウトプットし、それらを加算したものが経営成果となります。分割された経営資源の合算が最終目的ですので、数値目標のようなアウトプットコントロールによる標準化が特徴で、プロセスをコントロールしない（できない）のが機能別組織との違いです。

事業部制組織の目的・狙いは絶え間なく変化する外的環境の不確実性へ立ち向かうため、事業・プロダクトチームはものを作る方法を委ねられたのだと理解しています。

それぞれの事業において、不確実性が高く例外となる事象が発生しやすいケースでは、専門性をもったチームでの組織学習によって得られた思考能力・応用力・判断力に任せて対応を進めるほうが効率的です。事業やビジネススキームに合う形でワークフローは整備され、求められるシステムもそれぞれの事業にあった形で成熟していくことになるでしょう。

事業部制組織がうまくいくケースでは、事業ごと組織内での市場的競争により健全な競争意識が醸成され、事業・プロダクトチームの達成感やエンゲージメントを高めるだけでなく組織と個人の成長を望めそうではあります。書籍から引用しますが、書けば書くほど甘美な組織体ですね。

“各チームを並列化、競争を生むことで組織内部の切磋琢磨を望むことができる”
“アウトプット・コントロールはプロセス・コントロールよりも不確実性に対して頑健”
“管理する側に負担がかからない”

課題に対する現状のマトリクス組織

しかしどの組織も一定の課題を抱えるように mediba の開発組織も例外ではありませんでした。事業部制により、技術指針や設計レビュー、Ops を含んだシステム保守のあり方など、機能別組織の中で標準化されていた・されようとしていたことはプロダクト開発チームに閉じていくようになりました。いわゆるサイロ化というやつです。

サイロ化が悪いわけではありません。機能別組織が敷いた旧来の標準化されたプロセスにブロックされチャレンジできなかった領域へ取り組める、事業とのバランスを考え余剰を活かして新しい技術要素を広げていける、などのメリットもあります。

ただしその一方で、ほかの事業部の開発には無関心といった状況もないとは限りませんし、マネージャーからすればガバナンスの効力範囲が小さいうえ観察できることも散漫になるでしょう。

そういった課題解決にマトリクス型組織が求められるのは当然で、その一環として前段で申し上げた取り組みがあるというわけです。まだ始まったばかりの組織体ですのでテクノロジー部門では課題への取り組みを一層強化していくでしょう。

一エンジニアの課題感

事業部制になってからチームが持つ目標に対してダイレクトなコミットができない（と思い込んでいた）というのが自分の大きな課題となっていました。

機能別組織であれば開発組織自身が掲げる目標を意識しながら個人の技術的な取り組みや日々の活動のテーマを昇華させやすいと感じていましたが、 事業部制となると自分ができることは何なんだと立ち止まるようになったのです。 こう感じている開発者は私だけではなかったはずです。

プロダクトチームの開発者として取り組めることを苦悩しながらさまざまな実践をしてきました。

  • モブプログラミングの実践により属人化を排除する
  • リリースの回数を増やしていく（ためのプロセスを構築する）
  • 運用コストを下げるために X を導入する、Y からリプレイスする
  • パフォーマンスを計測しメトリクスから異常値を検知する
  • チームで合意しブレないものづくりに取り組む

以上はいずれも取り組みとしてポジティブに見えます。ただ事業部制といった組織軸においては取るに足らない改善業務のように感じてしまうことが多くなってきたのです。もちろん実際には取るに足らない改善業務ではけっしてありません、技術組織が強くあるためには必要な取り組みです。

※ 上記のような技術的な取り組みを評価すべくテクノロジー部門ではどういった評価が適切かといった議論や実評価も試験的に進んでおり、組織的な課題解決に取り組んでいる最中です。

開発者の中にある不確実性

より良いプロダクトチームの組成といった部分においては現マネージャーと協働しながら良いメンバーに恵まれチーム自身も成長しているものの、さてプロダクトに対してどうかと言われると自信がまったくありません。

チームのデータアナリストにはプロダクトが追うべき数値を可視化してもらっていましたが、伸び悩む数字をデイリーイベントで見ては無力感を日々感じ、事業に対してコミットできたかどうかの手応えのない状態がしばらく続きました。若干それに麻痺しかけていたことも危機感の 1 つです。

そうなると人間はどうしても環境や外部に要因を見出そうとして、市場やユーザー、プロダクトの特性に不確実性を探してしまいます。

しかし、不確実性は市場や外的環境の変わりやすさだけではなく、人間の推測する能力が低いことも影響します。それと同時に能力の低さの根本には、無知・無関心があるのではないでしょうか。 プロダクトについての理解不足からコミットできる領域を自分自身が狭くしている可能性について考える必要があるでしょう。

前編はここまでです。

開発者としてプロダクトへダイレクトに関与できなさというのは、自らの能力の低さと関心の無さにある起因するのではと思うにいたり、今どうやってプロダクト開発に取り組んでいるか・納得をえるためにどうしているかといったことを後編で書いていきます。