アジャイルをスケールさせる手法に正解はない 自社のモデルを探す事例と課題 平鍋健児さんに聞く

アジャイルをスケールさせる手法に正解はない 自社のモデルを探す事例と課題 平鍋健児さんに聞く

仕様書の通りのITシステムをカッチリと時間をかけて作っても、顧客に「依頼したものと違う」と言われてしまう。ソフトウェアエンジニアの「いいものを作りたい」という気持ちがビジネスに生かされていない。そう感じていた平鍋健児さんは、ピラミッドのように大きな建築物を数十年かけて作るやり方ではなく、生鮮食品のように鮮度を大切にしたアジャイルの開発手法に出会い、この20年を実践と普及に取り組んできました。

近年はビジネスの立場からも語られる「アジャイル」ですが、このインタビューではアジャイルを導入する企業がステージや事業規模に応じてどのような課題に直面するのか? とくに、小さなスタートアップ企業がアジャイルネイティブから大きくなったメガベンチャーだけでなく、旧来の開発手法を続けてきた既存の企業が、自分たちにフィットしたアジャイルを見つけるときに参照できるいくつかの事例とあわせて紹介します。

アジャイルがデフォルトに変わった20年

── 平鍋さんが2000年にケント・ベックの『Extreme Programming Explained』を読んでエクストリームプログラミングに出会い、アジャイルの実践と普及に取り組んでもう20年がたっています。ソフトウェア開発に対する一般的なアプローチも、当時と比べるとずいぶん変わったのではないでしょうか?

平鍋 そうですね。今や「アジャイル」という言葉はソフトウェア開発に限らず、組織改革や「デジタルトランスフォーメーション(DX)」とともに日本のあらゆる事業組織で耳にするようになりました。うれしいことなんですが、正直なところ、ちょっとびっくりしています。

当時、アジャイルという方法論を見つけて取り組んだものの、人月単位の見積もりといった商習慣はなかなか変わりませんし、ビジネス側を納得させるような説明ができなかったこともあります。今につながる「アジャイルジャパン」というイベントを2009年に始めたときも、事例を集めるのに一生懸命でした。

ですが、その頃から状況が変わってきたようにも思います。ソフトウェア開発の特性をビジネスに生かそうという考え方が出てきて、2010年代以降はグーグルの「プロジェクト・アリストテレス」にも表れているように、心理的安全性を担保して効果的に仕事をするチームを作ることで、ソフトウェアエンジニアの「いいものを作る」という気持ちをビジネスの味方に付けることを考えるようになっています。

今では、(平鍋さんが代表の永和システムマネジメントに)お客様の方から「アジャイルでやりたいんです」と言ってくることが普通になりました。新しく入ってくるエンジニアにしても、アジャイルネイティブで「え、これ以外のやり方があるんですか?」と言われて驚いたりもします。

── ビジネス側にもソフトウェア開発のよさを生かすスタンスの変化があったんですね。

平鍋 ソフトウェアを開発するエンジニアとビジネス側が一体化できるようになってきたという変化ですね。これは昨年(2021年)講演中に手書きした図なのですが……。

手書きの図
▲ スクラムフェス札幌2021キーノート「アジャイルの旅支度 − ここではじめる、自分ではじめる」講演資料より

2000年以降に起業したスタートアップ企業(図の下段)は、多くがWebを使ってサービスを展開し、ユーザーの反応を見ながら開発を進めるというように、ソフトウェアを中心にビジネスを考えてきました。こうして成長した企業は、おそらくほとんどがアジャイルネイティブですね。それが自然なやり方になっているでしょう。

── 図の上部にある「既存大企業」のビジネスとソフトウェアはどうなのでしょう?

平鍋 昔からのソフトウェアメーカーやシステムインテグレータでは、スタートアップとまったく違う話になります。彼らにとってこれまではプロジェクトマネジメントが最も重要で、ソフトウェアを書く仕事は外注していました。エンジニアがよいやり方を見つけても「変更の工数は……」といった話になり、最終的なユーザーとは関係のないコミュニケーションにほとんどのエネルギーが吸い取られるようでした。

