ソフトウェアエンジニアとして、チームでの「ふりかえり」に500回*1ばかり取り組んできた中で、「ふりかえり」とは、「チームという複雑系をよりよくするための実験にコミットする道のり」である、という理解に行き着いた。 これが真理である、というよりは、自分なりの整理の枠組みみたいなものなんだけど、ふりかえりという活動を見つめ直す役には立つんじゃないかなと思うので、解説してみたい。 「ふりかえり」とは、チームをよりよくするために立ち止まって話し合うこと 「ふりかえり」とは、実験を考案してその実施にコミットすること 「チーム」とは、目的を持つ複雑系（complex system） 「チーム」の目的の1つは、価値を生み出すこと 「チーム」の目的の1つは、学習・成長すること 複雑系において、あらゆる介入は本質的に実験 課題は「見い出す」もの 「ふりかえり」の道のりもまた、システムに影響を与える 「ふりか

Agile Journeyをご覧のみなさん、こんにちは。今井健男（@bonotake）と申します。「ぼのたけ」と名乗っていることもあります。普段はフリーランスのアジャイルコーチをしつつ、現在は国立情報学研究所という国の研究所でスクラムの研究をしています。 今回、「はじめてのアジャイル」という連載企画に声をかけていただき、僕がアジャイルの道に進むきっかけをこちらに書くことになりました。ただ、執筆の依頼をお引き受けはしたものの、正直なところ、僕の体験が皆さんにとって何かしら参考になるかは分かません。もともとずっとソフトウェア工学の研究をしている研究者だった、という特殊な経歴の持ち主だからです。 恐らく他の人とはかなり変わった視点からアジャイルを体験してきていて、あまり共感されるような内容ではないかもしれませんが、それでも読者の方のうち何人かは面白がってもらえるかもしれないと期待して、ひとまず筆

記事AI要約 アジャイル推進者とプロダクトマネージャー、この2つの立場の間にしばしば生まれる「溝」について、両者の視点から率直な議論を展開。プロダクトの成功という共通のゴールを持ちながらも、時として対立する背景には何があるのか。「理想」と「現実」のバランス、専門性の捉え方、組織変革の視座など、本質的なテーマに切り込んでいく。建設的な対話を通じて、より良いプロダクト開発の実現に向けた具体的なヒントと実践的な示唆を提供する。「溝」を超えて協働するための第一歩となる知見が詰まった往復書簡。 今回は、プロダクトマネージャーやアジャイルコーチを歴任し、現在プロダクトコーチとしてプロダクトマネジメントのコーチングやアドバイザリーを提供されている横道さんと書簡を交換します。テーマは「アジャイル推進者とプロダクトマネージャーの間にある溝」という、やや刺激的な内容を扱いたいと思います。 「アジャイル推進者」

こんにちは、グループ経営ソリューション事業部の米久保です。 はじめに リファクタリングとは リファクタリングの定義 振る舞いのサイズ 振る舞いと自動テストとの対応 リファクタリングテクニック リファクタリングサイズ 技術的負債はどうして生まれるのか コードの守備範囲 変更への対応 技術的負債を返済する 早い返済が吉 新規開発時 変更時 開発チームの裁量で返済する 説得方法 大規模なリファクタリング まとめ 参考文献 はじめに 「リファクタリングをする時間がない」「リファクタリングの必要性を関係者に説得しなくてはならない」という悩みをよく聞きます。 リファクタリングという用語が広く普及した結果、意味の希薄化が発生し、元来の意味と異なる使われ方を目にすることもあります。また、似通った用語としてリアーキテクティングというものがあり、混同されがちです。 リファクタリングの課題と向き合い、それらを解

