Yahoo! JAPAN

納期、不確実。
予算、不確実。
完成度、不確実。

アジャイル開発に対し、経営層*が眉をひそめるのは、こうした予測不可能な状況下での意思決定を迫られるからではないだろうか。

事実、「ウォータフォールはやめて2024年の開発をやろう！」と題された牛尾 剛さんのnoteでの発信に対し、「アジャイルはいいんだが、それだと経営者などの非エンジニアからの理解が得られないので納得できるように言語化してほしいんだよな」と懸念を示した藤川真一（えふしん）さんのポストは、テック界隈で大きな反響を呼んだ。

柔軟性とスピードを謳うアジャイル開発が成熟しつつある一方で、経営視点では「扱いづらさ」が拭えないのはなぜか。経営層と開発現場の溝にあるものとは？

米マイクロソフトのエンジニアで『世界一流エンジニアの思考法』著者の牛尾さんと、BASEでエンジニアのマネジメントを手掛けるえふしんさんの対談から探った。

*本記事で「経営層」としている部分には、CTOや開発組織のリーダークラスを含みます

BASE株式会社
上級執行役員SVP of Development
藤川 真一さん（@fshin2000）

1973年生まれ、埼玉県出身。FA装置メーカー、Web制作のベンチャーを経て、2006年からWebサービス業界に転身。ショッピングモールサービスにプロデューサーとして携わるかたわら、2007年から携帯向けTwitterクライアント「モバツイ」の開発・運営を個人で開始。モバツイ譲渡後、12年11月6日に想創社設立。その後、BASE株式会社 取締役CTOに就任。19年7月から同社上級執行役員SVP of DevelopmentおよびPAY株式会社取締役に就任。17年9月に慶應義塾大学大学院メディアデザイン研究科博士課程を単位取得満期退学、18年1月博士（メディアデザイン学）取得、同学科研究員。G's Academyメンター。デジタルハリウッド大学大学院にて客員教授を務める

米マイクロソフト Azure Functionsプロダクトチーム シニアソフトウェアエンジニア 牛尾 剛さん（@sandayuu⁠⁠⁠）

1971年、大阪府生まれ。米マイクロソフトAzure Functionsプロダクトチーム シニアソフトウェアエンジニア。シアトル在住。関西大学卒業後、日本電気株式会社でITエンジニアをはじめ、その後オブジェクト指向やアジャイル開発に傾倒し、株式会社豆蔵を経由し、独立。アジャイル、DevOpsのコンサルタントとして数多くのコンサルティングや講演を手掛けてきた。2015年、米国マイクロソフトに入社。エバンジェリストとしての活躍を経て、19年より米国本社でAzure Functionsの開発に従事する。ソフトウェア開発の最前線での学びを伝えるnoteが人気を博す。書籍『世界一流エンジニアの思考法』（文藝春秋）は10万部を突破し、ITエンジニア本大賞2025特別賞も受賞

アジャイルにモヤつく瞬間とは？

アジャイルが成熟した手法になりつつある今、えふしんさん、ひいてはアジャイルを採用している開発組織のリーダーや経営層がモヤっとするのは、どんな瞬間なのだろうか。

えふしんさんは「予定していた開発スケジュールが遅れる」場面を例に取り、こう説明する。

「例えば、当初見積もっていたスケジュールが何らかの要因で遅れるとしましょう。それ自体はアジャイルもウォーターフォールも関係なく、よくあることです。ただ、アジャイルの場合、そうした場面で『やっぱり、あの日程は現実的じゃなかった』『この機能開発が割り込んできたし、しょうがない』なんて言いながら計画が引き直されるわけです。

最終的に、当初計画から1カ月リリースが遅れたとしても、仕切りなおした日程は守られているので『スケジュール通り遂行した』という報告になる。果たしてこれは正しい姿なのか……という疑問は残りますよね」（えふしん）

こうしてスケジュールが“ふわっと” 伸びていくことが、えふしんさんの悩みを深くしていると言う。

「スケジュールしかり、予算しかり、要件しかり。あらゆる事情が絡み合い、プロジェクトが途中で変更を余儀なくされるのは理解できます。それに、関係者たちが合意した上で変更するのですから、実質的な問題は生じていないし、誰かが困っているわけでもないでしょう。遅れを指摘したところで、事態の打開にもつながらないですしね。

ただ、何と言うか……。その状況でも『よどみなく進んでいます』なんて胸を張られちゃうと、なんとも言い難い気持ちになってしまうんですよね。この気持ちを持っているのは、おそらく僕だけじゃない。多くのCTOや開発リーダーがこの状況にどう折り合いをつけるべきか、頭を悩ませていると思います」（えふしんさん）

