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

by bayashi

Embed

Start on current slide

Slide 1

Slide 1 text

スタートアップにおけるアジャイルの実践について渋谷アジャイルカンファレンス 2026/07/04

Slide 2

Slide 2 text

自己紹介ばやし@bayashimura 医療系スタートアップでエンジニアリングマネージャー最近の趣味はストーリーが難解なゲームのシナリオを理解できず後でピクシブ百科事典で解説を読みながら寝落ちすること

Slide 3

Slide 3 text

まずは渋谷アジャイル2周年＆初カンファレンス開催おめでとうございます

Slide 4

Slide 4 text

とはいえキーノートを務めるのは初めてどんな話をしたらいいんだろうどういうことを期待してtrebyさんは俺にキーノートを依頼してきたんだ...

Slide 5

Slide 5 text

主催者(の中のtrebyさんの思い）の思いを汲み取るコミュニティとして様々なバックグラウンドの方に参加いただいている実情がありつつ、「生き残りに必死な環境」という表現を維持したのはコミュニティ立ち上げの想いを新たにしたい意思。 2026年GWに川越で渋谷アジャイルのふりかえりを行った #shibuyagile https://treby.hatenablog.com/entry/2026/05/11/233830

Slide 6

Slide 6 text

キーノートをやることになった経緯（想像） 1. RubyKaigiでtrebyさんkobaseさんえーちゃんとジンギスカン屋に行く 2. trebyさんが渋谷アジャイルのコンセプトに最近悩んでるんですよね的なことを言う 3. ベロベロに酔っ払ってた私が「スタートアップとアジャイルだから良いんだろうが！！」とtrebyさんにダル絡みする 4. キーノート依頼が来る

Slide 7

Slide 7 text

ベロベロに酔っ払ってましたが渋谷アジャイルのスタートアップ×アジャイルっていうコンセプトが好きなのは本心です

Slide 8

Slide 8 text

自分のキャリア一社目割と歴史ある大規模SIerでエンジニアやったり社内アジャイルコーチやったり二社目人材系スタートアップでエンジニアやったりEMやったり三社目医療系スタートアップでエンジニアやったりEMやったり

Slide 9

Slide 9 text

大企業とスタートアップのアジャイルの違い大企業とスタートアップの両方でアジャイルの実践や普及活動やった身としては大事なコアの部分は変わらないけど - 前提 - コンテキストが結構違うと感じている

Slide 10

Slide 10 text

ということで本題スタートアップにおけるアジャイルの実践について - スタートアップのコンテキスト - 起きがちなことや自分のやってきたこととかを話しますなお話の構成上スタートアップってこんな感じとかアジャイルってこんな感じって言いますけど、あくまで「自分が思う」が接頭辞につくってことだけ堪忍な

Slide 11

Slide 11 text

突然ですが、皆さん

Slide 12

Slide 12 text

アジャイル好き？

Slide 13

Slide 13 text

どこが好き？

Slide 14

Slide 14 text

アジャイルの好きなところ自分の好きな部分 - ビジネスとエンジニアリングを近づける取り組みである - テイラーイズムからの脱却を目指している

Slide 15

Slide 15 text

アジャイルの好きなところ自分の好きな部分 - ビジネスとエンジニアリングを近づける取り組みである - テイラーイズムからの脱却を目指している

Slide 16

Slide 16 text

ビジネスとエンジニアリングを近づける取り組み自分が初めて仕事でシステム開発をやったのは受託件ウォーターフォールその時のソフトウェア開発の印象 - 誰がどう使う機能なのかはわからない - 何故必要なのかを開発者が理解する必要はない文化 - すべての機能を決められた期日までに定義通りに作る作業 - 何が大事な機能とかはなく、すべてが揃っていることが重要 - (あとリリース前は必ず残業地獄になる）

Slide 17

Slide 17 text

ビジネスとエンジニアリングを近づける取り組みリリースした後も、無事に終わった安堵感があるだけでそれが誰かの役に立っているのかの実感はなかった

Slide 18

Slide 18 text

はじめてのアジャイルその後なんやかんやあってお客さんと一緒にアジャイルで開発をやることにその時感じた、アジャイルのここが凄い３選 - 受託ながらもお客さんとの一体感が凄い - お客さんのビジネスも理解ながら開発してる感が凄い - お客さん更にその先にいるユーザが満足してる感が凄い

Slide 19

Slide 19 text

スクラムガイドスクラムガイド2016 https://scrumguides.org/docs/scrumguide/v201 6/2016-Scrum-Guide-Japanese.pdf スクラム（名詞）：複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。

Slide 20

Slide 20 text

XP白本ビジネスや仕事も含めたコミュニティーのなかで、自分の居場所を見つけることだ。自己超越のプロセスのことだ。そのプロセスのなかで、開発者として最善を尽くすことだ。ビジネスのためになる優れたコードを書くことだ。エクストリームプログラミング Kent Beck (著), Cynthia Andres (著), 角征典 (翻訳)

Slide 21

Slide 21 text

ビジネスとエンジニアリングを近づける取り組みその後の事業会社経験も含めてアジャイルは決して「コードを効率的に量産する仕組み」でも「自分たちが満足するプロセスを追求する仕組み」でもなく価値やビジネスを追求するところがアジャイルの好きなところです

Slide 22

Slide 22 text

アジャイルの好きなところ自分の好きな部分 - ビジネスとエンジニアリングを近づける取り組みである - テイラーイズムからの脱却を目指している

Slide 23

Slide 23 text

テイラーイズムとはフレデリック・テイラーが提唱した「科学的管理法」に基づく考え方。主に製造現場における効率化を追求する ● 業務の細分化と標準化 ● 「計画（管理職）」と「実行（作業員）」の完全な分離 ● マニュアル通りの作業による生産性向上 ● 各動作にかかる時間をストップウォッチで計測し、標準的な時間を割り出す、「時間研究」という技法が有名

Slide 24

Slide 24 text

自分が過去感じてたテイラーイズム過去ソフトウェア開発をやっていた時に以下があった - 既に誰かが決めた計画で開発をしたり - 自分たちでやり方を決められなかったり - 現場から程遠い人が開発標準を定めたり納得感は薄く日々不満をいだいていた

Slide 25

Slide 25 text

テイラーイズムからの脱却アジャイルを実践する中で以下を学ぶ - 開発をする人が自分たちで計画し、やり方も含めて決める - 素晴らしいマニュアルを作って誰でも成果を出せる仕組みを作るより個人のモチベーションや熟達を重視する実際にやってみて複雑なソフトウェア開発をやる上で効率的だし合理的だなと感じた

Slide 26

Slide 26 text

Kent Beckもそう言ってるエクストリームプログラミング Kent Beck (著), Cynthia Andres (著), 角征典 (翻訳) ソフトウェア開発で問題となるのは、テイラー主義に伴う仕事の社会構造だ。テイラーが提唱した「時間・動作研究」の儀式や道具こそなくなっているが、我々は無意識にこの社会構造を継承しているのである。その社会構造は、ソフトウェア開発にまったく適していない。

Slide 27

Slide 27 text

ということでビジネスとエンジニアリングを近づけるアジャイルという考え方が開発者が自分達で計画して作業することを主張してるところがすごく好きです

Slide 28

Slide 28 text

スタートアップの説明

Slide 29

Slide 29 text

スタートアップとは

Slide 30

Slide 30 text

T2D3 主にSaaS系スタートアップ売上の成長目標売上3倍(Triple)を2回 2倍(Double)を3回５年で売上(正確にいうとARR)を72倍！

Slide 31

Slide 31 text

急激な成長を行うために自己資金だけでやってるとそんな急激に成長できないので、投資をしてもらって、その資金を元手に急拡大する資金を使って - 採用したり - 広告打ったり

Slide 32

Slide 32 text

スタートアップはずっと赤字基本的にスタートアップは赤字なので赤字額で、調達したお金をどんどん消費していくどれくらい赤字を出しているのかをバーンレート手元の資金で何か月持つかがランウェイと言う

Slide 33

Slide 33 text

その中で起こってること LinkedIn創業者リード・ホフマン「起業とは崖から飛び降り、落ちるまでに飛行機を組み立てるようなもの」 https://logmi.jp/knowledge_culture/speech/36430 私はよく例えとして、「起業とは崖から飛び降りて、落ちるまでに飛行機を組み立てるようなものだ」と言います。非常に困難で、基本的には死ぬのが前提だからこそ、勝ち残るために考えうる全てのチャンスをものにしなくてはいけないのです。

Slide 34

Slide 34 text

スタートアップの特徴 - 明確に期限が決まっている中でのビジネス成果を出さないといけない - 中途採用がほとんどでネームバリューもそんななかったりするので、やりたいことをやりに来てる人たちが来てる - 人数が少なく管理職も少ないため、全体的にフラットな関係性

Slide 35

Slide 35 text

アジャイルに向いてそう - 明確に期限が決まっている中でのビジネス成果を出さないといけない - みんながビジネスに向き合ってる - 中途採用がほとんどでネームバリューもそんななかったりするので、やりたいことをやりに来てる人たちが来てる - 自分で選択して仕事を選んでいる - 人数が少なく管理職も少ないため、全体的にフラットな関係性 - テイラーイズムはそんなに蔓延ってない（諸説あり）

Slide 36

Slide 36 text

ミドル〜アーリーシードシード一緒にアイディア考えてアイディアをどんどん作るアーリースケールするためにビジネスの要望に応え続けるミドル〜顧客を抱えながら競合との競争。市場が魅力的だと後発参入プレーヤーもわんさかスタートアップもフェーズごとに雰囲気は結構違うよ

Slide 37

Slide 37 text

ミドル〜アーリーシードシードカウボーイコーディングアーリー個人商店型ミドル〜個人商店崩壊、そして大規模WF ソフトウェア開発スタイルの変遷（BAD ENDルート）

Slide 38

Slide 38 text

片っ端から開発するぜシード: カウボーイコーディング - とりあえず思いついたもの必要なものをどんどん作っていく - レビュープロセスなんてものもなくて、作った端からリリースされる - 最初はドメインとしてもシンプルだし、コードも複雑さが低いため、このまま突っ走っても特に問題は起こらない

Slide 39

Slide 39 text

アーリー: 個人商店型チームではあるがチームメンバー同士のコラボレーションが存在せず、指示者とチームメンバーの一対一の関係のみがある開発スタイル指示者は多くの場合 - PdM - リーダー - マネージャなど、別ポジション、別ロールの人が担う元カウボーイメンバーメンバー

Slide 40

Slide 40 text

カウボーイから個人商店型になる理由シードのタイミングでモリモリ機能を作っていた人だけでは急激な事業の成長に追いつけなくなってくるその結果、正社員や業務委託を採用して開発する人を増やす（今は生成AIの台頭で結構状況変わってそう）仲間が欲しいぜ

Slide 41

Slide 41 text

カウボーイから個人商店型になる理由業務やコードに詳しいため自然と元々いた人が - 要件詰め - 設計 - コードレビューを一手に担うことになるどこかのタイミングで要件詰めや設計を委譲出来ればよいが、多くは指示者と実装者という構図のままずるずると進んでいくこの仕事お願いするぜ了解です。出来たら確認お願いします

Slide 42

Slide 42 text

カウボーイから個人商店型になる理由上記の構図のまま人を採用していくと１人の指示者と多数の作業者という個人商店型が自然と出来上がる元カウボーイメンバーメンバー大変なことになったぜ

Slide 43

Slide 43 text

ミドル: 個人商店の崩壊そして大規模WFへうまくチーム化ができなかった場合の到着点個人商店型で遅延や品質の問題が多発し「問題はリーダーのプロジェクトマネジメント力の低さにある」と結論自分の力が弱いせいで... ほんとごめんだぜ

Slide 44

Slide 44 text

ミドル: 個人商店の崩壊そして大規模WFへ結果、プロジェクト管理の専門職を採用作業者のスキルによらずクオリティを担保するための標準化やチェック機構がモリモリと作られていく（テイラーイズムが帰ってきた！）計画・管理は任せてください

Slide 45

Slide 45 text

それぞれのタイミングで我々は何ができるんだろうね - シード - カウボーイコーディング - アーリー - 個人商店型 - ミドル〜 - 個人商店の崩壊そして大規模WFへ

Slide 46

Slide 46 text

自分が過去やったこと - 個人商店からチームへ - 自律したチームをスケールする

Slide 47

Slide 47 text

個人商店からチーム形へ個人作業に閉じて仕事が出来る状況をできるだけなくし、チームが自分達でプロジェクトマネジメントできるように - バックログをひとつにする - 事前アサインからサインアップ - 締め切りを極力なくして、優先順位をコントロールできるようにする

Slide 48

Slide 48 text

自律したチームをスケールする複数チームが関わるような仕事も自律かつオーナーシップがあるチーム同士だとそんなひどいことにならない（コミュニケーション大変だけど）〇〇さんがすべてを把握してるから自分は指示された作業をやれば良い、という状況を極力排除これやらないとまずいですよねこれもやらないとまずいですね

Slide 49

Slide 49 text

ただそんなすんなりやり方が変わったわけでもなくやっぱり大事なのは信頼貯金

Slide 50

Slide 50 text

信頼貯金「引き継ぎできない！」から始まった私のスクラム - 川口恭伸の「はじめてのアジャイル」 https://agilejourney.uzabase.com/entry/2023/10/19/103000

Slide 51

Slide 51 text

スタートアップで信頼貯金を稼ぐコツ - 理不尽を受容する - 現状をリスペクトする - ビジネスに向きあう

Slide 52

Slide 52 text

理不尽を受容するどんなフェーズのスタートアップでも理不尽は多発する - キーマンが突然退職する - 法規制が変わった - 競合がすごいことしてくる - 売上が全然足りない

Slide 53

Slide 53 text

自分がやらないように気をつけてること - チームを守る - プロダクトを守るという言葉を盾に、自分たちが理不尽を引き受けなかった際の影響を一切考慮せず理不尽を拒絶することは控えてます

Slide 54

Slide 54 text

理不尽からチームは守られた、けど？ - 法規制に間に合わせられなくて、事業が大きなダメージを負いました - 他のチームが突貫でどうにかして危機を回避しました自チームや自プロダクトは守れたけどトータルで見た時にもっとひどいことになるかもふぅ… かすり傷で済んだ

Slide 55

Slide 55 text

理不尽を受容するどう理不尽を受容すると一番マシかを考えるそして自分のところで対応するのが一番マシな場合歯を食いしばってやる (可能であれば一人で向き合わずチームで向き合う)

Slide 56

Slide 56 text

理不尽をトリアージする一方以下のような理不尽は最初にトリアージしておいてます - コミュニケーションで解決出来る類のもの - バックログの一番下にスッと入れても問題にならなそうなもの

Slide 57

Slide 57 text

現状をリスペクトする今の自分から見たら「ひどい」と言いたくなるような現状 - バグだらけで読みづらいコード - 最悪の体験の機能でもそれって理不尽を受容した結果かもしれないその時の限られた面子でどうにかしようとした痕跡なのである

Slide 58

Slide 58 text

ノーム・カースの最優先事項今日見つけたものが何であれ、チームの全員が、その時点でわかっていたことやスキルおよび能力、利用可能なリソースを余すことなく使って、置かれた状況下でベストを尽くした、ということを疑ってはならないアート・オブ・アジャイルデベロップメント ―組織を成功に導くエクストリームプログラミングジェームズ・ショア (著), シェイン・ウォーデン (著), 木下史彦 (著)

Slide 59

Slide 59 text

よく見るやつ最近入ったハイスキルな人昔作られたやばいコアロジックこれはひどいコードだ。自分が当時いたら絶対こうは書かない

Slide 60

Slide 60 text

よく見るやつ最近入ったハイスキルな人昔作られたやばいコアロジックこれはひどいコードだ。自分が当時いたら絶対こうは書かないこのコードがビジネスを支えてくれてたからあなたが入りたいと思えるような会社になったのである

Slide 61

Slide 61 text

James Shoreも昔はそうだったってこの頃の私は、エレガントで保守性の高いコードを書くことを誇りにしていた。成功とは技術的卓越を意味していた。コードは優れているのに失敗してしまうプロジェクトもあった。完璧に遂行されたプロジェクトでさえ、ユーザからそっぽを向かれることもあった。アート・オブ・アジャイルデベロップメント ―組織を成功に導くエクストリームプログラミングジェームズ・ショア (著), シェイン・ウォーデン (著), 木下史彦 (著)

Slide 62

Slide 62 text

ビジネスに向き合う自分が携わっているビジネスの存在を忘れ、コードやプロセス、チームだけに注目していると「自分たちはうまくいってる！（けど、周囲からの評価は高くない）」という状態に陥る俺ら最高のチームだ！エンジニアステークホルダー

Slide 63

Slide 63 text

ちゃぶ台はひっくり返されるビジネスに向き合わず周囲からの評価を無視して好きにやってると - 自分たちの意見が通らなくなる - 意思決定の場から遠ざかる - 自由に出来ることが減っていくなど徐々に影響力が薄くなるようになっていくそして、最終的に信頼を損ねすぎると...

Slide 64

Slide 64 text

新機能の開発ですけど、エンジニアの皆さん忙しそうですし、私の知り合いの開発会社さんにお願いしますねステークホルダーエンジニアあ、はい（そんな忙しくないけどな）

Slide 65

Slide 65 text

次の案件ですが、この機能開発お願いしますステークホルダーエンジニアはい、期日までに仕上げますねなんか最近機能開発の要望来なくなったな... 外部パートナーの皆さん

Slide 66

Slide 66 text

次の案件ですが、この機能開発お願いしますステークホルダーエンジニアはい、期日までに仕上げますねなんか最近機能開発の依頼来なくなったな... 外部パートナーの皆さん開発要望が来るのも信頼のひとつですよね

Slide 67

Slide 67 text

Slide 68

Slide 68 text

James Shoreも昔はそうだったって私はようやく、自分のプロジェクトチームは、何十、何百、ときには何千の人たちからなる、もっと大きな生態系の一部なんだということに気づいた。ソフトウェアの価値はそれにかけたコストを上回る必要があった。成功とは組織に価値をもたらすことを意味していた。アート・オブ・アジャイルデベロップメント ―組織を成功に導くエクストリームプログラミングジェームズ・ショア (著), シェイン・ウォーデン (著), 木下史彦 (著)

Slide 69

Slide 69 text

ビジネスに向き合うエンジニアとして働いていると、日々向き合っているものプロセスやチームに、コードにどうしても注目してしまうのですが、アジャイルの好きなところはビジネスとエンジニアリングを近づけるところってことだけは忘れないように気をつけています

Slide 70

Slide 70 text

どれも難しいことであるここまで紹介した話はどれも難しい難しいものに向き合うには一人では限界がある。同じような課題を経験した人たちとの対話が助けになるし職場の外のコミュニティは、自分では気づけない視点を与えてくれる。

Slide 71

Slide 71 text

その課題は既に誰かが向き合ったことのある課題かもシードアーリーミドル〜 PMF辛い PMFはしたけどスケール辛いスケールはしたけど黒字化辛い

Slide 72

Slide 72 text

コミュニティ自分のコミュニティ初参加は2017年アジャイル・ディスカッション！！というコミュニティ渋谷アジャイルと同じく - OSTがメイン - オープンでゆるい雰囲気 https://agile-discussion.doorkeeper.jp/

Slide 73

Slide 73 text

コミュニティ大体月１くらいで開催されてたので、当時は毎回相談にいってましたそこで直接悩みが解決することもあったけどそこにいる人達の振る舞いから多くを学ばさせてもらった - オープンさ - 他者へのリスペクト - ビジネスへの向き合い方

Slide 74

Slide 74 text

コミュニティ以降アジャイルディスカッション以外のコミュニティにも顔を出し続け、ずっとこんな感じです仕事で悩む →コミュニティで相談したり学んだことを活かす →仕事でチャレンジ →(時々)知見をコミュニティに共有 →次の悩みにぶつかる（最初に戻る）

Slide 75

Slide 75 text

アジャイルが良いものだと思うならみんなで現場の難しい課題に向き合って信頼貯金稼いで大変な時はコミュニティで相談したりしながら自分が好きなアジャイルを実践していきましょう（信頼損ねすぎるとストップウォッチ持った人がくるよ）この後のLTとOST楽しみにしてます！計画・管理は任せてください

Slide 76

Slide 76 text

No content