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

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

Advent Calendar 2023をやるので2023年を振り返ってみます

💡 こちらは株式会社ヘンリー Advent Calendar 2023の第1日目の記事です。

ヘンリーエンジニアブログ初回の記事がリリースされて300日余り経ち、この間計18エントリーが公開されました。数はそれほど多くないですが、年初公言していた「蓄積してきた失敗談や技術ノウハウのシェア」はある程度行えたのではないかと思われます。そして、この12月、さらにシェアを増やすべく、有志の企画によりヘンリー史上初のアドベントカレンダーを行うことになりました。僭越ながら今回は引き続き私、VPoEのshenyu_cyanよりトップバッターを務めさせていただきます。

年初の記事では開発者体験、ユーザー体験とスケールアウトの3側面から展望を述べさせていただきましたので、今回はこの3側面から振り返らせていただきます。

DALL·E作アドベントカレンダーイメージ図

スケールアウト

初めからはわかりやすいスケールアウトの話よりスタートします。スケールアウトの観点で考えるとき、人数と事業の二角度が視点に含まれていると思われます。事業の成長によって人数を増やす判断につながり、人数の増加によって事業の可能性が広がる為、両者は切っても切り離せない相互依存の関係だと考えられます。

まず人数の増加によるスケールアウトの施策が実施されました。イメージしていただくために最も集計しやすい客観的データを上げますと、ヘンリーの正社員数は2022年12月31日時点27名でしたが、2024年1月1日には50名以上になる見込みです。プロダウト開発のメンバーに絞ってみても17名から30名になるので傾向が同じく、ほぼ倍増として捉えられます。

そういう背景の中で、チーム構成とアプリケーションアーキテクチャの再編が不可欠になり、プロダクトチームに関する大きな再編が計2回行われました。開発時にますます痛感する認知過負荷を解消するために、4月に開発チームの分界点を見直し、コンプリケイテッド・サブシステムを解除した上ストリームアラインドチームを2つ立ち上げることにしました。また、8月にプロダクト組織内の役割分担を見直し、それぞれのロールを再調整しました。例えば、より抽象的な課題に取り組むCTO室の新設やカスタマーサクセス関係の開発機能の分割はまさにその時から始めました。その中、VPoEの業務範囲を合わせて広げるようにし、開発組織の価値を引き上げ続けるロールと仕組みの展開にフォーカスするロールへ分けました。

アプリケーションアーキテクチャの再編は4月のチーム再編と同時に行われていたため、解きたい課題がつながっていました。正確な分界点をより簡単に探り出せ、効率的に試行錯誤を繰り返せるようにしたく、マルチリポからモノリポへの移行を実施しました。技術面でのしっかりとした準備のおかげでスムーズな移行が達成できました。

組織とアーキテクチャの再編について、正解がわかっているわけでなく、みんなで一緒に手探りしながら実施している中で、来年以降振り返ってみたら微妙だったという所感が全然あり得ます。それでもバリューの「ドオープン」の元で、ADR(Architecture Decision Records)の役割と同じようにブログや社内Notionにちゃんと記録を残し、苦労の実体験を今後のヒントに繋げていけたらと考えます。

ユーザー体験

ヘンリーではUI/UXのガイドラインと製品コンセプトを掲げた上プロダクトの開発を進め、ユーザー体験の一貫性を保ちながらプロダクトの進化を目指しています。ユーザー体験を追求する中、今社内で最もよく使われている言葉はジョブ理論の「ジョブ」です。聞き慣れていない方も多いと思いますが、我々の中では達成したいこと(WillとWant)と解釈しています。

社内の説明用スライド抜粋

院長や看護師長、医事課長の方々にご協力を仰ぎ、医療機関の各ロールがやっていることと実現したいことを整理し、各ジョブの落とし込みを行いました。それらの実用化はまだこれからですが、プロダクト作りにきちんと反映していけたらと考えています。

また、実践面でも多くの工夫を重ねてきました。例えば、ヘンリーのプロダクトはもともと純React SPAでしたが、利用時の待ち時間によるストレスを解消すべく、Next.jsの導入に至りました。アーキテクチャも変わった大きめの変更でしたが、事前検証と同時期に導入され始めたMablのおかげで大きな不具合が現れませんでした。さらにフロントエンドのルーター部分に関して、React Suspenseを利用することになり、遷移体験が向上しました。

上記のようなわかりやすいユーザ体験向上と別に、常にヘンリーを満足して利用いただくために、適切なサポートが不可欠です。お客様からの問い合わせが来た場合、状況を迅速に理解するために、2つの側面から工夫を行いました。まず、サービス上の画面操作を記録するブラウザ拡張機能を提供し、お客様端末側の事象を特定しやすくしました(技術詳細については後日のAdvent Calendarにて公開予定)。同時に、プロダクトの可観測性向上を繰り返して行い、裏側の改善もしっかりと進めました。とはいえ、改善余地はまだたくさん残っていると考えています。これからはより手を広げ、可観測性関連ツールの活用を検討していく予定です。

開発者体験

開発者体験に関して、引き続き重要視しながら技術選定をしていると感じます。年初以降の技術スタック変化に関して、速度向上とDoppelgangers問題解消のためにpnpmの導入を実施したり、コンポーネントテスト作成の省力化を実現するためにChromaticを導入したことはまさに好例だと考えます。上記のNext.jsの導入の場合でも、開発者体験の向上を一要因として上げていました。

