ドクターズプライム Official Blog

「救急車たらい回しをゼロにする」ドクターズプライムの公式ブログです

プロダクト開発のコミュニケーションをなめらかにする10の概念

こんにちは、ドクターズプライムの高橋(id:kyosu-ke)です。ドクターズプライムでプロダクト部門と管理部門の担当役員をやっています。

インターネットではTwitterを中心に@kyosu_keというアカウントでやっています。ユーザーIDにアンダースコアを使えるサービスが好きです。

普段は About Productという個人ブログで割と硬めで気取った文章をポストしています。ゆるいテンションで書こうと思ったのですが、途中から個人ブログ向けに書いてると錯覚してしまい、割と重い文章に仕上がりました。

これはなにか

今回はドクターズプライムで取り入れている、「プロダクト開発のコミュニケーションをなめらかにする10の概念」を紹介するポストです。

プロダクト開発に携わる職種の方はもちろん、プロダクト開発職種と関わる非開発系職種の方にも読んでいただけると、プロダクト開発系職種のメンバーとのコミュニケーションがスムーズになるかも知れません。

それでは本題です!

こんなことありませんか?

プロダクト開発をしていてこんなことはありませんか?

  • 開発スコープの境界線や何をやるべきかの認識が揃わない
  • 何を基準に意思決定すべきかの認識が揃わない
  • 議論の粒度が揃わない
  • その他いまいち議論が噛み合わない

これらは大体が共通認識を持てていないことが原因だと思います。

こういった噛み合わなさや平行線の議論は、以下の4つの要素を定義することで避けることができると考えています。

  1. Issueの種別
  2. 機能品質の種類
  3. 影響対象の区分
  4. 優先順位の基準

そしてそれらの4つの要素はこれから紹介する10個の概念によって定義できます。

これらのフレームワークを利用して、チーム内で今扱っている議題や機能がどう定義されるか、また今回の開発プロジェクトはどういった種類のものをどこまで求めるのかという共通認識を作ることでプロダクト開発のコミュニケーションはスムーズになっていくと思います。

プロダクト開発をスムーズにする10の概念

この1枚が全てといえば全てなのですが、以下1枚の図にまとめました。

f:id:drsprime:20211011175618j:plain
プロダクト開発のコミュニケーションをなめらかにする10の概念

これら10の概念を使うことで、4つの要素についての議論がスムーズになります。

10の概念を使って「抽象的なスコープ」を決める

実際にドクターズプライムでもこれらの概念を導入してコミュニケーションに織り込むようになってから、開発スコープに関する議論がスムーズになりました。

ある開発プロジェクトを進める際、そのプロジェクトの具体的な機能スコープを決める前に、これらの概念を用いて「抽象的なスコープ」を決めておくと、その後の議論がスムーズになります。

抽象的なスコープの欠如は高コスト or 無関心につながる

なぜ抽象的なスコープが大事なのでしょうか。一見、開発スコープというものは具体的でなければ意味がないように思えます。

キーワードは "コミュニケーションの高コスト化" です。

いきなり具体のスコープを決めてしまうと、必ずチーム内外から「これは入れないんですか?これは入れたほうが良いと思います。入れてくれませんか」みたいな話が、しかもスコープがあらかた決まった後から出てきます。

そのときに抽象度の高いスコープを定義できていないと、この疑問・要望に対しての説明コストや調整コストが高くなります。

スタートアップであればトップダウンの独断で説明・調整コストをゼロにしていくことも可能ですが、これではリーダーの判断基準や、リーダーが見えている世界のロジックが周囲に伝わらないため、同じことが繰り返し発生します。

そしてリーダーは逐一入る横槍にフラストレーションを感じ、周囲は提案を無碍に跳ねられる状態にフラストレーションを感じ、ついには無関心化します。

これを避けるためにも、この10の概念を用いて具体的なスコープ決めの前に「抽象的なスコープ」を定義すると良いと思います。

前置きが長くなりましたが、それぞれについて具体的に見ていきましょう。

Issueの種別

Issueの種別を定義する際には、 "効果問題・効率問題・満足度問題" という3つの概念セットを用います。

効果問題、効率問題、満足度問題
引用: 「UX/ユーザビリティのためのテスト - ユーザーテスト見学会 at JaSST」

