エンジニアだからこそできる社会に役立つ「プロダクト開発」とは？
こんにちは、広報の上島です。
PharmaXでは、2023年1月より月1ペースでテックイベントを開催しています。
先月は「フルリモートでうまくいくプロダクトチームの作り方」についてディスカッションしました。
（レポート記事はこちらです）
3月のテーマは「エンジニアだからこそできる社会に役立つ「プロダクト開発」とは？」
医療業界でプロダクト開発を行っているharmo株式会社、Ubie株式会社、PharmaXの3社が集まり、 実際にプロダクト開発を進める上でどのようなことを考え工夫をしているのか、成功や大失敗した事例をふまえてディスカッションしました。
今回、各社のLT紹介と実際のパネルディスカッションの内容を記事にしています。
ぜひアーカイブとあわせてご覧ください。
今回の登壇者とLT紹介
では今回の登壇者・モデレーターと各企業のLT資料をご紹介します。
harmo株式会社 代表取締役 副会長 福士岳歩 さん
harmo の考案者。2000 年にソニー株式会社に入社。2008 年、自らの体調不良を機に harmo を構想し、2011 年に実証実験、2013 年に部署設立を経て、2016 年、ソニーの社内ベンチャーとして harmo おくすり手帳の事業化を果たす。2019 年 6 月に harmo 事業をシミックグループへ承継し、CMIC Tech Lab 所長に就任。harmo ワクチンケアを考案。2021 年 10 月、harmo 株式会社 営業開始により現職に至る。
・コーポレートサイト
・採用ページ
LTタイトル：社会に役立つプロダクトを生み出すエンジニアのキーワード「社会との接点」
おくすり手帳やワクチン管理のDX化に挑むプロダクト「harmo（ハルモ）」。現在も多くの医師や薬剤師、そして患者に支持されながら発展を続けています。社会に役立ちたいという志あるエンジニアに向けて「実社会と接点を持つことの大切さ」をharmoプロダクトの創案者が、実際の事例を織り交ぜてお話します。
Ubie株式会社 ソフトウェアエンジニア 八木俊広 さん
医療機関向けプロダクトの「ユビーAI問診」の開発に従事。ユビーAI問診のプロダクト開発のほか、スクラムマスター、アライアンス関連の開発、医療機関事業のプロダクト基盤チームリード、ユーザサポートとカスタマーサクセスの社内オペレーションに関する開発などを兼任。
・コーポレートサイト
・採用ページ
LTタイトル：「医療機関内で利用するプロダクト」の解像度を上げるための取り組み
「ユビーAI問診」は医療機関で受付から診察にかけての業務で利用するプロダクトです。患者さんへの問診の実施と、問診の結果に基づいて医師向けのカルテを生成することで、診察に必要な情報収集の負荷を軽減しています。「医療機関内で利用するプロダクト」の解像度を上げるために、開発チームが行っている取り組みを紹介します。
PharmaX株式会社 取締役・開発責任者 上野彰大 さん
東京大学農学生命科学研究科卒業。大阪府堺市生出身。新卒でIGPI（経営共創基盤）に入社し、2018年12月にPharmaX株式会社（旧・株式会社YOJO Technologies）を共同創業。全社戦略、エンジニアリング責任者。趣味でエンジニアリング勉強会を数年続けている。得意なのは、統計、機械学習、データ分析。
・コーポレートサイト
・採用ページ
LTタイトル：エンジニアが社会の構造不良を解消し プロダクトの強みを構築した事例
PharmaXは、テクノロジーを駆使したオンライン薬局を創り、全く新しい医薬品購買〜相談〜服薬体験をデザインするスタートアップです。
PharmaXでは、数年前から薬剤師のリモートワークを推進しています。 当初は、法律的には患者対応をする薬剤師が薬局内にいることが必須だったため、独自の仕組みを構築し、行政とのコミュニケーションを踏まえてリモートワークを実現しました。
そこから数年経ち、オンライン服薬指導が解禁されて、医療社の働き方改革にスポットがあたる中で、オンライン服薬指導については、正式にリモートワークが解禁され、PharmaXでも多くの薬剤師はリモートワークに移行しております。しかし、多くの薬局では、リモートワーク導入には至ってはいません。
難しいドメイン領域で法律の壁があるからこそ、その壁を乗り越える仕組みを構築できれば、事業・プロダクトの独自の強みとなる可能性があります。どのように行政とコミュニケーションを取るべきなのか？などや、どのように社会の構造不良を発見すべきなのか？といったことなどをシェアできればと思います。
PharmaX株式会社 エンジニア 尾崎 皓一さん（モデレーター）
立命館大学院情報理工学研究科卒業。 TIS株式会社でシステムエンジニアとして勤務後、独立しフリーランスのWebエンジニアに。母が調剤薬局を経営していることもあり、PharmaXのミッション・ビジョン・目指す世界観に共感し、2号エンジニア社員としてジョイン。 現在はエンジニアリングリーダーとしてサービス開発に携わっている。
発想のできるエンジニアとは
今回のパネルディスカッションでは、各社LT発表をもとに2つのテーマについてお話いただきました。
モデレーターのPharmaXエンジニア尾崎さんより、各々に質問していただきましたので内容をご紹介します。
ユーザーもあっと驚くような良い体験エピソード
まずは、これまでのプロダクト開発のうちエンジニア的な視点が活かせた良い体験エピソードについて、各社にお話をお伺いしました。
PharmaX尾崎：
パネルディスカッションをはじめさせていただきます。
パネルディスカッションのテーマは、2テーマ用意しております。
まずはLTの中でもたくさんお話をいただいていますが、エンジニア視点を活かして体験を作ったエピソードについていろいろ深掘しながら話を広げていければいいなと思っています。
2テーマ目は、大失敗したエピソード、ちょっと失敗しちゃったエピソードをもとに、いろいろ深掘れていければと思います。
まず1テーマ目について、harmoの福士さんからエピソードとあわせて「エンジニア視点がどのように活きたか」についても簡単にお聞きできればと思いますが、何かありますでしょうか。
harmo福士さん：
先ほどのLTスライドにも出させていただきましたが、最近の話で一番印象に残っていることは、厚労省と外務省がジョイントでやっている事業の話になります。
この事業自体は2021年8月1日から始まるということでしたが、私が初めてその会議に出させていただいたのが同年7月1日だったんですね。
実際に初めてお話を聞いて、１ヶ月という期間で現実的にできそうなことを頭の中で組み合わせて、「このような仕組みを作ってここに入れれば、１日かかる想定を15分に短縮できると思います」とその場で改善案を提案しました。
かなり議論は白熱しましたが、その場で出た技術的な質問にすべて回答したのと、私が責任者として「間に合う」と断言したこともあったからか、結局最後は「それでいきましょう！」という話になりました。
ちょうどオリンピック開催のときでしたが、オリンピックを見ては、ひたすらコーディングをしていた日々が今でも思い出深いです。
PharmaX尾崎：
ありがとうございます。
先ほどのLT発表でも「このスピード感はすごい」というようなコメントをたくさんチャットでいただいていますが、スピード感を出す秘訣についてはいかがですか。
もちろん福士さん自身の行動力や発想力もさることながら、スピード感のある開発を進めるには何か工夫されていることがあるでしょうか。
harmo福士さん：
開発はきちんと「何を作るか」さえ決まってしまえば、あとはそんなに迷いなくいくと思っています。
「何を作るか」が決まるまではどうしても時間がかかるため、決めるということはユーザーの体験を見ながら何往復もすることがやはり大事なことだと思います。
しかし、ときには時間がないこともあるため、エンジニアとして「この期間でこれならいける」と判断することがとても大事だと思います。
判断をしたあとは、ここは作る、ここはもう落とす、と決めれば短期間でもできるのかなと実感しました。
PharmaX尾崎：
なるほど、ありがとうございます。
八木さんのLTの中でも、ニーズと開発の接合部分はとても大事だというような文脈もありましたよね。開発における仕様の落とし込みの精度などにエンジニアが関わることはとても大事だなと思います。
八木さんも、開発スピードを出すことに対して工夫されていることはありますか。
Ubie八木さん：
そうですね、福士さんの場合だと大臣などとの会議での提案なので、また少し違う話になるかもしれません。
小さく作るような、手前の課題とか欲求とかをファジーというか全体の「これとこういう仕様があったらうれしそう」のようなぼんやりしたものから、「本当にそうか」「これだけあったらできるんだっけ」「これとこれがないとだめ」みたいにひたすらそぎ落とすことをやっています。
我々はこのことを「カリカリする」と言っています。
これ以上そぐと全然意味がないギリギリのラインまでひたすらそいでそいで、いわゆる最小限でかつ有効なものにした上で、そこから開発に乗せることを普段はやっていますが、エンジニア発想なのでしょうかね。
PharmaX尾崎：
スタートアップだとそこが肝になるのでしょうね。ありがとうございます。
他にもエンジニア的な視点が生かされたお話があればお伺いしてもよろしいでしょうか。
Ubie八木さん：
我々には予約APIというものがあります。
医療機関予約サービスのベンダーさんと連携するAPIで、実際に予約した後、医療機関へ行く前に事前に問診をする機能になります。
事前に問診内容を医療機関に送ることで、医療機関はどういう症状の患者さんが来るか知ることで待ち構えることができるような機能を作っていました。
当初は単純に「事前に送れるっていいね」というぐらいでした。
実際に作ったあとの利活用のところで、受付タイミングに「こういう症状があるんですね」と患者さんに伝えた時に、相手に全部伝わっていることがわかることはスムーズで患者さんの体験もよく、満足して帰っていただけています。
事前に送ることはシステム的にはできるぐらいの感じでしたが、実際作ってみると今までにない体験を作れたところがあります。
エンジニアリングとしては、途中で予約ベンダーさんに向けてAPIの仕様などを作っていましたが、段々と予約ではなく、任意のタイミングで問診が始められることが大事そうだなと気づき、使用を汎用的にしてみました。
すると他の使い方が広がって、例えば病院の受付機でQRコードに問診を払い出すとか、医療法人によってはグループの医療機関で使う外来アプリのようなもので受付してアプリの中で待ち時間を通知するとか、待っている間に問診してもらおう、などとアプリでの連携もこのAPIでできる、そういった他の利活用の仕方がノーコストでできることは最初から想定はしていなかったのですが、汎用化することで広がったのはとても良い体験でした。
エンジニアらしさが発揮できたかなと思っています。
PharmaX尾崎：
広げていくことは、「カリカリ」とは逆ですね。
Ubie八木さん：
そうですね、最初は最小限でやりましたが、ユースケースを聞いているうちに段々と抽象化できました。エンジニアは抽象化が好きだし得意かなと思っています。
「固定のユースケースに汎用的に流れるものとは何だろう」と考えたときに、「そうか、別にそこに限定する必要ないんだ」というところで落ち着きました。
しかも作ることはそういう作りにするだけなので難しくありません。工数は変わらず設計を変えました。
PharmaX尾崎：
ありがとうございます。
発想のできるエンジニアについては今日のテーマでもありますので、ちょっと視点を変えてとても興味があることについてお伺いします。
エンジニアを個人的にみたときに、スキルなどをどのように見極めるのか、伸ばしていくのかについても気になります。また、どのようにうまく組織を作っているのかについても興味があります。
Ubieさんの場合ですと、エンジニア組織を作っていく、発想のできるエンジニア組織にしていくために、採用面や組織面で気にされていることはありますか。
Ubie八木さん：
まず採用面だと、エンジニアが全部採用プロセスを作っていますし面接も実施しています。採用のリファラルやスカウトも全部やります。
どういうエンジニアに来てほしいかでいうと、やはり課題を解決できる人ですね。
技術についてなどはあまり見てはいなくて、「今まで事業でどういうことをやっていましたか」とか「在籍している会社のミッションは何ですか」とか「製品の価値とは何ですか」のような質問から、そこをバリバリ意識してやれる人はプロダクト開発の目線が揃うかなと思い、意識して面接しています。
PharmaX尾崎：
ありがとうございます。
福士さんにもお伺いします。もしかすると、harmoさんもUbieさんと似たようなエンジニアの方を求めているのかなと感じたのですが、採用面や組織面で気にされていることはありますか。
harmo福士さん：先ほどのLTスライドの図でのAやBのエンジニアの人に来てほしいなと思っています。
しかし、どのように見極めるのかは非常に難しい問題だなと思っています。
実際には、ポテンシャルがある人に来てもらい、AやBの姿を自分たちでしっかりと実践しながら見てもらうことで理想に近づいてもらえればよいかなと思っています。
PharmaX尾崎：
私自身、医療業界以外からPharmaXに入社しましたが、組織の文化などに触れたり作業したり現場を見たりすることで、より興味を持ってやっていきたいと思った経験があります。個人のキャリアとしても意識できるといいのかなと思いました。
ありがとうございます。上野さんもいかがでしょうか。
PharmaX上野さん：
そうですね、我々は薬局という難しいドメインのため、エンジニアがプロダクトをどう作るかが非常に重要な業界です。
そのため、もしかしたらお二人とも温度感が揃うかもしれないですが、まさにコンセプチュアルスキルというか、ちゃんと越境してエンジニア以外のことなどに取り組めたり他の職種の人などと絡めていけたりなど、自分にとっていい意味で領域を侵犯していける人は技術力も高く、やればできると思っています。
私も面接でエンジニアリングの経験についての話はそこまでせず、「こういうことをやったことがありますか」「こういう課題がある場合、あなたならどう解きますか」などの話から、大体の技術力がわかるため重要視しています。
PharmaX尾崎：
そうですね。今後残っていくのはエンジニア以外のことにも取り組めるスキルなのかもしれません。個人のエンジニアとしても伸ばしていけるといいなと思いました。ありがとうございます。
最後に上野さんからもエンジニア視点を生かして体験を作ったエピソードをいただければと思います。
PharmaX上野さん：
行政と保健所に仕様を持っていき議論したことです。
あの時はエンジニアがやるのが一番早いなと思いました。
仕様もいろんなパターンがあるため、どういう仕様だったら彼らが許してくれるか。その場でエンジニアが「これならどうか？」などと議論するほうが早いためメリットだなと思います。
先ほど八木さんのお話にも合った、まさに「カリカリする」ですね。
これだけ絞ってもこれがあれば許してもらえるところの絞り方の工夫などは、やっぱりエンジニア目線があると早いなと思いましたね。
大失敗したエピソード
プロダクト開発は、成功ばかりではありません。失敗から学ぶこともあります。
そこで各社のこれまでの失敗談からのどのような気づきや学びがあったかについて、お話をお伺いしました。
PharmaX尾崎：
次のテーマは失敗談についてお伺いします。
順番を変えてまずは上野さんからお願いします。
PharmaX上野さん：
今回、あたかも法律の変更を予測して動いていたようにLTで話をしましたが、その中で失敗もしています。
薬局は我々の作っているシステムだけでは成り立たず、外部ベンダーさんなどのシステムを組み合わせないと業務が成り立ちません。
我々のシステムはリモート対応をしていたけれども、外部ベンダーさんはリモート対応が難しく、そのため薬歴とレセコンを総取替することになりました。
外部ベンダーさんも法律の変更にちゃんと合わせて対応してくれるのかについて、事前に見ておかないといけなかったなと改めて思いました。
PharmaX尾崎：
ありがとうございます。
ちなみに、外部システムを使うときにロードマップなどはお願いすると出してくれるものなのでしょうか。
PharmaX上野さん：
普通は出してくれないですね。
PharmaX尾崎：
そうですよね。読みも必要になりますからね。
PharmaX上野さん：
最近だと、電子処方箋の対応やオンライン資格確認端末など、どんどん法律が変更されているため、対応しますと営業の人は言うけれど予定より遅れることはあります。
だからといって自分たちで全部作るのはやっぱり違う気がするため、やはり連携していくことがいいと思っています。難しいポイントですよね。
PharmaX尾崎：
ありがとうございます。
時間の関係で皆さんから失敗談を聞くのは無理かもしれないため、いただいているQAを拾いながら進めていきます。
「エンジニアが実際に現場に出るのはどのくらいの頻度ですか」との質問を聞いてみるのも面白そうなので、テーマを変えてみなさんにお伺いします。
まずは上野さんからいかがでしょうか。
PharmaX上野さん：
薬局の見学は入社いただいたタイミングに行っています。
あとは合宿やオフサイトミーティングをやるときは一緒に来てもらったり、患者さんとのインタビューに参加してもらったりすることはいい機会かもしれないです。
PharmaX尾崎：
ありがとうございます。福士さんはいかがですか。
harmo福士さん：
そうですね、私は職場にいないことの方が多いぐらいですけれど、エンジニアでも外に出ていいよという雰囲気を作ることがとても大事だと思います。
私の経験上はそれでもなかなか外に勝手に出かけていくエンジニアは少ない印象です。
harmoのお薬手帳は薬局の方が患者さんにすすめてくださっていますが、一度エンジニア全員に薬局へ行ってもらい、丸１日、患者さんにカードを勧める任務を遂行してもらいました。
行くと説明しないといけないじゃないですか。
エンジニアはけっこう説明が苦手な人が多いのですが、それでもなんとかやっていくうちに、「簡単に説明できるものでないと患者さんに使ってもらえない」と実感したようです。この経験は、その後機能を作っていく上で役立ちました。
PharmaX尾崎：
なるほど。そういう意識は大事ですね。
（もう少し時間があるようなので）失敗談についてもう少し聞こうかなと思います。
八木さんはいかがでしょうか。
Ubie八木さん：
そうですね。プロダクト的な話になります。
最初、病院向けに作り、途中でクリニック向けにもやろうかなと話が出てきたときに、最初からクリニック向けでサービスを分けたプロダクトの方が、独立して作れるしいいよねと思ってやっていました。
しかし結果的にほとんどオーバーラップした形になりました。
実はクリニック向けの機能でやっていたのに、病院の方から「この機能を使いたい」と要望があり、内部的にはできると知っているため「クリニック向けのあの機能を○○病院さんでも使えますかね」のような話が出て、「使えなくはないけど特殊な設定をしなきゃ」などとガチャガチャしたことがありました。
結局、クリニック向け独自のものはそんなにないということがわかり、サービスを分けていたものを統合して、かなりの工数を失ったという失敗がありました。
早い段階で分けてしまったことがだめだったことはあります。
PharmaX尾崎：
ちなみに、病院とクリニックの違いについて簡単に教えていただいてもいいでしょうか。
Ubie八木さん：
簡単な区分けとしては、ベッドが20床以上あると病院、19床以下または病床なしだとクリニックに区分けされます。
街のクリニックは入院がそもそもできないところも多く、入院ができるところは病院に該当する場合が多いですね。
病院だと、院内システム課の方がいらっしゃって診察室もいくつかあるような構造です。
クリニックだと2～3名の医師と看護師さんが複数いらっしゃることが多いですね。診察室は1つ、院長先生が診察もやっています。
そのため病院とクリニックでは関心事が違います。
大きい病院だと診療科がいくつもあり、診療科ごとに総合受付がある場合にタブレットをどのように渡すかが重要になります。
しかしクリニックの場合は、地元でいかに「ここにクリニックがある」「こういう症状のときに受診してほしい」というようなことを知る、いわゆる病院経営が重要になります。
また老舗のクリニックの場合だとすでに地元密着しているため、集客よりも時期ごとにマーケティングの話が重要になります。例えば、花粉の時期には注射薬の取り扱いがあることを既存の患者さんに通知できるとうれしいなどですね。
それぞれ要求が異なるため、機能を分けていく工夫することはやっています。ただ、基本の問診やカルテの部分はほぼ共通になります。
PharmaX尾崎：
すごいですね。エンジニア視点でいくと、まさにこのあたりのコンテキスト境界の切り方、マイクロサービス化の検討など、今の話をぱっと聞いただけでも難しさを非常に感じます。
先ほどのプロダクト分割の話だと、コンウェイの法則と逆コンウェイの法則のように、どちらが先かといった話もありますし、まさにだなと思いました。
まさにエンジニアリングそのものかもしれませんが、チームを先に分けて早めに検証するなど、同じことを繰り返さないためにどのような判断基準で検証するかなどやり方のイメージはありますか。
Ubie八木さん：
そうですね。最近は『チームトポロジー』という本を取り入れてやっています。
今ある機能群にとらわれず、患者さんジャーニーや診察業務フローなど、どういう形で流れているのかをポンチ絵のようなものをまずは書いてみます。すると、「これはとても遠い」とか「ここが近い」とか「ここはわかれるな」などたたき台として議論できていますね。
議論を重ねて、最終的には「これで一旦やってみよう」とチームをスタートしたり、そこから同じように「その後どうだ」と議論を繰り返したりします。
結局何かリリースをするときに、別のチームに頼まなければいけない場合でもチームが独立していないため、どこか繋がっているところがないか見直すことをやっています。
チームトポロジーの考え方に基づき、取り入れてやっています。
PharmaX尾崎：
ありがとうございます。福士さんの失敗談もお伺いできますでしょうか
harmo福士さん：
薬局に物を持ち込んで、実際に現場で実証実験をしようとしたときのことです。
私がお薬手帳を作り始めたときは、1人、2人でやっていた時期が長くありました。
実証実験の前日、薬局へ行き準備万全でセッティングをしましたが、翌日に薬局の全機能が麻痺し、半日間ぐらい薬局の機械が使えない状態になってしまいました。
あとから確認すると、IPアドレスを手動で振ったときに振り違いをしたことでバッティングした機械があり、ネットワークの輻輳が起きていました。
前日にスイッチをオンして確かめたつもりでしたが、マイナーな機械が起動しておらず、当日バッティングしてしまったようでした。疲れていたのだと思います。
その時は人生で初めて土下座に近いことをしました。
PharmaX尾崎：
実証実験するとなると協力してもらっているという関係性もありますよね。
harmo福士さん：
良かれと思って作ったものについて、うまくいけば多くの人が喜んだり体調が良くなったりします。
しかしうまくいかなかった場合、例えばそのときに大事な調剤がされなかったことで体調が悪くなってしまった人がいたら、なんてことしたのだろうというふうに思ってしまいます。
やはり社会でちゃんとやるからには真剣勝負でやらなければだめだということをとても思い知ったため、それから先にそこまでの失敗はまだないかなと思っています。
PharmaX尾崎：
けれどそこが面白さでもあるなとは思いますね。
本日集まっていただいた3社ともに、ドメインの難しさがある分、エンジニアとしての面白さややりがいを非常に感じるお話をたくさんいただけました。
最後にみなさんへの質問です。
「エンジニアとしてまだまだ未熟だと認識しているのですが、実際に使っている立場目線で開発をしていくにはどう意識をしていけばいいのか」という質問が来ています。
まずは上野さんから、これからどんどんやっていきたいという方へ向けてメッセージを最後にいただけますか。
PharmaX上野さん：
プロダクト作りの観点というよりエンジニアリング観点の話でいうと、一番着目すべきことはデータの持ち方ですね。
そのデータをどう扱うか、どう取り回すかを常に考えながら、どういう設計をしようか、どうやれば今のシステムにつなぎこめるかを考えていきます。
PharmaX尾崎：
面白い。福士さんはいかがですか。
harmo福士さん：
実際にそうだなと思いました。日本語で会話しながらも、結局どういうデータ構造にした方がいいかと思うことはよくあります。
PharmaX尾崎：
なるほど、やっぱりベースは技術力ですね。
Ubie八木さん：
あとはシステム理解もあるかもしれません。
自社の要素技術の組み合わせでモヤモヤした領域があると、どうつながるかなど全くイメージができません。そのため、まずは技術を磨くよりも、自分たちが作っているものや提供しているものをより詳しく知ることは、よい取り組みなのではと思います。
大企業だと部署が分かれて、他のシステムなどについてわからないこともあるかもしれないですが、話をして見せてもらうなどできたらよいかもしれません。
PharmaX尾崎：
実際に開発する現場にいなかったとしても、興味を持って理解をしに行くところからスタートすることはよいかもしれないですね。
まとめ
3社それぞれの成功事例や失敗談をお伺いする中で、「難しいドメイン領域だからこその面白さ」が伝わるディスカッションでした。
その中で共通点としては、以下が挙げられます。
「決める」ことの大切さ
開発期間、やること・やらないことを決めたうえで最小限かつ有効なものから開発
発想のできるエンジニアを求めている
課題解決できる
技術以外のことに取り組める
ユーザー目線で開発するためには意識したい２つのこと
データの持ち方
システム理解
今回ご登壇いただいたharmo福士さん、Ubie八木さん、各社関係者のみなさん、ありがとうございました。
ぜひみなさんも各社のサービスをお試しになってみてください！
お知らせ
4月は、「企業フェーズごとの事例で学ぶ技術広報」というテーマでウェビナーを開催します。
登壇は、日本経済新聞社・株式会社グロービス・PharmaX株式会社の3社。
近年、知名度を高めて自社のことを知ってもらうために、技術広報に取り組む企業も増えています。
しかし日々事業に取り組む中、技術広報は後回しになりがちで文化として定着せず困っているという企業も多いでしょう。
今回登壇する各社も、狙いや戦略を持ちながら技術広報に日々取り組んでいます。
その中で、技術広報・発信文化を醸成するための工夫などを成功・失敗事例を交えながらお話いただく予定です。
ぜひご参加お待ちしております！
私たちとともにオンラインを中心とした新しい医療体験を一緒に作ってみたいと思った方、もっとPharmaXについて知りたいと思った方はこちらを覗いてみてください。
まずは気軽にお話しましょう！
この記事が気に入ったらサポートをしてみませんか？