はてなブックマーク

はじめまして。流しのアーキテクトを生業としている、株式会社ウルフチーフの川島（@kawasima）です。私はSIerで20年、主にアーキテクトとしてさまざまなプロジェクトに関わってきました。現在は独立し、データモデリングを中心に、多くの企業の設計や技術者育成を支援しています。 数多くの現場を渡り歩く中で、プロジェクトを停滞させる「ある共通項」が見えてきました。それが、技術的負債に伴って静かに蓄積する「クラフト」です。本稿ではこの「クラフト」の正体を突き止め、パターンごとの対処法を具体的に紐解いていきます。 メンテナンスコストを増加させる「クラフト」 クラフトは計画的なリファクタリングによってのみ解消できる なぜクラフトが溜まる？ 欠けているのは「整えるフェーズ」 【ケーススタディ】 技術的負債に伴って発生するクラフトの4分類と対処法 【1】混在：異なる概念が同じ場所に置かれる 【2】分散：

ダイキン工業では2021年から、有志が集い、アジャイル開発によるソフトウェアの内製化に取り組み始めました。営業部門をステークホルダーとしたスクラムによる開発体制を作り、事業価値を提供するためプロダクトの改善を繰り返してきました。 しかし、本来一つのチームであるはずのスクラムの中で、営業側から開発チームが「社内受託チーム」のように見なされるなど、ズレを感じる場面が生じていたといいます。 ダイキン工業はその状況をどう乗り越え、同じ目線でプロダクトに向き合うアジャイル本来の理念に根ざした取り組みを進めたのでしょうか。 同社でスクラムマスターとして活動し、他チームへのアジャイルコーチングを担当している谷尾虎之介さんと、営業部門に所属しながらプロダクトオーナー見習いとしてアジャイル内製化チームに参加している芦葉舞さんに、「営業チームへの働きかけ」を中心にお話を伺いました。 アジャイル開発で対外的な評

クラウド経営管理システムを開発する株式会社ログラスでは、事業の成長に伴って、組織面でのさまざまな課題に直面しました。 スクラムチームがサイロ化し、プロダクトの全体像にずれが生じたり、チーム間のコミュニケーションコストが増大したり……。そうした課題を解決するため、同社は2024年8月、「FAST」という新たな開発プロセスの導入に踏み切りました。 FAST導入から1年──。開発現場はどう変わり、どんな学びが得られたのでしょうか。 今回はアジャイル開発に取り組む株式会社ユーザベースの中嶋淳さん・福田航輝さんが、ログラスの飯田意己さん・粟田恭介さんとディスカッション。FASTの背後にあるユニークな考え方やXP（eXtreme Programming）との共通点・相違点を深掘りします。 FASTとXPには「組織の流動性」という共通点がある FASTって何？ 特徴を簡単におさらい FAST（Fluid

ペアプログラミング（ペアプロ）は、効果的だと分かっていても、開発組織のカルチャーとして根付かせるのは簡単ではありません。 では、ペアプロがほとんど行われていなかった組織で、それが自然に広がり、カルチャーとして息づくまでにはどんな工夫があったのでしょうか。 適切な休憩の取り方、ペアとの事前合意、ふりかえりのタイミング……現場での試行錯誤から生まれた「実践知」を、ネットショップ作成サービス「BASE」のプログラミングをするパンダさんに寄稿いただきました。 自身もベテランエンジニアとのペアプロでCSSへの苦手意識を克服したパンダさん。そのリアルな体験と知見は、ペアプロ文化を組織に根付かせたい全ての人に響くはずです。 はじめに｜ペアプロは心理的安全性を築く ペアプロは、価値を体験すれば自然に広がる チームの状況に合わせた柔軟なペアプロ運用 信頼関係構築、知識共有の促進――ペアプロの効果 【効果1】

生成AIを巡る状況は、わずか1年ほどで劇的に変化しました。Claude Codeなど実用的なコード生成エージェントが普及し、開発現場に大きなインパクトを与えつつあります。 とはいえ、「どのような場面で活用できるのか」「実際の開発で本当に役立つのか」といった疑問を抱えるチームも少なくありません。 そこで本稿では「生成AIによるコーディングとテスト駆動開発（TDD）」をメインテーマに、TDDの第一人者・和田卓人さん（@t_wada）と、アジャイルコーチのやっとむさん、こと安井力さん（@yattom）が対談。TDDの意義や、チームでAIを活用するための現実的な視点を掘り下げます。 AIをどう導入し、どう使いこなすか──実践的なヒントが詰まった対談です。 2025年7月時点のコード生成エージェントの現場感 AIが広げるテスト導入の可能性 生成AIが自動テスト導入のハードルを下げた 「As-Is」の

