こんにちは。ヘンリーでエンジニアをしている agatan です。 私は現在医事会計チームに所属し、医療事務の皆様が使う会計システム（レセコン）としての側面について Henry の開発に携わっています。
日々開発をする中で、「デリバリーが3倍速ければいろんな問題が解決するのになー」と考えていることがよくあり、そのための障壁や打ち手を考えるために現状の開発の課題感を整理していました。 実はこれはヘンリーのソフトウェアエンジニアリングの向き合っている難しさ（とそこに挑戦する面白さ）の芯の一つなのではないかと思い、せっかくなので記事にしてみることにしました。
（弊社の行動指針に「ドオープン」（自身の考えを積極的に共有する）というものがあるのですが、同僚から「もっとこうするべきだという考え方を出していくのがリーダーシップですよ」とドオープンにフィードバックされました。この記事は、その通りだなと思って社内ブログに書いた記事の外部公開版です。）
私たちが開発しているレセコン一体型電子カルテ「Henry」は、複雑な医療保険制度や診療報酬制度に対応しながら、医療現場の業務を支えるプロダクトです。この複雑さゆえに開発は非常に挑戦的ですが、同時にエンジニアとして成長できる魅力的な環境でもあります。 この記事では、そんな特殊かつ奥深い領域での開発課題と、それに対してどのようにアプローチしようとしているのかについてお伝えします。 私たちが日々格闘している課題の本質と、それを解決するための取り組みを知っていただくことで、ヘンリーでの開発の面白さを感じていただければ幸いです。
ここで述べる内容は、あくまでもヘンリーの製品開発の一面に過ぎません。医事会計システムのなかでも複数の側面がありますし、電子カルテ（臨床）側のチームではまた違った課題と挑戦が複数存在しています。 他の側面に関しては、下記の記事を始めとして、ヘンリーエンジニアブログをご覧いただければと思います。
製品開発の構成要素とその課題認識
私たちの製品開発は、ディスカバリーとデリバリーという構成要素から成ります。ざっくりした説明ですが、ディスカバリーは「何を作るべきか」を見つけるプロセスで、デリバリーは「それを実際に作る」プロセスです。
複雑な製品開発における課題は、ディスカバリーの課題として注目されることが多々あります。 ヘンリーにおいても同様で、より多くのロール（お客様を含む）が複合的に関連するプロセスでもあり、ディスカバリーの課題感を感じる人や課題解決に動く人も多くなりやすい傾向にあります。
事実として私たちの製品は、専門性の高い複数の専門職の方々が相互に作用し合う複雑な業務フローを理解する必要があり、ディスカバリー難易度は非常に高いですし、確かにそこに重要な課題はあります。 このあたりは、代表の逆瀬川も記事にしている通り、全員が向き合う価値のある重要な要素です。
最近のソフトウェア開発界隈では、エンジニアもディスカバリーに積極的に関わるべきという流れが強まっていますが、あえて私はソフトウェアエンジニアとして、「デリバリー自体にも大きな課題があり、それに真剣に向き合うことが重要だ」と考えています。
一般的に言っても、デリバリーに一切の課題がない開発現場などありえませんし、デリバリーに課題があるとしてそれを解決できるのは主にエンジニアの役割です。 ディスカバリーへの関与も重要ですが、その前にデリバリーそのものの改善に向き合うことが大切だと考えています。
（もちろん、この手の課題は複合・相互的なものであり、どちらか一方しかアプローチできないものではありませんから、二者択一でどちらかに責任を押し付ける必要はありません。私自身の実際の業務としても、ディスカバリー的な領域に関わっていることのほうがむしろ多いくらいではあります。）
デリバリーの課題は速度
デリバリーの課題とは、端的に言えば「速度」です。
バグや障害発生率も当然課題としてはありますが、多くの場合これも速度によって解決可能だと考えています。 速度が遅ければ、スケジュール逼迫によるQA不足や考慮漏れで障害が発生することは想像に難くありません。 さらに、速度を向上させるための施策は、概ねバグ・障害発生率にもポジティブな影響を与えます。（もちろん、適切な方法で実施した場合という前提ですが。）
デリバリーが3倍速くなるとどうなるか？
3倍速のデリバリーが達成された世界を想像してみます。（3倍という数字に厳密な意味はありません。直感的に理解しやすい数字として挙げています。）
まず、会社全体の運営として不確実性が大幅に下がります。「あの機能がいついつできるはずだから〜」という計画を立てて行動することは、我々のようなスタートアップでは必要なことですが、単純に開発が遅ければその不確実性は高くなります。
当初の想定通りのスケジュールですべてがうまくいくことはそもそも珍しいわけですが、もしこれが3倍速で開発できるなら、開発の不確実性が下がるタイミングもぐっと手前になり、計画の信頼性が高まります。
また、ディスカバリーもより積極的な探索が可能になります。「試してみる」ことのコストが下がるため、より多くの仮説を検証でき、結果的により良い製品を作れる可能性が高まります。
顧客からのフィードバックをもらえるタイミングが3倍早くなればどうでしょうか？間違ったものを作ってしまったとして、根本的な修正を行うコストが3倍低かったらどうでしょうか？
もちろんそれでも事前検証の価値は依然として高いわけですが、検証方法や深さなどにより幅広い選択肢が生まれることは間違いありません。
そして、当たり前ですが、お客様により速くより多くの価値が提供できるようになります。ひいては社会にもです。
3倍速くするには？
どうしたら3倍速くなるでしょうか？
単純に「とにかく手を速くたくさん動かす」「とにかく人を増やす」ことでは、たぶん3倍速くはなりません。ソフトウェア開発では人月の神話といって、人が増えても必ずしも速くならないことは一般的に広く知られています。
質とスピードの考え方も重要です。保守性が高くなければ、継続的なソフトウェア開発で速度を出し続けることはできません。
今のヘンリーの開発について私が思う改善ポイント（の一部）として、以下のようなものがあります。
- 構成要素（「機能」とか「データ」）の混線・依存が強く、ある要素だけを切り取って独立に開発することができないこと
- すべての構成要素とそれにまつわる制度・業務を脳内に入れないと自信を持って開発できない状況では、いちいち確認や理解のための時間が必要になる
- 1の結果、とにかく優れたスキルを持つソフトウェアエンジニアが、ソフトウェアエンジニアとして能力を最大限発揮できる環境が整っていないこと
- ソフトウェアエンジニアリングで突破力のある人が、より活躍できる環境にしていきたい
この手の問題については、「分割統治」が基本戦略です。困難は分割せよ、というやつです。実際のところ3倍速くなるかはわからないですが、ヘンリーの向き合っているような複雑なドメインにおいても有効なはずだと思っています。
（分割統治はチーム分割を内包する概念ですが、プロダクトチームとしての分割だけを意味するわけではありません。コードベースだけの分割も非常に重要な戦略です。）
速く、スケールする開発を続けるために
Henry の開発に必要な知識は、
- 制度の知識
- 業務の知識
- コードベースの知識
- 技術の知識
の4つに分類できます。
「技術の知識」については、スキルのあるソフトウェアエンジニアであればあまり問題にならず、今のヘンリーでは課題感はあまりありません。
一方で、医事会計システム側を開発するチームに関しては、これまでも長らく「制度の知識」に縛られた構造になっていました。
「制度の知識」は専門性が高いので、そこに習熟することを明確に役割として持ったチームを作ろう、という考え方にもとづいたチーム設計で、「その制度を理解できた（できる）人（チーム）は貴重だから、その制度にまつわる実装はその人（チーム）に集中させよう」という方向性の最適化が行われていました。
これはフェーズの問題なので、これまでが間違っていたというわけではありませんが、現状の規模、またこれから先のスケールに対しての戦略としてはハマらない、と思っています。
具体例がないとわかりにくいので、いくつか挙げると（といいつつドメイン知識がないとわからない説明ですみません。雰囲気を感じ取ってもらえると。）
- 「この診療行為を算定するときは、レセプトファイルにこのような順番で出力する必要があるので、このように自動算定しておく」
- 「この公費制度で会計する場合は、レセプト上の一部負担金はこのように出力し、窓口会計ではこのように出力する」
- 「この公費制度はレセプト上このように出力する必要があるので、そのように公費が使われていないときはバリデーションで警告する」
このような開発は、従来「レセプト出力機能」と「自動算定」など、またがる領域の両方に詳しくないと実装できませんでした。したがって同じチームに包括されている必要があったのです。
しかし、いま「制度の知識」「業務の知識」「コードベースの知識」のすべてが、一人の人間の頭に入る規模ではなくなってきています。
そこで必要なのは、開発対象を分割することです。 「制度の知識」を「技術の知識」と同じような『ヘンリーのエンジニアならみな知っている（調べられる）』土台にし、そのうえで「ある制度の知識」に依拠する実装をするチームが、複数あっても構わない、といえる状態を目指します。
「ある制度の知識」に依拠する実装をするチームが、複数あっても構わない、といえる状態にするには、何が必要でしょうか？
分解すると、
- その制度を理解できる人を増やせる
- ある制度に依拠する実装が分散しても開発効率が落ちない
ことが重要です。
「その制度を理解できる人を増やせる」については、実は現状では大きな障壁はないのではないかと思っています。今のヘンリーの開発チームには、制度とシステムの両方に非常に詳しいドメインエキスパートが在籍しています。そのような環境であれば、多くのエンジニアが制度を理解できるはずです。
「ある制度に依拠する実装が分散しても開発効率が落ちない」はソフトウェアアーキテクチャの最適化によって達成されます。構成要素の分解と境界面の明確化を行っていく必要があります。
そのうえで、私たちのプロダクト開発における考え方のベストプラクティスを構築していくことも重要です。
たとえば
- 一定の重複処理・重複作業を許容したほうがマシになるケースがあるということを認める
- そのような無駄を許容することでどんなスケーラビリティを獲得しようとしているのかを広く理解する
- 他のコンポーネントをなるべく信用しない方針を取る
- 一つの制度を表現するのに、「こっちのコンポーネントのこの部分で計算する値をいじっておいて、あっちのコンポーネントで後からそれを使って補正する」みたいな作り方をしない
といった考え方です。
おわりに
ソフトウェアエンジニアとして、デリバリーをもっと速くすることでいろんな課題が解決すると信じていますし、そこにもっと向き合っていかなければならないと思っています。
ここに書いた内容は青写真感のある内容ですが、もっと足元の改善ポイント、たとえばリファクタリングやツールの改善によって速度をあげられる部分もたくさんあります。
最近の実践例としては、
- 大きくなってきたチームを分割し、より小さく速く挑戦し失敗し学べる体制を整えつつある
- モノレポ化とモジュール分割によって、コードベースとしての分割統治が進んできている
- AI コーディングツールの導入によって、開発の生産性は相当に向上している
- 主要なコンポーネントのうち負債が大きくなっていたものをリニューアルし、新規制度への対応工数の大幅な削減とスケールする状況を実現している
など、デリバリーを速くするための具体的な活動も進んできています。
社会的意義やお客様にとっての価値に対して貢献し続ける意識を前提に、ソフトウェアエンジニアとしてしっかりソフトウェアエンジニアリングの改善にも向き合っていきます。 また、ソフトウェアエンジニアリング力がより効果的に発揮できるような土台の改善も行っていきます。 ヘンリーはソフトウェアエンジニアを積極的に募集しています！興味を持っていただけた方は、ぜひお話させてください！
