こんにちは！ いきいきいくお（小田中育生、@dora_e_m）です。現在、株式会社カケハシにエンジニアリングマネージャーとして所属しています。カケハシにジョインしたのは2023年10月で、それまでは長い間、株式会社ナビタイムジャパンに所属していました。 ここ数年はアジャイルコミュニティで発信する機会が多いため、「アジャイルの人」という印象があるかもしれません。2011年に書籍『アジャイルサムライ』と出会い、2017年頃から本格的にアジャイル開発に取り組み始め、アジャイルコミュニティにも参加するようになりました。2020年には『カイゼン・ジャーニー』の著者である市谷聡啓さんや新井剛さんとともにアジャイルの入門書『いちばんやさしいアジャイル開発の教本』を執筆する機会にも恵まれました。 私がアジャイル開発に取り組み、その活動を広げてきた原点は「目の前にある課題を解決したい」「よりよい状態へとカイ

Agile Journeyをご覧のみなさん、はじめまして。川口恭伸（@kawaguti）と申します。 私はアジャイル開発やスクラムに関する知識を提供し、モダンなソフトウェア開発の要素の研究、プロダクト開発の進め方やチームの目標設定など、さまざまな領域でのコンサルティングを手掛けています。 また、アギレルゴコンサルティング株式会社においてシニアアジャイルコーチとして活動しており、一般社団法人スクラムギャザリング東京実行委員会と一般社団法人DevOpsDays Tokyoの代表理事も務めています。さらに、コミュニティ活動としては、毎週水曜日に品川アジャイルに参加しており、RSGT、スクラムフェス、DevOpsDaysといったカンファレンスでのスタッフワークも担当しています。 このように、ほぼ公私の境なくアジャイルやスクラムを基にした活動を長く行っていますが、本稿では、私がスクラムを始めるまでの

はじめに こんにちは。カケハシの各プロダクトを支えるプラットフォームシステムの開発チームでテックリードを担当しているkosui(@kosui_me)です。 プロダクト開発の世界では、明瞭な社内向けドキュメントを書くための方法が数多く提案されてきました。読者の中には、製品要求を明瞭にするためにPRD (Product Requirements Document、製品要求仕様書) を書き、プロジェクトの背景から全体の設計やその代案について明瞭にするためにDesign Docsを書き、アーキテクチャに関する意思決定の記録を明瞭にするためにADR(Architecture Decision Record) を書いてきた方も数多くいらっしゃると思います。 しかし、どんな素晴らしいドキュメントも、何故か更新されなくなります。新メンバーへのオンボーディングのためにインフラ構成図を検索したあなたが見つけた

2023年9月25日、和田卓人さん（t-wadaさん）をお招きし社内講演会を開催しました。 和田 卓人さん / プログラマー、テスト駆動開発者 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。執筆活動や講演、ハンズオンイベントなどを通じてテスト駆動開発を広めようと努力している。 『プログラマが知るべき97のこと』（オライリージャパン、2010）監修。『SQLアンチパターン』（オライリージャパン、2013）監訳。『テスト駆動開発』（オーム社、2017）翻訳。『事業をエンジニアリングする技術者たち』（ラムダノート、2022）編者。テストライブラリ「power-assert-js」 作者。 Twitter: @t_wada GitHub: @twada 開催のきっかけ カケハシでのシステムの質とスピードの前提知識を理解し、改めてシステムの質についてチームで会話するきっかけにな

8/26 発売！ 『スクラムの拡張による組織づくり』をいただいて読んだ。だいくしーさんの書かれた本。昨日 8/26 発売。すごく読みやすいし、色々と頭の中でぐるぐる考えて面白かった。 gihyo.jp 大規模スクラムに興味がある人にオススメ Scrum@Scale という大規模スクラムのフレームワークの解説を中心にした書籍なので、Scrum@Scale に取り組みたい人や大規模スクラムに興味がある人には、もちろんとてもオススメ。僕は全然 Scrum@Scale のことを知らなかったので本書で入門できて勉強になった。 そして、読みやすい。これから何を説明するのか、なぜこれをここで説明するのか、という著者の意図が各章の最初に書いてあるのが嬉しい。まえがきを含めて、一冊を通しての流れがとても分かりやすいので、まえがきから読むのがオススメ。 まえがきから第6章までを通して読んで「なるほど。Scru