高いアジリティを持ってプロダクト開発を進めなければ、事業が立ち行かなくなるリスクをはらむスタートアップ。先が見えない状況下でも変化に即対応しつつ、ユーザーに価値を提供するには、どのように開発を進めていけば良いのでしょうか。 今回は、「ソフトウェア開発を行うスタートアップ」というスコープで、スタートアップの現場で日々この課題に向き合う面々が、それぞれの立場からアジリティのあり方を探る対談を行いました。ご登場いただいたのは、コミュニティ「Startup in Agile」を共に主宰する永山大輔さん（じゃがさん、@jagaimogmog）と新多真琴さん（あらたまさん、@ar_tama）、そして、同コミュニティで登壇されメディカルフォースでCEOを務める畠中翔一さん（@punk_punx）。 スタートアップという状況で起きやすい問題や、その対処法が浮かび上がってきました。 三者三様のスタートアップ

アイスブレイクとは、会議や面接などの前に行う軽い雑談やゲームのこと。緊張感のある場面で、参加者が話しやすくなるように雰囲気を和らげるコミュニケーション手法です。 例えば、ふりかえりの場で取り入れると、参加者全員が自然と声を出しやすくなります。緊張がほぐれるだけでなく、コミュニケーションがより活発になるでしょう。さらに、アイスブレイクによって心理的安全性が高まり、「発言しても否定されない」という安心感が生まれることで、オープンな議論につながります。ふりかえりの場では、伸びしろのような少し言いにくいことも話す必要があるため、その効果をより強く感じやすいです。 この「Agile Journey」を運営するユーザベースでは、採用面接や部署横断のキックオフなどの場面でもアイスブレイクを欠かさず取り入れています。どのような場でも、参加者全員が心理的ハードルを感じずに発言できるようにすることが目的です。

「こんなにうまくいかないのは、何かが根本的におかしいんじゃないか？」 優秀なメンバーが集まり、全員が真面目に取り組んでいるのに、なぜかプロジェクトはいつもギリギリ。良いものを作りたいのに時間がない。改善したいのに余裕がない。そんなフラストレーションを抱えながら、私は開発リーダーとして悶々とした日々を過ごしていました。 当時の私には想像もできませんでしたが、その後10年以上にわたって続くアジャイル実践の旅が、この疑問から始まったのです。 「Agile Journey」をご覧の皆さん、こんにちは。天野祐介（@ama_ch）です。先日、新卒入社から16年間という長い時間を過ごしたサイボウズを退職し、現在は充電期間中です。 私のキャリアは、ソフトウェアエンジニアとしてスタートしました。その後、長い間「kintone」の開発に携わり、開発チームのリーダーを経てサイボウズの一人目のスクラムマスターにな

アジャイルな開発チームで仕事をするデザイナーには、どういったマインドセットが求められるのでしょうか。アウトプットへのこだわりを抑えて、チームのメンバーとして果たすべき役割があります。またAIによるUIの生成が可能になってきた現在、その役割も大きく変化し始めています。 同じ美術大学に1学年違いで学んだ平野友視（@hiranotomoki）さんと大輪俊行（@ohwatoshiyuki）さんは、現在それぞれ法人向けSaaSを展開する事業会社でアジャイルな開発組織に所属しています。アジャイルな現場におけるデザイナーに必要な姿勢や考え方、そしてこれからの在り方について語り合いました。 アジャイルでは完成品ではなく価値を届ける アジャイルに馴染めるデザイナーとそうでないデザイナー 影響の少ないところから始めて4年で8割をリプレイス デザイナーとAIだけで実現するプロトタイプやデモシステム この先生き残

アジャイルにおいて開発の過程や成果を振り返ることは、チームの改善につながる大切な行動です。とくにスクラムにおいては、スプリントごとにレトロスペクティブ（retrospective、ふりかえり）のイベントを実施します。ふりかえりのフレームワークといえば「KPT」がまず思い浮かびますが、実際にはチームの状況やふりかえりの目的に合わせて、さまざまなレトロスペクティブの手法をチョイスするのが望ましいでしょう。 それでは具体的にKPT以外ではどんなフレームワークがあり、それぞれチームがどのような状態のときに用いると効果的なのでしょうか。ブログに「自分がレトロスペクティブで最初はKPTをやるけどそのうちやらなくなる理由」という記事を執筆したソフトウェアエンジニアの大金慧（@bayashimura、ばやし）さんと、その記事で引用された講演資料の発表者で長年エンジニアリングマネージャーを務める小田中育生（

