それでは、ワークショップを開始します。まず自己紹介から始めましょう。私はこのモデリング技術部会の主査をしているオージス総研の細谷です。社内の所属はグローバルビジネス推進部で、1年ほど前まで上海でオフショア開発の現場のマネジメントをしていました。その頃はUMTPの国際部会の副主査でした。今年度は、中国以外の海外のビジネスパートナーを作ったり、海外拠点向けのシステム開発のプリセールスなどもやっています。その流れの中で、去年の6、7月に平鍋さんと一緒にブラジルに行く機会がありました。私はそれまでアジャイルというものを避けて通っていたのですが、北米などではアジャイルが普通になっていて、北米からの仕事を請け負っているブラジルでもアジャイルが普通です。海外と仕事をするときにはガチガチのウォーターフォールだと人の育成にも時間がかかるし人もついてこないので、アジャイルでできないとだめだなと心を入れ替えて帰ってきました。そんなこともあり、モデリングとアジャイル開発がどう絡むかに興味を持っています。今日は1つの答えを皆さんと出せたらと思っています。

テクノロジックアートの照井です。UMTPではモデリング技術部会で活動しています。最近は大規模開発での設計支援をしたり、中小規模の開発でプラクティショナーとして開発もしています。私自身はソフトウェア技術者なので、ソフトウェアをどうすれば良くしていけるかを一生涯を通じてやっていきたいと思っています。理想的な形の1つがアジャイル開発だとは思っていますが、すべてにおいてアジャイルが適用できるわけではないので、折り合いをつけながらやっていきたいと思っています。

モデリングについてはソフトウェアのモデリングと企業活動のモデリングを分けて考えた方がいいと思うので、そのあたりの共通認識を今日皆さんと作れればいいと思っています。

河合です。モデリング技術部会と問題作成部会の副主査をやっています。仕事は、10年来、開発ではなく教育ばかりをやっています。最近は新人研修も多く、この4月からは2ヶ月間、Webアプリケーションの新人研修をやります。今日の平鍋さんのお話にはいっぱいヒントが隠れていて、ひらめいたことがあるので、後で話したいと思っています。

オージス総研の藤井です。モデリング技術部会のメンバーです。私は講演の中でも言及して頂いたアジャイルモデリングに興味があって、2002〜3年頃にやっていたんですが、その気持ちは今も同じです。モデリングは精密さを良しとするものではなく、コミュニケーションや思考のツールとして使っていくことが有効だと考えているので、アジャイル開発の中でもモデリングを使えるという立場です。大規模開発になると複数チームの間で何を作るかについて合意、すり合わせをしなければならないので、そこでモデリングを活かせると思います。また、開発者が過去に自分で発見したことや経験を他の人に伝える手段としてのモデルという意味もあると思います。その他に、モデリングとファシリテーションを組み合わせるあたりにも興味があります。

若林です。オフショアソフトウェア開発部会[以下「オフショア部会」]にも参加しています。会社はNECネクサソリューションズで、NECグループの中でも中堅/中小企業のSIなどを担当しています。オフショア部会に入った時にはシステム開発部門でオフショアをやっていたんですが、2年ほど前からクラウドサービスを立ち上げる部門に移り、現在は中堅/中小企業向けのサービスの立ち上げをやっています。今は開発の現場から離れていますが、クラウドサービスには非常にスピードが求められるので、アジャイル開発の知見をクラウドの方に活かしていけないかと考えています。

富士通の吉田です。モデリングはかなり昔からやっていますが、私が本を書くとあまり流行りません。最初に書いたUMLはなかなか流行りませんでしたし、EJBは忘れられていますし、JSFやMDAの本も書いたんですが…。最近やっと、UMLもMDAもそれなりに定着してきている気がします。

大きい会社でアジャイルとモデリングの採用が進まないのは、1つは契約の問題、もう1つは開発者のモチベーションの問題だと思います。海外ではエンジニアが先を争って新しい技術を実践して名を揚げるというモチベーションがあるんですが、日本の大きい会社のエンジニアは人と違うことをしなくてもお給料が貰えるので、違うことをやって人より先に覚えたいというモチベーションがなかなかわかない。だから新しいことをやろうと決めるのは上の人で、どうやって教育するかから始まる。そのあたりが特徴だと思っています。

中原です。1年前に日立グループの会社を退職して、今はフリーでいろいろな学校の非常勤講師をやっています。オフショア部会では主査をしています。4月からはアジャイル開発部会として活動する予定で、アジャイル開発のノウハウをまとめたガイドラインを作りたいと思います。専門知識を並べるだけではなく、できるだけ実践に使えるものを目指したいと思っています。アジャイルには興味を持っている企業もたくさんあるんですが、上が認めてくれないのにやって失敗するわけにもいかないので、なかなか広がらないように思います。そういうときに使えるよう、モデリングとからめた事例を集めたいと思っています。

オージス総研の竹政です。UMTPではモデリング技術部会とオフショア部会改めアジャイル開発部会に所属しています。アジャイルに関しては、最近は若い人に勢いがあると感じています。自発的に勉強会や読書会をやるような動きがあり、IT業界では久しぶりにうねりのようなものを感じています。これをうまい方向に持っていくと、IT業界自体がポジティブな方向に行くのではないかと期待し、それをどう広げていけるかを考えています。アジャイルをそのまま大規模開発に適用するのは難しそうですが、それ以外の方向もあるかと思っています。

豆蔵の羽生田です。UMTPでは問題作成部会の主査をやっていて、先ごろL4のベータを終了し、春からL4認定試験として開始します。これは主に面接と、その前2か月ほどのメールによる審査員とのやりとりを通じて、その人がモデリングのスキルを持っているか、モデリングの指導者としてITの世界で振舞ってもらえるかを実際的に確認するというプロセスで、今までのWeb上でやる試験とは違う形のものになっています。

モデリングに関してはずっと教育やコンサルティングをやってきているんですが、最近は豆蔵でもアジャイルをやりたいというお客様が増えています。今までコンサルで主張してきたUMLやアーキテクチャは大事だという話とこのアジャイルとをどうやって結びつけるかは、私のところでもまだ解がなく、試行錯誤しているところなので、今日は色々とディスカッションできると嬉しいです。

モデリング自体は、アーキテクチャを定義することも大事ですが、コミュニケーションや納得感を得るための道具だと思っているので、その意味ではアジャイルと結びつく要素は非常にあると思っています。そこをパブリックな認識にまで高めたいので何かヒントが得られればと思っています。

オージス総研の正田です。UMTPではオフショア部会に参加しています。オージス総研ではオフショアとして弊社で作っていたUMLツールを上海に発注していたのですが、思い起こせばアジャイルという言葉をまったく意識していなかったけれども、仕事をうまく投げるために行っていたことのいくつかは、結果的にアジャイルだったような気がしています。

今はオフショアを離れて、対外の教育ビジネスをしています。新人社員のミニプロジェクトをする場合、時間が限られているので「中途半端なレベルの成果物」しかできません。その中で優先度をつけて教えていく際にもアジャイルが参考になるかもしれません。また、今は組み込み部という所属なので、組み込みでアジャイルは流行るのかなど、見極めをしていければと思います。

オージス総研の張と申します。UMTPではオフショア部会に所属しています。社内ではアジャイル開発センターに所属していて、大規模アジャイル開発の手法などを模索しながらやっていますが、モデリングに関してはアジャイルとの関連付け、アジャイル開発ではモデリングの位置付けなどに関して自分の心の中でもやもやしているところがあるので、皆さんとのディスカッションを通じて何かヒントをいただければと思っています。よろしくお願いします。

