それでは、ワークショップを始めます。最初にメンバーから簡単に自己紹介をしていただき、その後、今日のセミナーの内容で深掘りしたいところを中心に議論したいと思います。自己紹介は、現在の会社や過去の経歴などを、アジャイルやモデリングに関することも入れてお願いします。

小倉と申します。現在はネットイヤーグループという会社でソフトウェアエンジニアリングをやらせていただいています。その前は情報システムの会社、いわゆるSIerのような会社で仕事をしていました。アジャイルとモデリングに関しては、今の会社ではアジャイルっぽいやり方で仕事をしていますが、モデリングのスキルがあって非常に助かっています。今、アジャイルをしている人たちの間ではモデリングがあまり浸透していないような気がしますので、もう少し強く引きつけができればいいのではないかと思っています。よろしくお願いします。

オージス総研の竹政と申します。よろしくお願いします。もともとはモデリングをずっとやっていました。アジャイルは、お話でもありましたが日本ではなかなか普及していません。理由としては、欧米のものでは日本特有の部分が考慮されていないのではないかと思っています。日本特有の部分を何か提供することで、日本にも広がるのではないかと思い、このアジャイル開発部会でも活動しています。

河合です。本橋さんはパターンランゲージのコミュニティではよく存じ上げております。今は開発の現場を離れて久しいのですが、10年以上前、ちょうどXPが出た1999年ごろからRUPとアジャイルの関係に興味があり、比較していたことがあります。RUPもバージョンが上がっていき、XPもバージョンが上がっていき、それが非常に影響し合っているわけです。RUPがあって、XPがバージョンアップする。そのXPを見て、RUPも完全に変えていっている。その変わったRUPを見て、またXPが変わっていく。それを追っていくとものすごく面白いわけです。

そもそもXPが出たときに、パターンランゲージというものをケント・ベックは表に出さなかったのですが、XPは明らかにパターンランゲージなのに、12のプラクティスにパターンという言葉を出さなかったわけです。RUPも最初はパターンランゲージを言っていなかったのに、パターンランゲージ風になってきています。

今回、本橋さんが正面からパターンランゲージをされて、パターンランゲージが日の目を見たということで、非常に興味があります。

オージス総研の細谷と申します。思い起こせば、昔、あるメーカーさんに誘われて、「うちに来たら、オブジェクト指向をやらせてあげるよ」という口車に乗って入りました。（笑）その前、GoFの1人であるラルフ・ジョンソン先生と同じ大学にいましたので、入社する前にデザインパターンなどを勉強しておいてくれと言われて、ラルフ・ジョンソン教授のパターンの授業などを受けました。デザインパターンを見て初めて、オブジェクト指向はこのように使えばいいのかと、非常にメークセンスしたという体験を今でも鮮明に覚えています。

その後、オフショア開発やグローバルビジネスの担当のほうに変わってしまいましたが、最近、たまたまメーカー時代の人たちと会って、「最近の人たちはアジャイルとか言って、いきなりコーディングをし始めているけれども、オブジェクト指向の原則やデザインパターンはどこに行っちゃったんだ」という議論をしました。そういうものを見直して、どういう関係にあるのか、どういう場合にいきなりコーディングというアプローチがうまくいくのかということをはっきりさせて、ばらばらになっていたものをつなぎ合わせれば、皆さんにとってわかりやすいのではないかと思い始めています。

豆蔵の羽生田です。もともとは富士ゼロックス系の会社にいて、その後、オージス総研さんに行って、そこでモデリングを中心とした教育とコンサルティングというビジネスにかかわらせていただきました。その後、豆蔵を立ち上げ、またモデリング、オブジェクト指向を中心としたコンサルティング・教育をずっとやってきました。

その中でパターンというものも、ワークショップなどの形でビジネスとしてさせていただいている部分がありますが、やはりモデリングとパターン、モデリングとアジャイルに関しては、それほど具体的に折り合いをつけて方法論として定式化されたものは今のところあまりありません。今日、紹介された中でも、システムメタファというところが若干かぶるかなという感じですが、それもそれほど表立ってモデリングというような言い方をしているわけではありません。このUMTPの部会としてはモデリングというものが一つのテーマになっていて、私はモデリングが非常に好きなので、何とか今のアジャイル開発のスタイルとモデリングをつなげていきたいと思っています。

その一つのキーワード、ブリッジになるのは、やはりパターンランゲージではないかという気がしています。それをもう少し一般の人たちが怖がらないようにといいますか、恐れないような形で少しでも浸透させるためにはどういうことをする必要があるのかということに非常に興味があります。よろしくお願いします。

名古屋の中菱エンジニアリングという会社から来ました古川と申します。現在、仕事的にはERPパッケージの導入のカウンターパートなどをやっており、特に開発に直接携わっているわけではないのですが、会社としては組み込みのシステムプログラムを作ったり、試験装置のプログラムを作ったりしています。同期がプロジェクトマネジャーなどをしていますので、そこに対して「こういうものがあるから、やれ」と口出しをしているという形になっています。

モデリングとアジャイルについては、ちょっと珍しいパターンですが、もともとは数年前にSysMLから入り、そこでモデリングと初めて出会って、ああ、いいなと。

それまではUMLは全く使っていなかったのですか。

全く使っていませんでした。黒船のアメちゃんからの使えという指示によって、SysMLを使うことになりました。その後、ウォーターフォールをがちがちやっていたのですが、なかなかうまくいかなくて、アジャイルに手を出したのですが失敗し、やはり体系的にちゃんと勉強しなければいけないということで勉強し始めました。そして、L3を取ったことをきっかけに、ここに来させていただけるようになりました。よろしくお願いします。

