それでは、ワークショップを始めます。
最初に皆さんに自己紹介をしていただいて、その後で今日のセミナーの内容についていろいろ議論したいと思います。では大森さんから、簡単に、経歴とか仕事内容をお願いします。

東芝ソリューションの大森です。職場では生産技術センターという部署にいまして、UMLを初めとして、さまざまな生産技術を使って生産性を上げる活動をしています。オフショアの活用とかいったことも含まれています。アジャイルについては、社内で試し始めたぐらいなところです。プロダクトオーナーをうまく巻き込むことが難しいので、そのあたりの、経営層に近い人を巻き込むところに『BABOK®2.0 ガイド』の話とかを活用できたらと感じております。よろしくお願いします。

オージス総研の赤坂と申します。今日はセミナーに参加させていただいた流れで参加させていただきました。UMTPは、2005、2006、2007年ぐらいに組込み分科会のほうに参加しておりました。現在は、組込みモデリング部会の幽霊会員になっているのか入っていないのかわかりませんけれども、ほとんど活動しておりません。業務のほうでは研修のトレーナーをやっております。最近はアジャイル系の研修も担当させていただいております。よろしくお願いします。

河合です。仕事は、10年ぐらい、オブジェクト指向とかUMLを中心に研修をやっております。その過程で、Rational Universityというのをやらせてもらっています。Rational Universityは、要求から分析、設計とずっとありますけれども、今日のお話はその要求のところと接点がかなりいろいろありそうな気がします。Rational Universityもここ10年ぐらいやっていますけれども、最初は六つのベストプラクティスといって開発が中心でしたが、途中で大きく変更があって、今度はビジネスドリブンという言い方に変えました。ビジネスドリブンの六つのプリンシプルと。やはり6個は6個で中身は一緒ですけれども、ビジネスドリブンと言い方を全然変えていって、開発ではなく、価値をユーザーに提供するというように、ものすごく変わっていっています。そこら辺が今日のお話と大変接点がありそうな気がしました。1ラウンド目はこれぐらいにしておきます。（笑）

オージス総研の竹政と申します。よろしくお願いします。もともとはUMLとかモデリングを専門にしています。最近は、ビジネスイノベーションセンターという会社の部署に所属しており、上流の部分を考えております。その意味で、今日のお話にかなり近いところかなと思っております。よろしくお願いします。

オージス総研の細谷と申します。経歴的には、もともとは大森さんと同じメーカーにいて、大森さんが職場の先輩でした。当時、デザインパターンとかそういうものが大好きでしたので、オブジェクト指向をやらせてあげると唆されてメーカーに行かせていただき、フレームワークを作ったり、しばらく楽しい思いをさせていただきました。その後、オフショア開発など、海外のエンジニアと一緒に仕事をするほうにシフトしまして、中国に6年ぐらいいました。オフショアの仕事を受ける側で現場を切り盛りしたり、できるだけUMLで図を描いてねと言ったり、100万人のエンジニアのほとんど、99％はそういうことに興味がない人たちにどうやってそれを伝えるかと。うまくいかず、そういう挫折も味わって帰ってきました。
今はグローバルビジネスサービス部におりまして、開発の仕事を外に出すのではなくて、我々のソリューションというか持っている価値を見直して、海外に持っていってどれだけ価値を発揮できるか、それをどうやって売るかという、そういうチャレンジを受けています。主に東南アジアのほうに今は取り組んでいるところです。海外の人たちと一緒に仕事をしながら、日本のITの価値はどこにあるのかなと見直すような、そういう日々です。
開発の仕事をする上では、拠点の立ち上げとかも含めると、ウォーターフォールだとスピードがもう全く追いつかない。うちの上海の拠点はウォーターフォールで立ち上げましたが、やはりドキュメントのお作法とかを習得させるまでに最低３年かかって、あまりに時間がかかり過ぎるので、これからはアジャイルが当たり前と思っています。そういう観点でアジャイルとかモデリング、価値、分析というところに非常に興味を持っております。よろしくお願いします。

豆蔵の羽生田です。私もUMTPに関しては2003年の立ち上げのときからずっと活動に加わらせていただいていて、今はL4認定の準備もしています。今回3年目です。皆さん、ぜひ、周囲でL4を受験できそうな人がおられましたら、「ちょっと面白そうだから受けてみたほうがいいよ」と唆してあげてください。（笑）
今日のお話とつなげると、私自身は、モデリングとか、川添さんに今活動をやっていただいているアジャイルプロセス協議会の立ち上げとかにもかかわってきて、ようやくアジャイルに関してビジネス的に豆蔵の中でも回り始めたところです。今後は、今まで豆蔵やオージスさん等がこの業界の中でやってきたモデリングという話とアジャイルをつなげてみたり、あるいは、要求開発と以前言っていたものを、要求という切り口だけだと狭いので、エンタープライズのビジネス全体をテーマにして、今日のお話などとも接点を持ちながら、もう少し広い意味での活動として捉え直して、それに関する人材育成なども含めてやっていきたいと思っています。よろしくお願いします。

豆蔵の山田と申します。私はもともとはSIをやっていましたが、豆蔵に入ってからプロセス改善に取り組んでいます。その流れで、プロセスということでアジャイルのほうも見始めたのが、アジャイルとの接点です。その流れで、こういう部会にも出させていただいている感じです。今はPM系の講師をやったり、スクラム、アジャイル系の講師をやったり、あとは、ある企業さんの中に入ってその組織の中でのアジャイルの普及活動というか定着化のご支援をするのが主な業務です。
『BABOK®2.0ガイド』の一番最初の要求の洗い出しのところは、アジャイルであってもウォーターフォールであってもすごく重要だと感じているところです。あとは、やはり決定打的なものがないので、そこをいかにその場に合ったいいものを提供してあげられるかが鍵かと思っています。今日はAgile Extensionの中でそういったお話が聞ければいいなと思っています。よろしくお願いします。