（分割キーボードのMoonlander。とても気に入ってます。） はじめまして。ソフトウェアエンジニアの椎葉（@bufferings）です。今年の4月にカケハシに入社して、今月末で3ヶ月になります。毎日楽しく過ごしていて、あっという間の3ヶ月間でした。 最初にすなおにお伝えすると、この週末と週明けにイベントで登壇するので、その宣伝をしたいなという気持ちがあってブログを書くことにしました。ぜひイベントを見に来てほしいです！ そんなきっかけではあるのですが、せっかくの機会なので、この3ヶ月をふりかえって、やったことを書いてみようと思います。初の会社ブログです。僕がどんな風に仕事をしているか、雰囲気が少しでも伝わると嬉しいです。宣伝は最後に書きます！ 薬剤師さんってすごいー！（4月上旬） 4月上旬は会社のオンボーディングで、カケハシのことをいろいろと学びました。 カケハシは基本的にリモートワーク

グーグルが開発するAIチャット「Bard」。2月6日に発表され、3月21日より米国と英国のみで公開されていたが、4月18日午後（日本時間）あたりから、日本でもベータテストに参加できるようになった。 さっそく使ってみる 「Bard」は大規模言語モデル（LLM）「GPT-4」を使用したOpenAIの「ChatGPT」同様、Googleが開発するLLM「LaMDA（Language Model for Dialogue Applications）」の「軽量で最適化されたバージョン」を利用している。 ベータテストに参加するには、サイトの右下に表示されている「Join Waitlist」ボタンをクリックし、ニュースメールの購読にチェックを入れるだけでよい。

Jestではじめるテスト入門 本日「Jestではじめるテスト入門」がついに発売されました 🎉🎉🎉 peaks.cc CircleCI時代の同僚の伊藤さん @ganezasan が「Jestの自動テスト本の執筆を手伝ってくれませんか？」と声をかけてくれて「これからテストを書きたいって人に向けたJestの入門書を書きたいんですよ！！」って熱く語ってくれて「いいなぁ」と思ったので参加しました。本を書くなんて初めてのことなので、自分なんかに書けるかなぁとドキドキしてたのですが、周りの方々の助けのおかげで、なんとか書き上げることができました。 そして、監修はなんと和田さん @t_wada です。自分が自動テストについて書いた文章を、和田さんに監修していただけるなんて、それだけでとても幸せだなぁと思っていたのですが、「むちゃくちゃ面白かったです！」って言ってもらえたので、もう出版しなくても満足し

ありがちな仕様とコードを題材に、よくないコードに立ち向かうための整理術を紹介します。 この Book にはデザインパターンや DDD やオニオンアーキテクチャや関数型プログラミングなどは一切登場しませんが、それらのエッセンスと日常のコーディングにおいて求められる基礎的な考え方の説明が含まれています。 この Book の内容は、特定の業務領域やプログラミング言語・フレームワークには限定されません。 Laravel でも RoR でも Spring でも React でも Nuxt.js でも、きっと役に立つはずです。 逆にこの本にはクラス設計のべき論や OOP vs FP のような議論は含まれません。 画一的なコードの良し悪しの定義は難しいですが、何かしら得るものがあったと感じてもらえたらうれしいです。

アジャイルリーダーシップ を翻訳者の一人であるヒロオカさんにいただいて読みました。ありがとうございます！今の自分にグサッとくる内容でとてもとても良かった。今後の自分の行動も変わりそうです。今日から数日後の11月22日に発売されます www.kyoritsu-pub.co.jp 読みやすかった 著者は SCRUMMASTER THE BOOK を書かれたズージーさん ズージーさんの本自体が読みやすいのと、あと、ユーザベースさんの翻訳が読みやすいのとで、とても読みやすかった。英語の言い回しって日本語にすると分かりにくかったりするけど、そういうのがなくて、自然に読むことができた アジャイルリーダーシップ？ 「アジャイルリーダーシップ」ってタイトルを見たときは、アジャイルなチームのリーダーの話なのかな？スクラムマスターはこうあるべきだよとかって話？と思ったのだけど、読み始めてみるとそうじゃなくて、

