はじめに 処方箋データ連携チームでエンジニアをしている岩佐（孝浩）です。 カケハシには「岩佐」さんが複数名在籍しており、社内では「わささん」と呼ばれています。 私が所属する処方箋データ連携チームでは、これまで Slack App を用いて社内管理画面を構築・運用してきました。 しかし、運用を続ける中でいくつかの課題が明らかになってきたため、現在は Lambda Web Adapter を利用した Web アプリケーションへの移行を進めています。 本投稿では、Slack App から Web アプリケーションへの移行に至った背景と、移行前後のシステム構成についてご紹介します。 移行の背景 Sla…

ヘルステックスタートアップであるカケハシは、シリーズDで累計150億円の資金調達を実施しました。 カケハシ、約140億円のシリーズDラウンドを実施 | 株式会社カケハシのプレスリリース ベンチャーデットを活用した資金調達を実施 | 株式会社カケハシ - 日本の医療体験を、しなやかに。 プレスリリースにもあるように、新技術への投資や事業推進を見据えた人材への投資を積極的に実施します。組織基盤の強化やプロダクトの拡充による当社プラットフォームの拡大を加速し、次世代ヘルスケアの推進を通じた日本の医療課題解決を目指します。 難しい、でも誰かがやらなきゃいけない医療という社会課題の解決 少子高齢化が進む…

Let's Encryptのプロファイル選択機能 Let's EncryptにはProfile機能があり、異なる仕様のサーバ証明書を発行できます。 説明ページにある通り、現在classicとtlsserverの2種類のプロファイルが選択できます。（shortlivedプロファイルもありますが、まだ一般公開されておらず利用できません） プロファイルを選択すると何が変わるのか 何も選択しなければclassicプロファイルが選択されます。通常Let's Encryptの証明書といえばこの証明書です。tlsserverを選択すると、新しい仕様の証明書が発行されます。 「新しい仕様」とはCA/Brows…

こんにちは、処方箋データ連携チームの岡田です。 突然ですが、皆さんは開発の現場で 「あの決定、誰がいつ、どういう背景で決めたんだっけ？」 と頭を抱えた経験はありませんか？ 私はプロダクトに対する意思決定を行う立場上、こうした問いを投げかけられることが多く、その度に記憶を頼りにあやふやな回答をしては、もどかしい思いをしていました。ソフトウェア開発において、こうした「なぜ」の欠如は、手戻りやコミュニケーションコストの増大、そして「技術的負債」の温床となります。とくに、外的要因による方針変更の背景などは意識して記録しておかないと、あっという間に風化してしまいます。 そんな問題意識から、マネージャーと…