多くの改善のうち、ChatOpsの推進によってもたらされた開発者体験の向上は、触れなければいけないと考えます。例えば、ヘンリーではセキュリティ担保のためにGoogle CloudPlatform周りのスーパーユーザ権限を付与しない運用になっています。そのため、インフラに関する一時的な変更などを行いたい場合、専用リポジトリに対してPull Requestを送り、権限をもらう必要があります。そういった権限申請をSlackで半自動的に実施可能になったおかげで、わざわざGitHub上からPull Requestを作成する手間が減り、レコードも取りやすくなりました。

それに、ツールによる開発者体験の向上はもちろん大事ですが、人数が増えてきている中、技術トピックに関する交流の促進はもう一つ大事なテーマになってきます。ありがたいことに、有志による社内技術勉強会が企画され、コンテンツが多種多様で、私を含む多くの方にとって毎週の楽しみになっています。

社内技術勉強会のコンテンツ

加えて輪読会も継続的に開催され、「オブザーバビリティ・エンジニアリング」や「ソフトウェア見積り」のような名作が続々と今年の輪読会にて読破されました。輪読会形式なので、本の内容より行われた議論は最も多くの収穫につながったと感じますので、そのメリットをちゃんと享受できるようにしていきたいと思います。

振り返ってみて

2023年はまだ残り1ヶ月ではありますが、振り返ってみたら私個人にとっても、ヘンリーの組織にとっても変化の激しく、学びの多い一年になっていると考えます。

まず私の仕事の幅が大きく広がったため、これまで触れようと思わなかった知識や経験にたっぷり触れるきっかけが多く生まれました。私は元々技術畑の人間であり、ヘンリーに参画して以来は主に開発組織のチーム作りを行ってきました。しかし今は開発組織のみならず、全社範囲の組織作りに携わっています。職種とメンバー構成の違いによって、必要になってくる設計思想が異なります。手探りをしながら、実践と学習のループを回しています。

組織の角度から考えた場合、新しい仲間の参画によりもたらされた変化が最も学びのきっかけになっていたと感じます。前述のように、人員拡大によって組織の再構築およびチューニングの繰り返しが必然となり、そのプロセスからたくさんの経験が生まれました。特に今の主力製品である中小病院様向けのHenryが今年の年初にリリースされたばかりと考えたら変化の目紛しさが非常に印象的で、感慨無量と言えます。

また、新しい仲間の加入は新しい考え方をもたらしてくれました。ヘンリーに入社する方にはミッションである「社会課題を解決し続け、より良い世界をつくる」とバリューの「理想駆動・爆速アウトプット・ドオープン」への共感を求めていますが、みなさんの人生経験やこれまで歩んできたキャリアがそれぞれなので、性格がもちろん多種多様です。そこで異なる思想の交流による考え方の火花が生まれ、数多くの創意工夫や変則的な思考に繋がりました。今日から25日までの記事はある意味その体現だと考えています。ぜひ毎日の記事をチェックして頂き、交流を深められたら幸いです。

OpenTelemetry Meetup 2023-10 で登壇しました

ヘンリーで SRE をやっている id:nabeop です。2023/10/19 に開催された OpenTelemetry Meetup 2023-10に登壇したので感想とフォローアップエントリです。

まず、Meetup の企画をしていただいた運営のみなさま、素敵な会場やオンライン中継をご提供いただいた CARTA HOLDINGS 様に感謝します。本当にありがとうございました。当日は久しぶりにたくさんの聴講があるイベントの登壇で緊張しましたが、素晴らしい発表も聴けてとても実りが多い Meetup でした。

登壇内容

今回の登壇資料は Speakerdeck にアップロードしています。

speakerdeck.com

今回は時間の関係で複数のアプローチを PoC 環境で構築しての比較までしか共有できませんでしたが、社内では引き続き OpenTelemetry の構成見直しは進んでいて、近いうちにサービス環境の OpenTelemetry 周りの構成を入れ替えて、可観測性の向上に繋げたいと思っています。このあたりはまた機会をみつけて、得られた知見をみなさんにお届けしたいと考えています。

さて、今回の発表ではお金の話が目立ってしまいました。確かに Cloud Native な環境で可観測性を獲得するためにはそれなりのコストがかかります。しかし、抽象度の高い PaaS などの環境に構築された複数のコンポーネントが複雑に関連していることが前提になってきている場合は何らかの手段によって可観測性を高めるための手段の導入はサービスの安定性の維持には必要不可欠です。

実際に我々も OpenTelemetry は導入していて、可視化されたトレース情報による恩恵を実感したものの、保存されているトレース情報に課題感を感じたので、今回の見直しをしています。今回の発表のように導入にはいくつかのアプローチが存在し、それぞれにコスト面でのメリットとデメリットがあります。他にも運用面や開発面でのメリットとデメリットがあります。それぞれの環境でバランスが良い選択があるはずなので、今回の発表が選択時の参考になれば嬉しいです。

僕以外の方の発表内容もとても参考になって、@ymotongpoo さんの OpenTelemetryのここ4年の流れは OpenTelemtry が登場した背景を丁寧に解説していただけたので、自分の中の知識も整理できて助かりました。とくに OpenTelemetry が設立された背景は全く追えてなかったのでよかったです。

また、逆井さんジョインしたチームのマイクロサービスたちを再計装した話は、ちょうど僕らも PoC が終わった後には計装の詳細を詰めていく必要があるので、実務の経験からくる知見はとてもありがたかったです。このあたりの知見は日本語ではまだまだ出てきていないので、僕らも同じように知見が共有できるようにしたいとう思いを改めて実感しました。

Q&A セッションで話題に出ていた exampler については僕も全然知らない話題だったので、配信のアーカイブなどで復習したいですね。

