はてなブックマーク

カケハシの 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のような強力なLLMを動かすためには、20GB程度のメモリが必要です。（4月末にQwen3も出ましたね！） さらに、LLMに入力するコンテキスト長を増やすためにもメモリは追加で必要になります。（例えば、Gemma 3を

生成AI研究開発チームのainoyaです。この記事では、カケハシが社内で生成AIの活用をどのように推進しているかについて紹介いたします。私は、この活動を支える「生成AI活用研究会」のリードを担当しています。 ※研究会は技術を軸とした社内コミュニティで技術領域ごとに存在しています 「日本の医療体験を、しなやかに。」というミッションを掲げ、薬局DXをはじめとした革新的なソリューションを提供するカケハシでは、医療という社会インフラを支える責任と、技術革新への飽くなき探求心を両立させながら日々進化を続けています。 近年、目覚ましい発展を遂げる生成AI技術は、私たちの働き方や提供する価値を大きく変える可能性を秘めています。カケハシでは、このポテンシャルを最大限に引き出すべく安全性を考慮しながら、業界の未来を切り拓くためにプロダクト活用にチャレンジする一方、社内における生成AIの業務活用も積極的に推進

AWSでDBを構築する場合、RDSのリザーブドインスタンス(RI)を利用することが多いと思います。しかし、一部のインスタンスタイプはRIが提供されずオンデマンド専用です。例えば東京リージョンのAurora MySQLの場合、r7iシリーズがこれに該当します。 ここでは調べ方について紹介します。 検索条件 ここでは調査対象をAurora MySQL 8.0系とします。また、RIのタイプは「1年全額前払い」とします。 RI未提供インスタンスの検索方法 まず利用可能なRDSインスタンスタイプのリストを取得します。リストはAWS CLIのrds describe-orderable-db-instance-optionsコマンドで出力できます。インスタンスタイプのリストはAuroraのバージョンごとに出力されるため、uniqコマンドで重複を削除します。リストにはAurora Serverlessも

DynamoDBも当初はマネージドとしてシンプルでしたが要求が増えるにつえ複雑になってきました。 ＊ソフトウェアでは良くあることで、そして新しくシンプルなものが生まれ新しいサイクルが始まる モデリングなどはドキュメントを見ていただきつつ、この記事では間違えやすい抑えていただきたいポイントを解説します on-demandモードを使う 初期設定はprovisionedモードになりがちですが固定料金を取られます。また、トラフィックが読めないとき、増減激しいときもあるでしょう on-demandモードが無難です(2024/11/1から半額になりなおさら) CDKの場合、dynamodb tableV2を使うと初期設定でon-demandです provisionedになっているテーブルを探すならAWS Configを使えばアカウント横断で検索できます provisionedは上級者向け。地味に難しい

カケハシ Advent Calendar 2024の24日目の記事になります。 今年は、開発組織のビジョンと技術戦略を策定しました。本記事では、カケハシの開発組織が歩んできた軌跡を振り返りながら、技術戦略を立案するに至った背景やプロセスを詳しく紹介します。 対象読者は特定の肩書に限定していません。CTOやVPoEといった役職に関わらず、開発組織の変革や成長に関心をお持ちのすべての方を対象としています。特に、現場で課題に直面し、それを解決することで組織全体を前進させたいと考えている方々にとって、本記事が参考になれば幸いです。 本記事では、以下のテーマに焦点を当てています： カケハシの開発組織が歩んできた軌跡 ビジョンの策定と課題の診断 技術戦略の基本方針と具体的な行動計画の立案 今回は、技術戦略やビジョンの具体的な内容そのものではなく、これらを策定するプロセスや背景に焦点を当てています。カケ

カケハシ Advent Calendar 2024の25日目の記事になります。 こんにちは、カケハシでCTOをやっているゆのん(@yunon_@phys)です。 様々なスタートアップやベンチャーでCTOの肩書を持った方が、入れ替わっているのを観測しています。かくいう私も、創業メンバーに近かった海老原さんからCTO のポジションを今年の3月より引き継いでいます。私自身はこれまでのキャリアでCTOになったことはなく、これまでに無いリーダーシップが求められています。まだ9ヶ月という短い期間ではあるのですが、この期間にどんなことを考えどんなことを実行していったのか、はもしかしたらそういったリーダーを引き継ぐ方の学びになるかもしれない、と考えました。そこで、CTOを引き継いだ後に私なりにどのようにリーダーシップを発揮してきたのかを本エントリで書いていきます。 CTOと名乗り、退路を断つ 開発組織のミ