中菱エンジニアリングの古川と申します。個人的には、現在、ビジネスジェットのサービスを提供していくためのエンタープライズ系のシステムの準備をしており、まさにビジネスがないところからビジネスを立ち上げる、それをサポートするためのシステムを準備するというところをちょうどやっています。今までは組み込み系のプログラマ、システムエンジニアをやっていました。
一方で、会社のほうではやはり組み込みシステムがメインでウォーターフォールでずっとやってきていましたが、どうしても要求のほうが増えてきている。当然のように要求のトレードオフをしなければいけないところが出てくるんですが、会社の組織構造的に、要求は絶対来るものだ、これは絶対やれよというような感じで仕事をしていました。依って、トレードオフなしに仕事をしていた。そうすると結果的に破綻するという道しか見えてこないので、やはりそれではまずいと。そこで、アジャイルで見えることを一個一個やっていくというアプローチをとっていかなければいけないと思い始めて、社内でアジャイルを普及していこうかということを今、やっているという状況です。ここの部会ではガイドラインのほうをいろいろ手伝わせてもらっています。今まで、UMLとアジャイルは別々の領域、似たような『BABOK®2.0ガイド』もアジャイルと別々の領域なのかなという感じです。Agile Extensionという形で適用されているので、どういう視点で適用されているのかというところをお聞かせいただけたらなと思っています。よろしくお願いします。

オージス総研の原田と申します。ふだんの仕事は、アーキテクトとして、実際に手を動かしながら物を作ったり、お客さんと話したりしています。それ以外に、アジャイル開発センターを兼務していまして、社内のプロジェクトにアジャイルっぽいプラクティスを適用させたり、講演の中でも話を挙げていただいたを部内の活動に対して適用させたりというところをやっています。今現在、客先に出ていて、どうシステムを作っていくかというところでお客様と一緒にドメインモデルを描きながら、何が欲しかったのかという話をまさに今やらせてもらっています。
まさにこの本の中にあったような、顧客とユーザーによって価値が違うから分けて考えないといけないというのを、今日まさに体験してここにやってきた感じです。ユーザーさんとは握れているはずなのに、その上の方と話すと観点がちょっと違って話がうまく通じなかったりしていて、ちょっと困っています。後で濃い話ができたらと思っています。よろしくお願いします。

アジャイル開発部会の主査の中原です。私はもともとは日立グループでソフトウェア開発、システム開発をしておりました。現在は定年退職し、大学や専門学校などの非常勤講師をしています。UMTPとのかかわりは、日立グループにいたときにオフショア開発をしていて、社内でUMLを使って成功させようという方針があって、UMLの人口をふやすためにUMTPに入ったのがきっかけです。オフショア開発部会に入っていろいろ活動していましたが、部名がアジャイル開発部会に変更になり、現在に至っております。
現在はシステム開発はもうやっていないのですが、大学でシステム設計の方法論を教えていて、現在はウォーターフォールですが、その中にアジャイル開発の手法を取り入れることを考えており、役に立つものはないか調査するために参加しております。よろしくお願いします。

川添です。先ほど自己紹介させていただいたので、改めてお話しすることもそうないのですが。もともとソフトウェア開発で、UMLも全く縁がないわけではなく、多分、協会ができたころと近いときに書籍を書いたという、そんな経緯もあります。また上位資格にチャレンジしてみようかなという気がちょっと出てきたりもしています。
今日は『BABOK®2.0ガイド』とアジャイル拡張版についてお話をさせていただきましたが、最後にお話ししたように、モデリングというのが一つつなぐ鍵になりそうな気がしています。皆さんのモデリングに関する活動とBAとかアジャイル拡張版がどういうふうにつながっていけば、より世の中に貢献できるのか、世の中に必要なものになっていくのかというような話ができればいいなと思っています。よろしくお願いします。

では、一通り自己紹介が終わりましたので、あとは、セミナーの中で深く議論したいことがありましたら、お願いします。それについていろいろ議論していきたいと思います。

ディスカバリーフレームワークとデリバリーフレームワークというお話がありました。詳しくは知らないのですが、全体を見るとか、顧客として考えるとか、価値を分析する、それはプラクティスみたいな形になっているのでしょうか。例えばXPだったら12か14のプラクティスだとか（がありますね）。RUPなども、実はあれはベストプラクティスといって、プラクティスですね。1個だけではなくて、これとこれとこれをやってとお互いに関係があって、パターンランゲージ風になっていますね。前回のセミナーでも、IPAで60何個かのアジャイルのプラクティスを作ってパターンランゲージ風に作り上げたというお話がありましたが、今日のお話で、BOKかAgile Extensionの中にプラクティスとかパターンランゲージみたいなものはあるのでしょうか。

『BABOK®2.0ガイド』のプラクティスというようなものはありません。ただ、アジャイルのプラクティスはAgile Extensionに書いてあります。ただ、『BABOK®2.0ガイド』独自の何かという定義はありません。アジャイルの中のプラクティスのどこに関係があるかとか、そういうことは書いてありますけれども、『BABOK®2.0ガイド』のというものはありません。