今後

今はインフラ面の構成方針はおおまかにはきまっていて、あとは細かい構成の調整や計装内容について検討しているところです。遅くとも今年中には本格的に稼働を開始して運用知見を貯めるフェーズにしたいと考えています。

ヘンリーでは Observability の整備の他にも複雑なシステムに正面から向き合って、社会課題を解決していく仲間を募集しています。興味のあるかたはぜひご連絡ください。

jobs.henry-app.jp

ダブルVPoEが取り組むチーム作りとは?急拡大するヘンリーの“芯”|ヘンリーという組織を紐解く

株式会社ヘンリーは、「社会課題を解決し続け、より良いセカイを創る」というMissionのもと、中小病院向けの基幹システムであるクラウド型電子カルテ・レセプトシステム「Henry」を開発・展開しています。

2023年2月には中小病院向けプロダクトをリリースし、事業の成長とともに組織の急拡大を図るフェーズに入ったヘンリー。8月からはVPoEを2人体制とし、エンジニアの採用・育成・評価などを強化していくことになりました。

今回は、ダブルVPoEとして開発組織のチーム作りに携わる張沈宇(Cyan:シアン)さん松木雅幸(Songmu:ソンム―)さんのお二人にお話を伺いました。ヘンリーがチーム作りにおいて大切にしていることや、今後の急拡大において注意すべきこととは、一体何なのでしょうか。

シアン(左)とソンムー(右)

組織拡大に伴う課題を解決するため、ダブルVPoEに

─ 今回、VPoEが2人体制になったのはなぜですか?

シアン:ヘンリーでは、2024年末までにフルコミット(週3日以上、計24時間以上勤務の従業員。2023年10月現在で47名)の数を100人以上にまで増やしていこうと計画しています。その計画通りに進めていくために必要な採用力を強化したり、組織が大きくなるにつれて出てきてしまいそうな課題をどんどん倒していくためには、VPoEが私1人では手が足りませんでした。

また、ヘンリーはエンジニア市場における存在感がまだまだ弱く、良さを知ってもらうための発信も必要だと感じていました。ソンム―は発信力を持っていますし、そういった面でも強みが発揮できるということもあって、ダブルVPoEという体制を作ることになったんです。

ソンム―:ヘンリーは今年の2月に中小病院向けのプロダクトをリリースし、今ではその手応えも感じられるようになってきました。ただ、そのプロダクトや事業の成長に合わせて、組織もどんどん拡大・成長させていかなければならない。そこが課題として出てきそうだと認識していますし、エンジニア採用や組織作りの面でやるべきこともたくさんあります。

つまり、採用力を高めてプロダクトチームの採用速度を上げ、組織を急速に拡大させていく必要があるのです。そこで、採用や組織作りに関わってきた私がVPoEになって、2人体制で進めていくことになりました。

─ お二人の役割分担について教えてください。

ソンム―:私は主にプロダクトチームの採用と技術広報、ヘルスチェックをメインに行っています。エンジニアの採用自体はもともとシアンがやっていたのですが、VPoEになって引き継ぎました。これまで私がやってきたことを生かしながら、開発組織をより良くしていくのが私の役割だと考えています。

シアン:私はプロダクトチームだけでなく、全体的な採用に関わるようになりました。必ず選考フローのどこかで顔を出す、という形ですね。ただ、業務内容としては採用をメインに行っているわけではありません。

社内外への広報やオンボーディング、目標設定など全社の施策に対して広く浅く携わり、どちらかというと採用より後の段階で、文化作りや仕組み作りの部分に関して動いているようなイメージです。

バリューを大事に、生き生きと社会課題に向き合うチーム

─ 現在のヘンリーは、VPoEの立場から見てどんなチームだと感じますか?

シアン:「生き生きしているチーム」だと思います。そしてメンバーがちゃんとプロダクトの価値を認識していて、自分たちの仕事によって社会に貢献していくぞという想いを強く持っています。

それが顧客の本質的なニーズや課題を深掘りして、その課題を解決するためのソリューションとしてプロダクトを提供しよう、という動きにつながっているのがヘンリーというチームが持つ強みなのではないでしょうか。

ただ、人が増えてチームも複数に分かれてきたことで、チーム間でのコミュニケーションが不足している部分は課題だと感じています。チームをまたいでフィードバックしあうような仕組みを作って、人が増えても組織全体で一体となって動けるように改善していきたいですね。

ソンム―:私もそう思います。ヘンリーのミッションが「社会課題を解決し続け、より良いセカイを創る」だからということもあり、ちゃんとチームで課題解決していこうと思って入社されている方ばかりなので、素敵な人が揃ったすごくいいチームだなと感じますね。

あとは私たちのバリューに「理想駆動」「爆速アウトプット」「ドオープン」という3つの考え方があるのですが、特に「ドオープン」の情報をオープンにする文化は、今いるメンバーと今後入ってくる方とで意識の差が生まれてくるのではないかと懸念しています。

そのあたりもちゃんと組織全体でエンジニアリング的に駆動していくことが、今後大事になりそうです。

─ チーム作りを行っていく中で、お二人が大切にされているポイントについて教えてください。

ソンム―:私たちはまだ小さいスタートアップ企業です。だからこそ、メンバーの中で「ヘンリーが世の中にどういう価値を提供しているのか」という目線を揃えることが大切だと思っています。

その上で、気持ちよく働いてもらえる環境を整えていくことが必要なのではないでしょうか。

シアン:その通りですね。事業だけが成長していくのではなく、事業とともに急成長できる組織を実現したいという観点も大切にしています。さらに言えば、事業がうまくいかなかったケースのことも考える必要がありますよね。

