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

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

要件定義失敗と改善の歴史 ~ その時、要求・ユーザーストーリーをどうまとめ、どう改善してきたか ~

こんにちは。ヘンリーCEOの逆瀬川です。

開発する上で、難しい部分の一つである要件定義。

最近、社内では「要求仕様」と呼ばれるようになり、要求仕様化のプロセスとフォーマットの改善に取り組んでいます。しかし、3年間にわたって苦労し、失敗と改善を繰り返してきた歴史があります。

本ブログでは、主にプロセスとフォーマットの失敗について触れますので、詳細は割愛します。「ココもっと深く知りたい！」という方は、ぜひカジュアルにお話しましょう。その場で深堀りいただいた内容を元に、更にブログで考察していきたいと思います。

では、過去私たちが体験した5つの時代と今後訪れるだろう要求開発黄金時代についてお話しましょう。

  1. ユースケースで仕様漏れた時代
  2. 要求導入混沌時代
  3. 要求を全員で書くぞ時代
  4. プロダクト要求と仕様を分けて書き始めた時代
  5. CSと連携して速度が上がり始めた夜明け前
  6. 将来訪れるだろう要求開発黄金時代へ

本題に入る前に

要求の難易度を理解するために、Henryについて少しだけご紹介します。

私たちは、電子カルテ・会計システムをコアとするクラウド型基幹システム「Henry」の開発をしております。複雑な診療フローと法制度の制約、多くのアクターが使うシステムになるため開発難易度が高く、実は四半世紀以上新規プレイヤーが参入してきてない業界です。

  • 開発難易度を上げる具体的な話
    • 診療報酬制度は、A4で1,700ページ以上あり、かつ2年に1度大きなルール変更がある
    • 3省2ガイドラインという官庁が出しているセキュリティ要件がある
    • 病院には、多くの診療科・病棟の種類があり、それぞれ細かいニーズが異なる
    • 入院患者さんの治療には、医者だけではなく、看護師、クラーク(医者の事務補助)、セラピスト、栄養士、薬剤師、検査技師、医療事務(会計・受付)など、多くの人が関わる
      などなど

上記の様に、基幹システムでありかつ会計の機能も開発しているシステムのため、要求をしっかり捉えることが重要になります。

事業の詳細を知りたい人は下記動画を御覧ください。

レセコン×電子カルテ スタートアップ「Henry」彼らは今、何を考えているのか〜Henry CEO 逆瀬川光人 - YouTube

1. ユースケースで仕様漏れた時代

最初にクリニック向けの電子カルテの開発では、ユースケースを詳細にまとめ、デザイナーとエンジニアがそれを読んで設計や内部仕様を決めるという流れで進めていました。

クリニック向けの開発が大きな事故なくリリースできたため、病院向けの開発が始まった当初も同じように進めましたが、病院ではアクターが多く、複数のアクターが関わるユースケースの複雑性を捉えるのに漏れなく失敗しました。

例えば、処方のオーダー(院内の指示出しと指示受けのワークフロー)という機能についても、医師や看護リーダー、現場の看護師、薬剤師、医療事務、クラークといった幅広い職種が別の理由で利用します。

要件定義で行ったこと

  • 業務ワークフローの書き起こし
  • 最小限のユーザーインタビュー
  • ユースケースの書き起こし
  • テストケースの書き起こし

何を失敗したのか

  • アクターが多く、すべてのユースケースを洗い出せなかった
  • 当人ではない相手にユーザーインタビューをしてしまい、自分がやらない業務について、想定の回答をもらってしまった。
  • ユースケースでまとめたため、プロダクトで求められる要求をMECEに整理ができなかった などなど

失敗した結果何が起こったのか

  • 一部の機能を作り直した・・・

2. 要求導入混沌時代

プロダクト要求をきちんとMECEに整理しようという気持ちになり、要求を仕様化する技術・表現する技術の輪読会をして、要求と仕様を書き始めました。どういうフォーマットにするべきか、どういう粒度で書くかをすり合わせして書き出しました。電子カルテでコアとなる入退院のモデルがあるのですが、これに関しては10回くらい書き直しています。加えて、ドメインの知識を実装するエンジニアも必要だろうということで社内勉強会で各ユースケースの説明をしていきました。完成フローやフォーマットが固まるまで地獄でしたが、光が見え始めた時代です。

