Jagu'e'r データ利活用分科会 #32 Meetup 「複数分科会コラボ企画 ― 各業界のデータ利活用事例スペシャル」で登壇しました

こんにちは、ヘンリーでPMをしているdam(@aki_hiro0038)です。

2026年2月6日、Google Cloud公式ユーザーコミュニティ「Jagu'e'r」のデータ利活用分科会に弊社も参加し、登壇しました。

jaguer.connpass.com

きっかけは私が個人的に所属しているデータ分析系のテックコミュニティで「最近噂になっているヘンリーさん、よかったらJagu'e'rで登壇してみませんか」とお声掛けしてもらったことでした。

ちょうど社内でもデータ分析に力を入れようという動きがあり、組織拡大の中でデータ分析業務や基盤構築を専任で担うメンバーも採用できたタイミングでした。

そこで、ぜひ直近の活動内容を紹介させてほしいと登壇が決まりました。

勉強会の雰囲気

今回は複数分科会コラボ企画ということで、エネルギー分科会から大阪ガスさん、ENEXIA合同会社さん、街づくり分科会から三菱地所株式会社さんが登壇されていました。（ちなみにヘンリーはヘルスケア分科会としての登壇でした。）

コミュニティの方針として、登壇内容は基本コミュニティ内に閉じる考えのため多くは書けませんが、再エネ業界の課題にデータ分析でどう立ち向かっているかというお話や、街（オフィス・商業施設・居住施設など）の価値をどう捉えて向上させていくかなど、どれも興味深いお話ばかりでした。

詳細にご興味のある方は、下記の新規会員登録フォームからぜひコミュニティにご参加ください。

jaguer.jp

また、運営メンバーの高須賀さんより、イベントレポートも公開されておりますので、こちらもご確認ください。

note.com

弊社の登壇内容

弊社からは「カオスな病院のデータにどう立ち向かうか？」というタイトルで、データ分析基盤チームで活躍する吉村が登壇しました。

吉村は異業界から入社したばかりのメンバーですが、退院サマリーなどの書類をデータから自動作成する取り組みや、病院経営を支援するダッシュボードの提案など、データ活用の可能性が医療業界には多くあると感じている点についてお話ししました。

また、それらを実現するために、AI活用も視野に入れた可用性の高いデータ基盤の構築を目指しているが、過去の経緯からデータマートがカオス化してしまっている課題に対して、dbtのYAMLファイルのカラム定義をAIに生成させたり、テーブル構造図をAIに描かせたりと、AIをフル活用して整理を進めているといった具体的な事例も紹介しました。

参加してみて

今回登壇した企業の共通点は、どの会社も「社会インフラ」を構築・維持する事業に取り組んでいることでした。

医療業界以外でも社会の維持にどのような課題があり、どう立ち向かっているのかを直接聞けたのは、大変貴重な機会でした。

また、そうした社会を支えるエンタープライズ企業が並ぶコミュニティに、ヘンリーも一員として参加できたことを嬉しく感じています。

懇親会のご飯もとても美味しかったです

さいごに

ヘンリーでは医療 DX を通じて理想駆動で社会課題解決に取り組むプロダクト開発に興味のある仲間を募集しています！！気になった方は気軽にカジュアル面談へお申し込みください。

jobs.henry.jp

Claude Codeで開発を全自動化する - Orchestrator型Skillの設計と実践

株式会社ヘンリーでソフトウェアエンジニアをしているwarabiです。

ヘンリーは医療業界向けのプロダクトを開発しており、開発メンバーにも難解なドメイン知識が求められます。そのため普段からドメインの理解や深堀りに時間をかけたいところですが、実際は開発業務も進めなければならないため、時間の使い方に悩んでいました。

この課題に向き合うために、普段開発で使っているClaude Code（Anthropic社が提供するCLIベースのAIコーディングアシスタント）をもっとうまく活用し、実装にかける時間を減らして学習に充てる時間を増やせないかと考えました。

それまでのClaudeCodeの使い方と課題

