VPoEになって、まず取り組んでいること
フジイ タカヒロ
27/Mar · 20 min read
最初に
早いもので、転職してから早5ヶ月が経ちました。4ヶ月を経て、自分の仕事に対する慣れや、環境や立場の変化など、色々なことがありました。
一つ大きな出来事として、4月から、現在働いているWealthParkで新たにVPoEに就任しました。今は、フロントエンドだけではなく、より包括的にEngineeringと向き合っています。今回の記事では、今自分がどういうことを考えていて、(まだこれからやっていくことも多いですが)、どのような取り組みをしているのか、ということについてまとめていきます。
· · ·
はじめに
WealthParkの組織体系について少し触れておきます。WealthParkでは、僕がVPoEとして就任するタイミングでは、VPoE, CTOはいない状態でした。約20名のメンバーで、エンジニア組織は非常にフラットな組織で仕事をしていました。(プロダクトマネージャ組織にはVPoP, デザイン組織にはVPoDがいます。)
以前の記事でも少し触れましたが、WealthParkの開発組織、手法はSpotifyが提唱しているSquadを強く意識したものとなっています。水平方向の組織(FrontEnd, BackEnd, QA, Mobileなど)をみるChapter Leadは存在していました。(僕は今年1月入社以降、FrontEndのChapter Leadとして仕事してきました。)
参考 : SpotifyのSquadを紹介する文章に書かかれている、Chapter Leadの説明はこちらです。
The chapter lead is line manager for his chapter members, with all the traditional responsibilities such as developing people, setting salaries, etc. However, the chapter lead is also part of a squad and is involved in the day-to-day work, which helps him stay in touch with real
今回、ChapterLead上のラインとして、僕がVPoEとして入ることになりました。正確には、ChapterLeadはChapterの1員という要素も強いので、既存のエンジニア組織の上のラインとして入ることになった、というのが正しいのかもしれません。
- Squadを意識した組織、開発手法を採用している
- VPoE交代ではなく、新たなポジションとしてVPoEとして入る
- CTOは現状いない
本記事では僕がVPoEとして取り組んでいること、考えていることを紹介していきますが、弊社の状況の補足をいくつか書いておきます。
これらの点を踏まえた上で、読んで頂ければと思います。
· · ·
1.自分の仕事の可視化
まず最初にやったことです。昨今の情勢を踏まえて、WealthParkではほぼ完全にリモートで業務にあたっています。その為、どのような責任や役割で、実際に僕が何をやっている状態か分からない状態で業務を初めてしまうと、他のメンバーから何をしているかかなり見えづらい状態になってしまいます。
VPoEになった途端、周りの人から僕の仕事が見えなくなり、「あいつは何やっているのか分からない」と感じてしまう状態をまずは避けたかったというのがあります。一方で、自分のVPoEとしての役割や優先度を状況に応じて徐々に定めていく必要があり、全てを最初から明確にすることは難しいとも考えていました。とはいえ、クリアになるまで発信しないという状況も避ける必要があり、ある程度不十分な状態でも情報を公開しようと考えました。
VPoE就任にあたり、メンバーとの1on1を通じてVPoEに対しての期待値のすり合わせを行いました。その上で、まずは自分がやっていることを可能なかぎり公開することにしました。今自分が関わっているプロジェクト、プロジェクトやタスクに対する関わり方、今注力していることは何か、どんなmtgに出て、何を決めようとしているか。などといったことです。
興味がある内容は適宜メンバーからコメントもらったり、DMとかで直接聞いて下さい！って感じにしています。まずは新しい組織になりレイヤーが増えることで情報が伝わりにくくなる、隠れるわけではなく、引き続きオープンに情報を共有する意思表示をすることが一番の目的です。
一方で、改善点は多々あります。メンバーが都度これを見にいくのも手間なので、Daily Reportで業務の共有も別途しています。より簡単に自分が何をやっているか周りから見える状態は常に意識していきたいです。より自然に、何をやっているか共有できる、周りに伝わる方法を考えています。さらに言えば、共有すること自体が最終的なゴールではなく、メンバーが興味がありそうなプロジェクトや、MTGを見つけて、どんどん参加していく、みたいなことを出来るようにしていきたいです。
· · ·
2.周りの仕事の可視化
こちらは他部署、社外に向けたものです。僕がWealthParkに来た時、エンジニアが皆凄くオーナーシップを持って、ハードワークしていることが凄く印象的でした。一方でその成果を周りに伝え切れていない点があり、改善できる部分があると考えました。
· · ·
2-1.社内
月並みではありますが、まずは他の部署に対してしっかりと成果や取り組みを紹介することで、より信頼を得ていく必要があります。
- 月次のmtgなどで、成果や進捗を報告
- 技術的負債の返却の計画や進捗、成果の共有
- 事業の方がどの粒度で、どういった情報を知りたいのかのすり合わせ
などから始めていますが、様々なメトリクスを取り始めることで、中期的には、数字を使う形で、成果を示していけたらいいなと思っています。また、VPoPを中心にトラブル対応のフローを明確化できたことで、トラブル対応が周りからも目に見えてわかるようになったことも非常に良かったです。
· · ·
2-2.社外
社外に関しては今まで全くカンファレンスなどでの発表がなく、ググってもWealthParkの開発組織や技術スタックに触れることが出来ない状況は良くないと捉えていて、今後は様々な形で、僕らの情報をより社外に向けて発表出来たら良いなと考えています。
WealthParkのエンジニア組織は非常に多国籍なチーム(日本人は2人しかいない)ので、英語での情報公開も推進していければと考えています。
· · ·
3.プロセスの改善(MaintenanceとProjectのBoard分離)
開発プロセスの改善にも一部着手しています。WealthParkにも様々なプロダクトがあり、中にはレガシーなプロダクトも存在しています。この中の一つにいわゆる巨大なモノリスなプロダクトが存在しています。
このプロダクトに関連した多くのバグ修正やプロジェクトが同時進行する中で、
- タスクの優先度管理が難しくなってきた
- タスクの優先順位の判断を都度エンジニアがしなくてはならない
- Sprintの期限が曖昧
- 優先度の高いチケットの差込で、プロジェクトの遅延が度々発生(しかもそれの検知が遅い)
しているなどの課題があります。
改善策の1歩目として、プロジェクト以外のタスクとプロジェクトのタスクを明確に分けました。
- プロジェクト - Scrum
- メンテナンス - Kanban
にしています。
プロジェクトのタスクはきちんとSprintを切ります。一方、メンテナンスタスクに関してはKanbanを利用しています。メンテナンスタスクは、1ボードで、統一されてた優先順位にチケットが並べられ、上から順番に消化できる状態にまずします。
現状比較的優先度の高いメンテナンスタスクが高い確率でスプリント中に差し込まれます。それによって、常にScrumにスプリント中の変更が発生している状態が続いていました。それを完全に改善するわけではないですが、まずはボードを分離する所から初めています。
一方、開発リソースは充分ではなくプロジェクトとメンテナンスのタスクを兼務しているメンバーが大勢います。なので、ボードとしては分かれた一方で、引き続きリソースをプロジェクトとメンテナンスの両方に使う状況は続きます。
こちらに対してまずは、ボードを分け、今実際どれくらいの割合を各人がプロジェクトに割いていて、その位の時間をメンテナンスタスクに割いているのかを可視化します。その上で、それが適切な状況なのか、という判断をしていきます。(別途、タスクのアサインまでのフロー、PriorityのTriageの基準などについても議論しています。)
· · ·
4.Spotify Model(Squad, Chapter)を参考にした組織、開発手法
4-1.Spotify Modelの導入 / (Squad, Chapter)
WealthParkではいわゆるSpotify Modelをアレンジした開発手法・組織体系を導入しています。細かくはより色々な要素がありますが、基本的に、縦割りはSquad(Product, Project毎), 横割りはChapter(FrontEnd, Backend等)と定義してマトリックス型の組織体系で構成されています。(今回の記事では、TribesやGuildsには触れません)
基本的には、Squad毎に日々のプロジェクトを進行しています。Squad毎に責任はかなり委譲されていて、各Squadで開発を進めます。各SquadにはProduct Owner, Product Manager, FrontEnd, BackEnd, Mobile, QA, Scrum Masterがいて、アーキテクチャ、開発のスコープ、スケジュールの判断などを各Squad毎に判断して進めます。それによって、リリース期間を現状の組織において短くできている、というのは確実にあると思います。
一方で、完全な縦型組織ではなく、横串の組織として、Chapterが存在するので、専門分野に関連した議論や連携はChapter間で行うことになります。(Guildによって進める場合もあります)
· · ·
4-2.目的(自己組織化)
Spotifyではその開発、組織手法がもたらす最大のメリットとして、'Autonomy(自治)'を上げています。
VPoPのSethが下記の記事で言ってくれている内容が近いと思っているのですが
· · ·
チームの立て直しにあたり、あるべきチーム像はどの様に描かれていましたか？
良い意味で勝手に動いてくれるチームです。僕が考えるリーダーの仕事は、目標の設定とチームのサポートだけ。あとはそれぞれが自分で動いてくれれば良いと思っています。目の前にある川を渡りたい場合、橋を作れと指示するリーダーシップと、川を渡る方法を> 考えてと指示するリーダーシップがあるとしたら、僕は後者。若い人は自分よりも優秀になると信じているし、彼らのアイディアは自分1人のアイディアよりも優れていると思ってチームビルディングをしています。
· · ·
Squad, Chapterという組織構造で、より一人一人のOwnership、責任と自由を強化していくことが、この開発手法を採用している一つの大きな目的と捉えています。
僕はよくチームの段階を表す指標の一つとして、下記の図を使っています。どのようにしてチームの自己組織化を推進できるのか、ということを考えています。
· · ·
マネージャ主導型チームでは，チームメンバには単にタスク実行の権限のみが与えられ，作業プロセスの管理やコンテキスト設計，方向付けはマネージャが行います。私たちが見る限り，機能的サイロを形成する専門家グループや，従来的なプロジェクト管理“チーム”の多くが，この形式の実例になります。
自己管理型チームではメンバに対して，タスクの実行だけではなく，進捗の管理についても責任を与えます。ITでは，チームのタスク，あるいはチームを越えたバリューストリームを重視するかんばんチームに，このアプローチの適用が多く見られます。
自己設計型チームはメンバに対して，チームのデザイン，および／またはチームが運営される組織コンテキスト面での変更を行う権限が与えられます。ほとんどのマネージメントチームに加えて，特にリーン／アジャイルで高いレベルに達したスクラムチームの一部がこのポジションにあります。
自己統治型チームでは，企業の取締役会や労働組合，新興企業で見られるように，４つのコア職務すべてについて全メンバが責任を持ちます。
· · ·
これらのチームの状態と、Squadでの開発を紐づけて考えてみると、Squad毎に責任が移譲されているということは、その中に属しているメンバーの1人1人が大きな責任をもつということです。例外もありますが、1Squadに属する同じChapterの人間は多くて3人、多くは1人か2人です。(1 Business Owner, 1 FrontEnd, 2 Backend, 1 Mobile, 1 Product Owner, 1 QAみたいな感じです。(本当はもう少し増やしたい))例えば、その1人1人が自分の進捗の管理に責任を持ちます。なので、あるSquadにおいて、あるChaper(FrontEnd, BackEnd)の責任はChapter Leadではなく、Chapterのメンバーにあります。(必要に応じてChapterLeadは支援を惜しみませんが)
その為、Squadは組織をSelf-managing teamの状態まで引きあげやすいという特徴があります。加えて、次の段階Self-designing teamまでの道も凄くオープンです。新規のプロジェクトの多くは、Squad毎にDesign Sprintを行うことで、縦軸のメンバーを早い段階からProjectに関与させることが可能です。
Squadを用いた自己組織の究極の目的、目標としては、1Squadがほぼ独立した会社の用に、プロダクトやビジネスのKPIの達成のために邁進できることではないでしょうか。
一方で、Squadで開発を進める上での難しさ、デメリットもあります。その点において、Chapter Leadの役割は非常に重要だと考えています。次のセクションでは、自分がエンジニアのChapter Leadに対して求めている期待値について紹介します。
· · ·
5.Chapter LeadというRollの洗練
改めてですが、弊社の開発組織は、縦割りはSquad(Product, Project毎), 横割りはChapter(FrontEnd, Backend等)と定義してマトリックス型の組織体系で構成されています。
Chapter Leadは、横割りのChapterを支援するLeadポジションです。
· · ·
5-1.Leadershipについて
Chapter LeadのMissionについては、WealthParkでは次のように定義しています。
“Maximize chapter productivity, output by using both leadership and hands-on”
“Chapterの生産性、成果をリーダーシップとハンズオン(自ら手を動かすことによって)最大化すること“
リーダーシップとハンズオンの両者が明確に記載されている点が特徴です。
まず、リーダーシップの点についてですが、
The chapter lead is line manager for his chapter members, with all the traditional responsibilities such as developing people, setting salaries, etc
Chapter leadはいわゆるEngineering Managerの側面を持ち合わせていて、Chapter間での技術スタック、知識、ツールの共有などをファシリテートします。また、メンバーの開発のサポートや、目標設定なども行います。
WealthParkではLeadershipについて、下記の期待値を定めています。
Expectation A : It’s the chapter lead's responsibility to help with chapter members' personal development, to work on their professional expertise and to offer guidance and advice for their challenges and development goals.
Expectation A : メンバーの開発、成長の支援。専門領域に対して、課題の提供、成長、目標設定の為の指導や助言をすること。
· · ·
5-2.Hands-onについて
Chapter Leadの特徴である、hands-onの部分です。
Spotifyの資料は次のように書かれています。
However, the chapter lead is also part of a squad and is involved in the day-to-day work, which helps him stay in touch with reality.
このTouch with realityの部分が非常に大切だと考えています。一見、このChapter Leadはいわゆるプレイングマネージャのように見えるのですが、必ずしもそうではないと考えています。
このrealityという言葉は、色々な読み取り方が出来ると思います。1エンジニアとしての技術力、エッジなTechnologyに対する理解、プロダクトに対する知識、プロダクトの課題など。
僕は、'プロダクトに対するリアルな課題感の把握' を 'Reality' として捉えています。
例えば、組織として、リファクタリング、リアーキテクトを進めたいが、思ったより進んでない。
というIssueがあったとき、どうやって課題を特定していくことになるのでしょうか。どの粒度で課題を見るのが良いでしょうか。それは、プロダクトがMonolithだからなのか、レガシーすぎるからなのか、コードが複雑(らしい)からなのか、コードのドメインが綺麗にわかれていないからなのか、ある複雑な関数のテストコードがなく、リファクタリング後のテストコードがかけないからなのか、メンテナンスタスクに追われて、リファクタリングに時間が避けないからなのか。どれもが正しくある可能性がある一方で、どこに一番課題感を現場の人が感じているのか、それが'実際どれくらい大変なのか'という肌感は、現場にいる人とそうでない人には違いがあることが多いと考えています。
かけられる時間は他のメンバーよりも少ないですが、それでも1Chapterのメンバーとして手を動かすことで、Realな課題感を持つことができると考えています。
とはいえ、Leadership, Management業をしつつ、頑張ることで、Chapterのメンバーと同等以上のアウトプットを出してほしいというわけではありません。LeadershipとHands-onにかける比重については、柔軟に考えています。パターンを考えると、
- 一定の割合を維持する
- どちらかに多めの比重をかける(それはもしかしたら、EMっぽいChapter LeadとTechleadっぽいChapter Leadなのかもしれない)
- 状況に応じてMenagementに専念している時もあれば、開発に専念しているときもある
などがあると思います。どれも一番良いアプローチになりうると考えています。大切なのは、
“Maximize chapter productivity, output by using both leadership and hands-on”
“Chapterの生産性、成果をリーダーシップとハンズオン(自ら手を動かすことによって)最大化すること“
に貢献できているかどうかです。但し、Chapter Leadが1 ChapterとしてSquadに属することを大切に考えているということは伝えています。
WealthParkにおけるChapter Leadに対する期待値の1つ(Hands-on)
Expectation B : A chapter lead is not only responsible for his or her chapter, but also works in a squad like everybody else.(the chapter lead is also part of a squad and is involved in the day-to-day work, which helps him stay in touch with reality.)
Expectation B : チャプターリードはチャプターに対する責任を負うだけでなく、他のメンバーと同様にSquadのメンバーの1人として、働くことを期待する。(それによって、現実的な課題や実情の理解を高いレベルで行う)
· · ·
5-3.未来と今
これはChapter Leadにだけ、というメッセージではないのですが、上記を踏まえて、未来と今の両方を見て欲しい、ということを最後に伝えています。
Expectation C : By demonstrating professional expertise and touching with reality, Chapter lead SHOULD consider future architecture, vision and NEED TO understand current technical debts, complexity.
Expectation C : 専門知識を発揮すること、実情を正しく理解することで、チャプターリードは、将来のアーキテクチャとビジョンの検討、現在の技術的負債、複雑さを理解する必要がある。
· · ·
5-4.Chapter LeadとSpotify Model
Chapter Leadという切り口で話すと新鮮な面である一方で、現状はいわゆるメンバー、チームリーダーとマネージャーの責任範囲、TechleadとEngineering Managerの責任範囲とそこまで大差ないといえば無いのかもしれません。コンセプト的には上じゃなくて横。Chapterの１員であるということが違いにはなりますが、大なり小なりそういった働き方をされているチームリーダーの方はいらっしゃると思うので。但し、Squadの縦割りが強力な分、EMとしての力が求められる、という側面はあります。それぞれが独立して動ける環境を維持しつつ、横串をまとめあげ、大局的な情報を理解しつづけられるか、というのは腕の見せ所です。
SquadやChapter Leadに関する資料は多くはありませんが(特に日本語)、Referenceをいくつか載せておきます。よかったら見てみてください。
How to Build Your Own Spotify Modelにも書かれているように、僕らがやりたいことはSpotifyのコピーではなく、考え方をベースにした自分達のやり方です。また、この考え方が発表されたのも2012年であり、現在の彼らの組織構造もまた、元々あったものとは変わってきているはずです。僕自身も、まだまだこのプロセスを理解しようとしている、見極めている最中です。
· · ·
6.技術的負債と新規開発の向き合い方
正直、結構負債は多いほうだな、と会社に入ってから実感しています。加えて、Squadでの開発は、Agilityがでる一方、個人や組織として未成熟な状態では、それなりに負債が出やすいという感覚があります。常に負債の返却と新規開発のバランスを適切に保つことは、自分の大切な責任です。
今は、Squadでの開発体制を維持しつつ、技術的負債を返却していこうと考えています。プロダクトの全体像と、今抱えているメジャーな負債については、VPoEになるあたりでまとめて共有しました。(Miroはとても図が描きやすくて好きです。)
技術的負債の返却に向けて、現在打っている手としては、
- エンジニアそれぞれが今ある技術的な負債を大局的に理解すること
- なぜ負債を返さないといけないのか、それぞれの負債が阻害していることを理解する
- Core Squadを作り、プラットフォーム的なプロダクト、リファクタリングに専念できるSquadを作る
- Chapter Leadを中心に、将来あるべきアーキテクチャと現状の課題の理解を深めalignしていく
のようなことをしています。正直、まだまだ負債を返却するスピードは十分でなく、よりスピード感をもって技術的負債に取り組んでいく必要性を感じています。こちらに関しては、負債の返却のスピードをみながら、打つ手を変えたりしないといけない所も出てくると考えています。技術的負債に対するアプローチについては別途掘り下げた記事を書こうと思います。
· · ·
7.責務
責務は多くあるものの、シンプルにまとめるとするならば、'Execution'と'Roadmap'の2つだと捉えています。Executionとは実行責任で、やろうとしていること、やりたいことがきちんと実行され、デリバリーされることです。(加えて、エンジニアの人がやりたいと思っていることをExecuteできるも含めた伝え方をしています。ただ、これは本質的にはCareerや、モチベートする部分ではあります。)
VPoEに求められるExecutionの責務に関してはFincの清水さんがまとめられている下記のHandbookに非常に良くまとめられています。
ただ、1点弊社のポイントとしては、弊社はCTOがいる体制ではないので、戦略策定の部分にも責務を負っています。現在はややExecutionに自分の比重が向いていると捉えています。
一方で、
ベンチャーの規模が小さいうちはこの役割を一人で兼任することも多いのですが、数が増えるなどして忙しくなると、多くの場合CTOの役割を放棄してしまう後者の状況に陥るケースはよく見られます。上に引用したエントリーでは社員数が20人くらいになったら、両者を専任にすべきだろうといっています。これはケースバイケースですが、日々のオペレーションを離れて戦略的に考えることができる環境を得ることができなくなったら、対応策を早期に取るべきだと心得ておくとよいでしょう。
とある通り、今の組織体系において、常に自分がどれだけ先のことを考えることに時間を使うことができているか、意識しながら仕事する必要があります。このバランス感は自分がChapter Leadに求める部分とも凄く似ていますが、今の自分の立ち位置でも非常に大切です。
· · ·
8.まとめ
実行と戦略と向きあっていたら、あっという間に2ヶ月が経ってしまいました。定期的に自分のアクションを振り返る / まとめる為にも、発信を続けていけたらなと思います。近々、会社のエンジニアブログも立ち上げようと考えているので、より実際の業務に踏み込んだ話は、今後はそちらを通じて発信できればと考えています。もしも質問などありましたら、気軽にTwitterでメンションやDMなどしていただければと思います！
· · ·