カケハシでの社内講演に、 株式会社一休 執行役員CTOの伊藤直也氏をお招きしました。同社がどのようにレガシーシステムから脱却し、事業リスクを抑えながらRust/Go/TypeScriptを使い分けてきたのかお話を伺いました。社内向けの場ではありましたが、非常に有意義だったためご本人の許可を得て外部向けにまとめました。 当日は、医療変革プラットフォーマーを目指すカケハシのチーフアーキテクトである木村彰宏との対談形式でお話を伺い、ファシリテーターはカケハシのテックリードである松山が務めました。   松山 ： 本日は宜しくお願いします。まず、一休での関数型プログラミングの導入の背景についてお聞かせください。     伊藤 ： 実は、最初から TypeScript による関数型プログラミングを目指していたわけではなく、結果的にそうなったという方が近いです。参照透過性などへの強いこだわりよりも、「型がちゃんと効いてるほうが嬉しい」くらいの比較的軽い動機でした。弊社ではそれまで C# や Python でオブジェクト指向による開発を行ってきました。 私自身、この業界で20年近く、 Java や Perl、Ruby といった言語も使ってきましたが、どのシステムも何度作っても結局は同じことの繰り返しで、時間が経つとアーキテクチャの解釈が人によって異なったりして、技術的負債が蓄積して作り直し、というサイクルを繰り返していました。新システムを作るのにこれまで通りの方法で作っても何も変わらないだろうなと感じ、 新しいプロジェクトでは従来型のクラスベースのオブジェクト指向から一度離れてみよう、というのが出発点 でした。  Webアプリケーション開発という前提と、社内の技術的文脈から、静的型付け言語としてはTypeScriptが現実的な選択肢でした。TypeScriptらしい、よりスケーラブルな書き方を模索する中で、クラスを使ってDTOに値を詰めてgetter/setterを書くような、旧来の手法ではないスタイルにたどり着きました。結果として、以前よりコードの書き方に統一感も出て、壊れにくくなったと実感しています。 クラスベース設計の限界としては、getter/setterのボイラープレート問題に加え、人数の増加に伴い実装方針にばらつきが出やすい点がありました。 オブジェクト側に実装を寄せる人もいれば、オブジェクトへの委譲をそこまでやらない人もいる。ドメインロジックを内部でしっかり処理する人もいれば、DTOとして扱ってロジックを外部に書いてしまう人もいて、ある程度コードレビューなどで方針を統一しても、新しい人が入ると同じ問題が再発するという状況でした。   松山 ： 「どこに処理を書くか」という問題は、関数型でも起こり得るように思いますが、何か違いがあるのでしょうか？ また、以前Xでも言及されていた「Domain Modeling Made Functional」について、クラスベースが一般的なドメイン駆動設計を関数型で実践する上で、大変な点はありましたか？   伊藤 ： 正直なところ、なぜ現在うまくいっているのかあまり深くは考えていませんでした。ただ、おそらく関数型であること以上に、型による設計上の制約が強く働いているからかもしれません。例えば、「ワークフローはドメインロジックを起動するための部品であり、ロジックは必ずデータの近くに関数として書く」という構成にしていますが、型の制約もあるためか、その方針に自然と収束していく感じがします。 また、関数型ではIOを途中でいきなり発生させにくいという制約が、逆にロジックを自由に書きすぎることを防ぎ、良い方向に作用しているように思います。  ドメイン駆動設計を関数型で行うことは、それほど大変ではありません。オブジェクトの内部状態を更新する際に、オブジェクト自体を書き換えるのではなく、引数をコピーして変更した値を返すという基本を徹底するだけで、全体のアーキテクチャ自体は従来のものと大きく変わらず、イディオムが変わる程度です。   松山 ： 関数型を進めていく上での理想像はありますか？ 例えば、Haskellのように堅牢だが学習コストが高いというイメージではなく、皆が書きやすいような理想があれば教えてください。   伊藤 ： TypeScriptで関数型プログラミングを行う上で悩ましいのは、エラーや例外をどう扱うかですね。我々はResult型を導入して大域的な例外のスローはしないようにしていますが、Result型をモナドなどの支援機構なしで書くのは面倒ですね。 とはいえTypeScriptで他に良い方法も思いつかないので、多少の記述の面倒さを受け入れつつもそれでやっています。あとは代数的データ型が、模倣ではなくもっと言語の基本操作として書けると良いのですが。エコシステムのことを無視して文法的な理想だけを追うなら、結局Haskellが一番良いと考えています。学習コストは確かに高いんでしょうけど、かといって 学習コストの低い言語はすなわち、必要な概念が実装されていない ということでもあり。 Haskellのdo記法のようなモナドの仕組みが言語に組み込まれていると、Result型やOption型、Maybe型のようなモナディックな構造を扱う際にコードをフラットに書けます。TypeScriptでもモナドなどを使いたい気持ちはありますが、サードパーティのライブラリなどで無理矢理導入するとTypeScriptらしからぬ複雑なコードになりがちなためResult型のみを導入するに留めています。それでもなお無理した記述をせざるを得ない場面もあって「言語に組み込まれた形でのモナドがあればなあ、Haskell はいいよな」という気持ちに着地してしまいます(笑)   松山 ： ありがとうございます。木村さんもバックエンド開発の経験があり、TypeScriptも書かれていたと思います。伊藤さんのお話を聞いてどう思われましたか？   木村 ： 伊藤さんのお話には非常に共感します。私は2019年頃(前職)からバックエンドでTypeScriptを選択しています。Webサービス向けのSDKをTypeScriptで提供していました。SDK側にビジネスロジックが多く含まれていたのをバックエンドにリビルドしていく過程でロジックの可搬性が重要だったので、バックエンドをTypeScriptで構築していました。 私はキャリアの中で長らくScalaを使った開発をしていて、イミュータブルな設計思想や副作用の局所化、型による制約を他の言語でも実現したいと考えていました。このようなスタイルはどんな言語でも実現しようと思えばできますが、TypeScriptが程よい選択肢だと思っています。 私もワークフローのような組み方をすることが多く、制約を設けるやり方には共感します。制約は一時的にアジリティを下げるかもしれませんが、 ユースケースの書き方や責務の分け方を都度議論して統一性のあるコードを作るコストの方がはるかに高い と感じています。easyでないコードでもあらかじめベストプラクティスを用意しておけば、メンバーがそれに沿って開発を進めてくれるという実感がありました。  私が以前fp-tsを導入したのは、ただ単にエラーを型(Either)で表現し、その型に応じたエラーハンドリングを実施したかったからです。関数シグネチャを見るだけでエラーが把握できるようにしたかったのです。それ以外のAPIはあまり使わないようにしていました。業務ロジックでEitherを導入すると、複数のEitherを1つのEitherに結合するような機会がよくあるので、Traverse処理が簡潔にできるライブラリを探していました。 今は、neverthrowを使うようにしていますが、当初はTraverse処理にそこまで開かれていなかったので、fp-tsを導入しました。 Either型(あるいは、Result型)は、TypeScriptではタグ付きユニオン型で定義され、その型の関数が定義されているだけなので、手続き的にも書ける柔軟性があります。現場では、関数シグネチャをしっかり定義し単体テストが書けていれば、手続き的な書き方でもひとまず受け入れていました。プルリクエストでのやり取りの中で、宣言的な書き方を紹介していくうちにチームがそのスタイルに慣れていった感覚があります。ただ、 一部処理の機能要件を達成するために導入したライブラリが、気が付くとあらゆるレイヤーにおいて利用され、プロジェクト全体が「関数型的」なコードになってしまい、少しやりすぎではないかと感じることもありました。ある意味それだけ、関数型プログラミングのスタイルが浸透したともとれるのですが。   松山 ： おふたりとも、開発において型によるより強い制約を設けるための手段として関数型プログラミングに着目されているように伺えました。   伊藤 ： そうですね。もちろん、他にも利点は多くあると思いますが、特にWebアプリケーション開発においてはそれが重要だと思います。   複数言語戦略とRustの採用 松山 ： Rustの採用は、どういった経緯があったんでしょうか？   伊藤： 一休で提供しているレストラン事業向けのシステムは元々Pythonで開発していましたが、コロナ禍で約2年間開発を停止していました。開発再開時にPythonモジュールのアップグレードが難航したのと、もともとPython製アプリケーションはコンテナでの実行効率が悪く Goで書かれたホテル事業のシステムに対し、Pythonでは10倍ほどのクラウドのリソースを要していて、これはさすがにちょっとなと思っていました。 他にも色々ありまして、しばらく開発を停めていて負債化してしまったシステムを再度まともな状態にもっていくのに労力を使うぐらいなら、このタイミングで作り直すのがいいだろうと判断しました。 より高速な言語を検討する中で、宿泊事業で使っていたGoが候補に挙がったのですが、私の経験上、 事業が異なるなら別のプログラミング言語を使い、社内に2〜3種類の異なるシステムがあっても良いだろう という直感的な経験則があり、Go以外の言語でのリプレースを考え始めました。 社内にRustに非常に明るいエンジニアがいたので「WebアプリケーションをRustで作るの、今ならどう？」と質問してみたところ「いけるんじゃないですか？」ということだったので、Rustの盛り上がりやエコシステムに将来性を感じていたこともあり、まず1画面だけ書き換えてみよう、という形で始まりました。実際にやってみると心配していたメモリ管理周りでのつまずきの声はほとんど聞こえてきませんでした。 それよりも非同期ランタイムの使い方やCPUバウンドな処理のオフロード方法とか、そういう他の言語ではあまり意識しない部分が、チーム内にRustに詳しい人がいないと難かっただろうな、という印象でした。それ以外はあまり、Rustに固有の苦労話というのは聞いていません。プロダクションに投入してみたところ、やはり速度に関しては圧倒的で、Pythonでバックエンドを捌いていたときに比べ、ずっと少ないリソースで安定的に稼働させることができました。 松山 ： 複数言語を使うメリットは何でしょうか？ 人材流動性が一時的に下がる可能性もあると思いますが。   伊藤 ： 「最大のメリット」というわけではありませんが、採用にプラスになる点はわかりやすいと思います。Rust、Go、TypeScriptなど、多様な技術を扱える体制は外からみたときに魅力的なんでしょうね。しかしこれは副次的メリットで、 本質的なメリットは、特定の技術やプラットフォームへの過度な依存を避け、会社全体の技術スタックが急に時代遅れになるリスクを軽減できること でしょうか。 私が以前在籍していた会社では使用言語を特定の言語一つに統一していましたが、当時 Ruby on Railsの台頭があったためか、自分たちが依存していた言語のエコシステムが急速に縮小してしまって、当初思い描いていたような形での運用が難しくなったことがありました。 そういう経験もあったので、可能であれば複数の言語を併用してポートフォリオを組む方が柔軟に対応できるかもしれないなと考えるようになりました。 「この技術が最先端だ」と思われているうちは問題ありませんが、どんな技術にも流行のピークがあり、いずれ安定期や衰退期に入ります。 新しい魅力的な技術が登場した際に、会社全体が一つの技術に固執していると身動きが取りづらくなってしまいます 。 木村 ： 以前勤めていた会社では、使用するプログラミング言語を主要なものに絞ることで、部署を横断して知見を共有しやすくなるとともに、メンバーが異なるプロジェクトへスムーズに移動できるといったメリットを享受していました。ただ、おっしゃるように、プログラミング言語をはじめとする技術への分散投資ができていないと技術の衰退や市況環境の変化に直接的な影響が出てしまいますよね。個人のキャリアを振り返ってもそういった変化に追随できるよう選択をしてきましたし、それは組織運営においても重要ですよね。 とはいえ、短期的には一つの言語に絞った方が良い場合もあると思います。そういった技術選定を、技術に詳しくない経営層にどう説明されているのでしょうか？   伊藤 ： 正直なところ、 「いい感じにやっとくんで」くらいしか言っていません （笑）。事業ごとに別言語を使っていることを経営層に詳細に説明することはあまりないですね。これまで信頼貯金を貯めてきたことで「その辺はこの人に任せておけばよいだろう」と思われていると解釈してます。 とはいえ任されているからといって好き勝手やっているわけではないです。私はこの会社に後からCTOとして参画しましたし、会社は私が辞めても存続するものなので、 組織が長く続くことを前提に考えています 。ポートフォリオを組んでおけば、先に話したようなリスクに対して強くなるだろうし、私が退任した以降もその効果は続くだろうとか、そういうことは意識しますね。 元々社内は .NET 中心でしたが、一気には変えられない。徐々にGoを取り入れて、.NET と並行稼働になり··· と技術的負債を返却する過程で結果的に常に2つ3つの技術を持つ状態になりました。当初から「混在していていいのか？」と社外から質問されることもありました。以前は経験値も少なかったので、ややごまかすような説明しかできなかったものの、今では「技術の多様性を担保するためです」と自信を持って言えるようになりました。 松山 ： 複数の言語を運用するのは、ベンチャー企業の初期には難しいと感じます。企業の規模やチームがある程度大きくなってから取り入れられるものでしょうか？   伊藤 ：おっしゃる通りです。弊社でも複数言語を使っていますが、事業単位では特定の言語に絞ります。例えば、ホテル事業は基本的にGoのみ、レストラン事業はRust、私が関わっているSaaS系のレストラン向けプロダクトはTypeScript、といった具合です。ベンチャー企業は基本的にワンプロダクトでしょうから、初期に技術ポートフォリオのために複数の言語を使い分けることは考えられないでしょうね。 松山 ： 新しいプロダクトを立ち上げる際の言語選定の基準は何ですか？ メンバーに合わせるのか、それとも他の基準があるのでしょうか？   伊藤 ： 合理性とメンバーのモチベーションの両方を考慮します 。どちらか一方では決めないです。理屈だけ··· たとえばビジネスのことを考えてこうでこう、みたいな理由で選んでもそれを使うメンバーがやる気を持てなければうまくいきませんし、逆にメンバーがやりたい言語だけで決めるとバランスを欠くとか、中長期的な視点を欠くこともあります。 「やりたい人がいること」と「その言語やエコシステムに将来性があること」 、この両方の条件が揃ったものを採用するようにしています。Rustの場合も、社内に詳しいメンバーがいたからこそ任せられると思い採用しました。   トップダウンで進めた技術移行とチームの変化 松山 ： 技術の移行をトップダウンで進めると、社内から様々な反応があったかと思います。賛成や反対、共感や反感など、どのように対処し、説明し、納得を得るためにどんな取り組みをされたのでしょうか？     伊藤 ： .NETからオープンソース系のGoやPythonへ移行した際は、「なぜそんなことを？」という雰囲気も多少感じました。私も入社してそれほど時間が経っておらず、現場からの信頼もそれほど得られていない状況です。しかし、一人ひとりを説得していては進まないし、トップダウンで進めてある程度形になってから「こういう理由でこうしました、よろしくね」と理解を求める形を取りました。最初から全員の合意を得ようとすると、細かい議論ばかりで前に進めません。 最終的に決める人間が責任を持ってトップダウンで進めるのが最も現実的 でした。反対意見を押し切れるのは、権限と責任を持つ立場だからこそです。 おそらく現場では“不安”が大きかったんだと思います。慣れ親しんだ.NET、Windows、Visual Studioから未知のプラットフォームへ移行するわけですから。弊社は元々.NET畑の人が多くて、全員WindowsでVisual Studioを使って開発していました。そこにMacでPythonやらRubyやらを書いている私が入ってきて「これでやって」と言うのですから、不安になるのも当然だと思います。それでも、時間の経過とともに「新しいことができて楽しい」という空気が広がっていきました。 古いシステムで作っていた人たちにとっては、新しいシステムの方が楽に書けるしテストもきちんと実行できるし、デプロイもしやすい。こっちの方が開発しやすいな、と支持されるようになっていったと思います。そういう新しいプラットフォームへの切り替えを過去何度かしてきたため、最近のRustやTypeScriptで新しい開発を始める際には、かつてのような不安はもうなくなっていたと思います。   松山 ： ”雰囲気が変わる”というのは、具体的に感じられるものですか？ チーム単位での違いや、個人の適応力の問題などはありましたか？   伊藤 ： はい、それは感じますね。先ほど申し上げたように、古い環境からPythonやGoに移行した際には、開発のしやすさから支持が広がりました。一度、言語移行の成功体験を組織全体で共有できたことが大きく、その後のRustやTypeScriptへの挑戦も前向きに進められたのだと思います。   技術選定と信頼の築き方、マネジメントの役割 松山 ： 以前、naoyaさんとSHIFTの川口さんの対談で「良い兄貴問題」について触れられていたのが印象的でした。最近のエンジニアマネージャーはメンバー育成に注目が集まりがちですが、本来は目標達成が最も重要だというお話に共感しました。改めてご説明いただけますか？   伊藤 ： はい。「良い兄貴問題」とは、マネジメントを始めた人がやがて現場の仕事をやらなくなって、メンバーが面倒に思っている調整ごとや雑務を巻き取ることで好かれるものの、 気がつけば事業や開発を推進する力を失っている、という状況 を指します。 マネージャーはコードも書かず企画やプロジェクトを先導することもしなくなり、事業やプロダクトに関する解像度が落ちてかつてのような全能感を失う。それでもチームの役に立とうと1on1や組織運営といった“周辺業務”ばかりに邁進するようになって、現場では“役に立たない人”になってしまう。 マネージャーの本来の役割はチームで目標を達成すること であり、メンバーのモチベーション向上などはその手段の一つでしかないです。しかし、調整や雑務ばかりでは事業やプロダクトが行き詰まったとき、その局面を打開するのに組織的なアプローチしか取れなくなってしまう。だからこそ、「プロダクトを作ることや、コードを書くことを続けよう」と伝えています。  少し話はかわりますが、私たちは技術と事業目標を直接結びつけることはしません。事業目標と技術は多くの場合関係がないので、目標設定に技術の話を混ぜ込むとおかしなことになります。例えば関数型でシステムを作りたいとして、それを無理やり事業目標に結びつけようとすると「関数型プログラミングの方が事業に貢献する」なんていう妙な屁理屈を捻りだすことになる。だから、 事業目標達成にコミットする、その手段は我々に任せてほしいというスタンス です。その上で自分たちが快適で効率的な開発環境を整えることができれば、仕事も捗り成果にも繋がるでしょう、そういう順番です。目標と技術的手段は分離して考えています。  ただし、常に事業目標を優先せよ、というようなメッセージを強く打ち出しすぎると今度は「技術は手段である」という側面が強調されすぎて、技術的なチャレンジがしにくくなってしまいます。技術的に正しいことは技術的に正しいこととして、大義名分をもって実行していきたいですよね。そういう後押しもマネジメントがしていきます。 Rustへの書き換えのような大きな判断は、「事業的にRustが正解だから」というような ごまかしたような主張はせず、「技術的にこっちの方がいいからそうしよう」という話をストレートにして、後押ししてきました 。 この話が「良い兄貴問題」とも関連します。技術的負債の返済を正面からビジネス側に説明するのは非常に困難です。しかし、マネージャーがプロダクト開発に主体的に関与し、状況をコントロールしていれば、「次の新機能開発時にこの部分も書き換える」という判断と実行が可能です。マネージャーが調整役に徹していると、こういうビジネスと技術の双方を加味したミクロな判断ができません。結果、ビジネス要求をチームに流すだけになって、技術的負債の返却は、別途現場でプロジェクト化するしか方法がなくなります。しかしそのプロジェクトの遂行にはステークホルダーの説得が必要だが、前述の通りそれは難しい。ゆえにいつまで経っても、プロジェクトを進める機会がやってこない。 結論、 自分たちのプロダクトやサービスに対するコントロールをどれだけ持てるかが重要 で、そこを握っていれば技術的な判断も主体的に行えます。ここを手放さないためにもマネジメントがプロダクトやサービス開発に主体的であることが重要だと考えています。   松山 ： それは信頼があってこその話だと思いますが、どのように信頼を築いてこられたのでしょうか？     伊藤 ： 目標達成はもちろんですが、 ステークホルダーの期待に日々きちんと応える続けること ですね。「この人たちには、やり方も含めて任せればいいんだな」と思われたら良いんです。 私も入社当初は社長を含め周囲から全く信頼されておらず、プロジェクトへの人員割り当てを事細かく全て説明することを求められたりすることもありました。しかし、成果を出し続けるうちに、徐々に「この人には細かいことを言わなくても大丈夫だ」と思われるようになっていったと思います。ここでの成果は、開発的な成果というよりはビジネスまで含めた成果です。 以前、レストランの基幹システムをビジネス上の課題解決のために作り直すプロジェクトがあり、それを全面的に任されました。課題把握から解決策の実行まで全て自分でやって、まあまあ期待通りの内容で完遂したあたりから、「この人は任せて大丈夫だ」と認識されたようです。それが大きなきっかけだったと思います。   松山 ： なるほど、ありがとうございます。木村さんにお伺いしますが、今後社内で様々な施策を展開されるにあたり、トップダウンやボトムアップなどをどのような形で進めていくイメージを持っていますか？   木村 ： 私はアーキテクトなので、「どんな問題を解くか」という問題定義の部分は、ある程度トップダウンで示す必要があると考えています。しかし、「どう解くか」まで全てトップダウンで決めるつもりはありません。「こういう課題があるので、こういうアーキテクチャにすべき」「この品質特性を守るにはこういう技術が必要」といったガイドラインレベルの話はするかもしれませんが、基本的にはそこまでです。  カケハシのエンジニアはサービス指向性が強く、向かうべき方向さえ明確になれば自律的に動ける方が多い ので、細かく指示するのはおこがましいとすら思っています。 一方で、抽象的なことばかり言っていると思われないよう、今も現場でコードを書いています。 トヨタの豊田章男さんの「トップダウンとは自分でやって見せることだ」という言葉に共感しており、最終的には「自分が全ての責任を負う」──そういう覚悟で取り組んでいます。 私の考えた課題が全て正しいとは思っていないので、あくまで「叩き台」として問題を提示し、現場の声も聞きながら一緒に進めていくことが多いです。ただ、現在の会社の規模は大きく、ドメインも5〜6個あるため、全てを個別に見るのは困難です。そのため、ドメインチームごとにアーキテクトを配置し、その方々と対話しながら進めていく体制を考えています。   AIと共に進化する開発現場・役割の再定義と人間の価値 松山 ： 最近Devinを使い始めて、人間の仕事が今後どう変わるのか気になるようになりました。エンジニアの仕事もAIで大きく変わっていくと思いますが、どう見ていますか？   伊藤 ： 変化の速さには正直驚いています。2年前にChatGPT-3.5を触った時は「AIもコードを書けるようになってきたな」程度でしたが、1年半でここまで実用的になるとは予想外でした。もっと時間がかかると考えていましたが、未来予測が全然当たらないですね。 こういう状況では未来を正確に予測しようとすることより、足下で起きていることにどう適応していくかを重視したほうがいいかなと思っています。 先のことは分からないが、目の前のことを早めにキャッチアップして、適応する 。それを繰り返していれば、先のことはわからないものの、それなりの位置には立ち続けていられるだろうという考えです。 昨今社内では、フロントエンドのコードはかなりAIに任せるようになっています。プレゼンテーションはドメイン知識が少なくても、デザインシステムやFigmaの情報があれば生成できるようで、うまく活用されています。ただし、大規模なコードや複雑なドメインロジックはまだAIでは難しいですね。フロントエンド中心の人たちは、AIを積極的に活用し、別のことに時間を使うようにもなっています。組織全体で、現在どこまでAIに任せられるか、逆にどこが難しいかの肌感覚を掴むためにも、まずは皆に積極的にAIを使ってもらう必要があると考えています。 ここは敢えて、手段を目的化するフェーズ かなと思っています。   木村 ： 技術革新の真っ只中で様々なパラダイム・シフトが発生していますが、あまり流行りに左右されずに裏で動いている構造の理解をし、エンジニアリングに落とし込んでいきたいですね。 確かに、ドメインロジックを自律的に組んでもらうことは難しいですが、ある程度線引きは可能かもしれません。 ドメインモデリングには「探索」と「体系化」の2つのフェーズがあり、探索フェーズではAIエージェントにアイデア出しや支援をしてもらうのが有効だと考えています。体系化フェーズではドメイン知識が必要なので開発者が主体となりますが、ある程度進んでくると部分的に自律的AIに任せられるかもしれません。  個人的には、生成AIのパラダイム以前から、ドメインロジックが組めて検証が済むと「だいたい仕事が終わったな」という感覚を抱くことが多かったです。アダプターの部分は単純化しやすいため、そこがAIで効率化されたのが現在のフェーズだと認識しています。   松山 ： ありがとうございます、本日は以上とさせていただきます。貴重なお話をありがとうございました。 伊藤 ： こちらこそ、ありがとうございました。  

