高いアジリティを持ってプロダクト開発を進めなければ、事業が立ち行かなくなるリスクをはらむスタートアップ。先が見えない状況下でも変化に即対応しつつ、ユーザーに価値を提供するには、どのように開発を進めていけば良いのでしょうか。
今回は、「ソフトウェア開発を行うスタートアップ」というスコープで、スタートアップの現場で日々この課題に向き合う面々が、それぞれの立場からアジリティのあり方を探る対談を行いました。ご登場いただいたのは、コミュニティ「Startup in Agile」を共に主宰する永山大輔さん（じゃがさん、@jagaimogmog）と新多真琴さん（あらたまさん、@ar_tama）、そして、同コミュニティで登壇されメディカルフォースでCEOを務める畠中翔一さん（@punk_punx）。
スタートアップという状況で起きやすい問題や、その対処法が浮かび上がってきました。
- 三者三様のスタートアップ開発現場
- 事業フェーズによってアジリティの出し方は変わる
- 「慢性息切れ問題」には、サイクル高速化とWhyの共有で対処
- 「0→1」フェーズの進め方では、いつか行き詰まる
- 「手段の目的化」に陥っていないか
- 意外と後回しになりがちな「メンバーへの興味」
- 経験主義だからこそ、正解はない
- 合わせて読みたい注目記事
三者三様のスタートアップ開発現場
── 皆さんはスタートアップでどのような開発に携わっているのでしょうか。
永山（以下、じゃが） Nstockでソフトウェアエンジニアをしています。新卒で入ったAWSでスタートアップ技術支援を行ううちに「自分もスタートアップで働きたい」という思いが強くなり、創業して間もない頃のNstockに入りました。
Nstockは「スタートアップエコシステムをブーストし、日本からGoogle級の会社を生み出す」をミッションに、事業を展開しています。僕は株式報酬のSaaS開発に立ち上げから参画していて、チームでは現在はスクラムから「Shape Up*1」に切り替えて開発を行っています。
新多（以下、あらたま） 私は新卒でDeNAに入り、その後何回か転職をしていますが、スタートアップでの経験が一番長いです。
現在はLayerXに所属し、「バクラク申請・経費精算」というプロダクトの開発チームでEM（エンジニアリングマネージャー）をしています。バクラクは法人バックオフィス向けのAI SaaSのシリーズで、現在8つのプロダクトを提供しています。プロダクトの開発チームは、エンジニア・PdM・デザイナー・QAエンジニアの混成チームが基本構成で、それぞれがスクラムを実践しています。
畠中 学生時代に創業したメディカルフォースでCEOをしています。創業時はCTOとして、クラウド型電子カルテ「medicalforce」の開発やPdMを担当し、現在は警備事業者向けのSaaS「警備フォース」の開発にも携わっています。
全社で「Scrum@Scale*2」を取り入れていて、開発サイドもビジネスサイドも全てスクラム。基本的に1〜2週間のスプリントで回っています。
事業フェーズによってアジリティの出し方は変わる
── 早速ですが、スタートアップでアジリティを出すポイントはどんなところにあると思いますか？
あらたま トップダウンの方がアジリティが出るフェーズと、ボトムアップで自走してもらった方がアジリティが出るフェーズがあると思います。
例えば、前職では私がプランニングを全てやっていた時期がありました。プロダクト開発でPO（プロダクトオーナー）が別にいる場合、エンジニアに求められる姿勢は、「なぜやるのか、何をやるのかを理解して、その上でどうやるかに責任を持つ」ことだと思っていて。それをメンバーに身に付けてもらうことを目的に、最初のフェーズだけトップダウンのような回し方をしていました。
どういう理由でタスクの順番を入れ替えるのか、どういうコミュニケーションを他部署と取っているのか。判断軸をチームで共有できるようにした上で、優先順位に関する意見をメンバーからも吸い上げられるようにしていく。チームのコミュニーケーションを醸成していく最初の一歩として、そういうやり方が最適なタイミングもあるなと思います。
じゃが すごく理解できます。誰かが意思決定の比重を大きく持っているから、エンジニアが迷いなく開発を進められるところがありますよね。そう考えると、僕たちは逆にフラットな組織だったので、初期フェーズでチームが意思決定するまで時間がかかってしまったんだろうなと思います。
── 具体的にはどんな状況だったんですか？
じゃが チームには初期段階からエンジニアが3人いたんですけど、それぞれ並列に「適当にバックログを取ってとりあえず開発をする」時期があって……。その時はカオスな状況で、PdMの意図は反映できていないし、みんなの進捗も分からなかった。
チーム全体の成長に十分な時間を投資できる状況であれば、みんなの価値観が揃い、同じ方向を向くことで開発スピードを上げられるでしょう。でもスタートアップのように「放っておいたら3カ月で会社が立ち行かなくなる」といった状況だとそんな余裕はないじゃないですか。
畠中 そうですよね。僕たちもいろいろなフェーズがありましたが、やっぱり初期フェーズは「何が何でもとりあえず終わらせる」状況でした。手が空いた人が他の人を手伝って、なんとかリリースまでこぎつける。開発をきれいに回すより、とにかくベロシティを高めてカバーしていく感じでした。
あらたま よく「自律性が大事」とは言うけれど、みんなのコンテキストを100%そろえられるわけじゃないから、「何のコンテキストが意思決定に重要なんだっけ？」の感覚がそれぞれ違うまま話が進むと、スタートアップの場合、かえって時間がかかることもあるんですよね。
「慢性息切れ問題」には、サイクル高速化とWhyの共有で対処
── 反対に、アジリティを損なってしまったケースはありますか？
あらたま 「慢性息切れ問題」というのがありました。
私たちはだいたい2週間に1回の定期リリースで動いていて、本番にデプロイする手前にコードフリーズの期間（開発中のコードに対する変更を一時的に禁止する期間）を3日間設けています。
「自分が作ったものが正しく動くか」はセルフチェックしているのですが、コードベースが複雑だったり、初めて触る機能だったりすると「他の機能に影響を与えていないか」の確認までうまく回らなくて。いざステージングに出したら「あの機能もこの機能も壊れている」となり、あわてて突貫で直して、またバグが出て……ということが起きていました。
本来、コードフリーズの期間は次のバッチの仕込みに当てるのが理想です。ところが不具合修正対応ばかりに時間がかかり、次の開発の期間が短くなって、その分、検証がおざなりになってつらくなる……という状態に陥ってしまった。それが「慢性息切れ問題」です。
── どう解決したんですか？
あらたま 「手戻りが発生している状態」に着目しました。変更をステージング環境に出して初めてフィードバックを得るのではサイクルが長過ぎるので、開発中の早い段階でみんなに触ってもらう取り組みを考えました。
あとは、そもそもの開発をうまくできるようになる必要がありました。「うまい開発」の究極形は「作り始める前にどこに罠があるか」が分かっていて、その罠を踏まないように進むことだと思います。そこで、開発に着手する前に影響範囲を把握するステップを挟みました。
具体的にはスプリントバックログのフォーマットを決めて、「この機能で何を解決したいのか（Why）」と「解決をするために何をするのか（What）」を書くようにしました。バグフィックスでは「直さなきゃ」とコードの方に走っていきがちですが、一度立ち止まってスプリントバックログを書くプロセスを採用したことで、「ここに手を入れるんだったら、こっちにも影響があるかもしれない」と考えるタイミングを作れたと思います。
「Why」を書くのって、実は結構難しい作業で、「POがこう言っていたから」はみんな分かるけど、そこからさらに踏み込んで考えるには習熟度が必要です。それを鍛えるエクササイズにもなりました。
そうやって検証観点を書いてQAにレビューしてもらうことで、開発中からフィードバックが回り始め、サイクルを短縮できたと思います。
畠中 以前の僕たちと全く同じ状況です。手戻りが多くなると悪循環にハマってしまうので、僕たちの場合は開発したものを30分くらいビジネスサイドに見せる時間をつくったり、デイリースクラムで作っているものをPOにチェックしてもらったりといった「プレ・スプリントレビュー」を取り入れています。つまり、正式なスプリントレビューの前に開発途中の成果物を共有し、早期にフィードバックを得る場ですね。
そして、開発の初期段階、プランニングのための準備として「リファインメント（スクラムにおいてプロダクトバックログの内容を詳細化する作業）」が非常に重要だと考えています。僕たちは「そもそも何をやるのか」というプランニングをきちんとするために、このフェーズで「Why（なぜやるのか）、What（何をするのか）、How（どうやるのか）」について合意するようにしています。特に「Why」の合意を重視し、ストーリーの優先順位を決める中で「これはやらなくていいのでは？」と判断し、ストーリー自体がなくなることもあります。この事前の合意形成が、手戻りの少ない好循環を生むんです。
「0→1」フェーズの進め方では、いつか行き詰まる
畠中 余裕は一度なくなるとどんどんなくなっていくんですけど、逆に一度余裕が生まれればどんどん楽になっていくなと実感しています。ただ、「悪循環を断ち切って好循環に戻す」のは、すごく大変じゃないですか。お二人はどうしていますか？
じゃが まずは「悪循環に気付く」ことですよね。余裕がないことに気付ければ、開発スピードを緩めたり、開発の遅れやバグの温床になっている箇所を改善するための技術投資をしたりといった判断ができます。その際、状況の深刻さをビジネスサイドに理解してもらえると、余裕を取り戻すための活動に着手しやすいのかなと思います。そのためには、やはり定期的なふりかえりが大切ですね。
畠中 そうですね。ビジネスサイドが状況を把握して、みんなが納得できる状態に戻すのは確かに不可欠です。一度立ち止まると、2カ月のスパンで見れば開発できる機能は減るけど、1年のスパンで見れば増えるでしょうしね。
あらたま 短期的な改善のためのふりかえりなのか、中長期的な改善のためのふりかえりなのかを明確にするのは本当に大事ですね。
じゃが スタートアップの初期「0→1」のフェーズ（新規事業立ち上げ期）では数カ月後、あるいは数週間後に目がいきがちですが、その短期目線の進め方のままだと「1→10」フェーズ（事業立ち上げ後の拡大期）では中長期の課題に対応しきれず、行き詰まってしまいます。
畠中 最初からスプリントバックログを整備しておくことは重要だと思います。スタートアップの初期はユーザーニーズに応じて個別対応することが多いですが、クライアントが50社を超える頃から対応がハード過ぎて、エンジニアの表情が変わってしまう。
だからこそバックログを整備して、優先順位をどうやって決めるのか、合意をとっておく。「ユーザーに言われた順番通りにやる」「インパクトが大きいところからやる」など、なにかしらの軸を持っておくといいと思います。
じゃが 「0→1」のフェーズはどんどん作っていけばいいけど、その後のタイミングでは既存機能に関する改善要望もたくさん出てくる。「新機能開発と機能改善、どっちを優先するんだっけ？」っていう話はよく聞きますが、現場が迷わず進める仕組みになっているといいと思います。
「手段の目的化」に陥っていないか
── 他に「これは気をつけた方がいい」と感じるスタートアップ開発の落とし穴はありますか？
畠中 僕たちは大規模スクラムを導入していますが、「なんちゃってスクラム」になると悪循環に陥りやすいと思っています。結局はスクラムイベントをちゃんとやることが大事だと考えています。特にビジネスサイドにはイベントを飛ばそうとする人が多いので、「絶対飛ばさないでください」と言い続けています。
あらたま そうですね。あとは、まさに今の話にも通じますが、手段が目的化してしまうこともありますね。まず、達成したいゴールや提供すべき価値がある。それを実現するためにアジャイルという考え方や、スクラムという「How」があるはずです。この基本を忘れ、「スクラムのイベントはこなしている」けれど、生み出したかった価値がおろそかになってしまうのは、ままある状況だと思います。
「自分たちはスクラムだからうまくいっている」「スクラムが自分たちのカルチャー」など、手段をアイデンティティ化させずに、手段以上に「提供価値こそが重要」という考え方が失われないように気をつけていますね。
じゃが 僕は自分たちにとっての当たり前を壊すタイミングは、事業やチームに変化が起こる時だと思っています。
例えば、「こうしたら？」の声を大事にする。実際、過去にリファインメントを軽くした時は、新しく入ってきた人たちが「もっとプロセスを軽くしても回るんじゃないか」と声を上げてくれたのがきっかけだったんですよ。チームの流動性を高めて、新陳代謝が起こる状態を一定間隔で作るのは大事だなと思います。
あらたま 最初にじゃがさんから「スクラムからShape Upに変えた」という話がありましたけど、それも会社のフェーズが変わったからですよね？
じゃが そうですね。「0→1」が終わり、プロダクトがユーザーに受け入れられると分かったタイミングでフレームワークを変えました。
価値提供の方向性や改善箇所が見えてきた時に、個別のプロダクトバックログを整理し続けるコストより、大きく何にリソースを張るか方針を決めて、中身の細かいところは個人に任せた方がうまく進むんじゃないか。もっと長いスパンで開発をした方がメンバーの実力を生かせるんじゃないか。そういった背景からShape Upに変わっていきましたね。
最近はリファインメントも厳密にはしていなくて、「何をどういう理由でやるか」だけ決めて、詳細はエンジニアとPdMとデザイナーがアドホックに相談して決める場面が増えてきました。
それはチームとしての価値観が共有されてきたことと、スタートアップとして安定した状況になってきたことが影響している気がします。一人一人に任せて、方向性が一時的にずれたとしても修正しきれる体力がついてきたのかなと思いますね。
── より効率的かつ柔軟な手法を見出したわけですね。
じゃが はい。一気にやらないと事業が立ち行かなくなる状況を脱した後のフェーズでは、今のやり方の方が合っているなと思います。
意外と後回しになりがちな「メンバーへの興味」
あらたま スタートアップ特有の落とし穴として「人への関心」もあると感じています。
特に立ち上げフェーズの場合、「同じミッションの下に集まった濃い価値観を共有できている仲間」といった感覚が先に来て、意外と個人への興味が後回しになりませんか？ だからちょっとしたすれ違いが増えてきたときに「あの人のこと全然知らなかった……」と気付いて愕然としてしまう。
じゃが 「同じ価値観を持っていると思ってたのに、なぜ齟齬が生まれるんだ」って、勝手にショックを受けて。でも、実は単に相手のことを知らないだけなんですよね。
あらたま 私はマネージャーとして、できるだけ素朴な意見を言える状態をつくりたいと思っているんですけど、その手前で「お互いがどういう人なのか」理解できていることが大切だと考えていて。それがないと無用な遠慮を生んだり、無意識にやっていることの裏の意図を探ったりしてしまいます。
みんながうまく回っているような顔をしている中、「やばい」と思ったことを善意で引っ込めちゃうシーンは結構あると感じます。でも、「フォントサイズが違うけど、大局に影響ないしいいか」と流すよりも、「サイズがそろっていない」と伝えた上で、今直すか・今後修正するかを決めた方が絶対にいいじゃないですか。
それが言えると、自分たちの開発サイクルをうまく回せていないときに「隣のチームに聞きに行こう」といった、改善するためのネクストアクションも自然に決まっていくんです。お互いに「できてないじゃん」と断罪し合って終わらないためにも、みんなが前を向けるような土壌を耕しておくことが大事だなと思います。
じゃが お互いが考えていることをざっくばらんに話せる関係性は本当に大事で、そのためには仲良くなっておくことが必要なんでしょうね。
自分たちの会社は年に2回合宿をしているんですけど、仕事の話は3〜4時間で、あとはずっと遊んでいるんですよ。その時間が普段の人への頼りやすさや自己開示につながっていると思います。
僕は「アジャイルソフトウェア開発宣言」の中の、「プロセスやツールよりも個人と対話を」が大好きで。自分が抱えてるモヤモヤや不満を共有するだけで相手との距離は近くなり、結果として透明性は上がり、ゴールにストレートに走っていけるようになるのだと思います。
ただ、個人と本当の意味で対話ができるようになるには時間がかかる。そのための時間はつい後回しにしがちだけど、実は先に投資していいのかもしれないですね。
畠中 まさにそうですね。僕自身、CEOとして全社でスクラムを導入する上で、この「人への関心」はとても重要だと感じています。会社のコアバリューで担保したい気持ちもある。『Team Geek ―Googleのギークたちはいかにしてチームを作るのか』という本に「Humility（謙虚）、Respect（尊敬）、Trust（信頼）の頭文字を取った『HRT』を大切にしている」と書いてあって、会社のコアバリューにも「HRT」を入れています。
Team Geek ―Googleのギークたちはいかにしてチームを作るのか
O'Reilly Japan畠中 全社スクラムを始めて1年半ほどになりますが、この土台がなかったらうまくいっていなかったのかもなと、お二人の話を聞いていて思いました。
じゃが バリューやミッションへの共感は多様なメンバーの共通項であり、そう考えると初期から採用基準を下げないことがアジリティにもつながってくるのかもしれませんね。
初期フェーズでは「カルチャーは合わないかもしれないけど、スキルがマッチするから採用する」といった誘惑がありますけど、そこで踏みとどまることがその後のカルチャーを決定し、そしてカルチャーがアジリティをもたらす気がします。
経験主義だからこそ、正解はない
── 今回の座談会では、スタートアップにおけるアジリティの出し方は一つの正解があるものではなく、フェーズや状況によって大きく変わるというお話が印象的でした。
畠中 大前提としてスクラムは経験主義に基づいていて、「これをやっておけば間違いない」というものはないと思っています。今の状況を理解して、課題を見つけて、対処する。そのサイクルがスクラムの本質です。
とはいえ、現状を正しく認識するのがまず難しい。認識できたとしても、どう変えたらいいのかという難しさもあります。だからこそ自分たちが常に変化するつもりで、人の話を聞いたりして情報収集するのが大事だと改めて思いました。
あらたま スタートアップに参画するということは、会社や事業の存続に関わるということで、私たちエンジニアも例外ではありません。企業体力があまりない時期こそ、スクラムの経験主義的なやり方、観測したものに基づいて次に何をやるかを決めていくアジャイル的な進め方がマッチすると思います。
今後もうまく回らなかったり、リソースが足りなかったり、いろいろな問題はあるでしょうけど、ないない尽くしの状況こそ創意工夫のしがいがあるし、エンジニアの腕の見せ所でもあります。それを楽しむことを大事にしたいですね。
じゃが 何回も「シチュエーションによる」「会社の状態による」という話になりましたが、まさにそういうことだと思うんですよね。世の中には多様なスタートアップがあって、それぞれに試行錯誤をしている。
そういった経験を共有する場所として「Startup in Agile」を立ち上げたので、困りごとがあってもなくても何でもいいので、スタートアップで開発をしている人にぜひ遊びに来ていただきたいですね！
構成：天野 夏海
取材・編集・制作：はてな編集部
- 永山 大輔（ながやま・だいすけ） X: @jagaimogmog
- より良いスタートアップエコシステムを目指し、Nstockでソフトウェアエンジニアをしています。コミュニティ「Startup in Agile」と「CHUO_Tech」の運営。最近はサウナとポーカーにはまっています。
- 新多 真琴（あらた・まこと） X: @ar_tama
- ソフトウェアエンジニアとしてキャリアをスタートし、前職では執行役員CTOを務めた。現在はLayerXにて「バクラク申請・経費精算」のEMを担いつつ、コミュニティ「EMゆるミートアップ」「Startup in Agile」、カンファレンス「EMConf JP」を運営している。著書に『エンジニアリングマネージャーお悩み相談室 日々の課題を解決するための17のアドバイス』（翔泳社）。
- 畠中 翔一（はたなか・しょういち） X: @punk_punx
- 株式会社メディカルフォース代表取締役CEO。慶應義塾大学理工学部卒、慶應義塾大学大学院理工学研究科中退。2020年11月に株式会社メディカルフォースを設立し、現在のmedicalforceをフルスクラッチで開発。2025年2月、同社代表取締役CEOに就任。開発の傍ら、深層学習を用いた研究が国際学会に採択されるなど、機械学習（AI）や最先端の技術にも精通する。
