平鍋健児氏(チェンジビジョン代表取締役) 「アジャイル開発とスクラム」(1)

派生開発カンファレンス企業講演

 開発と保守・改造を並行して進めていくという意味では、昨今話題の「アジャイル」と派生開発には何となく共通点があるようなのだが、どこがどのように通底しているのか判然としない。カンファレンス運営委員会にも同じ思いの人がいたのだろう、基調講演がアジャイルの伝道師として名高い平鍋健児氏(チェンジビジョン代表)による「アジャイル開発とスクラム〜顧客・技術・経営をつなぐ協調的マネジメント〜」——となれば、おのずから講演採録ということになる。

司会 基調講演に入る前に企画意図を申し上げておきます。1つは皆さん、1日中、XDDPとUSDMにとっぷり漬かって、そろそろ違う話で気分転換しつつ、気づきを得ていただきたいなぁということです。もう1つは、せっかくこれだけ多くの開発者に集まっていただいて、日ごろ皆さん、辛い思いとか苦しい思いをなさっておられると思うんで、ここで元気になっていただこうと考えました。あれこれ考えまして、ちょっと派生開発との親和性はどうなんだろうということはあるんですが、いま非常に活躍されている株式会社チェンジビジョン代表取締役の平鍋健児さんにお願いすることにしました。では平鍋さん、よろしくお願いします。(拍手)

平鍋 え〜、皆さん、こんにちわ。(会場から「こんにちわ」)チェンジビジョンの平鍋と申します。ご紹介ありがとうございました。まずタイトルなんですが、もしかしたら「派生開発とスクラム」というのでもよかったんですが、ここはストレートに「アジャイル開発とスクラム」にしました。
 私自身もソフトのエンジニアでした。で、日本のソフト開発の現場って、皆さん、苦しくないですか? 辛くなることがよくあるじゃないですか。うん、うん、って頷いている方が何人かいるようですが、なんとかしていい方向に……開発現場の人って、いいものを作ろうといつも考えているんですよね。なのになぜかうまくいかない。なぜなのかなぁ、と考えてきたら、それを解決する一つの方法が、わたしはアジャイルだ、と。そして清水先生(吉男氏)はXDDP、派生開発だ、と。解きたい問題は同じなんだけれど、方法が違うだけなんだ、ということです。
 簡単に自己紹介をしますと、わたしはチェンジビジョンの代表取締役で、永和システムマネジメントという会社の副社長をしています。永和システムマネジメントという会社は福井市にありまして、いつもですね、「福井から来ました」と挨拶しますと、「あら、九州から遠い所をよくいらっしゃいました」と言われます(笑)。福井というのは九州じゃなくて北陸ですので、よろしくお願いします。
作る喜びを開発の現場に

 最近の話題ですと、新幹線ですね。北陸新幹線が開通しまして、これまでは福井から米原経由で名古屋に出まして、東京まで3時間30分だったんですが、新幹線ですと金沢、長野回りで3時間25分(笑)。ちょっとだけ早くなりました。現在は金沢までなので、福井まで通じるともっと早くなるんですが。

 それとチェンジビジョンは「Astah」というソフト、昔は「JUDE」といったんですが、使ったことがある、という方、どれくらい……、(挙手の様子を見て)あ、ほぼ100%ですね(笑)。ありがとうございます。ぼくが作ったソフトなんです。
 これをですね、世界に売っていきたいな、と考えてずっと活動しています。ユーザーは日本がいちばん多いんですが、次に多いのはブラジルなんですよね。買っていただいているのはアメリカ。ブラジルでは教育用に使っていただいているんですが、ほぼ買ってもらえない(笑)。
 ですがときどき激励というか、「いいソフトを作ってくれてありがとう」といったメールが入るんですね。作った人間として、それだけで嬉しくなったりします。作ったものがお客さんのもとに届いて、役に立ってお礼を言われる。そういうのって開発者にとっては素朴な喜びなんですね。その喜びをソフト開発の現場に取り戻したい、というのがいちばんのモチベーションになっています。
 ここに何冊かぼくが書いた、共著もたくさんありますが、本があるんですが、オブジェクト指向とかC#とか……。XXXって書いてあるのが「エクストリーム・プログラミング」、おそらく日本で最初にブレークしたというか、たくさんの人が認識したアジャイル手法の1つです。これが2001年ごろから「XP」と呼ばれまして、けっこう注目されるようになりました。他の本としてはUMLやリーン開発とか、最近ですと要求開発とかマインド・マップとかですね、わりと上流でフワッとしたものを掴む手法などに興味があります。