東芝ソリューションの山城です。以前にこの技術部会の主査を担当し、同様のセミナーを8回実施し、今回より細谷さんにバトンタッチしました。

元はモデリングや要件定義に携わっていたんですが、ここ1年は品質保証部で主に方式設計/システム設計のレビューに参加しています。設計技術だけでなくそこで使われるITインフラの技術をレビューする役割になっています。

東芝ソリューションは東芝の中でIT関係のソリューションをやっている会社で、人数が5000人、関係会社を含めると10000人います。そこで色々な案件を受けてソフトウェアを作成するんですが、アジャイルはなかなか難しい。私にとってアジャイルの開発スタイルはbuild from scratchで毎回考えて作るというイメージですが、そうすると毎回メンバーを変えて同じ失敗が繰り返される危惧があります。一方、会社としては同じ失敗はしてほしくないので、なるべく既存のものを再利用して作ろうという方向に考えます。新しい技術にもチャレンジしなければならないので、アジャイルという開発の仕方でありながら、同じ失敗を繰り返さず、あるものを再利用して早くものを作るという新旧の開発スタイルの接点を、今日の議論の中で探したいと思います。

今日は話を聞いていただいてありがとうございました。時間が長かったので横道にそれる部分が多かったんですが、話したいことは話せました。モデリングとアジャイルという組み合わせは、いつまでたっても落ち着きどころのある解がみつからず、そもそも比べられるものなのか、どちらが大きい概念かも分からない。そういった点でこの後のディスカッションを楽しみにしています。

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

まず、平鍋さんの講演の内容から、気になるところや感想など、自由にディスカッションしたいと思います。

私はイリノイ大学の大学院にいて、ラルフ・ジョンソンからデザインパターンを教わったり、VisualWorksでSmalltalkの環境をいじったりしていましたので、今日の講演で出たdeGoF[デザインパターンはずし。使われているデザインパターンが本当に必要かを検討して、不要なら取り去ること]という話はショッキングでした。それはそうと、Smalltalkが源流だという話はよくわかります。Smalltalkは型がないので、コンパイルしても何も分からない。しかもデプロイとコンパイルとコーディングのフェーズに区別がなく、書いたそばから動きますし、コンパイルの段階も意識しません。ただ、型がないので、Aというメソッドを書いたら、testAというメソッドを同じクラスに置くんです。Smalltalkにはメソッドをグループ分けするプロトコルという概念があって、テストのメソッドだけをかためられるので、xUnitでやっていたようなテストメソッドを書くという作業はプログラミングの一部の習慣として身に付きます。とりあえず思いついたらその場で書く。そのうちにこのクラスとこのクラスをまとめたいなというようにリファクタリングをします。なので、Smalltalkに触れることでそういうことが習慣として身についたなぁと、講演を聞いていて思い出しました。

ピュアなスクラムとウォーターフォールはギャップが激しいので、まずウォータースクラムフォール[講演で言及された言葉で、スクラムを繰り返す前と後にウォーターフォール的な要件定義やテストのフェーズを置くもの]というアプローチをとるのはいいと思います。

日本的ですよね。納得感が妙にある。

そのスタイルなら、最初にモデリングでざっくり輪郭を描いて、ユースケースを出して、その単位に作ってテストするというのが分かりやすいので、まずそこから入るのも1つの手かと個人的に思っています。

その他に、まずプログラミング言語の進化があって、分析設計手法が後からついてくるという話がありましたが、その流れでいうと、アジャイルという手法が出てきて、その後、continuous integrationのようにcontinuous modelingができないかなど、考えてみたいなと思いました。

図1 ソフトウェア開発の歴史 (講演資料18ページ上)

欧米と日本では文化や契約の面で仕組みが違うとおっしゃっていましたが、ウォータースクラムフォールは日本にアジャイルを適用するときのひとつの形としてとらえていいものでしょうか。それともできるだけピュアなアジャイルの方向に移動していくべきものでしょうか。

難しいですね。アジャイルでもイテレーションゼロという部分があったり、たとえば建築で実際に建て始める前に地ならしをしないと何も始まらないというような話があり、やりすぎないことは重要だけど事前の何かは必要だという認識は定着してきた気がします。終わりの方は、よく「Doneの定義」として議論されます。何をもって1つのタスクをDoneとするかの判断基準が最終テストなのか、イテレーションの中で組み上げたものでのテストなのかと考えると、本当はイテレーションごとにテストをし、ユーザビリティも確認してDoneとするといいのですか、たとえばユーザビリティのテストを毎回するとしたらコストも大きいのでそこはやらないという選択肢もある。そうすると、Doneの定義によってはウォータースクラムフォールの最後にフォールの部分が残るのは自然かと思います。

アジャイルを最初に伝えるためのメッセージとしては「縦に切る」と言うと分かりやすいのですが、現実的に考えたらどう考えても最初に少し必要だよねとか、最後にもう一度確認しないと不安だよねというのは、あると思います。

社内でアジャイルと言うとすごく不安を覚える人がいて、「ドキュメントがなくなるってことですか?」のような極端な理解のされ方をします。「私はCOBOLしか読めませんがドキュメントがなくなったら何をレビューすればいいんですか?」などと聞かれるんです。別にドキュメントを書いちゃいけないと言っているわけではないんですよね。必要最低限のものは書けばいいということなんですが、そのあたりのアジャイルの説明の仕方も、日本向けに考える必要があると思います。

講演の中の平鍋さんのアナロジー[ショートケーキを作るのにホールで作って切り分けるのではなく、最初からショートケーキの形で作ってしまうという話]で言うと、1つずつのショートケーキを作る前に、最初にケーキを設計するんですよね。それで最終的に、たとえば髪の毛が入っていないかなどの検査をしてお客さんに販売しますよね。だから、スコープを広げてみると、そういうところにモデリングが入る余地があるのかと思います。

図2 ケーキの作り方 (講演資料5ページ下)

なるほど。

ウォータースクラムフォールは、ウォーターフォールからアジャイルに移行していく中間過程という位置付けもあると思います。IBMの方がおっしゃっていたんですが、IBMがアジャイルと言い出したら、その手前のイテレーティブなRUPなどのプロセスについての問い合わせが増えたそうです。今、ウォーターフォールとアジャイルというプロセスの話はよく出てきますが、RUPなど2、3か月でイテレーションを回すような、中間的なサイクルのプロセスの話をあまり聞きません。イテレーティブなプロセスは、ウォーターフォールからアジャイルへ移る過程の有効な手段と考えられるでしょうか?

少し違うと思います。僕ならKanbanを置きますね[『Kanban: Successful Evolutionary Change for Your Technology Business』を参照]。まず、何でもいいから今やっていることの流れをビジュアルに見えるようにしよう、という風に始めた方が日本っぽいと思います。

ビジュアルというのは、紙でなくてシステムでディスプレイに常に出すのでもいいんですか? 皆で同じものが見れれば。

はい。工場の平準化ボードなどがあるじゃないですか、あんなイメージです。

オフショアでやったときは、カンバンなどはどう共有していたんですか?

うちでは、オフショアの状況を必ず掴んでいる人間を1人おいて、その人がカンバンを作っていました。

ブリッジみたいな人が1人日本側にいるってことですか。

そうです。