画像生成AI「Stable Diffusion」の開発元でAIスタートアップ企業である英Stability AIは10月17日（現地時間）、1億100万米ドル（約150億円、1米ドル＝149円換算）の資金調達をしたと発表した。画像や言語、音声、動画、3Dなどの一般および法人向けのオープンAIモデルの開発を加速させるという。 Stability AIに投資をしたのは、ベンチャーキャピタルの米Coatue Managementと米Lightspeed Venture Partners、米O'Shaughnessy Ventures LLCの3社。 Stable Diffusionはオープンソース化された画像生成AIで、ライセンスを明記することで営利・非営利問わずに使用できる。画像生成AI「Novel AI Diffusion」（Novel AI）のベースとしても利用されている。日本でも日本語版

▲ 2020年1月に開催された「Regional Scrum Gathering℠ Tokyo 2020」に登壇（撮影：藤村新 @aratafuji さん） こんにちは、椎葉光行（@bufferings）です。CircleCIでIC（Individual Contributor）としてシニアソフトウェアエンジニアをやってます。20代に小さな開発会社や派遣でプログラミングを覚え、30代をまるっと楽天で過ごし、2021年に41歳で転職しました。現在は大阪の自宅からフルリモートで仕事をしています。 この20年、ずっといろいろなことを学びながら過ごしてきました。その中でも特に楽天で過ごした30代は「密度の濃い10年間だったなぁ」と思います。エンジニアとして技術的な成長はもちろん、チーム作りや組織作りにも取り組み、人と一緒に仕事をすることについて考え続けた10年でもありました。 この記事では私の30

config.yml を分割できる Orb を作ったよー Split Config Orb という Orb を作った こないだからちょこちょこ試してたやつを Orb にしたのだ。この Orb を使うと config.yml を分割できる。Orb にしたから簡単に使えるよー！ config.yml が大きいから分割したいー！って場合や、モノレポで複数サービスを入れてるから各サービスごとに config.yml を書きたい！って場合に使えるかなぁって思ってる もしちょっとでも興味があったら、実際に使ってみてフィードバックをいただけると嬉しいです。フィードバックを元にして機能をブラッシュアップできるといいなと思ってます！GitHub の Issue でも Twitter でメンションくれても OK です！ GitHub Issue: Issues · bufferings/orb-split-c

ぼーっと CUE のドキュメントを読みながら CUE という設定用の言語・・・と呼んで良いのかな？のドキュメントを読みながら https://cuelang.org/ 「これ、いろんな機能があるけど、それは置いといて、YAML の合成が簡単にできるのでは？・・・とすると、CircleCI の設定を簡単に分割できて面白いかもなぁ」 と思ったので試してみた。わりとアリかもしれない 今回のサンプルコードはここ： github.com どういう感じ？ こんな感じに適当に分割した設定を ❯ tree .circleci/configs .circleci/configs ├── header.yml ├── job1.yml ├── sample │ ├── job2.yml │ └── mixed\ sample.yml ├── workflow1.yml └── workflow2.yml 1

こんにちは。株式会社アカツキでエンジニアリングマネージャーをしている、石毛琴恵です。私がマネージメントするチームでは、約1年半前から、スクラムのスケール手法であるLeSS（Large-Scale Scrum）を導入しています。本記事では、「これから自分の環境でLeSSを取り入れたい」「スクラムをスケールさせたい」と考えている方に向け、私のLeSS導入体験やそこから得た学び、失敗したこと、導入した結果や今後の挑戦についてお伝えしたいと思います。 なお、本記事のテーマは、「LeSSの実践」です。そのため、スクラムやLeSSの基本的な概要については、詳しく触れません。これらの基本概念に関しては、スクラムガイドやless.worksをご参照ください。 LeSSを導入した環境について LeSSとはなにか？なにをどのように解決するものなのか？ なぜLeSSを採用したのか LeSS導入のプロセス。チーム

