2001年に公開された「アジャイルソフトウェア開発宣言」から20年以上が経過しています。この間、現場で自ら試行錯誤を繰り返しつつアジャイルへ挑み続けてきた、レッドジャーニーの市谷 聡啓中村 洋が、アジャイルとの出会い、うまくいったことや壁にぶつかったこと、具体的な打開策など7つのトピックスをテーマに対談しました。20年以上にわたるアジャイル実践経験がもたらした最も大きな成果とは?親交の深いふたりのアジャイル実践者が、アジャイルの過去と現在、そして未来を忌憚なく語ります。

話し手

市谷 聡啓 Toshihiro Ichitani

株式会社レッドジャーニー 代表
元政府CIO補佐官
DevLOVE オーガナイザー

サービスや事業についてのアイデア段階の構想から、コンセプトを練り上げていく仮説検証とアジャイル開発の運営について経験が厚い。プログラマーからキャリアをスタートし、SIerでのプロジェクトマネジメント、大規模インターネットサービスのプロデューサー、アジャイル開発の実践を経て、自らの会社を立ち上げる。それぞれの局面から得られた実践知で、ソフトウェアの共創に辿り着くべく越境し続けている。訳書に「リーン開発の現場」がある。著書に「カイゼン・ジャーニー」「正しいものを正しくつくる」「チーム・ジャーニー」「いちばんやさしいアジャイル開発の教本」がある。

中村 洋 Yoh Nakamura

株式会社レッドジャーニー
A-CSM(アドバンスド認定スクラムマスター)・CSPO(認定プロダクトオーナー)

様々な規模のSIerや事業会社でのアジャイル開発に取り組み、今に至る。現在まで主に事業会社を中心に40の組織、80のチームの支援をしてきた。
「ええと思うなら、やったらよろしいやん」を口癖に、チームや組織が自分たちで”今よりいい感じになっていく”ように支援している。
【発表資料】 「いい感じのチーム」へのジャーニー、チームの状況に合ったいろいろなタイプのスクラムマスターの見つけ方、アジャイルコーチが見てきた組織の壁とその越え方、など多数。

アジャイルとの出会いとこれまで。

中村:はじめに、我々二人がどんな風にアジャイルと出会ったのか、身の上話(笑)をしましょうか。私は、2001年頃だと思うのですが、SES(システムエンジニアリングサービス)として会社の情報システム部門の現場に常駐して、社内向けのソフトウェアを作ったりしていたんです。ウォーターフォールでの開発に難しさを感じていたところにXPの白本(「XPエクストリーム・プログラミング入門―変化を受け入れる」2000 Kent Beck)と出会いました。「なんだこれは⁈よく分からないけど、面白そう」と感じたのが最初の出会いでした。

市谷:私も、だいたい同じくらいの時期です。社会人になったのが2001年で、翌2002年『達人プログラマー』(『達人プログラマー 職人から名匠への道』2000  Andrew Hunt、 David Thomas)という本と出会いました。本の中にあった「ライトウェイトなプロセス、言語」という言葉がものすごく刺さって。XPと出会ったのはその後です。

中村:スタートは二人ともXPなんですね。スクラムと出会ったタイミングは、それからしばらく経ってからですか?

市谷:そのあたりの経緯は語り出すと止まらなくなる気がするので、手短に(笑)。アジャイルに取り組んできた20年のうち前半の10年は苦戦の連続で、まるで「幻の珍獣」でもつかまえるかのように、てんで現実味がなかったんですよね。

中村:わかります。XPを実践しようとしても全然うまくいかなくて、SIerにいた頃は少し距離を置いていました。その後、社内でチームを組んで開発をするようになり、アジャイル開発やスクラムと再会して…しっかり取り組んだのはそこからだったと思います。

市谷:距離を置いていたのは私も同じです。白本を読んで「素晴らしい」と感じたものの、どうしても現実味がないというか、ひょっとしたら「アジャイルごっこ」なのではないか、と。言葉だけが先行して、実際はお客様を置いてけぼりにしているのではないかと感じて、懐疑的になっていました。

 その後、XP祭り(XPの普及を目的としたユーザグループである日本XPユーザグループ(XPJUG)が主催するイベント。2002年より毎年秋に開催されている)に参加して、先輩方の話を聞きました。木下さん(木下史彦さん)が「顧客は重要」と言っているのを聞いて、懐疑的だった見方が変わり、それから学びなおしたんです。洋さんは、先達の姿を見て「がんばらなくては」と感じたことはありませんでしたか?