先ほどのウォータースクラムフォールやイテラティブな開発を中間に入れるというのは、分業をどう考えるかに絡んでいる気がします。分業を行っているという現状から、その分業を徐々に減らしていく中間段階で、専門性を多少残しつつ開発をやっていくという移行をするなら、イテラティブな開発もありじゃないかと思います。アメリカでは最初からコーディング主体で開発しているという会社が意外に多いので、比較的すっとアジャイルに入るパターンが多いんじゃないかと思います。

分業という面では、平鍋さんがおっしゃったようにアジャイルが一周してきてもう一度盛り上がりを見せているというところの1つの要素として、バーサタイリスト[Versatilist: 多能な人]が小さくやるアジャイルから、もう少しスコープが広がって、いろんな専門性のある人が1つのチームでやっていく方法も必要だという見方があると思います。

先日、『The Agile Samurai』の著者にインタビューをしたのですが、アジャイルビジネスアナリストとかアジャイルPMなどのロールをなぜ設定したのかと質問したら、既存の専門性を持った人がアジャイルに移行する時の「自分たちの役割が無くなってしまうんじゃないか」という恐怖をなくすことが大事なので設けたとおっしゃっていました。

恐れをなくすという意味で名前を付けるんだけど、実際にはできるだけ色々総合的にできるといいんですよね。

徐々にみんながコーディングのスキルをある程度身につけていくとか、テストの自動化をできるように学習していくための、1つの移行パスじゃないかと思います。

海外の方が日本よりもテスターなどの役目がはっきりしているので、そういう言い方が効くんでしょうね。テスターであっても一緒にコードを見てほしい、BAにもプログラムを知ってほしい、プログラマにもビジネスのことを知ってほしい、という背景があるように思います。

日本だと会社がゼネラリストを作ろうとしますからね。上海でコーディングする人に「ちょっとテスターになって」と言ったらすごく嫌な顔をされて、「私はコーディングの人です」と言われました。ひどい場合には、学校でJavaを習ったからJavaしかやりません、のように極端に自分の仕事の範囲を狭くとらえています。入社して数年でお給料を上げようとするとどうしても転職しないといけないので、履歴書にどう書けるかがすごく重要なんです。

欧米の人のモチベーションが違う理由は流動性だと思うんです。IBMさんやOracleさんでみんな社内でアジャイルをやっているのは、やらないと人が逃げちゃうからなんです。つまり、細谷さんがおっしゃったように、履歴書に「アジャイルを5回やったことがある」とかって書きたいわけです。日本の大きい企業のエンジニアはそういうモチベーションがないんですね。だからアジャイルに限らずモデリングもRubyも、食いついていこうというモチベーションがすごく少ない。

欧米の会社では流動性があるため変化しているけれども、日本の、たとえば富士通さんや東芝さんではそういう変化はまだ起きていないということですか。

上から言うとかお客が言うとかでない限りなかなか起きないですね。上が認めていないのに下が勝手にやって失敗したら困るというのもあります。

言われていないことをやると大騒ぎになりますからね。何もやらなければ文句は言われませんが。

言われて失敗するのはいいけど、言われていないことで失敗するとね。(一同笑)

あと、品質管理ががちがちで、フェーズごとに欠陥を出さなきゃいけない目標件数が設定されているので、それ以外の品質保証がどういう形でありうるかが分からないと難しい。

さっき山城さんがおっしゃったことですね。同じ失敗を繰り返さないでほしいと会社は考えますから。

経営視点で一番大事なのは、このプロジェクトで失敗したことを他で繰り返さないことです。そのためには、すべてを1つのプロジェクトに任せられないんですよね。

メーカーの品質保証の考え方は、とにかくバグ曲線をとってなんぼみたいなところがあるので、アジャイルで途中でバグの数が出てこないと、大問題ですよね。

テスト駆動開発だかペアプログラミングだかをお客さんに説明したときに、「ペアプロをやるとコードの行数が15%減るんです、しかも欠陥が15%減るんです、コードがシンプルになって欠陥も減っていいですよね」と言うと、「うーん、1000行あたりのバグ数は一緒だな」と言われました(一同笑)。古い地図をいくら見ていても新しい大陸は見つからないんですよ。

日立は品質保証が強いですが、中原さんはどう思われますか。

やっぱり定量的な値がないと上は納得できないですね。もちろん、コード数が減っているから最終的にバグが減って効率も上がっていると裏付けできればいいんですが、まずは数値を見ますね。

どうして定量的になるかというと、みんながみんな優秀だったらいいものを作れるんですけど、若い方も社外の方も一緒にものを作るわけで…

バラつきをなくしたいという製造業の基本的なところがずっとあるんですよね、「日本の品質はそこだ!」という。

そうすると、何らかの定量的な指標で測って、満たすか満たさないかを重視することになります。

それは結局仕様通りに作れば良しという姿勢ですよね。それでいいのか?というのが、多分アジャイルの考えなんだと思うんですが。

仕様通り作ると品質はばらつかないんですよ。

品質が大事なのか、役立つソフトウェアを作るのが大事なのか、という考え方の違いですね。

ビジネスが多分違うんです。

企業では、実は新規案件は2〜3割で、残りはリプレースや改造など、既存のものをどういじるかというのが多いんです。そういうビジネスでは、アーキテクチャは既に分かっているし、どこを直さなければいけないかも分かっているので、本当にアジャイルが必要かを考えなくちゃいけません。

逆に、mixiとかDeNAとかGREEがガチガチのウォーターフォールでやっているというのは想像できないですよね。ビジネスモデルがそもそも違うんですね。

リプレースや改造の案件でも、アジャイルと銘打ってやるメリットはあるんでしょうか。

既存のコードが多い場面ではアジャイルをやりにくいとは言われています。同時に、やるのであれば、既存であってもウォーターフォールでやるよりメリットは出せるんじゃないかとも言われています。ただ、茨の道であることは間違いなくて、それは既存のコードに動いているテストがないという理由が大きいです。

元のものがあると、元のものの解析みたいなところから入らなきゃいけなくなるんですが、そこで使えるアジャイルのプラクティスみたいなものはありますか。

うちの案件で全部のアプリにWindows 7対応のコードを仕込むというのがあったのですが、古いテスト仕様書や古いテストデータは使えないんです。残っていなかったり残っていてもメンテされていなかったりで。そこで、テストデータを全部残して、足りないところを全部補って、Selenium[Webアプリケーションのテストツール]でテストスクリプトを書きました。テストフロー開発やテストの自動化は、最初にやるときは大変なんですが、一度やって、その後、テストスクリプトも一緒にメンテできれば、受け入れテストや結合テストがボタン一発でできて、保守の時にとてもメリットがあります。これまではテストの自動化ツールが高かったのですが、今はWebであればSeleniumのようなオープンソースのものがあるので、長く使っていける環境もできてきているかと思います。

自動化する環境を作ってから、プロダクトに取り組むようなやり方を、1つのアジャイルのやり方のように考えてもいいんでしょうか。

場面によって切り口が違います。全部のプラクティスをいっぺんにというのは現状に合わないので、今言ったようにメンテナンスでテストデータがないならテスト自動化をしようとか、場面場面で入り込む切り口があるんだと思います。

『リーン開発の本質』に記されていた話ですが、レガシーシステムを再構築する時に、受け入れテストの自動化をし、ハーネスでテストケースを実行できる環境を整えてから、アジャイル開発を適用して新しいシステムを作り直したという話が出てきます。そういうスタイルもあるんじゃないでしょうか。レガシーのメンテナンスコストが年々上がってくるので、維持するコストと新規開発するメリットがクロスするところがあって、そこでアジャイル開発に移行するというパスもある、という話を読んだことがあります。