デルタ設計というアイデア

 で、今日、派生開発カンファレンスに呼ばれるっていうのはたいへん意味があることなんですね。というのは日本でこれほど現場チックな、というか、汗の匂いを感じる会場で、アジャイルというもう一つの現場中心の話ができるので、それでけっこう緊張していまして、今朝は6時に目が覚めてしまって、やることがないんでちょっと派生開発のことを考えてみました。何を考えたかというと、変更ということについてです。
 派生開発で変更を指示する場合、変更前と変更後を表すとき、このように図で示すわけですが(写真?)、モデルで示すとなるとけっこう難しくて、間違い探しみたいなことになってしまう(笑)。普通ですと赤ペンを入れて変更か所を指示する(写真?)。これをもうちょっとフォーマルで分かりやすい方法はないかなぁと考えていて……、変更ということに着目したモデルってないかと。つまり「変更モデル」というものを作れないか、と考えています。
 で、それをとりあえず「デルタ」と呼んでいるんですが、いちばん左側に元の変更前のモデルを置いて、「デルタ」を中央に、変更後のモデルを右に置く。そうしたとき、「デルタ」の中にユニークなパターンとかアーキテクチャが見つかれば、デルタ設計のうまいやり方があるんじゃないか、ということを考えました(写真?)。今日はここまでで止めておきますが、ここから派生する何かアイデアがあったりお気付きの方がいらしたら、ぜひ教えて下さい。
 
清水先生との出会い

 ちょっとさかのぼって、私と清水先生の出会いを振り返ってみますと、2001年に「オブジェクト・デイ」というイベントがあって……、渡辺さん、覚えてるかな……。
 (会場から「覚えてます」の声)
 あ、覚えてます?
 たぶん、私が最初にしゃべってたと記憶しています。清水先生もここに来られていて、何をここでやったかと言いますと、「XP談義」というパネルをやりました。XPというのは、いまでいうアジャイルです。その有効性を問う、というパネルディスカッションを、懐疑派と擁護派に分かれてやったんですね(笑)。そのとき清水さんは懐疑派、ぼくは擁護派に席に座ってまして、これ以来、道を分かって(笑)、別々の……(笑)。
市場と開発の乖離

 今日はアジャイルの話を聞きたい、という方もおられると思うので、なぜアジャイル開発が出てきたか、という話をしますと、従来のシステム開発ウォーターフォールに代表されるミッション・リスク分割型の開発では、「市場」・「ビジネス」・「IT」という関係のなかで、ビジネスの人たちは市場を分析して商品とかサービスとかを企画して、そのためにはこういうシステムが要るよね、ということをITサイドに伝える。つまり要求定義が行われてシステム開発ということになるのです。ITの側は仕様書に従ってシステムを作って、納品し、リリースする。そういう段取りになります。
 この場合、いくつかの問題が生じます。1つは、「ビジネス」のミッションは製品やシステム、あるいはサービスを売って利益を上げることです。あるいは内部システムであればコストを下げるとか事務を簡素化するとか。ところが、「IT」のミッションは、仕様書通りに作ること、要求通りに作ること、になっちゃうんですよ。大多にして、仕様書がいい加減だったり間違っていることもあるし、要求通りに作っても実態に合っているかどうか分からない。
 そうなると、要求定義書や仕様書に書いてあるから作ります、書いてないから作りません、ということになって、ビジネス側とIT側が要求定義書や仕様書を前にして綱引きをすることになっちゃうわけです。ときどきは「読めば分かるでしょう」なんていうことになるんです。
 もう1つは、ビジネスのサイドは当然ですが、あれもこれも機能をたくさん盛り込みたいと思うけれど、ITのサイドはあまり作りたくない。そういうことを背景に、仕様書に書いてある・書いてない、言った・言わない、の議論になりがちなんですね。それでどうなるかというと、「行間を読めよ」っていうことになるわけです。俗に言う「行間仕様」っていうヤツです(笑)。
 コレがあるんだから、当然、ソレもあるでしょう。という感じで……。さらに悪いことに、行ったり来たりしているうちに時間が経ってしまうと、市場が変化してしまう、逃げてしまうことがあるわけです。ウォーターフォールのV字モデルって、非常によくできたモデルなんですけど、それはVの左側にある「要求」が止まっている場合は非常にいいです。ところが市場は動いているので、気がついたときには、半年も経ったころには、「競合会社がもうやっちゃってるよ」という話になっちゃうんですね。
 アジャイルというのは、動いている市場となるべく一体となって、要求の優先度の高いほうから一個流しでV字モデルを素早くたどって作っていくやりかたです。もともとアメリカの西海岸で生まれたもので、ベンチャービジネス、スタートアップのシステム開発なんかが分かりやすいですね。つまり、作って市場に出しちゃえ、です。出して売れたら続けるし、売れなかったら止める。非常にビジネスライクなやり方です。さらに最近は要求があって作るんじゃなくて、市場の動きを見て作って、すぐリリースして、市場の反応を見ながら直すというやり方も出てきました。
で、ここにいらしてる方の中にはエンベデッド系のエンジニアもおられると思いますが、最もナチュラルにアジャイルが受け入れられるのは、スタートアップ企業であるとか、市場と非常に近いところでビジネスしているケースです。市場に製品を出すループと、システムを構築するループがほとんど同期しているケースなんです。