サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
災害への備え
kakehashi-dev.hatenablog.com
カケハシのプラットフォームチームでソフトウェアエンジニアをしているすてにゃん (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
前回は、アーキテクチャの進化はドメインイベントが起点になるという記事内で、ドメインイベントの重要性を語りました。本稿では、ドメインイベントを伝達する際にシステム要件を満たした上で、どのようにしてデータモデル並びにドメインモデルを象るかを説明します。 なお、ビジネスドメインを深掘りドメインモデルを探索する手法の説明は、世にたくさん解説されているため詳しくはそちらに譲ります。特にAlberto Brandolini氏が提唱するモデリング手法であるEvent Stormingは、ワークショップ形式でドメインイベントを深く理解し、一連の業務プロセスやドメイン領域を探索的に発見することができる手法であり、Event Sourcingを前提とするアーキテクチャと相性がいいので参考にするとよいでしょう。 ドメインイベントのデータモデルの属性 ドメインイベントの記録および伝達に着眼した構成を紹介した前回の
はじめに こんにちは、株式会社カケハシでエンジニアリングマネージャーをやっている小田中( @dora_e_m )です。 今回は、タイトルの通り「日報を書くといいよ!」、とくに「組織のニューカマーにはオススメだよ!」という話を書きます。 日報って何? まず、日報とは何でしょうか。一般には、日々の業務内容や進捗などを報告する文書を指します。 この定義に従えば、受益者は報告される立場の上長であり、日報を作成する当の本人にはあまりメリットがありません。 私自身、ただ進捗を共有するだけの日報にはあまり意味を感じません。たとえばJiraなりTrelloなりで進捗管理している現場であれば、そのうえで進捗報告のための日報を作成することは作業の重複、情報の二重管理の発生を意味します。 ですが、日報を以下の目的で作成するようにすると、それは作成者本人にとって役立つものにできます。 毎日のふりかえり 思考プロセ
こんにちは。ソフトウェアエンジニアの椎葉(@bufferings)です。最近実施したオリジナルのふりかえりがよかったので紹介します。 いつもはエンジニアリングマネージャの小田中さん(@dora_e_m)が、そのときのチームの状況に合わせたふりかえりの手法を用意してくれていて、毎週違うふりかえりをみんなで楽しんでいるのですが、今回は小田中さんが不在だったので私がファシリテーションをしてみることにしました。 どんなふりかえりをしようかなと ふりかえりカタログ を眺めていたところ Six Thinking Hats が目に止まり「これをアレンジして『帽子の交換』をすると、今のチームにちょうどいいかもしれないな」と感じて、今回のふりかえり手法を思いつきました。 カケハシはリモートファーストの会社で、私の所属するチームもフルリモートで開発に取り組んでいます。そのため、今回のふりかえりもオンラインホワ
こんにちは。 カケハシの Musubi AI在庫管理 チームにて業務委託のエンジニアをさせていただいております takanakahiko と申します。 今回はuvをGitHub Actionsに導入したらとても効果があったので、紹介することができればと思います。 uvとは uvとはPythonのパッケージインストーラー・リゾルバーです。 その最大の特徴はRust言語で開発されており、従来のツールの100倍の速度で動作する点です。 pipやpip-toolsのdrop-in replacementが可能であることも特徴です。 開発をするのはAstralです。 AstralはRuffの開発で有名ですね。 Ruffについては、こちらの記事で紹介しています。 試しに手元で利用する 今回の目的はGitHub Actionsへの導入です。 その前に手元でひととおり使ってみます。 まずは、比較のために通
はじめに 私はカケハシでエンジニアリングマネージャーをしている伊豆本です。約5年スクラムマスターを経験しています。 カケハシにはスクラムマスターが複数いるので、この記事で記載するのはあくまで私の持論です。 スクラムマスターでよくある課題感 自身がスクラムマスターをしている中で見聞きしたり経験した課題感には以下のようなケースがありました。 スクラムイベントに遅れて参加する 参加者が集まらずスクラムイベントを開始して良いかわからない スクラムイベントに無断で欠席 スクラムイベントがあると休みづらい スクラムイベントが予定していたタイムボックスに終わらない プロダクトバックログの完了の定義がない 外部要因でスクラムバックログが進捗しない プロダクトオーナーが差し込みタスクを追加する頻度が多い スクラムはミーティング多いとメンバーから声が上がる 開発系のバックログは大体できたのでステータスをレビュ
この記事はカケハシPart1 Advent Calendar 2023の12/25分の記事になります。 カケハシPart2 Advent Calendar 2023もありますので、ご興味あれば読んで頂けたら幸いです。 はじめに こんにちは。カケハシCTOの海老原です。カケハシでは2022年から明確にエンジニアリングマネージャー制を敷きそれを前提に組織を構成していますが、そこに至るまで様々な紆余曲折を経たり、また設定後も隣接職種間でのいわゆるRole & Responsibilityに関する議論が多く行われてきました。今回は、この点について既存のフレームワークを援用しつつ私の考え方をまとめてみたいと思います。 長すぎるので先にまとめ 事業フェーズに応じて開発ディレクター概念の発生からエンジニアリングマネージャー設置までのシームレスな流れがあった 両者は本来明確に分かれるというよりはグラデーシ
本エントリはカケハシ Advent Calendar 2023 Part 2の 25 日目の記事です。ぜひ Part1 と合わせて見て頂けたらと思います。 本日はMusubi AI在庫管理プロダクト開発チームでエンジニアリングマネージャーをしている僕が、開発ディレクターとして入社した当時に進めた組織変更への取り組みについて、現状の組織の状態も踏まえて振り返ってみようと思います。 組織変更の方針 入社した当時、Musubi AI在庫管理はフロントエンドチームとバックエンドチームに分かれて活動していました。 同じプロダクトを開発しているにもかかわらず、それぞれのチームは別々に活動している状態で同じ開発テーマも異なる時期に開発していることもありました。 それをフロントエンド、バックエンド混合のフィーチャーチーム化するというのが組織変更の方針でした。 組織変更の背景 実は組織変更の方向性は僕が入社
こちらの記事はカケハシ Advent Calendar 2023 Part2の24日目の記事になります。 adventar.org はじめに 反復的な開発は、変更容易性の高いソフトウェアが不可欠です。ソフトウェア開発の経験がある方なら、デリバリ後の洞察や市場環境の変化から、新しい機能の追加やアーキテクチャの進化の必要性に直面したことが一度はあるでしょう。 私自身、要求分析手法やSOLID原則等の技法を取り入れ、変更容易性に対応する多くのプロジェクトに参加しました。しかし、どれだけ優れた手法や技法を持っていても、変更が難しい要求が出てくることは避けられません。その際、「過去の出来事」を正確に記録していれば、後から見返して問題解決が容易だったと感じることがよくあります。 ドメイン駆動設計(DDD)では、「過去に起こった出来事」を表現するドメインモデルを「ドメインイベント」と呼びます。変更容易性
フロントエンド(React.js TypeScript) バックエンド(Node.js TypeScript) インフラ(CDK TypeScript) の Monorepo の linter を ESLint からbiomeに変更したら lint が約50秒かかっていたのが大体2秒になって嬉しかったので共有します。 こんにちは、カケハシでソフトウェアエンジニアをしている加藤です。 本エントリはカケハシ Part 2 Advent Calendar 2023の 21 日目の記事です。 ぜひ Part1 も 2 も見て頂けたらと思います。 同じカケハシ社内の他のチームでは以前 コードフォーマッターを Prettier から dprint にしたら 10 倍以上速くなった話 🚀 で紹介した通り、dprintを導入していますが、今回僕たちのチームは biome を導入してみました。 導入してみ
この記事は カケハシ Advent Calendar 2023 の19日目の投稿になります。 adventar.org 東 浩稔(あずま ひろとし)と申します。 私は、カケハシでデータプロダクトのPdM(プロダクトマネージャー)を務めております。 2023年の7月に入社し、全社のデータ利活用を促進するため、データプロダクトの整備・強化に取り組んでいます。 今回は、9月にDatabricks AI World Tour Tokyo 2023で発表した「データガバナンスの視点から見たデータメッシュアーキテクチャ」を元に 当社のデータメッシュアーキテクチャの詳しく掘り下げて解説いたします。 本書を読むことで得られること データメッシュアーキテクチャを段階的に検討するための手法やヒントが得られます。 当社はなぜデータメッシュアーキテクチャか? 当社では、患者様や薬剤師様の医療体験を向上させるため、
こちらの記事は カケハシ Advent Calendar 2023 の 16日目の記事になります。 概要 こんにちは。AI在庫管理の開発チームでSWEをしている小室です。 私は普段ドメイン駆動設計(以下、DDD)を意識しながら開発することが多く、実践を重ねるほどDDDの素晴らしさを実感しております。 最近異動してきたAI在庫管理の開発チームでは、現状はあまりDDDを意識して開発を進めていないのですが、プロダクトが対象としている世界が非常に複雑であることと、今まさに多くの法人様に利用していただけるようになったうれしい悲鳴として成長痛を感じ始めており、ドメイン駆動設計を何かのヒントとしてプロダクトによる価値提供速度を加速できればと考えています。 しかしながら、ドメイン駆動設計は独自の価値観や学習コストの高さから、まだ取り組んだことのないメンバーとしては大きな不安を感じる部分があると思います。
はじめに こんにちは。カケハシでPatient Engagementという新規事業に関わるプロダクトマネジャー(以降PdM)を担当している渡部と申します。現在はこれらの事業を加速させるために、いわゆる0→1フェイズ、かつ、SoE(System of Engagement)の側面が強いプロダクト・サービスの企画開発をしております。 カケハシではスクラムでのアジャイル開発が共通して採用されていますが、前述のプロダクト特性上、お客様ごとに置かれている状況も考え方も異なる状況下であるべきを模索し続ける必要があります。いわゆるVUCAそのものなサービス開発に日々取り組んでいます。 そんな不確実性が高い状況下で仮説検証サイクルを最速にできるよう、我々のチームのスプリントのタイムボックスは1週間、スクラムチームの成果物の一つであるインクリメントを生み出していくという活動をしています。このとき、日々プロダ
こんにちは!ソフトウェアエンジニアの種岡です。 こちらの記事は カケハシ Advent Calendar 2023 Part2 の14日目の記事になります。 Part1もあるのでぜひご覧ください! はじめに カケハシではコミュニケーションツールとしてSlackを導入しています。 開発チームの多くはフルリモートで働いていることもあり、仕事の中心にSlackがあるのが当たり前の日常になっています。 そんな職場としての役割も果たしているSlackに、お手軽に独自ワークフローを作成する仕組みが備わっているのをご存知でしょうか? この記事ではSlack次世代プラットフォームを使った業務効率化事例を紹介しようと思います。 事例その1:メンバー指名ルーレット🎯 誰がやっても大差ない作業ってありませんか? 「誰かやりたい人いますか?」と提案しても手が上がりにくいといった状況に覚えはありませんか? そんな
本エントリはカケハシ Part 2 Advent Calendar 2023の13日目の記事です。 (Part 1もおもしろい記事がいっぱいあるので、ぜひご覧ください。) はじめに こんにちは。カケハシでソフトウェアエンジニアをしている平松です。 今年、新規プロダクト立ち上げの機会があり、その際に行ったフロントエンドの技術選定について紹介したいと思います。 フロントエンドの領域は選択肢が豊富で、変化のスピードも速いため、プロダクトの要件に適した技術を選ぶことはひとつの挑戦です。 実際、フロントエンド技術選定のヒント 【令和五年度版】のアドベントカレンダー記事を読んで、その難しさを改めて感じました。 今回の新規プロダクトは、ユーザがログインして利用するtoBの業務システムです。 私はカケハシでは2度目の新規プロダクト立ち上げですが、前回の経験を活かしつつ、新しいアプローチにも挑戦しています。
はじめに はじめまして。 Musubi 開発チームで SRE を担当している、家事育児 🧹🍳👧 の負担率がイレブンナインの大山です。 この記事はカケハシ アドベントカレンダー🗓 part2の 12 日目の記事です。 そして入社してそろそろ 2年になりますが初投稿です。 この記事 is 何 ゆるふわスクラムをしていた私(38歳)がはじめてガチのスクラムにチャレンジし、継続的に課題を解決しながらスプリントを走った備忘録です。 また課題に対するカウンターや、スプリントを 4回ほどこなしたイマココの所感をまとめています。 記事のタイトルにあえて年齢を入れたのは下記の対象読者に向けた意図がありました。 対象となる読者 しっかりめにスクラムをすることに興味がある方 年齢を理由に何かをはじめることにためらいがある方 スクラム未経験🐤 〜 ゆるふわスクラム時代 早速ですがスクラムの話です。 まず
はじめに こんにちは!エンジニアリングマネージャーの小田中(@dora_e_m)です。 この記事はカケハシ Advent Calendar 2023 の 12日目の記事になります。 https://adventar.org/calendars/8587 今年はPart2もあるのでぜひそちらもご覧ください! https://adventar.org/calendars/8728 この記事ではタイトルのとおり、新規事業のプロダクト開発チームにおいて新任のエンジニアリングマネージャー(以下、EM)がどのような役割を担うのか、私自身の実体験をもとに紐解いていきます。 前提: カケハシに存在するEM、開発ディレクターというロール カケハシにはEMに加え、開発ディレクターというロールがあります。カケハシでは基本的にどのチームでもスクラムを採用しており、開発ディレクターはスクラムマスターとイコールで考え
本エントリはカケハシ Advent Calendar 2023 の 11日目の記事です。 今年はPart2もあるのでぜひそちらもご覧ください! カケハシのVP of Engineeringの湯前(@yunon_phys)です。皆さん、目標設定と評価は順調ですか?私はこれまで何年にも渡って、様々なメンバーの目標設定や評価をしてきました。残念ながら、こうすれば良い目標設定や評価が出来る!という銀の弾丸は無さそうです。でも、こう考えたら目標設定はやりやすいかも、こうすると評価はより納得感のあるものになるかも、というのはあります。 そこで今回は制度を施行・運用していく立場の人間として、目標管理と評価制度の考え方について、私の意見を述べていきます。 目標管理 目標はそもそも変わるものである みなさんこんなことありませんか? やる気満々であんなことやこんなことを色々考えて、壮大な目標を期初にがんばって
こんにちは。カケハシでソフトウェアエンジニアをしている椎葉(@bufferings)です。私の所属するチームでは先日「質とスピード」についてのふりかえりを実施しました。この記事では、チームが「質とスピード」をふりかえってどのようなことを話し合い、何を決めたのかご紹介します。 この記事は カケハシ Part 1 Advent Calendar 2023 10日目の記事です。今年のカケハシのアドベントカレンダーにはPart 1とPart 2があるので、両方とも楽しんでいただけると嬉しいです。 カケハシ Part 1 Advent Calendar 2023 カケハシ Part 2 Advent Calendar 2023 「質とスピード」の社内講演会 カケハシでは、9月に和田卓人さん(@t_wada)をお招きして「質とスピード」の社内講演会を開催しました。 講演中には社内のSlackで「わかる
こちらの記事は カケハシ AdventCalendar 2023 の5日目の記事です。 はじめに こんにちは。カケハシのAI在庫管理チームに所属している梅田です。 私は2年程前に、カケハシのCS(カスタマーサクセス)チームに加わりました。 カスタマーサクセスとは、プロダクトを利用していただいているお客様に伴走し、お客様の業務がより良くなるようにサポートする役割を担う仕事です。 そしてタイトルの通り、今年の10月から新たな役割としてフロントエンジニアとしてのキャリアをスタートさせました。 このブログでは、これまで開発やプログラミングの経験がまったくなかった私が、CSの仕事からエンジニアへと進むことに決めた経緯や、どのように実現していったかを書きたいと思います。 この挑戦は、カケハシのメンバーの多大なサポートと励まし無しには実現できなかったと思っています。私の体験が、新しい挑戦を考えている皆さ
こちらの記事は カケハシ Advent Calendar 2023 の 4日目の記事になります。 こんにちは。カケハシでエンジニアをしている今川です。 今回はこれからフロントエンドの技術選定をする方向けに、どんな技術・ツールを使えばいいかのヒントになるような記事を書いていきたいと思います。 ただし、本記事では個人的な好みというよりは、npm trendsやGitHub Star Historyなど客観的な指標からどんな技術が世間に受け入れられているかの比較にしていきたいです。 もちろん数値などの比較以外に、ドキュメントを読んだり使ってみたりすることも重要だということは言うまでもないと思います。あくまでも今回の記事が知らないライブラリを知る機会だったり、ヒントになれば幸いです。 もくじ パッケージマネージャ ランタイム フロントエンドフレームワーク レンダリングフレームワーク ビルドツール
こんにちは。 AI在庫管理というプロダクトでフロントエンドの開発を担当している大村です。 AI在庫管理開発チームでは、顧客に素早く価値を提供するためにフロー効率を重視した開発を行っています。 本記事では、なぜフロー効率を高めようとしているのかと、どのような取り組みによってフロー効率を高めているかについて紹介します。 リソース効率とフロー効率 生産性の効率の考え方として「リソース効率」と「フロー効率」があります。 複数人の開発者がチームでソフトウェアを開発するシーンを想定し、リソース効率とフロー効率それぞれを重視した場合の仕事の流れを単純なモデルとして表現してみました。(ここでは仕事の1つ1つをタスクと呼ぶことにします) これだけ見ると、リソース効率重視の方がムダなくタスクを消化しているように思います。 しかし、ソフトウェア開発の現場では以下のような状況が頻繁に発生します。 他の開発者のレビ
Musubi AI在庫管理の機械学習エンジニアをやっている中野です。 こちらの記事は カケハシ Advent Calendar 2023 の1日目の記事になります。 昨年はprophetについて書きましたが今年は勾配ブースティングにしました。 医薬品や食料品、アパレルなどの需要予測において平均値ではなく95%点や99%点を要求されるケースがままあります。 例えばコンビニおにぎりの在庫管理において需要予測の平均値だけ発注していれば2回に1回程度は欠品してしまうでしょう。こういった場合に予測の95%点を発注すれば欠品をおよそ20回に1回へと低減できます。 GBDTでもこのような確率点を返す予測が可能なのですが解釈や使い方には注意が必要そうです。 分位点回帰とは MAEを最小化するモデルが中央値を予測しているのはよく知られていますが分位点回帰はこれを一般化したものです。 分位点回帰では以下のよう
はじめに こんにちは!ソフトウェアエンジニアの種岡です。 私たちのチームでは、TypeScriptを使用して開発を行っており、Prettierというコードフォーマッターを利用し、チーム内でコーディングスタイル統一に大変重宝しています。 そんなフォーマッター界隈で、Rust製で爆速で動作すると噂のdprintが良いということで試してみたところ、驚くべきことが起きました! Prettierでは、コードフォーマッティングに 7.69秒 かかっていたのですが dprintを使うことでわずか 0.47秒 で完了するようになりました🚀🚀🚀 なんと、 10倍以上速い とういう結果に! コードフォーマットは、Gitのpre-commitフックやGitHub Actionsで日々活用しており、普段の開発作業の裏側でコードの品質を支えてくれているありがたい存在です。 この速度改善により、開発プロセスの中
こんにちは、カケハシで Musubi 開発チームのバックエンドエンジニアをしている関です。 Musubi 開発では、 Python の Linter と Formatter に Flake8、isort、Black を使用しておりました。しかし Rust で書かれた Ruff という高性能なツールが出たということで、置き換えてみたら爆速になった(25倍以上速くなった)ので、Ruff について記事を書かせていただきます。 今回は Ruff を導入した経緯や実運用に至るまでの工程を紹介したいと思いますので、最後まで読んでいただけると嬉しいです。 Ruffとは Ruff は、2022年8月にリリースされた Rust 言語で書かれた Python の Linter 兼 Formatter です。数多くのフレームワークやライブラリで採用1されています。 Python での開発には複数のツールチェーン
はじめに カケハシで BI ツールを開発している横田です。 AWS のリソース、いつの間にか増えていませんか? 今回は、ChatGPT を使って AWS のリソースを簡単に可視化することができたので、紹介したいと思います。 今回の課題と工夫したこと 我々のチームでは、半期に一回大掃除会を開催しています。 今回は、我々が管理している AWS Glue の job のうち使っていないものを削除することにしました。 使っていないリソースを調べるには AWS のコンソールを開いて一つ一つ確認する必要がありますが、これは非常に手間がかかります。 そこで、ChatGPT に Python スクリプトを書かせて、使っていないリソースを調べることにしました。 ChatGPT とのやりとり紹介 まずは、雑に ChatGPT に聞いてみます。 Q pythonでboto3を使って、直近1ヶ月実行されていない、
カケハシでVP of Engineeringをやっています、ゆのん(id:yunon_phys)です。僕はEngineering Manager(EM)とは何かについて、かれこれ5年ぐらいEM.FMというPodcastや、ブログを通じていろんな発信をしてきました。そうすると色んな質問を各所から受けるわけなんですが、一番聞かれる質問第一位は、「結局EMって何する人なんですか?」 です。一口にEMって言っても、なんか人によって得意な領域が違っていたり、大事だと思うポイントがバラバラなので、この疑問を持つのはそりゃそうだよなあ、とは思います。というわけで、このエントリーではEMは何する人なのかを明らかに・・・と思ったのですが、一言で語るのはやっぱり難しいなと思っています。なので、なぜ僕がEMという役割を説明するのが難しいと思っているのか、を書いていきます。 マネージャーの本質はチームの足りてない
次のページ
このページを最初にブックマークしてみませんか?
『KAKEHASHI Tech Blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く