要件定義で行ったこと

  • ユースケース理解の動画を作った
  • プロダクト要求を書いた
  • ドメインエキスパートを増やした
  • 難しい機能についてはユーザーインタビューとユーザーテストを行った

何を失敗したのか

  • Notionで書くフォーマットにして、MECEのチェックが難しかった
  • レビュープロセスが定まってなく、要求をどこまで書けば完成と言えるか分からなかった

失敗した結果何が起こったのか

  • 要求の完成が見えず、開発の終わりが見えない状況が続いた
    • チームにストレスをかけてしまった

3. 要求を全員で書くぞ時代

フォーマットとレビュープロセスを定めて、ある程度書けるぞとなったタイミングで要求と仕様を開発メンバー全員で書いて開発速度を早めようとTryしました。元々私とPdMロールを担う2名で書いていたのですが、様々な理由で要求がスタックすることが多くスピードを上げる施策として採用しました。

これは大きな失敗でした。そもそも、書く技術もドメイン知識もバラバラな中で全員で書けるわけがなかったのですが、
失敗に気づくのも早く、この時代は短命に終わりました。

要件定義で行ったこと

  • 要求導入混沌時代と同様

何を失敗したのか

  • ドメイン知識がないメンバーにも要求を書くのを求めてしまった
  • PdM経験などあるメンバーとないメンバーの要求化の技術力の差を考慮せずに、みんな書けることを目指してしまった

失敗した結果何が起こったのか

  • 要求が2週間程度全く進まなかった

4. プロダクト要求と仕様を分けて書き始めた時代

紆余曲折を経て、現在は要求と仕様を分けて書いています。書くツールはいろいろ試した結果、要求仕様をGoogle Spreadsheetに書き貯めています。 基本的な構成はユーザーストーリーと近く、下記構成で書いています。

  • 要求
    • それに紐づく理由
    • 紐づく仕様

要求仕様フォーマットのサンプル *1

また、レビュープロセスも要求と仕様でそれぞれ定めており、要求化→レビュー、要求の内容FIX、仕様化→レビューのサイクルを定めて、適切にレビューサイクルを回して完了できるように進めています。 プロダクトチーム内の改善がだいぶ進んで来たなと振り返ると感じます。

要件定義で行ったこと

要求導入混沌時代に加えて。。。

  • レビュープロセスを整えた
  • 要求仕様の書くフォーマットを整えた

何を失敗したのか

  • Epic単位での提供価値とユーザーのペイン・ゲインが見えづらくなった
    • プロダクト要求をきちんと書くことを意識しすぎた
  • このプロダクト要求がビジネス的にどのようなインパクトがあるのか、なぜ必要なのかというビジネス要求がわからなくなった
  • どういうものが最終的に必要なのかイメージ出来なくなった
  • 要求・仕様をきちんと書かなくて良いライトな機能についても書きすぎてしまう

失敗した結果何が起こったのか

  • 仕様を見直そうとした時に、何を基準に判断すればよいかわからない
  • 開発速度が遅れた

5. CSと連携して速度が上がり始めた夜明け前

ここでブレイクスルーが起こります。CS(カスタマーサクセス)を担当している山本さんと永井さんがエンジニアチームのDaily Stand Up等のチームアクティビティに参加し、密に連携を取り始めました。2人は実際に病院で医事課業務を行っており、ワークフローへの理解も深いです。CSメンバーが積極的に開発に関わるようになったことで開発プロセスと要求の質が劇的に向上しました。

行ったこと

  • CSのメンバーが開発チームにJOIN
  • CSがビジネス要求や不明点の収集をお願いした
  • 要求分析の相談をDailyで行った
  • 要求化のプロセスものはCSを通じてアジャイルなサイクルを回した