カケハシCTOの湯前です。 この度、一般社団法人 日本CTO協会の幹事に就任いたしました。 本記事では、なぜこのタイミングで幹事をお引き受けすることにしたのか、その経緯と想いについてお話しさせてください。 「CTO」を捉えきれなかった頃 実は、日本CTO協会のお誘いは、数年前から何度かいただいていました。当時はまだCTOという役職ではなく、「どう？」と声をかけていただく度に、やんわりとお断りしていました。 その頃の自分は、「CTO」という存在をまだ明確に捉えきれていませんでした。CTOとしてどのようなリーダーシップを発揮するべきなのか、経営に対してどのように関与していくべきなのか。その輪郭がぼやけている中で、自分がそのコミュニティに貢献できることは何もないと感じていたのです。 逃げ場のない「緊張感」と、本気の誘い しかし、いよいよ自分がCTOという役割を拝命し、その職務を全うしようと日々奮闘する中で、その認識は大きく変わりました。 「技術組織のトップが投げ出してしまったら、自分の後ろには誰もいない」 この強烈な緊張感は、CTOになって初めて心の底から理解した感覚です。事業の成長、組織のあるべき姿、技術的な挑戦、そしてメンバーのキャリア。そのすべてに対する責任を一身に背負う中で、日々生まれる葛藤。このポジションならではの重圧と孤独を痛感する毎日でした。 そんな葛藤を抱えていたある日、理事である広木さんから、こう声をかけていただきました。 「そろそろ、本当に手伝ってもらえないですか」 それは、これまでのような気軽な誘いとは違う、本気の言葉でした。自分が今まさに感じている大変さや葛藤を理解した上で、だからこそそこでしか出来ないことがあるのではないかと言われた気がしました。 恩返しと、熱量の渦の中へ 広木さんを始め、日本CTO協会の理事や幹事の方々、そして会員の皆さまには、これまで言葉では言い尽くせないほどお世話になってきました。 Podcastでご一緒させていただいた方、毎月のように1on1で壁打ち相手になってくださる方、ふらっと飲みに誘っては的確なアドバイスをくれる方、インタビュー記事を通してその思考に深く学ばせていただいている方々。振り返れば、私のキャリアは、常にこのコミュニティの皆さんに支えられていました。 この方々への恩返しがしたい。そして、今度は自分がその組織の中に入ることで、この素晴らしいコミュニティを一緒に盛り上げていきたい。広木さんの言葉をきっかけに、そう強く思うようになりました。 その想いをさらに確固たるものにしたのが、先日参加した経営合宿です。 今後の協会の方向性を決めるその場では、深夜2時、3時になっても議論が終わりませんでした。「日本CTO協会は今後どうあるべきか」「次世代のCTOとは何を指すのか、そして我々もどのように成長していくべきなのか」。日本のスタートアップ・エコシステムやテックカンパニーを本気で良くしたいと考える人々の熱が、そこには渦巻いていました。この光景を目の当たりにして、自分の心にも火がついたのを感じました。 コミュニティの力で、CTOの「集合知」を創る 私は、日本CTO協会の活動を「 コミュニティ活動 」だと捉えています。 CTOと一口に言っても、その役割は会社のフェーズや本人のスキルセットによって実に多様です。だからこそ、「CTOって、結局何をする人なんだっけ？」という問いが生まれやすく、それぞれのCTOが孤独な戦いを強いられる場面も少なくありません。 この状況を、コミュニティの力で変えていきたい。それぞれの知見や悩みを持ち寄り、共有し、議論することで、価値ある「集合知」を形成していく。CTO協会が、そんなプラットフォームになるのではないか。 かつて私がEM（Engineering Manager）のコミュニティで、Podcast「 EM.FM 」を始めたり、「 EOF2019 」や「 EMConf JP 」といったカンファレンスを主催したりしたのも、同じ想いからでした。情報を発信する側、そして情報を集めて広める側に身を置くことで、自分自身に新たな情報や視点が集まり、それが結果としてコミュニティ全体に良い影響を与えていく。その手応えを、身をもって感じてきました。 これまでの経験を活かし、今度は日本CTO協会という場で、コミュニティの盛り上げ役の先頭に立っていきたいです。例えば、日本CTO協会の発信している情報は現在CTOの方ももちろんですが、次世代のCTOとなるEMやVPoEにも有用であると考えています。そういったコミュニティ同士の架け橋(偶然にも社名と一緒ですが)になり、 日本CTO協会に新しい風が舞い込み、盛り上がりが作れると良いなーと考えています。 そして、この活動を通じて得られるであろう多くの学びや繋がりは、必ずや本業であるカケハシでの活動にも還元できると信じています。 まだまだ未熟者ではありますが、日本の技術力向上、そしてスタートアップ・エコシステムの発展に少しでも貢献できるよう、幹事として精一杯務めさせていただきます。 皆様、どうぞよろしくお願いいたします。  