ところが今になって、このやり方では社内にまったく技術的な体力が残らないことに気付きはじめたのです。誰に言われたでなく「これはおかしい。技術をもう一回取り戻して、技術に適したやり方をしなくてはいけない」と考えるようになった。内部にエンジニア組織を持ってソフトウェアを内製し、それにはアジャイルが適しており、ビジネスもそうじゃなければいけないという感覚が強くなってきました。

Extreme Programming Explained: Embrace Change
エクストリームプログラミング(XP)提唱者の1人であるケント・ベック(Kent Beck)自身による解説書。原書は1999年に刊行され、平鍋さんの目にするところとなった。翌年に『XPエクストリーム・プログラミング入門 ソフトウェア開発の究極の手法』のタイトルで日本語訳もある。2004年には大きく内容を改めたSecond Editionも刊行され、これは『エクストリームプログラミング』(角征典 訳、2015年、オーム社)が現行の日本語版となっている。

手法よりも「チームの文化作り」が最大の課題

── そうした変化により、ビジネス慣習というアジャイルを導入する上での大きな障壁を解消できたとして、次のステップとして実際に導入する際に直面する課題もまだ残っているでしょうか?

平鍋 はい、いくつかありますね。まず、アジャイルは手法というより、チームの文化作りそのものといったところがあります。ビジネスとエンジニアが一体のチームになり、一緒になって「いい仕事をしよう」と思える文化が大事です。ベタに言えば「みんなでよい成果をユーザーに届けよう」ということですね。

業務を「ここまでが私の仕事、ここから先はあなたの仕事」と分担しても、こぼれるボールはあるんですから、気付いた人が拾って、チームで1つのゴールに向かう必要がある。これはルールで決めてもなかなかうまくいくものではありません。「スクラムをします」といってチームを作ってルールは決めたけど、めまぐるしいスプリントにメンバーの顔は死んでいる。抜けた仕事を誰も取りにいかないし、改善の提案もできない。そういう形から入って「言われたからやってる」だけのゾンビスクラムは、僕がもともとやりたかったこととは違います。

私たちが取り組んでいるソフトウェア開発で、唯一正解を知っているのは顧客であり、外に向けられたWebサイトではユーザー市場にしかありません。だからビジネスが分かるプロダクトオーナーは、早く市場に接近して何をどのタイミングで作るかを決め、そのビジョンが合っていたかを市場と会話しながら確認するわけです。エンジニアもプロダクト開発だけでなく、そのやり方に対しても知恵を出して、変えていけるといいですね。

そんな活動体としてのチームを作れるかどうかが一番大きなテーマだと思います。

チームが大きくなるととたんに難しくなる

── アジャイルにおけるチーム作りにおいて、現在の課題はどういった点にあるのでしょうか?

平鍋 実は、小さいチームでのアジャイルは環境が整えばできますし、成果もたくさん上がっています。ですがチームが大きくなると、とたんに難しくなる。これがもう1つの課題です。先ほどの図でいうと、小さなスタートアップ(左下)から始まっても、成長して大きくなる(右上に移行する)と、1つの製品にチームがいくつも必要になる。すると「チーム間のコミュニケーションをどうするか?」という別の問題が起きるんですね。

アジャイルをどうやってスケールさせるかはいつも課題です。たぶん正解がないんでしょうね。だからみんな苦労しながら、工夫しながらやっている。スケールするフレームワークも多く提案されていますが、たぶんどれも本質ではない。本質はその組織が独自の文脈で、自分たちのやり方を作り出していくこと。Spotifyモデルのようなものが出てくるのも、そうしたムーブメントです。肝心なのは、そういったモデルを自分たちで作っていくことです(図中の②)

