私の目標は、読者が午前中に本書を読み始めたら、午後には設計が上達していることだ。 本当にそのとおりだった。読んでる途中で既に自分の設計に対する考えが良い方向に変わってると感じた。とても良かった。おすすめです。 『Tidy First?』 をいただいて読んだ。昨日（2024年12月25日）発売。英語版が2023年11月28日発売だから、たった1年で日本語版が出たということだな。うれしい！はやい！ありがたい！ ソフトウェア設計に焦点を当てたシリーズの最初の1冊ということで、サブタイトルに「個人で実践する経験主義的ソフトウェア設計」とあるように、1人でできる種類のソフトウェア設計について書かれている。続刊ではチームについての話になる予定のようで、それも今から楽しみ。 2周読んだ なんとなく2周読もうと思ってそうした。 1周目は細かい部分は気にせずにざーっと1,2時間くらいで読んだ。全体的にどうい

typescript-eslintのFlat Configについて、自分に今必要そうな部分だけをひととおり確認したので忘れる前にメモを残しておく。 前提 素のJavaScriptプロジェクトをやることは自分はあまりなさそうなのでTypeScript前提 ES Modules前提でいいやと思っているので設定ファイルの拡張子はシンプルに .js にする フォーマッターにはESLintのStylisticじゃなくてESLint外のフォーマッター（PrettierやBiome）を使う前提 基本の設定 https://typescript-eslint.io/getting-started/ の最初に書いてある設定。 // @ts-check import eslint from '@eslint/js'; import tseslint from 'typescript-eslint'; expo

AI在庫管理の開発チームでバックエンドエンジニアをしている沖（@takuoki）です。AI在庫管理では、サーバーサイドの大部分で Python を使用しているため、私も毎日 Python をごりごり書いています。ただ、私が Python をちゃんと触り始めたのは、カケハシに入社した 1 年半前で、それまでは主に Go を書いていました。 Go の方が後発の言語のため、Pythonista が Gopher になったという記事の方が簡単に見つかるのですが、ここでは逆に「Gopher のための Python 入門」みたいなものに挑戦してみようかなと思っています。入門といいつつも、今回は、私が実際に業務で使用したものにフォーカスしているため、ちょっと偏りがあります。また、私自身が Go の前は Java などのオブジェクト指向言語の経験があるため、その辺りもあまり詳細には触れていない点もご容赦く

2023 年度の僕のエラーハンドリング について書きたい。 昨日Safe Data Fetching in Modern JavaScriptを読んでいて、fetch に限った話ではないが一家言ある内容だったので書きたくなった。 おそらくやりすぎだとか非効率と言われる点はあると思うので、みんなの一家言も教えて欲しい。 対象は Typescript での サーバー開発想定だが、TS であればクライアント開発にもほとんどに当てはまる話だと思う。 例外のスローではなく Result 型を使う Result は失敗するかもしれないという文脈を与えてくれる型 エラーハンドリングの戦略として例外を投げるのではなく、Result 型を返すやり方がある。 Result 型というのは export type Result<T, E> = Ok<T> | Err<E>; export interface Ok

数日前にTypeScript 5.7 RCがアナウンスされてリリースが楽しみだなー！ってところなんだけど、そのさらに数日前に、ウォッチしていたこのPR↓がマージされてTypeScript 5.8.0のマイルストーンに入った。わー！ これが今日のお話。TypeScript 5.8.0でConditional return type narrowingが入りそう。楽しみ！ Conditional return type narrowing? 直訳すると「条件付き戻り値型の絞り込み」かな。引数の型によって戻り値の型が変わる関数を定義したいときに、例えばこんな風に書きたくなる。 declare const record: Record<string, string[]>; declare const array: string[]; function getObject<T extends str

（まだ書いてる途中）僕がシニアエンジニアとしてどのようにアジャイル開発を実践しているかの現在地を紹介します。アジャイルな開発に取り組んでいるみなさんにとって何かしら、ヒントや刺激になるようなものがあると嬉しいです。

株式会社カケハシは「日本の医療体験を、しなやかに。」というミッションを掲げた、医療系のスタートアップです。現在は薬局向けのSaaSを主軸としたビジネスを行っており、多くのエンジニアがチームを組んで開発に取り組んでいます。その開発チームのひとつ「yabusame」は、特徴的なチーム編成もあって社内外で注目を集めています。 メンバーの椎葉光行（@bufferings）さん、小田中育生（@dora_e_m）さん、荻野淳也（@ogijun）さん、種岡篤志さん、平松拓（@hirataq__）さんは、それぞれが開発チームをリードできる高い技術力やマネジメント能力だけでなく、細やかな対人スキルや広い視座でメンバーの関係性を捉える能力を備えたシニアエンジニアでありながら、同じチームのメンバーとして開発に取り組んでいます。 日本の古式弓馬術である流鏑馬(やぶさめ)から「変化が速い中を駆け抜けて、的確にゴール

「イマジナリー○○さん」がチームを強くする。メンバーの技術力をブーストする「自己開示」の力 2024年9月26日 株式会社カケハシ　エンジニアリングマネージャー 小田中育生 大学院修了後、外資系半導体企業に就職。テストエンジニアとして経験を積んだ後、乗換案内・地図・ナビゲーションサービスを提供する会社に転職。研究開発部門のエンジニアを軸足にUX改善やアジャイル導入推進、プロジェクトマネージャーやエンジニアリングマネージャーを経験し、2019年にVP of Engineeringに就任。2023年10月、カケハシにジョイン。新規プロダクト開発チームのEMとして働く。著書に『アジャイルチームによる目標づくりガイドブック』（翔泳社）、『いちばんやさしいアジャイル開発の教本』（共著・インプレス） X note 株式会社カケハシ　ソフトウェアエンジニア 椎葉光行 大学時代のアルバイトをきっかけにエン

