1. はじめに

初めまして、コミック ROLLY サービスでサーバーサイドエンジニアをしている伊藤です。
今回私からは、「今までチームリードや PM の経験はなかった人間が、“プロジェクトを前に進める役”をやって気づいたこと」についてお伝えします。

コミック ROLLY の開発チームは、スクラム開発を導入しています。
PM という役職自体はないものの、メンバー各自が自律的に動くことをよしとしているチームです。

その中で今までチームリードや PM の経験がなかった私ですが、今回ご縁があり、現在のチームでリーディングの機会をいただきました。
このチームでリーディングのためにどういう動きをしたか、動いてみて気づいたことお話ししていきます。

2. コミック ROLLY のサービスと PM をしたプロジェクトについて

「コミック ROLLY」とは、株式会社ソニー・ミュージックエンタテインメントから配信している Android, iOS のスマートフォンアプリケーションです。

様々なコミックスを無料で読めたり、アプリを通して課金してコミックスを購入できるなどの機能があり、書店で売られているコミックスほか、先行配信するコミックスなどもそろっているサービスです。

今回のプロジェクトは、コミック ROLLY で一定期間課金せずに読むことができる「期間限定無料」というコミックス商品に対応するというものでした。

コミック ROLLY が商品をアプリに出すまでが以下の流れになっています。

① 社内別チームが担当する商品管理システム(取次システムと呼んでいます)からコミック ROLLY の商品取り込みサーバーに商品情報を連携する。
② 商品取り込みサーバーが連携を受け取ったら、コミック ROLLY の DB に情報を登録する。
③ コミック ROLLY のコンテンツ(アプリに出す特集情報など)管理から、商品と特集などの紐付けを行う。
④ アプリと通信する webAPI を通して DB から情報を取得、整形する。
⑤API から情報を受け取ったアプリが商品情報を表示する。

このプロジェクトは新しい商品をアプリに出すことが目的になるので、①~⑤ に関わる開発が必要になります。
あわせて、商品管理システムのチーム側もコミック ROLLY に対応するための開発が必要になるので、足並みをそろえての開発・リリースをする必要もありました。

3. なぜ自分が PM 役をやることになったのか

コミック ROLLY チームではスクラム開発という短期間で計画・作業・リリース・振り返りを繰り返す開発手法を採用しています。

プロジェクトを短期間で回す単位(スプリント)を 2 週間で回るように設定していて、タスクもその間に対応できる規模のものがほとんどになります。
ですが、まれに要望が複雑で複数システムの開発が必要なタスクもありました。

そのようなタスクが出てきた場合、要件整理・進捗の見通しなど「誰かが主導して動かす」必要がありました。

当時チーム内で一番所属経歴が長く、ドメイン知識や技術的な理解が深かったため、自然と自分がその役割を担うことになりました。

4. "PM 的な役割”でやったこと

プロジェクト推進役を実施するにあたり、主に以下の対応を重点的に行いました。

1.明確な方針の元の要件・仕様の整理とステークホルダー（PO や他チーム）とのコミュニケーション

中・大規模開発において重要なのは、要望を出すステークホルダー、ステークホルダーと開発メンバーの仲介であるプロダクトオーナーと一緒に要望の認識を合わせていくことです。

チームの設立時から「最低限の開発でユーザーへの提供スピードを優先する」という方針をもとに開発してきており、プロダクトオーナー、ステークホルダーとも方針を共有できていました。

この方針を元に要件・要望を整理し、最低限の機能開発で収めてリリースすることを確定できました。

2.仕様漏れ、変更に対しての柔軟に対応

今まで対応していたプロジェクトやチームでは仕様確定 → 開発 → テスト → リリースの流れが決まっていて、テスト時に仕様の考慮漏れがあった場合の修正やリリース時期の調整に時間がかかりました。

先に記載していますが、コミック ROLLY では 2 週間サイクルで開発を進めているので、中・長規模なプロジェクトも 2 週間で実施できる程度にタスクを細分化しています。そのなかで仕様の整理と開発を並行して行い、都度テストして確認していく方法を取りました。

この対応の結果テストで仕様の考慮漏れに気づけて次のスプリントで修正対応ができるので、大きな手戻りの発生がなく、リリースもリスケせずに対応できました。

3.定期的な振り返りで声を上げやすい環境を作る

スクラム開発ではレトロスペクティブというイベントがあり、プロジェクトに対しての振り返りを行います。私たちはプロジェクト以外にも開発プロセス内の振り返りも行っていました。

レトロスペクティブ中にプロセスの変えたいことをメンバー同士出し合い、アプローチ方法の検討し、次のスプリントにプロセス変更を取り入れる流れで改善案を迅速に取り入れる仕組みを導入しました。

この対応で改善の提案と実行のサイクルを早めたことで「自分の意見でチームが動いている」実感を得やすい形になりました。

その結果、プロジェクトの進行への取り組み、仕様や要件、開発プロセスに対してメンバーそれぞれが自主的に改善意見を言ってくれるようになるなどメンバーの自律性が格段に向上しました。

5. やってみての気づき・視野の変化

今回PM の役割を体験して、以下の気づいた点があります。

① チーム内で声を上げやすい環境にすることの大事さ。
チーム内のコミュニケーション方法を考慮したおかげで、チーム間で声を上げることのハードルが大幅に減りました。
それによってプロジェクト進行中に「リリース手順に考慮漏れがある」「仕様に矛盾点を発見した」などのさまざまな指摘をもらえる機会が多くありました。
おかげで慣れない進行でも進捗が早く、想定した時期に適切な機能をリリースできました。

この状況がないと、リリース直前で仕様の見落としや重大なバグが発見されリリースに大幅な遅れが出る可能性もありました。改めて意見を通しやすい環境があったことの大事さを実感しました。
この気づきとともに「頼れるところはもっと他メンバーにも頼ってよかった」という反省点もありました。

進行上エンジニアのメンバーには決定事項を共有することが多かったのですが、もっと早い過程の段階で意見を聞くことで、メンバーそれぞれの知識を活かせる場面がもっとあったのではと考えています。

② 物事を進めることの大変さ。
プロジェクトの推進役を経験することで、仕様に従うだけではなく、サービスとしてありたい方向、チームの状況に応じて柔軟に対応することがいかに大変かつ重要かも感じることができました。

③「リーダー」は役職じゃなく、チーム状況によって生まれる役割のひとつ。
PMの役割を体験したことで、要件定義や実装の流れを十分理解していれば誰でもチームリーダーとして対応できると考えを改めました。

今回はたまたま私がリーダーでしたが、プロジェクト周りの習熟度で他メンバーをアサインする可能性があったように誰でもリーダーになる機会はあります。

普段からこの感覚を意識すると、関わっているプロジェクトでも開発プロセスに対する積極的な提案や、仕様の曖昧な部分があったときにすぐに確認に入るなどを自主的に考えていけるようになりました。

6. 次にPMをやる時に気をつけること

先の気づきで「決定前の段階で他メンバーにも頼るところがあってよかった」という反省点があったのでそこに対してアプローチしていきたいです。
次にPMをやることがあったら、たとえば設計初期や技術選定の段階でメンバーに相談して考える段階でメンバーを巻き込んで色んな視点を取り入れる対応をすべきだと感じています。