ソンム―:事業が苦しい時はきっとどうしてもやってきますが、そこで大事になってくるのがミッションやバリューといった文化だと思います。自分たちの行動指針や価値基準がきちんと浸透していれば、たとえ事業が苦しくても、人がどんどん抜けていって組織ごと崩壊する、といったことにはなりにくいのかなと。

─ バリュー浸透のために行われている取り組みはありますか?

シアン:「理想駆動」「爆速アウトプット」「ドオープン」3つのバリューを社内のSlackスタンプにして、みんなで使うようにしています。定例ミーティングの中では、最近スタンプが押されていたスレッドを発表して、バリューを意識してもらう取り組みも行っています。

ソンム―:バリューはちゃんと解釈することがすごく大事で、「これは理想駆動/爆速アウトプット/ドオープンを体現してるよね」とすり合わせていくことで文化が醸成されて認識が揃っていくのだと思うので、Slackのスタンプはいい施策だなと感じています。

バリューは自分たちが行動するときや、どういう人と働きたいか、どういう人が評価されてほしいか、といった部分を映す鏡であると思うので、大事にしながらアップデートしていきたいですね。

オンボーディングコンテンツもさらに強化

─ では、働きやすい環境を整えるためにやっていること・今後やっていくことはありますか?

シアン:今はオンボーディングにすごく力を入れていますね。入社する前の段階からどんな体験を提供したらスムーズにキャッチアップできるのか、入社した後は一人前になるまでどのようにサポートしていくのか、その後も継続的に生産性を向上させていくためには、といったことがヘンリーでの働きやすさに関わってくるので、全方面で設計を進めています。

─ オンボーディングの施策について、もう少し詳しくお聞かせください。

シアン:今やっているオンボーディングのコンテンツとしては、Notionに各自1つオンボーディングシートを作成して、取り組むべきタスクをチェックリストにしています。入社1日目には何をすべきか、最初の1週間ではこういうことをやって、といったタスクをこなしていって、その中でいろんな情報をキャッチアップしていくというイメージです。

Notionのオンボーディングシート

ただ、医療ドメインは複雑で深い世界なので、病院での実際のオペレーションやワークフローなどの実践的な知識も含め、もう少し踏み込んだオンボーディングをしなければなりません。今はそのあたりを整理・設計している段階ですね。

やるべきことの数が多くなってくると、今のようにチェックリストでこなしていくのは結構大変なので、ゲーム感覚でクリアしていけるように設計することを心がけています。ここはずっとブラッシュアップし続けるべきところですね。

複雑な医療ドメインに立ち向かう強いチームを作っていく

─ 現在のヘンリーは採用に力を入れて、どんどん人を増やしていく段階にありますが、急拡大に伴い注意しなければならないと感じている点はありますか?

シアン:出会える課題を先回りして特定し、内部の制度と仕組みをちゃんと整えなければならない、というところですかね。特にポジションが多くなると引き継ぎが不十分になったり、対応の精度が欠けてしまったりする可能性も考えられるので、コミュニケーション不足が起こらないように意識した組織作りをしなければなりません。

ソンム―:今、エンジニアの採用は売り手市場で、プロダクトチームの採用は難易度が高いのが現状です。それでも数値目標のために採用の基準を下げるようなことはしてきませんでしたし、これからもしないよう注意していきます。

あとは採用基準を明確にしておくことも大事ですよね。単にスキル的なことだけではなく、我々のカルチャーにフィットしているかとか、不確実性の高い状況でも楽しめるかとか、そういった基準をはっきりさせた上で採用を進めていかなければならないと感じています。

─ エンジニアの採用を行う際は、どのようなことを大切にされているのでしょうか?

シアン:ヘンリーのメンバーは優秀な人が揃っていますので、そのメンバーと一緒に働けるスキルセットが大切なのはもちろん、複雑なドメインの難しさに負けずに自分事化して取り組めるかどうか、といったところも採用のキーポイントになります。

我々受け入れる側としても、難しいドメインに飛び込んできてくれる人への受け入れ体制をしっかりと整えて、心配せず飛び込んできてもらえるような環境にする必要がありますね。 ─組織としてやるべきことと、個人がやりたいことのバランスは取れていますか?

ソンム―:今は事業の成長・拡大を大切にしたいフェーズでもあるので、全てのメンバーの「これがやりたい!」という希望を叶えられているわけではないと思います。でも個人のやりたいことも大切にしたい、という想いはみんなが持っています。

社内ではwill-can-mustの話がよく出てきますし、採用のタイミングであったり、人の配置転換や役割の変化が発生するときに「その人のwillはどうなんだっけ」という話はかなりたくさんする会社です。やっぱり、自分のやりたいことをやっていた方が生産性の向上につながるのは間違いないですし、今後も疎かにしたくない部分ですね。

一人ひとりが熱意を持って成長し続けていくヘンリー

─ お二人が描くVPoEとしての展望についてお聞かせください。

シアン:これまでプロダクトチームにフォーカスして動いてきましたが、今後はヘンリーの組織全体に目を向けて、カルチャーを作っていく立場になります。プロダクトチームのチーム作りで感じた課題や培ってきたノウハウは、プロダクトチーム以外のところでもしっかり活かしていきたいですね。

ソンム―:私はスタートアップの熱狂が好きで、みんなで目線や価値基準が揃っている中で物作りをしていく過程が好きなので、それを組織が拡大していく中でも維持していきたいと思っています。