アジャイルのプラクティスは割と開発の中身のほうです。今回はもっと上流の要求のほうでね。それで、さっきの七つのフレームワークというのはプラクティスと違うのですか。

七つの知識エリアですね。知識エリアは、ビジネスアナリシスの活動の中でどんなタスクが必要かということと、インプットとアウトプット、あと、それをやるために必要な補足。これは見てのとおり、ほかの知識エリアと比較するとボリュームが少ないです。知識エリアの中に書かれていることというと、主要なタスク、インプット、アウトプット、使用するテクニック、それをまとめたものです。

「引き出しの目的」のところに「BAの要となるタスクである」と書いてありますが、そのタスクはフレームワークの中に書かれているのですか。

はい。タスクは各知識エリアの中に書いてあります。知識エリアは全部で七つあって、基礎コンピテンシー以外の六つの活動に関するところでいうと、一つの知識エリアで大体六つぐらいのタスクが定義されています。

でも、そのタスクをもう少し、こういうふうにやればいいよとか書いていったら、プラクティスになっていくと思うのですが。

そうですね。その具体的なところがないわけですよね。
今、別のワーキンググループでは、プラクティスというか、まずはマニフェストを作ったらいいのではないかという議論がされています。BAのマニフェストをワーキンググループの活動の中で作っていこうと思っています。

マニフェストというのは価値を決めることですよね。それはすごく大事ですけれども。それはまだないわけですか。

そういう位置づけのものはありません。

何か、アジャイルが価値であるみたいなことを、名前から感じるのですが。

アジャイルが価値ということではありません。ビジネスアナリシスとしては、アジャイルも、とることができる一つのアプローチ、そういう位置づけです。ただ、今後はそういうアプローチの仕方がより増えていく、そういう見方です。

気になるのは、アジャイルは素早いということですよね。前にも言ったけれども、もともと、RUPのような大規模開発に対して短期・小規模開発を昔はアジャイルと言っていました。でも、今は言い方が少し変わってきたみたいで、アジャイルエンタープライズとかは〔早いor速い？〕ということではない。僕は、名前を例えばスマートとかにしたらどうかと思っています。素早いではなくて、スマートな、賢い開発。そうすると、RUPも今の素早いアジャイルも、一緒くたにできると思います。RUPは最近人気があまりないみたいですが、自然にどこかに入っていっているのですかね。

〔早いor速い？〕という言葉が先に出てしまうのはどうかなと個人的には思います。早くアプローチできるというか、そういうものかなと私は思っています。

キーワードだから。もともとアジャイルは、素早いという意味とは別に、アダプティブで環境に常に適応し続けるという意味のほうが大事だと思います。そういう意味では、アジャイルという言葉だけに固執しなくてもいいと思います。

そう思っている人はいいけれども、ぱっと聞いたら、素早さがすごい価値だと思ってしまうのではないですか。

〔早いor速い？〕もいろいろありますよね。高速開発とかもあるし。

ヤフーさんの爆速とか。（笑）
でも、私の中ではアジャイルはフィードバックループのイメージがすごく強いので、昔みたいにウォーターフォールみたいなでかいバッチで最後にわかるのではなくて、少しずつ理解するとか、そういうイメージがある。そういう意味では、失敗も早くわかるとか、いろいろなところに早く気づけるみたいな早さはあるかとは思います。

改善の機会を得るということですかね。機会の頻度となったらやはり、従来よりは〔早くor速く？〕ということになるのでしょうね。

先ほどお話ししましたけれども、『BABOK®2.0ガイド』とアジャイルは、僕のイメージの中では両極端です。かっちりしたものが決まっていて、それに対してアジャイルは、機敏にやっていく。それを適用するAgile Extensionを作るに当たって、着目したというか、気にした点、注意した点は何かありますか。

直接開発した者の話も聞いてないですし、その開発の状況の話はわかりませんが、まず、『BABOK®2.0ガイド』はアジャイルの反対側にあるというものでもありません。こういうことをやりなさいよというタスクは書いてありますが、それをいつどういうタイミングでどれをやるか、しかもその順番はどうするかということが書いていません。ですから、Agile Extensionというものが出ましたけれども、もともとこれを使ってアジャイル的なアプローチでやっている人たちもたくさんいると思います。これがアジャイルと反対側にあるものというわけではないので、そういう書き方もしていません。
でも、初めて見た人がどこを気をつけてアジャイル的にやっていけばいいかというところは、多分、アジャイル・アライアンス（Agile Alliance）の人たちと一緒に作成しているので、そういう人たちのアドバイスを聞きながらまとめたのではないかと思います。

形的には、先ほど言われていたように、『BABOK®2.0ガイド』がまずベースにありますよと。そこの中に、ではそのアジリティーを高めるためにどういうアジャイルプラクティスをどこにどのタイミングで適用すると、よりよくなりますよというような形ですか。

はい、そうですね。これをベースに早くフィードバックを得て改善しながらビジネスも動かしていかなければいけないという認識を持っているアナリストの人たちはいっぱいいると思いますけれども、自分でやり方の順番を決めたり、使うテクニックを決めたり、そういうやり方をしていたと思います。それを、体系立って、アジャイルのテクニックとちゃんと関連づけて、『BABOK®2.0ガイド』と関連づけてまとめたものがAgile Extension、そういう位置づけです。

はい、わかりました。

日本だと古川さんが持つ「『BABOK®2.0ガイド』とアジャイルは両極端である」という印象を持つ人は結構、多い思います。海外は人の印象は異なりますか？

海外だとアジャイルに関する認識も日本とは全然違うと思います。『BABOK®2.0ガイド』もその辺は多分違うと思います。

