プラットフォーム開発の要求分析の流れ
岩佐幸翠氏：ここで、プラットフォーム開発の要求分析の流れを紹介していきたいと思います。詳細をこれから解説していくんですが、まず、プロダクトの現状と将来どうなっていきたいかをドメインモデルで表現する。
現状と将来の展望の間を取り持つ「今、なにをやらなきゃいけないか？」というところを要求としてモデリングします。この要求をドメインモデルで表現した時に、「本当に漏れていないか」ということを、実際の使い方、ユースケースに当てはめて考えてみる。
まぁ、必ず漏れているので（笑）。そのユースケースに当てはめて得られた洞察をまたドメインモデルに反映して、それをまた使ってユースケースを書いて、ということを繰り返していきます。
まず現状、中長期的な展望の両方をドメインモデルとして書き出そうという話をしましたが、なんでそんなことをするかっていうと、お客さん、プロダクト開発チームの要望をそのままドメインモデルとして書き出しちゃうと、「あれもやりたい」「これもやりたい」というふうに、スコープが広がっていきますよね。
だからといって「まずはここだけやります」と限定して書いちゃうと、その社内プラットフォームで提供するものって、各プロダクト開発チームが掲げるサブドメインの一部しか解決しないと。それはすぐに価値を失っていくわけですね。
長く使われる社内プラットフォームを作るためには、現状と将来どうなっていきたいかという中長期的な展望をきちんとモデリングした上で、「じゃあ、その間で、今なにをやるのか？」を考えていく必要がある。
現状と中長期的な展望をモデリングしたら、要求のモデリングにも入っていきましょう。ここで先ほど紹介したユースケースモデリングが登場します。ここまで要求をドメインモデルとして書き出した時に、「本当にドメインモデルが正しいのか」ということがわからないわけです。なので、実際にどうやって使われるかを検証していきます。
例えばBIシステムツールが組織管理サービスを呼び出して、子孫グループとか、あるグループの子孫とか、あるグループの「薬局」なんていうものを取得していくということを書いた時に、このグループと薬局というものは、1つの抽象的な概念として、例えば「組織単位」なんていう名前にしてみましょう。
そして「汎用化できるんじゃないか」と。「これは今までドメインモデルに出てきてないぞ」と。それをあらためてドメインモデルに反映していく。これを繰り返していくのがドメインモデリングとユースケースモデリングです。
これらの方法の詳細は「ICONIXプロセス」と検索すれば本当に数多くの記事があるため、ここで詳細は割愛します。
「テックリード」と「プロダクトマネージャー」はそれぞれ何をするのか
ここまで要求を分析してきました。ではさっそく開発に入っていきたいわけなんですが、ここで私たちが直面した課題とその解決策について紹介していきたいと思います。
当初、組織管理サービスを開発していた時、2週間のスプリント、プロダクトマネージャーとテックリードとエンジニアとスクラムマスターで、スクラムに取り組んでいくことをやっていました。このテックリードとプロダクトマネージャーの連携が課題となっていました。
テックリードとプロダクトマネージャーはそれぞれ何をするのか、あらためて確認していきます。プロダクトマネージャーは、プロダクトの品質の説明責任を果たす。要は「このプロダクトが本当に顧客の課題を解決しているのか」「その解決するための品質を満たしているのか」をプロダクトマネージャーは気にするわけです。
だからこそ、「なにからやったら一番顧客の課題を解決できて、品質を高められるのか？」「なにからやればいいのか？」とプロダクトロードマップを示して、他チームからのビジネス要件、顧客からのビジネス要件を整理して。
品質としては法務的な品質とか、あとはカスタマーサクセスの品質もまた関わってくるので、こことも連携していくというのがプロダクトマネージャーです。
一方でテックリードは、これは組織によってかなり違う部分があるかなと思うんですが、技術的な意思決定の説明責任を果たすと紹介しています。というのも、中長期的にどんな技術的戦略を描いていて、そのために今なにをやらなきゃいけないのか。そして他チームのシステムと連携する上で、ほかの開発者と連携していくというのがテックリードの役割だと考えています。
例えばプロダクトのバックログリファインメント、つまり何から取り組んでいくかの整理をする時に、テックリードはその開発アイテム、「なにをやるか」というタスクみたいなものがもたらす機能要件とか、「これをやるとこういうふうな機能が提供できる」「こういうふうな非機能要件がこういうふうに品質が上がる」ということをプロダクトマネージャーに説明する。
プロダクトマネージャーは「それを今やったらこういう品質が得られるんだね。じゃあこのタスクは最初にやろう」と優先度を決めてタイムラインに組み込んでいくわけです。
これまで紹介してきたように、プロダクトマネージャーの責務は、プロダクトの品質が顧客の要求を満たしているかどうかを説明していくことです。
でも、社内プラットフォームにおける品質とは何でしょうか？ これまでもお話ししたように、一般的なプロダクトと異なり、社内プラットフォームの機能要件は、例えばAPIとかデータベースとかメッセージキューで表現されるわけですね。
さらに、そのインターフェイスは、例えばAPIがどれぐらいでレスポンスするのか。例えば先ほど言ったように重複してメッセージされないのか、されちゃうのかみたいな。非機能要件と言われているものも大きく絡んでくるわけです。
さらに、社内プラットフォームにおける顧客というのもまた一癖あります。社内プラットフォームの顧客は、プロダクト開発チームなわけですね。ということは、顧客を理解するためには、当然プロダクトを実現するシステムの理解も必要になってしまいます。カスタマーサクセスとかも含め、すべてプロダクトマネージャーがやっていくのはかなり難しい話かと思います。
プラットフォーム開発のアジャイル開発では「エンジニアPdMとPMM」がおすすめ
そこでプラットフォーム開発では、テックリードがPdMのような役割をして……。従来PdMと呼ばれていた役割はProduct Marketing Maneger（PMM）と呼ばれていますが、（その役割を）マーケティングの責任者として位置付けることをおすすめしています。
テックリードは社内プラットフォームの品質がプロダクト開発チームの要求を満たしているかどうかということを担保して、バックログの整理とか、プロダクト自体のロードマップを決めていく。
「じゃあProduct Marketing Maneger（PMM）はなにをやるのか？」というと、社内プラットフォームが仮に品質を満たしている時に、「これは本当にビジネス価値を提供できるか？」ということを担保していきます。
例えばカスタマーサクセスとかセールス、または法務との連携を行っていくわけです。このように分担することを今は試しているという状況になります。
まとめとしては、この2つになります。プラットフォーム開発の要求分析はドメインモデルで対話することをおすすめしています。また、プラットフォーム開発のアジャイル開発では、「テックリードとPdM」という役割分担ではなくて、「エンジニアPdMとPMM」という役割分担をおすすめしています。
以上で終わりたいと思います。ありがとうございました。
