株式会社ヘンリー エンジニアブログ

株式会社ヘンリーのエンジニアが技術情報を発信します

GitHub ActionsでNextJSアプリのビルドとCloud Runへのデプロイを組む

株式会社ヘンリーでSREなどをやってる戸田(id:eller)です。最近の仕事のテーマはリスクコミュニケーションとサイト信頼性です。

弊社のビルドとデプロイは長らくCircle CIを使ってきました。一方でGitHub Actionsも強力なRunnerを使うハードルが下がったり、Circle CIのcontextsよりも使いやすいvariablesやsecretsの管理ができるようになってきたりしています。特にNodeJS開発界隈はGitHub ActionsがメジャーなCI/CD環境になってきている感触もあります。

今回は既存デプロイパイプライン整理のため、NextJSプロジェクトのデプロイパイプラインをGitHub Actionsで組み直しました。要点をご紹介いたしますので、どなたかの参考になれば幸いです。

要件

  • ビルドとデプロイを分離すること。コンテナイメージとアセットをビルドのタイミングで作成しておき、デプロイでは gcloud run deploygcloud storage cp を実行するだけにして、変更のリードタイムを短縮する一環とします。
  • 動作確認環境や本番環境など、複数の環境へのデプロイを統一的に扱えること。
  • ランニングコストがCircle CIと大きく乖離しないこと。将来的にCircleCIの利用を止められればユーザごと料金を大きく削れるため、多少のランニングコスト増は許容範囲とします。

課題

ビルドとデプロイを分離するために、以下のようなワークフローが必要になります。弊社の組み方ですと対象環境ごとにコンテナイメージを作る必要があったため、ビルドマトリックスを利用しています。

graph LR
  テスト
  subgraph ビルド
    development
    staging
    production
  end
  subgraph デプロイ
    d-development[development]
    d-staging[staging]
    d-production[production]
  end
  development --> d-development
  staging --> d-staging
  production --> d-production

また弊社はアセットをCloud Storageにアップロードして、Cloud Load Balancingを経由してエンドユーザーに配布しています。Cloud Storageへのアップロードが即エンドユーザーに対する公開となるため、コンテナイメージはビルドフェーズにpushし、アセットはデプロイフェーズにアップロードさせたいところです。しかしどちらも next build コマンドによって作成するものであるため、アセットのアップロードをビルドフェーズではなくデプロイフェーズまで遅延させる必要がありました。

graph LR
  subgraph ビルド
    direction TB
    build[job] --コンテナイメージ--> ar[(Artifact Registry)]
  end
  ビルド --アセットの受け渡し--> デプロイ
  subgraph デプロイ
    direction TB
    deploy[job] --アセット--> gcs[(Cloud Storage)]
  end

最後に、Pull Request(PR)作成時のワークフローではテストやビルドは行いたいもののコンテナイメージのアップロードはしたくない、またデプロイフェーズは実行する必要がないという特徴があります。こうした制御によってランニングコストを下げるとともに、エンジニアの開発体験を改善することができます。

ビルドマトリックス間の依存関係を表現する

今回の要件はほぼGitHub Actionsの基本機能で実現可能ですが、ビルドフェーズとデプロイフェーズの双方でビルドマトリックスを使っているところだけ注意が必要です。ジョブ同士の依存には jobs.*.needs を使いますが、ここでは matrix を参照できないからです。

jobs:
  build:
    strategy:
      matrix:
        env:
          - development
          - staging
          - production
  # ...
  deploy:
    strategy:
      matrix:
        env:
          - development
          - staging
          - production
    needs:
      - build[matrix.env] # このようには書けない

この問題に対応するため、今回は cloudposse/github-action-matrix-outputs-writeを採用しました。ビルドフェーズに含まれる各々のジョブからひとつずつアーティファクトをアップロードし、これを統合するジョブをデプロイフェーズの前に挟むことで、ビルド用ジョブとデプロイ用ジョブの間に依存関係を持たせつつ、不必要なデプロイ用ジョブを実行しない仕組みを実現しています:

jobs:
  build:
    # ...
      - uses: cloudposse/github-action-matrix-outputs-write@928e2a2d3d6ae4eb94010827489805c17c81181f # v0.4.2
        if: steps.trigger-release.outputs.result == 'true' # リリースが必要な場合。後述
        with:
          matrix-step-name: ${{ github.job }}
          matrix-key: ${{ matrix.env }}
          outputs: |-
            include: true

  # デプロイが必要な環境をリストアップしてmatrix用のJSONを出力する
  prepare:
    runs-on: ubuntu-latest
    needs: build
    steps:
      - uses: cloudposse/github-action-matrix-outputs-read@ea1c28d66c34b8400391ed74d510f66abc392d5e # v0.1.1
        id: read
        with:
          matrix-step-name: build
      - uses: actions/github-script@v7
        id: set-result
        with:
          script: |
            const input = JSON.parse(${{ toJSON(steps.read.outputs.result) }});
            return input.include ? Object.keys(input.include) : [];
    outputs:
      result: "${{ steps.set-result.outputs.result }}"

  deploy:
    needs: prepare
    runs-on: ubuntu-latest
    if: join(fromJSON(needs.prepare.outputs.result), '') != ''
    strategy:
      matrix:
        env: ${{ fromJson(needs.prepare.outputs.result) }}
    environment: ${{ matrix.env }}

ジョブの依存関係は以下のようになります。

graph LR
  テスト
  subgraph ビルド
    development
    staging
    production
  end
  subgraph デプロイ
    d-development[development]
    d-staging[staging]
    d-production[production]
  end
  development & staging & production --> prepare --> d-development & d-staging & d-production

ビルドマトリックス間のファイル受け渡し

依存関係が表現できれば、ファイルの受け渡しは難しくありません。actions/upload-artifactactions/download-artifact を利用して、 ${{ matrix.env }} をnameに含むアーティファクトをアップロード&ダウンロードするようにします。アーティファクトは一定時間で削除されますが、デプロイが充分に頻繁であれば問題にならないでしょう。

jobs:
  build:
    steps:
      # ...
      - uses: actions/upload-artifact@v4
        with:
          name: next-static-${{ matrix.env }}
          path: .next/static
  # ...
  deploy:
    steps:
      # ...
      - uses: actions/download-artifact@v4
        with:
          name: next-static-${{ matrix.env }}
          path: .next/static
          merge-multiple: true

コンテナイメージのpushやデプロイフェーズの必要性を判断する

弊社はGitflowを使って開発をしています。コンテナイメージのpushやデプロイフェーズの必要性を整理すると、以下のようになります:

  • developブランチに変更をpushしたら、開発環境にデプロイ
  • releaseブランチからmasterブランチに向けたPRを更新したら、動作確認環境にデプロイ
  • masterブランチに変更をpushしたら、本番環境にデプロイ

これ以外のケース、例えばtopicブランチへの変更のpushやdevelopブランチに向けたPRの更新では、ビルドやテストは必要でもコンテナイメージのpushやデプロイの実行は不要です。この判断をGitHub Actions Workflowのフォーマットで表現することは可能ですが、単体テストを書きたいと考えたためJavaScriptファイルに切り出してactions/github-script で実行することとしました:

      - run: |
          echo "head=${GITHUB_HEAD_REF:-${GITHUB_REF#refs/heads/}}" >> $GITHUB_OUTPUT
        id: extract-branch
      - uses: actions/github-script@v7
        id: trigger-release
        with:
          result-encoding: string
          script: |
            const triggerRelease = require(".github/workflows/trigger-release");
            const {HEAD_BRANCH, BASE_BRANCH, APP_ENV} = process.env;
            return triggerRelease(HEAD_BRANCH, BASE_BRANCH, APP_ENV);
        env:
          HEAD_BRANCH: ${{ steps.extract-branch.outputs.head }}
          BASE_BRANCH: ${{ github.base_ref }}
          APP_ENV: ${{ matrix.env }}
// .github/workflows/trigger-release.js
/**
 * @param {string} head PRのHEAD、あるいはPUSHされたブランチの名前
 * @param {string|undefined} base PRのBASEブランチの名前、あるいはundefined
 * @param {string} env development, staging, productionのいずれか
 */