これらは "ユーザビリティテストの問題分類" で使われている用語・概念から借用しています。 "ユーザビリティテストの問題分類"、ないしはユーザビリティテスト全般については、以下の記事が参考になるので、興味のある方はご覧ください。 
 note.com

それぞれを詳しく見ていきます。

1. 効果問題

効果問題は、ユーザーがソフトウェア上であるタスクを実行しようとしたときに、そのタスクが実行不可能である状態を意味します。

たとえばファッションECサービスで靴を買う場合にサイズフィルターが提供されておらず「サイズでの絞り込みができない」といった状況を指します。 機能は用意しているが、導線が奥深い階層にあって発見できないというのも効果問題に含まれます。

2. 効率問題

効率問題は、ユーザーがソフトウェア上であるタスクを実行しようとしたときに、そのタスクが実行可能ではあるが、手間が掛かる状態を意味します。

先と同じ例を使うならば、サイズフィルターは用意されているが、ヨーロッパサイズの表示にするためには「別の画面で別の設定を触らないといけない」といった状況を指します。

3. 満足度問題

満足度問題は、ユーザーがソフトウェア上であるタスクを実行しようとしたときに、タスクはスムーズに実行できるが、不満が残る状態を意味します。

同様の例でいえば、サイズフィルターはあって絞り込みはできるけど、「単位表記がないため混乱するし見にくい」といった状況を指します。

これらを使って「今回はユーザーの効率問題を解決する」と抽象的なスコープを整理することで、満足度問題を今回の開発のスコープにしないことがチーム内外に伝達でき、コストとハレーションが減ります。

機能品質の種類

「機能品質の種類」を切り分けるには "当たり前品質・魅力品質" というフレームが役立ちます。

これもまた、製品やサービスの品質要素を分類し特徴を記述したモデルである "狩野モデル" から引用している概念です。

狩野モデル
引用: 「狩野モデルと商品企画:部門別スキル - 品質管理なら日本科学技術連盟」

狩野モデルでは上記2つだけでなく、"一元的品質" というものもありますが、スコープの切り分けの議論を行う上では重要度が低いため除外してあります。

狩野モデルについては、以下の記事が詳しいため、興味のある方は以下の記事をご覧ください。

www.juse.or.jp

productmanager55.hatenablog.com

以下で詳細を記述します。

4. 当たり前品質

当たり前品質は、その機能・品質が満たされていて当然だとユーザーが認識しているものを指します。

例えば家に例えるなら、屋根がある、壁がある、水道が通っているというのは当たり前品質に該当します。

これらは満たされていたところでユーザーは魅力に思わないが、欠けていると不満に思うものになります。 当たり前品質は早急に満たす必要がある一方、必要以上にコストをかけても得るものは大きくないです。

5. 魅力品質

一方魅力品質は逆で、その機能・品質が満たされていなくて当然だが、満たされていると魅力に感じるというものです。

同じく家に例えるならば、オール電化の住宅や、家の中に設置されたエレベーターや、スマホで開閉出来るロックなどが該当します。

この例でもわかるように、魅力品質に該当するものは満たされていなくても特に不満には思わないですが、満たされていると嬉しくてユーザーにとって差別化に繋がります。

今回の機能改善は当たり前品質を満たしに行くプロジェクトなのか、魅力品質を作りに行くプロジェクトなのか、それらを事前に定義できるとどこまで力を掛けてクオリティを追求すべきかの認識が自ずと揃いやすくなります。

影響対象の区分

ひとくくりにされがちな「品質」をその影響が及ぶ先で外部と内部に区分した "外部品質・内部品質" も使いやすい概念です。

外部品質と内部品質
引用: 「質とスピード(2020秋100分拡大版)」

これらはソフトウェア開発の文脈で使われる品質特性を区分する概念のため、説明は不要かもしれませんが、これらもプロジェクトやチームのフォーカスを揃えるのに役立ちます。

これらの品質は○○bilityで表現することができます。どんな○○bilityが存在しているかは@t_wadaさんの以下のスライドにわかりやすくまとまっているので参照することをおすすめします。

6. 外部品質

外部品質はプロダクトのユーザーが実際にプロダクトにふれたときに感じる品質のことを表します。

