スタートアップにおけるアジャイルの実践について #shibuyagile

渋谷アジャイルカンファレンスキーノートです
https://shibuyagile.connpass.com/event/392971/

Transcript

1. スタートアップにおける アジャイルの実践について 渋谷アジャイルカンファレンス 2026/07/04
2. 自己紹介 ばやし@bayashimura 医療系スタートアップで エンジニアリングマネージャー 最近の趣味は ストーリーが難解なゲームのシナリオ を理解できず後でピクシブ百科事典で 解説を読みながら寝落ちすること
3. まずは 渋谷アジャイル2周年 ＆ 初カンファレンス開催おめでとうございます
4. とはいえ キーノートを務めるのは初めて どんな話をしたらいいんだろう どういうことを期待してtrebyさんは俺にキーノートを依頼してきたんだ...
5. 主催者(の中のtrebyさんの思い）の思いを汲み取る コミュニティとして様々なバック グラウンドの方に参加いただいて いる実情がありつつ、「生き残り に必死な環境」という表現を維持 したのはコミュニティ立ち上げの 想いを新たにしたい意思。 2026年GWに川越で渋谷アジャイルのふりかえりを行った #shibuyagile https://treby.hatenablog.com/entry/2026/05/11/233830
6. キーノートをやることになった経緯（想像） 1. RubyKaigiでtrebyさんkobaseさん えーちゃんとジンギスカン屋に行く 2. trebyさんが渋谷アジャイルのコンセプトに 最近悩んでるんですよね的なことを言う 3. ベロベロに酔っ払ってた私が 「スタートアップとアジャイルだから良いん だろうが！！」 とtrebyさんにダル絡みする 4. キーノート依頼が来る
7. ベロベロに酔っ払ってましたが 渋谷アジャイルの スタートアップ×アジャイルっていう コンセプトが好きなのは本心です
8. 自分のキャリア 一社目 割と歴史ある大規模SIerでエンジニアやったり社内アジャイルコーチやったり 二社目 人材系スタートアップでエンジニアやったりEMやったり 三社目 医療系スタートアップでエンジニアやったりEMやったり
9. 大企業とスタートアップのアジャイルの違い 大企業とスタートアップの両方で アジャイルの実践や普及活動やった身としては 大事なコアの部分は変わらないけど - 前提 - コンテキスト が結構違うと感じている
10. ということで本題 スタートアップにおけるアジャイルの実践について - スタートアップのコンテキスト - 起きがちなことや自分のやってきたこと とかを話します なお話の構成上スタートアップってこんな感じとかアジャイルってこんな感じっ て言いますけど、あくまで「自分が思う」が接頭辞につくってことだけ堪忍な
11. 突然ですが、皆さん
12. アジャイル好き？
13. どこが好き？
14. アジャイルの好きなところ 自分の好きな部分 - ビジネスとエンジニアリングを近づける取り組みである - テイラーイズムからの脱却を目指している
15. アジャイルの好きなところ 自分の好きな部分 - ビジネスとエンジニアリングを近づける取り組みである - テイラーイズムからの脱却を目指している
16. ビジネスとエンジニアリングを近づける取り組み 自分が初めて仕事でシステム開発をやったのは受託件ウォーターフォール その時のソフトウェア開発の印象 - 誰がどう使う機能なのかはわからない - 何故必要なのかを開発者が理解する必要はない文化 - すべての機能を決められた期日までに定義通りに作る作業 - 何が大事な機能とかはなく、すべてが揃っていることが重要 - (あとリリース前は必ず残業地獄になる）
17. ビジネスとエンジニアリングを近づける取り組み リリースした後も、 無事に終わった安堵感があるだけで それが誰かの役に立っているのかの 実感はなかった
18. はじめてのアジャイル その後なんやかんやあってお客さんと一緒にアジャイルで開発をやることに その時感じた、アジャイルのここが凄い ３選 - 受託ながらもお客さんとの一体感が凄い - お客さんのビジネスも理解ながら開発してる感が凄い - お客さん更にその先にいるユーザが満足してる感が凄い
19. スクラムガイド スクラムガイド2016 https://scrumguides.org/docs/scrumguide/v201 6/2016-Scrum-Guide-Japanese.pdf スクラム（名詞）：複雑で変化の 激しい問題に対応するためのフ レームワークであり、可能な限り 価値の高いプロダクト を生産的か つ創造的に届けるためのものであ る。
20. XP白本 ビジネスや仕事も含めたコミュニ ティーのなかで、自分の居場所を 見つけることだ。自己超越のプロ セスのことだ。そのプロセスのな かで、開発者として最善を尽くす ことだ。ビジネスのためになる優 れたコードを書くことだ 。 エクストリームプログラミング Kent Beck (著), Cynthia Andres (著), 角 征典 (翻訳)
21. ビジネスとエンジニアリングを近づける取り組み その後の事業会社経験も含めてアジャイルは決して 「コードを効率的に量産する仕組み」でも 「自分たちが満足するプロセスを追求する仕組み」でもなく 価値やビジネスを追求するところ がアジャイルの好きなところです
22. アジャイルの好きなところ 自分の好きな部分 - ビジネスとエンジニアリングを近づける取り組みである - テイラーイズムからの脱却を目指している
23. テイラーイズムとは フレデリック・テイラーが提唱した「科学的管理 法」に基づく考え方。主に製造現場における効率 化を追求する • 業務の細分化と標準化 • 「計画（管理職）」と「実行（作業員）」の 完全な分離 • マニュアル通りの作業による生産性向上 • 各動作にかかる時間をストップウォッチで計 測し、標準的な時間を割り出す、「時間研 究」という技法が有名
24. 自分が過去感じてたテイラーイズム 過去ソフトウェア開発をやっていた時に以下があった - 既に誰かが決めた計画で開発をしたり - 自分たちでやり方を決められなかったり - 現場から程遠い人が開発標準を定めたり 納得感は薄く日々不満をいだいていた
25. テイラーイズムからの脱却 アジャイルを実践する中で以下を学ぶ - 開発をする人が自分たちで計画し、やり方も含めて決める - 素晴らしいマニュアルを作って誰でも成果を出せる仕組みを作るより 個人のモチベーションや熟達を重視する 実際にやってみて複雑なソフトウェア開発をやる上で 効率的だし合理的だなと感じた
26. Kent Beckもそう言ってる エクストリームプログラミング Kent Beck (著), Cynthia Andres (著), 角 征典 (翻訳) ソフトウェア開発で問題となるの は、テイラー主義に伴う仕事の社 会構造だ。テイラーが提唱した 「時間・動作研究」の儀式や道具 こそなくなっているが、我々は無 意識にこの社会構造を継承してい るのである。その社会構造は、ソ フトウェア開発にまったく適して いない。
27. ということで ビジネスとエンジニアリングを近づけるアジャイルという考え方が 開発者が自分達で計画して作業することを 主張してるところがすごく好きです
28. スタートアップの説明
29. スタートアップとは
30. T2D3 主にSaaS系スタートアップ売上の成長目標 売上3倍(Triple)を2回 2倍(Double)を3回 ５年で売上(正確にいうとARR)を72倍！
31. 急激な成長を行うために 自己資金だけでやってるとそんな急激に成長できないので、 投資をしてもらって、その資金を元手に急拡大する 資金を使って - 採用したり - 広告打ったり
32. スタートアップはずっと赤字 基本的にスタートアップは赤字なので 赤字額で、調達したお金をどんどん消費していく どれくらい赤字を出しているのかをバーンレート 手元の資金で何か月持つかがランウェイ と言う
33. その中で起こってること LinkedIn創業者リード・ホフマン「起業とは崖から飛び降り、落ち るまでに飛行機を組み立てるようなもの」 https://logmi.jp/knowledge_culture/speech/36430 私はよく例えとして、「起業とは崖 から飛び降りて、落ちるまでに飛行 機を組み立てるようなものだ」と言 います。非常に困難で、基本的には 死ぬのが前提だからこそ、勝ち残る ために考えうる全てのチャンスをも のにしなくてはいけないのです。
34. スタートアップの特徴 - 明確に期限が決まっている中でのビジネス成果を出さないといけない - 中途採用がほとんどでネームバリューもそんななかったりするので、やりた いことをやりに来てる人たちが来てる - 人数が少なく管理職も少ないため、全体的にフラットな関係性
35. アジャイルに向いてそう - 明確に期限が決まっている中でのビジネス成果を出さないといけない - みんながビジネスに向き合ってる - 中途採用がほとんどでネームバリューもそんななかったりするので、やりた いことをやりに来てる人たちが来てる - 自分で選択して仕事を選んでいる - 人数が少なく管理職も少ないため、全体的にフラットな関係性 - テイラーイズムはそんなに蔓延ってない（諸説あり）
36. ミドル〜 アーリー シード シード 一緒にアイディア考えてアイディ アをどんどん作る アーリー スケールするためにビジネスの要 望に応え続ける ミドル〜 顧客を抱えながら競合との競争。 市場が魅力的だと後発参入プレー ヤーもわんさか スタートアップもフェーズごとに雰囲気は結構違うよ
37. ミドル〜 アーリー シード シード カウボーイコーディング アーリー 個人商店型 ミドル〜 個人商店崩壊、そして大規模WF ソフトウェア開発スタイルの変遷（BAD ENDルート）
38. 片っ端から開発するぜ シード: カウボーイコーディング - とりあえず思いついたもの必要なものをど んどん作っていく - レビュープロセスなんてものもなくて、 作った端からリリースされる - 最初はドメインとしてもシンプルだし、 コードも複雑さが低いため、このまま突っ 走っても特に問題は起こらない
39. アーリー: 個人商店型 チームではあるがチームメンバー同士のコラボ レーションが存在せず、指示者とチームメン バーの一対一の関係のみがある開発スタイル 指示者は多くの場合 - PdM - リーダー - マネージャ など、別ポジション、別ロールの人が担う 元カウ ボーイ メンバー メンバー
40. カウボーイから個人商店型になる理由 シードのタイミングでモリモリ機能を作っていた 人だけでは急激な事業の成長に追いつけなくなっ てくる その結果、正社員や業務委託を採用して開発する 人を増やす（今は生成AIの台頭で結構状況変わっ てそう） 仲間が欲しいぜ
41. カウボーイから個人商店型になる理由 業務やコードに詳しいため自然と元々いた人が - 要件詰め - 設計 - コードレビュー を一手に担うことになる どこかのタイミングで要件詰めや設計を委譲出来 ればよいが、多くは指示者と実装者という構図の ままずるずると進んでいく この仕事お願いするぜ 了解です。出来たら 確認お願いします
42. カウボーイから個人商店型になる理由 上記の構図のまま人を採用していくと １人の指示者と多数の作業者という個人商店型 が自然と出来上がる 元カウ ボーイ メンバー メンバー 大変なことになったぜ
43. ミドル: 個人商店の崩壊そして大規模WFへ うまくチーム化ができなかった場合の到着点 個人商店型で遅延や品質の問題が多発し 「問題はリーダーのプロジェクトマネジメント力 の低さにある」と結論 自分の力が弱い せいで... ほんとごめんだ ぜ
44. ミドル: 個人商店の崩壊そして大規模WFへ 結果、プロジェクト管理の専門職を採用 作業者のスキルによらずクオリティを担保するた めの標準化やチェック機構がモリモリと作られて いく（テイラーイズムが帰ってきた！） 計画・管理は 任せてください
45. それぞれのタイミングで我々は何ができるんだろうね - シード - カウボーイコーディング - アーリー - 個人商店型 - ミドル〜 - 個人商店の崩壊そして大規模WFへ
46. 自分が過去やったこと - 個人商店からチームへ - 自律したチームをスケールする
47. 個人商店からチーム形へ 個人作業に閉じて仕事が出来る状況をできるだけな くし、チームが自分達でプロジェクトマネジメント できるように - バックログをひとつにする - 事前アサインからサインアップ - 締め切りを極力なくして、優先順位をコント ロールできるようにする
48. 自律したチームをスケールする 複数チームが関わるような仕事も自律かつオーナー シップがあるチーム同士だとそんなひどいことにな らない （コミュニケーション大変だけど） 〇〇さんがすべてを把握してるから自分は指示され た作業をやれば良い、という状況を極力排除 これやらないと まずいですよね これもやらないと まずいですね
49. ただそんなすんなりやり方が変わったわけでもなく やっぱり大事なのは 信頼貯金
50. 信頼貯金 「引き継ぎできない！」から始まった私のスクラム - 川口恭伸の「はじめてのアジャイル」 https://agilejourney.uzabase.com/entry/2023/10/19/103000
51. スタートアップで信頼貯金を稼ぐコツ - 理不尽を受容する - 現状をリスペクトする - ビジネスに向きあう
52. 理不尽を受容する どんなフェーズのスタートアップでも理不尽は多発する - キーマンが突然退職する - 法規制が変わった - 競合がすごいことしてくる - 売上が全然足りない
53. 自分がやらないように気をつけてること - チームを守る - プロダクトを守る という言葉を盾に、 自分たちが理不尽を引き受けなかった際の影響を一 切考慮せず 理不尽を拒絶することは控えてます
54. 理不尽からチームは守られた、けど？ - 法規制に間に合わせられなくて、 事業が大きなダメージを負いました - 他のチームが突貫でどうにかして 危機を回避しました 自チームや自プロダクトは守れたけど トータルで見た時にもっとひどいことになるかも ふぅ… かすり傷 で済んだ
55. 理不尽を受容する どう理不尽を受容すると一番マシかを考える そして自分のところで対応するのが一番マシな場合 歯を食いしばってやる (可能であれば一人で向き合わずチームで向き合う)
56. 理不尽をトリアージする 一方以下のような理不尽は 最初にトリアージしておいてます - コミュニケーションで解決出来る類のもの - バックログの一番下にスッと入れても 問題にならなそうなもの
57. 現状をリスペクトする 今の自分から見たら「ひどい」と言いたく なるような現状 - バグだらけで読みづらいコード - 最悪の体験の機能 でもそれって理不尽を受容した結果かもし れない その時の限られた面子でどうにかしようと した痕跡なのである
58. ノーム・カースの最優先事項 今日見つけたものが何であれ、チー ムの全員が、その時点でわかってい たことやスキルおよび能力、利用可 能なリソースを余すことなく使っ て、置かれた状況下でベストを尽く した、ということを疑ってはならな い アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング ジェームズ・ショア (著), シェイン・ウォーデン (著), 木下史彦 (著)
59. よく見るやつ 最近入った ハイスキルな人 昔作られたやばい コアロジック これはひどいコード だ。自分が当時いたら 絶対こうは書かない
60. よく見るやつ 最近入った ハイスキルな人 昔作られたやばい コアロジック これはひどいコード だ。自分が当時いたら 絶対こうは書かない このコードがビジネスを支えてくれてたから あなたが入りたいと思えるような会社になったのである
61. James Shoreも昔はそうだったって この頃の私は、エレガントで保守性 の高いコードを書くことを誇りにし ていた。成功とは技術的卓越を意味 していた。コードは優れているのに 失敗してしまうプロジェクトもあっ た。完璧に遂行されたプロジェクト でさえ、ユーザからそっぽを向かれ ることもあった。 アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング ジェームズ・ショア (著), シェイン・ウォーデン (著), 木下史彦 (著)
62. ビジネスに向き合う 自分が携わっているビジネスの存在を忘れ、 コードやプロセス、チームだけに注目していると 「自分たちはうまくいってる！ （けど、周囲からの評価は高くない）」 という状態に陥る 俺ら最高のチームだ！ エンジニア ステークホルダー
63. ちゃぶ台はひっくり返される ビジネスに向き合わず 周囲からの評価を無視して好きにやってると - 自分たちの意見が通らなくなる - 意思決定の場から遠ざかる - 自由に出来ることが減っていく など徐々に影響力が薄くなるようになっていく そして、最終的に信頼を損ねすぎると...
64. 新機能の開発ですけど、 エンジニアの皆さん忙し そうですし、私の知り合 いの開発会社さんにお願 いしますね ステークホルダー エンジニア あ、はい （そんな忙しく ないけどな）
65. 次の案件ですが、この機 能開発お願いします ステークホルダー エンジニア はい、期日まで に仕上げますね なんか最近 機能開発の要望 来なくなったな... 外部パートナーの皆さん
66. 次の案件ですが、この機 能開発お願いします ステークホルダー エンジニア はい、期日まで に仕上げますね なんか最近 機能開発の依頼 来なくなったな... 外部パートナーの皆さん 開発要望が来るのも信頼のひとつですよね
67. James Shoreも昔はそうだったって この頃の私は、エレガントで保守性 の高いコードを書くことを誇りにし ていた。成功とは技術的卓越を意味 していた。コードは優れているのに 失敗してしまうプロジェクトもあっ た。完璧に遂行されたプロジェクト でさえ、ユーザからそっぽを向かれ ることもあった。 アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング ジェームズ・ショア (著), シェイン・ウォーデン (著), 木下史彦 (著)
68. James Shoreも昔はそうだったって 私はようやく、自分のプロジェクト チームは、何十、何百、ときには何 千の人たちからなる、もっと大きな 生態系の一部なんだということに気 づいた。ソフトウェアの価値はそれ にかけたコストを上回る必要があっ た。成功とは組織に価値をもたら すことを意味していた。 アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング ジェームズ・ショア (著), シェイン・ウォーデン (著), 木下史彦 (著)
69. ビジネスに向き合う エンジニアとして働いていると、日々向き合っている ものプロセスやチームに、コードにどうしても注目し てしまうのですが、 アジャイルの好きなところは ビジネスとエンジニアリングを近づけるところ ってことだけは忘れないように気をつけています
70. どれも難しいことである ここまで紹介した話はどれも難しい 難しいものに向き合うには一人では限界がある。 同じような課題を経験した人たちとの対話が助けになるし 職場の外のコミュニティは、自分では気づけない視点を与えてくれる。
71. その課題は既に誰かが向き合ったことのある課題かも シード アーリー ミドル〜 PMF辛い PMFはしたけどス ケール辛い スケールはしたけ ど黒字化辛い
72. コミュニティ 自分のコミュニティ初参加は2017年 アジャイル・ディスカッション！！というコミュニティ 渋谷アジャイルと同じく - OSTがメイン - オープンでゆるい雰囲気 https://agile-discussion.doorkeeper.jp/
73. コミュニティ 大体月１くらいで開催されてたので、 当時は毎回相談にいってました そこで直接悩みが解決することもあったけど そこにいる人達の振る舞いから多くを学ばさせて もらった - オープンさ - 他者へのリスペクト - ビジネスへの向き合い方
74. コミュニティ 以降アジャイルディスカッション以外のコミュニ ティにも顔を出し続け、ずっとこんな感じです 仕事で悩む →コミュニティで相談したり学んだことを活かす →仕事でチャレンジ →(時々)知見をコミュニティに共有 →次の悩みにぶつかる（最初に戻る）
75. アジャイルが良いものだと思うなら みんなで現場の難しい課題に向き合って 信頼貯金稼いで 大変な時はコミュニティで相談したりしながら 自分が好きなアジャイルを実践していきましょう （信頼損ねすぎるとストップウォッチ持った人がく るよ） この後のLTとOST楽しみにしてます！ 計画・管理は 任せてください