WealthParkの開発組織について(2023年)
WealthParkでVPoEをしています、藤井@taka_ftです。
去年WealthParkの開発組織のアップデートして、2022年におけるWealthParkの開発組織について紹介させて頂きました。
あれから早1年が経過するということで、時の流れの速さを感じます笑。
また、この1年でもWealthParkの組織やプロセスに様々な変化が起こりました。
2022年のアップデート版ということで2023年度版の組織や体制について記載します。
何をしている会社か
詳しくは、下記の会社紹介資料をご参照ください！
エンジニアの方向けにプロダクト開発の観点でみると
WealthParkビジネスという、不動産管理会社、不動産オーナー様向けのプロダクト開発(不動産テック)
WealthPark オルタナティブという小口化事業DXプラットフォームの為のプロダクト開発(FinTech)
大きくは2つのプロダクト群の括りがあり、そのいずれかの開発、もしくはプラットフォーム、共通基盤の開発に関わって頂いているイメージです。
2022年の開発組織
2023年の開発組織を説明する前に、去年までの開発組織について簡単に説明します。
2022年の組織では、開発組織が1チームで構成される組織体系でした。(詳しくは2022年版の記事をご確認下さい)
開発組織が1チーム(かつ基本的には職能別の組織)でいることで、良い側面も多くありましたが、組織の拡大に伴い、課題も出てきました。
良い点
開発組織が1チームとして一体感を持ちやすかった
開発組織で完結する議論については早い決断ができた
組織を拡大していく中でも開発組織が健全なチームアップを継続することができた
状況に応じて、柔軟にアサイン調整やタスク調整が行いやすかった(ただ、組織が拡大したり、機能数が拡大する中で課題にもなっていた)
横断的に設計やレビューや議論がやりやすい環境だった
職能別の組織によって、方向性の統一などはやりやすかった
課題
柔軟にやっていたが故に、コアな人材が様々な箇所にヘルプに行くようになり、一部のメンバーの暗黙的なマルチタスクが増えていた
開発部署以外とのコミュニケーションをもっと活発に出来ないかと考えることが増えた
人数が増える中でコミュニケーションパスがとにかく複雑になっていた
それぞれの担当範囲や誰が何をやっているかある程度理解して初めて良いコミュニケーションが取れるな状況になってしまっていた
良くも悪くもエンジニアリングの全体最適を考えることで、ステークホルダーに向き合ったプロダクト開発意識が希薄になりやすくなり、いかに(エンジニアリング観点で)効率よく開発できるかという思考になりがちだった
エンジニアリング観点の最適化が事業の意識とギャップを生むケースもあり、結果としてステークホルダーに向き合った素早い対応ができないケースがあった
事業ごとの優先順位がある中で開発組織は1つのチームなので、アサインのコンフリが発生した場合、エンジニアのアサインの優先度の調整に時間が過度にかかるケースがあった
2023年の開発組織
こちらが、2022年と比較し、最も大きなアップデートがある箇所になります。2023年、WealthParkはステークホルダードリブンで組織を変更する決断をしました。(※ ステークホルダードリブンで組織を変えるのは、開発組織に限らず、全社としての決断になります。)
具体的には、開発組織を大きく3部門に分けました！(Enterprise(法人事業本部), FinTech Consumer事業本部, Platform Infrastructure)
ステークホルダードリブンは、言葉の通り、ステークホルダーと向き合うための組織変更です。そのため、ステークホルダーという切り口で、EnterpriseとFinTech Consumerの2つに組織を分けています。これは、タイミングやフェーズによっては、プロダクト別組織と沿うことになりますし、実態としてはかなりプロダクト別組織と近くなります。ただ、向き合うものの視点はあくまでステークホルダーであるということです。
また、開発組織が拡大する中で、プラットフォーム視点で横軸で考える組織も必要です。Enterprise、FinTech Consumerに加えて、Platform Infrastructureという横軸組織が生まれました。
そして、今回の組織変更によって、私自身の役割も変わりました。今回の組織変更に伴い、私はより横断的なエンジアリングマネジメントに注力し、縦軸組織をそれぞれ別のメンバーにリードして頂いています！これによりマネジメント負荷の分散と、それぞれが何に責任を持つかがより明確になりました。
ということで2023年の開発組織でもっとも変わった点は、開発組織が2つの縦軸組織と1つの横軸組織に分かれたことです。
ここから縦軸組織と横軸組織についてそれぞれ説明していきます。
縦軸組織
Enterprise、FinTech Consumerはいわゆる事業別組織であり、上記の図は開発組織のみを記載していますが、同列にProduct、Design、カスタマーサクセス、営業部などが配置され、文字通り同じステークホルダーに向き合う全ての組織が1つの部署として配置される組織体系となっています。
これにより、より事業内での横断的なコミュニケーションを促進し、開発組織がより事業に溶け込むことを目的としています。
開発組織の中では、ドメインやFocusによってチームが分割されますが、これらは職能による分割ではなく、ドメインやFocusによるチーム分割としています。
つまり、縦の組織はFrontEnd、BackEnd、Mobile Engineerなどが1チームとして配置されています。(機能によってはBackEndだけで完結するものもあるので、そういう場合はBackEndだけが所属しているチームも存在します)
これはチームトポロジーで言うところのストリームアラインドチームを目指しています。出来る限り縦軸組織がE2Eのオーナーシップを保持し、素早い決断とデリバリーの為のアクションを独立して行えることを狙いとしています。(後述しますが、一方で完全に独立で配置していない機能(QAやSREなど)もいます)
ストリームアラインドチームについて
ストリームとは、「ビジネスドメインや組織の能力に沿った仕事の継続的な流れのこと」とされています。組織が価値を生み出し顧客に届くまでの価値の流れだと考えてよいのではないかと思います。ストリームアラインドチームは、「価値のある単一の仕事のストリームに沿って働くチーム」とされています。一つの価値の流れに関して、出発点から到達点までのすべてに対してオーナーシップを持っており、他チームへの仕事の引継ぎを必要としません。※価値の流れの中でチーム間での仕事の引継ぎを要するようなあり方は、チームトポロジーにおいてはアンチパターンなのでしょう。
ストリームアラインドチームは、組織で根幹となるチームタイプであり、残りの基本的なチームタイプの目的は、ストリームアラインドチームの負荷を減らすことにあります。
繰り返しになりますが、この目的の実現のために、今回の組織変更に伴い、Enterprise、FinTech Consumer共に専属の開発責任者(Director、VPoE)を配置しています。
横軸組織
一方、全てを縦軸組織で完結しようとすると大変なことが多くあります。縦軸組織、ストリームアラインドチームの力を最大限発揮するために、WealthParkでは組織変更に伴い、横軸組織を立ち上げました。
横軸組織はProductivityとTechnology Drivenの2つをテーマにしています。
(英語の文章を日本語に訳しているので、一部固いところもありますが)
Productivity
横断的な技術支援、高い技術力によるブレークスルー、技術的負債の削減による業務組織の開発経験の向上、SREによる開発しやすいプラットフォームの準備、PMOによる開発プロセスの改善・管理、QAによる品質管理など、必ずしも直接的ではないものの、縦割り組織の開発生産性の底上げに寄与すること
Technology Driven
(ステークホルダーに対して)ある程度独立して活動し、ビジネスの優先順位に（強く）影響されない組織であるため、技術主導で会社に貢献することが求められる。それは、例えば技術負債の改善、新しい技術の検証・検討、縦軸開発チームと連携し、より良いアーキテクチャの実現などである。技術を通じて会社に貢献することを体現する組織になること
具体的な役割は、チームトポロジーでいうところのプラットフォーム、イネイブリングチームにあたる責務が中心となっています。加えて、現状を鑑みたときに少なくとも今は横軸組織においた方が良いよね、という責務、機能も配置しています。
イネーブリングチームについて
イネーブリングチームの役割は「特定のテクニカル（プロダクト）ドメインのスペシャリストから構成され、能力ギャップを埋めるのを助ける」ことです。イネーブリングチームは、「複数のストリームアラインドチームを横断的に支援し」ます。
ストリームアラインドチームが独力で行うよりも効率的に能力を獲得できるようにすること（能力獲得に対するストリームアラインドチームの負荷を低減すること）が目的となります。
プラットフォームチームについて
プラットフォームチームの役割は、「ストリームアラインドチームが自律的に仕事を届けられるようにすること」とされています。ストリームアラインドチームが価値を届けるうえで使用するモノ（ツールやサービス、知識、情報等）を、セルフサービス的に容易に活用できるようにすること、と私は理解しています。
プラットフォームチームにとっては、ストリームアラインドチームがある意味で顧客であり、プラットフォームを通じて、ストリームアラインドチームに対する価値提供を行うチームとみることもできるでしょう。
現在、4つの組織が横軸組織にはあり、それぞれについて説明していきます。
横軸組織の各チームの説明
チャプターリード(イネイブリング)
まずは、チャプターリードと呼ばれる人/ 組織です。現在は、FrontEnd、BackEnd、Mobileの3分野においてチャプターリードと呼ばれる人たちがいます。
繰り返しチームトポロジーを引用しますが、イメージはイネイブリングチームです。現状はほぼリーダーシップメンバーのみが所属しています。(一部メンバーがいる箇所もあります。)
テックリードよりのEMがイメージと近いと思います。
具体的に、下記のような活動を行っています。
横軸でのメンバーのサポート、コミュニケーションや共有の場づくり
職能別の各エンジニアのチームアップ、tips、情報共有
例: フロントエンド横断でのカジュアルな情報交換の場、コード規約などの議論のファシリテート、新しい技術の情報共有を行う・・など
メンバーの技術面での成長支援、一時的な技術サポート
例: 1on1 MTGやslackなどで、技術的な相談相手になる。時にはペアプログラミングを行ったりする・・など
そもそも今回の組織変更で改善したいポイントとして、開発組織のコミュニケーションの複雑性を抑えたいということがあります。一方で、取りに行きたい情報を取りに行ける、相談したいときに相談することができる、そのような横断的な情報共有、コミュニケーションは引き続き重要です。
そのため、現在はチャプターリードがこのような役割を担っています。
この役割に関しては、組織の拡大やフェーズの変化によって見直しや調整が発生すると考えています。
俯瞰的な視点でのアーキテクチャ設計への関与
横断的な議論が必要なアーキテクチャ設計にアーキテクトの1人として入る
(意図がない)技術スタックやアーキテクチャの差などを避ける
横軸組織は事業組織から一歩離れて設計を考えることが出来るので、ある意味客観的な視点で物事を見ることが出来ます。なので、例えばこれは一見Enterprise組織だけのプロジェクトにも見えるが、FinTech Consumer組織のことを考えると、横断的なアーキテクチャの考慮が必要だ、とかに割と気付きやすい立ち位置でもあります。
横軸組織に属するメンバーはある種鳥の目を持ち、俯瞰的な視点でのフィードバックを行います。
一方で、横軸組織がソリューションやアーキテクチャを押し付ける、決めることは目的ではありません。あくまでこの組織の目的は、ストリームアラインドチームの自律性を高めることです。
技術負債改善の為の取り組み
各縦軸組織では事業への貢献のためのプロダクト開発、技術的な改善を日々行っています。一方で、一部の大きなリファクタリング、アプリの再設計・再実装などは、プロダクト開発と並行して行うことが難しいというのも事実です。そのため、
縦軸組織では並行して進めることが難しい、中規模ー大規模な技術負債改善に向けた取り組み
緊急度は高くないが重要度が高い技術負債に対する取り組み
などを行う人・組織が必要だと考えています。これを横軸組織で一定担うことを期待しています。
今は各領域にはリーダー陣以外に数名の小さな規模なのですが、このメンバーのうち一部は、技術負債の改善・解消にコミットしています。彼らが専属の人員として独立して負債の改善・解消にコミットすることで、縦軸組織がプロダクト開発に専念しつつも、並行して技術負債と向き合うことが出来ます。
とはいえすぐに多くの技術負債を解消、巻き取ることも出来ないので、まずは出来るところから始めています。
卓越したスキルに基づく各所で発生している技術的課題の解決のサポート(遊撃部隊/レンジャーチーム)
現状、チャプターリードにおいて、特に大事だと感じているのが遊撃部隊(レンジャー)としての役目です。
遊撃 : あらかじめ攻撃する目標を定めず、戦況に応じて敵の攻撃や味方の援護に回ること
縦軸組織にしたことで、事業ごとの優先度に基づいたアサインメントを各組織で行えることはメリットです。一方で不足の事態が発生し、現状のメンバーだけでは期待を達成できないという状況に直面することは比較的よくあります。
ただ、その都度横断的な議論が発生し、他の縦軸組織からエンジニアをサポートに呼んだりするようでは、縦軸組織の独立性、ストリームアラインドチームとしての責務をお互いに十分果たすことが出来ません。逆に、一切のサポートをせずにストリームアラインドチームで必要なリソースの調達を完結することは1つの理想ではありますが、すぐに完全なE2Eのオーナーシップを持つことは簡単ではありません。
この状況に対して、横軸組織が遊撃部隊としての役目を果たすことで組織に一定の柔軟性を持たせることができると考えました。(トレードオフはある)
一方で、チームトポロジーのイネイブリングチームの説明にもあるように、遊撃部隊によるサポート当たり前にならないようにすること、イネイブリングチームが常に遊撃部隊としての１リソースにならないことは大事です。
組織変更直後はこの役割が縦軸組織をワークさせる上で有効に働いていると考えています。
もともと1人1人の能力が高いメンバーが集まっているので、彼らを固定のプロジェクトにアサインせずに、問題が起きているところや課題があるところ、リソースが足りていないが局地戦での解決が可能な開発などに入り、会社全体としてEnable(可能)なことを増やすことに貢献しています。
チャプターリードとイネイブリングチームとの違い
では、現状のチャプターリードの人たちが、チームトポロジーの定義でいうところのイネイブリングチームの役割と完全に合致するか？と言われると、そうではない所もあります。
プロダクト開発・機能開発により密に関わる
チームトポロジーに書かれているイネイブリングチームとの違いとしては、現状チャプターリードは、プロダクト開発、機能開発そのものにも入り込んでいます。局所的にプロジェクトの開発の一部を担当することもあります。これは、もともとプロダクト開発でも非常に強い貢献を行なってきた人、前組織でリーダーだった人が所属していることも背景としてあります。
今後、より縦軸組織それぞれが成熟する中で、もう少しイネイブリングチーム本来の業務が中心になること考えています。いずれにしても、ストリームアラインドチームが出来ることを増やし、縦軸組織で完結できること、成果を最大化することがそもそもの横軸組織の目的であるため、依存に気をつける必要はあります。
全員がリーダーシップ・マネジメント経験を有している
今のチャプターリードは、名前の通り、もともと職能別の組織においてEM、リーダーを行っていたメンバーです。そのため、FrontEnd/BackEnd/Mobile領域のリーダーという立ち位置になります。なので、単純に技術に強いだけではなく、リーダーシップを持っているメンバーで構成されているという点は、状況が若干異なるかもしれません。一方でイネイブリングチームの立ち上げにおいて、リーダーシップも非常に重要だとは思うので、これ自体は比較的自然なことなのかもしれません。
課題
一方、チャプターリード組織は現状課題もあります。
兼務が発生している
チャプターリードとしてアサインしたい人材は事業上も重要な役割を担っている人が多く、現状兼務で対応してもらっているメンバーが数人いる。そのため活動が限定的になってしまっています。中期的には兼務をなくし、専属の責務にしたいと考えています。
技術負債改善に向けた取り組み
こちらは、リソースがまだまだ限定的な為、やりたいことに対して部分的な貢献しか出来ていません。
事業要素からある程度独立した組織を立ち上げる際は、組織としてどの程度すぐに人を動かせるのかという点が難しさとしてあり、ある程度中期的に課題の改善を考えていく必要があります。
SRE
SREは下記のような理由から、横断組織に配置しています。
まだ各事業に専属で固定の人を貼り付けるほどの規模ではない。
横断的な基盤の作り直しを行っている最中なので、今は1つSRE組織として動いた方が効率が良い。
SREの役割そのものですが、例えばインフラ周りの作業をSREで巻き取ることが仕事ではなく、縦軸組織に積極的に知識を共有し、より縦軸組織で出来ることを増やすための取組を行うことがコンセプト。その為、仮に横断組織にSREを配置したとしても、インフラの構築タスクをSREが全て巻き取ってやるとかにはならない。
例の如くチームトポロジーを流用していますが(一部異なりますが)、SREは最初は密に連携し(Discover、Learningの部分)、そしてストリームアラインドチームが自分たちで出来ることを増やし、疎結合なコミュニケーションにする。
この繰り返しにより、より自走できるストリームアラインドチームを実現し、その一方でSREはよりコアな開発生産性の改善に注力するということを目指しています。
そのため、SREチームはプラットフォームチームとしての1面と、イネイブリングチームの顔を合わせもつようなチームというイメージになります。
PMO
PMOはProgram/Project Management Officeを指しています。
去年、WealthParkでは1人目のProgram Managerを採用し、Program Management、Project ManagementのイニシアチブをEMからProgram Managerに移しました。
イメージとしてはゆのんさんが下記のブログで書かれているプロジェクトマネジメント職の立ち上げの所が近い気がしています。
幸い、1人目のProgram Managerは非常にワークしており、今年に入り人も増え、PMOとして組織化することが出来ました。(Agile Coachもこの組織に所属しています。)
一方、今回の組織変更を行う際に、PMOを縦軸組織に置くか、横軸組織に置くかは最後まで悩んだポイントです。
結論としては下記の理由から、横軸の組織に配置しています。
個別にアサインを固定で配置するだけの規模ではない。
まだPMOが立ち上がってからの期間が短く、1チームで、PMOとしての共通理解や共通認識を醸成することに時間を費やしたい
(これはニュートラルですが)事業から離れた組織に属することで、より俯瞰的にPMOとしての責務を実行することができる
一方、PMOに関しては、チームトポロジーの概念とは今このタイミングではあまり沿っていないのですが、将来的にプロセスや組織が洗練されていけば、プラットフォームチームとして横軸組織に残っていくか、縦軸組織に配置するか、というようなことがあると考えます。
加えてPMOのメンバーはProject / Program Managementの観点から、非常に事業組織と密接に仕事をすることになります。今後、FrontEnd / BackEnd / Mobileと同様に一部の人材は縦軸組織に配置したり、あるいは完全に縦軸組織に配置する可能性は引き続きあります。
こちらは状況を見ながら、継続して今の会社に合った形を模索します。
QA
QAは下記の理由から、横軸組織に配置しています。
現状各縦軸組織のQA負荷が安定しているわけではなく、時期や状況によって必要なリソース・サポートが柔軟に変化します。現状においては共通組織にQAを配置し、状況に応じて柔軟なアサインを行う方が最適化ができると判断しました。
縦軸組織は厳密にプロダクトが全て独立しているわけではなく、ステークホルダーで分けられている。その為、片方の変更や機能追加がもう片方に影響を及ぼすことなども当然ありえる。QAが横断的なプロジェクト、仕様の変更の理解をすることで、仕様の矛盾や齟齬などを検知できる可能性は現時点では高いと判断しました。
一方でPMOと同様、QAも事業組織との関わりが非常に多いです。その為、将来的には一部の人材をストリームアラインドチームに配置したり、あるいは完全に縦軸組織に配置することも継続的に検討しています。
以上が横軸組織が持つ機能になります。
縦軸組織と横軸組織の循環
今回の組織変更によって、縦と横の組織に分かれたことになりますが、継続的に運営していく上で、縦軸組織と横軸組織は一定の循環が必要だと考えています。
縦軸組織と横軸組織では注力するポイントや求められるスキルに違いがあります。一方で、お互いの組織の経験を持ち込むことは、健全な組織の成長の上で非常に大切だと考えています。
例えば、横軸組織は技術的負債の改善を一部担当するわけですが、プロダクトや事業を理解している人の方が技術負債の改善によって解決したいペインをより理解でき、アウトカムを意識した提案が可能であるということがあると思います。または個人のキャリアやチャレンジの中で、テクニカルなチャレンジに注力したいというタイミングもあると考えています。
逆側で言えば、組織変更直後の今は問題ないですが、中長期では、横軸組織は現場を知らない、事業の状況が縦軸組織ほど鮮度高くわからない、ということは起こり得ると考えています。例えば、自分が行った技術改善の効果を肌で感じてもらうために縦軸の組織に行ったり、あるいはより明確にドメイン知識を獲得するために縦軸の組織に行くことが考えられます。また、技術力に強みがある人が縦軸組織に入ることでの相乗効果なども期待しています。
縦軸組織と横軸組織に分けたから、後はそれぞれでよしなにやってね、は成り立たないと考えています。良い循環のサイクルを作っていければと考えています。
横断的な交流
エンジニア全体での交流の機会も非常に大切だと考えています。
今年、開発組織ではポットラック(持ち寄り)会を開催し、WealthParkが誇る様々な国のメンバーが、自分の国の料理を持ち寄る会を行いました。
レンタルスペースを借りて行いましたが、かなりの盛り上がりだったので、またいつか開催したいと思っています。個人的にはフィリピン料理がめっちゃ美味しかったです。
こういう場で普段無いコミュニケーションパスでの会話やカジュアルな情報共有などが出来、新たな発見や、みんなの様子を伺い知ることが出来ます。組織変更だけでなく、リモートワークを行う上でもこのような機会があることは大事です。(一方で参加を強制することはなく、あくまで任意での参加となります。)
まとめ
ということで、今まで1つだった開発組織が、ステークホルダーという切り口で2つの縦軸組織、1つの横軸組織の計3つに分かれたことが2023年、もっとも大きな組織の変化になります。
まだまだ走り始めて長い期間が経っているわけではないので、これから直面する課題なども多くあると推察されますが、現段階においてはこの組織変更は非常にポジティブに働いています。
良い点
縦軸組織内でのコミュニケーションが促進され、より事業と開発組織が密になることができた
縦軸組織内で共通のKPIを持つことができた
結果、会社全体としてのアウトプットが去年から明確に向上している。
マネジメントの役割と負荷を分散させることができた
課題
組織コンセプトに対して、主に既存の技術的負債に基づく依存関係がある為、お互いへの影響を横軸組織を中心に、ケアする必要がある
技術負債に対する取り組みについては、チャプターリードに記載した課題を中心に、改善していく必要がある
また、今回記事を書いていて、チームトポロジーについて興味が湧いた方は、是非手に取って読んでみて頂ければと思います。
また、本を買うほどでは、、と思った方も、下記のスライドなどと合わせてこの記事を読んで頂くと理解が深まると思います。
ということで、2023年の開発組織変更についてまとめました。
改めてこの1年でも様々な変化が起こり、組織が進化していることを実感しています。
今回は技術スタックや開発プロセスについては記載していませんが、こちらも去年から一定変化した点があります。大きなところやコンセプトは変わっていないので、基本的には前回のブログをみて頂ければと思いますが、変更点については別途何かしらの形で共有できればとおもいます！
2022年版
この記事が気に入ったらサポートをしてみませんか？