だんだんと一人ひとりの当事者意識みたいなものが薄れてきたりとか、組織が縦割りになっていったりとか、それで熱を失って面白くなくなってしまうことは、組織拡大に伴って起こりやすいと思うんですよね。そういうことが起きないように抗いたいという想いはすごくあるので、文化の定着やチームワークの促進といったところに取り組んでいきたいです。

─ 最後に、ヘンリーに興味をお持ちの方へのメッセージをお願いします。

ソンム―:ヘンリーはエンジニアリングに対する理解度がかなり高い組織です。営業の人やCEOの2人も、エンジニアリングのことを学んだり目線合わせをしてくれているので、エンジニアにとってはかなりいい職場だなと思いますね。

また、企業としてあるべき姿を描いて「理想駆動」していくこと、そしてみんなが立場や情報を「ドオープン」にして「爆速アウトプット」していく、というバリューはやっぱり大事にしたいと思っています。そういったところに共感していただける方は、ぜひ一度カジュアル面談などでお会いしましょう!

シアン:ヘンリーはこれまでも激しい変化を経験してきました。これから成長を加速させていく中でも、課題が出てきたらみんなで解決し、その繰り返しの中で組織も様々な変化を変化を遂げていくことでしょう。

そういった課題解決のプロセスや変化のプロセスを味わいながら仕事がしたいという方には、ヘンリーはすごく面白い環境だと思っています。今後新しく入ってこられる方とも一緒に楽しんでいけたらいいなと思いますので、まずは気軽にお話ししましょう!


ヘンリーでは、さらなる成長に向けて採用も積極的に行っています。ご興味をお持ちいただけた方は、ぜひお気軽にご連絡ください。

https://jobs.henry-app.jp/

JVM勉強会(開発編)を開催しました

こんにちは、SREの戸田です。本日はJVM勉強会(運用編)に続けて開催したJVM勉強会(開発編)の一部を公開します。

図1 勉強会はやっぱりGoogle Meetでオンライン開催しました

システムプロパティ

システムプロパティは環境変数のように、プログラムの挙動を変えるために利用することが多いです。例えばOpenJDKそのものでも Integer.valueOf() で値をどの程度キャッシュするか*1を設定するためにシステムプロパティを使っています

他にも user.language あたりはよく知られていますし、標準で提供されるシステムプロパティも多数あります。しかし製品コードから直接参照することは基本ないと思っていて、 File.pathSeparator などの提供されたAPIを使うことが望ましいでしょう。またシステムプロパティは動的に変更することも可能ですが、システムプロパティを読み込む側がそれを想定しているかは確認したほうが良いでしょう。

文字コード

JVM自体はOS標準の文字コードを用いることになっていました。すなわちここは特に抽象化されておらず、プログラマが意識する必要がありました。 しかしJava 18からUTF-8が標準になるので、動作環境について気にする必要性がひとつ減ります。

逆に言えば、暗黙的にOS標準の文字コードを期待しているプログラムがあるならJava 18以降では注意が必要になります。医療機関向けシステムを扱っている弊社の場合だと、仕様としてShift_JISの利用を求めている書式がレセ電コード情報ファイルをはじめとして多数存在していることから、明示的に文字コードを指定する書き方を徹底することが必要です。

改行コード

JVM自体は改行コードの扱いを抽象化しません。このためプログラマがCR, LF, CRLFのいずれを使うか決定する必要があります。

とはいえOS標準の改行コードを使う場合は PrintWriter, BufferedReader, Scanner といった標準ライブラリが提供する抽象化をもって対応すれば充分で、わざわざ System.lineSeparator() などを利用して改行コードを明示的に扱うことは不要でしょう。

なお書式を扱うメソッドでは、Formaterが提供する %n を使うことでOS標準の改行コードを参照することもできます。

マルチスレッドプログラミング

JVM/Javaはマルチスレッドプログラミングに向いているという話から入り、それでも考えることが結構あるよねという話で盛り上がりました。

特に InterruptedException の扱いが複雑という点は、電車本(Java並行処理プログラミング)に詳しく説明されてるもののかなり古いため、最近の良い本を知りたいという声が複数出ました。おすすめの書籍がある読者の方はぜひ教えていただきたいです。

よくある落とし穴

JVMや標準ライブラリの挙動を知らないとハマる落とし穴がけっこうあり、以下に挙げるものを含めいくつか紹介しました。

JVMとタッグを組んで顧客価値にこだわるエンジニアを探しています

運用編と開発編の2回に分けて、JVMについて勉強会を開催しました。こうした機会を通してJVMの落とし穴を避けて性能を引き出すプログラムが書けるようになったり、システム運用のペインに刺さる監視が行えるようになると嬉しいです。

弊社では医療業界の業務改善のため、医療機関のERPと呼ぶべき電子カルテやレセプトコンピュータをSaaSとして開発・提供しています。JVM大好きな方も、TypeScriptどんと来いな方も求めておりますので、関心をお持ちの方はぜひ採用ページをご覧いただければと思います。よろしくお願いいたします。

jobs.henry-app.jp

*1:この話をしたらPythonにも似たようなキャッシュ機構があるという話が聞けて面白かったです、勉強会は話す側にもたくさん学びの機会があって良いですね

オブザーバビリティにはお金がかかる

tl;dr

オブザーバビリティにはあなたの直感よりもお金がかかるかもしれない。でもそれはアジリティを上げるために必要なコストである。同時にオブザーバビリティ関連ベンダーには、それらをリーズナブルに提供してもらうことを期待します。

オブザーバビリティ・エンジニアリング輪読会

8月からVPoEになりました。id:Songmuです。