module.exports = (head, base, env) => {
  const isPush = base === undefined || base.length === 0;

  if (env === "production") {
    return isPush && head === "master";
  } else if (env === "staging") {
    return !isPush && head.startsWith("release/");
  } else {
    return isPush && head === "develop";
  }
};

まとめ

弊社のユースケースでは next build はコンテナイメージとアセットの双方を作成するのに必要なコマンドでありビルドフェーズに実行したいものでしたが、アセットのアップロードタイミングはデプロイ時にまで遅延させる必要がありました。またビルドマトリックスを利用するために、ビルドジョブとデプロイジョブの依存関係管理が複雑化していました。アーティファクトを利用することでこの2つの問題が解消できました。

またコンテナイメージのpushやデプロイフェーズの必要性を判断する条件は複雑化しがちですが、JavaScriptに切り出すことでVitestなどによる単体テストを書けるようになります。必要ならTypeScriptで書くこともできるでしょう。複雑化しやすいワークフローを制御するテクニックとして覚えておいて損はないと思います。

OpenTelemetry Collector 自身のモニタリングについて考える

ヘンリーで SRE をやっている id:nabeop です。最近の仕事のテーマはサービスの可観測性の向上と信頼性の計測です。

最近では可観測性の文脈では OpenTelemetry が話題に上がると思いますが、ヘンリーでも OpenTelemetry を導入してテレメトリデータを収集して、各種バックエンドに転送しています。分散トレース周りの話題については、以下のエントリがあります。

ヘンリーではマイクロサービスからのテレメトリデータは Cloud Run で構築した OpenTelemetry Collector で集約し、otelcol のパイプライン中で必要な処理を実施し、バックエンドに転送するアプローチを採用しています。

OpenTelemetry Collector でテレメトリデータを収集している様子

現在は監視基盤の移行期なので、メトリクスが Google Cloud と Datadog の両方に転送されていますが、将来的には Datadog に一本化される見込みです。

今回のエントリでは OpenTelemetry Collector 自体の可観測性をどのように確保しているかについて紹介します。

OpenTemetry Collector の内部メトリクスを Prometheus 形式でエクスポートする

OpenTelemetry Collector のモニタリングについては以下のドキュメントが参考になります。

また、OpenTelemetry Collector 自体の可観測性の考え方についてはこのようなドキュメントがあります。このドキュメントでは実験的なアプローチとして OTLP でテレメトリデータを外部に転送するアプローチが紹介されています。今回は以下の理由から OTLP によるエクスポートを選択せず、Prometheus 方式で OpenTelemetry Collector の内部情報をエクスポートするアプローチを採用しました。

  • OTLP でのエクスポートは実験的という扱いである
  • 前述のモニタリング方法のメトリクスが Prometheus 形式で記述されている

したがって、OpenTelemetry Collector の内部のメトリクスを Cloud Monitoring と Datadog の双方に転送する OpenTelemetry Collector の設定は以下のようになりました。

receivers:
  prometheus:
    config:
      scrape_configs:
        - job_name: otel-collector
          scrape_interval: 30s
          static_configs:
            - targets: ['0.0.0.0:8888']

processors:
  batch:
    send_batch_size: 8192
    timeout: 15s
  transform/gcp:
    metric_statements:
    - context: datapoint
      statements:
      - set(attributes["exported_service_name"], attributes["service_name"])
      - delete_key(attributes, "service_name")
      - set(attributes["exported_service_namespace"], attributes["service_namespace"])
      - delete_key(attributes, "service_namespace")
      - set(attributes["exported_service_instance_id"], attributes["service_instance_id"])
      - delete_key(attributes, "service_instance_id")
      - set(attributes["exported_instrumentation_source"], attributes["instrumentation_source"])
      - delete_key(attributes, "instrumentation_source")
      - set(attributes["exported_instrumentation_version"], attributes["instrumentation_version"])
      - delete_key(attributes, "instrumentation_version")

exporters:
  googlecloud:
  datadog:
    api:
      site: datadoghq.com
      key: ${env:DD_API_KEY}

service:
  telemetry:
    metrics:
      address: ":8888"

  pipelines:
    metrics/promethus-for-datadog:
      receivers: [prometheus]
      processors: [batch]
      exporters: [datadog]
    metrics/promethus-for-gcp:
      receivers: [prometheus]
      processors: [batch, transform/gcp]
      exporters: [googlecloud]

service の telemetry.metrics によって OpenTelemetry Collector の内部メトリクスを Prometheus 形式で 0.0.0.0:8888/tcp でエクスポートして、prometheus レシーバーで Prometheus 形式のテレメトリデータを収集しています。

また、Cloud Monitoring にメトリクスを転送しようとした際に「Duplicate label Key eccountered」というエラーが発生し、メトリクスデータの転送に失敗していたので、google exporter の README.md の記述を参考に transform プロセッサーで transform/gcp としてメトリクスの属性を exported_ プレフィックスをつけた属性名に置き換えています。

このようなパイプライによって、Datadog と Google Cloud の Cloud Monitoring の両方で OpenTemetry Collector の内部メトリクスが他のマイクロサービスと同様に観測できるようになりました。

今後の課題

今回のアプローチでは Prometheus 形式でエクスポートしていますが、前述の OpenTelemetry Collector の Observability のドキュメントでは実験的という立ち位置ですが、将来的に OTLP 形式に置き換わることが示唆されています。将来的に OTLP 形式が推奨となり、Prometheus 形式でのエクスポートが非推奨となった場合、メトリクス名もドット区切りの OTLP 形式に置き換わることが予想されるので、メトリクスデータの連続性が失われることが課題になりそうと思っています。

また、OpenTelemetry Collector のモニタリングのドキュメントでは転送時にエラーになった場合は otelcol_processor_dropped_spansotelcol_processor_dropped_metric_points がカウントアップされるとありましたが、我々の環境ではこれらのメトリクスは生成されていませんでした。今は代替として otelcol_exporter_send_failed_spansotelcol_exporter_send_failed_metric_points を監視するようにしています。

We are hiring!!

ヘンリーでは各種エンジニア職を積極的に採用しています。Henry が扱っている医療ドメインは複雑ですが、社会的にもやりがいがある領域だと思っています。複雑な仕組みを実装しているアプリケーションには可観測性は重要な要素です。一緒にシステムの可観測性を向上しつつ、複雑な領域の問題を解決してみませんか?

mablers_JPでドメインエキスパートとQAについて登壇しました

SDET / SREのsumirenです。 2023/12/21に開催されたmablers_JP オフラインMeetUpにヘンリーから登壇しました。その際の登壇内容について、こちらのエントリにサマリを記します。

当日のアーカイブは以下になります。よろしければぜひご覧ください。

youtu.be

イベントを運営・企画いただいた運営の皆様に感謝します。ありがとうございました。

背景

ヘンリーは医療ドメインにディープダイブし、複雑な診療報酬制度に向き合っています。難解なドメインでお客様のペインに正しくアプローチするために、ヘンリーではドメインエキスパートが活躍しています。ヘンリーで活躍しているドメインエキスパートについては、こちらの記事も是非ご覧ください。

ドメインエキスパートの知見をサービスの品質に最大限活かすため、ヘンリーではドメインエキスパートがQAの役割も担っています。これにより、「実際には医療事務さんはこういう使い方をしない」であったり「この診察をしたときには、厳密にはこういう金額計算になる」といった業務への深い洞察をサービスの品質に活かすことを目指しています。

登壇内容

上記のドメインエキスパートの知見を自動テストにおいても活かすため、ヘンリーではローコード自動テストツールであるmablをドメインエキスパート中心で運用しています。

ローコード自動テストツールとはいえ、実際にmablを非エンジニア中心で運用しているケースは少ないのではないかと思います。ヘンリーでは様々な工夫をしながらこうした尖った運用を実現し、自動テストの領域においてもドメインエキスパートの知見を活用することに挑戦しています。

イベントでは、こうしたドメインエキスパート中心のmabl運用について、組織やプロセスの設計における工夫の事例をシェアさせていただきました。

最後に

ヘンリーの組織にはまだまだQAの課題があります。

