Upgrade to Pro — share decks privately, control downloads, hide ads and more …

「わかる」から「つくる」へ / CRE Goes Dev: Building with AI

「わかる」から「つくる」へ / CRE Goes Dev: Building with AI

コラコン 2026 夏 スポンサーセッション

Avatar for Mayuka Sugimoto

Mayuka Sugimoto

June 27, 2026

More Decks by Mayuka Sugimoto

Other Decks in Technology

Transcript

  1. Copyright © Henry, Inc. All rights reserved. CoLab Conf 2026

    Summer 株式会社ヘンリー 杉本麻由香 「わかる」から「つくる」へ: CREがAIで開発に踏み出すまでの道筋
  2. Copyright © Henry, Inc. All rights reserved. 2 お品書き 1

    CRE になるまでと CRE としての歩み 2 ヘンリーの CRE 3 CRE として開発に取り組むまで
  3. Copyright © Henry, Inc. All rights reserved. 3 はじめに 今日は「すごい

    AI 活用技術」の話はしません いち CRE である mayuzo が AI を使うことで どう CRE のミッション達成に寄与しているかの話をします
  4. Copyright © Henry, Inc. All rights reserved. 杉本 麻由香 /

    Mayuka Sugimoto / mayuzo   @nanaka1103 • 製品本部 CRE部 ◦ 2025年12月入社 • ← 建設業界向けSaaS企業 CREチーム マネージャー • ← 医療系の神戸市の外郭団体 社内SE • ← 国語科教員 自己紹介 4
  5. Copyright © Henry, Inc. All rights reserved. 6 CRE とは

    • CRE = Customer Reliability Engineers (Engineering) ◦ Google Cloud が 2016 年に新しい職種として提唱 • 顧客の課題(問い合わせ/障害/運用)を、エンジニアリングで解決する役 割 • 日本での定義は各社バラバラ ◦ テクニカルサポート〜開発まで幅広い
  6. Copyright © Henry, Inc. All rights reserved. 7 なぜ YOU

    は CRE に? • 社内 SE をやる中で、部署間調整からの落とし所を決める部分が得意だし面 白いと気付いた • ここから、自分のエンジニア経験と得意を活かした役割にシフトしたかった
  7. Copyright © Henry, Inc. All rights reserved. 8 社内 SE

    の具体① • 社内向けの工数管理システムの開発・運用保守を担当 • ユーザーは社内の各部署 • 使用言語 ◦ Backend: Java / Struts ◦ DB: MySQL ◦ たまに VBA でいけるような軽いのもやったり
  8. Copyright © Henry, Inc. All rights reserved. 9 社内 SE

    の具体② • さまざまな部署へのヒアリング • 要望をもとに仕様調整 • 実装、テスト、リリース • 問い合わせ対応・運用保守 ◦ 毎月の工数データ出力を含む
  9. Copyright © Henry, Inc. All rights reserved. 10 面白かったこと・不得意だったこと 面白かったこと

    • ヒアリングからの要件定義 • データ抽出と分析 不得意だったこと • 実装 ◦ 「めちゃくちゃおもしろい」 という感じではなかった ◦ 自分よりうまく・早く実装し てくれる人がたくさんいる → 得意を深めていける役割がいいんじゃない?
  10. Copyright © Henry, Inc. All rights reserved. 12 実装をしない CRE

    になった • たまたま内定をいただいたのが「テクニカルサポートの CRE」だった • 主に問い合わせ対応を担当することとなった CRE の主な仕事 • 問い合わせ対応(80%) ◦ 不具合調査・仕様確認・データ抽出 etc • サポート向けダッシュボードの作成 • 問い合わせフローの整備・構築 • 仕様ドキュメントの作成
  11. Copyright © Henry, Inc. All rights reserved. 13 問い合わせ対応内でやっていたこと •

    問い合わせ対応のためのデータ・ログ調査 ◦ 時にコード調査 • より使いやすいシステムになるために、要望やバグを集約 ◦ 実装の詳細な要件定義 ◦ 優先度付けしてバックログ化 ◦ →いつでもエンジニアが着手できる状態へ
  12. Copyright © Henry, Inc. All rights reserved. 14 CRE は面白い①

    • 単純に、タスクとしての面白さ ◦ 問い合わせ対応を通じてユーザーの困りごとが解決する実感 ◦ どんどん倒していける達成感 • プロダクト全体を理解していく面白さ ◦ 横断組織としてプロダクトの繋がりを見ていく立場 • 部門・プロダクトを超えてコミュニケーションを推進していく面白さも ◦ ex. 機能間連携の問い合わせ対応/問い合わせ・障害対応フローの整備
  13. Copyright © Henry, Inc. All rights reserved. 15 CRE は面白い②

    • 実装こそしないものの、CRE は組織にとって必要だと感じた ◦ プロダクトチームがよりよいプロダクトを届けるのを伴走する立場 ◦ そのためにこぼれ落ちる玉を拾う立場 ◦ 自分がよいと思うプロダクトを、ユーザーが満足して使い続けるため の打ち手を打てる立場 • ユーザー理解・プロダクト理解は、領域が広くなるほど難しさが増すが、そ れが面白かった
  14. Copyright © Henry, Inc. All rights reserved. 16 どんどん倒していける…? •

    「どんどん倒していける」と言いましたが、実際は CRE だけで倒せないもの も多く存在した • それは「バグ修正」を始めとする機能改修
  15. Copyright © Henry, Inc. All rights reserved. 17 バグ修正の壁 •

    当時の私の壁は「自分で実装できないこと」 • これによりユーザーのお困りごとの解決までのリードタイムが延びる
  16. Copyright © Henry, Inc. All rights reserved. 18 なぜ実装できないの? ①

    • 影響範囲が読めなかったから ◦ 普段は各プロダクトに造詣の深いエンジニアが実装している ◦ CRE は「仕様」に詳しいが、「実装」に詳しいわけではなかった ◦ 安易に実装して不用意なバグを生むかもしれない ◦ 現在開発中の機能とコンフリクトが起こるかもしれない
  17. Copyright © Henry, Inc. All rights reserved. 19 なぜ実装できないの? ②

    • CRE がロードマップ上の開発を行っているわけではない ◦ CRE が把握しているのはあくまで「バグ・要望対応の優先度」 • 「これ作りたいです!見てください!」はプロダクト側にとって差し込み • 結果としてコミュニケーションコストが生まれてしまう ◦ もちろん、それを乗り越えてプロダクトチームと協力して実装もでき たことも多くあるが、差し込みに変わりはなかった…… ◦ ロードマップとの調整が大変
  18. Copyright © Henry, Inc. All rights reserved. 20 普段コードを書かないエンジニアが修正する怖さ •

    影響範囲が読めない+普段コードを書かないエンジニアが急に修正 ◦ → 致命的なバグを引き起こす確率が上がるのでは • 機能が多岐にわたり相互に関連していると、思ってもみないところにバグを 生む ◦ CRE だけでなく誰でも起こりうるが
  19. Copyright © Henry, Inc. All rights reserved. 21 当時の結論 •

    コードを書くことは諦めた • コードを読み、当たりを付けられる時は当たりを付けるまでやり、あとはプ ロダクトチームに任せる 上記は、当時としては正しい決断だった。最速がこの形だった。 実際、自分たちでバグを修正していけるほど開発のための時間を持てなかった し、開発していたら問い合わせ対応ができなくなっていた。 ただ、個人的な所感として、とても小さな表記揺れも自分で直せず力不足を感 じていたのも事実だった。
  20. Copyright © Henry, Inc. All rights reserved. 22 ここまでのまとめ •

    CRE として「コードを読む・原因を切り分ける」まではやった • でも影響範囲が読み切れず、経験も浅いので実装に踏み込めなかった • ここまではテクニカルサポートとしての CRE の経験の話
  21. © 2026 Henry, Inc. 製品の紹介 病院業務のDXを実現する業界唯⼀の 電⼦カルテ「Henry」 Henryは、⽇本の病院向けに開発された唯⼀のクラウド ネイティブな「レセコン⼀体型電⼦カルテ」です。 40年以上にわたり、医療現場の⽣産性向上を⽬的とした電⼦

    カルテ‧レセプト会計システム(レセコン)は存在してきまし たが、業界の主流は依然としてオンプレミス型製品です。この ⻑年変化の少なかった市場に対し、Henryは完全にゼロからク ラウドベースのサービスを開発‧提供しています。 私たちは、基幹業務を担う電⼦カルテによる病院業務のDX こそが、医療現場の⽣産性向上に最も効果的だと確信してい ます。Henryは、低コストと使いやすさを兼ね備え、医療 スタッフの業務効率化と患者ケアの質向上を同時に実現しま す。
  22. Copyright © Henry, Inc. All rights reserved. 25 ヘンリーの CRE

    組織 ① • 2026 年 4 月に誕生した • 導入、設定、移行、保守改善まで含めて、顧客が安定して成果を出せる状態 をつくることを目指す • 今は 利用支援チーム・導入改善チーム・こまいの解決し隊に分かれて、課題 解決のために動いている ◦ 参考: https://dev.henry.jp/entry/what-is-cre-at-henry
  23. Copyright © Henry, Inc. All rights reserved. 26 ヘンリーの CRE

    組織 ② 利用支援チーム 契約済みの顧客がサービスの利 用を開始/継続できるよう支援 する • 日々の問い合わせ対応・仕 様確認 • ユーザーへの機能の展開 ◦ 展開のための開発 導入改善チーム 導入件数が将来増えたときに備 えて導入支援をより効率的に成 立させる • 導入が安定して楽になるよ うな開発を行う ◦ 設定画面の開発など こまいの解決し隊 既存顧客の顧客信頼性を維持/ 改善する • ユーザー要望に基づき、 さっと実装できるものを開 発 ◦ 工数が少なくてインパ クトのある機能改善を 優先的に開発 ヘンリーの CRE は、開発を行うことが前提。 問い合わせ対応でも機能改善でも実装のスピード感が求められる。
  24. Copyright © Henry, Inc. All rights reserved. 27 なぜスピード感が必要か •

    Henry は中小病院向けの電子カルテとして後発 • 機能が圧倒的に足りていない • 大きい機能は専属チームが開発し、既存の改善は CRE で回す体制に
  25. Copyright © Henry, Inc. All rights reserved. 28 AI が役立つ時がきた

    • スピードを上げるために「今こそ AI で開発したい」と思うようになった • 私が CRE として解決手段を増やす必要があった • CRE にはシニアエンジニアが在籍しているので、コーディングに関してサ ポートを得ることができた • わからないことがあれば プロダクトチームをはじめ、 「わかる人」の支援を受ける ことができた
  26. Copyright © Henry, Inc. All rights reserved. 30 AI コーディングによって変わったこと

    • 今まで諦めてきた「実装」ができるようになった • 怖かった影響範囲調査も、AI とともに確実性を上げてできるようになった ◦ 問い合わせ対応の中で仕様確認やコード調査のツールとして普段から 使うことで、勘所ができてきた ◦ 「開発する」までのステップを小さくすることができた
  27. Copyright © Henry, Inc. All rights reserved. 31 CRE のタスクへの効果

    • コーディングという解決手段が増えた! • スピード感を持ってユーザーのお困りごとを解決しやすくなった!
  28. Copyright © Henry, Inc. All rights reserved. 33 丸投げできない理由 ①

    : コンテキスト • 電子カルテとその周辺領域はコンテキストが重要 • なぜその実装/動きになっているかは、制度や医療機関の運用に合わせて作 られている • AI は背景となる制度や運用までは理解できない ◦ ドキュメント化が不足している、という課題もある • ゆえに、実装の方向性があまりよくない場合がある
  29. Copyright © Henry, Inc. All rights reserved. 34 丸投げできない理由 ②

    : 説明責任 • 自分の能力以上のコーディングは説明できない • レビュワーに「どういう意図でこの実装にしたのか」と聞かれた時に詰む • 意図を取りづらく、コミュニケーションコストがかかる実装になることもあ る ※ 「AI で全部書けるなら人間のレビューは不要では?」という論もあるが、ここでは人間レ ビュー前提とする
  30. Copyright © Henry, Inc. All rights reserved. 35 だから心がけるようにしたこと •

    「おおよそ合っているだろう」でレビューに回さない • 「なぜこの実装にしたか」を説明できるまで実装を見直す • AI に任せた部分ほど、意図を言語化する
  31. Copyright © Henry, Inc. All rights reserved. 36 説明できる実装の例 •

    全てを定数化しない ◦ 局所利用で意味が文脈から明確・使い回しがないならマジックナンバーで もよい場合がある ◦ 例:〇〇コードは 20 桁と決まっているので、わざわざ定数化しなくてよ い Kotlin private const val XXX_CODE_LENGTH = 20
  32. Copyright © Henry, Inc. All rights reserved. 37 今やっていること •

    よりスピード感を上げるために、意志を持ってコードを書くことに再度挑戦 している • 自身のコード理解・プログラミング力を高める • AI ができたからといって、自分の技術を諦めない • AI をよりよく使えるように言語化能力を高めていきたい
  33. Copyright © Henry, Inc. All rights reserved. 38 今日のまとめ •

    CRE の重要な役割の一つは、ユーザーのお困りごと・要望を早期に解決する こと • CRE としてスピードが出なかった原因の一つに、CRE だけで解決できない課 題があった • AI が出現したことにより、CRE の解決手段が増え、スピードが上がった! • ただし AI に丸投げは、コンテキストの欠如によりまだ難しい場合がある • さらにスピードを上げるために、いま私がやるべきこと ◦ コンテキストを AI にわかるように落とし込むこと ◦ 自身のコード理解・プログラミング力を高めること
  34. Copyright © Henry, Inc. All rights reserved. 採用情報や事業や技術について、積極的に発信しています! 採用情報 採用募集ページ

    募集中の採用ポジションや募集要項 がご確認いただけます。 オープンポジションのカジュアル面 談も募集していますので、お気軽に お申し込みください。 技術ブログ はてなブログ ヘンリー製品開発チームが運営する 技術ブログです。 会社公式ブログ note ヘンリーで働く人や医療業界や事業 のことが幅広くしれる公式ブログで す。 CEO の逆瀬川も個人で NOTE を発 信しているのでぜひ! 理想駆動ラジオ Spotify プロダクト開発・運営の様子をお届 けするポッドキャストです。 40