中村:私が影響を受けたのは、はじめの頃に出会った西村直人さんやryuzeeさん(吉羽龍太郎さん)、騎郎さん(原田騎郎さん)かな。

市谷:そういえば、我々二人をつないでくれたのは倉貫さん(倉貫義人さん)でしたね。当時、XP祭りの会長を務められていたと思います。

中村:そうでしたね。

SIerでのアジャイル経験

中村:我々二人ともSIerでのアジャイル経験があるわけですが、どのように実践されていましたか?

 私は、或るお客様が、「もの」(プロダクト)を見て触りながら一週間・二週間単位で一緒に開発を進めたいとおっしゃって、当時は「アジャイル」という言葉こそ使いませんでしたが、そういう方法で進めていたことがありました。今になって思えば、もしかしたらその方はアジャイルをご存知で、私が知らないと思ってそんな風に伝えてくださったのかもしれませんね。

 そのときは請負に近い契約形態をとっていて、予算の範囲内で目的の機能が実現できれば、細かいところはわりと柔軟に作ることができました。週に一度、客先へ行って、工場の現場の方と情シスの方と私たちで会議室に集まって一緒にプロダクトレビューに取り組んでいましたね。私たちは、契約社員とかプロパーとか雇用形態を問わず、みんなで客先へ行っていました。もちろん、まったくアジャイルじゃないプロジェクトもありました。

市谷:アジャイルに取り組みはじめて最初の10年は本当に大変だったから、SIerでのアジャイル経験というと、その苦労を思い出してしまいますね。どうしたら実現できるのか?と、例えば契約についての話をずっとしていたりしました。

中村:そうでしたよね。契約の壁を突破すると、また次の壁が出てくる。「ドキュメントは何を書いたらいいのか?」「ガントチャートはないのか?」とか…。

 そういえば、チームでテストコードを書いていたとき、品質保証部門から「バグ率が低すぎる。本当はテストしていないのではないか?」と問い合わせを受けたことがありました。テストコードを書きながらやっていて、テストフェーズに入るまでに目立ったバグはほとんどつぶせていたので、バグ率が低いのは当たり前と言えば当たり前なんですけど、なかなか信じてもらえず苦労した記憶があります。

市谷:信頼度成長曲線(テストで発見されるバグ数をグラフにしたもの)というのがありますからね。バグが出ていないとおかしいだろう、という観点が確かにあった気がしますね。

中村:いい思い出です(笑)

アジャイルのマインドセットの共有を進める打開策とは?

中村:アジャイルがそもそも知られていないのか、知られてはいるものの定着していかないのか、いろんなパターンがあると思いますが、いずれにせよ理由は2つあると思います。

 1つは、プラクティスが先行しがちであることです。ふりかえりや朝会、スクラムといったプラクティスを取り入れるだけで、その奥にあるマインドセットまで理解することなく終わるということがあるのではないでしょうか。

 もう1つは、これまで培ってきた価値観や考え方をアップデートするのが難しく、なかなか変えられないということです。その人自身のバックグラウンドは変わりませんから。ただ、本当に必要性を感じていれば自ずと変わるはずですから、変える動機がないとも言えます。打開策は…20年かけてようやくここまできましたから、あと10年くらいかかるかな(笑)

市谷:ほかに考えられるのは、恐らく「ふりかえり」が出来ていないのではないでしょうか。何かしらの取り組みやプラクティスをしたとき、うまくいくこともあれば、うまくいかないこと、思うようにならないことが必ずあると思います。その理由の一つとして、アジャイルの原則や価値観への理解が足りないために、先へ進むにつれてズレが生じてしまうことがあります。

 やってみることはすごくいいことです。やってみて、もっとうまくいくにはどうしたらいいのか?と考えるとき、原則や価値観に立ち戻って考え、対話してみればいいと思います。打開策は、ふりかえりですよ。