ドメインへの理解度が高い一方、QA自体の専門性が不足しているため、一般的に検知しやすいバグが摘出できないこともあります。また、QA専任の方はいないため、長期的な品質戦略や計画を立てたり、品質のボトルネックを積極的に特定して課題解決を推進することもできていないと言えます。

制約の中で、ドメインエキスパートやSDET中心で定例や改善活動を回し、今自分たちにできるQAにチームで向き合っているというのが現状です。

そうした背景もあり、ヘンリーでは1人目のQAエンジニアを募集しています。ドメインエキスパートとQAエンジニアの専門性をシナジーさせることでサービスの品質をさらに高めたり、プロアクティブに品質戦略に臨む組織体制を作っていきたいと考えています。

興味を持っていただけましたら、ぜひカジュアル面談でお話させてください。よろしくお願いいたします。

hrmos.co

2023年ヘンリーアドベントカレンダー完走の感想

ヘンリーで SRE をやっている id:nabeop です。

そして、この12月、さらにシェアを増やすべく、有志の企画によりヘンリー史上初のアドベントカレンダーを行うことになりました。 Advent Calendar 2023をやるので2023年を振り返ってみます - 株式会社ヘンリー エンジニアブログ

そろそろ社員数も増えてきたし、アドベントカレンダーができるんじゃないか?という Slack の自分の分報チャンネルでつぶやいたら、あれよあれよという間に全社的な取り組みになって、25日間の枠が埋まりました。

ということで、今年のうちにアドベントカレンダーの感想のエントリを書いてみます。

12/1

アドベントカレンダーを始めるにあたり、せっかく2人の VPoE がいるので、開始と終了はそれぞれに担当してもらいたいと思っていたところでした。この一年で組織とサービス規模の両面が大きくなったというのが改めてわかりました。来年はもっと拡大する見込みなので、引き続きやっていきたいですね。

12/2

双方のソフトスキルに依存する話なので、むずいですよね。チームでも毎朝30分の Standup ミーティングをしていて、タスクの困りとかはそこで会話しているけど、自分が相手の困りを引き出せているかというと自信ないです。

12/3

僕は今年の6月にヘンリーに入社したので今年の後半しかいなかったですが、導入予定の医療機関様がすごいスピードで増えていく様子をみていました。来年も Henry をたくさんの医療機関様に導入いただいて、医療の DX 化を進めていきたいですね。

12/4

大きい会場で緊張しているところをダジャレで助けてもらいました!!だいたい発言から数分で面白いダジャレがついてくるので、瞬発力がすごいなと思っています。

あと、エントリのタイトルで「完走の感想」とダジャレにしていたので、カスタム URL も遊び心が欲しいなーと Slack のチャンネルでつぶやいたらシュッと「otucalendar」といい感じなワードを出してくれたので助かりました。

12/5

浸透圧だけでここまで語れるのすごすぎないですか!?

12/6

弊社の特徴として、Henry を導入いただくにあたって、医療期間様の業務の深いところまで理解して、導入の価値を最大化することを目指しています。今まではカスタマーサクセス (CS) という職種でしたが、より実態に合わせるようにパートナーグロース (PG) と職種名を変えました。その背景と今後の展望まで書かれているので、興味のある方はぜひ読んでもらいたいですね。

12/7

入社していきなりたくさんの医療機関様にインタービューをして、その内容が日々 Slack にながれてきて、とても頼もしいなーと思ってみていました。

12/8

数ヶ月くらい技術勉強会をやってきて、Slack でも「これギベンで話したら面白くないです?」みたいな会話がされていて根付いてきたなーと思っています。こういう取り組みはどんどんやっていきたいですね。

12/9

一緒に OpenTelemetry の導入をしているんですけど、このエントリを読んで思ったよりもハマりポイントがあるなーと改めて思いました。ただ、問題に向き合うことで OpenTelemetry のトレースのプロパゲーション周りの理解が深まってよかったです。

12/10

PC で仕事をすることが普通だと思っていたけど、業種によってはそうではない、ということが驚きでした。Henry を導入していただくことによって、DX 化の促進にもなると嬉しいなと思いました。

12/11

blogsync は個人的にも使っているので、メンテしてもらってありがたい!このブログも blogsync での自動化をしたいなーと思って途中まで作業していたけど、忙しくて手が動かせてないことを思い出しました。

12/12

PG の業務範囲は広いので、キャリアパスが多岐にわたるということですね。この中から各自にあったキャリアパスで成長してもらえそう。

12/13

PG という職種についてのエントリを読んでいたので、PG として活躍されている人の実体験も合わさって、PG という職種の解像度があがりました。

12/14

いつもお世話になっています!!!いろんなところに認知負荷があるんだということを知れました。

12/15

退路を立ちつつ、ちゃんと有言実行していてかっこいい!!!開発チームでレセプト関係の会話を聞くことはありますが、複雑すぎて理解できる気がしないので、プロは凄いなーと思っています。

12/16

一時期は朝にコーヒーを飲まないと夕方には頭痛がするくらいコーヒー好きな状態でしたが、淹れ方はここまでこだわれるとは思ってもなかったです。深い世界だ。

12/17

仕事でも関わることが多くて、関わるたびに圧倒されるくらい優秀な人です。そんな人が「自分がワントップにならなくて済むぐらいに激強メンバーが揃っている」という組織、どこだろう...?

12/18

弊社では Kotlin がメインの言語になっているけど、僕自身はあんまり触れていないので、まずは気軽に Kotlin Scripting で色々試行錯誤してみるのもいいかなーと思いました。

12/19

一年で1.5倍の組織規模になったけど、その時々でより良い組織になるように色々されていてありがたいです。あと、猫が可愛い。

12/20

複雑なドメインを扱っていてつらみはあるけど、課題が複雑であるほど、解いた時の達成感は大きいですよね。SRE としても複雑な問題に日々直面していますが、直面するたびにわくわくしています。

12/21

便利になるように個人的に作っていたツールがプロダクトに取りこまれてめっちゃいいですね。

12/22

会社の DemoDay で実際に動いているとこを見せてもらった時にも思ったけど、技術説明とかも含めて解説されると、これだけのモノを個人でガッと作っちゃうの、すごくない!?となっちゃう

12/23

異なる医療ドメインのキャッチアップをプログラミング言語の習得に例えられてイメージしやすかったです。

12/24

僕も最初に複雑な医療ドメインをキャッチアップすることに苦労したけど、こういうアプローチもあるんですね。とくにチャンキングの件が参考になりました。

12/25

アドベントカレンダーのいくつかのエントリで触れられていた通り、ヘンリーは今年だけで組織が1.5倍になるほど拡大したけど、来年は今年よりも拡大する見込みなので色々考えることがある!自分にとっても経験したことがない規模で拡大するので今からわくわくしています。

アドベントカレンダーを終えて

最初は25日分のうち8割くらい埋まれば御の字かなーと思って発案したけど、蓋を開けてみたら、あっという間に25日分が集まって、2トラック分やるか...?みたいな会話もされてびっくりしました。また、職種にかかわらずいろんな方に参加してもらえたことも嬉しかったです。エントリの内容も趣味から仕事までバラエティに富んでいてヘンリーのメンバーらしいアドベントカレンダーになったのではないかと思っています。

ヘンリーは来年も拡大しつづけているので、来年のアドベントカレンダーは本当に2トラック分になるかもしれないですね。

そんなヘンリーではさまざまな職種で募集をしています。一緒に日本の医療の DX 化を推進していきませんか?

スタートアップの熱狂と急成長を両立させる野望

VP of Engineeringのid:Songmuです。このエントリーは株式会社ヘンリー Advent Calendar 2023、最終日の記事です。

ヘンリーは今年、本丸の病院向け電子カルテ・レセコンシステムのサービスを開始し、順調に事業が立ち上がっています。早くも業界でもユニークなポジションを獲得し、注目度も上がっています。

そんな中アクセルを踏む決断をし、来年は組織として100人採用に踏み切ることになりました。

ビジネスを勝ち切るためのアクセルを踏むフェーズにおいて、自分がVPoEとして採用や組織開発に主体的にチャレンジできる立場にいることは喜ばしいことです。その中で自分が考えていることを書き出していきます。

