この記事は、SEN アドベントカレンダー 2024の23日目のエントリーになります。
はじめに
はじめまして。ものづくり部のビジネス開発グループでプロダクトマネージャーをしている別所(@gb_pdm)です。 複数存在する弊社の事業の中で、はいチーズフォトのカメラマン撮影プランを担当しています。
カメラマン撮影プランでは撮影依頼を受けてから実際にカメラマンが撮影するまでの間に複雑な業務プロセスがあるのですが、その中で保育園の先生からより良い写真を取るためのヒアリングを行う業務があり、入社以来その業務フローの改善に取組んでいました。
そして今月ついにそのフェーズ1を本番リリースしました！！ 社内からもポジティブな反応をいただけており一安心しているところです。
本記事では入社してから今日に至るまで、自分が所属するチームにおいてユーザーに素早く価値を届けるためにやってきた取り組みを紹介したいと思います。
入社当時の状況と課題
自分が所属するビジネス開発グループでは当時、エンジニアリングマネージャー1名で15人前後のメンバーをマネジメントしている状況でプロダクトマネージャーも不在だったため、プロダクトマネジメント全体のプロセスが十分に機能しておらず以下のような課題がありました。
- 1回のリリース内容が大きくリリースされるまでのリードタイムが長い
- 開発プロセスにおいてユーザーとの接点を十分にとれておらず本番リリース後に追加要件や仕様変更要望が出てくる
- テスト工程がリリース直前に行われており、納期が迫っている場合にスキップ・簡略化されリリース後に不具合が発覚する
こういった状況の中、2024.4月に自分とエンジニアリングマネージャーのdaitasuさんが加わったタイミングで現在の3チーム体制となり、その中の1チームをプロダクトマネージャーとして見ていくことになりました。
実際に行った3つの「減らす」
先程の課題解決に向けて大きく３つの「減らす」取組みを行いました。
- ①作るものを「減らす」
- ②手戻りを「減らす」
- ③不具合を「減らす」
1つずつ見ていきたいと思います。
①作るものを「減らす」
開発スコープを絞る
入社したタイミングで解決したい課題の大枠は決まっていたものの、開発スコープが広く大規模開発になることが予想されたため、まずはフェーズ1としてどこを目指すかを整理しました。
[STEP1]誰のために作るか
初期段階で改善要望を収集した際には「先生の課題」「カメラマンの課題」「社内の課題」が混じった状態になっていたため、社内業務を深く理解しているメンバーへのヒアリングを実施し、フェーズ1では「社内の特定部署」を最優先としステークホルダーと目線合わせをしました。
このタイミングでフェーズ1の成果指標も「社内の特定部署」目線のものにすることに決めました。
[STEP2]どんな状態にしたいか
「誰のため」が決まった後はそのユーザーを「どうしたいか？」の優先度付けを行います。 ユーザーストーリー形式で価値提供したいもの付箋で並べ優先順位を決めフェーズ1として含める開発スコープを決めていきました。
[STEP3]どこまでどう作るか
最後に提供すべき価値を実現するためにどう機能を作っていくかを検討しました。ここでも作るべきものをミニマムに出来ないか検討しました。
具体的な例を上げると当初は「カメラマンにメールで伝えている撮影内容をカメラマン向けのwebページに表示させる機能」を考えていましたが、様々なユースケースに対応するための開発コストや既存業務の変更影響度が大きいという懸念があったため、フェーズ1の段階では「社内向け管理画面上の撮影内容データをまとめてコピーしメールに貼り付けられる機能」にしました。 そうすることで運用者側でメール内容を自由にカスタムできる柔軟性を持たせつつ開発コストも抑えることができました。
上記STEP1~3を通して当初よりかなり開発スコープを絞って要件を整理することができました。
②手戻りを「減らす」
次は手戻りを減らす取り組みです。手戻りを減らすとはテストやリリース後の段階で考慮不足のユースケースが発覚したり、認識ズレによって余計な開発コストが発生するのを防ぐ取り組みです。
プロトタイプでユーザビリティテストを実施する
本番リリース後に追加要件、仕様変更が発生するのを防ぐためにFigmaでのプロトタイプ段階でデザイナーと一緒に社内の利用者がいる現場に行き画面操作をしてもらいながらフィードバックをもらいました。
実際に現場では電話をしながら管理画面を操作していたり、1つの画面内でウィンドウを分割して操作していたりしていることがわかり、当初のUIから大きくデザインを変更する結果となりました。
仕様や運用フローに考慮漏れがないか確認する
ユーザビリティテストとは別に運用者との定例mtgを週2回以上実施し運用フローのユースケースを細かく洗い出していきました。 最終的に60件以上の運用者からの質問と40ケース以上のユースケースを1つずつ確認しシステム破綻している部分がないか確認しました。
またこの定例mtgはシステムの要件整理だけでなく、運用者自身がリリース後にこの機能をどう使っていくべきなのかを十分に理解してもらう効果もありました。 おかげ様でリリース後に使い方がわからないといった問題も起きずスムーズに利用開始できたと思います。
③不具合を「減らす」
最後は不具合を減らす取り組みです。 入社のタイミングでチームが分かれたこともあり、このタイミングで2週間1スプリントのスクラムを導入し以下のようなデリバリープロセスに変更しました。
具体的なスクラム運用の話はまたどこかで紹介できればと思いますが、 実現したいユーザーストーリーの詳細を週1回のリファインメントで開発チームに共有します。その内容をプロダクトバックログアイテム(PBI)として分解、見積もりを行ったうえでスプリント単位でPBIを着実に完了させていくような流れです。 この変更による品質面で取り組んだことを紹介します。
PBI単位で受け入れ検証を行う
受け入れ検証に合格しなければPBIが完了ステータスにならないというフローにし自分の方で受け入れ検証を行いました。最初は細かなエラー文言やエッジケースも含めて細かくテストを実施しました。スクラム導入初期は開発チームの中でPRレビューが通れば終わりという暗黙的な認識があったように思います。その結果受け入れ検証で不具合が発覚するケースも多かったのですが、「受け入れ検証タイミングでこのレベルの問題が見つかるのは良くないよね」というエンジニア側での問題意識が高まり、PRレビュー観点の見直しやデイリーでの細かな認識合わせなど改善が行われていきました。 今では自分が以前のように細かく受け入れ検証することも少なくなり、デザイナーも含めて他メンバーが受け入れ検証を行ってくれることも多くなってきています。
QAチームを早期に巻き込む
QAチームは開発チーム横断で独立したチームとして存在しているのですが、週1のリファインメントにQAチームも参加してもらい仕様検討の段階から参加してもらいました。そうすることでQAチームでより精度の高いテスト仕様書を作成できるようにしました。
また今回はフェーズ1の中でもリリースをさらに分割することでこれまで開発工程の最後に行っていたQAチームのQA検証も分割して行いました。これにより1回のリリース内容が小さくなりテストすべきユースケースも明確になりました。
さいごに
いかがだったでしょうか？
本日紹介した取り組みについて当然自分1人の力ではなくチームやステークホルダーの方の協力や頑張りによるものが大きいです。 これからもみんなで力をあわせてユーザーに少しでも早く価値あるプロダクトを提供できるように精進していきたいと思います。
以上、最後まで読んでいただきありがとうございました！