既存システムをアジャイルのタイムボックス化で継続的に開発していくときに、デグレ[degrade。手直しの際に修正部分以外の個所で不具合などが発生すること]の防止だとか継続的に開発しやすくするために、自動テストがあるというお話ですね。

それによって、実際には使われていないコードがあることが分かって、旧システムより何割かコード行数が減ったそうです。

そういった観点から言うと、保守をしやすくするために前もってたくさんのドキュメントを作るプロジェクトが結構あったんじゃないかと思うんですが、既存のシステムのメンテナンスにアジャイルを適用する際に、そういうドキュメントは有効なんでしょうか。

ドキュメントをウォーターフォール的に作っていていつも思っていたんですが、詳細設計書、つまりコードを書くための情報…

あれは要らないですね。

要らないでしょ。メンテナンスの時に必要な情報と、基本設計から書き写してきたものとが混在して大量になっているので、メンテナンスしろといっても追いつかないし、そもそも誰も読まない。作るためのドキュメントは要らないと思うんです。コードが落ち着いてきたら、メンテナンス用の全体を俯瞰するための薄いドキュメントを1つ書けばいいと思います。こういうところをいじりたければどのコードを見ろとかいう、入口を指し示すようなものを作る。それなら薄いのを一度作ればいいだけなので、負担にならず簡単にできます。

それはモデルを使って書くのですか?

私がやったときはユースケース図やオブジェクト図などのモデルを使いました。

平鍋さんのところでは、朝会の写真などが出ていましたが、あそこでastah*はどのように使われているのですか。

図3 朝会 (講演資料9ページ上)

アーキテクチャなど重要なデータモデルをastah*で書いて壁に貼っておくような感じですね。スケッチ的に使っていて、キーとなる絵しか描いていません。

作るタイミングはいつですか。

アーキテクチャというか、かなり昔から枯れているフレームワークの部分は、ずっと壁に貼ってあります。新規開発の場合には、新しいデータモデルをいくつかと、ユースケース的なものと、みんなで合意したワンパスだけのシーケンス図を追加します。

ショートケーキで必要なデータのところだけではなく、データモデルとして全体があるということですね。

はい。

タイムボックスで切った中で必要なものだけではなく…

ではなく、ずっと残っているものもあります。全体のアーキテクチャとデータモデルは残っています。

講演の四象限の図についてですが、左の分析モデルで一番重要なのはデータモデルだと思うんです。データモデルは問題空間でも解空間でもほとんど同じじゃないですか。

図4 四象限の図 (20ページ下)

割とそうなることが多いですね。

それで、右側の設計モデルで重要なのはアーキテクチャかと思うんです。アーキテクチャさえ決まると、個々のショートケーキはいちいちモデルを書かなくても全部同じ形になるはずなんです。そうすると、わざわざ書くまでもないことになりませんか?

必勝パターンはそれに持ち込むことです。日本の開発はずっとそれをやってきましたね。共通部分はそれで作って、後は櫛の歯を揃えて、と。

特に業務システムはほとんどそうなっています。そうすると、フレームワークが決まってしまえば、後はわざわざクラス図やシーケンス図を書くまでもなく、いつも同じになりますよね。

ただ、そのやり方はコードのコピーを増やす原因の1つでもあるので、僕はあまり好きじゃありません。できれば、多様性がもっと櫛の歯に出るような形の方がコード行数を少なくできると思っています。

アーキテクチャという言葉が出てきましたが、「Agileとモデリング」というスライドに「リファクタリングでアーキテクチャを刈り取る」と書いてあります。この言葉がよく分からないんですが、もう少し簡単に説明していただけますか。

図5 アーキテクチャを刈り取る (講演資料17ページ上)

単純に言うと、リファクタリングを進めると抽象クラスが増えます。そして、その抽象クラスを切り取るとフレームワークになります。それを繰り返していくと、抽象クラスのレイヤでのアーキテクチャがだんだん見えてくる、という風に私は解釈しました。

僕がアーキテクチャを刈り取るという意味で言ったのは、実はあまりリファクタリングと関連していないかもしれません。エクストリームプログラミングでは縦パスを1つend-to-endで通すということをまずやります。そのときにはまだ有効なアーキテクチャが何かは分かりませんが、たとえばUIからDBなど縦パスが動いてビジネス価値があるものを作りました、となる。そして、もう1本作り始めます、こうやったら動いた、というのを繰り返していくと、アーキテクチャがそこに現れるのではないか、ということです。つまり先読みをして、1本通す前に絵を描いても、あまりその絵は機能しなくて、そこに季節がめぐって皆で作っていくと、秋にはそれができているでしょうと。

春にはアーキテクチャ設計はやらなくて…

やらない。もちろん、縦パスを2本作ったらここは一緒だからリファクタリングしましょうとなるかもしれない。でもそれは本質ではないかもしれません。動くソフトウェアを作っていく中でしか動くアーキテクチャは出ないんじゃないかということです。

「刈り取る」というのは収穫を得るということですよね。Fowlerの『リファクタリング』には、デザインパターンを入れた方がいい場合と入っているものを取った方がいい場合があると言っていますが…

ありますね。両方あります。

私の印象では、あらかじめフレームワークを作ってからそこにはめ込むのではなくて、RUPの推敲フェーズやXP(Extreme Programming)のスパイクをしながら、平鍋さんがおっしゃったように、アーキテクチャが自然発生してきたものをフレームワークとして取り出すというイメージなんですが。

縦パスを通す過程で、作っている人たちの中で暗黙的なアーキテクチャが生まれてくるのを少しずつ形にするんですね。

結果的にそれがアーキテクチャでした、ということです。

うちの会社もそうですが、オフショア活用などアウトソーシングを前提で作るんです。その場合、社内の人間が大枠や作り方を決めてルール化して、それに沿った作成作業を発注するやり方が多いんですが、そうするとどうしても大枠を決めた後でないと作れないという状況になってしまいますよね。それと矛盾する気がするんです。

矛盾します。難しいと思います。

全員が社内で作れば刈り取ることはできるかもしれないけど、オフショアを想定してもの作りをすると、刈り取りはできないですし…

オフショアではそこに契約が入ることになりますし、合意が必要ですし、そこが問題になりますね。

アーキテクチャという先人達の知恵があって、こういう状況ならこういうアーキテクチャがいいという皆のイメージがあるので、その過去の記憶も含めた知恵は取り込まなきゃいけないと思うんですが、アジャイルの言っているアーキテクチャは、僕たちの知っているこのアーキテクチャと同じなのか?という点は気になります。ブーチは「種族記憶(trinbal memory)の中にアーキテクチャがある」とか言ってますね。

平鍋さんが監訳されたリーン開発の本[『リーン開発の本質』]にエキスパートエンジニアという概念が出てきたんですが、それが結構アーキテクトに近いかなと思います。設計のコンセプトを先輩から代々受け継ぎながら蓄積していって、よいものを作っていくという点で、アーキテクトという役割を認めているように思います。

そうですよね。

Javaの世界でも、以前はStrutsとかがなかったので、めいめいでフレームワーク的なものを作りながら自然発生的に出てきたものがたくさんあって面白かったんですけど、最近は面白くないですね。アーキテクチャを作るというフェーズはもうなくなってしまった感じですね。

聞かないですね。櫛の歯ばっかり作っていますよね。

オフショアの話もそうなんですが、ある程度規模が大きくなったときに自然発生では限界があり、アーキテクチャを作り直して全体像から見た設計をしなければならないと聞いたことがあります。規模が大きくなったときにはそのモデリングが有効な手段なのですが、小さなシステムをつなげていけば、そのモデリングをしなくても自然発生したアーキテクチャだけで運用できるという考え方もあると思うんです。

