そこはやはりギャップがある。経営者は経営者で、最終的には利益を上げるのですけれども、その手段が幾つかあって、どれを選ぶかはアジャイル的に多分やると思います。不確定要素が上のほうほど高いと思うので、これかな、これかな、というように、アジャイル的にならざるを得ないところはある。その意味では、そこはアジャイル的なはずです。それがつながっていくような形になれば自然につながるのですが、そこがどうもつながっていない気はします。経営者にとって、ソフトウェアなんて別にどうでもいい。どのように作られているかは興味がないですね。Extensionは、どちらかというとアジャイル開発とビジネスアナリシスのマッピングでしかないですよね。ビジネスアナリシスという経営のためのサポート業務をアジャイルにどう回すかということに体系化していこうみたいな、そういう方向性はあまり感じられませんでしたが、そこはどうなっていますか。川添アジャイルのアプローチをソフトウェア開発の中で利用していくためにどう利用していくかという位置づけではありません。今ちょっとお話が出ましたビジネスニーズを分析したりする一連の活動をアジャイル的に行っていく。羽生田では、アジャイルのソフトウェア開発の手法のキーワードを整理して持ち込んでいるけれども、ターゲットはビジネスアナリシスだということでいいですか。これを作った人たちの中にはやはり開発に携わっていた人たちもいます。ソリューションはソフトウェアだけではないと言っていますが、逆に言うとソフトウェアの場合もあるということで、その場合はソフトウェアを作るためのものであるということもできます。細谷ビジネスにとっての価値と開発でやることとの関連づけをもっとちゃんとやりましょうということは言えるのかなと思いますけどね。最終的にはソフトウェアになるけれども、それは最初から決めてはいませんと。もとにあるのはやはりビジネス的な要求です。「各知識エリアへのマッピング」を見ると、アジャイルのプラクティスと言っていても、上流のほうに偏っているように見えます。プラクティスの中でも、ユニットテストとかCIとかペアプロという開発に近い部分と、ここに書いてあるようにペルソナとかユーザーストーリーとかストーリーマッピングという分析に近い部分とがあります。これを見ると後者の分析に近いものが結構マッピングされているので、そういう意味でもやはりBAのほうなのかなという感じを個人的には受けています。川添その開発のほうもアジャイルのやり方で開発をするようになったら、どのタイミングで結果を得られるかは、ビジネスアナリシスの活動の中でも必要な情報ですよね。羽生田ただ、アジャイルの開発のほうだと、エグゼキュータブルなアーキテクチャで本当にその価値が提供され得るのかどうかを検証するのが一つ肝になっていますけれども、ビジネスアナリシスでアジャイルで、そのアナリシスが妥当であるということ、ちゃんとビジネス価値を生み出すということを検証するには、アジャイル開発をつながないとだめなのか。それとも、何か違う方法も考えているのですか。結局、物ができ上がって、そのでき上がったものがニーズを満たしているかどうかという確認をしなければいけなくなるので、そこはつながってないといけませんよね。羽生田ただ、経営者は、つながって物が出るまで待てない。自分のビジネス構想はどこまで妥当性があるのかと、感触がある程度欲しいみたいなことがあると思います。川添でき上がる前にも妥当性の確認をするというタスクはあります。それは『BABOK®2.0ガイド』に書いてあります。羽生田ビジネスモデルという話があって、もう少し粘土みたいにいじくれるビジネスモデルが欲しいなというのがありますけれども。赤坂さん、その辺はどうですか。赤坂(セミナーの)最後に紹介いただいたビジネスモデルキャンバスはまさにそうだと思います。いろいろな立場の人が一緒に1枚のキャンバスの中でどうやってもうけをつなげるかという話ができる。BAのほうでどういうビジネスをやっていくかという仮説を立てて、それをITのほうが早く作って検証してもらうというか、フィードバックを早く回すような仕組みを作っていけるといいと思っています。ITと経営をつなぐのにモデリングというお話を最後にされていて、すごくいいなと思いました。そのモデリングがUMLなのかどうか僕はわかりませんけれども、例えばビジネスモデルキャンバスはエンジニアにも簡単にわかりますし、経営の方も当然わかりますし、共通言語としてこういう図を使って距離を縮めるのは非常にいいと思います。距離を縮めるということではすごくいいと思っています。さっき羽生田さんがおっしゃっていたような、実際に物を作るところの活動まで行っていてそこでのフィードバックを反映させていくときに、何か難しい問題が発生するような気が今しています。物を作る段階まで行ったときに、果たしてそのニーズをまた組みかえることができるような手順になっているかとか、成果物の状態になっているかとか。そこまではまだ書いてなかったような気がします。羽生田どっち側の話としてですか。Extensionのほうです。羽生田ああ、Extensionですね。古川その辺をうまいことやれよというのがBDDというところにおさまっていると僕は読みました。BDDをやって、ビヘービアレベルで上のほうで検証しておいてうまいことやってねと言っているのかなと。Extensionだけだと情報が足りない気がします。「このテクニックを使うと、全体像は見えるけれども、例えば小さいパーツで見たときにそれぞれの詳細がわからない」とか、また逆の手法が書いてあったりとか、各テクニックの長所、短所は書いてあります。Extensionの中にはない。それは個別に理解していく必要があるのでしょうね。このタイミングでこういうものを使ったほうがいいよというテクニックは載っていますけれども、実際にやるのにはすごく問題が出てきそうに思います。個人的に思うのは、先ほど顧客とユーザーという話がありましたけれども、誰にどんな価値を提供するのかという話を、経営層はもちろんいつも気にしているでしょうけれども、開発側もちゃんと意識することが大事なのかなと。その間のつなぎは、ビジョンを共有しているところに意味があるかと思います。従来は、要求として落ちてきた機能を実現することだけ考えていたから、そごが発生していました。川添さんがさっきおっしゃっていたように何か問題が出るかもしれませんけれども、キャンバスを使ってやりたいことを共有することによって解決できるのではないかなと、楽観的に思っています。違うことを考えていることは恐らくいっぱいあると思いますけれども、共通する何かがあるかどうかが大きいのかなと。『BABOK®2.0ガイド』も、なぜそれをやるのか、それを明確にするものだということを昔からずっと言っています。いろいろな問題が出るでしょうけれども、それ(共有したビジョン)があることによって、それを目指して行けますよねと。確かにそれはありますよね。羽生田あと若干不満なのは、BAといったときに、その業界とか業務のドメインモデルみたいなものとビジネスアナリシスの関係です。ビジネスアナリシストが分析した結果と、その業界や業種のドメインモデルとかモデルのパターンみたいなものが本当はもっと密接につながるのではないかと思うのですが、今はまだ、特定業種・業界ごとのビジネスアナリストの活動みたいなことになってないから、そこまで踏み込めていません。そこまで踏み込まないと、あまり面白くない気がします。