海外だとビジネスアナリストという職種がありますが、日本ではあまり聞きません。それは、単に日本が遅れているんでしょうか、あるいは事情が異なっているのでしょうか。

まず、向こうでビジネスアナリストという職種が確立しているのは、ユーザー側の企業にビジネスアナリストの人がいるわけです。組織の構造として、向こうはSIerというのがなく、ユーザー側の企業が自分たちの企業の中で自分たちのビジネスにITをどう使っていけばいいかということを考えるのは普通のことなので、そういう企業の中にまさにビジネスアナリストの役割をする人がいる、そういう職種ができています。ただ、コンサルティング的なことをやる組織も存在していて、コンサルティング的なことを業務としてやっている会社にもビジネスアナリストはいますし、外部の組織を支援するビジネスアナリスト（もいます）。ただ、数的に日本よりずっと多いのが、ユーザー企業が自分たちの組織の中にビジネスアナリストを持っている、そういう形態です。

自分の会社だから、当然、経営と直結したITというところを考えるのは自然なわけですね。外部となると、一部のコンサルティングがあるにしても、ちょっと難しい。日本だとどちらかというと外部が多いという状況ですか。

そうです。日本も、本当はユーザー企業がもっとビジネスアナリストを置いてほしいというか、ユーザー企業の人たちがもっとITに関心を持つ必要があると思います。そうなってくると変わってくると思いますけれども、現状としては、『BABOK®2.0ガイド』に関して興味を持っていただいている企業はほとんどさんです。ユーザー企業は少ないです。『BABOK®2.0ガイド』というものの存在は知っているし、何かビジネスに役立つものだというのはわかっているけれども、それをどう実現するか──ソリューションという言葉を使っていますけれども──は、IT側の知識を持っているユーザー側の人たちが少ないので、やはりまだ外部に頼りきりという感じです。

難しいですね（笑）。

難しいですよね。難しいですよ。

私も日立時代に、『BABOK®2.0ガイド』は普及していないけれども勉強しようという雰囲気はあって、私はSIerですが、そこで勉強をしました。まだ活用までは至っていませんが。
ITベンダ側がやるようなものだと私も思っているのですが、今の話ではどうもそうではないようですね。日本はどのように展開されていくようになりますか。

ユーザー企業までは届いてないので、やはりSIerさん。SIerさんはすごく興味を持っていただいているので、SIerさんにアプローチをする。そして、SIerさんが自分たちの売りとしてビジネスアナリシスという活動を積極的にやって、こういうふうにビジネスを考えていますよ、こういうふうにやっていますよというのをユーザー企業の人に見せることによって、ユーザー側の人たちもそれが大事だということに気がつく。そういうアプローチの仕方しかないという感じです。本当はユーザー側の企業の人たちももっと知ってほしいと思いますけれども、まだ興味あるという段階みたいで、それ以上までは行っていませんね。それ以上行くためには、今の日本のユーザー企業としてはSIerさんの助けが必要な気がします。

そういう状況だと、Agile Extensionというのは前面に出していったほうがいいですか。

うーん、どうでしょうね。（笑）

そこはSIerさんが対応できないのでしょうね。

そう。SIerさんも本当にまだ一部ですね。

まずSIerが自分の価値を分析してみたらいいのではないですか。（笑）
大体、SIerを選ぶときは、どれだけ優秀な人がいて値段がどれぐらいかぐらいしかないでしょう。本当にそれしか価値が届けられないのかというところを一回見直していったらいいのでは。
私の領域でいうと、今、SIerもユーザー企業についてどんどん海外に行っています。日系企業を相手にするときには同じノリでいいですけれども、ローカルに物とかサービスを売ろうとしたときに、話が全然通じないですよね。「我々はSIerです。じっくり要件を聞きます。言ってくれたらそのとおりのものを作ります」と（言っても）、要件なんかない。
特に新興国は今まで業務がなかったから、「私たちはベストプラクティスが買いたいのです。おたくらのベストプラクティスは何ですか。それはパッケージになっているでしょう。買いますよ。業務はそっちに合わせます」と。でも、日本のSIerは逆で、業務がもう既に確立されている中で、それをいかにITで効率化するかということしかやっていないから、「おたくの業務は何ですか。あなたの担当の業務は何ですか。それを効率化することをできるだけ安くやります」ということしかやっていなかった。
だから、海外に行くと、日本のベンダーはほとんど商売できていません。僕らも含めて、自分らがどんな価値を届けられるのかということが全く説明できない。パッケージ化されていなくて、売れる形にできてない。自分らが今までSIをやってきた中で身につけてきた業務知識とかノウハウが何で、それが海外に行くとどういう価値になって、どういう形にパッケージングをしておけば売れるのかというのを、今からやり始めているところです。当分の食いつなぎとして日系企業さんを相手にしているけれども、そんな市場は限られているから、みんな同じところへ行こうとしていて、いま大変なことになっているわけです。

ああ、そうなのですね。『ものづくり白書』の中に出ていた、日本は欧米諸国と比べて経営力が圧倒的に低いというデータを見ていたときの、その話が今わかりました。海外での競争力が非常に劣って日本が負けている要素の中に、ビジネスを考えてあげられないということもあるのでしょうね。それありきでしか日本の企業はやったことがないという。