それまでの私のClaude Codeの使い方は、一言で表すとAIとのペアプロです。

AIによるコードの変更をリアルタイムに確認しながらその場で質問もできるため、設計やサービスの理解には役立ちます。

ただ、このやり方だと人間がAIのそばを離れられません。会話のラリーを続けるために生成されたコードをそのつど読む必要があり、別の作業に移りづらい状態でした。

理想の動作を考える

使い方を切り替えるにあたり、まずは普段の業務フローを整理し、自動化できそうな部分を洗い出しました。

開発フローを3フェーズ・7ステップに分解したところ、それまでペアプロで行っていた計画・実装の2ステップに加え、情報収集・PR作成を含む計4ステップを完全に自動化できる可能性があると考えました。

As-Is: 黄色がAIとのペアプロ

To-Be: 緑色をAIで完全自動化

なるべく完走させるために

自動化したい作業がはっきりしたので、次は「どうやってAIに任せるか」を考えます。

ここで活用したのがClaude Code Skillsです。

code.claude.com

Skillsは、Claude Codeに対して特定のタスクの進め方を手順として定義できる仕組みです。

先ほど挙げた「ペアプロから離れられない」という課題の根本は、Claude Codeに一連の作業を任せきれないことにあります。

プロジェクトの前提知識はCLAUDE.md（Claude Codeのプロジェクト設定ファイル）に書けますが、CLAUDE.mdは会話の開始時に常に読み込まれるため、ワークフローのような長い手順まで書くとコンテキストウィンドウを圧迫します。コンテキストが長くなるほど指示が正しく実行されないケースが増えるため、CLAUDE.mdにすべてを詰め込むのは現実的ではありません。

Skillsを使うと、こうしたワークフローを手順書のように定義しつつ必要なときだけ読み込ませることができます。各ステップで何を参照し、どういう判断をし、どんな出力を期待するかを明示しておくことでClaude Codeが一連の流れを人間の介入なしに自走できるようになります。

CLAUDE.mdが「プロジェクトの前提知識」を常に伝えるものだとすれば、Skillsは「作業の進め方」を必要なときだけ渡すものです。ペアプロ型から自動化へ切り替えるにはこのSkillsの活用が適切だと考えました。

オーケストレーター型Skill

Skillsで自動化を実現する方針は固まったので、次は「どのようにSkillを作るか」を考えます。

Skillとはいえ1ファイルに大量の命令を書くと、コンテキストが長くなり指示が正しく実行されない問題が起きます。4ステップすべてを1つのSkillにまとめるのは避けたいところです。

そこで取り入れたのがオーケストレーターという考え方とSubAgent機能（親のAgentから独立したコンテキストで子Agentを実行する仕組み）です。各ステップを独立したSkillとして定義し、呼び出し順だけを管理する親のSkillを用意します。各ステップはSubAgentとして実行されるため親とは別のコンテキストで動作し、ステップごとにコンテキストがリセットされます。

この構成により、各Skillは担当ステップの手順だけを小さなコンテキストで実行できます。ステップ単位での修正や差し替えもしやすくなります。

情報取得Agentや設計Agentは、それぞれの結果を特定のフォルダにファイルとして保存します。AgentはOrchestratorに「処理が完了した」とだけ伝える仕組みです。これによりOrchestratorが調査結果を丸ごと読み込む必要がなくなり、コンテキストの圧迫を防いでいます。

成果物を別のAgentにレビューさせる

オーケストレーターとAgentの組み合わせにより、タスクを与えれば実装完了まで一撃で行えるようになりました。

この時点でSkill構築を完了しても良いのですが、実装の品質をさらに高めるために、Agentの成果物を別のAgentにレビューさせるというアイディアを取り入れました。

エンジニアの普段の開発でも、実装したものはそのまま使わず他者にレビューしてもらいます。この工程をSkillにも流用できると考えました。

親が受け取った成果物をReviewAgentに渡してレビューさせます。問題があればその内容を親に報告し、親が再度Agentに修正を依頼します。