こちらの記事は カケハシ Advent Calendar 2024 の 16日目の記事になります。 adventar.org こんにちは！エンジニアリングマネージャー（以下、EM）の小田中（@dora_e_m）です。11月より、新規プロダクト開発を主なミッションとするチーム"yabusame"に加え、Musubi AI在庫管理を開発するチーム"hakari"のEMを担当しています。 この記事では、hakariチームにジョインしてから取り組んだミーティング削減施策の狙い、実施までの進め方、効果、そしてこれからやっていきたいことについて紹介します。 hakariのチーム構成 まず、ミーティング削減の話に入る前に、hakariというチームについて簡単に紹介させてください。冒頭でお伝えしたとおり、このチームはMusubi AI在庫管理を開発するチームです。ローンチから数年が経過し、ありがたいことに

技術広報の941です。カケハシはPyCon JP 2024にスポンサーをし、ブースにて「カケハシ式、チャートでわかるふりかえりの技法」という冊子を作成し配布しました。普段はデータばかりを取り扱っているので、本というリアル媒体に関わることが少ないためなかなか苦労しました。 実際に配布した冊子 この記事では、イベントで配布するための冊子を印刷するためのデータ(組版といいます)を、Google Docsで作成する際に気をつけるべきポイントについて共有したいと思います。 この記事は秋の技術特集 2024の19記事目です。 組版とは Google Docsで作成するメリット Google Docsで作った組版データでハマりやすいポイント 入稿時に気をつけたいポイント 組版とは 文字や画像や表などの要素を配置して、読みやすく視覚的に効果的なデザインに仕上げる技術やプロセスのことを組版といいます。主に印

AI在庫管理の開発チームのバックエンドエンジニアのもっち(@mottyzzz)です。今回は、AI在庫管理の開発において、Gitのコミットログから開発属人性を可視化して品質向上を実施していく箇所の優先順位をつけた事例を紹介します。 この記事は秋の技術特集 2024の 16 記事目です。 背景 優先順位をつけて無理なくコツコツ取り組めるアプローチ Gitのコミットログに着目 Gitのコミットログで開発者の偏りを可視化してみました 結果の解釈と活用 Gitのコミットログを取得し可視化するまでの流れ 前提条件 Gitのコミットログの取得 コミットログのクレンジングと分析対象の決定 コミットログの集計 結果の可視化 結果の解釈における注意点 このあと実施したアクション まとめ 背景 AI在庫管理のプロダクトは、医薬品の在庫を効率的に管理するためのサービスです。 このシステムは3年前にリリースされ、そ

この記事は秋の技術特集 2024の 17 記事目です。 はじめに Musubi AI 在庫管理で DevOps エンジニアをしている kacky です。 Web アプリケーションの開発において、設定値の管理は避けて通れない課題です。データベース接続情報や 機能フラグなど、アプリケーションの挙動を左右する重要な情報を安全かつ効率的に扱う必要があります。 AWS では、設定値の保存に利用できるサービスがいくつか存在します。本稿では、特に S3, AppConfig, Parameter Store の 3 つに焦点を当て、それぞれのメリット・デメリットを比較し、最適な設計を選択するための決定法を紹介します。 なぜ設定値の保存先を検討する必要があるのか？ 設定値をアプリケーションのコード内に直接記述してしまうと、環境ごとに設定を変更する際にコードを修正する必要が生じ、運用ミスやセキュリティリスク

カケハシのプラットフォームチームのテックリードとして組織管理サービスと認証基盤を開発している kosui (id:kosui_me) です。今回は、目的別データベースをプラットフォームチームではどのように実践しているかご紹介します。 この記事は秋の技術特集 2024の 13 記事目です。 背景 目的 事例1: PostgreSQL の行レベルセキュリティを活用する組織管理サービス 組織管理サービスとは PostgreSQL の行レベルセキュリティ 行レベルセキュリティを用いたトランザクションマネージャー 行レベルセキュリティの運用上の注意点 事例2: DynamoDB を活用する認証基盤と Outbox パターンの活用 カケハシの認証基盤刷新 DynamoDB で実現する高稼働率の認証基盤 DynamoDB の特性を考慮する CDC と Outbox パターン まとめ 背景 医療の分野で様