ちょっと前にツイッターで見かけた、ゆめみのフロントエンドコーディング試験 フロントエンドコーディング試験 「RESAS API を使用して、都道府県別の総人口推移グラフを表示するSPAを作る」っていうお題 React の勉強をするのにちょうどいい題材だなぁって思ったのでやってみた。課題を公開してるってことは「やってみてもいいよ」ってことかなと思ってるんだけど、もし違ったら GitHub のリポジトリーを private にするので連絡ください 1週間でやらないといけないところを2ヶ月近くやってるし、コミットログも特に何も考えずにポイポイ書いたから、全然だめなんだけど、でも、色々勉強になったので、とてもよかった。楽しかったー！ つくったもの こんな感じ これでおわりにするー pic.twitter.com/K8zhrRUp54— Mitsuyuki Shiiba (@bufferings)

かなり良かった 「良いコード／悪いコードで学ぶ設計入門」を読んだ。読む前は特に書くつもりはなかったんだけど、かなり良かったからブログを書くことにした gihyo.jp どういう本？ この本は、読みやすくて変更しやすいコードの書き方と設計についての入門書 どのようなコードが悪いコードなのか、そこにどういう問題があるのか。それに対してオブジェクト指向設計で、どのように設計してコードを書けば、より良いコードを書くことができるのかを、分かりやすい例でコードを追いかけながら、学ぶことができる 読むと良さそうな人 2,3年目くらいで「もっと良いコードを書きたい！」とか「どんなコードが良いコードなんだろう？」って考えてる人や もうちょっと経験があって、機能追加や改修をするときに苦労をしてきて「どんな風に作ればこの苦労を減らすことができるんだろう？」って悩んでる人には、特におすすめ それ以外でも、今はコー

昨日はトランクベース開発とデプロイについて書いたので bufferings.hatenablog.com この勢いで GitOps とデプロイも書いてしまうー。先に言っておくと、自分は GitOps の経験はない。でも、よさそうだなぁと思う手法なので、機会があれば挑戦してみたい気持ち GitOps? GitOps は2017年に Weaveworks の Alexis によって提唱された手法で、Kubernetes を対象としている Guide To GitOps Git のリポジトリーに入れてある設定ファイルを Single Source of Truth として、Kubernetes のクラスター管理とアプリケーションデリバリーを行う。上記の記事には次の4つの原則が書かれている システム全体が宣言的に記述されていること 正規の望ましいシステムの状態が Git でバージョン管理されている

前回は Git-flow とデプロイについて書いたので bufferings.hatenablog.com 今回は、トランクベース開発とデプロイについて考える。LinkedIn, Facebook, Google などもトランクベースの開発をしてるんだね 参照: Agility Requires Safety | Y Combinator トランクベース開発は Git じゃなくてもいいと思うんだけど、この記事では Git 前提で考える トランクベース開発？ 幹（trunk）となるブランチにみんなが小さな変更を加えていくブランチモデル。寿命の長いブランチを作らないようにすることで、マージでつらい思いをしなくて済むようになって、ビルドも壊れないようにできて、ヤッター！というもの trunkbaseddevelopment.com Git-flow みたいに develop ブランチで開発をする

「Scrum Fest Osaka」はスクラムの初心者からエキスパート、ユーザー企業から開発企業、立場の異なる様々な人々が集まる学びの場です。KEYNOTEで登壇したのは、楽天グループ株式会社の椎葉氏。「誰も嫌な思いをしない変化」をタイトルに、自身が開発グループのサポートをしたときの取り組みについて話しました。全3回。3回目は、1年間をかけて変化したチームの結果について。前回はこちらから。 チームを変えるために「並行プロジェクトをやめる」ことを提案 椎葉光行氏：意識していることはわかった。それをどう実践しているのということで、具体的に自分がどういう選択をしてきたかを、さっきのチームのサポートの中からいくつか紹介したいなと思います。 サポートの始まりは、エンジニアのスキルアップをしたいので力を貸してほしいという依頼でした。それを考えながら、ぼーっと見ていたんですが、スキルアップができていない