上限回数を設けたうえでこのループを回すことで、レビューを通過するまで品質を高めるようにしました。

最終的なSkill構成

devと名付けたOrchestrator型Skillは最終的に以下のようなフローになりました。

大まかな流れ:

• ユーザーはdev Skill(Orchestrator)を呼び出し、タスクのIDを渡す
• タスクの中身を確認・更新したら内容が問題ないかを人間に最終確認
  • 問題なければ後は基本的に全自動で設計・実装・PRまで行う
• 各ステップには実作業を行うAgentと、レビューを担当するAgentがペアで存在する
  • 作業とレビューを繰り返すことで品質を高める

以前のClaudeCode利用との比較

Skill活用前とSkill活用後でどのような体験の差があるかを整理してみます。

	Before (ペアプロ)	After (全自動)	感想
作業時間の確保	☓	◎	最終確認にOKを出したら後はVSCodeをバックグラウンドにし、他タスクの情報収集などに時間を充てることができている。 全てではないですが、修正不要でマージできるPRも結構作れている。
開発速度	◯	◎	実担当AgentとレビューAgentを分けたことで全自動でも品質が大きく低下することもない。
実装の理解	◎	◯	ペアプロの頃はリアルタイムに細かな質問もできていたため、時間をかけているぶん実装の理解はペアプロに軍配が上がりました。 ただ、実装完了後のPRレビューはまず作業者である私が行うようにしているので、何も知らないということはなく他者のコードをレビューする時と同等に理解を維持できています。

総括

今回、作業時間を捻出するためにClaude Codeの活用方法を見直しました。

フローの整理、SkillsやAgentの活用、オーケストレーター、フィードバックループ。これらを取り入れたことで使い方を大きく変えることができ、時間の捻出だけでなく開発速度の向上にもつながりました。

まだ日が浅いため今後も調整は必要ですが、一人あたりの作業速度は明らかに向上しており、新しい使い方に切り替えた効果を日々実感しています。

今回Skillの活用によって開発体験は大きく向上しました。このアプローチは実装系業務に限らず、普段の様々な業務にも応用できるはずです。今後もSkillを使った自動化に取り組んでいきたいと考えており、またブログネタが生まれたら投稿しようと思います。

SRE Kaigi 2026 で推しのインフラツールについて聞いてみた

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

ヘンリーでは SRE Kaigi 2026 でゴールドスポンサーとしてスポンサーブースを出していました。

当日のヘンリーブースの様子

当日は朝からブースにたくさんの方に足を運んでいただき、いろいろなお話ができてとても刺激的な1日を過ごせました。また、SRE Kaigi 2026 の運営スタッフの皆様、素晴らしいカンファレンスをありがとうございました。

今回のヘンリーブースでは会話のきっかけとして、「あなたの推しインフラツールを教えてください!!」というアンケートをしてみました。実はこのアンケートは会期前に社内でも実施していたので、今回は会場での結果と社内での結果をみていきたいと思います。

メドレー、カミナシの皆さんとヘンリーで現場PM勉強会を開催しました

こんにちは、ヘンリーでPMをしているdam(@aki_hiro0038)です。

2026/1/20にメドレーさんの六本木オフィスをお借りして、3社合同のPM勉強会を開催しました。 本イベントは社外告知しておらず、クローズドな開催となります。

きっかけは昨年のpmconf 2025の懇親会にて、私が「勉強会やりませんか！」と声を掛けたら、即答で「やりましょう！」とメドレーの田所さん(@ytadokorokoro)、カミナシの吉岡さん(@oriori440)がお返事くださったことでした。

3社ともVertical SaaSのプロダクト開発を行っており、顧客現場に深く入り込むことを重視する文化を持ち合わせていることを知っていたため、「いつかクローズドに深く話し合ってみたいな〜」と考えていたところ、たまたま3社ともで知り合う切っ掛けができ、チャンスと思って提案しました。