ボトムアップ的なアーキテクチャが生まれるってことですか?

そうです。

ラルフ・ジョンソンのお弟子さんにブライアン・フットという人がいて、その人は、何かを作ったらまず「make it work」(動くようにしろ)、次に「make it right」(正しい作りに変えろ)、その次に「make it fast」(性能を上げろ)と言うんです。自然発生しただけじゃだめで、一度整理して、アーキテクチャを棚卸しして、変なところやうまくいっていないところをリファクタリングするなりアーキテクチャを設計し直すなりして、正しいアーキテクチャはこうだというのを考える。そこからまた改善したり性能向上をするという3段階だと言われて、なるほどと思いました。

改善していくという作業の中で、アーキテクチャのモデリングが利用できるわけですね。

いったんアーキテクチャを明示的に描き出した方がいいと思うんです。モヤモヤっとあるだけだと進化の限界がやってくるので、モデリングをするなりコードを見てリファクタリングするなりで、これがアーキテクチャだと一度描き出す。

細谷さんがおっしゃるのは、見える化するというか、明示的にするという意味合いのモデリングですね。

アーキテクチャのモデルと聞いたときに一番に思い浮かぶのは、大規模やオフショアで開発する際に、この仕組みで作ってくださいと伝達する手段としてのモデルだと思うんです。

仕組みの共有ための。

すると、先にドキュメントを書いてそれに基づいて作るのではなく、ものを先に作って、できたものに関して「こういうコンセプトだよ」と人に教えるためにドキュメントがいるという感じですね。

そうです。

ということは、方式設計の段階で動くものを作るということですか?

方式設計のタイミングにもよると思うんですけどね。アジャイルなら作りながらだんだん方式ができていくという形だと思いますし、過去の経験を活かして最初に設計するというタイミングもあると思います。

アーキテクチャを刈り取るというのは、方式設計をきちんとドキュメントでやってそれから作るのではなく、たとえば似たような、これまでうまくいっているようなものを持ってきて、その上に動くものを作成する、そして、いくつかのショートケーキができてから、きれいにして、うちのシステムはこういうアーキテクチャなんだよとドキュメントにまとめる、ということですね。

それで改めて細かい部分をちゃんと動くようにアウトソーシングするんですか? それともできちゃうんですか?

できちゃいます。

そうするとアウトソースの活用タイミングはいつになりますか?

上にショートケーキをいっぱい作るときです。

極端に言うと、アウトソースする前にアーキテクチャがないとできないということでしょう。そこに行く前は、社内でモヤモヤとプロトタイプみたいなものを作って、このアーキテクチャで行こうとなってから、こことここの要素を作ってねと契約して仕様書を書いて発注ということじゃないですか。

そういう話になると、大規模なアジャイル開発は本当にアジャイル開発なのかという疑問が出てきます。アーキテクチャをアジャイル的に作り上げるまではいいんですけど、そのアーキテクチャの通り単に大量生産をする段階になると、アジャイル開発的な色合いが薄くなっていると思います。その意味では大規模アジャイル開発は、小規模のアジャイル開発とは異なるものとして捉えるべきではないでしょうか。

あと、今までのウォーターフォール開発も似たような経緯をたどっているところがあります。一からアーキテクチャを作る場合はかなりアジャイル的な色合いが濃かったりしますが、アーキテクチャが大体決まった後に来た人はそれに沿って作っていくことになる。それが、大企業の人たちのモチベーションが上がらない理由なのかなと思います。

日本では、メーカーさんやSIerさんで大規模開発をするときの設計標準という意味合いでモデリングという技術が広まったという経緯が大きいと思います。ですから、モデリングを議論する上では大規模開発というキーワードは避けない方がいいのではないでしょうか。

アジャイルでの大規模開発について大手SIerの人に話を聞く機会がありましたが、そもそも大規模開発は実はそんなにないと言われました。確かに大きな開発はしているんだけど、それは役割が分割されていて品質保証もやっていて、ドキュメントもたくさん書いているからたくさん人がいるんだと。アジャイルでやれば小さくできるものがほとんどだと。そういう考え方もあるんだなと思いました。本当に大規模なものは別途考えるにしても、必ずしも大規模を前提にする必要はないのかもしれません。

高校生の時に小さいソフトハウスでアルバイトをしたことがあるんですが、その会社のホームページを何年か経ってから見たら、私たちは小さい会社なので大人数を要する仕事はできませんが、私たちに任せていただければ少人数でできる仕事も実は結構あります、と書いてあって、確かにその通りだと思いました。大きいと思っているけどやり方を変えると小さい仕事にできるものは結構あるんじゃないでしょうか。

Rubyのまつもとさんも同じことをおっしゃっていました。Rubyは小規模しか向かないけれども、Rubyだから小規模でできちゃうことも多いと。

それでもやっぱり大規模だというのはあって、それをどうアジャイルにするかは先のテーマだとは思いますが、今やっている仕事がどれもアジャイルを適用できないほど本質的に大規模かという点はちゃんと検証した方がいいと思います。

アジャイルでできるレベルのものをやってから大規模を考えても遅くないんじゃないかと思います。

今言っている「本質的に大規模」というのがどういう意味か分からないのですが…

人によって「大規模」のイメージが違うかもしれないですね。

同じような構造を繰り返し30個作るようなものでも、30個あれば大きくなるじゃないですか。エンタープライズ系はそういうのが多いですよね。

それは大規模というより、1つ作ってそれを量産するようなものなので…

だからオフショアが使えるし、最初に構造を決める必要がありますよね。

最初をアジャイルで作ったら、後はアジャイルでなくて量産するという手法にすればいい。

最初がアジャイルである必要もないような案件もあるんです。昔やっているから同じように作ればいいことが分かっているような。そうするとなかなかアジャイルの使いどころがないし…

それはアジャイルに変える必要はないですよね。

既存の大規模のままアジャイルのプラクティスを適用するという話と、大規模を分割して小さいプロジェクトの集合として扱うという話がありますね。私はそれにプラスして、アジャイル的なプロセスを採用した方がいいプロジェクトが日本でたくさん出てくるような変化を期待しています。今は新規開発があまりないということなので、今度はユーザーさんにプラスアルファ的な機能に投資してもらいたいと思うんです。

プラスアルファというのは既存のシステムに追加機能を付けるということですか? サービスで言うと今あるサービスにさらに付加価値のあるサービスを提供するということですか?

そうです。たとえば、基幹業務のシステムにソーシャル的な機能を追加するような、プラスアルファの投資をしてもらいたいと日頃から思っているんです。日本のメーカーさんやSIerさんの中で、そういう変化はあるんでしょうか?

IT予算は決まっていて、そのほとんどが修正やメンテナンスです。新規のところはアジャイルでやるとメリットが出ると思うんですが、あまりにもメンテナンスの方にお金を取られすぎているので、アジャイルも含めて新しいものを作るニーズが出てきていないような気がします。そこをもっとスリムにしてユーザーからのITに対する期待がもっと出てくれば、新規の比率が高まって、そこがアジャイルになるという方向に行くべきなのかなと。自虐的ですが、そもそもユーザーから期待されていないというか、所詮ITでやってもここまでと思われているから、モデリングをするような場面が出てこないような気もします。

そうですね。ビジネスとITが一体化してビジネスとして考え直すレベルからいかないと、新しいことは作れない気がします。そこを目指せばいいのでしょうが難しいですね。

