見出し画像

ドメインエキスパートを巻き込むプロダクト開発体制の3つのコツ

PharmaX Blog

※本記事は、PharmaX Advent Calendar 2022の 19日目の記事です。

こんにちは、稲垣慶典（@InagakiKay）です。
エンジニアと薬剤師によるチームで次世代型オンライン薬局をつくるPharmaXでプロダクトマネージャーをしています。
今回はドメインエキスパートxエンジニアの開発組織で発生しがちな問題とそれを回避するためのコツについて考えてみます。

＜プロフィール＞
新卒でDeNAに入社し、『怪盗ロワイヤル』や協業開発プロジェクトなどでゲームプロデューサーとして従事。その後ヘルスケア領域に異動し、がんスクリーニング検査の研究開発プロジェクトや健診施設のDXプロジェクトで事業企画リーダーやプロダクトマネージャーを担う。2022年4月にPharmaX（旧YOJO Technologies）に参画。

対象読者

  • 医療に関わらずドメインエキスパートと共に開発をしているエンジニア

  • エンジニアとともにプロダクトをつくりたいドメインエキスパート

背景

ここで言うドメインエキスパートとは、その事業・サービス領域における専門知識を武器にプロダクト開発に貢献するメンバーのことです。

PharmaXでは、漢方を中心としたセルフメディケーションのサブスクサービス『YOJO』と処方せんのお薬をオンライン完結で受け取れる『YOJO薬局四谷店』という2つのサービスを提供しています。
どちらのサービスも薬局事業者として全てを自社で行なっていることもあり、薬局業務のオペレーションや患者さまとのコミュニケーションを担う薬剤師と、プロダクト開発チームが極めて密接に協働しています（薬剤師出身のエンジニアやPMも存在します）。

ドメインエキスパートである薬剤師とエンジニア、デザイナーなどのプロダクト系人材がともにプロダクト開発するなかで、さまざまな問題に直面してきました（もちろん今も……）。

今回は、その中からいくつか問題を挙げながら、ドメインエキスパートとのプロダクト開発体制に普遍的な起こりがちな問題とそれを防ぐためのコツについて考えてみます。

ありがちな問題

最初にツールでつまづく問題

ドメインエキスパートのメンバーがプロダクト開発チームに入る、最初のタイミングから問題は発生しがちです。それが業務に使うツールのキャッチアップです。

ドメインによるかもしれませんが、薬剤師を含む医療系のドメインエキスパートの場合、Slackやnotion、Google SpreadsheatといったIT企業では一般的な業務ツールにも馴染みのない方がほとんどです。そのため、初日の時点でこちらが思う以上にキャッチアップコストを負担に感じてしまいます。

また、こういったツールは、ツール自体の理解だけでなく、その前提となる働き方の理解も必要となります。
電話がコミュニケーションの主である働き方だった方にとって、非同期チャットのSlackベースで働くというのが、実はイメージしづらかったりします。それが故に、操作方法だけでなく、いつ誰に連絡するときに使うか、どのような”お作法”が求められるのか、どういう温度感で書けば良いのか……といった意味での使い方を学ぶのが、実は大変だったりします。

そんな状態で、エンジニアから「このやりとりはGithubベースでするのでアカウント作っておいてください」「JiraのWBSのビューから必要なタスクを積んでおいてください」と言われても、ドメインエキスパートのメンバーからすると、なんのこっちゃわかりません。

ツールでつまづく問題は、実はこの先の問題の一歩目でもあります。思っている以上にきちんとオンボーディングをする、もしくはドメインエキスパートを含む開発チームにおいては全員が使いやすいツールにしていくなどの工夫が必要です。


互いに言葉が通じない問題

薬剤師とエンジニアのチームでは、互いによくわからない言葉や概念が飛び交うのが日常茶飯事です。

薬剤師「疑義照会！」「服薬指導！」「薬歴！」
エンジニア「スプリント！」「DDD！」「Firestrage！」

自分の領域では当たり前のように使っている言葉も、他のエキスパートには当たり前に通じません。
言葉自体は聞き馴染んできたとしても、その文脈やその言葉が意味することの概念構造を理解しない限り、「よく聞くけど、よくわからない」という状態になりがちです。

また、専門用語らしい言葉ならまだしも、より危険なのが、一般的な言葉の解釈が実は異なっていることです。

例えば「リスク」という言葉が意味するのも、エンジニアにとっては障害によるサービス停止などかもしれませんが、薬剤師など医療のドメインエキスパートにとっては患者さまへの身体的な過失であり、最悪の場合、死をも想定しています。
同じように言葉を使っていても、実は意味するニュアンスや温度感が違っていて、「なんとなく認識が合わない」という状態になり、空中戦になりがちです。

まるめて説明しすぎ問題

こうした言葉による分かり合えなさに直面すると生じるのが、”まるめて説明しすぎ問題”です。

どうせ細かく説明してもわからないからふわっと説明する、もしくは、そもそもわからないだろうから細かくは説明しないとなってしまう事象です。「細かい部分は端折りますが、まあ要するに……」が頻発されると危険です。

この事象の問題は、本来共有すべきことが共有なされなくなってしまうことです。つまり、複雑性や文脈が省略されてしまい、”ほぼ”決定事項のみの共有となってしまいます。

その結果、「なぜそうなのか？」「他にどういう可能性があるのか？」「その差分は何か？」など、決定事項の妥当性や必然性が共有されず、他のステークホルダーが協力しづらくなってしまいます。

その結果、互いがブラックボックス化してしまい、心理的にも孤立・対立した関係性になってしまいがちです。

わかりやすい対立構造作っちゃう問題

そして、エキスパート同士で本来必要な”健全な綱引き”が、ただの対立構造
になってしまいます。