私の言い方ですけれども、欧米だと大体、ITというと、それでROIをいかに高めてくれるのかという観点で提案を求められます。日本だと、情報処理という言い方が悪くて、わあっと来る情報をとりあえずシュレッダーにかけてどこかへほかしておいて、必要なときだけ取り出せればいい。その間には人が必ずいて、決まっている業務プロセスがあるという前提だったらそれでいいけれども、要するに業務処理しか考えてないから、そういうことになる。新興国へ行くと、まだ業務がないところから一から立ち上げるので、「世界のベストプラクティスを買いたい。これを買うと何ができるようになるのですか」と。イネーブラーでもあるし、ベストプラクティスを買うという感じです。
提案のどこに重きがかかっているのかがやはり違うと思っています。

そうですね。今の三つのタイプの中でも、今の日本ができていることは、きっと日本でしか必要ないことですよね。

日本はやはり特殊だと思います。100年以上の伝統的な企業がすごく多いですし、雇用も長期雇用なので、業務が属人化してしまう。うちの会社も、ユーザーが人しかいないようなアプリをたくさん作って、その人のわがままをいっぱい聞いています。一般の基準に当てはめるとダメダメな画面の造りとか、あり得ないだろうみたいなものがあるのですが、「いや、今までこうだったから、こうじゃないと困る」みたいなことが多いです。そういうものを外へ持っていってそのまま売れるわけがない。やはり、御用聞き的にやっているだけでは売り物はできていかないですよね。SIer自身が自分の価値をBAしてみることも必要かもしれないと思います。
中国へ行くと日本はITは2番手3番手という見方をされて、もし欧米になければ日本の企業の話を聞きますという感じがあります。でも、東南アジアはそうでもなくて、大規模なシステムを安定稼働させるとか、日本で実績があるものならどんどん持ってきてください、話を聞きますよと。ですから、日本の独特の業務のノウハウの本当の価値のコアの部分が何なのかを厳しく見直して、要らないところはそぎ落としてパッケージングすれば、売れるものは出てくる、そう思ってやっています。それをシステマチックにやるプロセスとかはまだよくわからないので、ヒントはこの（本の）中にあるかなと思っています。
日本のものは大概オーバースペックですよね。ATMとかはあり得ないほど何でもできるではないですか。あそこまでできることは全然求められていませんよね。

そうですね。膨らむ方向で行くものですから、どんどん膨らんでしまいますよね。

アジャイルとは関係ない話でしたね。（笑）

もとはオフショア部会でしたよね。

オフショア部会でした。ですから、興味はあります。

やはり海外のエンジニアに日本のぐちゃぐちゃした業務のシステムを作らせるのは大変です。まずわからないから。わからせるのに何年もかかるし。海外のエンジニアも人間だから、やはり自分で腑に落ちないものを作らせるとパフォーマンスが下がりますよね。「この業務はなぜ一体こうなっているのですか。こうしたほうが効率いいではないですか」「いや、だめだ。もともとそうなっているからそのとおり作ってくれ」と言われると、モチベーションもがたんと下がってしまうし、「日本でしか使えない業務プロセスですよね。その業務を勉強して自分にとって何の意味があるのですか」となってしまうと、人も集まらなくなってくる。そういうのも要因の一つ。
日本のオフショアは、規模的にはたいしたことないですよね。広がらない。日本のプラクティスは世界のベストプラクティスにならないので人もついてこないので、開発リソースを海外に求めることは限界に来ていると思っています。

『ものづくり白書』にそういうデータが出ていました。
逆にするというか、そうするとやはり、グローバル的な手法を日本の人たちが使っていくようにしていなければいけないでしょうね。

本当に（そう）思います。日本の中だけで勝負できた時代はもう終わっているので、やはり世界と競争しないといけないので、外のやり方にも目を向けないといけない。

選択肢としては、限られた日本の中の企業を相手にこれからもずっとビジネスをしていくのか、それともそれ以外の組織も相手にビジネスをやっていくのか、この二つしかありません。
今までは日本の企業だけでビジネスできていたし、競争相手も日本の企業だけだったけれども、日本の企業だけを相手にするという選択をしたときには、でも競争相手は制限できないので海外のたくさんの企業も競争相手になっていく。その中で、限られた日本の企業をとっていくのか、それともグローバルに展開していくのか、どっちがいいかですよね。

アベノミクスが成功すると、また逆戻りになるかもしれませんけれども（笑）。

どうでしょうね（笑）。

ただ、既存のシステムはほとんどの費用が保守に行ってしまっていますから、やはり新陳代謝は必要なのではないでしょうか。

多分、ちょっとずつ少しずつというのは難しいのではないかと思います。ショック療法的ならいいですが。

いずれIBMがメーンフレームの値段をがーんと上げてきたときに、大パニックが起こるのではないかと。（笑）

日本の会社は、業務プロセスが独自のものが多いと思います。それが良いこともあるし悪いこともあります。それぞれの会社で独自のプロセスがあるからこそ国内でいろいろ商売できます。ある会社でしか通用しないとなると海外の企業だと参入しにくくなっていると思います。
逆に、業務プロセスがグローバル標準になってしまえば、調達側からいえばコストは安くなります。どこかの時点でユーザーが、もうグローバルな業務プロセスにしましょうと言うかどうかで、がらっと変わるかもしれないですね。それがきっかけかなと思っています。
業務プロセスにこだわる意味があるのかなと思っています。業務プロセスのちょっとした違いよりも、もう少し上流──そもそもどういうビジネスをやるかというような企画を考えることに注力したほうがいいと思います。

やはり日本の文化としては、様子見して、絶対に先に行かない。

何でも「実績は？」と言われますからね。では、ファーストユーザーはどうだったんたみたいな。（笑）