公器を志向すること

「面白法人でありながら上場することに意味と面白さがある」

2011年頃、当時私が所属していたカヤック社で代表の柳澤さんが度々こう言っていました。カヤックとして上場を意識し始めた頃です。もともと上場を狙っていた会社ではなかったこともあり、上場は多くのイチ従業員達にとってはどこか他人事で、正直その意義への実感は薄かったと思います。そんな中、その意義を定期的に言葉にし、社員にも考えてもらう示唆を与えていたのは印象に残っています。

世界の片隅で面白そうなことをやっていても自己満足に過ぎず、会社の面白さとそれに伴う価値をもっと広く世に問う事に意味があり、その一つとして上場がある。私はそのように解釈していました。

また、DeNAの南場さんの「不格好経営」に以下のような一節があります。「公器」と言う言葉を私が意識するようになった一節です。

南場カンパニーにしたいのか、それとも公器として育てていきたいのか (中略) 熟考の上、決意した。社会の公器として発展させるために責任を果たす 南場智子. 不格好経営 (p.143) Kindle版.

公器と公開会社であることは異なりますし、ここでその関連が語られているわけではありません。ただ、イチ企業が公器足るためには、公開会社であることは多くの場合必要条件でしょう。

自分たちに公共性の高いミッションがあり、その意義を信じていて、広く世の中に価値をもたらしたい、つまり公器足りたいのであれば、その正当性を公に問う必要があります。個人の自己満足や局所的な箱庭作りに陥っていないかも世の中に評価してもらうということです。上場して公開会社になることは、そのための手段でもあります。

公開して自分たちの価値を問う、というのは実はOSSの精神にも類似する部分があると感じます。

ヘンリー社も「社会課題を解決し続け、より良いセカイを創る」「人類の医療・介護インフラを創る」というミッションを掲げているので公器を志向しているはずです。

スタートアップと急成長

スタートアップにそういう志がある場合、単純に少数精鋭での高い利益率を追い求めるだけだけではなく、その絶対量も意識しないといけません。そのドメインやマーケットに変革を起こすのであれば、広くその領域を取りに行く必要があるからです。現実問題としてWinner takes allの傾向は強く、新規領域で先行者利益で突破するにしても、既存領域でゲリラ的にシェアを拡大するにしても、スピードが必要です。そうしないとマーケットを育てられなかったり、他社に押し負けたりしてジリ貧になる可能性が高いのです。

急成長が必要です。

スタートアップ初期の熱狂

私も何度か経験がありますが、事業やプロダクトが立ち上がった時期の熱狂は何事にも代えがたい快感です。特に、プロダクトリリース後に手応えを感じ始めた頃などは、それまでの苦しみがあった分、その喜びは格別です。

まだ少人数で、メンバー間に部活や研究室のような一体感があり、ミッションも何も言わずとも行き届くツーカーの関係が築かれています。

また、全員が事業やプロダクトの全貌を大体把握しており、プロダクトのどこを変更すればどのような影響があるか大体想像でき、自分の決断の結果がダイレクトに自分に返ってくるので自分ごと化しやすい。そういう全能感があります。

この、一体感と全能感が、この時期の熱狂の源泉です。

ただ、この段階はあくまでもスタートを切れただけであり、この後は急成長をする必要があることは先に述べました。そして、組織が大きくなるにつれて熱狂は薄れていってしまうものです。

また、この熱狂の快感にやられてしまった人間は、全員に全貌を把握してもらいパワープレーでゴリ押すことを志向しがちです。認知能力の高いメンバーを揃えて一つのチームでなんとかしようとする。システムの話だけで言うと、何十人も開発者がいるのに、一つのモノリシックなシステムを触らせるようなことです。私自身にもそういった傾向を自覚しています。

成長期における熱狂の失われ方

これまで大企業、百人弱から数百人規模のベンチャー、スタートアップなどに関わる中で、私は熱狂が失われる局面を多く見てきました。以下は自分の周りで起きたことや起きそうになったこと、友人から聞いたことの一部です。

  • 人を増やしすぎる
    • 受け入れキャパシティを超えた採用
    • 採用人数目標圧に負けて採用基準を緩めてしまう
    • 結果として採用が組織力向上に繋がらない
      • 人件費ばかり増える
      • キーパーソンの離職
  • 逆に人を増やしたいのに増やせない
    • アクセルを踏みたいが、諸事情により人が増やせない
    • 事業として勝ちきれない
  • チーム分割による縦割りとサイロ化
    • 相互無関心と局所最適
    • 全体最適を見れず利益を奪い合うケースも
  • 攻めと守りを分けすぎる
    • 守りをおろそかにして、一部の人に押し付ける
      • 「攻め」の人たちが出したゴミ掃除をさせられる感
    • 守り側の人が余計防御的になりブレーキを掛けすぎる
      • 全体のスピードが遅くなる
      • 感情的な対立も
  • ガバナンス軽視
    • できてないことを認識しているならともかく、認識すらできておらず、急にやるべきことが噴出する
    • 上場前にその場しのぎで作られた形式的なワークフローが負債的に残り続ける
    • 逆に無駄な事務作業が増え非効率に
  • 文化形成や明文化を怠る
    • コンテキストや暗黙的な情報格差による成果の出しやすさの格差
    • 結果としての新旧メンバーの意識やコミットメント格差
    • 社歴や部署間での文化の違いや派閥化
    • 社員のベクトルが揃わず、組織のバリューに繋がらない

多くの人が全体観を持てず、全体最適を考えて行動できなくなり、局所最適に陥ることで起きる問題がほとんどです。

私がこれまで所属した組織はいずれも自分を育ててくれて愛着がありますし、今でも仲良くさせてもらっています。幸せなことに、どの組織も悪人はいなかった。他人を蹴落として自分の利益とするような人はいませんでした。それぞれがベストを尽くそうとしていた。ネガティブなことだけ羅列したので印象が悪くなり申し訳ないですが、実際はかなり上手くやっていたと思います。どこも事業継続しているし、上場している企業もあります。

ただ、それでも個人的に歯がゆかったり、悲しい思いをすることも多くありました。当時の自分が、当事者として関わりきれなかったり力不足だったことも反省材料として残っています。

ヘンリー社では、VPoEとして組織開発の当事者としてそれらの課題に主体的に関わるチャンスを得られています。これは私のキャリアにおけるリベンジの機会でもあるのです。

健全に組織を拡大しつつ熱狂を失わないようにできるか、組織が大きくなる中で文化が壊れないようにしつつも事業の成長速度と人が増える速度を同じ角度に保てるか、それらの実現が私のヘンリーにおける大きな野望の一つです。

ヘンリーは事業とプロダクトを大きく伸ばしており、周囲からも急成長を期待されています。野望を実現する舞台が整っているし、実現させないといけない局面でもあるのです。

そしてチームトポロジー

結局、組織拡大においてパワープレーは持続性に欠けます。組織やシステムを権限分離して、独立性や自律性を高める話には向き合わざるを得ません。

なるべくシステムはモノリシックにして、単一チームでのパワープレーを維持したかった自分にとって、チームトポロジーは身につまされる本でした。認知負荷の限界があることを認め、それをどのように構造的に解決するか、という視点をこの本から得られました。

しかし、認知負荷の存在を認めつつもどう立ち向かっていくかがチームトポロジーなのであって、認知負荷に日和ってブレーキを踏み合っていたら意味がありません。局所最適に陥らず、チームが増えてコミュニケーションパスが複雑化してもスピードを落とさないようにしないといけません。

何事も境界をきれいに切ろうとすると、絶対に隙間が生まれてしまいます。境界部分のオーバーラップとインタラクション設計が重要です。人間、境界が見えてしまうと、どうしてもその手前でブレーキをかけることが増え、そこにポテンヒットが集まってしまう。組織においてそれが起こることは「技術の創造と設計」の以下の図がよく表しています。

「技術の創造と設計」p.17

システム設計におけるレイヤードアーキテクチャーも、境界をきれいに切り分けようとすると、逆に隙間だらけで融通の効かないスカスカのバームクーヘンになる危険性があります。