お弁当の定番『イシイのおべんとクン ミートボール』などの商品作りを無添加調理で進める石井食品株式会社*1では、まだ40代の石井智康さんが代表取締役を務めています。石井さんは創業家の出身ながら、大学卒業後はIT業界に入り、フリーのスクラムマスターとして活躍するなど、石井食品とは距離を置いていました。 しかし、フリーランスとして働くなかで、改めて社会にどのような貢献ができるかを考えた結果、食の課題に取り組むため家業を継ぐことを決意。2018年に代表取締役社長に就任すると、それまで培ったソフトウェア開発やアジャイルの知見を生かして、さまざまな業務プロセスやコミュニケーションの改革に取り組んでいます。 企業を取り巻く環境が変化するなか、アジャイルに対する理解と知見を持つソフトウェアエンジニアが企業経営に取り組むことで、どのような変革をもたらすことができるのでしょうか。アジャイルとの出会いや石井食品

事業やプロダクトの成長を目指すとき、必然的にエンジニアリングのタスクも増えてチームは拡大し、開発組織のスケーリングという新たな課題が発生します。アジャイルにおいても開発をスケールさせるフレームワークはいくつかありますが、十分な知見が得られず試行錯誤している企業も多いのではないでしょうか。 クラウド経営管理システムを開発する株式会社ログラスでも、事業の成長に伴っていくつもの課題に直面しました。同社ではスクラムを導入していましたが、チーム間やエンジニア間のコミュニケーションコストが増大したり、チームが担当する領域以外の知識に乏しくなって全体感を把握するメンバーが減少したりしていました。 こうした課題にこれまでのやり方では解決が難しいと判断した同社は、スケールする開発プロセスとしてFASTの導入に取り組んでいます。これまでもアジャイルだけでなくドメイン駆動型設計（DDD）などを積極的に取り入れて

Agile Journeyをご覧のみなさん、はじめまして。株式会社ソニックガーデンの代表をしている倉貫義人と申します。 私はもともと大手システム会社でプログラマとして働いていました。そのとき出会ったアジャイル開発に魅了され、これこそ自分にとって理想の姿であると確信し、それ以来アジャイル開発を広めるための様々な活動を社内外で行ってきました。 最終的に、本当に自分の理想とするソフトウェア開発と、それを実現する組織をつくるためには、自ら会社を経営する立場になるしかないと考え、起業することになりました。そうしてできたのが株式会社ソニックガーデンです。 ソニックガーデンでは「納品のない受託開発」というサービスを提供しています。従来的な受託開発から、そもそものビジネスモデルを見直したことで、今では「アジャイル開発」を意識せずとも、自然とそれに取り組める組織として機能しています。 思い返すと、私のアジャ

アジャイル開発に関心がある人にとって、トヨタ自動車と聞いてすぐ思い浮かぶのは「TPS（トヨタ生産方式）」でしょう。 かんばん、ジャスト・イン・タイム、リーンなど、そのクルマ作りにおける考え方は多くのアジャイル開発手法の源流にもなっています。 一方、現代のアジャイル開発が主眼としているのは、変化への迅速な適応が求められるソフトウェアシステムの開発です。 自動車やその部品（ユニット）のようなハードウェアを開発する際の手法としてアジャイル開発手法を採用するケースはまだ決して多くありません。 そのような中、トヨタ自動車のエンジンを含む駆動系の技術開発を担うパワートレーンカンパニーでは、アジャイルなハードウェア開発への取り組みを2021年ごろから本格的に進めています。 さらに2023年9月のスクラムフェス三河や、2024年1月のRSGT 2024（Regional Scrum Gathering T

写真・文: 古賀及子 埼玉の実家から東京の短大に通っていた私は、入学半年ほどで通学に音を上げた。 実家は大宮とか川口といった東京に近い都市ではない、もっとずっと奥、本気の埼玉だ。学校へは片道2時間。通えなくはない、でも正直かなり遠い。実家の最寄駅を走る路線の電車の本数が少ないのにも参った。帰宅時、うっかり1本逃がすと家に着くのが1時間遅くなってしまう。 幸いにして父方の祖父母が東京に暮らしていた。まだ元気だった祖父母は喜んで私を居候として受け入れると言ってくれたから、すぐに実家を出て転がり込んだ。品川区の街だった。 祖父母にかわいがられ、すっかり居心地よくぼんやり暮らしているうちに気づけば短大の卒業はすぐそこにやってきた。短大では軽音サークルに所属していた私は、本格的に音楽活動に打ち込むのだという先輩たちに流されて、なんと就職しなかった。先輩方と違い、私はバンドにも楽器にも本気で取り組んで

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