アジャイル開発部会主査の中原と申します。私は日立グループでソフトウェア開発、システム開発を経験し、2年前に定年退職、現在は大学や専門学校の非常勤講師をしています。システム開発をやっていた時代に、オフショア開発でちょうどUMLを適用し始めたころ、オフショア開発の成功率を上げたいということでUMTPオフショア開発部会に入ったのがきっかけです。今はその延長で、オフショア開発部会がアジャイル開発部会に変わった関係で主査を引き継いでいるという状況です。

私は、アジャイル開発の経験はありません。退職する前、社内では皆さんアジャイル開発に興味がありましたが、やろうとは思っていても、本を読んだだけではできません。実際のシステム開発はウォーターフォールが多いですが、そこで使えるようなアジャイル開発の方法や、UMLをうまく使えるようなガイドラインを作りたいと思っています。

改めまして、本橋と申します。私自身は前職が外資系の保険会社で、システム開発などもしていましたが、完全なインハウスで、非常にクイックに、いわゆるアジャイルに近いと言っては怒られるでしょうが、毎日リリースしていくということを体験しました。

逆にアジャイルということでは、XPなどで2週間のイテレーションを回すことを聞いたときに、イテレーションって2週間もあるんだというのが第一印象でした。（笑）もちろん3カ月などのプロジェクトもありますが、2週間というと役員承認をとらなければいけない規模感で進んでいましたので、世の中にはこういう大きなものが多いんだな。ただ、大きなプロジェクトがだんだん増えてきましたので、やはり方法論はちゃんとしなければいけないということでやっていました。

また、モデリングについては、今はIBMになってしまいましたが、ローズ（Rational ROSE）というツールを買ったり、デザインパターンの本を真っ黒になるまで読んだりはしました。実際にインハウスの開発業務においてUMLでモデリングするということはほとんどありませんでした。外注した開発の納品物としてのUMLは読みますが、実際にモデリングして何かを作るということはほとんどありませんでした。

そのかわりというわけではありませんが、BPMN的なもの、流れを書いていくようなものは社内でよく（やっていました）。先ほど申し上げたように、システム開発（の方法論通りに）をきちんとやるということが目的ではありませんので、自分たちに使いやすいようにBPMN的なものを書いて業務プロセスを明確にするということはよくやっていました。よろしくお願いいたします。

それでは、今日のセミナーで掘り下げて議論したいところがありましたら、お願いします。

ではまず最初に、アジャイル開発ではなくアジャイル型開発だというところが非常に印象に残っているのですが、では、アジャイル型開発とは何だろうと思いました。なぜかといいますと、その下に非ウォーターフォール型とあります。ウォーターフォール型ではないものをアジャイル型開発と言っているのではないかと何となく思ったのですが。

おっしゃるとおりです。

しかも、非ウォーターフォール型のヒアリングは大規模プロジェクト（が対象）ですよね。

そうです。中大規模です。

アジャイル型開発はもともと短期・小規模開発だと思っていたのですが、今日のプレゼンを聞いていますと、小規模、中規模、大規模、全てアジャイル型開発の調査対象に入っています。つまり、今まで短期・小規模だと思っていたのですが、本橋さんがおっしゃっているアジャイル型は大規模も入ると。調査対象に入っていますから。

先ほどこの辺に座っておられた方から質問があったとき、何をもってアジャイルとするのかという議論は保留（させていただきました）。アジャイルとは何かということを友達や同僚などとはよく話します。アジャイルマニフェストの抽象度が高い理由は、その当時いろいろな方法論があり、結局、あれぐらいの抽象度のものでしかまとめられなかったのではないかと言う人がいました。要は、アジャイルマニフェストのマインド的なものをもってアジャイルとすると解釈している人たちがいるわけです。なるほど、アジャイルという言葉の定義は難しいなということがまず一つです。マインドを持っていればアジャイルなのか。では、マインドはどうやるのかというのは不明なところがあります。

一つは形容詞としての、小文字のアジャイル（
agile）ということです。今までの中大規模に対してであっても、少しでも「動くソフトウェア」に価値を置こうとか、比較対象として、形容詞として、これはアジャイルだと。何らかの想定しているものがあっての比較ということであって、単体でこれがアジャイルかどうかということは、本当に宗教戦争が始まり、終わらない議論（のよう）になってしまうだけではないかと思っています。

それで、今回見せていただいたプラクティス・リファレンスガイドの資料には45ぐらいのプラクティスがあり、そこには別に短期・小規模でなく、大規模でも使えるものがたくさんあるわけです。アジャイルという名前を使うと、みんな短期・小規模だと思ってしまいますので、もう少し違う名前がつけられないでしょうか。要するに、開発プロジェクトで使える便利で有意義なプラクティスが45個ある。それは大規模だろうが何だろうが関係ないので、ネーミングを変えて、例えばスマートプロセスやスマートプラクティスなどにすれば、アジャイルという言葉に縛りつけられなくなるのではないか。それが非常に賢い方法だと思うわけです。

プロジェクト全体が短期ではなく、一つ一つの作業といいますか、アクティビティといいますか、その一つ一つを賢くやっていこう、素早くやっていこうというものだと捉えればアジャイルでもいいのですが、今まで言っているアジャイルではちょっと縛られてしまうと思います。

先ほどの小文字の形容詞のアジャイルに関してのブログでは、大文字で始まるアジャイル（Agile）というものがあって、それはスクラムやXPを示しています。実際に今回の適用事例では、スクラムをやっていますと言っても、実際はウォーターフォールの大規模で、単にイテレーションで切っている、スプリントで切っているというだけのものも含まれているわけです。そういう意味では、ネーミングが非常に大切だというご意見には同感ですが、では何と言えばいいのか。スマートプロセスと言うと、それはそれでまた難しい問題を生むのではないかという気がします。