中村:私が支援している現場では、ほとんどの現場でスクラムガイドの読み合わせをしています。合わせてアジャイル開発宣言の読み解き方を一緒に考えたり、原則や価値観を前にどう解釈するか?という話をするのですが、そういうことを地道にやっていくのも、打開策の一つかもしれません

市谷:そうですね。解釈も受けとめ方も幅が広いですし、実際にどう行動に移すかとなるとさらに広がると思います。

中村:打開策ということでは、まず一緒に実践してみることでしょうか。小さくやって小さくフィードバックをもらうことで、少しずつ腑に落としていけると、アジャイルのマインドセットに少しずつ近づいていけるかもしれません。

市谷あまり難しく捉えずに、都度ふりかえりをしながら、「もっとうまくいくには?」と、スクラムガイドなどの原則に則って考えていけばいいんじゃないでしょうか。

アジャイルコーチとして「このチームはもうコーチがいなくても大丈夫」と思えるのはどんなとき?

中村チームとしてアジャイルの文脈で学び方やそれらを検査するあり方が身についていたら、コーチとしては自分がいなくても大丈夫という感じがします。自分たちがどれだけいいものを作ったかではなく、ユーザーの課題解決や、事業として成り立っているかに目を向けて、そういう観点でチームの対話ができていれば、もう言うことありません。このチームは、今後どんな変化があっても自分たちで乗り越えていけると感じられたら心強いですね。

市谷:自分たちの今の状態について自分たちで判断できるものさしが持てたら、ということですね。取り組みをふりかえると、いろんな改善点や考えるべき観点が際限なく出てくると思います。自分たちの状態を見て、何ができていて、何ができるようになって、次に何をしたらいいのか、自分たちで分かるようになっていたら、たしかに「アジャイルになっている」と言えるのかもしれません。

中村:チェックリストがあるわけじゃないですからね。○○ができるようになったら免許皆伝という仕組みでもありません。自分たちが荒波にさらされたときに、自分たちなりの軸を持って考え、対処をして、その結果と向き合い、よりうまくいくには?というカイゼンの話をして…ということが、チームとして当たり前にできるようになったら、大丈夫と言えるのではないでしょうか。

「ユニコーン企業のひみつ」(「ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方」2021 Jonathan Rasmusson)という本で、「アジャイルは今やふつう」と書かれていますが、日本では実際どの程度「ふつう」になったと感じますか?

中村:20年前と比べると、言葉として知っている人は圧倒的に増えたのではないでしょうか。朝会などのプラクティスが行われる機会も増えたでしょう。ただ、アジャイルの価値観や原則を普段の組織の活動の中でどれくらい実践できているかというと、まだまだ「ふつう」と言うには程遠いのではないかと感じます。

市谷:私もそう思います。活動の過程を通してアジャイルができていると感じる組織は、私が見る限り皆無と言ってもいいですし、とても「ふつう」とは言えないんじゃないかと思います。DX白書(DX白書2021 IPA)を見ても、日本のアジャイル活用状況はわずかに20%未満です。

 ただ、近年のDXの機運では、経営層など開発部門以外の部門の方たちとも、アジャイルという言葉を使って会話が成り立っていますから、20年前と比べたらずっと進んでいるのは確かです。

IPA DX白書2021より

プロダクト開発のアジャイルと組織のアジャイル、違いと共通点は?

中村:組織のアジャイルではステークホルダーの見ているものがバラバラすぎるということが大きな違いではないでしょうか。プロダクト開発の場合は方向性がある程度揃っていることが多いので、幅はあっても会話ができます。一方、組織のアジャイルとなると「そもそも組織って何?」というところから始めなくてはならないこともあります。

 もう一つ、プロダクト開発ではアウトカムとしてのプロダクトが存在するので評価がしやすいけど、組織がうまくいっているかどうかの評価はしにくいという違いもありますね。

市谷:違いも共通点も結構あると思いますが、大きく違うのは取り組み方です。組織のアジャイルでは膨大なバックログの洗い出しだけで疲弊し頓挫してしまいます。ソフトウェア開発の考え方を組織のアジャイルにそのまま当てはめてもうまくいかないと思います。

 第一に、ソフトウェア開発ではプロダクトという明確な目標がありますが、組織のアジャイルにはそれがありません。バックログを洗い出してみても、縦割りの組織構造の中では誰もが自分事として捉えられず次に繋がっていきません。共通の目標がない場面でどういう風にアジャイルをしていくのか?これは興味深い課題です。

