アジャイルを凌駕する「超アジャイル」のすすめ
開発現場の“Why”と向き合う重要性

超アジャイルのすゝめ

2018年11月12日、KDDI DIGITAL GATEにて、Tech-onが主催するイベント「Tech-on MeetUp#03」が開催されました。今回のテーマは「アジャイル」。スクラムやカンバン方式などのアジャイル開発をそのまま導入しても、思ったような成果が出ないこともあります。そこで、現場でうまくいっている事例を実際の開発メンバーに語っていただき、その成功の秘訣と知見を共有しました。プレゼンテーション「超アジャイルのすゝめ」に登壇したのは、楽天株式会社の及部敬雄氏。彼がアジャイル開発に出会ってから今日までの軌跡と、その過程で学んだこと。そして「超アジャイル」という考え方の重要性を語ります。講演資料はこちら

超アジャイルのすゝめ

及部敬雄氏(以下、及部):カレーのようにすべてが詰まったお話をさせていただきます。よろしくお願いします。

(会場笑)

『超アジャイルのすゝめ』というタイトルで、お話させていただきます。よろしくお願いします。みなさん今日のイベントの内容を覚えてらっしゃると思いますが、実はイベント主催者が隠したメッセージがあったことにお気づきでしょうか?

今日のイベントは、たぶん次世代キャリア対戦です。

(会場笑)

「なんとかバンクさん」がいらっしゃらないんですけど、代わりにやっとむさんがいるので、たぶん大丈夫です(笑)。

最初に考えていただきたいのが、みなさん今日このイベントに何をしに来たんですか?

別に煽ってるわけじゃなくて(笑)。なぜここに来たか、もう1度、頭で考えていただきたくて。

今日のイベントページに、「いろんなアジャイルの現場のレシピが紹介されるので参考にしましょう」ということが書いてありました。

あえて僕からはこういうふうに言わせていただきます。「いい加減目を覚ませ!」と。

みなさんアジャイルの原典である「アジャイルマニフェスト」をご存じかと思うんですけど、アジャイルマニフェストが作られたのは2001年2月なんですね。約17年くらい前ですかね。

すごく雑に言うと、アジャイルマニフェストって世界の各開発現場でブイブイ言わせていた人たちが集まって、自分たちのやっていることやうまくやっていることを話し合って、その共通点や学びをまとめたものがアジャイルマニフェストだと。自分はそんなふうに思っています。

その2001年にどんなできごとがあったか調べてみたんですけど、小泉純一郎内閣が発足している年なんですね。

もちろんまだスマートフォンはありませんし、クラウドもないです。Googleは2004年くらいに上場しているので、まだ上場前ですね。

技術要素だと、Javaはまだ1.3で、PHPはPHP4の時代ですね。Rubyはあったんですけど、Railsはまだ存在していない頃です。

なぜアジャイルを超えるのか?

ずっと自分が考えていたこととして、アジャイルは確かにすばらしいし、すごく学ぶことがたくさんあって、今でもたくさん学べることがあるんですが。

ただ、いつの日か誰かが考えたうまいやり方を真似していくということになってしまうだけだとおもしろくないなぁって、やっぱりやっていくと思うわけですね。

もちろん彼らはすばらしいんですが、僕らは現場にいる限り彼らに追いついて彼らを追い越していきたい。少なくとも「今自分たちのいる現場で今の時代の技術を使ってプロダクトを作る」ということにおいては、世界で1番うまくありたいと思っているからこそ、みなさん今日わざわざ時間を割いて勉強会に来たりしているのかなぁと思っています。

だから僕は「アジャイルを超えたい」という想いを今日みなさんにお話したくて、このタイトルにさせていただきました。

なぜアジャイルを超えるのかという話と、なぜそれをみなさんにすすめるのかという話をさせていただきます。

僕は今日はライトニングトークくらいのノリだと思っていたので、ここまですごく煽り気味でやっちゃったんですけど(笑)。ここからは少しまじめにお話しします。

改めて自己紹介ですが、楽天株式会社でエンジニアリングマネージャーをやっている、及部敬雄と申します。大事なことなんですけど、現在育休中でございます。育休中なのでお手柔らかによろしくお願いします。