Spotifyは、彼らのビジネスの中で自分たちがどうあるべきかを考えて、あのモデルに行き着いた。なので、みんながまねしても仕方ないんです。自分たちの問題は自分たちが気付いて、自分たちでやり方を作っていく。それが正当でしょう。スタート地点はどこでもいい。Scrum@ScaleやLeSSといったフレームワークでもいいです。「チームトポロジー」という考え方が出てくるのも、進化していくチーム独自のアーキテクチャを記述できるからですね。

やはりポイントは、みんなで作っていくことです。経営もエンジニアも、実際にユーザーに接している人も、みんなで会社の形を考えて、変えれるのかが2つ目の課題でしょう。

── 逆に、ずっとやり方を変えなくてもいい企業はあるでしょうか?

平鍋 イノベーションよりもオペレーションが強い企業なら、それでもいいんじゃないでしょうか。すでに大きなシェアを持っていて仕事をどう回すかが重要という企業では、ずっとウォーターフォールでいくのもありかなと思います(図中の④)

逆説的になりますが、アジャイルとは全然別のところに組織の強みがある企業が「アジャイルをやらなければいけない」と思ってやると、たぶん死んじゃうんですよね。いいところがなくなってしまうので。まずは自分たちの強みと進むべき方向を、現在の市場に照らして考えることです。

チームトポロジー
2019年にMatthew Skelton、Manuel Pais『Team Topologies: Organizing Business and Technology Teams for Fast Flow』という書籍が刊行されている。日本語版は『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』(原田騎郎、永瀬美穂、吉羽龍太郎 訳、2021年、日本能率協会マネジメントセンター)。

事例1. リクシル ─ 幸福度指数を計測して文化づくりを推進

── アジャイルをスケールさせる方法に正解はないというお話でしたが、これまでアジャイルのコーチングや内製化支援を一緒に取り組んだ中で、自分たちのやり方を作った企業の事例をいくつか教えてください。

平鍋 分かりました。まず、リクシルの事例です。リクシルはグローバル企業で、もともと組織に多様性がありますから、「日本のやり方でやろう」と考えない方がいいということもよく分かっていました。特徴はCxOレベルが率先して、トップダウンでスクラム導入を進めていることです。

文化作りの重要性も理解していて、もともと企業のパーパス(存在意義)を実現するリクシルビヘイビアを定義しています。この「正しいことをする/敬意を持って働く/実験し、学ぶ」という会社の在り方に合っているからこそ、アジャイルを選択しています。

フレームワークとしてはScrum@Scaleに落とし込んでいます。いくつもスクラムチームを作り、それが階層構造をなして、上がってくる課題を解決するための全社的なEAT(問題解決チーム)に届く仕組みを構築しています。これによって、開発の速度を止めることなく素早く課題を取り除こうとしています。

── リクシルの取り組みで、とくにユニークなところは何でしょうか?

平鍋 例えば、ジェフ・サザーランド(Jeff Sutherland)が提唱する幸福度指数(Happiness Index)の計測を通して、文化作りを推進しています。活動に加わっている人たちがどんなふうにプロジェクトに関わり、生き生きと働けていけるかを計測しています。サザーランドのスクラム理論では、幸福度指数はベロシティの先行指標になると言われています。

また、アジャイルプラクティスやスクラムを用いた開発を全社に広げるコーチ陣を、内部で持っていることも特徴です。コーチ陣が実際に現場に出向いて、一緒に働きながらチームのメンバーを育て、時には各スクラムから上がって来た課題を集め、全社で問題解決を図るというやり方です。

── 大きな企業になればなるほど「これまでのやり方を変えたくない」という声も上がりそうですが……。

平鍋 スクラム以外の部分も含め、さまざまなマネジメントを通して社員を不安にさせない工夫をしながら、人事制度の変革にも取り組んでいます。

Scrum Inc. Japan - LIXILのデジタル部門はなぜ、1年半で組織をアジャイルに変えられたのか

