ヘンリーは今、何を作っていて、どのような開発をしているのか。VPoE 兼 VPoTの戸田 (
id:eller) さんに、プロダクトの説明から、開発体制、技術スタック、開発手法や文化までお話を伺いました。ポッドキャスト番組、ヘンリー理想駆動ラジオのエピソードから書き起こしたものです。よろしければそちらもあわせてお聞き下さい。
本エントリでは、カタカナの「ヘンリー」は株式会社ヘンリーを表し、アルファベットの"Henry"はヘンリーが開発しているプロダクトを表します。
—— 自己紹介をお願いします
戸田: 戸田ケンゴといいます。元々高校生の頃にフリーソフトウェア開発をやっていて、そこから国産ERPパッケージ開発の会社に就職して、そこで様々なチームの経験をしてきました。
そこの会社ではオンプレの製品を作っていたんですけど、それだと保守に限界があるなということに直面しまして、次はオンラインのサービスを作ろうと思ってたんですが、そこでヘンリーから声をかけていただいて。
HenryがオンプレではなくSaaSのサービスであったというところと、あと、前職ERPだったんですけど、今ヘンリーが作ってるものは医療業界のERPと呼んで差し支えないんじゃないかというぐらいの規模感なんですけど、そこで自分が今まで積み上げてきた経験であるとか肌感を使えそうだなって思ったことと、社会課題解決っていうのは元々自分も好きなのでそれができるっていうところで良いなと思ってヘンリーにジョインしました。
でも、その後やっぱりHenryはERPじゃないなとは思ったんですけど。
—— フリーソフトウェア開発はどういったものだったのですか？
戸田: 窓の杜さんとかで配布公開されてるような個人開発のソフトウェアのことですね。フリーっていうのは無料のイメージがあるかも知れないですけど、どっちかっていうと「自由」の意味で使っていて、ソースコードをzipで固めて配布してたりしてたんですけど、そこにソースコードを同梱して自由に使ってください、ソースコードを含めてみたいなことをやってました。
—— そうですよね。フリーソフトウェアと言うと厳密なOSSなのかなどの定義が曖昧になるところもあるのでお伺いしました
戸田: そうですね。私も最初は適当に作ったexeを配布してるだけだったんですけど、自分のいたHSP(Hot Soup Processor)っていう開発環境でソフトウェアを作るっていうエンジニアの界隈にYukiさんって方がいらっしゃって、その方がライセンスとかをソフトウェアに同梱みたいなことをやってらっしゃるんですよね。なんだこれって思って調べて、そういう考えがあるんだってなって、そっから先はフリーソフトウェア開発者ですっていう名乗りを使ってます。
HenryはERPじゃない？
—— ERPをやられていた経験を踏まえ、HenryがERPじゃないなと思ったのは、どういったところに理由がありますか？
戸田: ERPってそんなに使い手のこと考えてない、と言ったら語弊があるんだと思うんですけど、究極を論ずればBIとか、経営上のシミュレーションであるとか、やっぱその経営者向けに機能が向いていて、経営者以外に対する機能ってのは割と二の次になりがちだと思ってるんですね。データソースとしてエンドユーザーを見ていて、本当の顧客は意思決定者だっていう風潮がどうしてもあるなと思っています。
Henryが医療業界のERPかなって思ったのはやっぱりそのデータの根っこ、ERPであれば人事情報であるとか給与、ヒト・モノ・カネですよね、の情報を全部持ってるんで、今風に言うとプラットフォームとして機能するシステムなんですけど、Henryもやっぱり患者情報を持っているので、これもERPとして動くんじゃないかなって思ったんですよね。
患者情報を持ってるってのは重要だし、院内システムのプラットフォームとして今後プレゼンスを発揮する可能性は十分にあるなっていうのは当たってたんですけど、その視点が経営者、院長とかですね、に対して向いてたかっていうと、どっちかっていうとエンドユーザーの医師とか看護師とか、そういった方に対して向いてるなって思うことが多かったんですよね。
それでどこかのタイミングで、創業経営者の逆瀬川にそこの話聞いてみたんですけど、やっぱりエンドユーザーの方を大事にしてると言っていて。そういう意味では着眼点は違うんだなって思いましたね。そういう点で(Henryは)ERPじゃないと私は思っているところです。
—— ERPはEnterprize Resouce Planningの略なので、その名の通り経営者向けに事実を管理して計画を立てるためのツールという側面が強いですが、確かにHenryは実際の利用者のことも考えて業務体験を良くする所も考えているサービスでもありますね。
ヘンリーが作っているもの
—— だいぶ話が進んだんですが、そもそもヘンリーっていう会社は何を作ってるんでしたっけっていうところを改めてお伺いしたいです。
戸田: はい。一言で言うと医療機関様向けSaaSなんですけど、それだとちょっと語弊があるのでもう少し詳しく話します。まず、医療機関様が利用するSaaSなので患者様の情報であるとかを管理しています。さらに患者様に対して、こういう治療を提供しました、こういう検査をしましたっていう情報を蓄積して、だから、今日は例えば3000円払ってください、みたいな最終的な請求をする、金額を算出するっていうこともしています。
これは皆様患者としてお金を払うときは大体3割とか、子供の場合は100円とか、我々の負担額、患者の負担額と実際に病院がもらえるお金っていうのはかなり差があります。そこの患者に請求する金額を決めたりとか、その差額、外部機関に対してこの人にはいくらだけもらったんで残りをあなたから払ってくださいという請求するんですけど、そこの患者向けと外部機関向け両方のお金の流れとかも管理しているわけですね。
で、さっきSaaSとして完結してないというか完全なSaaSじゃないみたいな話をしたのはなんでかっていうと、検査とかをする上で院内にあるネットワークの中のシステムと連携が必要になると。例えばCTを撮るとかそういう検査をするときに、我々が作ってるHenry上でそれが完結するかっていうとしないんですね。こういう検査が必要ですっていう情報を他のシステムに転送して、そこのシステムで検査した結果をHenry側に差し戻すという処理が走るんですけれども、そういたことをするためにはこの院内ネットワークとSaaSの間を取り持つエージェントのようなものが必要になってきます。どういうことかというと通信先のシステムがインターネットに繋がってないってことですね。インターネットにAPIがあるみたいな想定をまだできていないので、院内ネットワークに対して例えばファイルを作って、そのファイルを見に来てくださいという形の連携をしています。ので単なるSaaSだけではなくて、その院内システムで動くエージェントの実装提供も含めてやっているっていうところでSaaSとしては完結してないかなって思ってます。
—— エージェントは我々がローカルアプリとか呼んでるやつですね。 最近だと、医療機関とかにマイナンバーカードを読み取るための機械がたくさん置かれるようになったと思うんですけど。その裏側ではオンライン資格確認っていうやつが動いていて、マイナンバーカードに紐づいた保険情報が有効か、その人がちゃんと保険料を納めてるかなどを即時確認した上でちゃんと3割負担になるようにする仕組みがあって、そこの連携みたいなのもあったりしますよね。
戸田: そうですね。込みですね。あの顔をピッと読み取る機械は、通信をしてその結果がやっぱりファイルで保存されるんですけど、そのファイルをやっぱり我々のシステムが、先ほどおっしゃってたローカルアプリですね、それが読みに行くっていう形で連携をしています。
—— 僕らの仕組みっていうのは電子カルテ病院向けの電子カルテと言うこともあるんですけれども、電子カルテっていうのは本当にごく一部で、そういう事実を記録する部分に加えて、データをどう扱うか、取り込むかみたいなところとか、支払いをする、いわゆるレセプトって言われるところとか、業務を回すためのオーダーって言われるところに分かれるような形になっていますよね。その辺りちょっと解説してもらっていいですか。
戸田: はいそうですね。電子カルテって一言で言ってもいろんな機能があるんですけれどもカルテというからには患者さんの情報を蓄積する機能がまずあります。これはメディカルレコードなので電子的に記録するという意味でEMRと呼んだりしています。
そこから、例えば患者さんが検査したいですと、CT撮ります、超音波やりますっていうときに、医師の方がそれをオーダーという形で担当する部署に投げると。この患者さんの血液検査よろしくと投げると。これがオーダーと言ってますね。そのオーダーをもとに検査する人が、それを受け取って、あ、この患者さんの血液ね、はいはいと、血液抜いて、それを検査に回すということをやっています。
今EMRとオーダーを説明してもう1個レセプトですね。レセプトというのは今回この患者さんにはこういう検査をしたこういう治療をしたからいくらですと、国が値段を決めてまして、そこから算出するということになります。国のルールだけじゃなくて地方自治体のルールが絡んできたりとか、何か障害者手帳のようなものをお持ちの方、そういうものをお持ちの方はそれも含めて考慮した上で、まずトータルでおいくらなのかを決めると。そこからさらに3割負担1割負担、そういったルールから負担額を決める。そこまで含めてレセプトコンピュータですね。で、一ヶ月に一度、外部機関に対して申請して、その残りのお金をもらうというのがレセプトを使って医療事務という方がやってらっしゃるんですけども、その業務の流れを支援するのがレセプトコンピュータですね。
ヘンリーのシステム構成
—— ありがとうございます。この辺が如何に複雑かは話せばきりがないんですけれども、大体どういったものを使い作っているかはご理解いただけたんじゃないかなと思うので、次はヘンリーではどのようにそれを作ってるのかをお伺いしたいです。
戸田: はい。うちは一体型クラウドネイティブですっていうふうに言ってます。何のこっちゃなんですけど、一体型というのは今申し上げたEMRとかレセコンとかオーダーのシステムが全て一体になってますよということですね。お客様としては面倒な連携のための設定であるとか、システムの切れ目とかを意識することなく利用することができます。
先ほどプラットフォームでもあるって申し上げたんですけど、メインで動くのってこういうの大事だと思うんですよね。例えばGoogleのGmailとGoogleドライブが、設定にこことここのパラメータをいじって、ここにトークンを連携登録してくださいみたいなことやってたら、多分皆さんそんな活用しないと思うんですよね。そこはやっぱり一体型だからGoogleとして一つのプラットフォームを提供してるから、Gmailに対してファイルを添付するであるとか、Gmailに受信したメールにあるフォルダをファイルをGoogleドライブにコピーするとかそういうことがやりやすくなって、弊社もそれと同じでこっから先がEMRでこっから先はオーダーシステムだからとかを考えずに、シームレスな連携ができる。これが一つ強みです。
もう1個はクラウドネイティブと申し上げたのは、レセコンとかですね。レセコンは非常に長い歴史があります。競合もたくさんいるんですけれども、彼らは、クラウドネイティブではないと。我々こそがクラウドネイティブだというのを強みにしております。それはレセコン以外もそうですね。電子カルテであるとかオーダーシステムであるとかも、全てクラウドネイティブに特化、クラウドネイティブに実装しているので、ランニングコストであるとかメンテナンスコストっていうところでかなり競争力を高く保つことができています。
—— 従来のシステムだと、カルテとレセコンが分離されてるところは結構多かったりします。医療事務の人が紙のカルテを見てレセコンに転記して打ち込んだり、電子カルテになっていてもシステムが分かれていて電子カルテからレセコンに取り込んだりという作業が発生する。でもそこは一体であるべきだと考えて、オーダー・レセコン・電子カルテ含めて一体型の体験をヘンリーは提供しているところがありますね。
クラウドネイティブの強み
—— クラウドネイティブはセールス文言的な言い回しでもありますが、つまるところ、いわゆる普通のSaaS的な、1つのクラウドシステムの中に複数のお客様が同居するモデルで開発していますよね。そこが実は病院向けの電子カルテベンダーとしてはユニークで、強みになっているという理解ですが、それで合ってますか？
戸田: はいそうですね。クラウドネイティブだとスケールイン・スケールアウトしやすいっていう点もありますし、今おっしゃってたマルチテナンシーを実現しやすいってのはありますよね。
あとシングルバージョン、1つのバージョンだけなんで、オンプレ開発やってたときはこのパッチを出荷が必要だってなったときに、それぞれのメジャーバージョンマイナーバージョンパッチバージョンに対してどうやって当てるかみたいなことを考えてたんですけど、シングルバージョンだとそういうこともいらないので、そういうところで保守コスト、我々のコストは最終的にはお客様の金額に跳ね返るので、そういうところで優位性を保ってると思ってます。
ヘンリーの技術スタック
—— 他に今のシステム面や技術面がどういう感じなのかをお話いただいていいですか？
戸田: はい。実装技術についてはおそらく皆さんの考えてるSaaSと大差ないですね。
フロントエンドはReactですのでTypeScriptで書いていて、それをCloud Runとかにデプロイしている感じですね。バックエンドについては今Kotlinを採用しています。先ほど言ってたローカルアプリも含めてKotlinですね。なので弊社は今TypeScriptとKotlinが主力の2つになってますね、言語としては。
その間はGraphQLで通信をしていて、GraphQLをサーバーサイドで受け取って処理をしてフロントエンドに返すという実装をしてます。そんなに突拍子もないところはないのかなと思いますね。
帳票系が多いので、帳票と言っているのは例えば処方箋であるとか、もちろん領収証もそうですし、あと領収した内容は何が何点だったとかそういうのとか、お薬手帳に貼るシールであるとか、そういう印刷系が結構しっかりあるので、そこは今Node.JSで作っていたりしますね。
—— あの辺もPDFを出すというよりもHTMLを出してCSSで罫線とかを頑張って書くみたいになっているものが多いという理解です。
戸田: そうなんですよ。ちょっと記憶がすぐには出ないんすけど確かCSSがA4とかメジャーな用紙のサイズには対応してるんですけど、お薬手帳のサイズには対応していなくて、そこで苦労したって覚えがありますね。
—— その辺難しいですよね。ただ最近のCSSの表現力めちゃくちゃすごくて、普段私たちが病院でもらう、お薬手帳のシールとか処方箋などがHenryで綺麗に出力できるようになってるから、そこは驚きですよね。
戸田: そうですね。うちも結局は成功してますからね。
モジュラモノリス開発に移行している話
—— マイクロサービスからモジュラモノリスに変えたいという話題を持ってきていただいてますが、これはどういうお話ですか？
戸田: 最初はレセプトコンピュータがやっぱり特性として非常に特殊だったので、こいつを固有の独立したマイクロサービスをしたいと。で、電子カルテの部分からこれを呼び出すという形で考えていたんですけど、実際に走ってみて、このやり方だとやりにくいということがわかってきたと。
渡すデータが大きくなったりとか、レセコンの世界の概念に詰めて渡すっていうのがやっぱり現実的ではなかったりとかいろいろあったので、その考えをやめて1回全部モノリスにして、そこからモジュラモノリスにしていこうと。つまるところ、そんなに綺麗に切れるものではなかったっていうのもありますし、切ったときのAPIの扱いが生産性高いやり方ではなかったなって反省したので、そこをモジュラモノリスにしたいなっていうところが今ありますね。
そのあたり、これについては細かく技術ブログに書いたので、そっちも併せてご覧いただけると嬉しいです。
—— そうですよね。そこは進んできていて、元々リポジトリも分かれていたところを今はモノレポにして開発を並行で進められていますね。
戸田: そうですね。
ヘンリーの開発体制
—— そういうシステムを、どういうチーム体制で開発しているかをお話いただいていいですか。
戸田: はい。内部でさらに細かくわかれてたりはしますが、今はおおむね2つのチームが並行して開発してるというところです。
チームにはプログラムを書くエンジニアと、元々医療事務として活躍されていたなど、そのドメインに詳しいドメインエキスパートの方、あとはQAの方も、全て込み込みのチームがあって、そこでイテレーションを回してます。チームに寄るんですが大体1週間から2週間のイテレーションなので、遅くとも2週間に1回は新しい変更が出ていってるっていう状況ですね。
コミュニケーションをどうしてるかっていうと、基本はスクラムだと思って良いと思ってます。イテレーションの最初にこのスプリントで何をやるかっていう話をして、毎日そこに向かって透明性の確保であるとか何か起こったときにどう適応していくかっていう話をチームによって話してるっていうところですね。基本はスクラムって言ったんですけど、実行が難しいものでもあるのでまだ完全だとは思ってなくて。最近もスクラム詳しい方とかとスプリントレビューちゃんとしたいなとか、みんながより積極的に話せるようにしていきたいとかそういう振り返りはしてますね。
—— 2チームの人数ってどれぐらいなんですか？
戸田: 大体2つのチームそれぞれ15人ぐらいですね。なので、デイリースクラムとかは結構重くなってきてるなっていうのが今で。で、チームを分割したいねって話を並行して議論を進めてたりしますね。上手くいけば今月か来月ぐらいには今2つって申し上げたんですけど、3つぐらいになるんじゃないかなという感じです。
—— そうですね1つのチームが20人を超えるぐらいになってきてるので、さすがに分割しないとってなってきていますよね。
戸田: チーム内のコミュニケーション難しくなるんですよね。まとめることの利点ももちろんあるんですけど、ちょっと行きすぎたかなって思ってるので揺り戻したいみたいな感じですね。
—— 多分僕たちとして最適なチームサイズがどれぐらいなのかは模索した方が良いですよね。それこそチーム内にQAの方や、ドメインエキスパートが複数人いるのが特色だと思っているので、そうするとどうしても一般的な開発チームよりかは少し多めになるのかな、とは感じています。
戸田: 我々の対峙しているドメインが医療ドメインで特に今病院なんですけど、病院の皆さんが、元々多彩な役割をお持ちなんですよね。特に医療事務の皆さんなんですけど。
その医療事務の皆さんの業務フローに寄り添うって考えたときに、先ほど申し上げたその点数の計算、あと負担額の計算、あと受付業務、そういったものが全部医療事務という名のもとにガッと入ってくるので、医療事務の皆さんを助けようと思うとチームがそれだけ大きくなってしまう。
それで開発領域を分けたときにドメインエキスパートの皆さんの多岐にわたった知見をきちんと活かすことを考えると、兼務させるのかとか。このチームに一旦入れるけど、あのチームも助けてほしいみたいな悩みが出てくる。ので、チームの割り方は答えがないっすねって思ってますね。
—— チーム分割は試行錯誤した方が良さそうに感じていて、ドメインをきっちり分割しすぎるのも危ない。どこが境界なのかを調整するためにも、モジュラモノリスとかでやった方が取り回しはいいのかなと思ってる部分ではあります
戸田: そういう面は確かにありますね。
ヘンリーの開発の魅力
—— ヘンリーの開発の魅力や面白いところはどういったところだと考えられてますか。
戸田: 3つあると思ってます。
1個目が非同期コミュニケーションが中心になってるなと思ってて、ヘンリーはフルリモートの会社なんですね。一応五反田に拠点はあるんですが、そこに毎日出勤してる同僚もいるんですけど、多くの従業員は自宅あるいはそれに準じた場所で勤務しています。ので、ミーティングの議事録がきちんと残るとか、あと新しい方が来たときのオンボーディングとかもちゃんとドキュメントとして整理されてるとか、そういうところがきちんとしていて、柔軟な働き方ができるなって思ってます。
周りに目を向けるとお子さんいらっしゃる方とか、介護などお忙しい方とかそういう方もいらっしゃるんですけど、ヘンリーだとそういった方でもしっかり働ける、能力を十二分に発揮いただける、っていうのはあるなって思ってて、すごくいいところだなと思ってます。
もう1個は、今一応アーキテクトっていうチームはあって、そこでアーキテクチャを考えてるんですけど、彼ら以外がアーキテクチャを考えなくていいのかっていうとそうではなくて。ちゃんとADR (Archtecture decision record) 書いて、こういうのをやりたいって全体に発信すると誰でも採用する技術とか、アーキテクチャとかの仕様の変更とかについて議論ができる提案ができる土壌があると思っていて。各チームが、自分で必要だと思ったことをやり切るっていうことができる。
今、開発組織は大きくなってると思ってて、さっき言っただけでも30人チームだったんですけど、それにSREとかアーキテクトとか、考えると40人ぐらいいるのかな。その規模でこういった、それぞれの裁量に委ねた判断ができてるのは良いことだなと思ってます。
これが行き過ぎると何が何だかわかんなくなっちゃうんで、ちゃんとADRであるとか、現状のスナップショットを理解して、対外的にうちの判断はこうですとか、うちのポリシーはこうですとか、例えばうちのAPIを叩くときにはここういうところに注意してくださいとか。そういう一貫した説明をするっていうのが1つVPoTとしての私の仕事でもあります。
あと3つ目がですね、去年から公共政策チームっていうのができました。元厚生労働省の方にお越しいただいて、そこで国とか医師会とかそういう関係者と喧喧諤諤議論しつつ、理想の医療とは何かを中長期的な視点で考えることができるようになったんですね。これすごくいいなと思ってて。我々、所詮はスタートアップなんで、社会的な影響力は吹いたら飛ぶようなレベルしかなかったんですけど、公共政策チームが動き始めて、やっと我々国民の生活を良くするシステムみたいな視点に立ったアクションとか、協働ができるようになってきていて、すごくいいなと思うんすよね。
システムエンジニアやってると、どうしてもデータになってないもの、データの向こう側に対する無力感ってあると思うんですよね。そこに対して、IoTだとかセンサーとかでその壁をできるだけ向こう側に押しのけようっていうことをテクノロジーで解決はできてきてるんすけど、それでも届かないところってあって、この公共政策っていうのは、その壁の向こう側を作りに行くやり方としてかなり有効だなっていうのはこの1年で思っているとこです。
—— 非同期コミュニケーションとか、現実問題として、もう本当にお客様も全国に散らばってますし、働いてる人も北海道から沖縄までいるみたいな形だし。戸田さんも今お住まいどちらなんでしたっけ？
戸田: 私は今中国上海におりますね。
自分で設計して作るところまでやる
—— ヘンリーは言われたものをそのまま作るというよりかは、ドメイン知識を理解しながら設計して作るまでの工程を一貫して任せられるエンジニアが多いのかなと感じます。
戸田: これ今後大事じゃないすか。エンジニアのキャリアとしても。ここ数ヶ月で急にAIが開発の現場に入れるようになってきていて。そのときにコードを書きたいだけとか、そういう人じゃなくって、自分できちんと考えを持って、こういうドメインを解決するためにはこういう仕様がいいとか、こういう使われ方をするんだからここのパフォーマンスは考えなきゃいけないとか、そういうことに気を配れるプロンプトを書けるというか。人っていうのが今後大事になると思ってて、そういう意味でもヘンリーに必要なエンジニアはこういう時代に即してるなと思います。
公共政策という武器
—— 公共政策、元官僚の方がご入社いただけるなんて結構信じられないみたいなところがあります。その分部さんのインタビューもnoteにありますけれども。医療の世界ってすごくルールが複雑だし、歴史的な結果としてそうなってるから仕方ないけど、やっぱイケてないところはたくさんあるので。そういった上から降ってくるルール、例えば診療報酬の点数計算を粛々と実装してるだけだと絶対追いつかない徒労感を感じる部分がある。なので、ルールメイキング側に回って、マスタや元データを綺麗にするのをやってかないといけない。そういったルールメイキング側に回れるチャンスが出てきたのはワクワクするところではありますよね。
戸田: そうですね。我々しかクラウドネイティブな実装はいないみたいな話をさっきしましたけど。それって歴史のあるルールであるとかやり方に業界全体が根ざしてしまっている状況があって。それに対して公共政策側から、今のやり方ももちろんアリですが、クラウドネイティブにすることで例えば業界全体のコストが下がる、つまり医療費が削減できる、そうなるとそのやり方もアリなんだ、っていう発見を業界全体に持ち込めると思うんですよね。
それが大事だなと思っていて、そういうことがやりたいから今までのやり方の延長ではなくて、今までとは違うやり方を実現したいからスタートアップは生まれるんですけど、実現の手法って何？って考えたときに単なるエンジニアリングだけじゃなくて、公共政策っていう武器が持てたのは我々が社会的課題を解決する非常に重要だなと思います。
—— 個別最適をしてノウハウを隠して囲い込みをするような戦い方をしているベンダーが多い中、ヘンリーは逆にオープンにやることでイニシアチブを取ることを強みにしたいのかなと感じました。
ヘンリーの開発の課題
—— 色々良い所を語ってきましたが、今の開発の課題はどういったところがあると考えていますか?
戸田: 今、話したやつの逆なんですよね。なんで今まで既存のベンダーはこっちに来なかったのかっていう話だと思っていて。1つは何かを開発しようと思ったときにスコープがめちゃめちゃでかくなるんですよね。先ほどの医療事務の皆さんの業務が多岐にわたるっていう話もしましたけど、他にも例えば、国のシステムの変更、電子処方箋であるとか、オンライン資格確認ですとか、っていう話が出たときに、ここだけ実装するみたいな話にならない。
電子処方箋やります、となったら、まずはオンライン資格確認ネットワークに接続ですね、みたいな。そういう制約、何かをやろうと思ったときにいろんなものをずらずらっと釣れてきてしまう。ので開発のスコープを小さくできない。スコープを小さくするのはスクラムに限らずアジャイル開発の基本で、コントロールできる要素としてのスコープは重要だって考え方があると思ってて、そこに限界がすぐに来ちゃうのは難しいところだなと。
アジャイル自体は正解だと思ってるんですよ。クラウドネイティブの日本向けの病院さん向けのシステムって本当に世界で我々しかやってない、完全に前人未到なので。大きなリスクを少しずつ切り崩せるアジャイル開発が向いてるのは疑いてないんですけど、それを実装する上でスコープを小さくすることが非常に難しいなっていうのは思ってます。これをどうやるかっていうのは1個悩みだと思ってます。
これまでの多くの既存ベンダーはスコープが大きいものを小さくするために、例えば囲い込みですとか、クローズドにするとか。あとは閉域網ですかね。インターネットに繋いだ方が便利だしコストも下がるんだけど、そうするとサポートが大変だからとか、責任が取れない部分が増えるので、スコープを小さくする意味でインターネット繋がないでくださいと。Windowsもアップデートしないでください。アップデートした場合の動作保証できませんっていう方向になっちゃってたと思うんですよね。
そこを我々としては、インターネット、他のウェブサービス同様に、一番安全なOSの更新であるとか、定義ファイルの更新であるとか、時刻合わせとか、そういう我々が日常生活で普通に使ってるものを診療の場、医療の場でも普通に使っていただいて、少ないコストで生産性を上げていただくっていう未来を実現したいなとは思ってます。
—— レセコンは医療事務さんだけのシステム、これは看護師、医師だけのシステムとか、スコープを小さくするためにそういう分け方をしてしまっていたことはあると思うのですが、そうではなくてトータルで価値提供するにはどうすればいいかを考えたいし、そこが難しいところですね。
戸田: そうですね。院内システムも歴史的にまずレセコンだったんですよね。医療事務の方のエキスパートシステムとしてのレセコンが成長した後に、オーダーのシステムであるとか、電子カルテのシステムみたいのがあった。これは法律上の制約っていう側面が大きかったんですけど、それを再整理しないままここまで来てしまった結果、そのスコープの小さい3つ、4つのシステムを組み合わせて使うって発想になってしまっていたので、そこは我々が再整理できてるのはすごくいいなと思いますね。
趣味や休日の過ごし方
—— だいぶ仕事の話ばかりしてきましたが、戸田さんは休みの日とかどう過ごされたりとかしてるんですか？趣味とかあったりされるんですか？
戸田: 子供が日中ハーフで普段は中国語で学校に通っているので、土曜日は日本語を学ぶ時間にほとんど充ててますね。あとはできるだけいろんな経験させたいので、サッカーに行くとか博物館行くとか。その都度その都度いろんなところに連れてったりとかして、それで割と土日潰れてますかね。ので、土日の使い方で言うと子供とどうする、やり取りをするところがウェイトとしては大きくて。
自分の頃って宿題とか少なかったし本とかも図書館にこもって自由に読んでたみたいなところがあるんですけど、自分の子供だと、まず宿題が多いんですよね。家で漫画適当に読んでるとか、それこそ少年ジャンプを買ってきて読んでるみたいなところが全然イメージとしてないんですよね。
勉強をしっかりやらなきゃいけないし、さらに今週ちょうどAIを使ってですね、マインドマップを書きましょうみたいな宿題も出てきていて。いや本当に小学生のうちからいろんなことやってんなっていう。そこは自分の延長で考えちゃうと駄目なんだろうなってすごく思ってるんですよね そこが、趣味というか休みの日の過ごし方のウエートとしては今一番でかいっすね。
—— 僕も最近子供とサッカーしてて、なかなか自分だとサッカーとかしなかったけど、新しい体験を僕もできてるなってのは思ったりはしています
戸田: そうですね自分の子供とは思えないぐらいサッカー好きで、ウチも。自分はもう球技全般駄目なんすよ。駄目っていうのは単純に好きになれなかったっていうだけなんですけど。それの延長で子供のことを最初は見てたんですけど。全然サッカー大好きで。よし行くかっていうとすごい喜びますからね。面白いっすね。かとそう思うとなんか俺っぽい〜って思うときもあるんで。
—— それもありますね。子供に時間を使うっていうのは人生の中で、いい時間だなっていうのを僕も最近思うようになりました。
戸田: そうですね。
ヘンリーで働く人
—— ヘンリーにはどういう人がいて、戸田さんはどういう人と働きたいと思っていますか？
戸田: 一言だとプロフェッショナルだと思ってて。やりたいことがあるというか、きちんとお仕事ができるというか、そういうプロの方とお仕事したいなと思ってます。経営も採用ちゃんとやってるなと思ってて、自分より強い人を採用するっていうのは大事って話あるじゃないすか。あれができてるなと思ってて。自分の理解できることしか言わない人しかとらないとか、そういう採用ではなくて、こういうプロを取ってる。あとはカルチャーマッチですね。ちゃんとやってるなって思ってて。なので自分の働きたいプロフェッショナルが採用されてくる会社だなとは思ってます。
—— プロフェッショナルであることは大事ですね。いろんなプロフェッショナルがいる会社でもあるので、医療ドメインの方とか、自分の専門性に誇りを持ってる方であれば、他の方の専門性とかプロフェッションに敬意を持ったりもできるんじゃないかなと僕も思っているので、そこも大事なところですよね。
戸田: そうですね。先ほど申し上げたようにリモートで働いてるから、相手を舐め腐ったようなというか、そういう仕事の働き方もやろうと思えばできちゃうと思ってんですよね。
あるいは、その相手を信用しない、何かこの戸田ってやつよくわかんないな、みたいな仕事の仕方もできるはずだと思ってて。でもそうじゃなくて、お互いのプロフェッショナルを信じて尊重した上でコミュニケーション取ってくれる。オンラインだからってコミュニケーションをさぼらないとか、貢献することをさぼらないというかそういうところがきちんとできてる従業員ばっかですごいなと思います。
—— そういうオープンマインドを持ってる方も多いとも書いてもいただいてますけど。
戸田: そうですね。何かわかんないな、ってなったときに「1日やってましたけど駄目でした」ってなるんじゃなくて、SlackやNotionとか何かで分かりそうな人をメンションをしてこれどういう意味ですかとか、なんでこのコード変更したんでしたっけ、とかっていうのがポンと言える。言うこと拾うこともできるのは大事だなと思ってて。これってプロでなきゃできないのもあるんですけど、恥ずかしいとか怖いとかっていう自己防衛機能を意図的にオフしないとできないことだと思ってるんですよ。
私もいろんな人を見てきたっていう感じじゃないんですけど、それでも、こういうのが苦手とか怖いとか、面倒くさがる。それをやれば10分で解決するとわかっていても面倒くさいから30分自分で調べちゃうみたいな人は絶対いると思ってて。そういう形ではなくてオープンマインドで、誰からも怒られないって分かっているし、聞いた方が早いし、早く解決した方が顧客のためになるから、良し聞いちゃえって聞ける。そういうところはすごくいいなと思います。
—— それはそうですよね。これから僕らも100人超えてくるぐらいの規模になるし、新しい方だと遠慮が出ちゃうところがあるので、それでもちゃんと聞ける雰囲気は大事にしたい。信頼関係を作るのが大事なのかなってのは思っています。
戸田: 自分に照らしても前職で社員番号は1000何番とかだったんすけど、それでこのコードよくわかんねぇな、誰が書いたんだと思ったら社員番号2桁の方だったりして、そのときにその2桁の方にすいません教えてくださいって言えるかって話ですよ。やっぱ難しかったですね、当時でも。
そういうことが難しいとわかってるけど、その方がメリットあるんだからって恥ずかしさとか怖さ、面倒くささっていうのを、壁を乗り越えてアクションできるオープンマインドがあるってのはヘンリーの従業員のすごいとこだと思いますね。
戸田さんにとっての理想駆動
—— ヘンリーは理想駆動というのを大事な行動指針の1つとして挙げていますが、戸田さんにとっての理想駆動っていうのはどういったものですか？
戸田: 自分は理想駆動はイノベーションだと思ってます。なんで理想駆動やってるんだって考えたときに、社会的な課題を解決したいっていうのが根っこにあると思うんですよね。今までのオンプレのやり方であるとか、閉域網のやり方、今までのベンダーの普通のやり方ではなんで駄目なんだっけって考えたときに、そこは当時の理想と今の理想は違うから、今の理想を大事にして考えたときに、違う方法をやった方がいいなと。その方が医療費も削減できるし、お客様の業務効率も上がるし、セキュアにもなるし、いいことずくめだよね。そのための障害ってめちゃめちゃあるんですけど、理想を掲げてそれを大事にすることで初めて社会課題に向き合えると思うんですよね。
我々はスタートアップであって破壊的イノベーションをやる存在なので、初手の理想駆動ってのはめちゃめちゃ大事だと思ってます。もちろんクリニックさんとか病院さんとか医療業界側がやるっていうことも大事なんですけど、我々は言葉悪いですけど部外者なので、外部からこうした方がいいんじゃないですか、とか話をしたりすると、参考になる、そういう考えもあるんだ、みたいなことあると思うんですよね。最近もお客様がおっしゃってたんですけど、ヘンリーのプロダクトを入れることで、ヘンリーの考え方であるとか、クラウドネイティブな考え方が病院に輸入できてみんなの刺激になってるって話をされてたんですけど、まさにこういうことが外部の我々が理想駆動でイノベーションすることで、医療業界に与えられるポジティブな影響だと思うんですけど。そのためにもやっぱり初手は理想駆動だと思うんですよね。
理想駆動ってのはイノベーションだし、理想駆動であろうとすることで、社会課題を解決することにも繋がるし、エンジニアとしての自分の存在意義証明というか、ちゃんと仕事したなと思えるときが来ると思うのでそういう意味でもとても大事だなと思ってますね。
—— AIによって開発が変わってきているけど、既存のエンジニアが古い開発のやり方に慣れてしまっている分、なまじ適応できないみたいな話があったりします。それと似たような話で、僕らのヘンリーの文脈だと、既存の医療機関さんの既存の働き方をちゃんと理解して敬意を示しつつ、1番いい形を理想から逆算して、電子カルテを再発明して提示するみたいなところやっていきたいのかなと思っています。
戸田: そうですね。議事録の取り方とか1つとっても、今だったらこうできるのにっていうのは結構あるんすよね。議事録もそうだし、会議体の開催とかそういうところも含めて。もちろん今までの経緯には、きちんと敬意を払う、理解するのを踏まえた上で部外者である我々が異文化を持ち込むことは重要なんだろうなと思ってますね。
まとめ
インタビューいかがだったでしょうか？引き続き、理想駆動ラジオからの書き起こしを掲載していければと思っています。
本エントリーを読んで、ヘンリーの採用に興味を持った方は是非ご連絡ください。
jobs.henry-app.jp
こんにちは、ヘンリー技術広報ギルドです。
ヘンリーでは、技術広報が好きだったり興味のあるエンジニアと人事や広報に関わる有志メンバーで技術広報ギルドを結成し、イベントや発信の企画を行なっています。
id:nabeop