今は、そこをどこかが崩すのを待っている感じでしょうね。

国内で使っている基幹システムなどの業務システムを世界のあちこちにある支社店と共通化しようとかいったときに、例えばヨーロッパのほうから「こんなものは使えない」とがんがん言われて、では世界で一般的なものに置きかえますみたいな流れが出てきたりしないですか。

最近、ユーザーさんがグローバルのITの合理化を言い始めています。我々が接している中でも、この1年、急にそういう話が増えている気がしています。以前は、「この国にSAPを入れたいが、できる？」とか、（日本と相手国の）特定の2点間の話でしたが、今年に入ってからは、「この地域丸ごと統合して維持管理をアウトソースできるところを探しているけれども、できる？」みたいな話が急に増えたような気がします。
日本企業の情シス部門の傾向としては、海外拠点のITをあまり面倒見できていません。海外オンチで、自分たちは海外なんかできるわけがないと思っているところも多い。その結果、海外拠点はローカルのベンダーを使って自力でIT投資して、最初はエクセルから始まってローカルパッケージを使ったりしてやって、もう二重三重投資の嵐になって、本社から情報がとれないというのはよくある状況です。それで本社側も、トータルで見るとコストも相当かかっているし、そもそもガバナンスがきかないし、拠点間で在庫情報のやりとりとかができないので機会損失も出ているということに気づいて、このままではまずい、やはり合理化しようということが始まっています。

合理化しやすい環境になったのでしょうね。例えばクラウドの利用とか。

そうですね。やはり拠点をばんばん出していくと、クラウドでないと、なかなか。拠点を出してまた何かインストールしてまた作ってというと、全然追いつきませんね。地域ごとにデータセンターがあってクラウド化しているといいのかなという気がしています。

クラウドが普及したことで、企業、組織としてもいろいろな捨てられるものが出てきたのかなと思います。

クラウドに移行した段階で捨てざるを得ないというところですかね。逆に、捨てたくないところはクラウドにも移行しないのかもしれませんが。（笑）

僕の周りでは絶対移行しないでしょうね。（笑）

海外の日系の工場に行くと、10年以上前に導入したAS/400とかが動いていて、RPGで書かれた生産管理システムが動いて、もう誰もいじれなくなってしまっていて、そのまま使っている。（笑）
やはり、時期的に限界に来ている、どっちみち更新時期に来ていると思うので、そのタイミングで全部統合して合理化して、部分的にはクラウドでという形にはなっていくと思います。

トップの人たちも、もともとどこが無駄なコストなのかというのはわかっていて、やっとそういうことができるような環境になってきた、そういうタイミングなのではないかと思います。

一方で、大きな組織からすると、ごそっと変えるとどうなるかわからないから、怖くて変えられない。そうすると、本来なら、アジャイルで、ある部分を変えて、動くのを見せて、これで大丈夫だよねという段階を踏んでいくと、順番にグローバルなシステムに変わっていくのだろうけれども、会社の上のほうがそうでないと。

結局、GOが出ないとできませんからね。

そうです。アジャイルでやるとどうしてもコストがかかるような気がする。よく言われるのが、青天井になるのではないかと。

そういう議論はよくありますよね。

よく言われます。今まで、ウォーターフォールだと、最初にお金が決まっていて、やることが決まっていて、いいか悪いかわからないけれども全部決まっていた。（笑）

どっちがいいのかね（笑）。

どっちがいいのかよくわからない。ゴールが本当にそこでいいのかというのはあるけれども、経営者としては、お金が決まるので安心して進められるところがある。そこを何とかしていかないと。

その考え方ですよね。

ええ。どうやっても変わりませんよね。現場が変えようと思っても、今度は調達のところでひっかかって契約してもらえないというのもある。その辺をどうしていくといいかという知恵が、いまいちない。

そこは、トップに近い人がとくとくと情報を提供して説明をする。やることを先に決めてしまってやったほうがいいのか、それとも本当にやりたいことをやったほうがいいのか。トップの人は本当にやりたいことが何かは明確なのでしょうが、本当にやりたいことは何ですかと聞いたら、恐らく、利益を上げることだとしか言わないと思います。でも、利益を上げることを実現するために本当に何をしたいのか。利益を上げると一口に言っても、長期的なスパンで利益を上げたいのか、短期的にどれぐらい上げたいのか。そういうところをIT側の人も理解してあげると、経営層の人たちがよりわかりやすい説明の仕方で説明してあげられるようになるのでは。

今までのアジャイル開発だと、やはりIT、ソフトウェアではないですか。そこの話を経営者が理解するかというと、それは理解ができない。

そういうのは無理ですね。

使う言葉が違うので。

そうですね。そこはやはりギャップがある。経営者は経営者で、最終的には利益を上げるのですけれども、その手段が幾つかあって、どれを選ぶかはアジャイル的に多分やると思います。不確定要素が上のほうほど高いと思うので、これかな、これかな、というように、アジャイル的にならざるを得ないところはある。その意味では、そこはアジャイル的なはずです。だから、それがつながっていくような形になれば自然につながるのですが、そこがどうもつながっていない気はします。

経営者にとって、ソフトウェアなんて別にどうでもいい。

そうですね。どのように作られているかは興味がないですね。

そういう意味でいうと、今日ご説明いただいたAgile Extensionは、どちらかというとアジャイル開発とビジネスアナリシスのマッピングでしかないですよね。ビジネスアナリシスという経営のためのサポート業務をアジャイルにどう回すかということに体系化していこうみたいな、そういう方向性はあまり感じられませんでしたが、そこはどうなっていますか。