こんにちは。ソーシャル経済メディア「NewsPicks」NewsPicks Stage.事業のエンジニアをしています、林です。 業務では Next.js / Rust / Go などを用いて、経済・ビジネス情報に特化した動画配信サービスであるNewsPicks Stage.の開発・運用を行っています。 はじめに 突然ですが、皆さんは自身のソフトウェアのライブラリアップデートは行えていますか？ 皆さんはどのようにライブラリアップデートを行なっていますか？ 新機能を試したくて？ npm iで失敗してから頑張る？ Renovate / dependabot が自動Mergeされる環境？ もしくは対応担当が特定の日にまとめてMergeする運用？ しかし多くの開発者は、アップデートに対して「うまくいっている」と言えないのではないでしょうか？自身も様々なプロダクトを開発してきた経験上、日々の中ではどう

このブログエントリでは、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent BeckがTDDの定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ 2023年の年末、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent Beckは、substackにTDDに関するポストを連投して論戦を繰り広げていました。TDDはその誕生から20年以上が経ち、その間に「意味の希薄化」が発生して議論が噛み合わなくなっていました。意味の希薄化（Semantic Diffusion）とは、新しく作り出された用語が広まる際に本来の意味や定義が弱まって伝わる現象です。 私（和田）はTDDと関わりの深いキャリアを歩んできました。Kent Beckの著書『テスト駆動開発』の翻訳者であることもあり、TDDの正

エンジニアに限らず、BlogやTwitter、OSS、登壇など、対外発信力がキャリアにおける強力な付加価値になることは知られるようになりました。 英語力がそうであるように、発信力は必ずしも必須スキルではありません。英語ができなくても活躍しているエンジニアはいくらでもいます。同時に英語がそうであるように発信力が有力な付加価値をもたらすスキルであることは事実です。 私自身、発信力が強みになっている分バイアスがあるので、あまりそのスキルの価値を過大評価して他人に押し付けるようなことはしたくありません。それに、エンジニアだったら発信力などではなく、純粋な技術力で評価されたいよな、という青臭い気持ちもまだどこかにあります。 ですから、全員が発信すべきだとは考えません。ただ、対外発信に興味を持っている人は後押しはしたいし、そういう人が増えてほしいとは強く思っています。なぜならば、それが単純に楽しいから

昨年、十二月二十一日のことである。 森見登美彦氏は、万城目学氏と、ヨーロッパ企画の上田誠氏との忘年会に参加した。年末の京都に清らかなおっさんたちが集う忘年会も、すでに六回目を数える。 「六回目といえば」 ということで、万城目氏が新作『八月の御所グラウンド』で六回目の直木賞候補になっているという話になった。 しかし万城目氏の顔つきは暗かった。 「どうせあかんねん」 「待ち会はしないんですか？」 「そんなもんせえへんわ。いつもどおりにしてる」 それはいかん、と登美彦氏は思った。度重なる落選にウンザリする気持ちはよく分かるが、直木賞はようするに「お祭り」なのであって、盛りあがらなければ損である。「待ち会」は落ちてからが本番なのだ。落選したってええじゃないか！ 「何をいじけてるんです。待ち会やりましょう！」 「なんでやねん！」 「やるなら東京まで行きますって」 「あ、それなら僕も行きます」と上田氏