社内の勉強会で輪読形式でオブザーバービリティ・エンジニアリングを読んでいます。毎週30分、参加者の中から発表者を割り当て、1~2章を読み進めるスタイルです。

ちなみに、ヘンリーではActive Book Dialogue(ADB)というフォーマットも取り入れて輪読会が運営されています。社内で同時並行で数本走っており、先日、CEOの逆瀬川が書いたソフトウェア見積もりに関する輪読会も同様の形式で実施しています。

発表者は、事前に社内のNotionにその章のアウトラインや論点などをまとめてから会に臨みます。私も何度か担当しましたが、発表者は担当章を読み込むので理解が深まります。私は読書メモを取る習慣はなかったのですが、事前にNotion上に要点をまとめることで理解が全然違うことに驚きました。ADB形式での輪読会、オススメです。

このオブザーバビリティ・エンジニアリングがそろそろ読み終わりそうなので、所感をまとめてみます。

オブザーバービリティ・エンジニアリングとは

この本で述べられていることは単純で、構造化イベントがオブザーバビリティの肝となる構成要素で、それを構造化ログ、特にOpenTelemetryのような標準的なテレメトリ手法で逐一記録しておけば、後から任意の集計や調査、デバッグがやりやすくなる、というものです。

従来のメトリクスは決め打ちの次元で集計された情報量が落ちた値であり、既知の未知に対する調査方法としては有効ですが、未知の未知には弱い。構造化イベントをすべて記録しておくことで、問題が発生した後からでも、過去に対して任意の次元で集計したり、あるリクエストに付随するサービス間の呼び出しをトレースしたり、関連イベントをクエリしたりできるようになります。

オブザーバビリティがあれば、現代的な複雑なアプリケーションに対してもプロアクティブなデバッグが可能になり、素早くフィードバックサイクルを回せ、アジャイルな価値提供が可能になる、ということです。

オブザーバビリティの3本柱という言葉には触れられているものの強く支持はされていません。あくまでイベントが肝で、それを構造化ログとして記録しておけば、あとからトレースもメトリクス集計もクエリもできるよ、という単純明快な主張で分かりやすく、同意できます。

サービス開発者の立場としてもOpenTelemetryの手法をフォローしておけば、多くのオブザーバビリティツール・サービスとの接続もやりやすくなるため、これが業界標準としてもっと広く使われて、エコシステムがより成熟することも期待したいと感じました。

理想的だがお金はかかる

しかし、同時に思ってしまうこととしては「それってカネがかかるよな」ということです。実際、本書には以下のように書かれています。

オブザーバビリティツールは、テレメトリデータのカーディナリティやディメンションを制限することなく、発生するすべてのイベントに関する豊富なテレメトリーを収集し、任意のリクエストに対するコンテキストをすべて伝え、この先のどこかの時点で使用できるようにするために保存する、このようなことを開発者に推奨しています。 p.16

実現のためには結局、逐一構造化イベントログをどこかしらに記録し保存する必要があるということです。

ログと聞くと費用面で頭を痛めているエンジニアの方も多いのではないでしょうか。ログやそれを保管するDWH、その他オブザーバビリティ関連費用は年々増加傾向にあり、企業によってはそれがクラウドコスト全体の数割にも及ぶ、などという話も聞きます。

それらは本当に高いのか

しかし、それは本当に高いのでしょうか。良く考えてみると、高頻度の書き込みに耐え、大量のデータを効率よく集計・クエリ可能な形で保管するのは大変で、コストがかかるに決まっています。それでもそれらの情報を記録しておくことがビジネス価値につながる、ということが本書の主張なのでした。

  • 「たかがログになんでこんなにお金をかけなければならないのか」
  • 「直接的なコンピューティングリソースにお金がかかるのは仕方がないが、付随的なオブザーバビリティ関連費用が高額になるのは腑に落ちない」

そんなことを思うかもしれません。しかし、それは私達エンジニアが忌み嫌っているはずの、運用・運営軽視の態度です。

例えば、昔はCIサーバーにお金をかける発想は乏しかったですが、今はそこにコストをかけるのは当たり前になり、そこに力をかけられるサービスのほうが生き残れるようになりました。

また、昔は新規サービス開発が終わったらチームを解体、縮小して運用するのが多く見られましたが、今では運用・運営に力を入れて継続的にサービスを改善していくことが当たり前になりました。

こういった比重の変化がオブザーバビリティでも進行しており、マインドチェンジが必要です。少なくともエンジニアが「思ったよりお金がかかるな」などと思ってしまうと、経営者はそこに踏み込んで投資はしてくれません。それがビジネス成長のために必要なコストで、更に言うと、そこをおろそかにしていると変化が遅くなり生き残れないリスクがある、ということを認識し、説明可能になる必要があるでしょう。

システム運用的なコストセンターマインドだと、とかく運用関連費用を削りたがってしまうことがあります。もちろんコスト最適化は大事ですが、必要な部分にコストをかける前に削り始めるのは良くありません。

まあでも高いよね

とは言え、オブザーバビリティ関連費用が高くつくのは否めません。その辺りについて本書は後半歯切れが悪くなるように感じられて味わい深かった。そこには大きく以下の2つの理由があるように感じました。

  • オブザーバビリティが本来的にコストが掛かるものであるということ
  • OpenTelemetry周りがまだ未成熟であること

コスト面では、前半では「情報は全て残せ」みたいに強気に言っていたのに、17章でデータサンプリングについてまるまる1章割くなどしています。

また、15章の「作るか、それとも買うか」の章も、筆者がオブザーバビリティベンダー所属であるから公平さを期して書いているのも分かるのですが、業界が未成熟であるがゆえの歯切れの悪さも感じてしましました。