はじめに こんにちは！ソフトウェアエンジニアの種岡です。 皆さん、システム設計に取り組んでいますか？ 設計は、プロジェクト成功への道筋を描く、航海の羅針盤です。 目的地を見据え、それに向かって進むための確かな指針となります。 設計の質がしっかりしていれば、開発という大海原でも迷わず進むことができます。 設計はプロジェクトの土台を築く、創造的かつ重要なプロセスです。 夢を描き、それを形にする試行錯誤の楽しさ、これこそが設計の魅力だと思います。 この記事は秋の技術特集 2024の11記事目です。 この記事 is 何？ この記事では、設計図を描く際の心構えと、誰でも見やすい設計図を作成するためのテクニックについてお話しします。 なぜ設計図を書くのか？ 図は複雑な情報を視覚的に整理し直感的な理解を推進することができるため チーム内外での共通理解を促進し、コミュニケーションを円滑にするため 予測可能

カケハシで Musubi Insight のバックエンドエンジニアをしている末松です。今回はプロダクトのモニタリングをどう進めていくべきかについて、4つの大事な段階とそのベストプラクティスを紹介したいと思います。 この記事は秋の技術特集 2024の 10 記事目です。 想定読者 モニタリングの悩みあるある モニタリングを始めるためには モニタリングにおいて大事な4つの段階 1. 【可視化】プロダクトの状況がさまざまな断面で可視化されている 【可視化】 のベストプラクティス 2. 【共有】プロダクトの状況が定期的にチームに共有・認識されている 【共有】 のベストプラクティス 3. 【検知】プロダクトが異常な状態であることにチームが気付くことができる 【検知】 のベストプラクティス 4. 【集中】チームが優先すべき指標が定まっている 【集中】 のベストプラクティス まとめ 想定読者 プロダクト

「KAKEHASHI Tech Blog 秋の技術特集2024」は、カケハシで利用されている技術についてより深く知ってもらうため、9月の平日にブログを毎日更新していく特別企画です。(全19記事) 9月2日: Databricksでnotebookのセルの中身を検証する - KAKEHASHI Tech Blog 9月3日: Okta ログを AWS S3 にログストリームで保存する - KAKEHASHI Tech Blog 9月4日: 新しいチームでTypeScriptに素早くキャッチアップするためにやったこと - KAKEHASHI Tech Blog 9月5日: Slackリストを用いてSlackで管理を完結しましょう！ - KAKEHASHI Tech Blog 9月6日: renovateとDependabotの連携による脆弱性管理 - KAKEHASHI Tech Blog 9

AI在庫管理の開発チームでバックエンドエンジニアをしている沖です。今回は、AI在庫管理の医薬品検索において、MySQLの全文検索機能を使った話を紹介しようと思います。 この記事は秋の技術特集 2024の 8 記事目です。 今までの医薬品検索では満足できないユーザーがいた なぜMySQLの全文検索機能を採用したのか 全文検索機能を導入する 全文検索インデックスを付与したテーブルを作成する パーサー 照合順序と正規化 全文検索インデックスを使用して検索する データを最適な状態に保つために おわりに 今までの医薬品検索では満足できないユーザーがいた AI在庫管理には、医薬品の在庫一覧画面など、医薬品名で絞り込む画面がたくさんあります。この絞り込み機能を実現するために、これまではSQLのLIKE検索を利用していました。 LIKE検索は、使い慣れたSQLを用いて部分一致検索を実現できる便利な方法です

この記事は秋の技術特集 2024の 7 記事目です。 カケハシのAI在庫管理チームでフロントエンドエンジニアをしているNokogiri です。今回はAI在庫の入庫ダイアログを zustand を使ってリアーキテクチャした事例を元に取り入れたプラクティスを紹介したいと思います。 イントロ AI在庫では、ユーザーの入力を伴うフロントエンド部分で多くのケースに React Hook Form を利用しています。 React Hook Form は、入力フォームの状態管理やバリデーションを簡単に実装でき、パフォーマンスにも優れた素晴らしいライブラリです。 しかし、ユーザーの操作に応じてインタラクティブに変化する UI では、状態管理が複雑化し、コードの可読性が低下することがあります。その結果、バグが発生し、予測しにくい動作を引き起こすことも少なくありません。 そこで今回は、 zustand を導入