カケハシのプロダクトをあらゆるユーザーが安全に、かつ簡単に使えるようにしていくために欠かせない業務を担っているのが、Musubiアカウント管理基盤チームです。 このチームが担う重要な役割とは何でしょうか。今回はMusubiアカウント管理基盤チームのプロダクトマネージャー（PdM）・藤﨑翔吾と、エンジニア・松岡康夫のふたりに、チームの現在地、そして今後の目指すべき姿について聞きました。 Musubiアカウント管理基盤チームとは？ Musubiアカウント管理基盤チーム プロダクトマネージャー 藤﨑翔吾 —チーム発足の経緯から教えてもらえますか？ 藤﨑：5年以上前にさかのぼりますが、当時カケハシはク…

生成AI時代における「ガバナンス×SRE」の新しい責務 SREチームの乙二です。 生成AIが業務に浸透する今、医療データを扱うカケハシの全社SREとして、可用性とレイテンシを守る従来の活動ではリスクを吸収しきれないと感じました。 そこで私たちが取り組んだのが、SREの強みを「セキュリティ/プライバシー/法令遵守」へまで拡張し、情報漏えい・規制違反のリスクを管理するSRE組織への変革です。 カケハシでは生成AIサービスを利用する場合は、SRE、DRE(Data Reliability Engineering)、情報システム、法務といったガバナンス担当者間で連携しながら社内生成AIガイドラインに基…