医療系のドメインエキスパートとエンジニア間で対立構造になってしまうテーマとしては、例えば「リスクVSスピード」があります。
特に0→1フェーズのプロダクトにおいて、エンジニアとしてはリーンに開発していきたくなるものです。一方で、医療のドメインエキスパートにとっては、医療の質が担保されているかがとても気になります。患者さんの健康に直結するお薬を投薬する、医療の最後の砦として質を担保する重要な責任があります。

その結果「もっとスピーディーにやりましょう」「それだとリスクがあります」「いやいやそんなこと言ってたら時間がかかります」……といった空中戦の議論を経て、”対立構造”が暗黙的に生まれてしまいます。

そうした状況では、対立構造を前提とした議論になってしまいます。物事を進めるための議論でなく、議論のための議論になってしまい、全てが止まってしまいます。

ドメインエキスパートがお客さんみたいになっちゃう問題

次第に、互いに理解したり知見を吸収し合う関係性から、ドメインエキスパートに「OKと言ってもらう」「文句を言われないようにする」という関係性へ変化してしまいます。

ドメインエキスパートにとっても「どうせ言っても無駄だから」という気持ちになってしまうと、プロダクト開発チームとしては全くドメインエキスパートを巻き込めていない状態になります。

問題を回避する３つのコツ

考えるだけでも胃がキリキリと痛むような展開でしたが、大なり小なり、ドメインエキスパートがいるプロダクト開発チームでは似た問題を抱えているかもしれません。

では、上記に問題を回避するにはどうしたら良いのでしょうか？
以下3つが重要だと思います。

考え方や働き方の違いも捉え、理解し合う

ドメインエキスパートは、そのドメインにおける深い経験を経て、専門知識を有しているからこそ、とても重要な存在です。

しかし、わかりやすい専門知識の部分に気を取られ、異なるバックグラウンドの働き方や考え方をしてきたということを忘れがちです。

ドメイン特有の業界構造や慣習に基づく、固有の働き方や考え方があり、それらは必ずしもIT業界やスタートアップ業界とは同じではありません。

例えば、薬剤師含む医療の業界は組織の階層構造がしっかりしていて、上意下達のコミュニケーションが一般的です。だからこそ、「うちはフラットな組織なので、気にせずガンガン言ってください！」と言われても、戸惑ってしまう人が多いのです。

有している知識が違うのはわかっているけれど、ついつい当たり前と考えがちな物事で、実は分かり合えずにすれ違ってしまう。こうした起こりがちな問題をあらかじめ認識した上で、意図的にその違いをあぶり出し、互いに理解していくことが重要です。

※こうしたコミュニケーションにおけるすれ違いの考察は、下記書籍がおすすめです。

共通点・共通言語をつくっていく

ドメインエキスパートとプロダクト開発チームの間で、しっかり”健全な綱引き”が行われることが重要です。
健全な綱引きとは、それぞれが専門性やスタンスを明確にした上で、多面的にコトに向かう議論がしっかり行われる状態です。

ただし、前述したように、異なるバックグラウンドを持つメンバー同士なので、多かれ少なかれ対立的な姿勢になってしまうと思います。それを悪い方向に持っていかないためにも、立ち戻るための”北極星”が必要です。

プロダクト開発においては、ユーザーへの価値提供がその北極星になりうるわけですが、これはドメインエキスパートのメンバーにとってもとてもわかりやすい軸になります。なぜなら、その領域に深く経験を積み重ねてきたからこそ、とても熱い想いを持っている方が多いからです。

もちろんふわっとした言葉で済まさず、しっかり認識を揃え、共通言語として掲げることが必要です。それができれば、議論で対立構造になったとしても「ユーザーにとってどういう形が良いんだっけ？」という軸で前に進む議論をしやすくなります。

互いのポテンシャルをしっかり期待する

ドメインエキスパートとエンジニアやデザイナーといったプロダクト開発メンバーの間で、常に「どこまで細かく説明すべきなんだっけ？」という悩みは存在します。

その悩みの根底には、前提情報や前後関係などを含めてしっかり理解してもらうための情報はたくさんあるが、一方で伝えるのも大変という心理だと思います。さらには、そこまで教えて意味あるんだっけ？細かく説明したところで足元の業務にどう繋がるんだっけ？という不安も。

もちろんバランスではあるものの、ここまでの話を通じて、伝えることを横着すると痛い目を見るのも事実です。

互いのポテンシャルを信じ、しっかり説明をしていくことは、長い目で見たときにドメインエキスパートを巻き込んだプロダクト開発体制を強靭なものにしていきます。

ちなみに、ITとは縁遠い薬局で働いてきた弊社の薬剤師メンバーは、notionを誰よりも使いこなしたり、SQLをかいたりします。すごい。

まとめ

弊社のバリューに「智の創発」というものがあります。曰く、自分の専門分野だけでなく幅広くインプットしつつ、自分が得た知見を発信していくという姿勢です。

エンジニアなどのプロダクト系人材と薬剤師（あと医者も）が混在する社内では、日々刺激的な智の創発が行われており、従来のプロダクト開発の環境とはまた一味違った体験ができます。

というわけで、ぜひご興味あれば覗いてみてください！👇


PharmaXでは定期的にテックイベントをオンラインで開催しています！
2023年1月は、金融業界・花き業界・薬局業界という異なる業界でDX推進をリードするスタートアップ企業3社が集まり、それぞれのオペレーションを担っているドメインエキスパートとプロダクト開発チームがどのように連携しながらプロダクトや開発組織を作っているのかについてディスカッションします。
ぜひお気軽にご参加ください。


この記事が気に入ったらサポートをしてみませんか？