あなたの組織に「あの人が抜けたら動かない」というチームはありませんか？ 関わっていた人が組織からいなくなって誰も詳細を知らないAPIが存在したりしませんか？ アジャイル開発を導入しているのに、組織としての成長が止まっていると感じることはありませんか？ 「どうすれば組織全体の知識共有を促進し、自己組織化を加速できるのか？」「どうすればキーパーソン依存のリスクを低減できるのか？」「どうすればチームごとのよい取り組みを組織全体に広げられるのか？」これらは多くのエンジニア組織が直面している課題でしょう。 私たちユーザベースのスピーダ事業のProduct Teamでは、こういった課題を解消するために「レンタル移籍」という人事制度を実施しています。レンタル移籍はこれらの課題を同時に解決できる取り組みであり、アジャイルをさらに加速させます。 1週間だけ他のチームに移籍できる独自の制度 レンタル移籍に取り

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

技術ブログやエンジニアセミナーなど、ソフトウェア開発に必要な情報を得る機会はたくさんありますが、系統だった知識をまとめて学ぶなら「本」は依然として便利ですし、繰り返し参照するにも適しています。 また本には人生を変える力があり、多くのエンジニアが書籍から知識を得るだけでなく、本と向き合うことでやり方や考え方を見つめ直しています。今回はAgile Journeyと関係のある8人の開発者に、エンジニアとして壁を乗り越え、アジャイルに取り組む契機になるような自分にとって大切な本を推薦してもらいました。 紹介する中には現在では入手の難しい本もありますが、機会があればぜひ手に取ってみてください。 アジャイルやXP・スクラムをどう実践すればいいのだろう？ アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣 アジャイルな見積もりと計画づくり 価値あるソフトウェアを育てる概念と技法 塹壕よりScr

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

2人のプログラマーが一体となってプログラミングを行うペアプロプラミング（以下、ペアプロ）は、XP（エクストリームプログラミング）の主要プラクティスの1つです。ユーザベースのスピーダ事業では、開発組織全体でペアプロを実践し、生産性や品質の向上につなげてきました。 2022年にはその効果を最大化するため、社内の有志で「よりよきペアプロのためのガイドライン」という1万文字以上のドキュメントを策定。ペアプロの実践や「ふりかえり」に役立てています。作成自体がアジャイルに進められたこのガイドラインは何をきっかけにまとめられ、どういった内容を含んでいるのでしょうか。 現場でのペアプロを推進してきたスピーダ事業執行役員CTOの林尚之さんと、ガイドライン策定にも参加した機械学習エンジニアの二木拓也さん、ソフトウェアエンジニアとして実践する中嶋淳さんにお聞きします。 分からないほうが積極的にドライバーを取りに

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

読者の皆さんには、手間暇かけて実装し、たくさんのケースでテストを実行し、やっとの思いでリリースした機能が顧客に受け入れられなかった経験はありませんか？ 開発チーム内で想定していた通りの機能を作ってリリースしたとしても、実際はユーザーに利用してもらえない事態になったとしたら、リリースした価値はないかもしれません。 もちろん、プロダクトがどのように利用されるかを、リリース前から全て想定できるわけではありません。そのため、リリース後にも継続的に確認することが大切です。 本記事では、Dan Ashby（@DanAshby04）が2016年に提唱した継続的テストモデル（Continuous Testing）の考え方を用いつつ、リリース後に行うシフトライトなテスト活動について解説していきます。 継続的テストモデルとシフトライトの活動について 小売りチェーン向けECシステムの店舗向けアプリで実践 ある機

新規プロダクト開発チームやスタートアップにおいて、アジャイルの経験を積んだエンジニアが初期メンバーにいれば自然と開発プロセスにアジャイルが取り入れられ、スムーズにプロダクト開発にフォーカスできることがあります。しかし開発組織が拡大して経験の浅いエンジニアが増えてくると、今度はアジャイルのマインドやプラクティスそのものの定着がしばしば課題となります。どうすれば組織が拡大してもアジャイルであり続けられるのか？ その実例や情報の共有はまだまだ足りていません。 ドメイン駆動設計（DDD）に関する情報発信でも知られるエンジニアの松岡幸一郎（@little_hand_s）さんは、そうした「組織を対象とした課題」の解決にフォーカスするため、システムコーチングという組織やチームに対するコーチング手法を取り入れました。個人に対するコーチングはかなり知られてきましたが、組織に対するコーチングについては耳慣れな

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

アジャイル開発の方法論やフレームワークはいくつかありますが、ユーザベースのスピーダ事業では執行役員CTOである林尚之さんの主導によりエクストリームプログラミング（XP: eXtreme Programming）を全面的に採用しています。2023年3月にはアジャイル関連書籍の共訳・監訳などで幅広く活動される角谷信太郎さんがエクストリームプログラミング顧問として就任し、エンジニア組織の向上に取り組んでいます。 当初は「いまどきXPで大丈夫か？」と半信半疑だった角谷さんですが、かなりの規模でXPを実践できていることに驚いたそうです。そんな角谷さんと林さんが、アジャイル開発を推進する上で大切なことは何か？ 拡大する開発組織全体をアジャイルに保ち続けるにはどうすればよいのか？ について正面から語り合いました。 ユーザベースがアジャイル開発を始めるきっかけ 最高のプロダクトというより「最高の開発チーム