最近はモブプログラミングに関するお話をさせていただくことが多くて。『WEB+DB PRESS』にも書いたりしているんですが、今日は佐野さんが僕よりも前に話をして、しかもモブプロの話をするということで、将棋で言うと飛車角落ちの状態で話をする、というのは冗談ですが。

モブプロの話は若干話しすぎて食傷気味のところもあったので、今日は話したいことを話せるということですごく楽しみにしていました。

アジャイル開発を整理する

本題に戻ります。ちょっとアジャイルについて一緒に整理したいなと思って。みなさんは僕なんかよりも大変お詳しいと思うので恐縮なんですけれども、自分の頭の整理にお付き合いいただければと思います。

アジャイルソフトウェア開発宣言の中に出てくるキーワードというのをまとめてみました。

いくつか挙げると、「顧客満足の最大化」「早く継続的に」とかいろいろあるんですけど、これってすごく当たり前だと思っていて。

「僕らが当たり前に目指していきたいプロダクト開発の理想像が書いてある」というのが、最初に見たときからずっと今でも変わらず思っている印象です。

WhyとHowとWhatに分けて図にまとめてみました。さっき言ったとおり、アジャイルマニフェストはいろんな現場にいる人たちが、自分たちがうまくやったやり方を持ち寄っています。

現場で問題を抱えているBeforeの状態があって、それに対してAfter、こんなふうにしたいよねっていう理想像があって、そこに至る解決手段、プロセスがあります。

これを抽象化した結果、どんな開発現場がいいかなという理想像は、さっきのアジャイルソフトウェア開発宣言に書いてありました。

よくみなさんが話すプラクティスの話はあくまでこの図の中のHowの部分です。「アジャイルは形容詞」という話がよく出てきますが、理想像に向かっていくベクトルこそがアジャイルなのかなと自分の中では整理しています。

こういうイベントに参加していろんな現場の話を聞いていると、どうしてもHowを持ち帰りたいと思ってしまうし、別にそれが間違いではないんですけど。同じくらいこのベクトルが存在しているかがすごく大事で。

いろんな現場のHowもこのベクトルの上に乗っかっているから初めて効いてくるものなので。このベクトルを自分たちで作っていけるかどうかというのがなにより大事なのかなと思っています。

なので、「Start with WHY」で、ちゃんと自分たちで現場のWhyから始めていかなきゃいけません。最初に「なぜここにいるのか?」という問いかけをしたんですが、今日はぜひこの問いをみなさん頭の中で考えながら聞いてほしいと思っています。

なぜみなさんがアジャイル開発に日々取り組んでいるのか? という部分と、あるいは取り組んでないにしても今日こういう勉強会に来るということはなにかしら興味があって来ていると思うので、なんでそれに興味を持っているか? ということを頭で考えながらぜひ聞いてください。

アジャイルとの出会い

自分とアジャイルの年表を簡単にまとめてみました。自分のWhyの話を紹介します。

僕は、2009年にプログラミング未経験からエンジニアになったんですが、アジャイルに出会ったのは2011年くらいです。

最初の頃は、エンジニア自体が初めてだったので、そもそもなにをしたらいいかわからない状況から始まっています。よくある、もしかしたら今もみなさんの近くにあるかもしれないような現場で、ただただ目の前の仕事をこなすっていう仕事をしていました。

そこで師匠みたいな人と出会って、朝いきなり立ってミーティング始めたりというのを実際に体験して、それがあとから実はアジャイルやスクラムという名前が付いているのを知った、というのが僕のアジャイルとの出会いです。

さっきのBeforeとAfterで言うと、変化を自分の中で感じたというところがありました。

ここで何が1番大事だったかと言うと、当たり前だと思っていたこととぜんぜん違うやり方を体験して、要は自分の中の当たり前がぶっ壊れたというのが僕のアジャイルとの出会いでした。

“もっといいやり方”を探して

ここで初めてWhyが生まれたわけですね。「もっといいやり方があるんじゃないかな?」と思い始めて、ちょっとずつ自分の範囲が広がっていくというのがこのあとの話です。