シンプルに使い勝手が良い、レスポンスが早い、操作が直感的でわかりやすいといったものが含まれます。 これらは誰しもが触れることができるものなので理解しやすいのではないでしょうか。

7. 内部品質

一方、内部品質はソフトウェア内部の作りやコードベースの品質を示す概念で、おもに影響を受けるのはそのソフトウェア・プロダクト開発に携わるメンバーです。

この内部品質を高めることが、外部品質を高めることに繋がっていきます。

抽象的なスコープとして、「今回のスコープは内部品質(or 外部品質)を引き上げることを目的にする」ということを明確にするだけで、外部品質(or 内部品質)に該当する機能開発をスコープに含めようという不毛な議論を避けることができます。

優先順位の基準

最後に紹介するのがSIQ(シック)フレームワークです。ドクターズプライムでは開発の意思決定基準を定める上で重要視している観点です。

SIQフレームワーク

元ネタがあるフレームワークではないですが、Speed, Impact, Qualityという非常にわかりやすい単純な3つの概念で構成されています。

SIQはリファクタリングやDevOpsを含む、全ての開発を上記3つの観点で評価し、優先順位をつけていくという考え方です。

それぞれを詳細にお話します。

8. Speed

Speedは言わずもがな、スピードです。 スピードが早いことは大正義なので、ユーザーへの機能提供スピードが早いことを良しとして評価します。 どんなにイケているプロダクトや機能でも、タイミングを逸してしまっては成功が遠のきます。

9. Impact

Impactはユーザー・顧客へもたらす正の影響の大きさを意味します。 影響の大きさは影響を与える範囲の大きさと、影響の深さの2点の掛け合わせによって表現されます。 より多くのユーザーを対象にして、より変化値の大きい影響を出せる施策ほど評価されます。

どんなに品質の高い機能をどんなに早く出したとしても、その恩恵に預かれるユーザーがごく少数であったり、その影響レベルが浅ければ、やっても意味がない施策になるかもしれません。

10. Quality

Qualityは上記の内部品質・外部品質で表される品質を意味します。 どんなにインパクトの大きい機能を爆速でリリースしたとて、内部品質や外部品質が低すぎると、のちのち作り直しやユーザーにとってのディスブランディング、バグが多ければhotfixを当てて出し直すという事態に繋がります。

S.I.Q.3要素の大小をもとにスコープを整理する

各施策やIssueごとに、SIQの3要素がどれくらい変化するのかを考え、優先順位を付けていきます。 それぞれの度合いは明確に数値化しにくいものもあると思いますが、その場合でも度合いを大・中・小の3段階に分けて見える化するだけでも、かなり議論が整います。

全てを満たしにいく

Speed, Impact, Quality、これらの3つの概念ですが、どこかに偏重特化すればよいというわけではありません。 ひとつの要素だけに偏重した意思決定を繰り返していっても長期的に良い結果には繋がらないと考えています。

全てを満たしに行くのがあるべき姿である一方で、ときには「特定の1要素に全集中して爆速で出す」であったり「じっくり取り組み最高レベルで出す」という判断も重要になります。

そういった場合はプロジェクトの種類や内容に応じて、「雑でもとにかく早く出す or 時間を掛けてでも研ぎ澄まされたものを出す」といったように、抽象的なレイヤーでどこにフォーカスするかの認識を事前に揃えておくと、不毛な議論に時間を費やすことが少なくなります。

まとめ

  • 具体的な開発スコープを決めきる前に抽象的なスコープの認識を揃える
  • 抽象的なスコープに使える10のフレームを用いる
  • 具体的なスコープで追加要望が出てきた場合には抽象的なスコープに立ち止まって考える

だいぶ長くなってしまいましたが、これらの10個の概念を用いて、4つの要素についてチーム内外の認識と期待値を揃えることで、プロダクト開発のコミュニケーションがなめらかになっていくと思います。

参考文献

一緒に働く仲間を募集しています

ドクターズプライムでは「救急車のたらい回しをゼロにする」というビジョンの実現に向けて、病院向けのSaaSプロダクトおよび、医師/病院間の最適なマッチングを提供するマッチングプラットフォームを展開しており、一緒に働く仲間を募集しています。

まずはカジュアルにお話ししてみませんか?

meety.net

speakerdeck.com