Yahoo! JAPAN

市場のトレンドが目まぐるしく変わっていく時代。その流れに対応すべく、アジャイル開発を取り入れる開発組織は増加傾向にある印象だ。

しかしその成功事例はなかなか増えていかず、アジャイル開発に対してハードルの高さを感じている組織もいまだ多く存在するだろう。一方、アジャイル開発の本場である米国に目を向けると、「もはやウォーターフォールを採用する企業の方が少数派」という話も聞こえてくる。

今回は、シリコンバレーのスタートアップでの開発経験を持ち、現在は2000万人を超える国内外ユーザーを有する子どもの写真・動画共有アプリ『家族アルバム みてね（以下、みてね）』の開発チームを率いるMIXIの平田将久さんに、米国と日本のアジャイル開発の違いとあわせて、日本の開発組織でアジャイル開発を浸透させるためのポイントを聞いた。

MIXI
Vantageスタジオ みてねプロダクト開発部 部⻑
平田将久さん

2011年に株式会社ミクシィ（現MIXI）に新卒入社し、エンジニアとしてSNS『mixi』の開発を担当。14年に転職し、複数企業にてスクラム開発の導入やスクラムマスターを務め、組織変革などのマネジメント業務に携わる。その後、米国シリコンバレーのスタートアップ企業にてプロダクト開発を経験し、Director of ConsultingとしてDX推進をリード。22年12月にMIXIに再入社し、現在は『家族アルバム みてね』におけるエンジニアリング組織全体のマネジメントに従事。Certified Scrum Professional®-ScrumMaster。日本CTO協会 DX Criteria ワーキンググループメンバー

国内外の企業でアジャイル開発の効果を体感

——スクラムマスターとしてのご経験が豊富な平田さんですが、最初にアジャイル開発を経験したのはいつですか？

アジャイルとの出会いは、新卒でMIXIに入社した翌年の2012年だったと思います。社内の開発体制を刷新するにあたって、アジャイル開発の一種であるスクラムが導入されたのがきっかけでした。

——その後、どのタイミングでスクラムマスターに？

開発体制の移行が決まってからすぐのことです。当時私は入社2年目のエンジニアでしたが、社内にスクラム開発に精通したメンバーがいなかったこともあり、スクラムマスターに立候補しました。

以前からプロダクト志向が強く、エンジニアの枠にとらわれずサービスの成長に貢献したい気持ちが強くて。新たなキャリアを築くチャンスでもあると感じたので手を挙げました。

運よく希望を叶えてもらってからは、開発の傍らアジャイルやスクラムに関する書籍を読み漁ったり、外部の研修を受けたりしながら研鑽を積み、3年間で三つの開発チームにスクラムを導入しました。

——2014年に一度MIXIを離れてからはどんなキャリアを歩んできたのでしょうか。

MIXIの後に転職したリクルートでは、アジャイルによる新規事業開発を経験しながら、スクラムマスターとして組織づくりにも尽力しました。転職から半年ほど経つころには、国内では数少ないアジャイルコーチから「いいチーム」だとお墨付きをいただき、外部から見学者がくるようなチームをつくれたのは大きな自信になりましたね。

その後渡米し、立ち上げ間もないシリコンバレーのスタートアップにエンジニアとして入り、急速に成長する組織のなかでアジャイル開発を体感できました。どれも得難い経験だったと思います。

——22年に再びMIXIにジョインしてからは、開発部長として『みてね』のプロダクト開発チームを率いていらっしゃいます。なぜ戻られたんですか？

当社の取締役ファウンダーの笠原（健治さん）に「『みてね』の開発チームが一体感を持ってプロダクトにまっすぐ向かえるよう、新しい風を吹き込んでほしい」と声を掛けていただいたことがきっかけです。

『みてね』は他事業部門よりも開発メンバーが占める割合が高く、メンバーによって知識や経験の濃淡はありますがスクラム開発の経験もありました。メンバーの技術力は高く柔軟でオープンな開発カルチャーも申し分ありません。

そんなチームをもう一段高いレベルにまで引き上げるために、これまで会得したすべての知見を使って挑んでみたくなり、再入社を決めました。

アジャイル開発を採用する日本企業が少ない理由

——平田さんはさまざまなチームでアジャイル開発やスクラムを経験されています。自らのチームに導入する上で何を大切にされてきましたか？