事例2. ANA ─ 内製化を進め、オンラインに情報を集約

平鍋 次に紹介したいのは、ANA(全日空)の事例です。空港における遺失物管理や機内持ち込み危険物管理といった、運航に直接関わる基幹システム以外のさまざまなバックヤードシステムについても、昔から子会社のASY(ANAシステムズ)が仕様を作り、外注で開発していました。けれど、それではもうスピードが間に合わないため、内製化してスクラムに取り組んでいます。

特徴は、ANAとASYが一緒に内製化チームを作り、そこに弊社が入って、ともに文化作りを進めていることです。内製化チームでは「Be a Builder」というキーワードを掲げています。単なる発注屋ではなく、自分たちも手を動かして作れるようになることが目的なんですね。チームもこの目的に向けて構成したんですが、開発経験がない人も多いので、3人1組でチームを作り、お互いに教え合いながらバックログに載っているタスクに取り組んで、解決することでチームを育てています。

── 複数拠点での取り組みになるかと思いますが、オンラインの使い方にも工夫があるでしょうか。

平鍋 部門とのやりとりの仕組みや見積もり方法、スプリントの1週間の時間割や過去の議事録など、全部このオンラインホワイトボードにまとめています。チームが出発してどんな出来事があったかの年表もあります。

miroの画面
▲ プロジェクトの情報が集積されたオンラインホワイトボード(スクリーンショット)

── ツールはやはりmiroなんですね。楽しそうな雰囲気が伝わってきます。

平鍋 ポイントは、独自の進化をしていることです。例えばデイリースクラム(朝会)の進め方もボード上に載っていますが、いろいろなアイデアを出しながらどんどん変えてきました。プロダクトオーナーの願いをどうかなえるか、チームでどうやってタスクを裁くか、そしてチームの人数が増えてきたときにどうするか、そういった問いにはいろいろなやり方があります。型にはめるのはあまり好きじゃないですね。

miroの画面
▲ デイリースクラムを改善した様子(スクリーンショット)

ANA様の働き方改革へのご支援について(開発編)

事例3. 北國銀行 ─ サービスレベルと可用性を定めて開発

平鍋 もう1つ紹介したいのが、北國銀行の事例です。地方銀行として5年後、10年後も地域が持続的に発展できる基盤を顧客と一緒に作ることを目的に掲げて、インターネットバンキングへのシフトを進めています。

そんな中でアジャイルを選択した理由ですが、以前のシステム開発においては「声が大きい人の仕様が採用される」ことや「お客様不在」といったいろいろな問題があり、それをみんなが分かっていながらも、変えようとするとかなりたいへんな作業になるので手を出せない状態でした。

そういった「いったいどこの誰のために、何のために仕事をしているのかが分からない」という職業人としての「心の叫び」みたいなものをどうにかしたいと考えたんですね。そもそも銀行はさまざまなシステムで最も保守的で、計画通りにいけばそれでOKという文化です。そこからスピーディに効率よく、最もいいことを最初にやるというアジャイル志向の文化に変わろうとしています。

その一環として、「何があってもシステム障害があってはいけない」といったこれまでの考え方では何もできなくなりますから、どのサービスにはどのくらいの可用性が必要かといったサービスレベルを切り分けた上で、それぞれ違うやり方をしていこうときちんと定義して、開発を内部で進めています。

── 金融機関がそこに踏み込むとは、正直驚きです。

平鍋 私も執筆に協力した経済産業省のDXレポートでも触れられていますが、米国では内製化が当たり前で、銀行ですら多数のエンジニアリング部隊を持っています。しかし国内では、まだ内製化できていないユーザー企業もたくさんあります。そうした企業と一緒になって、環境作りやチーム作りに取り組むのが、弊社が目指すベンダーの役割です。ベンダーこそ、内製化の支援をすべきなんです。