こんにちは。カケハシで生成AI開発のプロダクトリードをしている高梨です。 最近、今更ながらキングダムと ONE PIECE を全巻揃えるかどうかで悩んでいます。 しかしそれは終わりなき戦いの始まりであると同時に、安息の時（睡眠時間）の終焉でもあるためなかなか覚悟が決まりません。 ちなみに ONE PIECE は109巻と110巻だけ買いました。 それ以外の巻とキングダム全巻がカートに入ったまま2ヶ月が経過しました。 閑話休題 今日は SaaS is Dead について、カケハシのプロダクト開発チームが考えていることことを書こうと思います。 SaaS is Dead の文脈をカケハシがどのように…

カケハシで技術広報を担当している櫛井です。 カケハシは2025年5月27日(火)〜30日(金)の期間で開催された2025年度 人工知能学会全国大会にて、プラチナスポンサーを務めました。また、カケハシの島吉がポスターセッションで発表いたしました。www.ai-gakkai.or.jp こちらのエントリでは、当日の会場での様子やセッション資料の紹介をいたします。 カケハシが実施したスポンサー カケハシはプラチナスポンサーとしてブースを出展し「AI活用で医療体験をアップデートするカケハシの取り組み」などをご紹介したり、会話文から薬歴を自動生成するAIアシスタントチャット機能のデモを行いました。 また…