スクラムに限ったことではありませんが、組織にアジャイル開発を導入して根付かせるためには、知識とマインドセットの両面が欠かせません。知識があるだけでは自分事にはなりませんし、プロダクトをよりよくしたいというマインドセットだけあっても、知識がなければ迷いが生じてしまうからです。

ほかにもアジャイル開発を成功させるために欠かせないポイントがあります。それが、アジャイルカルチャーを育む組織構造です。

——それはどのような組織構造なのですか？

シリコンバレーのスタートアップ時代、組織が大きくなるにつれアジャイルのよさが薄れていくことに危機感を覚え、手にした書籍があります。クレーグ・ラーマンの『大規模スクラム Large-Scale Scrum(LeSS)』です。

この本には文字通り、大規模な開発案件にスクラムを適用するための数々のノウハウが書かれているのですが、当時の私には「文化は組織構造に依存する」という言葉が非常に印象に残りました。いくらアジャイルやスクラムについて知識があり、高い理想を掲げたとしても、縦割りの組織構造やトップダウンによる指揮命令系統が残っていては、アジャイルに即したカルチャーは育めないとあり、非常に腹落ちしたからです。

逆にいえば、階層構造がフラットで、かつ柔軟で自律性に富んだメンバーを集め、ワンチームで顧客に価値を提供できるケイパビリティーを備えれば、数十名、数百名規模でも十分スクラム開発は機能することを知りました。以来、私は「文化は組織構造に依存する」というラーマンの言葉を念頭に組織づくりをしています。

——日本でもアジャイル開発が注目を集めるようになって久しいものの、ある調査によるとアジャイル開発を採用する日本企業はいまだ15％しかないそうです。日米の開発文化を知る平田さんの目から見て、なぜ日本ではアジャイル開発が支持されないのでしょうか？

米国にはアジャイルなカルチャーがあり、日本ではアジャイルなカルチャーが根付きにくいという比較論を目にすることは多いですが、その点に関しては産業構造の違いが大きく影響している気がします。

IT産業の大部分を受託開発やSIerが占める日本と、スタートアップをはじめ自社サービスを手掛けるエンジニアが大勢を占める米国の違いです。

——確かに日本では事業会社で自社サービスに携わるエンジニアは全体の30％に満たないのに対し、米国では65％が事業会社で自社サービスの開発に携わっているとか（出典)。

スタートアップに集まるメンバーは、起業家もエンジニアも関係なく積極果敢に課題に向き合おうとする傾向があります。一人一人がプロダクトビジョンの実現に直接影響力があるような組織規模ですし、プロダクトビジョンに共感した人たちのみが集まります。

報酬面でも、将来ストックオプションで手にする金額に直結するのも理由の一つとしてあります。先行きが不透明な状況を打開するには、コラボレーションを好み、守備範囲にこだわらないタイプでなければ切り抜けるのが難しい側面があるからだとも言えるでしょう。

日本でも優秀な起業家のもとにはアジャイルなマインドを持つエンジニアやデザイナーが集まるわけですから、程度の差はあれど日米で大きな違いがあるようには感じません。自社サービスを開発するスタートアップが増えれば、おのずとアジャイル開発を採用する企業は増えるのではないでしょうか。

基本を軽視する姿勢がアジャイル開発の失敗を招く

——アジャイル開発を導入したにもかかわらず失敗してしまったとしたら、そこにはどのような理由があると考えられますか？

アジャイルにはスクラムだけでなく「エクストリーム・プログラミング」や「ユーザー駆動設計」など、さまざまな手法がありますが、それぞれの手法で定義されているルールやプロセスを安易にアレンジした途端、歯車が噛み合わなくなってしまうことはよくあります。

アジャイル開発の特性を正しく理解し、試行錯誤を重ねた上で自社に合うようなアレンジを施すのはかまいません。しかしそれはしっかりした基礎があるからできることであって、基礎がないのに我流を貫けば失敗するのがオチです。あくまでも肌感覚ですが、こうした基本を軽視する姿勢こそが、アジャイル開発の失敗を招いているのではないかと感じます。

——平田さんが得意とされているスクラムの場合、守るべき基本とはどんなものがありますか？

会議のやり方一つとっても厳密なルールが決められています。

例えばスプリントプランニングは、「なぜ開発するのか」を議論した上で、何をどのように開発するか決める場ですが、会議の趣旨を理解していないメンバーがこの会議に加わっていたらどうなるでしょう。議論がすれ違い、決めるべきことが決められないまま会議が終わってしまうかもしれません。