チームトポロジーもレイヤードアーキテクチャーも大事なプラクティスではありますが、形式張って進めすぎると、多くの衰退した大企業が歩んできた轍を踏むことになりかねません。組織の「成熟」を早め、いわゆる大企業病を加速させてしまう諸刃の剣であるように思えるのです。

私としては、境界の手前でブレーキを踏まず、その上での健全な衝突が発生することを良しとしたい。同時にお互いにストレスを抱え合うような、感情的で無駄な軋轢が起きてほしくないとも思っています。

矛盾に立ち向かうための幾つかのアイデア

このようなスタートアップが抱える一種の矛盾に立ち向かうために、個人的に意識している考えを幾つか挙げて行きます。

二項対立を超越する

人間には状況を把握するために二項対立で物事を整理したがる傾向があるように感じます。これはある対象が有害か無害かを瞬時に決断できないと自身の生死に関わったような太古の時代ならともかく、現代では悪癖とも言えます。これは名著「知識創造企業」で似非ダイコトミーとも表現されています。

先に述べたように、組織拡大においては、チームを分割して自律性と独立性と担保しつつも、それぞれが全体観を失ってはいけません。また、少数精鋭の方がスピードが出せるのは間違いないので、精鋭部隊を維持しながら組織を大きくしなければなりません。

それに限らず、スタートアップでは多くの困難な両立を実現する必要があります。「要はバランス」とか言わずに、まずは両取りを考えなくてはいけません。「知識創造企業」ではダイナミックな統合と言われているものです。「要はバランス」とかいい出した時点で二項対立に囚われており、その軸でしか考えられなくなるのです。

このエントリーのタイトルの、熱狂と急成長の両立も、私が実現したい困難な両取りのチャレンジです。

内集団バイアスに陥らない

スタートアップはそれ自体、内集団バイアスが高まりやすい傾向があります。そして、チームが分割され、他チームと断絶されたときにチーム内での内集団バイアスも高まりやすくなります。場合によっては外への価値提供よりも自分たちを守ることが優先され過ぎ、ともすればカルト的にもなり危険です。

組織は内向きになりすぎず、外とのつながりを常に意識しなくてはいけません。企業やチームにおいては、自分達の業務や活動が最終的にどのような顧客や世の中への価値提供につながっているのかというバリューストリームを意識するということです。

これは、全チーム、全社員が意識できることが理想です。自分たちは守りの仕事だから関係ないなどと思ってはいけないし、そう思われてしまうのであれば組織設計の失敗です。

分散と集中

多くの技術トレンドがそうであるように、分散と集中が螺旋のように繰り返されます。組織においても同様で、チームを分割するだけだと、無駄にチームが増えていくだけです。時には統合して分割し直すプロセスも必要でしょう。

両利きの経営

これは、書籍「両利きの経営」のタイトルそのままです。既存事業を深めて伸ばすための「知の深化」と、新規事業のイノベーションを生み出すための「知の探索」を両立する考え方です。この「深化」と「探索」の両軸の考え方は、普段の組織の業務設計の中でも応用が効く有用な分類だと感じています。

鉄郎のネジ問題

独立性と自律性を高めた結果、無味乾燥な業務にまで分割されたら、それは果たして業務を行う当人は幸せでしょうか。具体例としては過度なマイクロサービス化はエンジニアのモチベーションを奪いかねないといったことです。

これを私は「銀河鉄道999」からあやかって「鉄郎のネジ問題」と呼んでいます。色々考慮して行き着いた先が、無味乾燥で代替可能なパーツになることだとしたら笑えない話です。それが本当にあなたの欲しかった完全無欠な機械の体なのですか?という話です。

チームを分割するにしても、チームメンバーが創造性が発揮できてバリューストリームへの接続を意識できるレベルにとどめ置くべきでしょう。

銀河鉄道999 14巻 p.212

ポテンヒットをアウトにする

私は仕事においてお見合い落球が発生することが大嫌いです。そういう狭間に落ちそうになっているボールを積極的に取りに行く人が評価されて欲しいと思います。

そういう狭間の業務は、多くの人の死角に入っていたから狭間に落ちそうになっている訳で、目標設定のスコープからは漏れているものです。なので、目標に囚われすぎると、そういった業務を拾いに行くインセンティブはありません。これもまた悪しき局所最適です。

目標設定は大事ですが、それに囚われすぎ、全体最適な行動を取ることが称賛される風土作りや、インセンティブ設計をしたいと考えています。

組織開発上のアクション

これらの考えを元に、これまでとこれから私がどのようなアクションを取っていくかについて述べ、このエントリーを締めようと思います。

ミッション共感とバリュー浸透

組織の急成長の当事者として立ち会え、貢献できることは充実感が高く、得難い経験になるでしょう。しかし、時には痛みが出ることもあるでしょう。成長痛と言われることもありますし、そんな綺麗事では済まないケースもあるかもしれません。

そんな困難な状況ではミッションへの共感と高め、全員がそれを実現したいと思えるか、思ってもらえるかが大事です。最初の方に述べたように、公共性の高いミッションを掲げ、公器足るために急成長を志向しているわけですから、ミッションに共感して納得してもらう必要があるからです。

そんなチャレンジングな状況を楽しめるかどうかも大事です。そういう状況を乗り越えた先にはそれぞれのメンバーの成長もやってきます。それぞれの社会人としての価値も上がり、より面白くチャレンジングでリターンのある仕事がやってくるようになるはずです。

生存者バイアス的な部分がありますが、だからこそ、全員が生き残れるように、誰かに負荷が偏らないように、一丸となって乗り越えられるようにインセンティブ含めて設計する必要があります。

また、行動指針としてのバリューを浸透させていく必要があります。各人のベクトルを合わせて合力を最大化するためです。

その浸透の一環として少し前に社内でバリューについて考えるワークショップを実施しました。

ワークショップの様子

ミッションもそうでありますが、バリューは言葉だけだと曖昧です。そして「エラい」人が「分かっていない」人に説明を尽くそうとするほど、説明された側からすると、他人から押し付けられたモノ感が強まり、自分ゴト化が困難になります。

こういったものは実は曖昧でよく、各人が解釈することで、コンテキストが醸成されます。バリューは特に、ミッション実現のために、メンバー各位が大事にしたいことが抽出されたものでもあるため、全員にオーナーシップを持ってもらう必要があります。

メンバーに解釈してもらわずに放置すると、バリューはすぐに形骸化します。バリューを自分たちのものだと思ってもらえるように、定期的なワークショップなどを通してメンテナンスやアップデートをしていきたいと考えています。

1978年、ホンダのトップは「冒険しよう」というスローガンで新しいコンセプトカーの開発を打ち出した。 (中略) ホンダのトップが与えた使命の曖昧さは、開発チーム内に混乱を引き起こした。逆説的に聞こえるかもしれないが、この混乱が実は、全く新しいクルマをめざすというきわめてはっきりした方向感覚をもたらした。 野中 郁次郎; 竹内 弘高. 知識創造企業(新装版) (pp.38-39). 東洋経済新報社. Kindle 版.

採用

私が、ヘンリーの中で持っているメインのミッションが、エンジニア含めたプロダクトチーム全体の採用です。

採用においてはそれぞれの専門性に加えて、先に述べたミッション・バリューへの共感が大事です。ミスマッチによる採用失敗のダメージは大きく後を引くため、採用基準は妥協してはいけません。

私は、エンジニア採用を中心に採用には10年近く携わってきましたが、自分が採用に関わったエンジニアについては、失敗したことはほぼ無いと思っています。これは自分の中での自慢です。

ただ、一年で100人を超えるような採用ペースには携わったことはありませんし、そういうペースで多くの魅力的な人材を採用している企業に対して羨望の眼差しを向けてきました。

優秀な人が綺羅星のように集まり、それぞれがコラボレーションして思いもよらぬ価値を生み出せる環境は魅力的です。それを実現したいと考えています。

フィードバックサイクルの設計

「評価」というとアレルギー反応を起こしてしまう人が多いと思いますが、大事なのはフィードバックサイクルです。それを設計して改善し続け、それを回して経験学習を促進させ、個人や組織の成長につなげることです。