ポジティブな変化

  • ビジネス要求の把握がほぼリアルタイムで行えるようになった
  • 顧客インタビューや観察スピードが劇的にUPして、要求化のスピードが改善した
  • CSを通じて顧客との距離が近くなり、ライトなものはすぐ改善するサイクルが出来た(要求を書く強弱をつけられるようになった)
  • プロセス全体としてアジャイルに徐々に品質を上げていけるようになった

6. 将来訪れるだろう要求開発黄金時代へ

3年間の学びを受けて、これから改善していきたいなと考えている内容をつらつらと書きます。継続的に開発プロセスに導入することができれば良いですが、全部改善できるというわけでもないので、一つずつ改善していきたいと思っています。

これからやりたい流れ

  • ビジネス要求のデータベース化
    • プロダクト要求とビジネス要求を接続し、なぜ作るかがわかりやすく
  • 実例マッピングの導入
    • ドメインエキスパート、関係者全員で実例マッピングを行い、全員が作るもののイメージを揃えるとともに、ライトなものは要求仕様を軽めに書くなどの判断して開発スピードを上げる
  • 要求のメンテナンスのプロセス化
    • 要求が常に最新であることを保つためのプロセス設計
  • 要求とプロジェクト管理の整理
    • 要求と開発チケットを紐付け、相互リンクできるように
  • QAプロセスの改善
    • すべてのプロセスでQAを行い、品質向上を目指す

など

おわりに : アジャイルなプロセスで要求開発の質を上げつつ、スピードを担保する

要求開発は、あくまで価値提供のスピードと品質を上げるための施策に過ぎません。元々、開発内で閉じた改善活動もCSと協働することで、開発スピードが上がり、要求の質も高めることが出来ました。これからも、開発内に閉じず、会社全体で良いプロダクトを提供していくために改善していく予定ですが、要求開発とそのプロセスは重要な要素の一つであり続けると思います。
ぜひ、一緒に良いプロダクトを作りたい、そのために要求の質を上げていきたいぞっていう方がいたら、ご連絡ください。
2月末と3月頭にイベントもやるので、ワイワイ話しましょう！

henry.connpass.com

henry.connpass.com

プロセスを設計する上で参考にした書籍・リンク

www.amazon.co.jp

www.amazon.co.jp

leanpub.com

speakerdeck.com

*1:要求仕様フォーマットのサンプル

Cloud Runで動くJVMの監視にログベースの指標が便利

株式会社ヘンリーでSREをやっているTODA（@Kengo_TODA）です。弊社ではGoogle Cloud Platform（GCP）を活用してサービスを構築しており、またサーバサイドにはKotlinを利用しています。Cloud Runで動くJVMサービスの監視にログベースの指標が便利だったので紹介します。

何をもってJVMで駆動するサービスを「メモリが足りていない」と判断するか

Cloud Runのメモリ監視で最も利用しやすいのは、Cloud Monitoringでメモリ利用率などを見ることでしょう。次に示す図のように、サービスごとのデータを取ってグラフ化できます。

図１　メモリ利用率をプロットしてみた

ではこのグラフから何がわかるのでしょうか？例えば下側に紫色で示されたCloud Runサービスはメモリにずいぶんと余裕がありそうです。常時この状態であれば、メモリ割当量を減らしても良さそうですね。

反面上側にオレンジ色で示されたCloud Runサービスは、だいぶメモリを使っています。しかし、これをもって「メモリが足りないので増やす」判断を下すことはできません。JVMで動いているサービスは、Javaヒープなどの領域がどのように使われているか・フルGCがどの程度生じているのかを分析して初めて「メモリが足りているかどうか」判断できるからです。

単にメモリの利用率だけを監視すると、むしろ理想的にメモリを活用できているサービスを”犯人”だとしてしまう可能性があります。実際弊社でもユーザ増加に起因するメモリ利用量増加によって、一部サービスが頻繁にアラートを投げるようになりました。

フルGCの回数を数える

それでは対象のCloud Runサービスで、どのくらいフルGCが実行されているのか数えてみましょう。