先ほど挙げた課題の続きになりますが、3つ目は、ユーザー企業とベンダーの新しい協業の形をどう作るかですね。金沢が本社の北國銀行は、福井が本社の弊社とも距離的に近いので、週に1回はビジネスを考える人とエンジニアリングを考える人が会って話をしています。顧客やユーザーをどのように喜ばせたいかを考えている事業部門とその内製技術者部隊、そして私たちのようにエンジニアリングの技術を持った人が一緒になって、アジャイル共創という新しいやり方に取り組んでいるところです。

金融DXへの北國銀行の取り組みレポート〜失敗は本当に学びしかなかった

何のためアジャイルにするのかを言語化することが必要

── ここで挙げてもらった3社の事例に共通する特徴は何でしょうか?

平鍋 やはり文化ですね。どうやったら参加しやすく、みんなが同じ船に乗れるような文化ができるか。そのためにも、トップが「何のためにこれ(アジャイル)をやるのか?」を言語化できる必要があります。例えば、ANAの場合は「Be a Builder」という言葉で、ただ仕様書通りに開発するだけでないという気持ちを表しています。

このように、経営者や事業リーダーシップが「私たちは何のために存在していて、誰に対してサービスを提供しており、そのサービスがどうありたいから、アジャイルを選択している」と説明できるかどうかは大きいです。いろいろな抵抗があっても、トップの理解があるかどうかで全然違いますから。

── チームの全員がアジャイルを受け入れて考えることが大切になりますね。

平鍋 もうちょっと大きな話で言うと、アジャイルは既存のシステムにとって異物なのです。新しいものや未知のものを、わけの分からない、害があるものとしてはじき出すのは正常な免疫システムです。

ただし、僕が注目しているソフトウェアが中心になる世界はビジネスの速度が速く、変化も激しいので、自分たちもどんどん変化していくことが重要です。異物であっても取り込んで、役立つ形に変えて「自分たちのやり方はこうだ」と打ち出していかないと生き残れません。

アジャイルを取り入れた結果として、組織がどうなるのかは、その組織の話です。「こうやればできますよ」と言われた通りにやってもだめなんです。自分たちの強みにあわせて形を作ることになりますから、アジャイルの発現(かたち)はおそらく組織ごとに違うんだと思います。

── 自分たちなりに形を変えていることも、3社に共通することですね。

平鍋 最後にもう1つ、3社に共通するのは、情熱を持って変革を前に進める強烈な人材の存在です。リクシルの岩崎さん、ANAの永留さん(当時)、北國銀行の岩間さん。この方々は経営と話をしながら、現場にインスピレーションとワクワクを与える存在です。そんな方々と出会えて一緒にスクラムの仕事ができたことを、私は感謝とともに一番大切に思っています。

組織や立場を超えて、いま起きている日本の変革について真剣に話せる方々とのつながりを作ることが、アジャイルの本質なのかもしれません。皆さんの職場で、もし迷ったり、困難に直面したりすることがあったら、ぜひその話をできる仲間を社内に(もしかしたら社外に)見つけてください。きっと組織を変えるアジャイルジャーニーの伴走者になってくれると思います。

── 本日は興味深いお話をありがとうございました。

取材・構成:高橋睦美
編集:はてな編集部

平鍋健児さん近影
平鍋 健児(ひらなべ・けんじ) twitter: @hiranabe
株式会社永和システムマネジメント代表取締役社長、株式会社チェンジビジョンCTO、Scrum Inc. Japan 取締役。
顧客と共にチームで創る新しいソフトウェア受託開発を福井で実践しながら、国内外でアジャイル開発の普及活動に努める。チームをより生産的に、協調的に、創造的に、そしてなにより楽しく変えたいと考えている。2009年から13年開催している、アジャイルジャパン初代実行委員長
著書に、野中郁次郎との共著『アジャイル開発とスクラム』。翻訳書に『リーン開発の本質』『アジャイルプロジェクトマネジメント』など多数。
ブログ:an Agile Way | Software is made of conversations