そういう思い切りから始まった勉強会ですが、お二人の力をお借りしながら勉強会内容の企画し、無事開催に至りました。

改めて、メドレーの田所さん、カミナシの吉岡さんには感謝しかありません。 さらにメドレーのDevrel担当重田さんの粋な計らいから軽食とお飲み物もご提供いただき、大変ありがとうございました！！

勉強会内容

冒頭に開催の背景とお互いの事業紹介、あと顧客現場に入り込む上での悩みを共有した後、3社合同のOSTを開催しました。

OST（Open Space Technology）とは、話したい人が、話したいことを、話したい人と、話したいときに話せるようにするための方法論です。 簡単に言うと仕組み化された雑談と理解いただけたら良いと思います。

昨今、さまざまなカンファレンスでOSTが開催されており、参加者自身が話したいと思っていることを、同様に興味を持っている他の参加者と話し合える場作りがされています。 ヘンリーでは開発スプリントの振り返りやリモートーワーク下であえて雑談を発生させる仕組みとしてOSTを取り入れています。

OSTの冒頭では、まず参加者それぞれが「話したいテーマ」を出し合うところから始まります。

「顧客の本音を引き出す方法」や「現場でアナタに起きた奇跡」といった、実践的なスキルやリアルな経験談にフォーカスしたテーマがある一方で、 「究極、そんなに現場に行かなくていいんじゃない？」「紙に勝てない領域は本当にあるのか？」といった、他社の考えを聞いてみたかったり、前提そのものを問い直すようなテーマも次々と挙がりました。

ノウハウを学びたい気持ちと、価値観や思想をぶつけ合ってみたい気持ち。そのどちらも惹かれるテーマばかりで、どのセッションに参加するか本気で悩むほど、会場は早くも盛り上がりを見せていました。

どのテーマに参加しようか悩む参加者たち

OST中の様子

開催の結果

具体的に話し合われた内容として
・「顧客にホンネを語ってもらうのは難しい。やっぱり観察から判断するしかないと思う」
・「ものすごいインパクトのあった現場訪問について、現場訪問を切っ掛けに成約。成約ポイントから要求もシャープになり、新規事業の切っ掛けにもなった！」
・「紙で現場で回っている運用からの移行コストはシステム費用・教育・心理的な面でもかなり高いから、現状紙の運用業務から移行する強いメリットを感じないとやらないかも」
などなどが語り合われていました。

また、参加者からの感想では
・「聞きたいことの他社事例が聞けて、普通に勉強になりました！」
・「クローズド感が心理的にも安全な雰囲気があってよかったです」
・「社内でこんなに知見を共有し合ったことなくて、沢山しゃべれて良かったです！」
といった声が上がっており、大満足の勉強会になりました！！

今回の開催を通して、仕事のコンテクストに共通点があることや、クローズドだからこそ相談できること、普段会わない人から新たな知見を得られる点、などに合同勉強会の魅力を感じました。

もし、他にも私たちヘンリーと合同勉強会を開催したいという方がいらっしゃったら、dam(@aki_hiro0038)までDMください。 気軽なお声掛け、お待ちしております。

RSGT2026にゴールドスポンサーとして初参加しました

はじめまして、株式会社ヘンリーでPdM・DE（ドメインエキスパート）・スクラムマスターを担当しているowataです。

2026年1月に開催された RSGT2026 に、株式会社ヘンリーとして ゴールドスポンサー＋ブース展示＋セッション登壇 という形で参加しました。 今回弊社は、PdM・DE・エンジニアと幅広い職種で参加しました。 本記事では、

• なぜこのブース展示を企画したのか

• 実際にどんな体験を提供したのか

• 参加・登壇して何を得たのか

を振り返ります。

なぜ「体験型ブース」をやろうと思ったのか

今回のブース展示のコンセプトは、かなりシンプルです。

Help!!　― このプロジェクトの課題、どうやって解決しますか？ ―

RSGTは、スクラムやアジャイルに関心の高い人が集まるイベントです。 一方で、ブース展示はどうしても「説明を聞く場」になりがちです。

