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といったカンファレンスでのスタッフワークも担当しています。 このように、ほぼ公私の境なくアジャイルやスクラムを基にした活動を長く行っていますが、本稿では、私がスクラムを始めるまでの

アジャイルソフトウェア開発手法の先駆けともいえるXP（eXtreme Programming）の名を冠して2002年から20年以上にわたり毎年開催されているXP祭り。2023年はオンラインの講演とオンサイトでのワークショップによるハイブリッド形式で、9月30日（土）に開催が予定されています。 ▶ XP祭り2023 - xpjug.com/xp2023/ コミュニティ主体によるカンファレンス開催が国内でまだ珍しかったころにスタートし、企業によるスポンサードもほぼなく、参加費も登壇料も全て無料、セッションだけでなくスタッフも毎年公募して入れ替える素朴な運営を続けながら、和田卓人さんや平鍋健児さんといった著名なエンジニアも登壇し、ソフトウェア開発について多くの示唆を与えてきたこのイベントはどのように続いてきたのでしょうか。 世界的にもアジャイルが広まりはじめた立ち上げ当初を知る小井土亨さんと、2

エンジニアの梅原です。 少し前から「心理的安全性」というキーワードについて、疑問に思うところがあって色々と考えていて、 なんとなく考えがまとまったので、自戒も込めて文章として書き起こしてみました。 もともと社内向けに書いたものでしたが、思いのほか反響があったためこちらでも書いてみようと思います。 めちゃくちゃなこと言ってんな、って思う人もいるかもしれませんが、際に振ったときの思考実験だと思って読んでもらえると。 心理的安全性とは何か？ 一般的に「心理的安全性」とは、以下の定義で語られます。 "A shared belief held by members of a team that the team is safe for interpersonal risk taking." （このチーム内では、対人関係上のリスクをとったとしても安心できるという共通の思い） Edmondson (19

以前対談させていただいただいくしーさんが本を出されたということで、対談内容にも通じる組織の話ということもありこれは読まねば！　と思い買って読んでみました。*1 結果、とてもよかったです。 最近の個人的な関心事にも通じる部分が大きく、多くのヒントが得られ、また思考を刺激する内容でした。 複数チームでうまく価値を届ける 僕がいる組織ではスクラムを取り入れていませんし、スクラムやScrum@Scaleを取り入れる予定もありません。*2 それでも、複数のB2B SaaSを展開するアジャイルなプロダクトチームとして、複数チームでうまく価値を届けていく必要はあります。 単一のプロダクトを複数チームで開発するに際して、どのようにチームが分かれているとよいのか。チーム間の連携についてはどう考えるとよいのか。その濃淡は。また、（スクラムでいうところの）プロダクトオーナー側はどうなっているとよいのか。さらには

マネジメント 新しいチームのあり方を探求 就活 就活生必見！サイボウズの疑問 ティール組織 会社の「あたりまえ」が変わる 多様性 100人100通りの個性 ワークスタイル 働き方、生き方、もっと自由に 青野慶久 サイボウズ社長の想いと覚悟 キャリア 人生の「積み上げ方」を見直す 複業 複数の「本業」をもつ働き方 人事制度 多様な働き方を支える仕組み マンガ サクッと手軽に読める！

導入 こんにちは、Product Teamの朴です。 プロダクトを開発する中で、信頼が大事という話は良く聞きます。プロダクトマネジメントに関する本の「INSPIRED」、「Radical Candor」などでもメンバー同士の信頼関係の構築の大事さが強調されています。 特にプロダクト開発の中で多く取り上げられるこの信頼とはなんでしょうか？ 時々組織の技術的な面よりこの信頼を積み上げることで、プロダクト開発のスピードが上がる重要なキーにもなります。ではプロダクト開発のスピードにも関係するこの信頼はどう積み上げていけば良いでしょうか？ この記事は信頼についてと、信頼を資産のように考え、活用する方法についてです。 信頼とは 信頼の語源は「慰安」の意味のドイツ語の「trost」からだと言われています。誰かを信頼し、裏切られる心配がないと安心できますよね。それに裏切られる心配もないので、予防のためにコ

「アジャイルリーダーシップは、これからのリーダーシップです」 変化の速度が速まり、また、複雑化した現在のビジネス環境に適応し、価値を創出し続ける組織であるためには、旧来的ではない、新たなリーダーシップが必要になる。 こう説く書籍『アジャイルリーダーシップ』が2022年秋に刊行されました。著者であり高名なアジャイルコーチであるZuzana Šochová（ズザナ・ショコバ / @zuzuzka）さんは、自身の経験と多くの情報を融合し、変化に適応するアジャイル組織を形作るうえで重要な要素である、アジャイルリーダーシップを具体化し、それを体現するために必要なコンピテンシー（行動特性）やエクササイズを同書にまとめました。 書籍で語られる、アジャイルリーダーシップの価値はどこにあるのか、組織内で浸透させるための課題は何か、いかにして現場で発露するか。こうした「アジャイルリーダーシップの実践」を、同書