今日の講演のScrumの開発プロセスの例で、「開発者が製品バックログから出荷可能ソフトウェアを作る『ソフトウェアデベロップメント』とともに、カスタマーがその出荷可能ソフトウェアを使って新たな製品バックログ作りにフィードバックする『カスタマーデベロップメント』がある」と平鍋さんが説明されましたが、その後者の部分を頑張らないといけませんね。

今日、IPAから国内のアジャイル開発の事例を10件以上集めたものが発表されたんですが、日本で大規模なアジャイルをやっている事例のほとんどはゲームかWeb開発なんです。既存のユーザー企業とベンダーがやっているところでは、大規模アジャイルというのは見つけにくいですね。

ユーザーと話していると、ぶっ飛んだ提案を望んでいる人もいますし、言われたことを従順に作っていたら「あなたの提案はいつも面白くない」と言う人もいるんです。結局、ベンダーが自分達の仕事をやりやすいようにウォーターフォール的に仕事を落とし込もうとしている傾向はあると思います。

やっぱり予算を達成しなければいけないじゃないですか。そうすると、付加機能をどんどん提案していって、それで認可されれば数千万とかいう風にやっていくので、別にアジャイルでなくてもいいかという感じになるんですね。

大規模の基準を皆さん違うように考えているんじゃないでしょうか。IPAの報告書を見て驚いたんですが、IPAの報告書の大規模は100人以上なんです。私自身は30人以上で大規模かなと思っていて…

僕もそういう印象がありますね。

100人以上のプロジェクトを大規模と捉えると、かなり減ってきている気はするんです。でも30人以上というプロジェクトならそこそこあるかと思います。だから「大規模」というしきい値によって議論は変わるんじゃないかと思います。

日立さんは100人どころじゃなくて桁が違うんじゃないですか。

本体は100人以上ですね。

国内のアジャイル需要は、多くて何人くらいで動いているんですか?

100人のものもあります。複数チームで1つの大きなものを作っている場合が多いですが。

メンバー数が100人ですか。

100人が1部屋に集まってワイワイというのはあり得ないですから、アーキテクチャを分析して仕事を分割するのは当然必要ですね。

ただ、100人の規模の開発はかなり限定されているんじゃないかなと思います。

大規模というと、スタンディッシュグループのレポートだったと思うんですが、規模を人数でなく開発コストで分類していて、大規模ほど失敗の確率が高い、予算が小さいほど成功率が高い、ある程度を超えたらほとんど全部失敗、という従来型開発プロセスの問題認識がRUPというプロセスの開発動機のひとつにあります。

大きくした時点で負け、みたいな。

RUPは本来大規模開発を成功に導くプロセスです。だから対極としてアジャイルが出てきた…。

日本のベンダーも、総量をそもそも小さくしようという努力はしていないですね。ユーザーさんに向かって「この機能は本当に必要ですか」って言わないでしょう。

むしろ、増やす方向に…

商売的には増やしたいですからね。

一緒にビジネスを考える構造になっていないですね。

日本の傾向として、リスクをあまり取りたがらないというのが基本的にあります。提案する側もアジャイルしなければ分からないようなものじゃなくて、作ればできそうなものを提案したいし、お客さんも、作れるかどうか分からないものじゃなくて作れば絶対作れると分かっているものにお金を出したいので、なかなか出番が少ないような気がしています。

話題を変えますが、さっきひらめいたことをお話しします。品質とは何かという話になると、みんな製品の品質ばかり言います。でも製品の品質の前に、まず要求の品質があって、要求の品質が悪いと製品の品質が悪くなる。また、開発の場の品質というものもあります。たとえばXPにはオンサイトカスタマーというのがあって、開発の場にお客様と開発チームがいる。XPの12のプラクティスでは、製品の品質ではなくて、開発の場を活性化しようとしているんです。

つまり、要求の品質が悪いと製品の品質が悪い、開発の場の品質が悪いと製品の品質も悪いということです。開発の場の品質についてはアレグザンダーの「無名の質」が使えそうです[『時を超えた建設の道』]。メンバーが生き生きしている(alive)、それから、一体感がある(whole)、居心地がいい(comfortable)。そういうチームをケント・ベックは考えたんだと思います。

アレグザンダーは、建築のハードウェアの品質ではなく、alive、whole、comfortableという住人まで含めた品質を作ろうとしている。僕らもシステムの品質として、ものの品質ではなく、その周りのたくさんの利害関係者も含めた品質を考える必要があります。日本の開発はあまり人間系じゃないんですが、アジャイルのマニフェストはとても人間系ですよね。その人間系を含めた品質というのは、製品の品質と次元が違うんです。アジャイルが人間系を含めた品質を追求しているのが、僕はとてもいいと思います。

素晴らしいですね。作る人と作るものは相似関係にあるというコンウェイの法則で、4つの部隊で作ると4パスコンパイラになるという話があるので、一枚岩に近いチームを作れば、一枚岩に近い顧客も一緒に巻き込んだシステムができるとも言えるんでしょうね。だから、ケント・ベックはソフトウェアの設計ではなくて、ソーシャルネットワークとしての開発チームのあり方を設計したのかもしれません。

反復型開発と言いますが、アレグザンダーもオレゴン大学の実験で同じことを言っていて、Piecemeal Growthという表現をしています。ソフトウェアではiterativeやincrementalという言い方をしますね。それから、住民参加の法則。これはそのままオンサイトカスタマーです。ですから、人間系の世界はやっぱり建築もソフトウェアも同じなんじゃないかと思いますね。

ラルフ・ジョンソンがエクストリームプログラミングとアレグザンダーのパターンに関してのメールを1通書いていて、その中にPiecemeal Growthが共通点だという発言があります。

それを実現しようとしたら、本質的な問題を究めていかないといけないですよね。本当の課題は何なのかというところを。建築だったら住人にとって何が本当に必要かという部分ですが。そこが多分難しいんですね。

その価値をはっきりできないと難しいですね。

そこでモデリングが出てくるんじゃないですか?

そうです。モデリングは、カスタマーと開発チームがいる開発の場の道具というか武器だと思うんです。モデリングがなければ話も何もできない。今まで僕も大規模開発をずっとやってきましたが、モデリングという発想がそもそもなかったですね。

今まで解領域を中心にモデリングしていたんですが、問題領域をもっと違った形で捉えていく手法が必要かもしれません。

その辺はRUPがはっきりしています。開発チームの目標は顧客満足なんですけど、顧客は真の満足が何かを言ってくれない。要求通り作ってもだめなので、真の満足をもたらすにはユーザー参加の反復型開発が必要なんです。RUPの一番最初にそう書かれています。

品質というとバグがないとか止まらないとかがフォーカスされていますが、ISOでは、信頼性というのは8つくらいある品質特性の1つでしかない。大規模なシステムはもうバグフリーの限界に来ています。たとえば金融の大規模システムをバグフリー思想で作っても結局は止まっちゃって、止まらないことを前提に作っていたから止まった時に右往左往して対応できなかったりします。逆に今は、クラウドなどを見ても、個々の要素は止まるという前提でレプリケートなどで対応しているので、バグフリー思想で品質を定義するのはもうやめた方がいいのかと思いますね。顧客の要求は見えなかったりどんどん変わったりするので、壊れないための品質の作りこみに時間をかけるよりは、どんどんリリースして変えていく方が今の時代のスピード感に合っているんじゃないかという気がしています。