そこで今回は、

• 立ち寄った1分でも楽しめる

• 興味があれば、いくらでも深掘りできる

• 毎日来ても、変化を楽しめる

そんな「関与の深さを来場者が選べる体験」を作ることを目標にしました。

ブースの設定：架空プロジェクト × 開発ライフサイクル ブースでは、架空のプロジェクトチームが、開発ライフサイクルに沿って開発しているという設定を置きました。

• ディスカバリー中

• 開発・実装中

• リリース後

それぞれのフェーズで、「一度は聞いたことがある」「今まさに悩んでいる」そんな リアルな悩み をボードに配置しました。

例を挙げると、

• 仕様が固めきれず、合意できない

• ユーザーごとに要望が真逆で判断に迷う

• 「いつ出せるの？」にどう誠実に答えるか

• リリース後、どこまで改善したら“完了”と言えるのか

• 価値が出ているかをどう測るのか

などです。

来場者にやってもらったこと ブースで来場者ができることは、大きく3つです。

• 悩みに対して「いつ・何をするか」を付箋で提案する

• そのメンバーに声をかけるなら、どんな言葉をかけるかを書く

• 自分自身のプロジェクトの悩みを、空の悩みボードに貼る

答えを書く付箋の色を悩みごとに揃えることで、「この悩みには、どんな打ち手が集まっているか」が自然と可視化されていきました。

想定以上に付箋が集まり、途中で課題シートが足りなくなるほどでした。 ご協力頂いた皆様ありがとうございました！

1日目に集まった付箋

2日目に集まった付箋

ブースで起きていたこと（実感ベース）

実際にブースに立ってみて感じたのは、

• 自然とスクラムや開発プロセスの会話が始まる

• 「それ、うちも同じで…」という共感が連鎖する

• 来場者同士が付箋を見ながら議論し始める

という状態が多く生まれていたことです。

特に印象的だったのは、

• 「あの開発プロセスボードのブースだよね」と後日まで記憶に残っていた

• アジャイル・スクラムの理解度が自然と見える

• 結果的に「ヘンリーでアジャイルをやっている人」として会話が広がる

といった副次的な効果でした。

セッション登壇：新米スクラムマスターの4ヶ月 -「スクラムイベントを回しているのに手応えがない」からの脱出

3日目には、 新米スクラムマスターの4ヶ月 -「スクラムイベントを回しているのに手応えがない」からの脱出 というテーマで私自身が登壇しました。

ウォーターフォール出身・スクラム未経験の状態から、

• チームの停滞

• スクラムマスター就任

• 試行錯誤

• 「価値」にフォーカスしたレビューへの転換

までの4ヶ月を、実体験ベースで共有しています。

ありがたいことに現地30人、オンライン70人と100人近い方にリアルタイムで聞いていただけました。 Discordでもたくさん反響を頂いた上に、登壇後に声をかけてもらえたことは素直に嬉しかったです。

頂いた声の一部を紹介

• デイリーリファインメント良さそう

• 愚直に向き合えるのすごい

• リアルなレビューいい！機能じゃなくて体験をレビューするとみんな本気になってくれる

• 身近にスクラムマスターを始めようとしている人がいるので共有したい

発表資料はこちら

speakerdeck.com

登壇で使用したスライドは、SpeakerDeck に公開しています。

※ チームの状態が停滞している／レビューが形骸化している そんな方には、何かしらヒントになる内容だと思います。

振り返っての学び

今回のRSGT参加を通じて、個人的に大きかった学びは以下です。

• スクラムやアジャイルの悩みは、驚くほど共通している

• 課題は「粒度を小さくする」だけで、前に進むことが多い

• スクラムイベントは「回すこと」より「何を確かめるか」が重要

• 体験型の場は、人と人の距離を一気に縮める

また、 「DE（ドメインエキスパート）がこういう場に出ているのがいい」 という声をもらえたのも印象的でした。

