Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
「わかる」から「つくる」へ / CRE Goes Dev: Building with AI
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Mayuka Sugimoto
June 27, 2026
Technology
87
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
「わかる」から「つくる」へ / CRE Goes Dev: Building with AI
コラコン 2026 夏 スポンサーセッション
Mayuka Sugimoto
June 27, 2026
More Decks by Mayuka Sugimoto
See All by Mayuka Sugimoto
アンドパッド流 インシデント対応とポストモーテム / ANDPAD's Approach to Incident Response and Postmortem
mayuzo
0
90
SRE じゃなくてもできる! インシデント対応で鍛えた CRE チームの5年史 / Five-year history of CRE's hard work in incident response
mayuzo
1
12k
ANDPADのCREが業務改善に取り組んできた話 / Efforts To Improve CRE Tasks
mayuzo
0
220
Other Decks in Technology
See All in Technology
AI時代におけるエンジニアの新たな役割──FDEとクオリアの探求/登壇資料(戸井田 裕貴)
hacobu
PRO
0
460
AIコード生成×サプライチェーン攻撃 — PHPが直面する“二重の信頼問題
shinyasaita
0
490
どこまでAIに任せるか 〜確率論と決定論の境界決定〜
shukob
0
530
「休む」重要さ
smt7174
7
1.7k
現場との対話から始める “作る前に問い直す”業務改善
mochico50
2
310
それでも、技術なブログを書く理由 #kichijojipm / Why I Still Write Tech Blogs Even Now
shinkufencer
0
930
AI研修(Day2)【MIXI 26新卒技術研修】
mixi_engineers
PRO
1
740
「待ち時間」の消滅と「自我消耗」の加速:生成AI時代のエンジニアを救うメンタル・リソース管理
poropinai1966
0
200
2年前に削除したPHPクラスが、 ある日突然決済をエラーにした
ykagano
1
840
データエンジニアリングとドメイン駆動設計
masuda220
PRO
14
2.7k
『モデル + ハーネス』で読み解く AIエージェント入門
oracle4engineer
PRO
2
200
なぜ、あなたのAPIは使われないのか? AX時代の設計原則、ガードレール、運用体制
yokawasa
1
230
Featured
See All Featured
Unsuck your backbone
ammeep
672
58k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
47
8.2k
The Organizational Zoo: Understanding Human Behavior Agility Through Metaphoric Constructive Conversations (based on the works of Arthur Shelley, Ph.D)
kimpetersen
PRO
0
390
Money Talks: Using Revenue to Get Sh*t Done
nikkihalliwell
0
420
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.8k
Odyssey Design
rkendrick25
PRO
2
730
How to Think Like a Performance Engineer
csswizardry
28
2.7k
Introduction to Domain-Driven Design and Collaborative software design
baasie
1
910
Imperfection Machines: The Place of Print at Facebook
scottboms
270
14k
The Invisible Side of Design
smashingmag
301
52k
Mozcon NYC 2025: Stop Losing SEO Traffic
samtorres
1
420
BBQ
matthewcrist
89
10k
Transcript
Copyright © Henry, Inc. All rights reserved. CoLab Conf 2026
Summer 株式会社ヘンリー 杉本麻由香 「わかる」から「つくる」へ: CREがAIで開発に踏み出すまでの道筋
Copyright © Henry, Inc. All rights reserved. 2 お品書き 1
CRE になるまでと CRE としての歩み 2 ヘンリーの CRE 3 CRE として開発に取り組むまで
Copyright © Henry, Inc. All rights reserved. 3 はじめに 今日は「すごい
AI 活用技術」の話はしません いち CRE である mayuzo が AI を使うことで どう CRE のミッション達成に寄与しているかの話をします
Copyright © Henry, Inc. All rights reserved. 杉本 麻由香 /
Mayuka Sugimoto / mayuzo @nanaka1103 • 製品本部 CRE部 ◦ 2025年12月入社 • ← 建設業界向けSaaS企業 CREチーム マネージャー • ← 医療系の神戸市の外郭団体 社内SE • ← 国語科教員 自己紹介 4
01 CRE になるまでと CRE としての歩み Copyright © Henry, Inc. All
rights reserved. 5
Copyright © Henry, Inc. All rights reserved. 6 CRE とは
• CRE = Customer Reliability Engineers (Engineering) ◦ Google Cloud が 2016 年に新しい職種として提唱 • 顧客の課題(問い合わせ/障害/運用)を、エンジニアリングで解決する役 割 • 日本での定義は各社バラバラ ◦ テクニカルサポート〜開発まで幅広い
Copyright © Henry, Inc. All rights reserved. 7 なぜ YOU
は CRE に? • 社内 SE をやる中で、部署間調整からの落とし所を決める部分が得意だし面 白いと気付いた • ここから、自分のエンジニア経験と得意を活かした役割にシフトしたかった
Copyright © Henry, Inc. All rights reserved. 8 社内 SE
の具体① • 社内向けの工数管理システムの開発・運用保守を担当 • ユーザーは社内の各部署 • 使用言語 ◦ Backend: Java / Struts ◦ DB: MySQL ◦ たまに VBA でいけるような軽いのもやったり
Copyright © Henry, Inc. All rights reserved. 9 社内 SE
の具体② • さまざまな部署へのヒアリング • 要望をもとに仕様調整 • 実装、テスト、リリース • 問い合わせ対応・運用保守 ◦ 毎月の工数データ出力を含む
Copyright © Henry, Inc. All rights reserved. 10 面白かったこと・不得意だったこと 面白かったこと
• ヒアリングからの要件定義 • データ抽出と分析 不得意だったこと • 実装 ◦ 「めちゃくちゃおもしろい」 という感じではなかった ◦ 自分よりうまく・早く実装し てくれる人がたくさんいる → 得意を深めていける役割がいいんじゃない?
CRE と出会った!!! Copyright © Henry, Inc. All rights reserved. 11
Copyright © Henry, Inc. All rights reserved. 12 実装をしない CRE
になった • たまたま内定をいただいたのが「テクニカルサポートの CRE」だった • 主に問い合わせ対応を担当することとなった CRE の主な仕事 • 問い合わせ対応(80%) ◦ 不具合調査・仕様確認・データ抽出 etc • サポート向けダッシュボードの作成 • 問い合わせフローの整備・構築 • 仕様ドキュメントの作成
Copyright © Henry, Inc. All rights reserved. 13 問い合わせ対応内でやっていたこと •
問い合わせ対応のためのデータ・ログ調査 ◦ 時にコード調査 • より使いやすいシステムになるために、要望やバグを集約 ◦ 実装の詳細な要件定義 ◦ 優先度付けしてバックログ化 ◦ →いつでもエンジニアが着手できる状態へ
Copyright © Henry, Inc. All rights reserved. 14 CRE は面白い①
• 単純に、タスクとしての面白さ ◦ 問い合わせ対応を通じてユーザーの困りごとが解決する実感 ◦ どんどん倒していける達成感 • プロダクト全体を理解していく面白さ ◦ 横断組織としてプロダクトの繋がりを見ていく立場 • 部門・プロダクトを超えてコミュニケーションを推進していく面白さも ◦ ex. 機能間連携の問い合わせ対応/問い合わせ・障害対応フローの整備
Copyright © Henry, Inc. All rights reserved. 15 CRE は面白い②
• 実装こそしないものの、CRE は組織にとって必要だと感じた ◦ プロダクトチームがよりよいプロダクトを届けるのを伴走する立場 ◦ そのためにこぼれ落ちる玉を拾う立場 ◦ 自分がよいと思うプロダクトを、ユーザーが満足して使い続けるため の打ち手を打てる立場 • ユーザー理解・プロダクト理解は、領域が広くなるほど難しさが増すが、そ れが面白かった
Copyright © Henry, Inc. All rights reserved. 16 どんどん倒していける…? •
「どんどん倒していける」と言いましたが、実際は CRE だけで倒せないもの も多く存在した • それは「バグ修正」を始めとする機能改修
Copyright © Henry, Inc. All rights reserved. 17 バグ修正の壁 •
当時の私の壁は「自分で実装できないこと」 • これによりユーザーのお困りごとの解決までのリードタイムが延びる
Copyright © Henry, Inc. All rights reserved. 18 なぜ実装できないの? ①
• 影響範囲が読めなかったから ◦ 普段は各プロダクトに造詣の深いエンジニアが実装している ◦ CRE は「仕様」に詳しいが、「実装」に詳しいわけではなかった ◦ 安易に実装して不用意なバグを生むかもしれない ◦ 現在開発中の機能とコンフリクトが起こるかもしれない
Copyright © Henry, Inc. All rights reserved. 19 なぜ実装できないの? ②
• CRE がロードマップ上の開発を行っているわけではない ◦ CRE が把握しているのはあくまで「バグ・要望対応の優先度」 • 「これ作りたいです!見てください!」はプロダクト側にとって差し込み • 結果としてコミュニケーションコストが生まれてしまう ◦ もちろん、それを乗り越えてプロダクトチームと協力して実装もでき たことも多くあるが、差し込みに変わりはなかった…… ◦ ロードマップとの調整が大変
Copyright © Henry, Inc. All rights reserved. 20 普段コードを書かないエンジニアが修正する怖さ •
影響範囲が読めない+普段コードを書かないエンジニアが急に修正 ◦ → 致命的なバグを引き起こす確率が上がるのでは • 機能が多岐にわたり相互に関連していると、思ってもみないところにバグを 生む ◦ CRE だけでなく誰でも起こりうるが
Copyright © Henry, Inc. All rights reserved. 21 当時の結論 •
コードを書くことは諦めた • コードを読み、当たりを付けられる時は当たりを付けるまでやり、あとはプ ロダクトチームに任せる 上記は、当時としては正しい決断だった。最速がこの形だった。 実際、自分たちでバグを修正していけるほど開発のための時間を持てなかった し、開発していたら問い合わせ対応ができなくなっていた。 ただ、個人的な所感として、とても小さな表記揺れも自分で直せず力不足を感 じていたのも事実だった。
Copyright © Henry, Inc. All rights reserved. 22 ここまでのまとめ •
CRE として「コードを読む・原因を切り分ける」まではやった • でも影響範囲が読み切れず、経験も浅いので実装に踏み込めなかった • ここまではテクニカルサポートとしての CRE の経験の話
02 ヘンリーの CRE Copyright © Henry, Inc. All rights reserved.
23
© 2026 Henry, Inc. 製品の紹介 病院業務のDXを実現する業界唯⼀の 電⼦カルテ「Henry」 Henryは、⽇本の病院向けに開発された唯⼀のクラウド ネイティブな「レセコン⼀体型電⼦カルテ」です。 40年以上にわたり、医療現場の⽣産性向上を⽬的とした電⼦
カルテ‧レセプト会計システム(レセコン)は存在してきまし たが、業界の主流は依然としてオンプレミス型製品です。この ⻑年変化の少なかった市場に対し、Henryは完全にゼロからク ラウドベースのサービスを開発‧提供しています。 私たちは、基幹業務を担う電⼦カルテによる病院業務のDX こそが、医療現場の⽣産性向上に最も効果的だと確信してい ます。Henryは、低コストと使いやすさを兼ね備え、医療 スタッフの業務効率化と患者ケアの質向上を同時に実現しま す。
Copyright © Henry, Inc. All rights reserved. 25 ヘンリーの CRE
組織 ① • 2026 年 4 月に誕生した • 導入、設定、移行、保守改善まで含めて、顧客が安定して成果を出せる状態 をつくることを目指す • 今は 利用支援チーム・導入改善チーム・こまいの解決し隊に分かれて、課題 解決のために動いている ◦ 参考: https://dev.henry.jp/entry/what-is-cre-at-henry
Copyright © Henry, Inc. All rights reserved. 26 ヘンリーの CRE
組織 ② 利用支援チーム 契約済みの顧客がサービスの利 用を開始/継続できるよう支援 する • 日々の問い合わせ対応・仕 様確認 • ユーザーへの機能の展開 ◦ 展開のための開発 導入改善チーム 導入件数が将来増えたときに備 えて導入支援をより効率的に成 立させる • 導入が安定して楽になるよ うな開発を行う ◦ 設定画面の開発など こまいの解決し隊 既存顧客の顧客信頼性を維持/ 改善する • ユーザー要望に基づき、 さっと実装できるものを開 発 ◦ 工数が少なくてインパ クトのある機能改善を 優先的に開発 ヘンリーの CRE は、開発を行うことが前提。 問い合わせ対応でも機能改善でも実装のスピード感が求められる。
Copyright © Henry, Inc. All rights reserved. 27 なぜスピード感が必要か •
Henry は中小病院向けの電子カルテとして後発 • 機能が圧倒的に足りていない • 大きい機能は専属チームが開発し、既存の改善は CRE で回す体制に
Copyright © Henry, Inc. All rights reserved. 28 AI が役立つ時がきた
• スピードを上げるために「今こそ AI で開発したい」と思うようになった • 私が CRE として解決手段を増やす必要があった • CRE にはシニアエンジニアが在籍しているので、コーディングに関してサ ポートを得ることができた • わからないことがあれば プロダクトチームをはじめ、 「わかる人」の支援を受ける ことができた
03 CRE として 開発に取り組むまで Copyright © Henry, Inc. All rights
reserved. 28
Copyright © Henry, Inc. All rights reserved. 30 AI コーディングによって変わったこと
• 今まで諦めてきた「実装」ができるようになった • 怖かった影響範囲調査も、AI とともに確実性を上げてできるようになった ◦ 問い合わせ対応の中で仕様確認やコード調査のツールとして普段から 使うことで、勘所ができてきた ◦ 「開発する」までのステップを小さくすることができた
Copyright © Henry, Inc. All rights reserved. 31 CRE のタスクへの効果
• コーディングという解決手段が増えた! • スピード感を持ってユーザーのお困りごとを解決しやすくなった!
ただし… 全てを AI に丸投げはまだできない(と感じている) Copyright © Henry, Inc. All rights
reserved. 31
Copyright © Henry, Inc. All rights reserved. 33 丸投げできない理由 ①
: コンテキスト • 電子カルテとその周辺領域はコンテキストが重要 • なぜその実装/動きになっているかは、制度や医療機関の運用に合わせて作 られている • AI は背景となる制度や運用までは理解できない ◦ ドキュメント化が不足している、という課題もある • ゆえに、実装の方向性があまりよくない場合がある
Copyright © Henry, Inc. All rights reserved. 34 丸投げできない理由 ②
: 説明責任 • 自分の能力以上のコーディングは説明できない • レビュワーに「どういう意図でこの実装にしたのか」と聞かれた時に詰む • 意図を取りづらく、コミュニケーションコストがかかる実装になることもあ る ※ 「AI で全部書けるなら人間のレビューは不要では?」という論もあるが、ここでは人間レ ビュー前提とする
Copyright © Henry, Inc. All rights reserved. 35 だから心がけるようにしたこと •
「おおよそ合っているだろう」でレビューに回さない • 「なぜこの実装にしたか」を説明できるまで実装を見直す • AI に任せた部分ほど、意図を言語化する
Copyright © Henry, Inc. All rights reserved. 36 説明できる実装の例 •
全てを定数化しない ◦ 局所利用で意味が文脈から明確・使い回しがないならマジックナンバーで もよい場合がある ◦ 例:〇〇コードは 20 桁と決まっているので、わざわざ定数化しなくてよ い Kotlin private const val XXX_CODE_LENGTH = 20
Copyright © Henry, Inc. All rights reserved. 37 今やっていること •
よりスピード感を上げるために、意志を持ってコードを書くことに再度挑戦 している • 自身のコード理解・プログラミング力を高める • AI ができたからといって、自分の技術を諦めない • AI をよりよく使えるように言語化能力を高めていきたい
Copyright © Henry, Inc. All rights reserved. 38 今日のまとめ •
CRE の重要な役割の一つは、ユーザーのお困りごと・要望を早期に解決する こと • CRE としてスピードが出なかった原因の一つに、CRE だけで解決できない課 題があった • AI が出現したことにより、CRE の解決手段が増え、スピードが上がった! • ただし AI に丸投げは、コンテキストの欠如によりまだ難しい場合がある • さらにスピードを上げるために、いま私がやるべきこと ◦ コンテキストを AI にわかるように落とし込むこと ◦ 自身のコード理解・プログラミング力を高めること
ブースで待ってます! ご清聴ありがとうございました Copyright © Henry, Inc. All rights reserved. 38
Copyright © Henry, Inc. All rights reserved. 採用情報や事業や技術について、積極的に発信しています! 採用情報 採用募集ページ
募集中の採用ポジションや募集要項 がご確認いただけます。 オープンポジションのカジュアル面 談も募集していますので、お気軽に お申し込みください。 技術ブログ はてなブログ ヘンリー製品開発チームが運営する 技術ブログです。 会社公式ブログ note ヘンリーで働く人や医療業界や事業 のことが幅広くしれる公式ブログで す。 CEO の逆瀬川も個人で NOTE を発 信しているのでぜひ! 理想駆動ラジオ Spotify プロダクト開発・運営の様子をお届 けするポッドキャストです。 40