GCの発生回数を取得するには、まずGC実行記録をログを出すようにします。最新のJVMで必要な設定は久保田さんのUnified JVM Loggingに詳しく説明されていて、弊社では -Xlog:gc をJVM起動オプションに追加しました。この設定により、以下のようなログがCloud Loggingに出力されます：

[4204.610s][info][gc] GC(223) Pause Young (Allocation Failure) 139M->72M(247M) 4.592ms
[4077.128s][info][gc] GC(217) Pause Full (Allocation Failure) 176M->62M(250M) 302.523ms

こうしたログがあれば、grepやwcを組み合わせてフルGC回数を数えることはできそうに感じませんか？GCPの「ログベースの指標」はこうしたニーズの面倒を見てくれます。例えばTerraformなら以下のように設定すると、対象サービスのフルGC回数を数えられます:

resource "google_logging_metric" "full_gc" {
  name        = "${google_cloud_run_service.service.name}-full-gc"
  description = "The full GC (G1GC) triggered in the target JVM"
  filter = join(" AND ", [
    "resource.type=\"cloud_run_revision\"",
    "resource.labels.service_name=\"${google_cloud_run_service.service.name}\"",
    "textPayload:\"[gc]\"",
    "textPayload:\"Pause Full\"",
  ])
  metric_descriptor {
    metric_kind = "DELTA"
    value_type  = "INT64"
  }
}

更にMetrics Explorerを使うとグラフ化もできます。弊社の事例では、時間帯によってフルGCが生じているものの最頻値でも1分に1回程度であり、余裕はあると判断しました：

図２　フルGC回数を数えてみた

フルGCが頻繁に実行されたらSlackに通知を投げる

さて今は余裕があるとしても、今後負荷が増えてフルGCが増えてくる可能性もあります。よってフルGCの頻度が増えたらSlackに通知を投げるようにしておきましょう。これはCloud Monitoring Alertsによって実現できます。

今回はサービスごとのフルGC回数を数え、5分間に10回以上のフルGCが実行された場合にアラートを投げるようにしました。ケースによってはコンテナインスタンスごとにフルGCを数えても丁寧で良いと思います。

resource "google_monitoring_alert_policy" "full_gc" {
  display_name = "[${var.env}] Frequent Full GC (${google_cloud_run_service.service.name})"
  combiner     = "OR"
  conditions {
    display_name = "Full GCが5分間に10回以上実行されました。"
    condition_threshold {
      filter = join(" AND ", [
        "metric.type=\"logging.googleapis.com/user/${google_logging_metric.full_gc.name}\"",
        "resource.type=\"cloud_run_revision\""
      ])
      threshold_value = 9
      duration        = "300s"
      comparison      = "COMPARISON_GT"
      aggregations {
        alignment_period     = "60s"
        cross_series_reducer = "REDUCE_SUM"
        per_series_aligner   = "ALIGN_SUM"
      }
    }
  }

  notification_channels = [
    var.notification_channel,
  ]
}

まとめ

Cloud Runで動くJVMの監視では、単にメモリ利用率だけ見てしまうとノイズが多くなることを見てきました。 これを踏まえてフルGCの頻度を監視し、高頻度のGCを検知したらSlackにアラートを投げるように変更したことで、ノイズを減らしてより本質的な監視ができるようになったと感じています。

ヘンリーは顧客と同僚の体験を改善していきたい仲間を絶賛採用しております。急拡大するチームを支えるリリース体制を実現したい方、品質保証プロセスの理想を踏まえた開発体制構築に関心のある方は気軽にご連絡ください。お待ちしています！

jobs.henry-app.jp

ヘンリーはQAに注力していくぞ！

はじめまして。ヘンリー CEOの逆瀬川です。
タイトル通り、今年は会社としてQA(Quality Assurance)の向上に注力していきます。
今までも要求開発やテストなどの改善を行ってきましたが、今年は会社としてより一層注力していきたく、改めてここに宣言します。

医療業界において求められるQA基準