アジャイル開発には練り込まれたルールがあり、必要なピースが一つでも欠ければアジャイル開発は滞ってしまいます。本来の目的に沿わないやり方で置き換えてしまえば、途端に機能しなくなってしまう危険性があるんです。

——平田さんは22年にMIXIに再入社してから『みてね』の開発組織の成長をリードしてこられましたが、当時のチームにはどのような課題がありましたか？

MIXIは10年以上前からアジャイル変革に取り組んでいるので、まったくのゼロから立ち上げなければならないほどではありませんでした。だからといって問題が全くなかったわけではありません。

『みてね』の開発部長に着任してしばらくして、アジャイルやスクラムについての基本的な知識を問うためにワークショップを開きましたが、自信を持って答えられる人が少なかったことが分かったんです。そして、メンバーには基本を忠実に学びたいという意欲があることも分かりました。

研修を進めていくと、よりうまくスクラムを推進するための知識を得られると感じてもらえたようで、積極的に学ぶ姿勢を示してくれました。

——すでにアジャイルな文化自体はあったということは、チームの立ち上がりも早かったのでは？

技術力もポテンシャルもあるのにそれを十分活かし切れていなかっただけなので、確かに立ち上がりは早かったですね。

当時の経験を踏まえ、現在では新たにチームメンバーが加わる際にスクラムの基礎から組織論まで3日間かけて学ぶ研修を設けるようにしました。しっかりとスクラムについての知識を固め、ベストな状態で開発チームに加わってもらうためです。

不確実性と戦うなら、迷わずアジャイルを選ぶべき

——苦労してアジャイルを導入したにもかかわらず形骸化してしまったり、ゆがんだ形で浸透したりしてしまうのはなぜでしょうか？

日本には経験豊富なスクラムマスターやアジャイルコーチが少ないという構造的な問題が挙げられるでしょう。また、研修会社に依頼すると、一人あたり数十万円のコストがかかってしまいます。そのため自分たちの手でなんとかしようとするのですが、先ほど言ったような理解不足や誤解、準備不足によって頓挫してしまうケースが後を絶ちません。

フラットな組織構造に変えられなかったり、兼務が多くアジャイル開発に専念できないメンバーを許容したりすることによって、行き詰まるケースもよく見受けられます。

——やはり基本に忠実になるのが大切ということですね。

そう思います。本来スクラムは少人数の開発チームだけの手法ではありません。スクラムを応用した大規模スクラム(LeSS)という、何十人何百人という規模で適用できるフレームワークもあります。

しかし最初の入り口が間違っていたり、成り行き任せにしてしまったりすると、理想と現実の乖離が顕著になっていきます。最悪の場合、組織崩壊を招いてしまうかもしれません。

それほど細部に目を行き届かせなければならない繊細な取り組みなんです。

——アジャイルを選ぶべきか、違う方法を選ぶべきか選択の基準はありますか？

プロダクトの性質にもよりますが、事業を中長期的に見たときに不確実性と戦うことが確実なら、迷わずアジャイルを選ぶべきでしょうね。関係者の知識やマインドセットを揃え、組織構造を整えられるのであれば、アジャイル開発はこれまでよりも効率的でクリエーティブな開発者体験を保証してくれるはずです。

『みてね』の場合、スクラム開発の基礎をチームに再インストールし、アジャイル開発に対する迷いが消えた今は、2000万人を超えるユーザーに支持されるプロダクトの今後を支えることに大きく貢献できると信じています。

——アジャイルな開発カルチャーを手に入れるには、まず何から始めるべきでしょうか？

日本CTO協会が公開しているDX推進のための指標である「DX Criteria」を活用して、まずは現状を診断してみることから始めてみてはいかがでしょうか。DX Criteriaは、よりよい開発者体験を生み出すためのオープンな指標ですが、その中の重要な部分として組織がアジャイルであるかという指標が存在します。また、アジャイルカルチャーに関する指標だけではなく、不確実と向き合うための多角的な指標も表現されていることから、具体的に自分たちの組織には何が足りないのかを理解する助けになるのでお勧めです。私たちのチームでも、開発カルチャーの見直しなどに利用しています。

アジャイル開発への移行は、組織やカルチャーの変革を伴うものです。メンバーはもちろん経営陣やマネジャー陣の関与が欠かせない以上、各ステークホルダーがWin-Winになるような落とし所を見つけなければなりません。容易ではありませんが、地道に取り組めば必ず道は開けるはずですよ。

取材・文／取材・文／武田敏則（グレタケ）　撮影／赤松洋太