おわりに ブース展示・登壇ともに、 やってみて初めて見える改善点 も多くありました。

• 目立つ導線の作り方

• 1日目と2日目のブース展示の設計の違い

• 次の接点（Meetup・採用）へのつなぎ方

• 定量的な目標設定

これらは、次回以降にしっかり活かしていきたいと思います。

RSGTという場を通じて得た学びや出会いを、 日々のプロダクト開発・チームづくりに還元していきます。

株式会社ヘンリー Advent Calendar 2025 の感想

株式会社ヘンリーで SRE をしつつ、技術広報的なこともしている id:nabeop です。

2025年も会社でアドベントカレンダーを企画しました。2024年までは1トラックでの開催でしたが、2025年は2トラックでの開催をして多くのメンバーに参加してもらえるようにしました。

入社半年、はじめての医療ドメイン理解を振り返る

【これはHenryアドベントカレンダー 2025 シリーズ 1 における22日目の投稿です。昨日の記事は俺たちの成長は止まらない｜Sugimura Masashiでした。】

はじめまして、6月にヘンリーに入社したエンジニアのichienです。初めてブログを書くので、半年遅れの入社エントリーになります。

私はこれまで地図や会計プロダクトでの経験を経て、今回、新しく医療ドメインにチャレンジしています。開発では主に医事（医療事務）会計領域を担当しています。

入社して半年、過去の学習経験を活かしながら医療ドメインのキャッチアップに取り組んでいますが、自分なりに理解するまでに時間がかかることが多く、試行錯誤しながら取り組んでいます。 前職ではマネジメント多めのEMロールだった所から、今のヘンリーではエンジニアにフルコミットしており、利用技術周りのキャッチアップにも取り組んでいます。 ライフステージの変化と共に利用時間に制約が増えていく中で、「いかに学習の質を高め、最速で学びを積み上げられるか」という戦略の大切さを感じている所です。

この半年でドメイン理解のために取り組んだことを振り返り、今後のアクションについて考えてみます。

なぜ医療ドメインにチャレンジしたのか？

子どもが成長過程で社会福祉機関による公共の支援や医療サポートを受ける機会がありました。 私にとって初めての経験で、地域で支え合う仕組みがあることにありがたいと思うと同時に、一人のエンジニアとしてこのような公共の仕組みに何か貢献できないだろうかと考え始めたことがきっかけでした。

そんな中、理想駆動で社会課題に真正面から立ち向かっているヘンリーの考え方に共感し、飛び込んでみました。

巨大で複雑なものは難しいけど面白い

当初は「どんなドメインでも、学んでいけばなんとかなるだろう」と楽観的に考えてました。しかし、国民皆保険制度に基づく医療費請求の仕組み、国が定める医療費の根幹を貫く診療報酬制度、外来診療/入院を含めた病院業務の複雑さを一歩一歩理解するにつれて、奥深すぎて一筋縄ではいかないなと考え直しました。

未知で”わからなかった”ことを学び、解像度を上げていくことは面白いです。 "わかる”状態が増えると、自身の成長を実感できて、楽しいのです。 更にそれが難しいことほど、わかった時の成長実感が大きく、より面白くなっていきます。

こんな気持ちで複雑な領域に私は向き合っています。ここから半年間の取り組みを振り返っていきます。

半年間の取り組みと振り返り

1. 医療事務の入門書を読む

最初はどこから手をつけるべきか迷子状態で会話内での単語やコードベースの命名やロジックを見ても、"わからないこと"が"わからない"状態でした。 まず書籍から全体像を理解しようと思いました。

一通り読んでちょっと分かった気持ちになった気がします。 しかし、「書籍で読んだあの内容のことか！」と理解がつながる瞬間があまりなく業務中で活かせてる実感がなかなか得られませんでした。 一度読んで終わりでなく、頭にインデックスを張っておき、思い当たった時に該当部分を読み直すぐらいの温度感でいると良さそうです。

「大量の"わからない"ことがあることが"わかった"状態になりました。」