弊社は、医療機関向けの基幹システムとして、電子カルテと医療会計システム(レセプトコンピューター、通称レセコン)を開発している会社です。
医療機関において、電子カルテと医療会計システムは業務上で欠かせないシステムです。システムトラブルで実際の業務が止まり、新規患者受付を一時的に停止したといった最悪の事態につながる可能性があり、より安定性の高いシステムを提供していく必要があります。

また、電子カルテでは患者さんへの治療方針と指示、記録等を残すシステムです。投薬量を間違えるなどと操作ミスが患者さんの命を危険にさらすリスクもあります。

医療機関目線で言うと、医療機関は命を扱う現場であるため各医療機関は日々、「医療安全対策」 をしています。患者さんの安全を最優先に考えた業務プロセスの設計や、院内での研修や啓蒙活動が行われています。

医療安全の例

全社をあげたQA活動を

上記の様に、基幹システムであることとお客様の業務の特異性から、求められるQAの基準は大変高く、プロダクトだけではなくプロダクトを利用したワークフローやオペレーションレベルで高い品質の実現が求められます。

まだまだ理想とするレベルには程遠いですが、着実に前に進むべくプロダクトチームだけではなく、営業、カスタマーサクセス、コーポレートと一丸となって、お客様の医療安全の実現に向けたQA活動を行っていきたいと思っています。現在イメージしている各ロールの役割分担は下記の通りです。

  1. 営業 → 顧客への啓蒙
  2. カスタマーサクセス → 現場、ワークフローやオペレーションへの落とし込み
  3. プロダクト → 安定性の高いプロダクトの実現
  4. コーポレート → ガイドライン・規約等への反映

現在地と今年の目標

今までは重要性を感じつつも投資できてなかった、というのが正直なところです。専任のQAメンバーもおらず、各自が勉強し試行錯誤しながら施策を導入している状況です。

昨年まず、外部の講師を読んで勉強会をしたり、要求開発の勉強会をするなどして、要求仕様での検証やテストの改善などを行ってきました。また、外部の検証会社にお願いしていたリリース前の動作確認を内製化し、リグレッションテストの充実も図っています。今年に入ってからは、リグレッションテストの自動化やテスト戦略の設計なども開始しました。

今まで行った取り組み

今年開始した取り組み

見えてきた課題

リリース当初よりだいぶ状況は良くなってきていますが、手探りで進めているため、発生した課題ベースや各個人の興味をベースに改善している傾向があります。そのため、本質的なアプローチが出来ておらず、改善速度が早いとは言えない状況です。また、プロダクトチームに閉じた活動になっており、ビジネス系も含めたアクションプランに落とし込めてない状況です。
ただ、KPT等でQAに関連するトピックが上がる頻度は上がってきていてみんな強い関心をもって取り組もうとしています。QAリードの人がJOINして、全体ディレクションをしてくれたらうまくいく！！というイメージが湧いてきています。(ヘンリーのエンジニアは学習欲が強く、新しい取り組みには協力的です。)

今年の目標

  • QAリードの採用
  • QA戦略の策定
  • 全エンジニアがQA活動を改善している状態の実現
  • ワークフローへの落とし込み 等

上記のように、取り組み自体は徐々に増えていますが、会社が提供したいレベルとのギャップは大きく、この取組みに賛同してくれる素晴らしい仲間を見つけ、活動を加速していきたいと思っております！
ぜひ、1人目QAリードに興味があるよという方はお気軽にお声掛けください。 一方で、新しい仲間が入るまでにやらなくていいということではなく、出来るところからAgileに改善していきます。

jobs.henry-app.jp

ヘンリーの技術スタックの概観と展望

株式会社ヘンリーVPoEの@shenyu_cyanです。2023年が始まり、当社の新しい取り組みとしてエンジニアリングブログを始めました。

私たちは「社会課題を解決し続け、より良いセカイを創る」をミッションにプロダクトを開発しています。その第一歩として現在はクリニック・中小病院向けの基幹システムであるクラウド型電子カルテ・レセプトシステム「Henry」を展開しています。