また、私自身は参加していないのでわからないのですが、IPAにアジャイルに関するワーキンググループがありました。今は解散してしまったのですが、そこで非ウォーターフォールというものがあったわけです。そこで普通にアジャイルとかRUP、あるいは軽量などとは言わずに、非ウォーターフォールと言った経緯があったのではないかと想定しています。その辺は私のほうではわからないです。

経緯は、その時点ではアジャイルという言葉が大手
SIベンダーさんなどに刺激が強過ぎるので、IPAさんが避けたいと。でも、今からウォーターフォールではまずいという気持ちを込めて、非ウォーターフォールという名前になったと聞いています。

名前づけについてはおっしゃるとおりですが、代替案がなく、申しわけないということです。

IPAで検討してください。（笑）

そうですね。

IPAの報告書でも、欧米では割合と大規模なアジャイルに移行しつつあるという記述があったと思います。欧米での大規模開発への移行は、もう普通にできつつあるような状況なのでしょうか。それとも、欧米でもアジャイルはまだ中小規模で、大規模なものにチャレンジしているというぐらいの段階でしょうか。

実はIPAのほうでも2012年の6月に、海外のアジャイル事例の調査というものが上がっています。まずそれを読んでいただくのが一番だというのが正直な回答になるかと思います。

日本で中大規模が増えたということについては、イエスということになっています。それはなぜかといいますと、2009年にIPAが同じようにアジャイル、非ウォーターフォール型開発の調査をしていますが、そのときには中大規模への適用事例は0件でした。それが2012年にはレポートを上げられる程度の事例がありましたので、中大規模のものが増えてはきているということが一つあります。

もう一つは、アジャイルを中大規模に適用することが適切なのかどうかという議論もまた別にあるかと思います。

本橋さん自身は、それについてどのような思いですか。

私個人としては、これはアジャイル、これはスクラム、これはXPということにこだわる必要はないというスタンスです。要するに、ウォーターフォールでも非常にいい状況がたくさんありますし、ピュアスクラムでもいい状態がありますし、TOCでもいい状態があります。状況に応じて適切なツールというか考え方を取り入れて、一番よい（ものを選択していく）。「よい」というのは抽象的な言い方かもしれませんが、状況によってよいものを選択していける。そのためのパターンランゲージという器、パターンという器が非常に重要ではないかというスタンスを持っています。

ですから、先ほどRUPという話もありましたが、RUPのプラクティスでもいいところはたくさん使うべきだと思いますし、ウォーターフォールとスクラムをミックスさせてうまくやっているところもあります。アジャイル原理主義者といいますか、アジャイルをやりたいという人には怒られてしまうのですが、私は、何でも適切なものを適切なときに使えればいいのではないかと思っています。

それはパターン化するといいますか、こういうときにはこのパターンというようなものがある程度あったほうがいいのでしょうか。

そうですね。あとは、（すでにある）慣習というものもありますよね。この会社ではこういうマネジメント手法が使われているということももちろんありますので、それも含めて最適なものをどのようにやっていけばいいのかと。きれいごとのように見えて、実際にやってみると、「うーん、どうしよう」と悩むところではありますが、適切なものを求めていくということをやっていきたいと思っています。

会社の慣習というより、組織や人材が本当にアジャイルに適しているかどうか。今までウォーターフォール型でやっている人や組織では、そこからいきなり移行するのはちょっと難しいという意味合いでしょうか。

そう思います。小さいパイロット的なプロジェクトでアジャイルをやってみて、そこで失敗をたくさんしてみて、成功したものを横展開していくというのが多くの勝ちパターンではないかと思っています。いきなり全社展開している会社も実際にあるにはありますが、どうしても反発が起こりやすいので、そこで苦しんでいる事例と読みました。

最初はスモールスタートといいますか、一部の部署でやって、そこで人材も育成し、それから全社展開をするというのが一般的ですか。

よく聞きます。成功した人をシャッフルするといいますか、人材のローテーションなども含めてどんどんしていくということが多くあります。スクラムマスターという役割と……。

もう一つは、スクラムの場合、スクラムの認定制度が多く開催されていた時期がありましたので、その認定制度、あるいはトレーニングやブートキャンプなどのイベントに大量に人を派遣して取得させ、認定者がキャズムを超えるといいますか、ある一定の数を超えてやっているという事例も幾つかあります。その事例は、認定を取るまではなかなかうまくいかなかったが、みんなで取るようになってからは非常にうまくいくようになったという事例がありました。

それは、会社としてアジャイルなどに取り組もうとして認定制度に送り込むということですか。

そうです。

それまでは会社としてやろうとしても何をやっていいのかわからなかったけれども、とりあえず認定制度がきっかけになるという面が非常によかったということでしょうか。

はい。

それから、先ほど講演の中で、契約などはそれほどではないですが、規模の違いがプラクティスに非常に影響があるというお話がありました。その辺をもう少し詳しく教えていただけますでしょうか。

プロジェクターをお借りしてもよろしいですか。（以下、プロジェクター使用）

この「適用プラクティス」は、実際にアンケートをとって、規模別、システム種別、手法別で分析したといいますか、簡単な棒グラフにしたものです。システム種別的には、B2Cサービスではインテグレーション専用マシンや継続的インテグレーション、要するに、どんどんリリースしていくということが社内システムに比べて多いということももちろん出ています。手法別でも、スプリントレビューやファシリテータ、プロダクトバックログというプログラミング、ペアプロの適用率が高くなっているということが上がっています。ただ、そもそもXPをやっているかということも聞いていますので、これ自体にはあまり意味がありません。

