PM視点でひとつの機能が世に出るまで ”要求の整理〜要件定義〜リリースまで”

前段

ご覧いただきありがとうございます。クロスマート株式会社でプロダクトマネージャー（以下、PM）を務めております森(@monroo12)です。

これまで、開発チームや開発に対する大枠のフローについては、PM横断していくつか記事を書かせていただきました。

xmart-techblog.hatenablog.com

などなど。

今回はさらに具体的に、ある機能の”構想から世に出るまで”を執筆しました。（といっても、マスクしている部分が多くて分かりにくさあるかもしれないです、、、気になる部分や掘り下げたい部分あったら語る会しましょう）

もちろん、機能の規模によって取捨選択しながらのフローになりますが今回はプロジェクト的に切り出して進捗を行う中規模の機能について書いています。

想定読者

PMの関わる上流工程についてざっと知りたい方
クロスマートの開発フローに興味がある方
優しいまなざしで記事を見てくださる方

どのような流れで機能開発しているのか？

流れの全体感

要求定義
要件定義
外部・内部仕様の策定
見積・実装
テスト（ユニット・結合・総合・運用）
リリース

一部、機能の大小や、他機能への影響度の大小によって工程内でやるやらがあったりマージされて行われる場合もありますが、概ね上記のような流れで機能開発を行っています。

改善や改修などの小規模機能であれば、ざっと「1.要求定義」を社内ですり合わせしてそのまま「4.実装」を行うこともありますし、新機能、新事業レベルの大規模機能であれば、1.からしっかりとお客様へのヒアリングを行ったり、モックを作ってユーザーリサーチを行ったりもします。

1.要求定義

CS/FSとの連携であつまる要望から課題を抽出して解決する機能を考えます
- 必要に応じて社内のドメインエキスパートに参加してもらう
- 企画書やデザインモックを利用してお客様にヒアリングを行う
- なども行います
課題を起案したメンバーとその機能に対する要求を整理する
- なぜ必要か？どのような課題があるのか？
- その課題を解決するためにどのような機能が必要か？
- どのようなプロジェクト・機能か？（必要に応じてエレベーターピッチを作ります）
- 必要に応じてステークホルダーの整理
- 参考情報
- などを第三者があとから見てもわかりやすいようにドキュメント整理することを意識しています
※基本的に「お客様は〜をしたい」と表現することを意識しています。

2.要件定義

このフェーズでは前段階で整理された要求を可視化して機能（システム要件）・画面に落とし込みます
私の場合業務フローをフローチャートで可視化しそこに必要な機能と画面を一覧化していくことが多いです

AS−IS（既存業務）→TO-BE（機能によるDX化）のフローをもとにもれなく洗い出します

上記のユーザーフローと、要求定義を元に必要な機能を洗い出します
機能リストと画面リストの関係性に齟齬がないように記載していきます
- 機能リストには、機能名を軸に「どのような機能か？」「どの画面で行えるのか？」を記載しています。
- 画面リストには、画面名を軸に「どのパスにある画面か？」「何ができる画面なのか？」を記載しています。
  - 機能リストをバックエンドのメンバーが、画面リストをデザイナー、フロントエンドのメンバーが活用することをイメージしながら書くことが多いです
  - ここはPMやプロジェクトメンバーによって多少違いがあるように思います
初めは要求定義に毛の生えたぐらいの要件定義をしていました、、、
- ここだけの話、一年前PMジョイン時の要件定義書は何言ってるのか分かりづらく、要求と要件も混ざっていて読めたもんじゃなかったですつらい、、、。
- 一度デザイナー兼PM経験ありメンバーや、前職でゴリゴリ仕様策定していたエンジニアメンバーによる要件定義勉強会により昔に比べるとだいぶ精度が上がってきたのではないか、、、とおもいま、、、す。多分。きっと。

3.仕様の策定（外部・内部仕様）