16章の「効率的なデータストア」の章では、オブザーバビリティサービスを提供しているHoneycomb社内で実際にどのように、データを保持しているのかについて書かれています。これはエンジニアとしては読み応えがあり興味深い内容ですが、それと同時に、これは複雑で自前で運用はしたくないよなぁとも感じました。

やはり、多くのテレメトリ情報を扱う基盤は、自前運用が大変であることが想像できるので、どこかのベンダーに任せたい。それに加えて、ロックインされすぎないように、ベンダー間の相互運用性も求めたい。

相互運用性についてはOpenTelemetryを計装しておけば、多くのベンダーに接続できる流れになりつつあり、そのエコシステムのさらなる成熟を望みます。しかし、そのベンダーの選択肢については「ここに任せておけば安心」という有力ないくつかのサービスが存在するかと言うと、まだ足並みが揃っていないように感じます。

このあたりは、複数の有力なベンダーが同じ土俵の上で価格競争され、よりリーズナブルにサービスが提供される流れになることを期待しています。

ヘンリー社では

社内ではこのあたりは鋭意整備中ですが、Sentryで発番したtrace IDをTypeScriptやKotlinで書かれたサービスに引き回し、OpenTelemetryで計装するところまでは実現できています。それらとGoogle Cloud Logging, Cloud Trace, BigQueryなどを組み合わせて可視化、トレース、クエリ等を実現しています。

可能ならGoogle Cloudの機能で一通りまかないたいと思っているのですが、煩雑になってきているので、他社がどうしているかも知りたいところです。また、サードパーティのソリューションも検討しても良いとは考え始めています。このあたりのノウハウが他の会社の技術ブログ等で書かれると嬉しいです。

まとめ

ヘンリー社内での輪読会取り組み及び、オブザーバビリティ・エンジニアリングについて取り上げました。

ヘンリーはまだ数十人のスタートアップであり、輪読会やオブザーバビリティの取り組みにおいても、職種をまたがって実施しています。輪読会にはCEOや営業、CXメンバーが参加していますし、オブザーバビリティの取り組みではアプリケーションエンジニアが計装を実施しました。

小さいチームでクロスファンクショナルに活気を持って開発を進めていますし、お客様も増えてきていて拡大期に入ろうとしていて、もっと仲間を増やしたいと思っています。SRE、Webエンジニア、各職種を募集中ですので、興味のある方はぜひご連絡ください。

JVM勉強会(運用編)を開催しました

こんにちは、SREの戸田です。本日は社内で開催したJVM勉強会(運用編)の一部を公開します。

JVM、使っていますか?弊社ではサーバサイドKotlinが活躍しているので、もちろん日常的にJVMが稼働しています。このためサービス運用の一貫で必要になる知識や関連ツールなどをSREないしプロダクトチームに共有することを目的として、この勉強会を開催しました。

図1 勉強会はGoogle Meetでオンライン開催しました

パフォーマンス・チューニング

サービスを開発していると、この処理をもっと高速化したい!ランニングコストを抑えてユーザ体験の向上に投資したい!というというシーンには多く遭遇しますよね。こうしたユーザが増えてサービスに負荷がかかるようになったことで生じた課題に対して迅速に打ち手が取れることは、とても重要です。

しかし焦ってはいけません。「このコードはめっちゃループしてるし遅そう!」「あの機能を入れたら手触り悪くなったから、あの機能が怪しい!」という勘で改善を始めてしまうと、本当に改善されたのかの検証が難しいことに加え、問題の根っこを見つけられない可能性も出てきます。まずは、計測から始めましょう。

scrapbox.io

今回は問題となった処理をメソッドとして切り出せることを期待して、Java Microbenchmark Harness (JMH)を紹介しました。またその利用事例として inputStream.readBytes().toString(Charsets.UTF_8)inputStream.bufferedReader(Charsets.UTF_8).readText() に変えることで高速化することの確認を紹介しました:

Benchmark                   Mode  Cnt       Score      Error  Units
MyBenchmark.buffered128k   thrpt   25  226168.261 ± 3085.163  ops/s
MyBenchmark.buffered512k   thrpt   25  226123.470 ± 1595.982  ops/s
MyBenchmark.readBytes128k  thrpt   25    5105.985 ±   86.458  ops/s
MyBenchmark.readBytes512k  thrpt   25    1258.793 ±   49.706  ops/s

また問題が特定できていない場合に使える手段として、JDK Misson Control(JMC)などで作成できるJDK Flight Recorder(JFR)ファイルの作成を紹介しました。JFRファイルはJVMの状態をひろく、また時間軸に沿って観察したデータを残せるため、どこに問題があるかわからない状態でも活用しやすい特徴があります。

図2 JFRファイルをJMCで見ればメモリの利用状況も可視化される

そこからヒープダンプを取得したりマイクロベンチマークにつなげることで、より問題を掘り下げて調査する事ができると考えています。

起動高速化

Cloud RunでKotlinアプリケーションを動かす際、サービスの起動速度は重要なポイントになります。コンテナの起動が遅いとデプロイやスケールアウトに影響があり、最悪の場合はすぐにお客様に届けたい修正がなかなか届かない原因になってしまいます。

この課題は多くのユーザで共有されているようで、Cloud Runの公式ドキュメントではAppCDSによる高速化を紹介しています。ただこの方法だとデプロイの前処理が増えるので、スケールアウトはともかく修正を迅速に届けたい場合にはあまり有効ではないかもしれません:

cloud.google.com