それから、この棒グラフの変化度合いが、規模別では明確に「人材のローテーション」などが違っているということが見てとれると思います。小規模と中大規模で見ていただきますと、「人材のローテーション」や「ニコニコカレンダー」などは規模によって幅が出てきています。分散と言えばいいでしょうか、契約の場合、「インセプションデッキ」というものだけが違っていますが、（そのほかは）あまり違いはないという感じです。この辺も大体同じです。分析した結果、このような傾向が見えたということです。

それを引用したものが、「まとめ（2）」です。大もとの資料はこちらになるのですが、プロジェクト特性の中でも、特に規模の違いの影響が大きい。また、契約やシステム種別はあまりプラクティスに影響を与えていないということがわかったということです。こういうまとめがありましたので、そちらを適用しました。ただ、もう少し正しく検証する必要があるかなと思いながら見ているんですけれども（笑）、レポートでは一応こうなっています。

図1 IPA発行のアジャイル型開発におけるプラクティス活用事例調査
概要調査報告書 15ページ

図2 IPA発行のアジャイル型開発におけるプラクティス活用事例調査
概要調査報告書 26ページ

受託だろうが、自社開発だろうが、物を作るということに関しては同じだから、その辺の違いは出ないのではないかということでしょうか。

そういうことだと思っています。これは日本特有ではないかと。これは雑談に近いもので、正しい考察ではないですが、契約というものがそれほど重要視されていないのではないかと思うようなところがあります。契約と運用のマッチングは、課題になってくるのではないでしょうか。

契約で縛られるのはあくまでもスコープであって、やり方までは契約では縛っていないということでしょうか。

運用ではということですね。委託契約であれば、本当は「○○と○○を完成させてください」ということにならなければいけませんが、アジャイルの場合はそれが決められないわけです。ですから、一番適していると言われているのは、これはまだたくさん議論がありますが、とりあえず準委任契約であれば合うだろうということになっています。

準委任でも、クライアントがワーカーに直接指示したら法令違反になってしまうなど、真面目に言い出すと結構いろいろとあります。契約形態については、請負かどうかという話を現場でもよくしますが、結局、やっている作業自体は同じだという矛盾を毎回感じています。民法上は準委任と請負は全く違う仕事を想定していて、請負とは家を造るとか、大きな物件を完成させて引き渡すというプロセスであり、委任契約は行政書士などで、準委任になると事務処理ということで、全く違う世界なのに、システム開発の世界では一緒くたになってしまっているのは不思議だなと。法律がついていっていないようなところもあると思います。

それから、今の議論を聞いていて、ウォーターフォールやRUPなどはプロセスモデルですが、アジャイルはプラクティス集のようなもので、プロセスモデルとはちょっと（違うのではないか）。よく言えば直交概念で、それを直接比較するから混乱しているところもあるのではないかと思いました。ウォーターフォールなのに、アジャイルのプラクティスを使って結構うまくいっているというシチュエーションもあり得るとすれば、もしかするとプロセスモデルの話とプラクティスの話は必ずしも対比されるものではなく、組み合わせもできるのではないかと思います。そこもまだまだすっきりしておらず、みんな、ウォーターフォールに行くか、アジャイルに行くかという二者択一になっていますが、本当はそうではなく、組み合わせられるのかもしれないですよね。

そうですね。プラクティスとしてプロセスモデルが記述されている……。何をもってプロセスモデルと言うかということはありますが、（スクラムやXPにおいて）イテレーションを回したり、日時を回したりするようなプロセスっぽいものを規定しているプラクティスもあるわけです。微妙なところはあるのですが、そういう意味では議論といいますか、組み合わせ方がたくさんあるのだろうということについては同感です。

記述のスタイルがパターンランゲージ的に、全体的にほわっと表現しているのか、あるいはもう少し構造化されて、まずプロジェクトがあって、それに対してフェーズがあったり、イテレーションがあったりするというように、ソフトウェア工学的に記述しているかの違いがかなりあると思います。ですからスタイルの違いであって、0、1の二者択一というものではないですよね。

普通の建築は、基礎工事の期間があり、基礎ができたら今度は内装とか、電気とか配線とか、ちゃんとフェーズが分かれていますが、クリストファー・アレグザンダーの言っている通りにやると、その場で風景を見ながら、ここが玄関だとかなんとか、一歩一歩、特にプロセスを決めずにやっていくわけです。そういう意味では、もしかするとウォーターフォール的な世界とアジャイル的な世界が建築の世界にもあって、一方がアレグザンダーの言っているようなパターンランゲージの世界の建築で、もう一方が土建屋的な建築業という世界、予定どおり、計画どおりに全てがきちんと進むという手法が確立されている世界で、でも、でき上がるものはみんな同じと。そういう流儀の違いはあるのかもしれませんね。

もうお話ししたかもしれませんが、いわゆるウォーターフォールでも、フェーズを分けてとか、アジャイルっぽいことを現場ではやっているなと感じています。先ほどのウォーターフォールと組み合わせているというところは、うまく使い分けてやっています。今後はハイブリッドといいますか、自分の状況に合わせて、プラクティス自身も、最初はまねをするにしても、自分たちに合ったプラクティスを作っていくというほうにシフトしていくのではないかと思っています。