とはいえ、たとえば人命に関わるものや社会インフラを支える大規模基幹系が止まると問題になるじゃないですか。

「ソフトウェアが止まらない」じゃなくて、システム全体として止まらないようにしておけばいいんですよ。

DDD(ドメイン駆動設計)ではXPをベースに、ユーザーと開発者が同じ共通認識をモデリングしながら開発していくということですが、アジャイルやモデリングが違った形で出てくると何か変化が起きるんじゃないかなと思うのですが、いかがでしょうか?

アジャイルを説いてその変化を起こそうというのは無理があると思うんです。まず状況の変化があって、だからアジャイルでやった方がいいでしょ、というのは想像しやすいんですが、アジャイルでやることが目的ではないですよね。

まず今の受託開発などのビジネスモデルの中でアジャイルやモデリングがどれだけ活きるのかと考えるアプローチも必要かなと思います。急に、一括契約という習慣をやめて、価値創造契約[英和システムマネジメントで提唱している、システムの構築ではなくサービスの利用に対して料金が発生するという契約形態]になるかというと、そういうムーブメントがすぐに起きることはないでしょう。今できることは何かを出していかないと、現場の人もついてこないと思います。

今、クラウドの環境が出てきていて、セールスフォースなどはアジャイル的な開発をしていると聞いています。クラウドの環境の場合は、納品というのがなく、環境を作ってそのまま使ってもらう形になるので、PaaSと呼ばれるようなクラウドの開発環境で開発する形はアジャイルと親和性が高いんじゃないかと思います。

それはさっき言ったSmalltalkの時代に戻っているわけですよね。コンパイルとかデプロイの区別がなく、書いたら即、という感じで。セールスフォースも少しだけやったことがありますが、ドキュメントを書いて出すというのがばからしく思えます。画面そのものをGUIの中でいじって、それがそのまま動いている世界なので、作ったものを見て、それを直して、ということが技術的にできるようになっていますよね。

セールスフォースなどだと、バージョンアップがされたときに問題が起きないんですか?

セールスフォースの場合は、基本的にセールスフォース側の都合で全ユーザーをバージョンアップするわけなんですが、一応、問題を起こさないようにしていると言っていますね。

Googleマップでは、APIのPremier契約でAPIを一定期間保証するようなことをやっていますね。ある程度以上のことを求めるなら追加料金を払ってくださいということですね。

若林さんのところはどのようなクラウドサービスをされているんですか?

SaaSでグループウェアを提供するとか、ERPのソフトウェアパッケージを提供するとか、あとはIaaSと呼ばれる仮想マシンを提供するようなこともやっています。

そろそろまとめにかかりたいのですが、4月からのアジャイル部会で継続審議できるような課題を出せるでしょうか?

アジャイルとオフショアってあまりかみ合わない気がするんですが、どうしてアジャイルになるんですか?

オフショアは大企業で定型化して発注するような形に固まってきちゃっていて、それはアジャイルではないんですよね。だから日本で考えるとアジャイルとオフショアはかみ合わないという状況になっていると思います。定型化しているところにUMTPでさらにこうすればいいと提案してもあまり意味がなくて、もっと混沌としてどうすればいいか分からないようなところに回答した方がいいんじゃないか、ということでアジャイルに軸足を移すというスタンスです。ですから、今までのわりと大量生産的なやり方以外のオフショアが必要なら、そこを扱っていくという意味合いです。

オフショア部会の活動はある程度ちゃんとした成果が出ていると思うんですが、それはオフショア全般ではなく、オフショアとモデリングというところにうまく絞ったからだと思うんです。だからアジャイルも、アジャイルとモデリングということに絞って、その時に、たとえば平鍋さんにそれならこういう問題やこういう問題があるよね、という宿題を貰えると、活動のよすがになるんじゃないかという気もしますが。

ビュアアジャイルでモデリングというのはちょっと攻めにくいので、ウォータースクラムフォール的なアプローチで、頭とお尻のところはちゃんとモデリングで締めましょうというような作戦を思い描いてはいるんですが。

さっきの、アーキテクチャを刈り取るというところが1つのキーなのかなと思います。特にアジャイルというコンテキストでは、アーキテクチャというキーワードとモデリングというキーワードはすごくつながりがあるという気がします。

それ以外に、要求開発のところと、UX[user experience]というかユーザーインターフェイスデザインやユーザビリティのあたりも結構モデリングと絡むと思います。

今日はあまり話題に出てこなかったと思うんですけど、UMLをもっと広げて、SysMLがターゲットとしているような、色んなステークホルダーが共同で少し大きめの対象を作る、つまりソフトウェアのエンジニアだけじゃなくて、メカの人やエレキの人や、ユーザーの中でも土木の関係者や電気の関係者など、色んな人が集まってチームで開発をするといったときに、モデリングは絶対に必要になってくると思うんですね。その辺りは、今日はわざとテーマに挙げなかったんですが。

ファシリテーションではなくてモデリングですか?

ファシリテーションもあるしモデリングもあります。

組み込みの世界はSimulinkのようなモデルベース開発がかなり脚光を浴びていますよね。

モデルの世界だけでコンセプトから実行可能なコードまでつなげていく、要求の変化に合わせて制約条件をどんどん変えながら、実行可能なソフトウェアも作っていく、それをかなり継続的に毎週のように作っていっている、という話を聞きます。アジャイルという言い方はしていないんだけれども、アジャイルモデリングにかなり近い形で実行可能コードまで含めて対応しようとしているようなので、面白そうです。

組み込みですか?

組み込みをもう少し広げた感じでしょうか。

組み込みで行われているような、UMLの概念をもう少し広げることによって、そこにSysMLじゃないですけど、何かが出てくるのではないか、ということですか。

そうすることでエンタープライズ系の人も、要求に留まらず、先ほどのcustomer developmerntみたいなところも含めて、ゆるやかなモデリングとつなげられるんではないかな、という希望を持っています。

マインドマップとつなげる話も面白いかもしれませんね。

そうですね。

上流とつなげるというのと、動くものとつなげるというのと、両方ありますね。

システムエンジニアリング系の人たちは、トップのところから実行可能なところまでをつなげようとしています。上で書いているモデルは、ビジュアルプログラミング的な、かなりポンチ絵的なものなんですよね。それでも結構実行可能コードに落とせちゃっているので、開発環境としてはソフトウェア屋さんが使っているツールよりもかなり先に進んでいるなぁという感触があります。

最近人気のある本で、『ビジネスモデル・ジェネレーション』というのがありますね。ああいう辺りにモデリングをうまく使うと、ITだけじゃなくてビジネスの価値創造的なクリエイティブなものをどう考えていくかのヒントになるかもしれません。

マインドマップは自由度が高くて、使いこなせる人が使うといい方向性が出せるんだけど、マインドマップそのものに方向性があるわけではありません。そういう意味で言うと『ビジネスモデル・ジェネレーション』はある程度の大きなフレームワークを何タイプか用意してくれているところがすごくいいですね。

昔、UMLでモデリングするためのレファレンスがないねと皆が言っていたときに、コード/ヨードンのビジネスモデルのパターンだとかストリームラインモデリングだとか、いくつか出てきたじゃないですか。それと同じようなレベルでマインドマップのビジネスモデリングパターン版のようにも思えます。しかもファシリテーションや見える化も相当考えて練られているので、使いやすいかもしれないですね。

今日平鍋さんが紹介してくれたユースケースに落とす前のいくつかの項目分けも、プレーンなマインドマップじゃなくて…

図6 マインドマップのテンプレート (講演資料21ページ下)