こんにちは、生成AI研究開発チームのデータサイエンティストとしてAI開発を担当している保坂です。 本記事では、薬局の現場オペレーションを支援するAIを開発する私たちのチームが、ドメインエキスパート（薬剤師など） と データサイエンティスト の協働を円滑にするために構築した「Databricks × Dify x Colaboratory 協働基盤」を紹介します。生成AIプロダクトチームを新たに組成する際におさえたい3つのポイント の記事で、生成AIプロダクト開発にはドメインエキスパート人材の協力が不可欠だということを書いているのですが、その裏側について、深くお話ししたいと思います。 なぜ協働が…

こんにちは、椎葉です。2025年3月にVPoT(VP of Technology)に就任しました。しなやかな医療体験の実現に向けて、カケハシの技術全体を見ながら取り組んでいきます。今回は、どうしてVPoTという役割が生まれたのか、実際に何をやっているかについてお話しします。 先週、CTOの湯前とチーフアーキテクトの木村とのインタビュー記事が公開されましたので、こちらも合わせてご覧ください。 なぜVPoTという役割が生まれたのか カケハシにはCTOがいるのに、なぜVPoTという役割を新たに作ったのでしょうか。それは、CTO湯前の「現場の感覚をもっと経営につなぎたい」という思いからです。 湯前は開…