プラクティス、あるいはプロセスもそうですが、ウォーターフォール型が形式的で、アジャイル型が柔軟であると捉えるよりも、結局、柔軟にやっているやり方と、継続してやっているうちに硬直化してしまったやり方とが存在しているのではないかと思います。ウォーターフォール型も初めは割合と柔軟なところがあったのかもしれませんが、継続的にやっているうちに硬直化してしまったのではないかという気がします。ですから、アジャイルのプロセスやプラクティスも、今は割合と柔軟にやっていても、そのうち形式化してしまい、プラクティスのもともとの意図から外れて硬直化してしまうのではないかという気もします。

基本的な問題点はそうです。今は本を紛失してしまったので記憶が正しければケント・ベックのXPのバージョン1のときや、ジェームズ・ショアという人は、まずこれとこのプラクティスをやってくださいと結構強く書いているようです。XPのバージョン2になると、それはうまくいかなかった、これとこれをやりなさいというやり方は失敗したと書いています。そういう意味では、そういう失敗を一回したのではないかというのが私の理解です。

最初は軸がないですから、そのとおりやらざるを得ないと思いますが、そこからある程度、それを踏まえて応用していかなければいけないでしょうね。

私も昔、『デザインパターン』を最初に読んだときはよくわかりませんでした。最初に読んだときには、ぴんとこないですよね。ですから、とりあえずめったやたらにパターンを適用してみたら、フレームワークチックなネットワークがうまくできて、ああ、そういうことなんだとわかりました。当然、要らないパターンなども使ってしまっていますが、まずは言われたとおりにやってみることが大事だと思います。その後、自分なりに消化し、取捨選択しながら使う。そうでなければスキルなどは身につきませんので、XPも最初はまずやってみようというのはあながち間違いではないと思います。ただ、そのうち有名になって、それが原理原則、金科玉条のようになり、とにかくこれを全部やるのが正しいという誤解が広がってしまうと、バージョン2などのように、いやいや、ちょっと待てよという話になる。そういうぶれがあったのかもしれないですね。

つまり、バリューがどこにあるかということで、プラクティスがバリューだと思ってしまうと目的を忘れてしまうわけです。デザインパターンにも、デザインパターンをやることが目的だということが一部あったと聞いていますが、本来はQCDなどの大目的があるわけです。

先ほど竹政さんから柔軟というお話がありましたが、それは非常に同感です。政治の世界でも、民主党の工程表がちっとも（進まない）ということがありますが、工程表そのものが大事なのではなく、ほかに目的があって、そのために工程表を作るわけです。ですから、工程表の見直しはあってしかるべきなわけです。開発プロジェクトでも、ウォーターフォール型ではスケジュール絶対厳守ですが、アジャイルなどではスケジュールを見直す。RUPでも、最近はスケジュールを見直してもいいことになっています。ですから、目的が何かということが非常に大事だということだと思います。

本当におっしゃるとおりだと思います。柔軟ということでは、リファレンスガイドの中でも「柔軟なプロセス」ということが記述されています。ここでの説明は割愛しますが、アジャイルの中ではそういうものがあります。

もう一つは、プラクティスをやることが目的ではないということについては、私個人の意見としては全くおっしゃるとおりだと思います。また、今まで出てきていない議論としては、例えばクリスタルクリアやリーンなど、ほかの手法も幾つかありますが、そこではプラクティスについて、創出はしていくけれども、あまりうたっていないようなところがあります。そういう意味では、プラクティスという捉え方をした時点でXPとスクラムに結構近づいてしまうのではないかと個人的には思っています。

では、プラクティスを全てやればいいのか、正しくやればいいのかというと、全くそういうことはなく、どのように価値を提供するのかというところが大切ではないかと非常に思います。

そういう意味では、今回、本橋さんがIPAで作られた65個ぐらいのプラクティスは、その辺をちゃんと書いておかなければいけないと思います。この65個をやればいいということで、どんどん詳細になっていったり、やったのにうまくいかないということになったりしますので、その辺を最初にしっかりと書いておかなければいけないと思います。書いてあるかどうかは見ていないですけれども。

この「アジャイル型開発におけるプラクティス活用事例調査」という資料は、やっているという結果ですよね。調べるに当たっては、やめたというところも幾つか出てくると思いますが、そういうものはどこかにまとまっていますか。

それについては、事例ベースで「うまくいかなかったプラクティス」ということがあります。たとえば、事例Bは、ユニットテストはやっていません、逐次の統合もやっていませんというものです。うまくできなかったということですね。

それがなぜかということはありますか。全部はやっていられないとか。

全部はやっていられないということが多いと思います。それから、そもそもプラクティスで想定しているような問題がないとか。

やってみたけれども、俺たちはそんな問題は抱えていなかったと。

はい。逆に問題を増やしてしまったとか、そういうこともあります。別のツールで自動的にレポートができてくるのでバーンダウンチャートは作っていないとか、いろいろとあります。インセプションデッキをやっていないというのは、これは想定ですが、インセプションデッキをやると開発側の意見が非常に強くなってしまうといいますか、我々は何のためにいるんだと言われて、このためだと話しても意味がないと。まさしく、そういう問題を抱えていなかったのでやっていないということですね。

ニコニコカレンダーはたしか、やったのですが、誰も乗ってくれなかったと。（笑）

気持ちはわかります。（笑）

そして、これは別の事例ですが、ニコニコカレンダーではだめだから、怒るカレンダーといいますか、気持ちを天気で表すカレンダーといいますか、気持ちが荒れている度合いのカレンダーを作ったのですが、それも誰も乗ってくれなくて、やめたという事例もあります。

ニコニコカレンダーは日本発ですよね。

そうだと思います。

そういうものが非常にはやっている方面もあるのですか。