カケハシでエンジニアリングマネージャーを担当しているいくおです。 今回は、私たちのチームで中規模以上（複数スプリントにまたがるもの）の機能開発を行うときに作成している「全体マップ」について紹介します。 全体マップを考案したのはチームメンバーの椎葉さんなのですが、「いくおさん言語化うまいからブログにしてください！」とおだてられたので、それを真に受けて私がブログに書きます。 全体マップを作るようになってから、中規模の開発で自分たちの状況を把握しやすくなりました。また、全体マップを通して関係者全員がコミュニケーションすることで、なめらかな協働関係を築けるようになりました。こういった実体験からも、ぜひ多くの現場で全体マップを試してみたいと思っています。 では、全体マップとは一体なんなのか、どうやって活用するとよいのか、解説します。 この記事は秋の技術特集 2024の6記事目です。 ユーザーストーリ

この記事は秋の技術特集 2024の5記事目です。 カケハシではライブラリの更新検知にrenovateを利用しています。renovateは実行スケジュールの設定やパッチのグルーピングができるなどの機能が便利ですが、脆弱性データベースを持っていないため、検知された更新が脆弱性対応か否かがわかりません。 最終的にはすべて対応するべきですが、対応の優先順位づけのためどれが脆弱性対応パッチなのかわかると便利です。 GitHubでrenovateを使っている場合、Dependabot Alertsと組み合わせることで、Dependabotの脆弱性情報を利用してrenovateでも脆弱性を検知できます。 Dependabotシリーズについて Dependabotを有効化すると、renovateとDependabotで二重にPRが作られるのでは？と心配されるかもしれませんが、その問題はありません。費用もか

この記事は秋の技術特集 2024の 4 記事目です。 はじめに AI 在庫管理のフロントエンドの開発を主に担当している鳥海です。 今回は先日 Slack からリリースされた Slack リストをチーム内の開発プロセスに組み込んだので、活用事例についてご紹介していこうと思います。 Slack リストとは 2024/6/6 に Slack リストの機能がプレスリリースされ、順次展開されている機能で、 プロジェクトの管理 リクエストの管理 タスク管理 などのアイテムの管理が必要な業務を Slack 内で完結できるようなサービスとなっています。 機能のイメージとしては、上記添付のようになっており、今記事では基本的な機能についてはこの記事では記載しないので、プレスリリースを参照していただけると嬉しいです。 AI 在庫管理フロントエンド横串連携での活用方法 AI 在庫管理では 6 つのレーンで開発を進

カケハシのプラットフォームチームでソフトウェアエンジニアをしているすてにゃん (id:stefafafan) です。今回は、私が TypeScript をメイン言語として採用しているチームに参加した際、言語や周辺技術のキャッチアップを行った方法について紹介します。 この記事は秋の技術特集 2024の 3 記事目です。 この記事の想定読者 私が元々持っていたスキルセット 認知負荷の増加 TypeScript 学習のためにやったこと 学習の進め方 テックリードとの 1on1 の中で壁打ちや相談 ペアプログラミング 輪読会 もくもく会 学習コンテンツ O'Reilly Online Learning を使った学習 TypeScript Deep Dive プロを目指す人のための TypeScript 入門 安全なコードの書き方から高度な型の使い方まで type-challenges 公式ドキュメ

カケハシのプラットフォームチームでソフトウェアエンジニアをしているすてにゃん (id:stefafafan) です。今回はチームに配属されて数ヶ月の私が、いかにして社内ドキュメンテーションの階層構造を整理し、情報の検索性を向上させたかについてお話します。 はじめに この記事の想定読者 課題意識 メンバーへの共有と相談 社外事例の調査 esa の階層整理 第 1・第 2 階層の整理 ストック情報とフロー情報を意識した階層の整理 esa の機能をフル活用する 効果や今後について はじめに カケハシでは全社的にドキュメンテーションツールとして esa - 自律的なチームのための情報共有サービス を利用しています。それぞれのチームやプロダクトごとに階層を切ってドキュメントを書いています。 プラットフォームチームでは認証基盤などの社内プラットフォームシステムを開発しているため、自チームが運用する各種

ここ最近のトレンドとして、Vercel, Cloudflareとサーバレスにおけるコールドスタート高速化周りでしのぎを削っており Lambdaも様々な取り組みがなされています。それでもLambdaはシェアが大きいこともあり、コールドスタートが話題になることは多いです。この記事では、あまり語られないファイルサイズの観点からコールドスタート高速化にアプローチします。 zipアーカイブに着目するモチベーション Cold Start時はS3からコード一式をダウンロードするため、サイズが小さいほうがCold Startが短くなります。 また、解凍後のファイルサイズが250MBまでという制限もあります。こちらは上限緩和不可能です。なお直接アップロードする場合はzipのサイズは50MBまでで、これ以上だとS3バケットを準備してそちらにアップロードする必要があります。 とにかく不要なものを削ればCI/CD