アジャイルのアプローチをソフトウェア開発の中で利用していくためにどう利用していくかという位置づけではありません。例えば、今ちょっとお話が出ましたビジネスニーズを分析したりする一連の活動をアジャイル的に行っていく。

では、アジャイルのソフトウェア開発の手法のキーワードを整理して持ち込んでいるけれども、ターゲットはビジネスアナリシスだということでいいですか。

そうですね。ただ、もともとこれを作った人たちの中にはやはり開発に携わっていた人たちもいます。ですから、ソリューションはソフトウェアだけではないと言っていますが、逆に言うとソフトウェアの場合もあるということで、その場合はソフトウェアを作るためのものであるということもできます。

ビジネスにとっての価値と開発でやることとの関連づけをもっとちゃんとやりましょうということは言えるのかなと思いますけどね。

そうです。恐らく最終的にはソフトウェアになるけれども、それは最初から決めてはいませんと。もとにあるのはやはりビジネス的な要求です。

「各知識エリアへのマッピング」を見ると、アジャイルのプラクティスと言っていても、上流のほうに偏っているように見えます。プラクティスの中でも、ユニットテストとかCIとかペアプロという開発に近い部分と、ここに書いてあるようにペルソナとかユーザーストーリーとかストーリーマッピングという分析に近い部分とがあります。これを見ると後者の分析に近いものが結構マッピングされているので、そういう意味でもやはりBAのほうなのかなという感じを個人的には受けています。

その開発のほうもアジャイルのやり方で開発をするようになったら、どのタイミングで結果を得られるかは、ビジネスアナリシスの活動の中でも必要な情報ですよね。

ただ、アジャイルの開発のほうだと、エグゼキュータブルなアーキテクチャで本当にその価値が提供され得るのかどうかを検証するのが一つ肝になっていますけれども、ビジネスアナリシスでアジャイルで、そのアナリシスが妥当であるということ、ちゃんとビジネス価値を生み出すということを検証するには、アジャイル開発をつながないとだめなのか。それとも、何か違う方法も考えているのですか。

結局、物ができ上がって、そのでき上がったものがニーズを満たしているかどうかという確認をしなければいけなくなるので、そこはつながってないといけませんよね。

ただ、経営者は、つながって物が出るまで待てない。自分のビジネス構想はどこまで妥当性があるのかと、感触がある程度欲しいみたいなことがあると思います。

でき上がる前にも妥当性の確認をするというタスクはあります。それは『BABOK®2.0ガイド』に書いてあります。

ビジネスモデルという話があって、もう少し粘土みたいにいじくれるビジネスモデルが欲しいなというのがありますけれども。赤坂さん、その辺はどうですか。

（セミナーの）最後に紹介いただいたビジネスモデルキャンバスはまさにそうだと思います。いろいろな立場の人が一緒に1枚のキャンバスの中でどうやってもうけをつなげるかという話ができる。だから、BAのほうでどういうビジネスをやっていくかという仮説を立てて、それをITのほうが早く作って検証してもらうというか、フィードバックを早く回すような仕組みを作っていけるといいと思っています。
ITと経営をつなぐのにモデリングというお話を最後にされていて、すごくいいなと思いました。果たしてそのモデリングがUMLなのかどうか僕はわかりませんけれども、例えばビジネスモデルキャンバスはエンジニアにも簡単にわかりますし、経営の方も当然わかりますし、共通言語としてこういう図を使って距離を縮めるのは非常にいいと思います。

距離を縮めるということではすごくいいと思っています。ただ、さっき羽生田さんがおっしゃっていたような、実際に物を作るところの活動まで行っていてそこでのフィードバックを反映させていくときに、何か難しい問題が発生するような気が今しています。物を作る段階まで行ったときに、果たしてそのニーズをまた組みかえることができるような手順になっているかとか、成果物の状態になっているかとか。そこまではまだ書いてなかったような気がします。

どっち側の話としてですか。

Agile Extensionのほうです。

ああ、Extensionですね。

その辺をうまいことやれよというのがBDDというところにおさまっていると僕は読みました。BDDをやって、ビヘービアレベルで上のほうで検証しておいてうまいことやってねと言っているのかなと。

その辺のテクニックとかは、Agile Extensionだけだと情報が足りない気がします。「このテクニックを使うと、全体像は見えるけれども、例えば小さいパーツで見たときにそれぞれの詳細がわからない」とか、また逆の手法が書いてあったりとか、各テクニックの長所、短所は書いてあります。でも、それをもっと実際に使いこなすまでのテクニックはAgile Extensionの中にはない。多分それは個別に理解していく必要があるのでしょうね。このタイミングでこういうものを使ったほうがいいよというテクニックは載っていますけれども、実際にやるのにはすごく問題が出てきそうに思います。

個人的に思うのは、先ほど顧客とユーザーという話がありましたけれども、誰にどんな価値を提供するのかという話を、経営層はもちろんいつも気にしているでしょうけれども、開発側もちゃんと意識することが大事なのかなと。その間のつなぎは、ビジョンを共有しているところに意味があるかと思います。従来は、要求として落ちてきた機能を実現することだけ考えていたから、そごが発生していました。川添さんがさっきおっしゃっていたように何か問題が出るかもしれませんけれども、キャンバスを使ってやりたいことを共有することによって解決できるのではないかなと、楽観的に思っています。

そうですね。

全然違うことを考えていることは恐らくいっぱいあると思いますけれども、共通する何かがあるかどうかが大きいのかなと。