受託でも内製でも同じだと思いますが、ビジネス側と開発側に分かれていて、間にインターフェースが存在して仕事が回るみたいな構図がよくあります。

この時に開発のスピードが遅いとだんだん要件が溜まっていって、不満が溜まっていくみたいのがよく起こりがちで。結果として現場が炎上してしまったりします。

このボトルネックを解消するために開発のスピードを上げていって、要件ではなくて信頼貯金を貯めていきたいから、みなさん開発の現場の改善をしていくわけですね。

これをずっと繰り返していくと何が起きるかと言うと、今度は要件が足りなくなります。どんどん開発が終わってしまうので今度は要件をつくるところにボトルネックが移るということだいたいどの現場でも発生して、僕も何回か経験しています。

ここでまた新しいWhyが浮かんで来たんですね。「なんでビジネスと開発が分かれちゃってるのかな?」というWhyが出ました。

ということで開発チームからビジネスとかプロダクトのほうに自分の興味がだんだん広がっていって、ビジネス側の人たちも巻き込んで一緒にカンバンをやろうとか、一緒に朝礼をやろうというところから始めていきました。

カンバンのやり方自体も工夫をして、「価値創造カンバン」って勝手に名前を付けて、ビジネスと開発一緒にカンバンを作りました。

これを作ったときに仮説を持っていて、「ビジネス側から生まれたチケットがToDo→Doing→Doneと進んで、開発側にチケットが進んでいく」って思うじゃないですか。実際に計測したらわかったことが、だいたいチケットの流れがビジネス側のDoneで終わっていくんですよ。

左から右まで流れていくチケットの数がすごく少なくて、ビジネス側はビジネス側だけで完結する仕事をし過ぎていて、なかなか開発につながる仕事に時間を割けていない、ということがこのカンバンをやってみてわかりました。

Whyと向き合うことがプラクティスになる

こういうことを繰り返していくと、また今度は違うボトルネックが見つかります。ボトルネックはどんどん移動していくんですね。今度はなにが起こるかと言うと、ビジネス側とうまくいくようになったと思ったら、ぜんぜん関係ないところから横槍が入ってきてチームの邪魔をされるということが起きました。

ここでまた「なんでチームが邪魔されてしまうのか?」という新しいWhyが生まれました。だんだんとまた興味の範囲が広がっていって、ビジネス・プロダクトという部分から組織という部分に広がっていきました。

未来会議自体はやられている方がいたので僕はあえて違う名前を付けて。そのころ『シン・ゴジラ』が流行っていたので、「シン・未来会議」っていう名前をつけました(笑)。

「シン・未来会議をやりますよ」って声をかけて、課長とかも集めて、全員でディスカッションをして組織の改善の話し合いをする場を作りました。エンジニアもマネージャーも全員フラットに自分たちの組織のことを考えるという場です。

このように、「自分に生まれたWhyとそのときやってきたこと」をまとめてきました。これは今まで自分がプレゼンさせてもらってきた資料の一部です。

自分は自分が経験したことややったことしかお話しかできないので、自分の生きた証だったり、そのとき一緒に働いていた人たちとの思い出なんですけど。

つまり、次々現場で生まれてくるWhyに向き合って改善してきたことがプラクティスであり、自分の中の引き出しが増えていったということなんですね。

「分担=生産性が高い」という思い込み

こんなことをずっとやってきて、もちろん学びは常にあるんですが、最近衝撃的な学びがありました。

1つ目は、モブプログラミングです。

モブプロの説明は飛ばしますが、僕がよくお話するときにモブプロの最大の学びとしていつも紹介していることがあって。

僕はこれまでお話したようにアジャイルを知る前からいろんな開発でチームを改善していく、という経験をずっとしてきて。スクラムとかアジャイルに関してもあくまで分担することを前提にして、その分担をいかに効率的にやるかということが頭の中にありました。

それはおそらく分担することが「生産性が高い」という思考停止というか、前提に囚われてしまっていて、実は改善の範囲が狭まっていた、ということなのかもしれません。

分担作業がいいとか、モブワークがいいとかいう話ではなくて。たぶん向き不向きがあるということです。

仕事の質やチームの状況に合わせて使い分けることができるのが1番望ましいじゃないですか、当たり前だと思うんですけど。