ここでも大事なのはミッションに共感し、バリューに沿った行動が取れているか、そして、各人がバリューストリームのどこにいるかを意識することだと考えています。外向きへの価値提供が意識されないと内集団バイアスが強まる危険性があることはすでに述べました。

自分たちがどのような価値を生み出しているかを意識し、それを表明する。それに対して周りからフィードバックをもらう。フィードバックには当然称賛も含まれます。その繰り返しが大事です。

それらを踏まえた評価設計にも取り組んでいきますが、あまりにも大きなテーマなので、それはまた別の機会。

ビルドトラップに気をつける

最後に自戒ですが、組織開発的なアクションはやりすぎてしまうことも多く、得てしてオーバーエンジニアリング的になりがちです。プロダクト開発における作りすぎ、いわゆる「ビルドトラップ」と言われる事象が発生しやすいのです。

プロダクト開発がそうであるように、やった方が良いことはたくさんありますが、その中で今やるべきことは一握りしかありません。また、内向きな指向が強まると、自分たちの行動を正当化しすぎる内集団バイアスにもつながり兼ねません。組織開発の営みも、やはり組織の体外的な価値提供にどのようにつながっているかを意識することが大事です。

自分たちのやっていることを正しいと信じて行動しつつ、それを常に疑い続ける。そのように矛盾を内在していきたいと私自身は考えています。

まとめ

本エントリーは、ヘンリーという有力な舞台の上で、私の過去に対するリベンジを果たしたい、という私の個人的な物語でもありました。スタートアップの熱狂を維持しながら中身の伴った急成長を実現したいし、世の中に価値を提供し続けられる組織づくりをしたいと考えています。

ヘンリーはまだ100人に満たないスタートアップですが、事業が立ち上がり、マーケットにも受け入れられ始めています。メインの仮説検証は終わり、価値を届けるサイクルを回し始められています。事業の確度も高くなり、各人が価値提供を実感してフォーカスしやすい状況です。

自分たちでも信じがたいことですが、ヘンリーは病院向け電子カルテ・レセコン領域において、信じられないくらいユニークで有力なポジショニングができています。そしてまだまだ課題は山積みです。カジュアル面談に来ていただいたらその辺りのお話をさせていただきます。

このような状況の中で、一緒にヘンリーで世の中への価値提供に取り組んでくれる方を募集しています。単に興味があって話してみたいというのも歓迎なので、まずは連絡をお待ちしています。

認知科学を応用した医療ドメインの効率的キャッチアップ

【この記事は株式会社ヘンリーAdvent Calendar 2023の24日目の記事です。昨日は 嶺野さんによるヘルステックエンジニアのキャリアという話でした。】

こんにちは!2023年10月にヘンリーに入社した山口(@tyamaguc07)です。 エンジニアとして、主にHenryのレセコン(医療費・診療報酬)の開発に携わっています。

ドメインキャッチアップの重要さ、難しさ、そして楽しさ

ヘンリーで医療ドメインの理解は欠かすことができないものです。しかし、医療ドメインは情報量が多いだけでなく、読み解く必要性や、深く理解する必要性がある世界です ドメインキャッチアップの重要さや、難しさ(そして楽しさ!!)は @agatan の記事でも触れられています。

電子カルテ・医事会計システムとは、病院における業務基幹システムです。 ご存知の通り、病院にはさまざまな職種(医師、看護師、医療事務、検査技師、etc...)の方がいらっしゃいます。 専門職の方々が、互いに情報をやりとりしながらご自身の専門業務を遂行しています。 それぞれの業務は専門性の高い業務であり、単体で見ても複雑で難易度の高い一つのドメインです。 継続的に、より高い価値を届け続けるためのソフトウェアを開発するためには、そもそも開発対象を深く理解し、それをモデリングする・改善し続けることに心血を注ぐ必要があります。

Henry の開発はなにが楽しい?ソフトウェアエンジニアにとっての魅力と挑戦をご紹介します! - 株式会社ヘンリー エンジニアブログ

診療報酬制度では、保険医療の価格や、ある保険医療を実施するために医療機関が満たしているべき条件、提出すべき書類などが定められています。 ものによっては、継続的に統計データを提出する必要があったり、入院中の患者に対して日々記録を取っておく必要があったりします。 ルールの数も多いのですが、個々のルールについて読み解くのも非常に難しく、これをモデリングする作業には、パズルや謎解き的な面白さがあります。 きれいにモデリングできたときには、ものすごく気持ちよくなれます。

Henry の開発はなにが楽しい?ソフトウェアエンジニアにとっての魅力と挑戦をご紹介します! - 株式会社ヘンリー エンジニアブログ

※ 太字は私による強調

入社して3ヶ月が経ち、実体験を通じて、これらの難しさを乗り越えることの楽しさ、そして乗り越えた先の楽しさがあるのは間違いないと考えています。
しかし、同時にもっと効率的に向き合う方法はないのだろうかとも考えています。
組織としても、来年の100人採用に向けて医療ドメインの理解を効率的に進める方法が仕組みかされていることは重要であると考えています。

そんな中、今年読んだ「プログラマー脳 ~優れたプログラマーになるための認知科学に基づくアプローチ 」(以下、本書)の学びが医療ドメインの理解に応用できるのではないかと考えました。
本書は、認知科学に基づいてプログラミング時に発生する認知負荷をどのように軽減できるかを解説しており、非常に学びの多い一冊でした。
認知負荷は、プログラミングを行う際に限らず他の多くの状況でも発生する現象です。
本書で示されている考え方を転用し、医療ドメインの理解における認知負荷の軽減に応用してみようと思います。

慣れない文章を読む際に発生する問題に向き合う

本書では、まず、慣れないコードを読む際に発生する混乱は長期記憶、短期記憶、ワーキングメモリそれぞれに問題が発生すること、どのように対策できるのか述べられています。

この、慣れないコードを読むプロセスは、厚生労働省から公表される資料や診療報酬制度の文書を読むプロセスと類似していると考え、問題の理解と対策が、転用できるのではないかと考えました。

長期記憶の問題

未知の用語や略語はそれが何であるかを理解できないため、混乱の発生要因となり、理解を進める際の障壁となります。

対応策: 知っている単語や概念を増やす

対象ドメインにおいて知っていることを増やすかというシンプルな対応策です。 ヘンリーでは継続的にメンテナンスされている用語集ががあるので、それを学習に利用することが可能だと考えています。
本書では、素早く学ぶためにフラッシュカードを使うことが提案されています。

具体的なアクション

  • 用語集をフラッシュカード化し学習に利用する

短期記憶の問題

資料の一文に出てくる単語や概念の数が多いので、短期記憶にとどめておくことができず理解を妨げる傾向があります。

たとえば、以下のような文章を見たときには面食らいました。

Ⅱの規定にかかわらず、薬事法等の一部を改正する法律(平成 25 年法律第 84 号)第1条の規定 による改正前の薬事法(昭和 35 年法律第 145 号)第 14 条第1項又は医薬品、医療機器等の品質、有 効性及び安全性の確保等に関する法律(昭和 35 年法律第 145 号)第 23 条の2の5第1項の規定による承認を受け、次の表の左欄の承認番号を付与された同欄に掲げる特定保険医療材料の同表の中欄に掲げる期間における材料価格は、それぞれ同表の右欄に掲げる材料価格とする。

対応策: チャンキングをできるようになる

チャンキングとは物事を覚えるときに複数の情報を一つにまとめ、覚えるべきことの数を減らして短期記憶にとどめやすくすることです。
先程の文章であれば、以下のようにチャンキングできるようになると考えています。

- 「Ⅱ」の規定にかかわらず、
- 薬事法等の一部を改正する法律によって
- 次の表の材料価格とする。

プログラミングの場合は、私達でチャンキングしやすいようにコードを書くこと効率化を図れますが、医療ドメインの情報に関してはこの方法で効率化は図れません。
したがって、与えられた文章を如何にチャンキングできるようになるかが重要となります。

