Contreaとの出会いと、新規プロダクトを立ち上げた1年間を振り返る
はじめに
初めまして！Contrea株式会社でPdM兼EMを担当しております、川口(@hirykawa_)と申します。
入社したキッカケから1つのプロダクトを0から立ち上げた経験談を書いていきます。この記事の仕事が面白そうと思ったあなた！ぜひ一度お話ししませんか！
Contreaについて
Contreaは「MediOS」という医療系SaaSを開発運用しているスタートアップです。
事業概要や組織概要はこちらのCompany Deckをご覧ください。
新規プロダクトが立ち上がった経緯
MediOSはインフォームドコンセント(説明と同意)の「説明」の課題を解決するサービスとして始まりました。
手術や検査の説明に膨大な時間がかかることやスタッフによって説明の粒度にブレがあることなどから、Contreaが制作した動画を事前に患者さまに見ていただくことで時間短縮と理解度向上を提供します。
様々な医療機関様と商談を積み重ねていくと、説明領域だけでなく同意領域にも課題があることがわかってきました。
説明から同意までを包括して提供するために、電子的に同意取得を行うプロダクトの立ち上げが社内で検討されていました。
私のContreaとの出会い
少し話を戻しますが、代表の川端さんとの出会いは2年前に遡ります。
当時メガベンチャーでエンジニアとして新規事業の立ち上げをしていた私は、日々優秀なエンジニアと、大規模なシステムの設計開発していく日常に技術的成長を感じていました。
充実していましたが、私の中では違う「ものづくり」への関わりを求めていました。
その「ものづくり」への考えのキッカケは、更に大学生時代に戻ります。
当時医療関係の仕事をしていた父が起業することになり、一緒にソフトウェア会社をやろうと声をかけてくれました。
私は情報系の学部に通っていたことから”開発担当”となり、父と2人で夜な夜なシステム開発に明け暮れました。
初めてのことでしたので、開発したソフトが動かないこともあって苦労しましたが、何とかソフトを完成させました。
私は父と共に、開発したソフトを色々な学会や医療機関様に持っていき営業活動をしていました。
当初は売り上げが上がらず苦労しましたが、地道に改善活動を続けていくと少しずつ売れるようになっていきました。
使ってくれている先生に、「このソフトのおかげで楽になったよ」「もう無いことは考えられない」と言葉をもらえると、社会の一員になれた様な高揚感がありました。
その日々はとても充実していました。ただシステムを作るだけではなく、「ユーザーに自ら届け、ありがとうという言葉をもらい、フィードバックをもらって、改善する」
このサイクルに私は夢中になりました。自身の成長と共に、社会への貢献を感じることができること。私の「ものづくり」の原点となりました。
「エンジニア」は企業の大きさや役職によって求められる仕事は変わります。
私はメガベンチャーにて1人前のエンジニアになるために努力を重ねていきながら、広い「ものづくり」のサイクルに関われるスタートアップを探していました。
その時に「医療関係の起業経験がある×エンジニアとして幅広い開発をしている」ということで声をかけてくださったのが川端さんでした。
当時のContreaは今よりも更に小さな組織だったので、副業であっても要件定義から関われることに魅力を感じ二つ返事で参加させてもらうことになりました。
同意書プロジェクトの立ち上げ
本業では大規模システムの開発を行い、副業ではプロダクトの上段の要件定義から参加する、充実した日々を過ごしていたある日、川端さんから正社員での参画を打診いただきました。
「同意書をMediOSで電子化するプロダクトを作りたい。その新規事業を引っ張っていってくれないでしょうか？」
私は将来プロダクトを作って独立したいと思っていたこともあり、1つのプロダクトを0から立ち上げる機会を求めていました。
このチャンスを生かそうと覚悟を決め、思い切って正社員として参画することに決めました。エンジニア兼プロジェクトマネージャーとしての業務が始まります
プロジェクトのゴール決めと要件定義
まず手をつけたのは要件定義となります。
「同意書を電子化する」という部分のみが決まっていましたので、医療機関様にヒアリングを重ねながら課題感や現状のフローについて情報収集を実施しました。
医療は全国民が触れる部分だと思いますが、実際に医療スタッフがどのような業務フローで行っているかを普段知ることは少ないと思います。
ヒアリングを重ねていくと、医療機関様としては日々膨大な同意書を1枚1枚スキャンして電子カルテに取り込んでいたり、同意書の保管のために倉庫を借りていたりする課題を知りました。
また、患者さまの同意書持ち忘れや入力ミスで再記入が必要になることもあり、業務を圧迫している一因であると知りました。
医療現場には様々なスタッフが密接に関わりあっています。システムを導入する際には現状のフローをどこまで変えないで運用できるかも、導入担当者はとても気にされていました。
私はその様な情報を整理し、プロジェクトのゴールを「同意書を電子化し、現状のフローから使い勝手を損なわずに紙固有の課題を解消する」と定義しました。
次に上記のゴールを実現するための、システム仕様を考え、簡単なデザインモックを作成しました。
法的遵守も重視する必要があったため、弁護士の方とも確認しながら詳細仕様を詰めていきました。
同時に医療機関様や社内でもデザインモックを元にレビューを複数回実施し、課題が解決されそうか、不要な機能でないか等を確認していきました。
Figmaのプロトタイプモードを利用することで、開発前でも本番に近い環境をデモすることが出来ます。
仕様書等の文章だけでなく、デザインモックを作って擦り合わせを行ったことで論点がブレずにステークホルダーとスムーズに合意を取ることが出来ました。
実際に課題が解決されるかどうかはフローに乗せて動かしてみるまでわからないと考えております。全員の合意を取るのに多くの時間を消費するのであれば、ある程度のところで皆の意見をまとめて切り上げることもプロジェクトの推進には必要なことだと思います。
設計と開発フェーズ
要件を固めたあとは、設計と開発に入っていきます。
設計フェーズで心がけていたこととしては、まずは最小限に作ろうということです。
大事なのはいち早く現場で検証を実施すること。受け入れられるのかニーズがあるのかを検証することです。
そのため、まずはフローを実現できる最小限の機能と画面のみを用意することとしました。
検証時には直接DBを操作するなど、設定画面を作らない工夫などを行いました。
画面と機能は絞りましたが、システムとしては中長期的な表現の幅のカバーは必要です。
特にデータベースのテーブル設計は変えると改修が大きくなるので、多少API開発に負荷がかかるとしても拡張性に耐えうる設計としました。
開発フェーズに入ってからは、スタートアップならではの柔軟さで業務委託や副業で手伝っていただけるメンバーを募集し、PJチームを組んで開発を進めていきました。
プロダクトが小さいフェーズだと、キャッチアップコストも少ないので副業メンバーも活躍しやすいと思います。
MVP完成と初回検証の実施
メンバーがスピーディーに開発を進めて下さったおかげでオンスケにて初期プロダクトの開発が完了しました。
さっそく協力いただけることになっている医療機関様に連絡し、完成したプロダクトを持っていく日取りを決めました。
医療機関の皆様に集まっていただき、目の前でデモを実施することはとても緊張しました。
実際に使ってもらう現場の方に向けての説明だったので、熱が入りながらも必死にプレゼンをしたことを覚えております。
スタッフの皆様にQRコードを読み込んでいただき一連の動作を実施いただいている際には、頼むからちゃんと動いてくれ、、！と祈りながら見守っていました。
結果としては、無事問題なく操作いただき「うんうん大枠良さそうだね」とコメントをいただくことができました。
開発前にデザインモックなどでイメージを擦り合わせられたことが大きかったと思います。
ただ上手くいくことだけではなく、実際にデバイスで触ることで新たな課題が発見されました。
いくつか実用的なフローに載せるまでの壁となりそうなフィードバックをいただきました。
主にスタッフが確認する画面の使い勝手の問題と、高齢者の患者さまが使うには入力のハードルが高いのではないかという点です。
スタッフの使い勝手においては情報の網羅性をとても気にされていました。
文字サイズを大きく余白を利用して画面の可視性を重視していたのですが、そのことよりも情報を詰め込む網羅性を求められたりと新たな観点を得ることができました。
高齢者の方が入力できるかどうかについては、私自身が一度試してみたいという思いもあり実際に患者さまを交えての検証をお願いさせていただくことになりました。
医療機関様にご協力いただき、複数名の患者さまにMediOSの電子同意書を利用いただきました。
高齢の患者さまの実施中の様子を観察させていただくと、私が想定していたよりも入力に手こずっており、時間がかかっていました。
私たちがスマートフォンで当たり前に行っている操作は、デジタルネイティブでない世代にとってはハードルが高い動作であることを再び感じることができました。
実施終了後に患者さまにヒアリングした際にも「どうすれば良いのかわからなかった」と言われたり現場スタッフの方にも「説明コストがかかってしまう」といったフィードバックをいただきました。ゴールに到達するには改善が必要だと感じ、打ちひしがれながら帰宅しました。
検証結果の精査と改善
社内に持ち帰り「より簡単に・よりわかりやすく」なるために社内のデザイナーとエンジニアとともに思考錯誤を繰り返しました。
デザイナーとも一緒に検証に行ったことで解像度の高い状態で、改善案を検討することが出来ました。
結果として、入力項目の簡略化や出力するファイルの表示項目を変更する改善施策を策定しました。
とにかくまず使ってみて、生の声からプロダクトの改善を積み重ねることの大事さを感じました。
二回目の検証の実施
上記の課題を解消した施策を持ち込み、二回目の本番検証を実施しました。
再び高齢の患者さまに利用していただきましたが、無事完了画面まで補助なしで操作していただけました。
現場スタッフの方にも「これならば高齢の患者さまでも問題なく利用出来そう。電子同意書の発行と確認も現状のフローに沿ってスムーズに実行できました。」とコメントをいただくことが出来て、プロジェクト発足当時のゴールを迎えられたとほっとしました。
患者様やスタッフが同意書に記入した文字がデータとして保存されることにより、履歴画面にて同意書のサマリ情報を表示できる様になりました。
内容を確認するスタッフの作業もより手軽になり、新たな価値を生み出すことができました。
まだまだ最初の段階ですが、広い「ものづくり」のサイクルを一つ回せた瞬間を感じました。
エンジニアが現場に行く意味
私は「ユーザーの課題を発見し、整理し、解決すること」がエンジニアの仕事の本質だと考えています。
例えばですが、職場にて単調な業務に時間を割いているメンバーを見つけ、その業務を自動化して喜ばれる様な経験がどんなエンジニアにもあるのではないでしょうか。
(例. 毎朝Excelに色んなシートから情報をポチポチ集めて資料作成している営業メンバーの業務をマクロを組んで自動化するなど)
まさに課題を発見し、整理して、解決する。エンジニアの本質だと考えています。
一般的には、例の様な小さな課題ではなく大きな課題を効率的に解決するために仕事が細分化されていると思います。
ただし私は、可能な限り発見・整理・解決のプロセスを分断しないことが課題解決の効果の最大化に重要と考えています。
なぜなら課題の発見・整理・解決の精度は密接に関係していると考えているからです。
Excelマクロの存在を知らなければ、ポチポチとコピペしている作業を効率化できると気づきません。
解決の手札を持っていなければ、課題と認識できないのです。
同様に文章化された課題を見て解決する時には、文章化されていない相手の本音・状況・求める基準を知ることができません。理論上は解決できているけど、現実的には使えない様なものが出来上がる可能性があります。
上記のことから、できる限りエンジニアも現場に行き続けられる体制は大事にしていきたいと考えています。
この記事を読んでくださったあなたへ！
その後電子同意書は無事正式リリースを実施し、引き続き現場のフィードバックを元に改善を進めております。
今回は電子同意書の立ち上げをお話しさせていただきましたが、弊社のMediOSはまだまだ沢山の改善サイクルを回していく必要があります。
この記事を読んでくださったあなた！もし上記の仕事を少しでも面白いと思っていただけたらお話しさせていただけないでしょうか！
開発もするし現場にもいく、厳しい声もあれば嬉しい声もある。その様な環境で一緒に切磋琢磨しながらプロダクト開発を進めてくださるメンバーを求めています。
他にも弊社には魅力的なメンバーが沢山います。
転職意欲がない状態でも気軽にお声かけいただけますと大変嬉しいです。
何卒！何卒！よろしくお願いします。
この記事が気に入ったらサポートをしてみませんか？