技術ブログの初投稿として、今回はヘンリーが利用している技術スタックおよびその裏の考え方をご紹介し、これからの方向性について書かせていただきます。

ヘンリーの技術スタックを簡単にご紹介しますが、フロントエンドはReact+TypeScriptを採用し、その裏にBFFを設け、GraphQLで通信を行なっています。そして、BFFとバックエンドの各サービス、バックエンドのサービス同士はgRPCでやりとりをします。バックエンドは主にKotlinを採用し（一部はNode.js）、インフラ層はGoogle Cloud Platform（GCP）に統一しています。具体的に採用している技術スタックはwhat we useにて詳しく掲載しているので、ご興味のある方はぜひご覧ください。

さて、ヘンリーはなぜ今の技術スタックを採用しているのか、その裏には3本の柱があると考えています。

開発者体験の良さ

これまでのソフトウェアエンジニアリング界隈での実体験として、使いたい気持ちこそ開発効率向上の源泉だと感じています（ソフトウェアの世界に限らない話しかもしれませんが）。そのため、開発者体験の良さは非常に大切にしています。開発者体験をプロセスベースでざっくり3分割すれば、導入・使用・メンテナンスになると思います。

まず導入というプロセスにおける良い開発者体験はどんなイメージでしょうか？やはりエコシステムは重要な角度だと思います。ドキュメントやサンプルコード、プラグインのような周辺プロジェクトの数とクオリティは導入時の体験を大きく左右します。そのため、我々はエコシステムの充実さに定評があるReactやTerraform等を採用し、その利点を享受してきました。

また、使用時の良い体験、すなわち使いやすさが同じく重要です。例えば弊社はKotlinを採用していますが、標準ライブラリの豊富さはヘンリーのエンジニアの中で好評を博し、開発効率の向上に直結しています。さらに、JVM系言語の特徴としてテストライブラリの充実さがあり、ヘンリーはそれらを活用し、コミュニケーションコストの低減にもつなげています。

通信プロトコル周りはもう一つの例です。ヘンリーではGraphQL、gRPCとRestful APIを採用していますが、いずれもスキーマ駆動の仕組みを導入し、重複作業を無くし、開発者体験の向上を図りました。そのおかげで、コード自動生成はもちろん、仕様書も自動作成できるため社内向けリファレンスサイトを実現できました。

最後はメンテナンスしやすさです。前述の通り、ヘンリーはGCPを採用しています。GCPの各ソリューションの中でもなるべくマネージドサービスを利用しています。例えばヘンリーのバックエンドサービスはすべてCloud Runを利用し、手動メンテナンスの必要性を抑えています。また、SentryやOpenTelemetryといった技術を積極的に導入し、異常を検知しやすく障害時の原因調査を行いやすくするためにObservabilityを重要視しています。

一方、開発者体験に関して工夫すべきところはまだたくさんあります。まずFour Keysを始めとするメトリックスをベースに運用する仕組みを構築し、改善のイテレーションを回す基盤を設けて行きたいと思っています。例えば、直近の課題として、各サービスのインタフェース管理が密結合になってしまっている為、Deployment FrequencyとLead Time for Changesに悪影響を及ぼしているのでこれから改善していきたいと考えています。開発者体験は重要性が高く伸びしろの大きいポイントなので、イテレーションごとの収穫が多く見込めると感じます。

ユーザー体験への追及

使いたい気持ちが開発効率向上の源泉だとすれば、ユーザー体験こそヘンリーの競争優位性の源泉だと私たちは考えています。よって、ヘンリーではユーザー体験への追及を支えるためにさまざまな技術を活用してきました。

ユーザー体験を向上させるのに、細部への拘りが欠かせません。例えば、ヘンリーでは複数の医療スタッフがスムーズにドラッグ・アンド・ドロップを行い、自由自在に記述できるカルテエディターを仕上げるために、Draft.jsなど多くのソリューションを実験した末、Yjs+ProseMirrorを活用した自作エディターを実装しています。そのほか、react-routerやreact-navigationの利用をやめ、ルーターライブラリを自作する事例など、ユーザー体験向上に繋がる技術選定を繰り返してきました。

