この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
事業開発部改め prismatix事業部 の高野です。この度、7/1より開発者から開発チーム(以下Devチーム)のプロジェクトマネージャーにクラスチェンジしましたので、それに伴うよしなしごとをつらつらと書いてみようと思います。
prismatixの今の開発体制
prismatix事業部では、「EC/CRMを支えるAPIプラットフォーム prismatix」を開発しています。
prismatixの特徴の一つは、「認証/認可」、「商品管理」、「会員管理」といったEC/CRMに必要な機能群をそれぞれ「マイクロサービス」として提供していることです。そのため、各マイクロサービスには、掛け持ちがありつつも数人の専任チームを組んで、日々の開発にあたっています。
発生した問題
prismatixも開発を始めて5年目を迎えます。最初のころは規模が小さいこともあり、それぞれのマイクロサービス専任チーム間で人の移動もあり、スキル・知識の流動性も高い状態でした。
しかし、最近ではマイクロサービスの数も増え、それに伴いDevチーム全体の規模も大きくなってきました。また、案件の増加に伴う新規機能追加の要望も増えました。それに伴い、各マイクロサービスのメンバーにはより高い専門性が求められることになり、チーム間での人の移動が減りました。結果として、「スキル・知識のタコツボ化」、「担当サービス以外への興味の低下」の徴候が見られるようになってきました。
また、当初は「マイクロサービス」という「組織論」にこだわり、各チームの独立性を高めたつもりでした。しかし、EC/CRMという複雑な領域を扱う中で、各マイクロサービスを完全に独立して開発することが困難になり、それぞれのマイクロサービスの間で、ゆるい依存関係が生まれてしまいました。しかし、組織はあくまで「マイクロサービス」チームで進めていたため、 prismatix というサービス全体としての統一性や一体感というものが徐々に蝕まれていきました。
他にも、機能要望の増加で多忙になったことにより、改善活動のための時間確保が行いにくくもなっていました。
問題に立ち向かう
上記のような問題を解決するため、「個々のマイクロサービスチーム」単位でのマネジメントから「Devチーム全体を横断したマネジメント」にかじを切ることになりました。そして、「Devチームのプロジェクトマネージャー」という役割を、私が担うことになりました。
私に白羽の矢が立ったのにはいくつか理由があります。
本当に怖い軽減税率対応 by @masaru_b_cl #devio2020 | DevelopersIO で述べたように、「注文」というECの中核を担うサービスのリーダーであったこと、そして結果として関連する周辺サービスについてもある程度把握していることなどがあります。
しかし、それ以上に私には元々のモチベーションとして 人を含めた系(システム)を作りたい というものがあり、それにトライする機会を与えてもらったということが大きいです。
マネジメントの姿勢
マネジメントと言っても、「オラオラついてこいや！」という感じでグイグイ引っ張るタイプ、みんなが動きやすいようそっと支えるタイプなど、人それぞれで色々なやり方があると思います。
クラスチェンジするにあたり、私なりにどんな姿勢でマネジメントに向かっていきたいか、改めて考えてみました。過去を振り返ってみると、「みんなを引っ張っていく」という振る舞いは苦手でしたが、みんなが動きやすいように縁の下の力持ち的な動きをするのは好きだったことを思い出しました。
そこで、私は 指揮者(Conductor) として振るまおうと決意しました。
どう違うのかについては、こんなイメージです。
- 実際に音を出す(≒成果を出す)のはDevチームのメンバー
- チームメンバの音(≒声、意見)をよく聴き、調和させるのが私の役割
- 聴衆(≒Devチームの周辺ステークホルダーやprismatixの顧客)にも目を向け、いい演奏(≒製品)を一緒に作っていきたい
何をしたいのか
先述の通り、私は「人を含めた系(システム)を作りたい」とかねがね思っています。これをベースに、Devチームに当てはめて考えた結果、
Devチームを中心として系が回るようにする
ことを実現したいと思っています。
もう少しわかり易い言葉でいうと、「prismatixというサービスの 開発 を通じて、顧客およびチームに 価値を届け続けている 状態を作る」のが目的になります。
障害となっているものはなにか
上記の理想に対して現状を見たとき、何が障害となっているのかを私なりに考えて見ました。そして
「Devチームと周辺ステークホルダーとの 期待値 が一致していないのではないか？」
という仮説を立てました。
「期待値が一致していない」とは、例えば次のようなものを指しています。
- prismatixを利用した開発ドキュメントが、「prismatixを利用したEC/CRMサービスの開発者」から見るとわかりにくい
- 開発スケジュールがふわふわしていて、機能がいつごろリリースされるかわかりにくい
- 「リリースするために満たすべき条件」がチーム、メンバーによってブレがある
この結果、Devチーム内および周辺ステークホルダーとのやり取りで認識のズレがあり、全体的にストレスが高い状態になりつつあります。
どうしていくのか
この期待値の不一致を解消することで、 Devチームもハッピー、みんなもハッピー な状態に向けて、色々動いていこうと思っています。
そのために、次のようなことをやっていきます。
- 現状認識
- 「価値」の共有認識作成
- 小さくこまめにリリースする体制づくり
- 情報共有の整備
現状認識
まずは私が現状を把握しなければ、今立っている位置もわかりません。そのため、まずはDevチームや周辺ステークホルダーと 1on1 を行い、ヒアリングを進めています。具体的には、次のような人たちに話を聞いています。
- マイクロサービス専任チームリーダー
- 運用チームリーダー
- プロダクトオーナー
- 導入支援チームマネージャー
- エンジニアリングマネージャー
- prismatix事業部長
- Prismatix CEO
「価値」の共有認識作成
次に、prismatixというサービスに対して行うタスクが、顧客や自分たちにどのような「価値」を届けられるのか、Devチームだけでなく周辺ステークホルダー含めた「prismatixチーム」で統一見解を作成します。
また、その「価値」を届けるためには何ができていなければならないかのリスト、いわゆる「DONEの定義」を作成します。
これができれば、Devチームは「DONEの定義」に必要な作業を、順次こなせば良い状態を作れると考えています。
小さくこまめにリリース
スケジュールがふわふわしている一番の原因は、大きな問題をそのまま扱おうとしていることでした。前述の「DONEの定義」にも関係しますが、何をやらなければいけなくてそれには何かが明確でないため、取り組んでは新たな問題が見つかりということを繰り返し、段々とチームも疲弊していました。
この問題を解消するため、大きな問題を小さく分けて 各個撃破 するよう、開発スタイルを改善していきます。
これまでもDevチームは1週間のスプリントである程度タスクを管理していました。しかし、上述のような状況が多かれ少なかれあったため、今一度いわゆる「アジャイル」な開発を、チーム全体で考える必要があります。
このために、これまでは各マイクロサービスでバラバラだったタスクリストを一つにまとめ、一つにまとめた「プロダクトバックログ(PBL)」を作成し、ここを起点に各マイクロサービスチームの開発を駆動するようなやり方にしていくつもりです。
具体的には、大きなタスクを1つのスプリントに収まるサイズにまで小分けにし、Devチームが「自信を持って完了できる」と判断したタスクだけスプリントの計画に入れるようにします。これにより、もし先に全部完了したとしても、残った時間は各自のスキルアップのための学習や、サービス開発の改善作業に当てることが可能になります。
なお、こういったタスクのブレークダウンや回し方をチームにインストールする動きについては、弊社 内製化支援サービス のチームに入ってもらい、サポートを受けつつ進めています。内製化支援サービスのドッグフーディングとしても機能するため、双方に価値があります。
情報共有の整備
前述のような改善をすすめるためには、必要な情報がDevチームと周辺ステークホルダーの間で 滑らかに流れる ようにしなければなりません。
そのために、今一度「共有すべき情報の再定義」が必要です。例えば、顧客への導入支援チームには、追加要望の合った機能の提供時期を、運用チーム(prismatix事業部では「基盤運用チーム」と呼ぶ)にはマイクロサービスの変更がインフラに及ぼす影響を、といった感じです。
そして、それらの情報が漏れなく確実に伝わるような仕組みづくりも必要です。もちろんこれまでもある程度情報共有しながら進めてはいましたが、より洗練することでprismatixのチーム全体としてのストレスを下げたいと考えています。
何を学んでいるか
これまでに述べてきたようなことを実現するには、私自身も変えていかなければなりません。
まずは、次のような書籍で「マネジメント」に関する知識をインプットしています。
アジャイルサムライ
XP(エクストリーム・プログラミング)、スクラムといったアジャイル開発フレームワークの個々のやり方ではなく、「アジャイル」そのものの基本を学べる書籍です。
今のDevチームはマイクロサービスごとのサブチームに分かれていて、単一のプロダクト開発に向けたアジャイル開発フレームワークをそのまま使えない状態です。だからこそ、基本となるところ、押さえるべきところを取り扱ったこういった書籍はありがたいです。
パフォーマンス・マネジメント
「チーム、組織」のパフォーマンスを高めるために、メンバーにどう働きかければよいか、といった「行動分析学」の基礎を扱った書籍です。
マネジメントにあたって、自分の行動を変えることは大前提ですが、それでも自分以外の行動を変えるように動かなければならないこともあります。そんなときに参考にするため、手元においておきたい本です。
とはいえ、中に書いてあることは非常に「当たり前」のことだったりもします。その当たり前をいかにやり続けるか、といったことを引き続き考えていきたいと思います。
クリティカルチェーン
制約の理論(TOC:Theory of Constraints)に基づき、プロジェクトをすすめる上での「制約」（＝ボトルネック）と向き合い、高いパフォーマンス(スループット)をいかに出していくか、という内容を扱った本です。
過去に2回ほど読んでいるのですが、改めて読み返して今後のマネジメントに活かせるものがないか探してみています。
最後に
とはいえ、一エンジニアからマネジメントというロールに移るため、スキルや経験が圧倒に不足していることは確かです。
それでも、クラスメソッドのカルチャーであるCLP(Classmethod Leadership Principle)の「やってみる」、「フィードバック」、「楽しむ」のあたりを実現する場だと思い、メンバーと試行錯誤をしていくつもりです。
また、途中の成果などは随時このブログでアウトプットしていこうと思います。
メンバー募集！
prismatix事業部ではprismatixというサービスを成長させるためのメンバーを募集しています。
現在募集中のポジションは次のページから確認できます。
もし興味があるポジションがあれば、ぜひご応募お待ちしております！
4