何を知っていればチャンキングができるようになるのでしょうか?
本書では、プログラミングに関する概念、データ構造、文法を知っていればいるほどコードを簡単にチャンク化できるようになると書かれています。
これを、医療ドメインのキャッチアップに転用すると以下の情報を知ることでチャンク化できるようになるのではないかと推測しています。

  1. 公表される文章のよくある構成
  2. 医療制度の背景にある考え方
  3. Henryを開発するにあたって必要な情報、あるいは不要な情報

いずれもオンボーディング時にざっくりと共有可能な情報です。
しかし、プログラミングと比べると明確な情報ではないため、チャンク化しながら文章を読む訓練もより必要であると考えています。

具体的なアクション

  • チャンク化するために有効な情報をオンボーディングで共有する
  • 公表される文章をチャンク化しながら読む訓練を行う

ワーキングメモリの問題

コードが複雑で把握する変数や状態が多いときに発生するもので、理解を妨げます。
医療ドメインにおいても同様に変数や状態が多い文章があるケースがあり、理解を妨げます。 さらに、自然言語ならではの問題として修飾されている対象が不明瞭であったり、文中で名言されていないがコンテキストから察する必要がある事象などがあり、これも理解を妨げます。

たとえば、ある公費のルールは以下のようなものです。

大阪の乳児医療は1日500円以上の場合は限度額500円までとなる(当月2日間は500円限度、それ以降は患者様請求額0円)

CodeGolfでもしたのかと思えるほど情報が削ぎ取られています。

対応策: リファクタリングする

本書では、リファクタリングがワーキングメモリの問題に効果的であることが述べられています。 医療ドメインの理解で発生する同様の問題においても、文章に対してリファクタリングが有効であるように考えられます。先のルールをリファクタリングしてみると以下のようになります。

1)ある月において1回目の外来受診日における患者の負担額は500円を上限となる。
  これは、1回目の外来受診日に複数回外来を受診したとしても、その日に患者が負担する金額は500円までになることを意味する。
2)ある月において2回目の外来受診も同様である。
3)ある月において3回目以降の外来受診に関しては負担額は0円となる。

長くはなりましたが、ルールの内容が具体的になったと思います。
一方、コードのリファクタリングがそうであるように、リファクタリング前後でルールが変わっていないことを担保する必要があります。
ヘンリーではドメインエキスパートとの協業を前提としているため、ルールが変化していないことを確認することが可能です。
ドメインの理解を進めている最中は、そもそもリファクタリングすること自体が難しい可能性はあります。その場合は、ドメインエキスパートにリファクタリングしていただくことも選択肢にあがります。

具体的なアクション

実装に落とし込むような文章・ルールに関しては、リファクタリングを行う。あるいはドメインエキスパートにリファクタリングを依頼する。

次回?

本書では、他にもメンタルモデルが認知負荷に及ぼす影響であったり、意味波(semantic wave)を踏まえた学習プロセスのアンチパターンなども紹介されています。
これらを取り入れた方法も考えているので、整理できたタイミングでまた記事を書こうと思います。

ここまで読んでいただき、ありがとうございました!

Henry の開発はなにが楽しい?ソフトウェアエンジニアにとっての魅力と挑戦をご紹介します!

こんにちは!ヘンリーでソフトウェアエンジニアをしている @agatan です。

ヘンリーでは、医事会計システム一体型の電子カルテ Henry を開発しています。

この記事では、ヘンリーでソフトウェアエンジニアとして働く上での挑戦や面白さをご紹介したいと思います。
ヘンリーの生み出すプロダクトやビジネスの社会的意義など、ヘンリーで働くモチベーションとなる要素はたくさんあるのですが、あえて今回はエンジニアリングの面白さに焦点を当てて、なぜ僕は Henry の開発を楽しいと感じているのか・どこがチャレンジングなのか、について書いてみます。 「ここが難しい!」という話が多くなっているのですが、難しさは挑戦の種でもあるので、興味を持っていただけるとうれしいです!

(また、今回はエンジニアリングに焦点を当てていますが、僕個人としては、何よりも社会的意義とそれを目指したときのビジネス面の勝ち筋がきれいに整合していることに強く惹かれています。 そういったヘンリーの魅力については、株式会社ヘンリーのカレンダー | Advent Calendar 2023 - QiitaHenry|note の記事をぜひご覧いただければと思います。)

この記事は 株式会社ヘンリー Advent Calendar 2023 20日目の記事です。19日目は 今年も組織が1.5倍に!リモートワーク中心で拡大し続けているスタートアップのコミュニケーション設計|Henry でした。 qiita.com

Henry の技術スタック

前提として Henry を構成する技術について軽くご紹介します。 (少し古い & バックエンド中心の話限定ですが)こちらに以前登壇した際の資料があります。

speakerdeck.com

上記に記載のないものも含め、粒度もバラバラにざっくりまとめると

株式会社ヘンリーの技術スタック - what we use(技術スタックデータベース) にもうすこし詳細に利用しているものが載っています。)

見ていただいて分かる通り、割と普通のWebアプリケーションの構成をしています。 電子カルテというと馴染みのなさそうな雰囲気を覚える方もいらっしゃるかもしれませんが、技術的にはやっていることは概ね普通のWebアプリケーション開発です。

dev.henry.jp

シンプルに開発が難しい!ので見せ場がたくさんある!

電子カルテ・医事会計システムとは、病院における業務基幹システムです。 ご存知の通り、病院にはさまざまな職種(医師、看護師、医療事務、検査技師、etc...)の方がいらっしゃいます。 専門職の方々が、互いに情報をやりとりしながらご自身の専門業務を遂行しています。

それぞれの業務は専門性の高い業務であり、単体で見ても複雑で難易度の高い一つのドメインです。 継続的に、より高い価値を届け続けるためのソフトウェアを開発するためには、そもそも開発対象を深く理解し、それをモデリングする・改善し続けることに心血を注ぐ必要があります。

CRUDとは一線を画す複雑さがあったり、最終的に作るものがCRUDであっても「何をCRUDするのか」を見つめ直さないと適切なモデリングにならないことが多々あります。 開発そのものが単調になることが少なく、純粋に作る部分だけを取り出しても腕の見せどころが比較的多い環境だと思います。

診療報酬制度を解きほぐす面白さ