そうです。最初の枝は何かという…

それを決めてやることによってテンプレート化することを目指しているんですね。

1つの形式を作ることで、メタ知識にしたいんです。何回もそれを応用できるように。

アジャイルの開発自体には、メタ化するという概念はあるんですか? 話を聞いていると、アジャイルでは経験が人に集まって暗黙知が増えるのがいいことであって、それを顕在化しませんよね。

そうです。

ところが企業は、持っているものを全部吐き出せと言います。テンプレート化、標準化、部品化して、なるべく見えるようにするじゃないですか。どうしてアジャイルにはそれがないんでしょうか?

それをやりすぎたことによる人間性の欠如を取り戻したいという活動なんです。

なるほど。

欧米の方がむしろ、全部吐き出して仕様書と突き合わせるなどをするので、それに対するカウンターカルチャーなんでしょうね。

そうすると、企業の経営サイドの意向とは違う方向で動いているということですか?

企業の経営サイドにも、顧客満足と従業員満足が一番大切だという企業もあるので、何を優先するかによるんじゃないんでしょうか。

アジャイルって言っているものを額面通り受け取ると話が極端になってしまいます。背景にどういうコンテキストがあってそうなっているかを知って、それから日本のコンテキストにあてはめて解釈し直さないと、現場の人もなかなかついてこられないと思います。

XPだった頃は「エクストリーム」だという自覚があったけれど、スクラムになってからはないですからね。

マインドマップもですが、日本人はQC7つ道具みたいなものが好きですよね。

そういうノリでボトムアップでやる活動もいいですね。

DSL[domain-specific language: ドメイン固有言語]じゃないけど、それだってDSLと言ってしまえるところもあるような気がします。

QCの8つ目の道具とか言って展開すると、結構乗ってくる企業があるかもしれませんね。

いい言い方ですね。マインドマップです、8つ目が見つかりましたって。(一同笑)

MDAは影を潜めていますが、一方で組み込みなどを見るとモデルからコード生成までつながっているので、modeling as programming languageという側面も場合によっては有効と捉えていいんですか?

MDなんとかというのはすごく広がってきていますよね。MDA(モデル駆動アーキテクチャ)はOMGが唱えたマーケティング用語ですが、もうちょっと広くMDE(モデル駆動エンジニアリング)と言ってみたり、MDD(モデル駆動開発)という言葉は学会で割と出てくるし、MBD(モデルベース開発)という言葉は日本人が好きなんですよね。MBDとMDDの使い方の違いに言及している論文もあるし、MDDを包含するものとしてMDEを立てているところもありますね。

組み込みでツールチェーンが流行っていますが、あれも上流からつながるからツールチェーンにできるわけで、やっぱり上流のモデルがエンタープライズ系以上に有効に活用されていますね。

他に何か、これは言っておきたいことはありますか?

平鍋さんに質問なんですが、アジャイルが2回目に盛り上がってきたときのブレークスルーになったドライバは何ですか?

日本でですか? それは明らかにWebとゲームだと思います。その会社が勢いがいいですね。

言い方を変えると世代交代ですね。それをやっているのは20代30代の人たちですからね。

たとえばGREEとDeNAがすごく求人してますとか、そういうことですね。

Webとおっしゃっているのは、ソーシャルメディアをどう展開するかということですか?

BtoCでの動く顧客をどうお金に変えるかというビジネスが今はたくさんあって、その場面ではビジネスとITは直結せざるを得ないというビジネス構造だと思っています。

技術的なブレークスルーはそこにはなかったんですか?

もちろんあります。アーキテクチャとしてのWebが1つ、もう1つはIDE、コード構成管理、その他たくさんのツールが出てきたということが大きいと思いますね。クラウドだとか、オブジェクト指向の技術がテスティングに応用されたとか、リファクタリングとか。

ビジネスのニーズと、そういう技術的なシーズが両方重なって、2回目のブームが来ているということですね。

それで言うと、楽天はWebのくくりに入りますか?

入ります。

そこもアジャイル?

アジャイルでやっていますよ。

基本的にあそこはアウトソースしないという方針で、インハウスでやっていますよね。

たいていそういった企業はインハウスです。

インハウスだけど、globally distributedというのはありますよね。

BtoCのアプリは、作っている人が「こうすれば良くなる」というアイデアを出しやすいと思うんです。それがアジャイルに向いているのだと思います。ボトムアップに改善しやすいじゃないですか。ソフトウェア、特にInB向けのソフトは、自分がこう作ったらどうなるのかがよく分からなくて、反映しにくいのですが、BtoCはやりやすかったのかと思います。ゲームもそうですよね。こういうアイデアでこうしたらもっとよくなるんじゃないかとボトムアップに色んなことが言えるような気がします。

ダウンロードコンテンツっていう、後で買い足してどんどんお金を収集するような仕組みができているから…

設計した人が言う通りに作るんではなくて、作っている人がもっとこうした方がいいんじゃないのというのが足せると、アジャイルもすごくフィットしますね。

我々もダウンロードコンテンツを提供するみたいにどんどん付加価値を追加していくようなビジネスを展開すれば、そういうときにアジャイルというものがすごく有効な武器になるということですね。

おっしゃる通りです。

ビジネスを見直すという意味でスタートアップとアジャイルの親和性が高いということなんですか?

そうかもしれませんね…

クラウドと組み合わせるとダウンロードコンテンツビジネスみたいなのができそうですね。PaaSでもどんどん機能追加でいくら、この機能でいくら、と積んでいくような。

お金を払ってもらえるような形に持っていければ。

今、シリコンバレーベンチャースタートアップではARCという言葉があって、アジャイル、Ruby、クラウドという3種の神器の組み合わせが一番早いと言われています。

エンタープライズシステムのアジャイルへのパラダイムシフトはクラウドと一緒に起こっていく可能性が高いということですか?

クラウドなのかは僕もちょっと分からないです。スタートアップの環境の中ではその3つの組み合わせがうまくいくということは言えると思うんですけど、その中のどれが本当に引っ張っているものなのかは分からないです。

ドキュメントを作っているとスピード感が損なわれてしまうので、アジャイル/Ruby/クラウドという流れでは出てこないと思うんですけど、その中でもモデリングをする技術力は必要だという認識でいいですか?

それはあった方がいいんじゃないでしょうか。プログラミングもモデリングだということもできますしね。

アジャイルとモデリングを並べたときに、アジャイルをやっている人はモデリングを嫌うというか排除する傾向が一部にあるんじゃないかと思っているんですが、それが共存できるものであるっていうところを平鍋さんの口から言っていただけると…(一同笑)

共存したいですよね。少なくともホワイトボードにUMLチックな絵を書きますもんね。

ドキュメントには書かないけれども、モデリングの技術力を磨いていくということはアジャイルエンジニアとしても必要なことだと…

はい、そう思います。Ruby on Railsでモデルのクラスを書くときに、複数形で書いたらmanyになるので、UMLで1対多の関係を書くというのとほぼ一緒ですよね。それをテキストで書くのかグラフで書くのかは別にして、どういった概念構造を作ったら、解こうとしている問題領域の形をより素直に表せるかという問題は、プログラミングだろうがモデルであろうが解いているので、同じだと思います。

それでは時間を過ぎましたので、これで終わりたいと思います。アジャイル部会に引き継ぐテーマとしては、アーキテクチャのharvestingと、その中でモデリングがどう生きてくるか、また既存システムへの採用の可能性などを取り扱っていけるといいかと思います。

平鍋さん、今日はありがとうございました。