「アジャイルだから途中変更は当然」――。そんな風に強気なスタンスでいられるとマネジメント側は素直に受け止められない。そうしたジレンマを抱えてしまう背景には「清濁併せ吞んでいる人の存在が、脳裏をよぎるからかもしれない」とえふしんさんは続ける。

「プロダクト開発は、開発組織だけで完結するものではありません。それに、経営陣はエンジニアリングの専門家ではありませんから、現実的には、技術に精通している人がビジネスサイドに対し、『この開発要件であれば、ここまでにリリースできます』などと説明責任を負っているはずです。

ただ、それをそのまま現場に下ろし、『だからスケジュール通りによろしく』と託しても、現場はただ息苦しくなるだけなんです。だからこそ、現場寄りのマネジャーやリーダーたちは、毎週の進捗確認の場で『大丈夫』『任せて』と現場に寄り添いつつ、ビジネスサイドには『全力を尽くします』と伝えなくちゃならない。

清濁併せ呑み、双方の間で苦労を引き受けている存在がいる。

その人たちへの苦労に思いを馳せることもなく、平然と遅延を正当化するのは、いかがなものか。僕が伝えたいのはそういうことなのかもしれません」（えふしんさん）

マイクロソフトで“モヤつき”が発生しない理由

では、マイクロソフト（以下、MS）のエンジニアたちは、このような板挟みの状況にどう向き合っているのだろうか。牛尾さんに尋ねたところ、「そもそも、自分の経験的には、MSではこうした葛藤はほとんど生じない」のだと話す。

その理由はこうだ。

「MSでも当然、経営層への説明責任はあります。株主がいますからね。ただ、多くの日本企業と違って『経営トップがエンジニア』である点は優位に働いているように思います。CEOのサティア・ナデラをはじめ、経営陣の多くがエンジニア出身者で構成されていて、技術に対する深い理解があるので、提案や意思決定の際に詳細な技術説明や背景説明を必要としないと思います」（牛尾さん）

それゆえ、迅速な意思決定と実行が可能になるというわけだ。加えて「日本とアメリカでは、要求の細かさが大きく違う」と牛尾さんは続ける。

「アメリカの『要求』は日本のそれに比べるとかなり粗いです。悪く言えば雑、良く言えば細かいことは気にしない、といったところでしょうか。例えば、上から降りてくるリクエストと言えば『今期中に〇〇を実装したい』くらいのレベルです。Aという機能がいつまでに・誰がどう連携して・どんな順番で組み込まれるかは、さほど重要視されません」（牛尾さん）

アメリカでは、細かい仕様よりもビジネスゴールに重点が置かれる傾向にある。機能の細部にこだわるよりも、サービス全体のリリース時期や品質を重視する、といった具合だ。

「例えば、このサービスが正式（GA）版としてリリースされるのか、それともβ版としてリリースされるのか、といった大きな点を気にして細かい事は気にしません。他には、競合他社の製品に負けているようなときは競合に勝てるようになることは気にしますが、細かい事は気にしませんね」（牛尾さん）

さらに「エンジニアの裁量の大きさが日本と大きく違う」点も、モヤつきが生まれにくい理由だと牛尾さんは推測する。

「日本だと、往々にして上司や先輩の指示に従い、決められた範囲と順番で開発すると思うんですが、私が観察していると、MSでは新卒1年目だろうと、“ふわっ”とした要望を明確化するところからエンジニアの仕事です。要望を具体化し、設計、実装、テスト、リリース、そしてインシデント対応まで、開発の一連のサイクル全体を自らの責任において実行することが求められます」（牛尾さん）

曖昧なニーズを形づくっていくのは、自分。間に立って交通整理してくれる人がいない分、裁量が大きく、モヤつきも生まれにくい。こうした文化土壌こそ、“モヤモヤさせないアジャイル”を成立させているのだろう。

しかし、詳細な開発内容や工程、人員の決めごとなしに、一体どうやって予算を確保するのか。結局、予算交渉の場面でモヤつきが生まれるのではないのか。

「私の部署では、予算を見積もる場合、機能単位ではなく人員単位で見積もっていると思います。つまり『人員が何人必要なのか』が分かれば、おのずと予算も確定しますよね。

例えば、新しい機能の開発を提案する場合、まずは簡単なデモを作成し、経営陣に提示する。『このプロトタイプを使えば、こんな機能が実現可能です。なので、〇〇名のチーム人員を確保させてください。成功すれば開発を続けるし、上手くいかなければ中止します』みたいに。そんな形で説得していると聞いています」（牛尾さん）