アジャイルに興味を持った1人あるいは数人から始めることは、アジャイルの導入においてよくあるストーリーです。とはいえ昨今では、例えばスクラムを導入する開発チームも増えているでしょうし、ほかのメンバーが主導した取り組みとしてアジャイルを受け入れる方も多いでしょう。そんな経緯でスクラムに触れ、既存の開発プロセスとの違いに戸惑い、むしろ積極的にアジャイルを学ぶことで克服した過程を、岸田篤樹（パウリ）さんに寄稿いただきました。 Agile journeyをご覧のみなさま初めまして。株式会社ビットキーでEM（エンジニアリングマネージャー）・スクラムマスター・技術広報をしているパウリ（@pauli_agile）です。私は2015年に新卒でプログラマーとしてキャリアをスタートしました。 その頃の世の中ではすでに、アジャイル開発がさまざまな開発組織に浸透しつつある状況にあったかと思います。ただ、実際に配属さ

読者の皆さんは、テストについてどのようなイメージをお持ちでしょうか。「開発の後に行う確認作業」といったイメージを持たれている方もいるかと思います。 しかし、開発しようとしているソフトウェアに不具合の混入を防ぐには、もっと早い段階でテストについて考えることが必要です。こういったテスト活動は、プログラムを1文字も書いていないときから始めることができるのです。 本記事では、2016年に提唱された継続的テストモデルを紹介しつつ、アジャイルとも親和性のあるシフトレフトなテスト活動について解説していきます。 DevOpsにおけるテストの考え方 DevOpsのループ図とは何か？ 継続的テストモデルとは何か 継続的テストモデルにおいてテストは「活動」である シフトレフトなテスト活動とシフトライトなテスト活動 シフトレフトなテスト活動としてのテスト駆動開発 コード実装を始める前から行うテスト活動 シフトレフ

Agile Journeyをご覧のみなさん、こんにちは。コネヒト株式会社でプロダクトマネージャーをしている田中俊也です。 コネヒト株式会社は、「あなたの家族像が実現できる社会をつくる」というビジョンの実現に向けて、家族のライフイベントにおける意思決定をITの力でサポートしています。子育て支援アプリ・情報サイト「ママリ」の開発・運営を中心に、子育て包括支援や自治体および企業向けの産休・育休の取得支援を行っています。 私は元々エンジニアとしてアプリ「ママリ」の開発に携わっており、プロダクトマネージャーと共に、日々プロダクト開発やその改善について議論や勉強を行っていました。 そのような中、去年の7月に開催されたMobius Outcome Delivery研修のことを知ったのです。Mobius Outcome Deliveryの名は以前から知っていましたが、その詳細やプロダクト開発への具体的な活

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

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

ソフトウェア開発において、アジャイルという考え方はかなり浸透しています。多く出版物やWebコンテンツ、さまざまなコミュニティやセミナーが存在し、アジャイルの情報には触れやすい状況になってきました。一方で企業においてアジャイルを導入しようとする際に開発チームのどこを変えるべきか、組織固有のルールとどう折り合いを付けるかなどに頭を悩ませる方も多いでしょう。 『SCRUM BOOT CAMP THE BOOK』などの著作で知られ、アジャイルコーチとして企業の組織づくりを支援する永瀬美穂（@miholovesq）さんは、これまで複数の大学で授業におけるアジャイル導入も支援し、その成果を発表する「Agile PBL祭り」を主催してきました。永瀬さんによると、学生は前提知識もないところからソフトウェア開発を学ぶため、社会人エンジニアより自然とアジャイルに取り組める面もあるそうです。 大学はなぜ教育にア

「初！都庁職員、アジャイル型開発に参加する」 東京都デジタルサービス局デジタルサービス推進部の公式note（2023年1月公開）には、かつて“試みたことのない開発手法”であったアジャイル型開発を東京都が採り入れ、複数のソフトウェアを開発した経緯が綴られています。 これまでAgile Journeyでは、さまざまな組織、企業のアジャイル導入事例を紹介してきましたが、それぞれの組織がそれぞれのモチベーションを持ち、課題に向き合いながら、導入に取り組んできました。では、それが自治体の場合では？ 東京都がアジャイル型開発を導入し、運用していくための動機、準備、事業者との契約の方法、そして実践のありようを、東京都デジタルサービス局の石川秀之さん、下家昌美さんに聞きました。 コロナ禍で浮き彫りになった、「迅速」の重要性 「システムをアジャイル型開発で作ってみませんか」メールで呼びかけ、アジャイル型開発

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