なので働き方としてのモブプロをしているという話をしていますが、「働き方として」というのは、常にずっと全員で画面を見て作業しているわけではなくて、勝手にそのときの状況で使い分けて、モブプロと分担をうまくわけながら作業をしているというのが実情だったりします。

モブプロを始めたのは1年ちょっと前なんですけど、チームメンバー全員がアジャイル開発の経験を持っている人たちだったんです。それでも「今までで1番アジャイルっぽいことやってるよね」っていう感想が振り返りであがるくらいの学びを得ることができました。

新入社員へのプログラミング研修を通して気づいたこと

そしてもう1つ最近すごく衝撃を受けたことがありました。今年4月にビジネス採用の新卒が260人入社した時のことです。楽天は開発配属は通年採用になっているので、全員がビジネス配属予定の新卒です。

いきなり社長が入社式で「これからはプログラミングだ」というお話をされて、ビジネス配属の新卒にプログラミングの研修を半年くらいかけて実際にやることになり。そのときにいろいろあって、僕らがその研修をお手伝いすることになり(笑)。

どうしようかなと考えたらやっぱり最強の研修がやりたいなってなんとなく思って。

研修だから研修っぽいことをやるんじゃなくて実際の仕事になるべく近いことから学んでもらいたいということです。

あとは自分たちがふだんやっていることを当たり前にやってもらいました。モブプロも含めて、今こういうふうにしたほうがいいよねっていう最前線のものというのをやってもらうことにしました。

「研修する僕らが受けたいと思う研修を作る」ということが、最強の研修の定義です。最強のメンター陣にご協力いただいて、本当に最前線でやってる現場の取り組みを教えてもらいました。

本当にいろんなことをやっていて、スクラムももちろんやっているんですけど、1day sprintとか1hour sprintとか、モブプロもやってもらったり。本当にいろんなことをやっています。

簡単にどんなことをやったかと言うと、基本は1day sprintをベースにしていて。1day sprintを回しながら1週間に1回実際の事業の人に自分たちの作ったプロダクトを見せてフィードバックをもらうことを繰り返して、自分たちのプロダクトを作っていくということをやってもらいました。

「学んでいない」ということが強みになる

結果どうなったかというと、数ヶ月前にプログラミングを始めた彼らがいろんなプラクティスを自分たちで当たり前のように使いこなして、自分たちのチームと仕事の仕方を改善しながらすばらしいプロダクトを作って。

ビジネスメンバーの人が驚いて、実際に自分たちの事業にこのプロダクトを使いたいとかこのアイデアを取り入れたいっていうくらいのものがいくつもできるという結果になりました。

その結果自体も素晴らしいんですが、彼らは僕らメンター全員の想像を軽く超えていったんですね。何が今回重要だったのか考えてみたんですけど、彼らは「学んでいない」んですよ。僕らがふだん経験していることをやっていない。

要するに、「こうやってやるのが普通だよね」がなく、僕らが言ったことを「わからんけどとりあえずやってみよう」って素直に受け止めた結果です。「学んでいない」ということが彼らの強みだったということかな、と。

自分の過去のスライドの中で、例えば「身の丈に合った改善活動をしていきましょう」「まず目の前のことを1個ずつ改善していきましょう」というメッセージをよく入れていました。

それが間違いだったわけではないんですけど、僕はこれが唯一の解だなとずっと思っていたんですが、それが否定されるくらいの驚きがありました。これまでももっとうまくやれる方法があったんじゃないかなっていう振り返りをしたくなりました。

このあたりはRegional Scrum Gathering Tokyo 2019で、新卒の彼らと一緒にお話しすることになったのでぜひ興味がある方は聞いていただければなと思ってます。

どれだけやってもWhyは尽きない

だんだんまとめに入っていきます。

このようにどれだけやり続けてきてもWhyが尽きないんですよね。今になって気づく間違いとか、実は思い込みに嵌ってしまっていたというような学びがたくさん見つかります。

なので教科書にこだわっている場合じゃないし、よく「正しいアジャイル」や「アジャイルは死んだ」とか、そんなことを気にしている暇はないです。