方面といいますか、関係しているところでは、ニコニコカレンダーっぽいものを運用しているところはあります。事例ごとによって全て違うというところがポイントです。ニコニコカレンダーに乗ってくれる人たちもいますし、乗ってくれないといいますか、あまり役に立たないといいますか、問題が解決しないところもありますし、本当にプロジェクトごとに（違います）。

また、プロジェクトと一言で言っても、例えば最初の企画が強い時期、がんがん開発している時期、検証やテストをしている時期、保守・運用の時期など、どこまでプロジェクトに含むかということはありますが、その時期によって変わってきますので、プラクティス自体もその都度変えていく。柔軟なプロセスといいますか、柔軟なプラクティスといいますか、それが大切だと思います。

もともとニコニコカレンダーとは、日本では感情をそれほど表現しないので、それが表現しやすいようにやるというものだと思いますが、それをやらないというのは、もう表現しているからやらないのでしょうか。あるいは、ニコニコカレンダーでさえも表現したくないと思っているのでしょうか。

ニコニコカレンダーを運用していても、虚偽のあれを続けて、常ににこにこしているとか、もしくは常に怒っているとか。

そしてある日突然倒れる、みたいな。（笑）

内心は異なると、わかりにくいですね。

客観性がないですよね。

そうですね。主観をどう表現するのかという世界ですよね。

私がいるのは小さい部で、製品のサポートなどをやっていて、開発はほとんどやっていませんが、最近は個々人の担当製品が違っており、みんな黙々と自分の仕事をこなしているだけになっています。私から見ても、今何をやっているのかがよくわからないという状況でしたので、タスクボードを始めました。開発ではないのですが、「今、私はこういうことをやっています」ということを全部ポスト・イットで（貼っています）。ほかの部もやり始めたのですが、タスクボードの枠の引き方一つとっても、本当に十人十色といいますか、部によって全部違うわけです。先ほどおっしゃったように、プラクティスの使い方は状況によって全く違ってきますので、方法論などといって決め打ちにしてしまうとアジャイルはうまくいかないのではないかと思います。

おっしゃるとおりですね。タスクボードを見ているだけで、本当に面白いですよね。ノウハウ満載といいますか、なるほどなと。そういう意味では、タスクボードの意見交換といいますか、発表会といいますか、そういうものをやると面白いかもしれないですね。

それも（形容詞的に）アジャイル的な組織ならばそういうことは自然にできるのではないかとも思いますね。そもそもアジャイルを導入するという話とは別に、そういう組織では普通に使えるからやっているというような話ではないか。逆にそういうことができないところには、持っていくのが大変なのだろうと思います。

それはあると思います。私のところはもともと古いので、スペックが一番になっているわけです。「やれ」と言われれば、それを愚直にやり続ける文化があるところでは、最初に「こうだよ」と教えてあげても、それが変わっていかないということがありますので、それをどうしたものかということはありますよね。最初に決めたら、うーんと思っていてもそのままやってしまうという会社はあるのでしょうか。

今回はアジャイルということでヒアリングをしていますので、そういうものは思いつかないのですが、社会的にはそういう話を聞いたことはもちろんあります。

スクラムなどをやるときには、PO（プロダクトオーナー）がバックログアイテムの順番は決めますが、どこまで作ることができるのかというのはデベロップメントチームによって決まります。逆に、POがPM（プロジェクトマネージャー）のようになっていて、誰が何を作るか、どこまで作るかということもその人が全て決めているということもあると思います。今回の資料の中にはパターンとして朝会が入っているのですが、POがPOとして振舞っている現場と、PMらしく振舞っている現場とでは、同じ朝会でもその実態はだいぶ異なるのではないでしょうか？

朝会をやっているといっても、結局はPMの定例進捗会議のようになっているというところも見えています。これは推測を含みますが、やはり
PMが決めているのだろうというような印象を受けたところはあります。

朝会などでメンバーが誰に向かって話しているかということがよく例に挙がるのですが、
POに対してお伺いを立てているような話し合い方だと、あまりいい朝会ではないと言われたりします。

今回のレポートを見せていただきますと、プロジェクトが1個しかない会社もあれば、H社のように五つか六つのプロジェクトを持っているところもあって、五つも六つも（やって）社内的に広まっていれば、みんなアジャイルに対していい評価を持っているだろうと思います。恐らく1社は初めてやったというところで、入るときにはものすごい決断があったと思いますが、そういうところとは意見が少し違うのではないかと思います。

それも本当にディペンド・オンの世界ですよね。グループに関係なく同じようなプラクティスを実施しているため、非常に強いリーダーシップを発揮していると読み取れるところもあります。特に前々回の調査では、どの調査でもリーダーといいますか、アジャイルを推進したい人が必ずいます。メンバーの合う・合わないということもあって、どちらかというと合う人を募集することに力を入れている団体もありました。ですから、1個でやっているところとたくさんでやっているところはやはり違います。ギャップが少ないのは、どちらかというと1個のほうだと思います。それは自分たちがやりたくてやったということですね。

初めてやってどうだったかということを、もう少ししっかりと聞きたいですね。またやってみたいかとか。

今回、初めてアジャイルをやった事例もヒアリングしています。「G社の事例（9）」ですが、これは特殊な事例で、ある団体からアジャイルをするということで援助を受けていて、それが目的になっているというところです。アジャイルのコーチを呼んできて、プロダクトの価値をやるのではなく、アジャイルをやることによって対価をもらったという特殊な事例です。

何のためにそういうことが推進されたのですか。

県が公募し採択された実証事業プロジェクトです。

あとは、現場でやりたいとか、発注元がやりたいとか、いろいろとあります。