こんにちは、生成AI研究開発チームのエンジニアリングマネージャーの鳥越です。最近の生成AIのお気に入りの使い方は、好奇心旺盛な小学生の息子の不思議な質問を一緒に聞くことです。「四天王があるのに、五天王がないのはなぜか」「工事現場には春日部ナンバーがなぜ多いのか」「秋休みがないのはなぜか」など、どこで役に立つかわからない知識が増えてますが、なかなか楽しいです。 さて、カケハシでは生成AIを社内活用するだけでなく、プロダクトのエンハンスメントでも組み込みを始めていますが、従来の機械学習(以下ML)を活用したプロダクト開発と、生成AIを活用したプロダクト開発とでは、直面する課題や運用上の論点、それを…

カケハシの開発組織を俯瞰する「技術戦略室」は、CTO・チーフアーキテクト・VPoT(VP of Technology)の3人からなるチーム。カケハシの今後を占う技術戦略と、その実現のための組織ビジョンについてそれぞれの観点から語り尽くしてもらいました。 抽象と具体、事業と技術をつなぐためのチーム 執行役員CTO 湯前 慶大 —まず、技術戦略室を立ち上げることになった経緯を教えてください 湯前：継続的なプロダクト開発において必要なのは、目の前の課題解決に集中するとともに、一歩先を見据えた戦略立案を両輪で回すことです。日々の開発を支え、次のステップへと導いていくためのチームとして2024年に技術戦…

こんにちは、技術広報の櫛井です。 カケハシではカンファレンスや勉強会などの技術イベントにおいて、「コーヒースポンサー」として高品質なコーヒーの提供を行ってきました。 カケハシは「 日本の医療体験を、しなやかに。 」をミッションに掲げ、 患者さんのための薬局づくりのパートナーとして 複合プロダクトで薬局DXをトータルサポートしているヘルステックスタートアップです。 カケハシがコーヒースポンサーにこだわっている理由、どのように実現しているのかをこのエントリではご紹介したいと思います。 人と人をつなぐ、コミュニケーションのきっかけに 私たちが技術イベントでコーヒーを提供する最大の目的は、参加者同士の交流を促進することにあります。コーヒーを手にすることで自然と会話が生まれ、異なる分野の専門家同士が出会い、新たなアイデアが生まれる場を創出しています。 イベントの休憩時間やセッションの合間。緊張感の中で思考を巡らせる時間に、ふと手に取るコーヒーは、単なる飲み物以上の役割を果たしてくれます。 コーヒーには以下のような医学的効果が報告されています。 カフェインによる覚醒作用と集中力の向上 *1 抗酸化物質による健康維持への貢献 *2 適度な摂取によるストレス軽減効果 *3 こうした効果は、長時間にわたる知的なインプット・アウトプットをする技術イベントにおいて、参加者のパフォーマンスを支える存在になり得ると考えています。 コーヒー愛に溢れた私たちのチーム カケハシには「ogijun」として知られる珈琲店の店主がおり、彼の深い専門知識と情熱がコーヒー提供の原動力となっています。(彼はカケハシでソフトウェアエンジニアとして普段活躍しています) 最近の技術イベントでは、彼が経営していたお店でコーヒーを学んだ方が鎌倉でオープンした「 自家焙煎珈琲Shadore（ シャドレ ） 」さんに協力してもらい、コーヒーを提供しています。 コーヒーの専門家が複数人いることで、参加者が400名を超える技術イベントでも一杯一杯こだわったネルドリップによる高品質なコーヒーの提供が可能になりました。 ogijunとシャドレの皆さん 鎌倉で見つける、珠玉の一杯 自家焙煎珈琲Shadore（ シャドレ ） さんの紹介をさせてください。 店舗は鎌倉の若宮大路に位置し、地元のお客様たちから支持を得ている珈琲専門店です。伝統的な焙煎技術とネルドリップによるアプローチで、訪れる多くの観光客にも新たな発見を提供しています。   「 人生のあらゆる場面に寄り添う珈琲でありたい 」と話す店主の相原さん。店内には古民家の古木を使った梁や、貴重な一枚板のカウンターがあり、落ち着いた心地よさを感じさせてくれます。   ゆったりとした雰囲気で落ち着いた店内 店主がこだわって集めているカップ なかには貴重なものも多数あります   季節ごとに厳選された豆を使用し、一杯ずつ丁寧に淹れられる珈琲は、鎌倉散策の特別な思い出になると評判です。   コーヒーの抽出には細心の注意が必要です 芳醇な香りが今日を少し特別にしてくれます もしお店へ行かれる時があれば「静かに珈琲を楽しんでほしい」というお店のコンセプトがあるので、店内では声量にご注意くださいね。 ページをめくる音とカップを置く音だけが響く、そんな一時 鶴岡八幡宮の参道である若宮大路沿いにあるので、春には桜が満開となります   自家焙煎珈琲Shadore（ シャドレ ） https://shadore.stores.jp/ https://www.instagram.com/shadore_kamakura/   これまでに生まれた繋がり これまで、たとえば以下のようなイベントで来場者の皆さんに本格的な一杯を楽しんでいただいています。 TSKaigi 2024 YAPC::Hakodate 2024 EMConf 2025 きのこカンファレンス2025 カケハシは #TSKaigi でコーヒースポンサーをしております☕ B1F Track1 の後方にて、職人が心を込めてネルドリップしております。コーヒーの提供開始は11:15から、たくさんご用意しておりますのでぜひお立ち寄りください！ pic.twitter.com/eGAjmIK9Gj — カケハシ技術広報 (@kakehashi_dev) 2024年5月11日 YAPC::Hakodate 会場、1F中央ではカケハシがコーヒースポンサーとして本格コーヒーを提供しております☕️ ハンドドリップですのでお待たせする場合もありますが、ご賞味ください。 #yapcjapan pic.twitter.com/PHviFTah4Q — カケハシ技術広報 (@kakehashi_dev) 2024年10月5日   技術イベントの会場で参加者の皆さんがコーヒーを片手にリラックスしたり、関連する技術やトピックについて議論をしている姿を見るのが私たちにとって一番うれしい瞬間です。 技術イベントでお会いしましょう カケハシは今後も、テクノロジーの力とコーヒーの魅力を融合させ、意義あるイベント体験の創出に貢献していきます。次回の技術イベントでも、ぜひカケハシが提供するコーヒーをお楽しみください。   直近の予定ですと、2025年5月23日(金)〜24日(土)の日程で開催予定の TSKaigi 2025 にてコーヒースポンサーとして提供予定です。   *1 : Effects of Caffeine on Cognitive Performance, Mood, and Alertness in Sleep-Deprived Humans - Food Components to Enhance Performance - NCBI Bookshelf https://www.ncbi.nlm.nih.gov/books/NBK209050/ *2 : Antioxidant and Antiradical Activity of Coffee - PMC https://pmc.ncbi.nlm.nih.gov/articles/PMC4665516/ *3 : Caffeine Consumption and Depression, Anxiety, and Stress Levels Among University Students in Medina: A Cross-Sectional Study - PMC https://pmc.ncbi.nlm.nih.gov/articles/PMC10616803/