Agile Journeyをご覧いただき、ありがとうございます。本メディアの運営を担うユーザベースBtoB SaaS事業のCTOを務める林です。本メディアでは、これまで多くの方がアジャイルに関する経験、知見を披露してきてくれましたが、本稿では私たち自身のアジャイルの実践手段のひとつであり、「組織の耐障害性」を高める手段である「カオスWeek」という取り組みを取り込みについてお伝えしたいと思います。 カオスエンジニアリングを組織に適用した「カオスWeek」とはなにか カオスWeekの目的と、キーパーソンを隔離する意味 カオスWeekの実践方法 カオスWeekの実施タイミングを開発計画に織り込む 「抜ける人」は影響力の大きさで決める コミュニケーションを遮断し対象メンバーを隔離する。あえて準備しない 隔離されたメンバーは独立して進められるタスクにあたるのがおすすめ ユーザベースのProduct

こちらの記事は カケハシ Part 2 Advent Calendar 2023 の 11日目の記事になります。 こんにちは、AI在庫管理バックエンドエンジニアの安藤です。 今回は、在庫管理システムをテーマにXPを意識した取り組みを行ったのが大変だっ楽しかったので、その振り返りをしようと思います。 トライしたこと 先日、自分たちが普段気づいていないことに気づける機会を開発ディレクターの指示のもと作ってもらいました。 普段の開発のなかではなかなかアグレッシブな試みは難しいため、在庫管理のプロトタイピングを改めて試すなかでいくつかの制約を設けることで普段なんとなくやりすごしてしまっていることに気づき、より変化に適応する開発の方法を知ることが1つの狙いでした（当初はそのあたりの目的を完全には理解できていませんでしたが）。 そのなかで与えられた制約について整理しながら振り返ってみようと思います。そ

この記事は、Uzabase Advent Calendar 2023の10日目の記事です。 昨日の記事は@itsukiyさんの「YAGNIから受け取ったメッセージ」でした。 まえおき 現在僕が所属するユーザベースでは、エンジニア、デザイナー、プロダクトマネージャーは別の組織に所属していて、チームとしてプロダクトを開発・運用する日々の活動はエンジニアからなるプロダクトチームのメンバーが中心となって行っています。 デザイナーやプロダクトマネージャーは兼務であることも多く、日常の多くの時間を共にしてはいません。 もちろん、その時間にデザイナーやプロダクトマネージャーもそれぞれがプロダクトにまつわる活動をしているわけですが、いわゆる全員同席状態、常に自然とチームとしての意識を持ちやすい状態ではない、ということです。 それでも、僕はデザイナーやプロダクトマネージャーを含めた「チーム」として考え、行動

『プロダクトマネージャーのしごと』は本当にすばらしい本だった。 邦題にこそ『プロダクトマネージャー』という役割名が入っているが（※原題は『Product Management in Practice』）プロダクトはみんなで作るものであり、ソフトウェアエンジニアである自分もまたプロダクトマネジメントの重要な部分を担っている。常にではなくとも、すぐれたプロダクトマネージャとしての振る舞いが求められる場面や、役に立つ場面というのも多いと感じる。 この本から学んだことをよりしっかりと身につけ、実践していけるように、自分が学んだことをまとめてみる。 学んだことは、「過程にとらわれず、価値に集中せよ」「ユーザー価値とビジネス価値、シニアステークホルダーとチーム、すべてをつなげ」の大きく2つにまとめることができる。 以降はこの大きな2つの切り口から、学んだことをまとめていく。 過程にとらわれず、価値に集

プロダクト開発部の千田です。 チームで「実例マッピング」を実施してみたので、今回はそのことについて記事を書いていこうと思います。 ユーザーストーリーが曖昧なまま開発が進んでいる、ビジネスサイドと開発者の一体感がないなどの課題感があるチームの参考になったら嬉しいです！ 前提 チームが抱える課題 実例マッピングとは 実施方法について 良かった点 まとめ 前提 基本的にコドモンでは開発を進める際に、ユーザーストーリーを作成します。私が所属するチームでは、機能を開発する際にPdMがカスタマーサポートなどのビジネスサイドのメンバーから要件をヒアリングした後に機能の仕様を整理し、ユーザーストーリーの一覧を作成します。 その後、PdMと開発メンバーでユーザーストーリーの読み合わせをし、ストーリーポイントを付けていました。しかし、この方法には課題がありました。 チームが抱える課題 PdMが事前に作成したユ

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