日本には、診療報酬制度というものがあります。( なるほど診療報酬!|国民のみなさまへ|日本医師会
診療報酬制度では、保険医療の価格や、ある保険医療を実施するために医療機関が満たしているべき条件、提出すべき書類などが定められています。 ものによっては、継続的に統計データを提出する必要があったり、入院中の患者に対して日々記録を取っておく必要があったりします。

ルールの数も多いのですが、個々のルールについて読み解くのも非常に難しく、これをモデリングする作業には、パズルや謎解き的な面白さがあります。 きれいにモデリングできたときには、ものすごく気持ちよくなれます。

(また、診療報酬制度に詳しくなることは、雑学的な面白さもあります。診療報酬制度には、日本の医療の将来を見据えて方向性を示す役割があるため、これを知っておくと少し日本の将来について詳しくなった気分になることができます。)

巨大になっていくシステムをどうチームでさばくか

また、個々の業務・ドメイン単体で見た時の難易度もさることながら、ドメイン同士が深く高密度に連携している、というのも、医療の業務基幹システムの特徴です。 一人の患者に対して、様々な専門職が関わるため、それをスムーズに接続する必要があるのです。

さらにすこし違う視点から見ると、診療報酬制度を核とした結合も強く存在します。
僕自身は、診療報酬制度をもとに会計業務を行うための「医事会計システム」側のコンポーネントを開発しているのですが、診療報酬制度に関わる業務というのは、会計時だけでなく例えば日々の看護においても発生します。

そのため、きれいにシステムやチームを分割することが難しく、開発難易度を上げる要素となってしまっています。

こうしたある種偶発的な複雑さに起因する難しさは、あまり純粋に楽しめるものではないと思いますが、それを乗り越えるために改善の手を考え実行し続けるチームの存在や文化がある環境というのは、とても働きがいがあります。 チームとして、学習して手を打ち続けることが重要だと考えており、実際これまでにチーム分割やモノレポ化などの手を打ってきました。

dev.henry.jp

dev.henry.jp

また、1プロダクトでありながら実質的に複数のドメインが共存しているため、そもそもシステム自体のサイズが巨大です。

僕自身、すでに2.5年開発をしていますが、システムのすべてを把握できているかというとやや怪しく、詳しく内容を知らないコンポーネントも増えていっています。 どれも顧客にとって重要な機能であり、まだまだ足りていない機能もあるなかで、きちんと開発が健全に進んでいる証ではあります。 これも、プロダクトや組織が成長していくなかで、どのようにスケールする体制を作っていくか、という挑戦に繋がっています。

パフォーマンスの維持

業務で日々使うソフトウェアなので、当然スムーズに動作することが求められます。 Henry でもこれまで Next.js への移行などパフォーマンス向上のための手を打ってきました。

dev.henry.jp

Henry はいままでもこれからもどんどん進化していくプロダクトです。 システムの全体像を把握するのが難しいなかで、進化の過程で入る変更は、どうしても局所的な視点での変更になりがちです。

たとえば、「外来会計確定」というイベントをトリガーに走る処理は、この1年でも3,4つ増えています。 それぞれのイベントは、それぞれの業務ドメインを持っていて、 当初は1,2つ程度しかなかった処理だったために同期的に処理していたイベントでしたが、徐々に限界を迎えつつあり、根本的にアーキテクチャを見直す必要も出てきています。

また、「あっちで個別に処理していた内容を、こっちの月次一括処理でも同じことをしたい」というようなケースもあります。 診療報酬制度を中心に、業務が密結合しているため、どうしてもドメインをまたいだ共通処理が出てきてしまいます。 それぞれのドメインが十分に複雑であるため、ドメインをまたいで処理を共通化しようとしたときに、内部実装を細かく知らない状態で共通化してしまったりすると、後々パフォーマンスインシデントでえらい目にあったりします。

意識的に全体の状況を俯瞰する時間を取ることで、対処が必要であることに気づいたり、どういう手を打つべきかを考えるようにしています。 (冷静に俯瞰すれば、実際に問題になっているのは単純な N+1 だったりもするので、気づくこと・手を打つべきと判断することがメインの挑戦といえるかもしれません。)

Reliability

業務基幹システムであり、かつ医療の現場が使うサービスであることを考えると、信頼性も非常に重要です。 障害に対する備えはもちろんですが、日々の開発においても、互換性を維持したデプロイができるように意識したり、自動テストを拡充したりと、考えることがたくさんあります。

また、信頼性は高いに越したことはもちろんないのですが、ガチガチに固めればいいというわけでもありません。同時に開発生産性を高める意識をもって取り組まないと、最終的にはお客様の利益を害する結果に繋がってしまいます。我々は後発であるがゆえに、モダンな開発体制を築き、高い開発力を活かして、スピーディにサービスをより良くしていくことが求められています。

ここについては、まだまだヘンリーとしても取り組むべき課題がたくさんありますが、ポストモーテムの取り組みや障害対応のプラクティスの共有、自動テストの拡充とそのプラクティスの共有など、SREチーム / QAチームを筆頭に改善が続いています。

dev.henry.jp

dev.henry.jp

診療報酬改定

先に述べた「診療報酬制度」は、二年に一度改定されます。

改定の内容は年ごとに大小さまざまですが、Henry というプロダクトの根拠の一つである診療報酬制度が変わる、ということがプロダクトに与える影響は甚大です。(医事会計システムはもちろんですが、電子カルテ側も取る記録の内容がかわったりするため、多大な影響を受けます。)
したがって、二年に一度、(規模はそのときどきによって変わるようですが)大きな変更を迫られることになります。

さらにややこしいことに、改定後であっても、改定前の診療や会計の情報は閲覧・編集したいので、改定前の状態も同時にサポートする必要があります。 診療の記録にはデータ保全の義務があるため、データの寿命は非常に長く、互換性を維持した設計を心がける必要があります。

このあたりに気を使って開発をし、安全にリリースさせる、というのは、ソフトウェアエンジニアの腕の見せどころの一つだと思います。 (一例ですが、ダウンタイムなくデータのマイグレーションやミドルウェアのリプレースを行うために、知識や技術力を発揮することは、ソフトウェアエンジニアの本懐の一つといってもいいのではないでしょうか。)

また、まだまだ電子カルテ業界ではオンプレ・個別対応開発が主流となっています。 Henry はクラウドベースの SaaS という提供形態をとっているため、オンプレや個別対応の開発を行っているプロダクトと比較すると、明確に対応コストが下がっています。 自動テストなど、きちんと開発環境・体制のベストプラクティスを適用することで、我々の対応コストを下げると同時に、競争優位性も築くことができます。

エンジニアリングによって明確な競争優位性を作れるというのも、ヘンリーでエンジニアをする上でやりがいを感じるポイントになっています。

ドメインエキスパートとの協業を前提とした開発体制・プロセス

Henry を作るためには、非常に深いドメイン知識が求められます。 「なにを作るか」「どう作るか」「作ったものが正しく動いているか」などなど、開発を行う上で出てくるほとんどすべてのステップにおいて、ドメイン知識が求められますが、求められるドメイン知識のレベルは非常に高く、習得難易度も高いです。 (わかりやすいところでいうと、診療報酬制度をまとめた書籍「診療点数早見表 2023年4月増補版」は、1,760ページあります。)

そこで、ヘンリーでは、開発チームの中にドメインエキスパートが在籍しており、一緒になって仕様やモデリングを考えたり、動作検証をしてくれたりしています。

note.com

note.com

もちろんソフトウェアエンジニア自身もドメインを学ぶ活動は活発に実践されていますが、それでも経験豊富で強力なドメインエキスパートがいてくれることの心強さが非常に大きいです。 ドメインエキスパートが開発チーム内にいてくれるおかげで Henry の開発は進んでおり、もしドメインエキスパートがいなければ僕自身も泣きながら開発をしているのではないかと思います。 ここまで複雑でソフトウェアに落とし込む作業自体が難しい領域で、ここまでの手厚い体制が提供された状態で、エンジニアリングに向き合えるというのは、非常に希少な環境なのではないでしょうか。

さらにいえば、ヘンリーの開発体制は、まだまだドメインエキスパートのちからを最大限引き出せてはいないと感じています。 一部では、ドメインエキスパートがエンジニアの書くテストケースをレビューしたり、ドメインエキスパートが作ったテストケースを自動テストに組み込んだりするといった取り組みが進んでいますが、もっともっとこれを推し進めていくことで、直にドメインエキスパートがプロダクトを前に進められるような環境をつくれるのではないかと考えています。 まだまだ夢物語ではありますが、これが達成できれば圧倒的な強みになると思いますし、これも大きな挑戦の一つになると考えています。

データエンジニアリング

安定的に医療を提供するためにも、当然ながら病院は経営に対して関心を持っています。 また、診療報酬制度上も統計データを提出する義務があるケースがあります。 そのため、Henry に入力された・Henry が計算した情報を、さまざまな方式で分析したい、というニーズがあります。

病院ごとにさまざまなニーズがあり、分析したい内容や欲しい情報の粒度もさまざまです。 開発が加速するなかで、安定的にこういった情報を提供するためのデータエンジニアリングの部分も非常にチャレンジングです。

(まだ専任のデータエンジニアが不在の状態なので、ご興味のある方がいらっしゃいましたらお声掛けください! 現状は dbt + BigQuery での基盤を構築していますが、信頼性やドキュメンテーションなど、課題が山積みです!)

ほかにもいろいろ

細かくは書きませんが、他にもさまざまな挑戦があります。

などなど...

おわりに

ヘンリーでの開発内容については、社会的意義やビジネス上の価値はある程度外部から想像がつきそう(メンバーインタビューなどからも読み取れそう)だと思いつつ、開発そのものの日常的な面白さについては、あまり想像がつかないのではないかなと思い、あえて焦点を当ててみました。 ちょっと難しさにフォーカスが当たりすぎてしまった感もありますが、こういった挑戦はやはり純粋にソフトウェアエンジニアとしてやりがいを感じます。

少しでも興味を持っていただけた方がいらっしゃいましたら、ぜひカジュアルにお話しましょう!

jobs.henry-app.jp