はじめに こんにちは。 電子薬歴 Musubi の基盤開発チームで SRE を担当している大山です。 カケハシでは生成 AI の活用を丁寧に推進しています。 具体的な体制や方針については🗒️ 薬局DXをリードするカケハシは社内で生成AIをどのように活用しているのか?をご参照ください。 Musubi SRE チームでも生成 AI を導入し、業務効率化や生産性向上に大きな効果を感じています。最初は「便利そう」という印象でしたが、今では「活用しない選択肢はない」と考えるほどインパクトがありました。本記事では、生成 AI を活用した具体的な事例を 4 点ご紹介します。 対象となる読者 SRE がどのよ…

カケハシで技術広報を担当している櫛井です。 カケハシは2025年5月9日(金)〜10日(土)の期間で開催されたScrum Fest Niigata 2025にて、GOLDスポンサーを務めました。また、カケハシのHead of Engineering 小田中が登壇いたしました。www.scrumfestniigata.org こちらのエントリでは、当日の会場での様子やセッション資料の紹介をいたします。 会場の様子 現地会場とオンラインのDiscord会場が連動しているハイブリッド開催となりました。現地会場は沢山の参加者が聴講し、議論をする空間となりました。 カケハシが実施したスポンサー カケハシ…

ユーザー理解って大変 こんにちは。データが好きすぎる梶村です。 カケハシで薬局向けの在庫管理発注システムである「AI在庫管理」というプロダクトのPdMをしています。 プロダクト開発ではユーザー理解が一番大事だと分かっていても、実際に取り組むのは本当に大変です。薬局向けのプロダクトでは、店舗によって医薬品の在庫管理の運用や発注判断はさまざまであり、定性的にさまざまな店舗の方にヒアリングさせていただきながら、定量的に機能の利用状況を調査していくのは大変な作業です。 一方でPdMがヒアリングできる店舗や業務は限定的なので、営業やCSが認識している薬局の温度感とずれが生じてしまうと、「開発チームはユー…

カケハシの AI 在庫管理でソフトウェアエンジニアをしている鳥海 (@toripeeeeee) です。こちらの記事は 生成AI研究会 での取り組み記事になります。 カケハシでは、エンジニア個々のコーディング支援に留まらず、AI技術を活用して開発プロセス全体の生産性と品質を向上させることを組織的な目標としています。そこで今回は、こちらの記事で紹介した Slack のワークフローに Devin を用いて開発プロセスにAIを載せることで、リリース前の外部仕様書のチェックをAIにサポートしてもらう取り組みにトライしましたので、ご紹介したいと思います。 なぜ外部仕様書のレビューが重要なのか そもそも外部…

エンジニアの横田です。カケハシでは生成AIを活用し医療・薬局向けのプロダクトを開発しています。今回は、プライベートの話で恐縮ですが生成AIのキャッチアップのために150万円のMac Studio M3 Ultraを購入した話をしたいと思います。 150万円のMacについて 2025/3/5 にMac Studio M3 Ultraが発表されました。 私はOSSのLLM(大規模言語モデル)を使って遊ぶのが好きなので、M3 Ultraが発売された時に脅威のメモリ単価の安さに驚きました。 LLMを現実的な速度で動かすためにはメモリの大きさが重要です。Gemma 3やQwen 2.5のような強力なLL…