だから超アジャイル。アジャイルを超えていくくらいのつもりでやっていく必要があるかなと思ってます。

もし次のアジャイルのようなものが作られるとしたら、その時にブイブイ言わせている現場の事例を集める時に、自分たちの現場の事例をそこに載せることができるかどうかというところが僕らがやってる勝負かなと思ってます。

今後取り組んでいきたいこと

僕が近い将来にやりたいなと思っていることが3つくらいあるので、簡単にご紹介します。

1つ目はモブプロをもっとうまくやること。僕らは新規事業でやっていたので、業態や規模が変わってもどうやってうまくやるかということはやってみたいなと思っています。

2つ目はスプリント期間の工夫をもっとしてみたいということ。

そして3つ目は、これは新卒から学んだことです。彼らには「学んでいない」という強みがありました。僕らも彼らに現時点でのスキルではなくて成長率で負けないようにしなきゃいけないと思っていて。

僕らはふだんどのように自分たちの経験に上積みしていくかを考えていますが、あえて今までの自分たちの学びを捨てて学び直すみたいなことを、もっとうまくチーム開発に取り込めないかなということを考えたりしています。

Chaos Monkeyのように敢えて障害を起こしてテストをするという発想があると思いますが、チームやプロセスに関しても同じような仕組みを入れて、自分たちの学びをもっと活性化させていく取り組みができないかなということを考えています。

昔正しかったやり方や教科書に載っているやり方が今正しいとは限らないし、今正しいと言われているやり方がみなさんにとって正しいとは限らないわけですよね。

アジャイルを超えていこうとするベクトル自体がアジャイルなのかなと思って、今日は「超アジャイル」という話をさせてもらいました。

そして、そのためにはやっぱりWhyが大事なので、あえて今日はHowじゃなくてWhyの話をしました。

注意としては、教科書や型が必要ないという話をしているわけではないですし、ましてやダメなカスタマイズをして自分たちの都合のいいアジャイルを推し薦めたいわけではありません。

大事なことは「今よりももっとうまくなろう」ということです。

まだ始めてない方は始めてみればいい。真似することから始めればいいかもしれないし、誰か強い人を連れてきて一緒にやってもらえばいいかもしれない。

そして今やってる人たちは今やってること、ちょっと自分たちがうまくいっていることに満足するんじゃなくて、「アジャイルを超えていく」「あのチームよりもっと自分たちはうまくなろう」という感じで、どんどんうまくなって、最終的には世界で1番になるつもりでやっていくのがすごく大事かなと。

日本発のアジャイルを世界一に

今日話していた人(の話)を聞いていて思いついてさっき1枚スライドを追加しました。名前って大事だなって。自分たちがやったことに名前を付けちゃえばいいと思うんですよ。

「〇〇やりました」って、自分たちのプラクティスかのように言うってことがすごく大事で。日本人は苦手ですよね。けっこう海外だとたいしたことやってないのに「なんとかレボリューション」とかって名前を付けたりして。

前にアジャイルカンファレンスに出たときに「カンバンレボリューション」っていうすごく楽しみなセッションがあったんですけど、参加してみたらぜんぜんおもしろくなかったっていう体験をしたんですけど(笑)。それくらい「やっちゃえ!」っていう精神でもいいのかなと思っています。

これが最後のスライドですが、僕は日本から発信したアジャイルの事例が「世界一になる」というのが夢です。ぜひみなさんと一緒にアジャイルを超えて行きたいです。ぜひみなさんで世界一になりましょう。

以上です。ありがとうございました。

(会場拍手)

Occurred on , Published at

Tech-on MeetUp

「技術者同士を、人と人とのネットワーキングで繋ぐ」をテーマに、新しい知識創造の「場」を提供する技術者コミュニティ。

スピーカーをフォロー

関連タグ

人気ログ

人気スピーカー

人気コミュニティ

ピックアップ

編集部のオススメ

ログミーTechをフォローして最新情報をチェックしよう!

人気ログ

人気スピーカー

人気コミュニティ

ピックアップ

編集部のオススメ

そのイベント、ログしないなんて
もったいない!
苦労して企画や集客したイベント「その場限り」になっていませんか?