2. AIで調べる

今はAIがあるので、フル活用したらドメイン理解に費やす時間をショートカットできるのではと考え、知らない用語が出てきたら即AIで調べるようにしていました。 これは学習のフィードバックループを高速に回せそうです。

「"わからなかったこと"を"わかった"気になる状態になりました。」

振り返ると、とても便利で調査負荷を圧倒的に圧縮できていたと思います。 ただ、AIとのやり取りは基本的にクローズドなので、正しい意味で"わかった"のか客観的に判断できず、自身で自信が持てない状態でもあったと思います。 自身でAIで調べる・周囲の人に聞くことは、それぞれ一長一短ありそうです。

3. 病院訪問

半年間で2件の病院を訪問させてもらい、医事課の方々が働く現場を見学させていただきました。 現場での実体験によって、初めて具体的に頭の中でイメージできるようになった感覚がありました。例えば、「外来受付には一台の共有PCが置かれており、画面全体に開かれたブラウザ内でHenryが常に表示されている」の様な現場状況を含めたイメージです。

N=1であっても自分の中に参考となる「絵」が持てると、その後の設計や議論の解像度が大きく変わってきます。これは前職でも経験あったこともあり、自身の中で再現性が高そうです。積極的に現場訪問の機会を得られる環境があるのはとても良いなぁと思っています。

4. エピックオーナーに挑戦

入社して2ヶ月ぐらいで、担当する医事領域の機能開発でエピックオーナーに挑戦しました。

ヘンリーでは、エンジニアリングチームが主体となってプロダクトの仕様を意思決定します。 ユーザーの課題を真に解決するために、社内のドメインエキスパートや医療従事者の経験者などと協働し、時にはエンジニアがリードしてディスカバリーからデリバリーまでを一貫して担います。

この役割を「エピックオーナー」と読んでいて、社内には挑戦を後押しする文化があります。 この役割の存在が、ヘンリーへの入社を決めた一つの理由でもあります。会社の説明資料に記載があるので、ピックアップしておきます。

挑戦する楽しさとドメイン理解が十分でない状況で担えるかどうか不安な気持ちと両方の気持ちが交錯していました。

ドメインエキスパートやサポート、Bizメンバー、デザイナー等多様なロールと協働し、フィードバックを得ながら意思決定を積み重ねることで知識不足を補っていきました。重ねるごとに、徐々に自分で提案できることが増えていきました。

リリース後には、実際に利用している医療機関様にインタビューをさせてもらい、現場の声を直接得ることで、自分達で価値の検証を行いました。

この経験から、ドメイン理解の学習においても学習効率を最大化するのは、「適切な課題設定」と「その解決のためなら何でもするというオーナーシップ」なのだなぁと思いました。 まずやってみること大事。

これからは「点」から「線」で理解していきたい

半年振り返って、ドメイン理解にしても業務タスクにしても、目の前の課題の解決のために必要な知識の学習に多くの時間を使った感覚があります。 複数の取り組みから多くの情報を「点」で学習できたが、どうも自分の中で「点」と「点」をつなげて整理できてる感覚がまだまだ薄いです。 一方で「点」での理解を進めたことで、一定の成果を作ることができたとも思っています。

これからは長期的な視点を持って、学んできた「点」をつなげ、体系的に「線」で理解するためにアクションを増やしてゆく予定です。例えば、以下の様なことを考えています。

• 医療事務の経験者やドメインエキスパートと積極的に話し、自分の理解に対して壁打ち等を通してフィードバックをもらう
• 社内で得た情報をつなげるため、読むターゲットを社内ドキュメントに絞って幅広く読む
• 厚生労働省が公開している資料などの一次情報の読み方を学ぶ

さいごに

ドメイン理解の進め方はまだまだ探索しながらなので、定期的に振り返っていきたいです。 私の半年振り返りを最後まで読んでいただきありがとうございました。

もしヘンリーに興味をもっていただけた方がいたら、ぜひお話しましょう！

jobs.henry.jp