EC/CRMの自社サービス「prismatix」の開発者から開発チームのプロジェクトマネージャーにクラスチェンジした話

7/1よりprismatixの開発者から開発チームのプロジェクトマネージャーにクラスチェンジしました。一エンジニアがどうしてマネジメントをすることになったのか、何をしていくのか、どうしていきたいのか、といった話を語ります。

#プリズマティクス

#プロジェクトマネジメント（PM）

髙野将

2021.07.08

この記事は公開されてから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チームが「自信を持って完了できる」と判断したタスクだけスプリントの計画に入れるようにします。これにより、もし先に全部完了したとしても、残った時間は各自のスキルアップのための学習や、サービス開発の改善作業に当てることが可能になります。

なお、こういったタスクのブレークダウンや回し方をチームにインストールする動きについては、弊社内製化支援サービスのチームに入ってもらい、サポートを受けつつ進めています。内製化支援サービスのドッグフーディングとしても機能するため、双方に価値があります。