2024-11-11 追記ここから ---- TS 5.8で、その１のインデックスアクセス型の方はサポートされそう。その２の方はその対応が入ってもサポートされない。 追記ここまで ---- 最初にまとめ 現在のTypeScript（2024-09-19時点のバージョン5.6.2）では Generics と Control Flow Analysis は、いい感じには連携しないということを学んだ。 どういうこと？その１ Genericsを使って型安全にやりたいなぁと思って、こんなコードを書いてみてもコンパイルエラーになる。 type Mapping = { a: boolean, b: string, } function getValue<K extends "a" | "b">(key: K): Mapping[K] { if (key === "a") { return true; }

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

何を言っているんだ？というタイトルだけど、今日はTypeScriptの型で遊んでた。 タグ付きユニオンから型をExtractしたい こういうタグ付きユニオンがあって type MyUnion = | { tag: "a", value: boolean } | { tag: "b", value: boolean } | { tag: "c", value: string } その中の型をExtractしたいときは、こんな風に書ける type A = Extract<MyUnion, { tag: "a" }> そうするとtagが"a"の型を取得できるので、このテストがとおる import type { Equal, Expect } from '@type-challenges/utils' type cases = [ Expect<Equal<A, { tag: "a", value

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

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記事目です。 ユーザーストーリ

「目標」を使って人やチームを元気にしよう────『アジャイルチームによる目標づくりガイドブック』の著者に聞く。 仕事の「目標」は、どこへ向かって走れば良いかを示す地図のようなもの。 しかし、あまり良くない「目標」が設定されてしまうと、「この仕事に意味はあるの？」という疑念が生まれたり、仕事のコミュニケーションに齟齬が生まれてしまう場合もあるように感じます。 そこで今回は、『アジャイルチームによる目標づくりガイドブック』の著者である、株式会社カケハシのいくお (小田中 育生)さんに「人やチームを元気にする目標設定」についてお話をお聞きしました。 『アジャイルチームによる目標づくりガイドブック』著者、株式会社カケハシ エンジニアリングマネージャー。 2009年に株式会社ナビタイムジャパン入社。研究開発部門に配属。プロダクトや開発プロセスのカイゼンを推し進め、アジャイルとの出会いから社内でスクラ

開発部全体を見てるあのすごい人が、ある1つのチームのマネージャだったらどんな感じなんだろうなぁ？仕事がやりやすいんだろうなぁ？って考えることがある。それが今、僕のいるチームで起こっている。 VPoEの経験もあるいくおさんと、カケハシの同じチームで仕事をしている。いくおさんが1つのチームのエンジニアリングマネージャとしてついてくれているのって、とても贅沢だなぁと思っている。実際に仕事はめちゃくちゃやりやすいし、それだけじゃなくて、僕やチームみんなの心の支えになってくれている。 いくおさんが書籍を出した そんないくおさんが書籍を出した。この本がとてもいい本なので、みんなに読んでほしい。どうしていくおさんと一緒だと仕事がやりやすいのか、なぜ自分の持ってる力が引き出されるのか、その理由がこの本には書かれている。 www.shoeisha.co.jp いやー目標って苦手なんだけど・・・ 目標って聞く

Developers Summit 2024 Summer での登壇資料です https://event.shoeisha.jp/devsumi/20240723/session/5111

こんにちは、エンジニアの椎葉です。私は2024年7月10日と11日に台北で開催された DevOpsDays Taipei 2024 に参加し、『Our Scrum without Estimates, and into the Trunk-based Development（見積もりをしないスクラム、そしてトランクベース開発へ）』というタイトルで登壇してきました！この記事では、DevOpsDays Taipei 2024の登壇レポートをお届けします。 ↓スピーカー用のネームカード。Mitsuyukiだと呼びにくいのでMitzにしてます！ イベントの紹介と登壇のきっかけ devopsdays は、世界中で開催されるDevOpsコミュニティのカンファレンスです。最新の技術やベストプラクティス、現場での実践例などが共有される場になっています。 台北で行われるDevOpsDays Taipeiは、

成果を生み出す目標設定にチームで向き合う！ チームでの開発において、メンバーのモチベーションを高め、同じ方向を向いて進むためにも、目標づくりは重要です。 しかし、開発に合わせて状況は常に変化するため、当初の目標を見失ったり、遠ざかってしまうことは少なくありません。 本書は、チームで成果を生み出ための目標設定と向き合い、実践し続けてきた著者が、 ●目標を設定する ●目標と向き合う ●目標を達成した後 それぞれの過程で、やるべきこと、考えるべきことを架空の開発現場を舞台にしたマンガとともに、わかりやすく解説しています。 こんな課題を感じている方におすすめです。 ●組織目標とチーム目標の兼ね合いがうまくいかない ●チームのモチベーションの上げ方がわからない ●心理的安全性を守れているかわからない この本ではこういった悩みの解決できるプラクティスも多数紹介しています。開発の中でチームが変化していく