カケハシでエンジニアリングマネージャーを担当している小田中です。 AWSの皆様にご協力いただき、社内でAmazon Working Backwardsを開催しました。こちらの体験がとても、と〜ってもよかったのでみなさんにご紹介したく、イベントレポートを書くことにしました。 Amazon Working Backwardsって？ AWSで新しいサービスや取り組みを実施する際に必ず実施されるプロセスが「Working Backwards」です。 「お客様は誰ですか？」から始まる5つの質問を通じて、企業が作りたいものではなく、顧客の目線から顧客体験を徹底的に考えていくことで、自分たちがつくるべきもの、解決するべき顧客の課題を明確にしていくワークショップです。書籍にもなっているので、ご存知の方も多いかもしれません。 アマゾンの最強の働き方ーーWorking Backwards 私自身は、AWS C

すべてのソースコードを読む時間があればよいのですが。 GitHubを横断して確認すると、ソースコードレベルで気になる箇所はよく見つかります。このとき他のコードベースでも起きてないか確認したいところです。ソースコードレベルの細かいレビューをコツコツしていくことは可能ですが、どうしても量が多くなってしまうのとスケールしづらいです。調査のためにも再現性担保のためにもGitHubで検索できると便利でしょう。 この記事ではカケハシ内で実際に見かけた箇所について、サンプルのGitHub検索クエリを共有します。 カケハシではTypeScriptとPythonを活用していることから、この2言語に絞って記載します。 サンプルはおおよそ検索できていることを目指しています 和暦処理の再実装 TypeScript(JavaScript)では標準ライブラリを使いましょう date.toLocaleDateStrin

前回は、アーキテクチャの進化はドメインイベントが起点になるという記事内で、ドメインイベントの重要性を語りました。本稿では、ドメインイベントを伝達する際にシステム要件を満たした上で、どのようにしてデータモデル並びにドメインモデルを象るかを説明します。 なお、ビジネスドメインを深掘りドメインモデルを探索する手法の説明は、世にたくさん解説されているため詳しくはそちらに譲ります。特にAlberto Brandolini氏が提唱するモデリング手法であるEvent Stormingは、ワークショップ形式でドメインイベントを深く理解し、一連の業務プロセスやドメイン領域を探索的に発見することができる手法であり、Event Sourcingを前提とするアーキテクチャと相性がいいので参考にするとよいでしょう。 ドメインイベントのデータモデルの属性 ドメインイベントの記録および伝達に着眼した構成を紹介した前回の

はじめに こんにちは、株式会社カケハシでエンジニアリングマネージャーをやっている小田中（ @dora_e_m ）です。 今回は、タイトルの通り「日報を書くといいよ！」、とくに「組織のニューカマーにはオススメだよ！」という話を書きます。 日報って何? まず、日報とは何でしょうか。一般には、日々の業務内容や進捗などを報告する文書を指します。 この定義に従えば、受益者は報告される立場の上長であり、日報を作成する当の本人にはあまりメリットがありません。 私自身、ただ進捗を共有するだけの日報にはあまり意味を感じません。たとえばJiraなりTrelloなりで進捗管理している現場であれば、そのうえで進捗報告のための日報を作成することは作業の重複、情報の二重管理の発生を意味します。 ですが、日報を以下の目的で作成するようにすると、それは作成者本人にとって役立つものにできます。 毎日のふりかえり 思考プロセ

こんにちは。ソフトウェアエンジニアの椎葉（@bufferings）です。最近実施したオリジナルのふりかえりがよかったので紹介します。 いつもはエンジニアリングマネージャの小田中さん（@dora_e_m）が、そのときのチームの状況に合わせたふりかえりの手法を用意してくれていて、毎週違うふりかえりをみんなで楽しんでいるのですが、今回は小田中さんが不在だったので私がファシリテーションをしてみることにしました。 どんなふりかえりをしようかなと ふりかえりカタログ を眺めていたところ Six Thinking Hats が目に止まり「これをアレンジして『帽子の交換』をすると、今のチームにちょうどいいかもしれないな」と感じて、今回のふりかえり手法を思いつきました。 カケハシはリモートファーストの会社で、私の所属するチームもフルリモートで開発に取り組んでいます。そのため、今回のふりかえりもオンラインホワ