しかし、合意を得られたとしても、実装フェーズの進捗管理は避けて通れない。もし、進捗管理なしで担当エンジニアに任せっぱなしなら、『リリース日に間に合わない』なんて事態にもなりかねないのではないか。

「その場合、マネジメントはどう機能しているんでしょう？」というえふしんさんからの質問に対して、牛尾さんの答えは明確だ。

「マネジメントでどうこうするというよりは、まず達成可能な範囲でゴール設定を調整するんですよ」（牛尾さん）

「MSでは納期よりも品質と安定性を重視される感じなので、納期優先のプロジェクトはかなり稀です。稀に納期中心のプロジェクトが発生し、経営層から強い要望があったとしても、スコープを徹底的に絞り込み、確実に達成可能な範囲に調整しちゃいますね。

優先順位はP0（最優先）が頂点ですが、P0に次ぐP1、P2のタスクはほぼ着手しないか、余裕があればやるというスタンスです。そうするとリソースに余裕が生まれ、P0が発生した際には迅速に対応できる体制を構築しているんです。

一見、リソースを持て余しているように見えるかもしれませんが、それも戦略です。余裕を持たせることで、緊急事態に万全の対応が可能となり、結果としてプロダクトの安定性と信頼性を高めることにつながるんです。これは、機能追加よりも、既存の機能を安定させ、ユーザー体験を向上させることを重視しているため、結果的に余裕のあるリソース配分が安定したプロダクト開発につながるのです」（牛尾さん）

自分の正義やボキャブラリーは通じないと思え

牛尾さんの話を掘り下げていくほど、日米の開発環境を大きく隔てる文化土壌の違いが、鮮明に浮かび上がってくる。エンジニア主導の意思決定、個々の裁量、優先順位付けは、日本の多くの企業文化とは対照的だ。

こうした現実を前に、日本のエンジニア、特に現場と経営層の間で、“モヤモヤ”を抱えやすいリーダーたちは、いかにしてこの構造的な矛盾と向き合えばいいのだろうか。

えふしんさんは「牛尾さんの話を聞くと、アメリカの経営層はビジネスの成果に目を向けていることが分かります。これって案外、日本の開発現場でも共通する認識ではないでしょうか」と話す。

「少なくともBASEをはじめ、自社開発を進める企業では同様の傾向が見られると感じています。

経営層にとって重要なのは、開発チームの連携がうまく取れていて、事業へ貢献してくれること。詳細な開発プロセスへの関心は、はっきり言って低いです。

だからこそ、開発チームには『腹を括ること』が求められるんじゃないかなと思いますね。『こうすればきっとうまくいきます』と自信を持ち、その客観的データ（例えば、生産性指標）で根拠を示す。そして経営層から権限委譲を受け、成果への責任を担う。これらが実現すれば、多くの問題は解決の糸口が見つかるはずです」（えふしんさん）

「同時に、エンジニアたちに伝えたいのは、安易に『アジャイル最高』と称賛するのではなく、経営層との言葉や価値観の差異を理解し、両者の橋渡し役となるリーダーへの想像力を働かせてほしいということです。

エンジニア同士であれば通じる技術的な議論や思考でも、異なるコミュニティー（ここでは経営層）とコミュニケーションを取る時は、相手に合わせた『言語』に翻訳する必要があります。

自分たちの正義をその言葉のまま相手に伝えても、ベースとなるボキャブラリーが違えば伝わるものも伝わらない。相手の視点や理解度に合わせて、言葉を選び、説明方法を工夫をすれば、アジャイルにモヤる場面は圧倒的に少なくなると思います」（えふしんさん）

えふしんさんの言葉に同意しながら、牛尾さんはこうも提案する。

「まず、自分たちの組織文化を徹底的に理解すること。そして、その文化の中で最大限に力を発揮できる術を模索することが大事です。マイクロソフトのやり方やアジャイルは、万能薬ではありません。各組織は固有の強みと弱みを抱えていますからね。
だからこそ、自らの組織の強みを研ぎ澄まし、弱みを補完する戦略を見つけることが肝要です。そして、変化を恐れることなく、常に未知の領域に挑む姿勢を貫くこと。それこそが、日本のエンジニアとリーダーたちが、目の前の『モヤモヤ』を乗り越え、より理想的な開発組織を築き上げるための、一歩になると思います」（牛尾さん）

撮影／桑原美樹　取材・文／玉城智子（編集部）　編集協力／松村修（編集部）