次のフェーズは仕様の設計です
仕様設計については、クロスマートでは要求定義・要件定義をもとにエンジニアメンバーが設計することが多いです（ありがとうございます）
もちろん仕様設計時に疑問を感じた部分についてはSlackなどによる非同期の相談も、ハドルやZoomを使った同期の相談でもいつでも気軽にしてもらうようにしています
- ここでPMが変にボール持たないように意識して即返しを、、、（意識しています、意識。）

参考までに外部仕様（外部設計）とは

要件定義の内容に基づいて外部設計が行われます。ユーザー視点でシステムの振る舞い方を決めていく過程であり、ユーザビリティが大切になります。現場によっては、基本設計と呼ばれることもあります

参考までに内部仕様とは

外部設計の後に行われるのが内部設計です。成果物を実現させるために定義や処理方法などを決めます。エンジニア視点で考えて、開発を支援する役割を果たします。内部設計も現場によっては、詳細設計と呼ばれることがあります。

4.見積・実装

要求定義、要件定義と外部・内部仕様の齟齬がなくなり仕様設計が完了したらいよいよ見積りをして実装です
必要機能の開発チケットを切り、スプリントプランニングで工数を見積ります
- クロスマートでは、スプリントプランニング前に個人で工数に自信のあるものは各エンジニアでの自己見積りを行います
  - その上でスプリントプランニング中に「この工数で妥当か？」相談をすることはあります
- 難易度の高いものはプランニングポーカーを使った見積りを採用しています
2週間スプリントでプロジェクトを進行します
- 日々のデイリースクラムでプロジェクトの進行を確認し合いながらリリースまで進行していきます

このあたりの開発フローの大枠は冒頭の記事でも書いています

5.テスト（ユニット・結合・総合・運用）

コードレビュー等を経て実装された機能は開発環境で確認を行います
前提で、基本的にテストコードは書いて頂いていますので、根本的なエラーは起きにくい開発方針です
PM等がユースケースをもとにした基本テストは通して行いつつ
ステークホルダーであるFS・CSを巻き込んで、思った機能になっているか「お触り会」の名のもとにみんなで機能を確認する時間を取るようにしています
- 機能の規模によって、意図のズレによる開発出戻りの工数が大きくなりにくいように、デザイン段階や、開発環境段階など「お触り会」のタイミングは変えています
特にお客様の業務のコアになる機能（クロスオーダーにおける受発注に関わる機能）については入念にテストを行います

6.リリース・告知

発案から、要求定義、要件定義、仕様策定、実装、テストを経た機能は満を持して（？）世にリリースされます
クロスマートではお客様の業務に影響の小さな時間帯であればいつでもリリース行える開発環境が構築されているため、メンバーとタイミングをあわせながらリリースを行います
- 具体的には意図しない不具合が起きたときすぐの対応が難しい可能性のある休日前のリリースや
- お客様の業務が逼迫することが多い月末月初や年末年始などのリリースは控えています
機能がリリースされたら、社内のステークホルダー及び、お客様に告知を行います
- 社内のSlackのリリース告知チャンネルへの告知
- 朝会や週次会での告知
- 必要に応じて機能の勉強会
- ユーザーの声を上げてくれたFS・CSメンバーのSlackの要望投稿へのリプライでの告知
- FS・CSメンバーを通じてのお客様への告知
- お知らせ機能を利用したお客様への告知
- 広報メンバーによるメディアへのプレスリリース等々
- を行います、せっかく作った機能が届くまでがお仕事ではあるんですが、まだまだここは改善の余地ありです、、、

所感とかまとめとか

何も知らないままPMらしきことをしていた一年前に比べるとそこそこ”PMっぽい”仕事やってるなぁという気持ちですありがたい
書いてて思ったけどPMという仕事は本当にFSやCS、開発メンバー、なんならお客様に支えられてる職種だなぁということを感じました
今回書いたフローや各種定義書も日々の運営でどんどんブラッシュアップされて来年あたりこの記事みたら「あぁ、あの時こんなやり方してたんだ、、、」となりそうな気もします
ここまで読んでいただきありがとうございました！