平鍋氏「アジャイル開発の10年と今後を語ろう」、デブサミ2012

2012年2月20日

デベロッパーが集まるイベント「デベロッパーズサミット2012」(デブサミ2012)が、2月16日、17日の2日間、都内で開催されました。

そのセッションの1つ、日本のアジャイル開発の第一人者である平鍋健児氏が「アジャイル開発の10年と今後を語ろう」というテーマでセッションを行っています。

この記事ではその内容をダイジェストで紹介しましょう。

アジャイル開発の10年と今後を語ろう

株式会社チェンジビジョン代表 平鍋健児氏。「アジャイル開発の10年と今後を語ろう」

fig

デブサミが10周年、アジャイルソフトウェア開発宣言は2001年なので10年ちょっとたちました。僕が歩いてきた10年をみなさんと共有しつつ、次の10年について考えてみたいと思います。

まず、アジャイルの現状を復習。日本ではアジャイル開発を「XP」(eXtreme Programming)で知った人が多いと思います。その後でスクラムを知った、という人が多い。

fig

「Evo」って知ってます? トム・ギルブさんが1970年代に、PDCAサイクルをソフトウェアに当てはめたらどうなるか、ということで作った。おそらく世界最古のアジャイル開発方法論です。

その後、トヨタ生産方式(TPS、Toyota Production System)を源流にしてポペンディックさんが作った「リーン」。このあたりが経営者がアジャイル開発を知り始めた機会かなと思います。

「XP」はケント・ベックさんがパターンランゲージをソフトウェアに持ち込もうとした、正確に言うと二度目の挑戦。ソフトウェアを作るときに、お客様とどう会話するかをパターンにしたのがXPともいえます。でもケント・ベックさんは、パターンということに触れずにXPの本を書いたんだと思います。

2012年はXPだけではなくスクラムが広がってきています。昨年、フォレスターの調査でアジャイルがウォーターフォールを抜いたというレポートが出て、あきらかにキャズムを越えたと思っています。

いまはアジャイル開発を大きな組織でどう展開するか、世界中に分散したチームでどうやるか、といった話題になっていますが、それももう自然にあちこちで行われている状況になっている。

また、UX(ユーザー体験)デザインがアジャイル開発という方法論を発見して、これを使わないと、いいUXが開発できないとなっていてい、アジャイル開発とUXも結びついてきています。

ケント・ベック氏の書籍で目覚める

この本、読んだことありますか?(会場の4割ほどが挙手)

fig

これ、まだ日本のAmazonがなくて、米Amazon.comで注文して読み始めたら、止まらなくて一晩で読んでしまいました。ソフトウェアをちゃんと作るってどういうことなのか、動くものをちゃんと積み上げていこうよ、というプログラマなら誰でも持っている感覚が書いてありました。

また、ペアプログラミングとか計画会議とか、会話のプロトコルというか、開発チームをソーシャルな関係を見たときに、どのタイミングでどんなことが起こるかをデザインした本です。

この本を読んで僕が目覚めたのですが、いちばん響いたのは「リリースしたらお客さんとシャンパンの栓を抜きなさい」と書いてあって。開発の本にそう書いてあって、ぶったまげました。「ケント・ベック、おまえはオレか」(笑)という瞬間を感じました。

fig

「リーン」についてもう少し話すと、リーンというのは言葉で言えば無駄どり。在庫を持たないでどう作るか、という話。

例えば自動車は何万点という部品が集まって作られていて、川に例えるとアマゾン川のように支流がたくさんあって、それが集まって大きな川になるイメージ。

でもトヨタ生産方式では、だれかが「車がほしい」というと、カンバンで下流から信号が流れてくる。河口から支流を引っ張って流量を絞ろうとしているんですね。なぜかというと、車がいらなくなったとたんに川の面積全体が無駄になるから。本当にほしいものだけを作るのがリーン。

お客さまに価値のあるもの以外は全部無駄だと。

スクラムもカンバンも、在庫の数を絞る。ソフトウェア開発では何が無駄かというと、まだテストされていないコード、まだコードになっていない仕様など。スクラムだと1カ月という期間で区切られていて、その期間の中でしかバッファが生まれないようになっています。

フレームワークの中で、何を組み合わせてもいい

で、話は変わって、いまはアジャイル開発の何が使われているんですかねと、毎年行われているバージョンワンというところの調査結果を見ると、スクラムが52%、XP+スクラムが14%、合わせて66%なので、アジャイル開発している人の3分の2がスクラムを使っているんです。カンバンはまだ2%くらいですね。

fig

このグラフを見て気がついたことがあります。これからどうなるかを考えると、かっちりしたプロセス、方法論が薄れてきて、プラクティスの粒をどう集めてきてどう組み合わせるか。こういうやり方があるからやってみよう、というのではなく、僕たちの開発にはこういう特徴があるから、それに合わせてこれとこれのプラクティスを集めてやろうよ、というのが大事なってくるのではないかと。

スクラムもカンバンも方法論ではなくフレームワーク。そのフレームワークの中で、何を組み合わせてもいいんです。そうするとスクラムはハイブリッドにならざるを得ない。自分たちでプラクティスを選ぶんです。

カンバンも同じで、カンバンの本の中で最終的な方法論は「いまやっているやり方を付箋紙に書いて貼って、見える化してください」って書いてあるんですね。それをみんなで見て、話し合いを始めてくださいと。つまりカンバンとは、見える化から始める組織改革方法論だということなんです。

fig

昔は、カタログのように分厚い方法論の一覧があって、そこから選んでいくものでしたが、いまは薄いフレームワークがあって、そこに現場がプラクティスを足していく。トヨタ生産方式の「現場での改善」と同じです。

ものを作ることと、そのプロセスを改善することを分離するとおかしくなってしまうんですね。作っている人が考えて改善していくと。そうでないと本当にぴったりしたものはできないんですね。

で、「あと1分」という表示が運営者さんから出てますが、ここから10分くらいしゃべるつもりでいたんですが(笑)

やることと考えることは分けてはいけない

昨年、Innovation Sprintというイベントで、スクラムの生みの親のジェフ・サザーランドさんと、その基礎となった論文を書いた野中郁次郎先生を引き合わせたイベントを実現できたのですが、そのときに使われたスライドの1枚。

fig

いちばん上がNASAタイプの開発プロセス。分析、設計、実装と、それぞれのフェーズの出口にゲートがあって、プロセスを区切ってある。ところが日本のプロジェクト(ホンダのわいがやなど)はその下のタイプで、どんどん折り重なっている。

いちばん下のタイプは、最初にアイデアを考えた人が最後は現場までいく、そういうチームになっている。人がアイデアなり思いのキャリアになって現場までいく、それがスクラムの定義なんですね。

やらないと分からないことが多い。手と頭はつながっていて、やることと考えることが両方できる場作り、これができないとリーダーシップはだめなんだと。

日本からできることはまだまだあると思っています。最後に、永平寺。

fig

永平寺には修行僧がいますが、ここの修行システムを卒業して自分の寺を継ぐ、これが750年続いている。すごくサステナブルな教育システムなんです。その永平寺にこう書いてあるんです。

fig

悟りと禅。これを、悟りが目的でその手段が座禅である、そう考えてはいけないと。やることと考えることは分けてはいけないと。

そこ(開発プロセスや方法論)はまだサイエンスではないから、こうすればうまくいくという決まったやり方はなくて、やりながら考えなくてはいけないんですね。

関連記事

あわせて読みたい

DevOps アジャイル開発 スクラム




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本