とりあえず他の人に説明するのに良さそうなので、ChatGPTに書かせた記事です。 Agentic CodingでCLIを実装していると、機能要件がどんどん進められる反面、非機能要件がないがしろになりがちです。自分は最近静的解析CLIを育てているのですが、OpenTelemetryでtracesとeventsをexportできるようにしました。結果として「どこで遅いか」「どの実装が遅いか」を事実として掴めるようになり、最適化を迷わず打てるようになりました。さらにJargerを使えばスクリーンショットやJSONとして結果を取得できるため、人間はもちろんCoding Agentにとっても計測と改善のループを回しやすくなります。 traces（Span）とは CLIの処理を「区間」に分けて、spanとして刻みます。例えば： 引数解析 入力列挙（ファイル探索など） 入力の読み込み 処理実行（処理ごと
株式会社ヘンリーでソフトウェアエンジニアをしているwarabiです。 ヘンリーは医療業界向けのプロダクトを開発しており、開発メンバーにも難解なドメイン知識が求められます。そのため普段からドメインの理解や深堀りに時間をかけたいところですが、実際は開発業務も進めなければならないため、時間の使い方に悩んでいました。 この課題に向き合うために、普段開発で使っているClaude Code（Anthropic社が提供するCLIベースのAIコーディングアシスタント）をもっとうまく活用し、実装にかける時間を減らして学習に充てる時間を増やせないかと考えました。 それまでのClaudeCodeの使い方と課題 それまでの私のClaude Codeの使い方は、一言で表すとAIとのペアプロです。 AIによるコードの変更をリアルタイムに確認しながらその場で質問もできるため、設計やサービスの理解には役立ちます。 ただ、
株式会社ヘンリーで SRE をしつつ、技術広報的なこともしている id:nabeop です。 2025年も会社でアドベントカレンダーを企画しました。2024年までは1トラックでの開催でしたが、2025年は2トラックでの開催をして多くのメンバーに参加してもらえるようにしました。 12/1 12/2 12/3 12/4 12/5 12/6 12/7 12/8 12/9 12/10 12/11 12/12 12/13 12/14 12/15 12/16 12/17 12/18 12/19 12/20 12/21 12/22 12/23 12/24 12/25 最後に 12/1 おそらくどの企業もはまっているパターンを言語化していて、それを打開しようする意思表明をしていてよかった。(杉本) あがたくんの発見が素直に出ていて素敵！(林) VPoPのagatanの気合いの入ったブログ。Podcastも
はじめに 師走も佳境ということで、自分の開発環境に新しく導入したツールや本年もお世話になったツールを棚卸しがてら紹介できればと思います！ 前提: 普段の開発スタイル 中学生という多感な時期にブラッディ・マンデイというドラマにハマってしまったせいで、ターミナルみたいな無機質な画面に向かって作業することがかっこいいと思っているエンジニアです。そんなわけで、普段の開発はNeovimを使い、ターミナルから出ない生活を送らせていただいてます。 最近は業務でフロントもバックエンドも触るので、tmuxで複数サーバーを立ち上げて切り替えながら作業しています。雰囲気はこんな感じです。 ターミナルはもちろん透過させてます。 私は新しいクルトガを買ってもらうと勉強を頑張れたタイプの人間なので、開発環境も同じ。ツールを自分好みにして気分を上げることで、作業効率も上げていくスタイルを採用しています。 それでは、以下
天然温泉が湧き出すひなびた旅館、スキーやスノボのお客をもてなすリゾートホテル、受託開発と自社開発で業績を伸ばすゲーム開発会社……。 こうしたさまざまな施設の運営や会社の経営が楽しめるシミュレーションゲームを、長年コツコツと作り続ける会社がある。 それが、社員数わずか20人強のカイロソフトだ。 カイロソフトの「ゲーム発展国++」「ゆけむり温泉郷」「冒険ダンジョン村」がNintendo Switchのeショップで10/11（木）にポロリと発売予定だよ。みんな持ち運んだり、大画面で遊んでちょんまげ。#カイロソフト #switch #スイッチ #任天堂スイッチ #GameDevStory #kairosoft pic.twitter.com/VlpRI0Vjas — カイロソフト(Kairosoft)_公式 (@kairokun2010) October 2, 2018 2018年10月にNint
畑中様 いつもSNSでの発信陰ながら拝見しております。 私は今他業種にいるのですが、どうしても漫画を作って生きていきたいと思い、読み切りを賞に投稿しようと考えています。これまでに何本か二次創作ですが、漫画を作りました。 その際、成果物に対する出張編集部でのご意見や有料の添削も踏まえ、自分は重い感情を描くのが得意だと分析しました。 しかし、読み切りで心情表現を読者が納得できるようにエピソードを描こうとするとどうしてもページ数が多くなります。今、やっと納得ができるプロットができ、ページ数無制限の賞に応募したいと思っていますが、60〜70Pは多すぎますでしょうか？ それとも一般的な読み切りのページ数(32〜56p程度？)でも自分の強みを活かせるように作劇の努力や工夫をすべきでしょうか？ ご回答よろしくお願いします。 この悩み実は、新人さんの連載の打ち切り原因トップ５に入るあるあるですね…。 大前
株式会社ヘンリーでVPoEを務めている戸田（id:eller）と申します。これはHenryアドベントカレンダー 2025 シリーズ 1における6日目の投稿です。昨日の記事は kobayang の デザインシステムライブラリを実装するためのテクニック でした。 本日は弊社で経営と執行を分離するためにどう権限委譲を進めてきたかをご紹介したいと思います。スタートアップのVPoEって何をやってるんだろう、という疑問にお答えできれば幸いです。 目次 目次 解きたい課題 何がブロッカーだったのか 課題を解く10ヶ月 1月: 方針の明確化と障害の分析を行い、戦略を立てる 3月: 医事チームを分割して権限委譲できる大きさにする 7月: 電子カルテチームを分割して権限委譲できる大きさにする 9月: 逆瀬川の部長兼務が終了する 11月: 縣が製品部門代表としてお客様にご挨拶をする 振り返って、VPoEは何をし
自動車レースの最高峰F1の2026年以降の国内での放送・配信権を、フジテレビが独占で獲得したことが4日、関係者への取材で分かった。11年ぶりに地上波でのダイジェスト放送が復活する。 関係者によると、…
ヘンリーで SRE をやっている id:nabeop です。 これは株式会社ヘンリー Advent Calendar 2025 (シーズン1) の2日目の記事です。昨日は VPoP (VP of Product) の縣 (id:agtn / @agatan) による事業戦略は技術戦略に影響を与えるが、技術戦略もまた事業戦略に影響を与えるべきでした。 今年の SRE チームの大きなトピックとしてクラウド基盤を Google Cloud から AWS に移設するプロジェクトが進んでいます。プロジェクト自体は去年から始まっており、粛々と進めていたのですが、ある程度の目処が立ってきたので今年の10月に外部向けにもプロジェクトの存在を公開しました。 カジュアル面談やイベントなどで AWS 移設について言及することがあったのですが、一番質問されたのは「なぜ、クラウド基盤の移設をするのか?」という内容で
こんにちは。ヘンリーで VPoP (VP of Product) をしている agatan です。 2025年の10月から、これまでのエンジニアとしての役割に加え、VP of Product & 製品部門長という役割を担うことになりました。 これまではテックリードやアーキテクトなど、エンジニアとして、ヘンリーの複雑で巨大なドメイン（レセコン・電子カルテ）に技術面からアプローチしてきました。 VPoPという立場になり、プロダクトと事業をより俯瞰して見る中で、自分の中にあった「ある種の先入観」に気づくことができました。 今日はその言語化と、これからのヘンリーの開発組織が目指す「技術と事業の関係性」について書いてみようと思います。 この記事は qiita.com の1日目の記事です！ 「技術戦略は事業戦略の従属変数である」と知らぬ間に思い込んでいた 先日のアーキテクチャカンファレンスでもお話しし
はじめまして、株式会社ヘンリーで VP of Engineering を務めております戸田と申します。弊社は中小病院の方々に向けて、医療情報システムやサービスを提供しているスタートアップです。私はフルスタックエンジニアとして、前職から続けて18年間にわたり基幹システム開発に携わってきました。 ITエンジニアとして日々コードを書き、システムを運用していると、つい自分の専門領域の中だけで世界を捉えてしまいがちです。しかし社会には、普段の仕事では触れることのない領域が数多く存在します。そのひとつが「医療」です。診察券を持ち、病院で待ち時間を過ごした経験はあっても、医療現場のシステムがどのように作られているかを知る機会はあまりないでしょう。 ところが、今後15年の日本において医療は大きな変革期を迎えます。その変化の背景には、私たちITエンジニアにとっても馴染みのある「技術選択」や「システム設計」の
こんにちは、株式会社ヘンリーのVP of Engineeringを務めている戸田（id:eller）です。このブログではヘンリーでどのようなEngineeringが行われているのかをお伝えしたく記事を執筆してきましたが、今回は趣旨を変えてインタビュー記事をお送りします！ 今回のテーマは今年の4月に発足した、隔週で行われている「製品支援部に作ってもらったら嬉しいな♪」という会議体です。製品支援部は「あなたの検査がカルテに書かれてから結果が返ってくるまでに裏側のシステムでは何が起きているのか」を書いた坂口がリードする部であり、電子カルテと外部システムとの連携部分や、導入時の設定や開発を実施しています。 この会議体では製品支援部が所属する製品部門と導入を担う営業部門とが協力して弊社サービスの導入の改善を継続的に行っており、すでに多くのアウトカムを生み出しています。しかも弊社の心得である「明るくさ
自分は以前、意思決定というのは「腹をくくる」「清水の舞台から飛び降りる」のように不可逆的かつ一定のダメージを覚悟する・リスクを負う行為だと思っていました。そして意思決定が関わる戦略が長期的であればあるほど、情報を集めても考えを深めても不確実性を下げることはほぼできませんから、意思決定の難度も高くなっていきます。この長期的な意思決定の代表例が企業の経営戦略でありスタートアップの企業理念なので、自分は企業経営に対して強い苦手意識を持っています。不可逆なリスクを負うには覚悟が必要で、その覚悟はどっから持ってくるんだ？というのが未解決問題だったわけです。 いやーやはり経営者ってすごいな。自分にはできんわ。— 医療情報ｾｷｭﾘﾃｨとｴﾝｼﾞﾆｱﾘﾝｸﾞのひと (@Kengo_TODA) 2022年7月6日 ただ最近、不可逆的にリスクを取りに行くだけが経営ではないというか、もうちょっと違う解釈への投影
株式会社ヘンリーで2025年3月からVP of Engineeringを務めている戸田（id:eller）です。任命から3ヶ月経ったので現状をまとめつつ、今後の見通しなどについてまとめたいと思います。 VPoEとVPoTの違い 私は1月からVP of Technologyも務めており、現在は兼務している状況にあります。本題に入る前にこれら2つがどう異なるか、ヘンリーではどう考えているかを整理してみます。 VP of Engineering（VPoE）はエンジニアリングについてステークホルダーに説明責任を持つポジションであると定義しています。エンジニアリングとは工学ですから、VPoEは工学的アプローチ、特に組織づくりや開発プロセスを見るわけですね。ヘンリーは組織規模を拡大している最中で、またフルリモートを特徴のひとつとしている会社でもあるため、組織づくりや開発プロセスは投資する価値が高い状況
支出管理開発本部で事業部横断テックリードをしている @ogugu です。 広く複雑で大規模になりつつある支出管理のアーキテクチャについて、以下の連載形式でご紹介していきます。 (本記事) 支出管理におけるTypeSpecを中心にしたスキーマ駆動開発 ソフトウェアアーキテクチャに基づいた自動テスト戦略と実装ガイドライン 支出管理におけるマイクロサービスアーキテクチャの知見 今回は、TypeSpec を中心にしたスキーマ駆動開発をご紹介します。 結論からいうと、筆者は TypeSpec について「OpenAPI からの移行コストや技術的ロックインリスクを伴わず、開発体験を向上する最高のツール」と評価しています。その理由を順にご紹介します。 TypeSpec とは OpenAPI とのスキーマの比較 導入の意思決定 TypeSpec を取り入れた開発フロー カスタム Linter / Decor
こんにちは。株式会社ヘンリーでエンジニアをしているagatanです。 私たちが開発する電子カルテ・医事会計システム「Henry」は、非常に巨大な単一のプロダクトです。そして、その性質上、明確なドメイン境界を見出すことが難しいという特性を持っています。この「巨大で複雑なプロダクトを、いかにして組織的に開発し続けるか」という問いに開発チームは長年向き合ってきました。 最近、この大きな問いに対する新たな一手として、かつて2つのgRPCサービスとして分割されていたバックエンドを、段階的に「1プロセスのモジュラーモノリス」へと移行させるプロジェクトが進捗しています。 今回は、その移行の過程についてお話しします。 第一歩: モノレポ化 移行への大きな第一歩目は、2年前に遡ります。当時、第一歩として踏み切った「モノレポ化」については、過去のブログでも紹介されています。 dev.henry.jp この記事
Twitter (X) でデジタル庁が出したnoteについての議論があり、様々な立場からの意見が集まっています。自分が感じたこと考えたことを残しておくと私自身の勉強になりそうなので、このブログでもちょっとまとめてみます。 一応コンテキストとして書いておくと、私はオンプレミスパッケージ製品の開発運用経験がある、クラウドネイティブSaaSのSRE 兼 セキュリティ担当です。 文脈 この情報の初出は今年の2月で、そういう意味では新しい情報ではないでしょう。ガバクラのコストの高さなどに注目が集まったタイミングで拡散しやすいnoteに情報が載った、という文脈が今回の注目量の背景にあると思います。 xtech.nikkei.com note.com 最近の流れを汲めていない内容になっているのは、2月に決まっていた内容をほぼそのまま載せたから、と考えられそうです。 この定義の着眼点 モダン化に限らず情報
株式会社ヘンリーでエンジニアをしている okbee です。 直近は製品のフルリニューアルを行なっており、詳細は省きますが、私もこの開発に参加しています。社内では「コスト連携」と呼ばれる機能の開発を主に担当していました。 「コスト連携」をざっくりと説明するならば、患者に対して医師が作成した指示（オーダー）を元にして、実際の金額を算出するためのワークフローです。詳細はコンテキストで紹介します。 さて、今回は「コスト連携」の実装を通して感じた反省を元に、より良い設計のヒントとして「コンパイルエラーを活用した手順不足の検知」を考えていきます。 コンテキスト コスト連携には臨床・会計の2つの大きなコンテキストが背景にあります。 患者に対して医師が作成する指示（以降はオーダーと表記）は臨床と呼ばれるコンテキストで作成されます。ちょうど、皆さんがクリニックなどで診察を受ける際に医師が薬を処方したり、注射
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く