また、統一性の担保もユーザ体験に関わる重要なテーマだと感じています。ヘンリーでは、Figmaでデザインシステムを構築し、Styled ComponentsとStoryBookを活用し、コンポーネントごとのユーザー体験の一致性を担保しています。

ヘンリーのデザインシステム
ヘンリーのデザインシステム

とはいえ、それらはあくまで表面上の工夫だと私たちは思います。より根本からユーザー体験を追及するために、UXリサーチからスタートしたプロトタイピングのフローを回しやすくしていきたいです。そのために、技術面では機能モジュールごとのテスタビリティを高め、フロントエンドのコンポーネントやバックエンドのドメインモデルの粒度と独立性を整備する必要があります。さらに、価値検証を行いやすくする為にフィーチャーフラグAPI化といった現実的な技術課題から機能ごとの開発フロー構築という体制改善まで努力する必要があります。克服しなければいけないチャレンジが多く、難しい挑戦だとは思いますが、医療DXのセンターピンである電子カルテ・レセプトコンピューターなので毎回毎回のチャレンジが着実に医療DXの加速化につながると考えたら胸が熱くなります。

スケールアウトしやすさ

私たちはより良いセカイを創るために社会課題を解決し続けることに力を入れていますが、今の規模感では社会課題を解決し続けるのに力不足を感じています。そのため、もっともっと多くの優秀な仲間にご参画いただくことが不可欠だと考えています。必然的に、組織とシステムのスケールアウトに備えた技術スタックの検討が必要です。

新しいメンバーがスムーズにキャッチアップできるよう、多くの方にとって馴染みのあるツールを優先的に採用しています。例えば、コード管理はGitHubを採用し、デザインツールはFigmaを利用しています。

加えて、大規模な開発でも生産性が落ちにくい型付け言語の採用を徹底しています。もちろん、ソフトウェアのチーム開発において、型だけでは担保できない部分が多々あります。オンボーディング負荷の低減と機械的に発見可能な負債の抑制のためにDetektのような静的分析ツールを導入したり、EOLもしくは脆弱性のあるライブラリを排除するためにRenovateやSocket Securityを導入しています。

CIによるチェック
CIによるチェック

ヘンリーが今Cloud RunやCloud Storage等のサービスを利用しているおかげで理論上スケールアウトしやすいインフラになっていますが、実運用に耐えられるプロダクトにするためにデータの構造やオペレーション整備の観点から工夫しなければいけないポイントはまだまだ残っています。

また、組織のスケールアウトによって、各チームがそれぞれの実情に合わせた技術の判断を下すシチュエーションが増えていくと思います。一方、自由度が高すぎますと、横断的なアクティビティがやりづらくなり、技術面のオーバーヘッドが増えるデメリットが出てきます。良いバランスを保つためのチューニングが大きな挑戦であり、エンジニアにとって腕の利くところだと考えます。

各ソフトウェアプロジェクトの発展状況や組織の規模感によって、弊社技術スタックの移り変わりが予見できます。しかし弊社の行動指針「顧客の成果にこだわろう！」でも語られているように、プロダクトチームの思想の根幹に「ビジネスバリュー提供へのフォーカス」という核心があります。そのため、今後ヘンリーの開発チームが技術スタックの新規選定や置き換えを行う際に、その思想からブレることはないでしょう。

それに、今のスケールアウト速度で試算したらヘンリーという組織だけでは世の中の負をすべて解消することは不可能でしょう。そのため、ヘンリーは今後もっとコミュニティにフィードバックし、私たちが蓄積してきた失敗談や技術ノウハウをよく多くの方にシェアし、課題解決に活用いただくことを目指しています。このエンジニアリングブログはまさにその一環です。

2023年残り約11ヶ月、ヘンリーのプロダクトチームにとって飛躍的な一年でありますように我々は頑張っていきます。もしこの記事を通してヘンリーに少しでもご興味が湧きましたら、ぜひ下記のリンクよりお話しの時間を調整させてください。お待ちしております。

jobs.henry-app.jp