今回の勉強会ではこれに加えて、CRaCjlink、native-imageについて紹介しました。またそれぞれの特徴を踏まえて、いまの自社サービスに適切と思われるアプローチについて議論しました。

図3 起動高速化に加えてコードの動作高速化についても実例を交えて議論しました

質疑応答

最後に質疑応答の時間を取りました。

まず -Xms-XX:MinRAMPercentage のような似た設定ではどちらを使えば良いのか?という質問がありました。答えは -XX:MinRAMPercentage です。JDKにはエルゴノミクスという考え方があり、ざっくりと要求を伝えておけば自身を動的に最適化してくれます。そのためヒープのサイズを -Xms-Xmx でバイト単位で指定するのではなく、このくらいまでメモリを使っていいよとざっくり伝えて細かいチューニングを任せるようにします。

docs.cloudbees.com

またStacktraceを取得するのはコストが高いのではという質問もありました。実はJava 9でStackWalkerが実装されたことで、Stacktraceを取得するコストは安くなっています。その効果は高く、例えばlog4j2ではJava9以降ではこの新しいAPIを使ってメソッド呼び出し元を特定しています。

JVMと仲良くなってKotlinをもっと活用したい

今回のJVM勉強会(運用編)は良い盛り上がりを見せました。Kotlinを活用して顧客に価値提供をするためにも、こうした基盤部分の理解を深めることは大切です。今後もチーム一丸となって学ぶため、運用編に続き開発編も開催したいと考えています。

なおKotlinに関する活動については以下の記事でも紹介していますので、あわせてご覧いただけますと幸いです。

経営層が知るべき、目標と見積りの話について

img_tagert

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

今日は、ソフトウェア見積りという本を社内輪読会で読んでいるのですが、この本のお陰で、目標と見積りに関するコミュニケーションが劇的に改善したお話をします。

ソフトウェア見積りはとても良い本なので、他にも紹介したいことがありますので、それは別の機会に。

皆さんは目標や見積りはどのような意味で使っていますか? デジタル大辞泉によると、目標とは、「 行動を進めるにあたって、実現・達成をめざす水準。」と定義されてます。

皆さんがイメージしていた内容ではないでしょうか?私たちもあまり認識がずれるとは思ってなかったので、社内であまり定義せずに使っていた結果、下記のような問題が発生していました。

  • 目標と必達目標が生まれ、どちらの話をしているのかがわからない
  • 目標の期日と品質がいつの間にか必達水準に変わってしまうため、見積りをそのまま目標としてしまう
  • 見積りのコミュニケーションをしていたはずが、いつのまにか目標にすり替わってしまう
  • 元々出したい期日が目標として決まっており、その目標を達成前提で計画する。(しかも、その計画が非現実的)
  • 開発スケジュールが遅れに遅れ、見積り不要論が発生する
  • 開発スケジュールが遅れに遅れ、逆に同じような見積りを何回もする

などなど

結果、目標に関してミスコミュニケーションが多発しており、目標とはどうあるべきだという議論をしつつ、結論が出ないままフラストレーションが溜まる日々でした。 そこで、ソフトウェア見積りという素晴らしい本に出会います。

“ターゲット“と“コミットメント“と"見積り"と

ソフトウェア見積りに、見積り、ターゲット(目標)、コミットメントについての説明がありますが、まさに求めていたものでした。 しかも、1章に求めていたものが!!

- 見積り : プロジェクトにかかる期間やコストを予測
- ターゲット : 実現したいビジネス上の目標を明文化したもの
- コミットメント : 定義された機能を、特定の品質レベルを確保しながら期日までに納品するという約束

「この日までに終わらせたい」が見積りを歪めていた

スタートアップたるもの、なるべく早く開発したいし、Over達成したいものです。ましてや、私は楽天出身です。

いつの間にか、見積りを出す時または見積りを受け取る時に、目標を伝えていました。

みなさんもこういう経験あるのではないしょうか?

"見積り"と"ターゲット"の分類が全てを救う

“ターゲット“と“コミットメント“と"見積り"を分けて、コミュニケーション取るようになったため、社内のコミュニケーションがだいぶ改善されています。

「XXXの機能ですが、見積りとしては3週間程度で終わりますが、ターゲットとしては、2週間で終わらせたいと思っています」

「年内のロードマップですが、見積りとしては、1.5ヶ月ほどはみ出る可能性が高いです。XXとYYが特にリスクが高いので、それを早めに解消して、再度見積りとターゲットを決めましょう!」

などなど、建設的な意見が生まれるようになりました!

ソフトウェア見積りは、今年一番読んで良かった本といっても過言でもないので、ぜひ、プロジェクト進行や見積りなどで困っている方は読んでみてください。

経営者の皆さん、「それいつ終わるの?」って聞いてないですか?

最後に、自戒も込めて。 経営者が「それいつ終わるの?」と聞くと、コミットメントのように聞こえます。

そのため、回答する人は固めな目標を出すケースが多いと思いますし、経営者自身も正しい見積りを聞ける機会を失ってます。 ターゲットと見積りとコミットメントを分けて聞くことで、正しくコミュニケーションが取れるので、ぜひ使ってみてほしいです。

一緒に仕事をする仲間を募集しています

ヘンリーでは、他にも社内勉強会を積極的に開催して、得た知識を事業推進にみんなで活かしています。 全ては、日本の持続可能な医療を実現するために。 困難で大変なことも多々ありますが、今後も高いターゲットを掲げて事業推進していきます! ぜひ、興味のある方は、採用サイトよりご連絡ください。

参考にした本

www.amazon.co.jp