中村:プロダクト開発でも目標を見失うことはありますが、立ち止まってみると北極星(指標や目標)は必ず見つかりますよね。

市谷ソフトウェア開発では目標があっても目的を見失うことがあります。誰のどんなニーズのためだったのかが分からなくても、一応形にはなってしまう。組織では売上や収益など一応の目標はあると思いますが、それをもとに隣の席の人や違う部署のメンバーと意識を揃えられるかというと難しいですよね。

中村:一人一人の腹落ち感が最終的には大事だったり、感情的なわだかまりがあればそれを解きほぐすようにアプローチしないとうまくいかないところは、共通点だと思います。ロジックだけでは決してうまくいきません

市谷:たしかに、大事にしなくてはならないところはどちらも同じだと思います。そもそもチームで仕事をすることに慣れていないこともよくあって、そういう時はまず前提としてチームという言葉の概念から捉え直さないと、どんどんずれていきますよね。

アジャイル開発手法で開発してやっぱりよかったと実感した印象的なエピソードは?

中村:アジャイルと言っていいかどうかは分かりませんが、私がXPと出会った頃のエピソードが印象に残っています。

 工場の経理部門で働くユーザーさんのためにソフトウェアを作っていたのですが、最初は書かれた仕様書の通りに作ったんです。しばらくして、「使っていますか?」と訊くと「使いにくい」と。恐らく、上司にしかヒアリングせずに仕様書を作成したのでしょう。実際に見に行ってみると、まったくユーザーさんの実情にフィットしていなかったんです。

 ユーザーさんの隣に座って会話しながら一緒に作っていくと、日に日に使いやすくなり、ユーザーさんの表情もどんどん変化していきました。上司に伝えても実際に出来てくるものは自分の希望とずれているということが、恐らくずっと繰り返されてきたのでしょうね。「自分の伝えたことがちゃんと実現してもらえる」という実感があらわれた嬉しそうな表情が、今でも印象に残っています。

市谷:そういう風に感情の変化があるとすごくいいし、やっていてよかったと思いますね。私も、印象深い出来事というといろいろあります。例えば、アジャイルではスプリントのたびに方向性を考えるチャンスがやってきますが、そこで「途中で止める」という判断をすることがあります。進めるだけじゃなくて止めるという判断ができたことは印象深いですね

中村:止めたことは結構ありますか?

市谷:比較的多いかもしれないですね。永続的に止めることもありますし、一時的な中断は1プロジェクトに1回くらいはあるんじゃないでしょうか。

中村:惰性でこなすよりも、一旦スプリントを止めて立ち戻ったり整理した方がいいことってありますよね。私は、アジャイル関連のコミュニティでいろんな人と出会えたことや、アジャイルの価値観そのものが人生に役立っていると感じます。それも、やっていてよかったと感じることですね。

市谷:同感です。20年かけて到達できた大きな成果だと思いますね。20年前、よく分からないまま白い本だけを頼りにアジャイルを始めて、半分くらいは失敗の連続でしたが、そうして続けてきて、今、伝統的な大企業でアジャイルが取り入れられています。やってきてよかったなと思います。

中村:20年前の白本を読んでいる自分に、「役立つと思うよ!」って言ってあげたいですよね(笑)。

市谷:何の拠り所もなく、信じるしかなかったですからね。日々仕事をしていて感じる「何か違う」「これはおかしいんじゃないか?」「もう少しうまくやれるのではないか?」という違和感は、誰もが心の底に持っているものだと思います。今までの日本の組織では、それを聞こえないことにしてやってきたようなところがあったかもしれません。もっと、素直な気持ちを大切にしていけたらいいですよね。

中村:そうですね。今日は7つのトピックスをテーマに対談してきました。今後も月に一度くらいのペースで続けていきたいですね。

市谷:今度は聞き手の皆さんにも参加していただいて、もっとインタラクティブにやってみたいです。

中村:いいですね。ぜひやってみましょう。今日はありがとうございました。

市谷:ありがとうございました。

仮説検証型アジャイル開発 特設ページ