会社の中でアジャイルをやっている人たちはどの程度いらっしゃるのでしょうか。いろいろなプロジェクトがあると思いますが、アジャイルを推進してくれているプロジェクトはどれぐらいあるのでしょうか。

それこそディペンド・オンといいますか、100％、トップが「これをやるんだ」と言っていて、現場では反発しながらもやっているという会社もあります。また、先ほど言いましたように、何をもってアジャイルとするかという議論には意味がないのではないかということで、おいしいところをとっていくというところもあります。

100％アジャイルをやっているというところは、どういう業界なのでしょうか。業界は関係あるのでしょうか。

業界は関係ないような気がします。その組織のリーダーシップといいますか、組織の特性に影響があるとは思いますが、その100％やっているところはSIerさんで、ある配下では100％ということです。逆に、自社開発でも100％ではないところもあります。その辺は自由にやっていますね。

このヒアリングのスコープに入っているかどうかはわからないのですが、調査対象の会社の技術力についても調査はしているのでしょうか？明らかに技術力がないところでアジャイルをやるのは難しいと思います。

技術力については調査していません。申しわけありません。

いろいろなところにヒアリングをした経験から、やはりそれが絶対条件だという感想でしょうか。それとも、それほど技術力がないように見えるところでも、アジャイルで反復を何度も回すことによって、ある程度技術習得も進んでいくような事例があると言えるのでしょうか。

まず、全員が初心者とか、そういうことはあまりありません。ただ、先ほどのペアプロや人材のローテーションなどの手法を使って新人教育に成功したという事例はあります。逆にペアプロによる教育が失敗したという事例もあります。どんどん技術や知識が伝播されていったということは報告されています。

規模と人材のローテーションが割合と関係するということは、規模が大きければ人材のローテーションがされるということでしょうか。

そうですね。大企業の方の実際がどうだったのかということはあるのですが。

そこで言う人材のローテーションとは、どういうレベル、どういう意味ですか。

ここではちょっとあやふやにしています。組織間のローテーションや役割のローテーションなど、幾つかのローテーションが想定されているとは思いますが。

人材のローテーションというプラクティスがあったのですか。

あります。ちなみに、このB社は特徴的な人材のローテーションをやっています。

それはチームの中での（ローテーション）ということではなく、組織横断という意味ですか。

そういうことをあやふやにしているということです。要は、定義はせずに、人材のローテーションをしていますかという質問の仕方をしているわけです。それに対してイエスかノーかということで、デフィニションはありません。ただ、人材のローテーションに関するヒアリングは行っており、それはプラクティスになっています。全体の42％はやっていますと。

竹政さんが言われたのは、大規模なプロジェクトになるほど人材のローテーションのプラクティスを適用している例が多いということでしょうか。

ええ。そういうデータになっているわけですね。

はい。それが本当に定義されていなくて、人材のローテーションに丸をつけている人が多いということです。

何となく逆っぽい気がしないでもないのですが。

規模が小さいと人材をローテーションしておらず、その人たちだけでやっているということですよね。

逆に言えば、できてしまうということでしょうか。規模が小さいから、人を持ってこなくてもできてしまう。

そうですね。持ってこなくても、その人たちだけでいつも完結している。

ああ、そういう意味ですか。私は人材のローテーションというプラクティスについて、一つのチームの中で、「私は今までテスターとして仕事をしてきました」という人でも、アーキテクチャに関する議論に参加させたり、テストばかりを書くのではなくコードレビューもやってもらったりするという意味だと解釈していたのですが。

プラクティスは羽生田さんのご理解と一致しています。ただ、この辺は想定が入ってきてしまうのですが。

そうですね。その聞き方だと、どう解釈してチェックされたかがわからないですね。

小さい組織ではそもそも店子化といいますか、テスターであれ、アーキテクトであれ、いろいろなことを常に……

役割が分かれておらず、全員が全部やっているということでしょうか。

そういうことではないかと思います。

そして、明示的にそこには意識が行かないと。

はい。逆に大企業の場合は、そういうことが分かれているのではないかと推定するのですが。

そうだと思います。経験から感じるところでは、少人数のチームであればあるほど、お互いがお互いをちゃんと知って仕事をしていかなければならないという気持ちが働きますので、役割分担の話にはあまりならないのですが、声が届かないという人数にまで増えていくと、だんだんバウンダリといいますか、壁ができ上がるようなイメージを持っています。

そうなりがちな中で、ある程度役割が固定してきたらシャッフルするということを意識的にやろうというようなプラクティスであるというように、このインタビュイーの人たちは解釈してチェックしたのではないかということでしょうか。

そういうことです。適切です。（笑）

皆さんがそこまでちゃんと理解しているのであればいいですけれども。

そこと技術レベルが関係あるのではないかと思ったわけです。小さな規模だと、みんながみんなやっているから、それなりの技術レベルで進行していて、逆に大規模だと、専門特化する技術者になってしまうのか。それがうまくローテーションできれば、それはそれでよいのか。そこまではちょっとわからないのですが。

技術レベルとの相関はわからないですね。

今日は品質の話があまりなかったのですが、従来型の品質の評価方法をとったのか、それともアジャイルなので別の方法でやったのか、その辺は見られましたでしょうか。

まず品質に対する調査は、「非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査」で報告されています。

2012年の調査ですか。

はい。2012年のほうでしており、そのときには品質の悪化があったというレポートは上がってきていません。それに対して、既存の方法を使っているのか、アジャイルの方法を使っているのかということについては本当に十人十色で、あるServicerさんでは、会社の決まりで品質部門を通らなければならないというところもありました。それはアジャイルの方法とぶつかるのですが、その部分だけはウォーターフォールのように、品質部門を通してやっていくという会社もありました。あるいは、アジャイルのスプリントレビューなどできちんと品質を高めていくというやり方をしているところもあります。その辺は本当に十人十色でした。