『BABOK®2.0ガイド』も、なぜそれをやるのか、それを明確にするものだということを昔からずっと言っています。いろいろな問題が出るでしょうけれども、それ（共有したビジョン）があることによって、それを目指して行けますよねと。確かにそれはありますよね。

あと若干不満なのは、BAといったときに、その業界とか業務のドメインモデルみたいなものとビジネスアナリシスの関係です。ビジネスアナリシストが分析した結果と、その業界や業種のドメインモデルとかモデルのパターンみたいなものが本当はもっと密接につながるのではないかと思うのですが、今はまだ、特定業種・業界ごとのビジネスアナリストの活動みたいなことになってないから、そこまで踏み込めていません。そこまで踏み込まないと、あまり面白くない気がします。

そうですね。まだまだですよね。

最近のアジャイル開発は、アジャイルのテキストを見てもスクラムのことしかわからなくて、そこで実際にどんなモデルなりアーキテクチャが出てくるのかみたいなことは一切出てこない。それと同じ状態なのかなみたいな感じがします。だから、そこで赤坂さんはピクト図解にこだわっているのかなと思ったのですが。

はい。こだわっているわけではないですけれども。（笑）
こちらのモデリング部会でもやっていると思いますけれども、自分たちが作ろうとしている対象の大事なところを、クラス図でシンプルにいかにモデル化するか、それが自分の中でずっとモチベーションになっていました。ピクト図解は、対象が全然違いますけれども、販売する人と顧客がどんな商品を幾らで取引するかという等価交換だけに絞ってビジネスというものをモデル化したものです。ピクト図解と出会って、ビジネス構造とか、どうやってお金をもうけるかという収益構造が瞬時にわかってしまうところに衝撃を受けまして、はまってしまったわけです。UMLでも同じようにソフトウェアというものをぱーんとわかるように見せたいというのがもともとありまして、それでビジネスモデルに関心を持った次第です。

ピクト図解とビジネスモデルキャンバスとの関係はどのように考えていますか。

誰にどんな価値を提供するか、そのためにどんな活動をしなければいけないか、誰と協力関係にあるか、幾らもらって幾らかかるかという、割と全体的なものを九つの枠で俯瞰できるものがビジネスモデルキャンバスです。ピクト図解は、その中で、自社とお客さんあるいはパートナーになる人と、どういう物の価値をやりとりするかという、収益に関係します。収益とコスト、誰と何をやりとりするかだけに絞って見せたものになりますので、キャンバスほど全体をあらわしてないけれども、交換だけに絞るとものすごくビジュアルに関係がわかるというものです。

将来的には『BABOK®2.0ガイド』の中にもビジネスモデルキャンパスが出てくるのではないかと思っています。

個人的には、キャンバスで皆さんとアイデアをまず出して、形が少しできたところでピクト図解に描いてみると、全体のプレーヤーの関係がわかると思います。

九つの領域を最終的にはもっと深く分析していかなければいけないので、そのときにはお金の流れとかはそういう手法を使うし、そうではないところ、（例えば）ターゲット分析はターゲット分析でもっと違う手法を使って、どんどん掘り下げていく。そのときに使う手法の一つという、きっとそういう関係ですよね。

はい、そうです。ですから、いわゆるピクト図だけで何かできるというほどのものではないと思います。共通の認識を得るというか。

狙っているところはほぼ同じで、絞り込んで、あるビューで見たものがピクト図解みたいなイメージですが。

ピクト図解も、UMLの分析モデル、設計モデルのようにいろいろな視点で見ることによって、プレーヤーも、粗いレベルで自社とお客さんだけ出てくる場合もあるでしょうし、流通経路で仕入れさんとか途中の卸とかも出てくることもありますし。

狙っているパートナーさんとかチャネルとかを全部ビジネスモデルキャンバスで描こうと思えば描ける。だけど、それだとかなりぐちゃぐちゃになってしまうから、ポイントだけ絞って検証に使うみたいなイメージでいいですかね。

考案者の板橋（悟）さんは、ぐちゃぐちゃなものを一回描かないとだめだと言っています。オブジェクト図とクラス図の関係と多分同じだと思いますけれども、具体的に全部のプレーヤーを出した上で、抽象化して考える。本とかに描いてあるのはもう抽象化した結果でしかないので、あれだけでは検討としては足りない。あと、わかった気になってしまうという指摘はそのとおりだという話はされていました。

あれを描いたら終わりではないですね。

そうですね。あれは出発点だということです。

UMLは今は2.0ですか。

2.5です。

大分おくれていますね（笑）。

何が変わったのかわからない。

そう（笑）。

ダイヤグラムが何か増えたりしたのですか。

いや、増えていません。

使う人にとっては変わっていません。

似たモデルを整理してきれいにしたと言われていますけれども、どこがどうきれいになったか理解できる人は、某F社と某N社とか、多分数名しかいない。

2.4で1000ページを超えて、本当に正しいかどうかわからなくなってしまって、1000ページ全部読んだ人は多分誰もいないと思います。それで、2.5はSimplifiedとついています。だから、簡単にしようというのが2.5です。Simplifiedだから、増えたのではないですよ。

実際はあまりシンプルになっていないようです。

でも、目的はSimplified。

そこまで行けなかった。3.0ぐらいになったら直るのかもしれません。（笑）

エンタープライズアーキテクチャと『BABOK®2.0ガイド』の関係は何かあるのですか。

参考文献にTOGAFとザックマンフレームワークが出ています。

ちなみに、『Agile Extension』の日本語版のリリース予定は。

買いますか。（笑）