プロダクト設計にはDtoDの当てはまりが良さそう……な気がする
タイトル通り、かなりフワっとしているお話になります。
上流設計、特にどういう製品を作っていこうか、というプロダクト設計には、DtoD(Discover to Deliver)というフレームワークの当てはまりが良さそうだなあと思ったお話です。
私自身、DtoDについて詳しく調べたり本を読んだりしているわけではありませんので、こんなものがあるんだ、という参考程度に。
Discover to Deliverとは
米国EBG Consulting社のエレン・ゴッテスディーナーさんとメアリー・ゴーマンさんが、2015年に考案したフレームワークです。割と最近ですね。本家はこちらです。
日本では、オージス総研がまとめています。
DtoD手法に基づくアジャイル要求 | 株式会社オージス総研
こちらのページでは、こんな風に紹介されています。
個人的には、「プロダクトの7側面」がとても当てはまりの良いモデルだと感じました。
プロダクトの7側面
オージス総研のページにも少し紹介がありますが、ソフトウェア開発にはユーザストーリーマッピングやスクラムといった開発フレームワークがあります。これらのフレームワークはかなり浸透してきてはいますが、如何せんソフトウェア開発に直結していることもあって、少し技術者寄りな側面が否めない部分があります。特にスクラムはそうですね、。そして、ユーザーストーリーマッピングも、それだけではプロダクト設計を考える上では、不十分です。開発すべき部分ではない部分、例えばクレーム対応や在庫管理といった点は、ユーザーストーリーマッピングにはなかなか登場しないと思います。
少し話が脇道にそれますが、私の関わっているプロダクトオーナーは非技術者が多いせいなのか、プロダクトの方針について全く整理されていない状態で、新規プロダクトの話を持ち掛けられることが多いです。はっきり言ってしまうと、顧客要望をそのまま伝達しているようにしか見えません。せめて、プロダクトの指針くらいは決めて欲しいのですが、ある部分について顧客要望がない場合「何も言ってこないんですよ」と言ってくることがあります。ないならないでプランを立てるのがプロダクトオーナーの役割だと思うので、それを技術者に言うのはどうかと思います。
じゃあ、プロダクトオーナーに対して、「せめてこのくらいは考えたり、顧客からヒアリングしてほしい」というのは何ですか、と聞かれると、なかなかうまく整理して話せなかったりします。そこで、このプロダクトの7側面です。よくまとまってるなあと感じました（もしかしたら曲解しているかもしれませんが）。
プロダクトの7側面は、以下の通りです。
- ユーザ
- インターフェイス
- アクション
- データ
- 制御
- 環境
- 品質特性
ユーザ
プロダクトの使用者です。どういう使用者を想定しているのか、という部分を考えましょう、ということです。ユーザストーリーマッピングも、ここにある程度含まれます。使用者を主眼に置いた分析といえば、ペルソナが有名ですね。
稀に、プロダクトの納入先（要するに顧客）が使用者のスコープを想定していない場合がありますが、だからといってユーザ分析をしなくていいわけではないと思います。ちょっと考えただけでも、万人向けなのか、弱い部分をターゲットにするのか、強い部分をさらに伸ばすのかのプランがあり、それによってプロダクトの方針が変わります。顧客が外部企業の場合、それらのプランを提示するのもプロダクトオーナーの役目だと思います。
インターフェイス
APIというより、どれくらいの企業や人が関わり合いを持つか、という部分です。顧客企業と自社、ユーザのみの関係で完結することは稀でしょう。例えば、プロダクトがハードウェアを含む場合、絶対に物流や倉庫が登場します。故障対応はどうするのか、ハードウェアが自社開発ではない場合、カスタマイズはどうするのか、在庫管理は顧客企業がやるのか、自社がやるのか、いろいろ考えることがあるはずです。これを考えないで技術屋に投げると100%怒られます。
アクション
トリガーです。これはユーザストーリーマッピングやユースケースで考えることになると思います。
データ、制御
DtoDの資料をさらっと読む限り、業務フローや法務規制を検討するようです。技術寄り、例えばRDBのデータ構造をどうするかといった系統のものではないと思います。業務フローというのであれば、これは本当に大事で、作ったシステムが客先にマッチしない場合、受け入れを拒否されることすらあると思います。データは、顧客マスタや発注伝票なども含むかもしれません。そういう意味では、確かにプロダクト設計の段階で、絶対に把握しておく必要があります。
環境
どういう場面やシチュエーションで使用されるか、ということだと思っています。業務フローのように「流れ」を伴うものではなく、もう少し定性的なものでしょう。プロダクトの使用環境が、静かで薄暗い環境だと思っていたのに、屋外＋凄いノイズ環境下でした、となった場合、プロダクトがそもそも使用できないということも考えられます。
品質特性
ソフト屋（特にサーバ屋）の場合、想定ユーザ数とアクセス頻度は絶対気にしますし、ハードウェアの場合は耐性試験などの指針にもなるので、技術者からプロダクトオーナーに、どうなってんの？と聞くことも多いと思います。非技術者にとっては何をどう気にすべきなのかわからないので、ある程度、技術屋からインプットする必要があると思います。
メモリやストレージ、CPUはどのくらいのスペックを用意すればよいのかなどは、顧客要望、およびコストと絡む場合が多いため、技術者とプロダクトオーナー間で調整が必要になるでしょう。
まとめ
正直DtoDについてそこまで調べてないのにエントリを書くのもどうかとためらったのですが、紹介してみました。というのも、プロダクトの7側面は、プロダクトオーナー自身も気にかけていて欲しいし、技術者側も、これが足りないよ、とプロダクトオーナーにつっつくべき項目として、割と当てはまりが良いと思ったためです。