また、スクラムなどでも回しているんだけど、品質を向上させるためだけのスプリントといいますか、新しいチケットは出てこず、バグレビューといいますか、品質の問題点だけが上がってくるようなスプリントが後半に入ったというところもあります。それはスクラムとは言っているけれども、後半はチケットがばんばん来るということで、普通のウォーターフォールとそれほど変わらないとは思います。

品質に関して、XPの出始めのころに、組み込みの人たちでXPにチャレンジしたようなところが何カ所かあって、その人たちの話を聞かせていただくと、XPでやれば従来に比べてバグの数が1桁減るので、品質問題なんて全く問題ないと言っていました。しかし最近、だんだんスクラム中心のアジャイルになってきてから、アジャイルでは品質が1桁上がるというようなことを言う人が減ってきているのですが、それはなぜでしょうか。

推測を多分に含むのですが、まずスクラムの（コアな）フレームワークの中に、品質を上げるような（プラクティスは入っていない）。スクラムの定義がまた難しいのですが、スプリントを回してやっていますというようなフレームワークで、品質を向上させるようなプラクティスは入っていないというのが、私の認定スクラムマスター取得時の理解です。

スクラムのエコシステムの中に品質を上げるためのプラクティスがたくさん入ってきていますので、そこまで含めるのであれば、もちろんそういうものは入ってくるとは思いますが。

私はジム・コプリエンのスクラムを取ったのですが、そのときには、問題の2割はバグとして出てくると聞いて、2割は多過ぎると思って質問しました。そういう意味では、スクラムのフレームワークそのものは、実は品質に対して重きを置いていないのではないか。これは私の仮説というか推測が多分に入っており、スクラムの人たちが反論されることは想定されるのですが、そう思っています。

スクラムでは、開発チームがプロダクトの品質に責任を持つということしかありませんよね。やり方は任せると。

そうです。コアなフレームワークそのものにはないですね。そこに自分でそういうプラクティスを追加するということです。

そのものにはなくて、スプリントレビューのときに、ちゃんとDoneの定義を満たしているかどうかだけです。

そうですね。

一方では、ウォーターフォールのほうの品質も上がってきているのではないかという気がしています。昔は何も考えずにといいますか、「やれ」と言われて作っていたのに対して、今はウォーターフォールといっても、アジャイルのプラクティスなどを入れているといいますか、自然と入ってきているのだろうと思います。そう考えると、そちらの底上げもされていて、その差がどんどん狭まっているのではないかという気がしています。

あと、Doneの定義はくせ者で、Doneの定義をしているがゆえに、あるDoneの定義の領域と別のDoneの定義の領域の間にすき間が発生してしまい、リリース前に大問題が発生してしまったという事例がありました。

Doneの定義の範囲が狭過ぎたということですか。

これは推定ですが、Doneをさせるために、これが
Doneだと。それが通ってしまうわけですけれども。

本来はこれだけなければいけないのに、Doneさせなければ終わらないので、これだけにしてしまったと。

そうです。

時間が迫っていますが、ほかに何かありますでしょうか。

逆に私のほうから伺いたいのは、モデリングとアジャイルのプラクティスは直交するといいますか、アジャイルをやっていようが、ウォーターフォールをやっていようが、RUPをやっていようが、それぞれモデリングというものは大切なのではないかと思っています。前回のアンケートで、UMLの話がないという問題が書いてありましたので、何か考えなければいけないと思ったのですが、何をやってもモデリングが合うといいますか。UMLを使うのか、何かほかのものを使うのかは別の議論だと思いますが、それはどうなのかということを教えていただけますでしょうか。

私個人の意見ということになりますが、基本的には必要だと思っています。アジャイルの場合、モデリングをどこまできちんとやるかとか、そのあたりが異なっていくるのではないかと思います。本当にラフにホワイトボードに書くようなモデリングもあれば、モデリングツールを使って属性や操作などを細かく定義する詳細なモデリングもあります。レベルの差はありますが、本当に重要なところをメンバーが共通に理解するためのモデリングは最低限必要ではないかと思っています。

私もそう思っています。フィーチャーごとに物を作っていくためには、見えるようにしておかなければ、次のフィーチャーをどこにくっつけるのかということがどんどんわからなくなってきますので、最低限は要るのだろうと思います。私のところでは組み込みをやっているのですが、モデルなしでレッツゴーしますと、大概は最後のほうでえらい目に遭うわけです。ですから、きちんとレイヤー化し、役割が見えるようにして、ハードウェアのインタフェースを薄くしておかないと、もともとソフトウェアを作るときにはハードウェアがありませんので、後々困ることになります。ですから、先ほど竹政さんが言われたように、どのレベルまで作るかということはあると思いますが、何でやろうとモデルは必要だろうと思っています。

書く・書かないはともかく、モデリングの考え方が頭にないと難しいと思います。アジャイルを実践している現場でソースを修正する際、どこをどう修正するのかというのは、大体の場合、プログラミングする人に任されると思います。このときに、例えばアーキテクチャの人がどういう設計思想で設計したのかということがわからなければ、「動けば良い」ということで、変なところにコードを入れてしまいます。また、全体の設計思想から外れるようなコードを見たとき、アーキテクチャの観点から違和感を覚えるような感覚がなければ、プログラムを書きながら品質を作りこむことはできないのではないかとも思います。

他にはよろしいでしょうか。——では、ちょうど時間になりましたので、以上でワークショップを終了させていただきます。お疲れさまでした。（拍手）