[#Agile] アジャイル開発の課題と対策 その1

アジャイル開発が日本で知られるようになって10年以上経ちました。去年、あるいは一昨年からアジャイル開発2次ブームになって、大手ベンダーが取り組みを始めるようになりました。たぶん、今回は一定の広がりを見せると思います。

しかし気になるのは「なぜ、普及が遅れたか？」です。アジャイル開発の特長は数多くありますが、コード優先の繰り返し、テスト自動化、 現場能力発揮、顧客優先、いずれも大きな障害と考えにくく、 そのいずれを考えても遅れた説明がつきにくいと思っています。

関連する文献

そこで思い出したのは、児玉さんの「UMLモデリングの本質」に書かれた一文でした。

1990年代に入って、世界では構造化分析/設計手法がオブジェクト指向分析/設計手法に取り込まれました<中略>。一方、日本では、情報システムをWebアプリケーションで作成する事が主流になる2000年までは、DOA型の構造化分析/設計手法が依然として優勢であり、オブジェクト指向への取り組みが進みませんでした。

一方、平鍋さん・野中さんの「アジャイル開発とスクラム」には、こうあります。

コンウェイの法則によれば「ソフトウェアの構造はそれを作り出した組織構造に従う」となるだろう<中略>。ならば、オブジェクト指向的な組織構造を作ったらどうだろうと考えたというわけだ。

この二つを単純につなげると、日本ではオブジェクト指向の普及が遅れていたので、アジャイル開発の普及が遅れたとなりそうです。しかし、そこに（日本ではまだあまり説明されていないと思われる）アジャイル開発の課題があるのではないか。というのが、この記事の主旨です。

アジャイル開発の特長は理由にならない

(1) コード優先と繰り返し

オブジェクト指向を実践しているかどうかに関わらず、新しいフレームワークを利用する際や、Rubyのように動的な要素を含む環境では、机上の設計だけを先行しておいて、一気に開発するような事は危険です。プロトタイピングはもちろんですし、基盤部分とサンプルなどから順次構築していくことも珍しくありません。次にあげる自動化と共にあたりまえに行われていると思います（自動化による信頼性向上 - オブジェクト指向とアジャイル開発 -）

(2) 自動化

Eclipseのような統合環境による支援、テスト自動化や継続的統合、は、アジャイル開発をきっかけに広がった感があります。統合環境はアジャイル開発と関係なく使われていますし、JaSST(ソフトウェアテストシンポジウム)などでも、早くからテストファーストは有効だという意見がありました。継続的統合がそれほど普及していないとしても、自動化が大変だからアジャイル開発をしない、などという話は聞いた事がありません。チケット駆動開発が注目されているように、自動化によるプロセス改善への抵抗は（手段が目的化した場合の批判はありますが）あまりないと思います。

(3) 現場能力発揮

欧米との価値観の壁は確かにあると思います。しかし、プロセス改善を実践されている方とお話をしていると、現場への押しつけになってモチベーションを下げないように、勉強会の開催や各種フィードバックを心がけられている方も多いです。そのような方が一定量おられるなら、アジャイル開発が一定の普及をしてもおかしくないはずです。

(4) 顧客優先と契約

請負一括開発でディフェンシブになるのことについては、ないとは言いません。しかし、共存共栄できなければ仕事はなくなりますし、そもそもお金を握っている発注側が、日本では一般に強いでしょう。

[#TiDD] 従来法の限界とアジャイルの利点、そしてチケット駆動開発や[#TiDD] 最近のソフトウェアを考えるとアジャイルに向かうに書いたように、従来の開発法で進めるよりはアジャイル開発の方が有利な面が多く存在すると思います。また、契約面で考えると、顧客が望みさえすれば[#TiDD] アジャイル風開発ラフシミュレーションに示した、五月雨ウォーターフォールが実現できますし、実際されています。この事から言えるのは、未だにウォーターフォールに近い開発をされているユーザや開発部門は「その気になっていない」のだと思います。

DOA

このように見てくると、その良さが伝わるのに時間がかかるとしても、10年はかかり過ぎだと思います。そこには、アジャイル開発に移行できない「危機感」があるのだと思います。

【初級】ゼロから学ぶDOA　第1回にあるように機能よりもデータが安定しているので、データに注目するという認識を持つ方が多いでしょう。私もワーニエ法やジャクソン法、構造化設計/分析などを学ぶ際に、機能よりもデータが安定しているので、データに注目した方が良いと言われている、と教わりました。

しかし、DOA（海外ではDDA）を実践されている方にうかがうと「データが変わると大変なことになるから」というのが本当の理由だそうです。以前話題になった渡辺さんの「データモデルなきアジャイル」の危うさ: 設計者の発言はそのように読めます。また、それを受けたkent4989さんのアジャイルとデータモデル、DB進化設計のこともそれを肯定されているように読めます。

これに対して平鍋さんはデータモデリングなきアジャイル開発は危ういか？の中で、リーンソフトウェア開発の「決定をできるだけ遅らせる」というプラクティス（セットベース設計）、ベーム氏の記事からプロジェクトごとに異なる計画とアジャイルのバランスのほか、「高リスク制約と思われていたものが、最近変更コストが低くなった、という例も本当に多い」とも言われています。

また、tgkさんは[モデリング]データモデル自体はアジャイルなのだが...の中で「データモデル変更の影響範囲を極力狭めるようアプリケーションをレイヤリングする」こと、つまりデータモデルを参照する範囲を限定せよと言われています。

これらは正しい事を言われていると思いますが、DOAを実践する際のモチベーションである危機感をなくして「先にデータモデルを作らなくて良い」と考えさせるには力不足ですし、解決策に至っていないと思います。

つまり、アジャイル開発の良い所も認めるし、うまくいく場合もあるでしょう、でも、私たちの仕事はうまくいかないんだよ。という方達の意見を覆す事ができていないと思います。

日本の特徴

解決策を考える前に、DOAがなぜ日本では根強いかを考える必要があると思います。

a) 既存業務の存在しない新規開発が少ない

最近は起業する人も増えて、リーンスタートアップなどが注目されています。しかし、日本のソフトウェア産業は大手ベンダーが中心で、新規の業務をこれから作るという事が少ないと思います。

既存システムのリプレスの場合、サービス開始当初から多くの機能が実現されている事が要件になります。 業務を止めないように細かなところまで必要とされます（場合によっては不具合までも仕様になります）ので、スモールスタートできる可能性は、あまりありません。

b) 基幹業務システムの割合が大きい

会社の屋台骨である基幹業務は、ルールの明確な複雑な処理です。法律の変更によって仕様が変わる事があっても、外界の変化によってスコープが変更される事はあまりありません。

結果的にスケジュールを守る目的で、運用で回避する事はあっても、作り上げながら仕様のバランスを取るような要素は、ユーザインタフェースを除くとあまりないでしょう。

c) 全体最適主義

個々の事情よりも全体の管理が優先されます。上に述べたように現場のモチベーションも重視されますが、部分最適よりも全体最適の方が効果が大きいからでしょう。

予算獲得もなぜそれが必要かの説明や、どこまで実現するかのコミットメントが求められ、全体を考慮した上での決定がなされます。

d) ミッシングリンク

そんなことを言っていたら「ビジネスに乗り遅れる」と最近のアジャイル技術を知っている方なら思われるでしょう。「許可を求めるな謝罪せよ」（ CSMA/CDを思い出すのは私だけ？）とまで言われるように、スピードがビジネスには欠かせないはずなのに、なぜ日本だけ違うのでしょうか？

古くから欧米は起業精神が高いと言われますが、現在の日本の大企業も明治時代や戦後に起業しています。安定になれてしまったとか、インターネットバブルが日本では失われていたとか、色々な説明ができると思いますが、ここではDOAから考えてみます。

上で引用したITproのDOA解説の年表にも出てくるジェームス・マーチン氏はInforeation Engineeringの後にRapid application development(RAD)を、インターネットブーム直前の1990年に発表されています。これは、繰り返し型の開発や顧客と共に開発するなど、アジャイル開発の要素を含んだ開発法です。なぜか、日本ではあまり盛り上がらず、RADといえばVisualBasicのような開発環境しかWikipediaには載っていません。

海外ではビジネスチャンスに開発を最適化し、新規ビジネスを起こそうとしていたころ、日本では景気回復まで耐えるべく、全体最適とクライアントサーバーで乗り切ろうとしていたのでしょう。もちろん、日本でもインターネット関連は大きな伸びを示しましたが、海外と比べるとM&Aが多かったように思います。

この記事のはじめに、日本は10年遅れたと書きましたが、RADから考えると20年おくれていることになります。

解決策

では、これから景気が回復して、新規ビジネスが増えて、アジャイル開発が増えればそれで良いかというと、大いに問題があります。

新規ビジネスはリーンスタートアップでスモールスタートできますが、日本を支える既存産業が時代遅れになってしまうからです。欧米が20年かかって学んだ事に追いつき、追い越さないといけません。

まず10年取り返すには「アジャイルと規律」が参考になります。この本はXPが出てきた後に、５つの重要要因に注目してアジャイル開発と計画駆動の開発をどのようにバランスするかが書かれています。

この本のポイントは、以下の３点です。

• リーンやFDDなどのリスクベースのアジャイル手法と計画駆動を組み合わせる
• アーキテクチャ設計を予め行う
• 開発内容にあわせて計画駆動のチームとアジャイル開発のチームに分ける

これで10年ほど、取り返せます。

さらに10年を取り戻すには、上記のアーキテクチャ設計をビジネスの視点で考える事だと思います。日本でも実装の基盤として多くのアーキテクチャ設計が行われてきました。しかし、ビジネスの視点でアーキテクチャを考えれば、計画駆動のチームとアジャイル開発のチームをうまく分ける事ができるでしょう。

また、時間軸の考慮も有効だと思います。「決定を遅らせる」べきものを拙速に決定するのではなく、リスクが少なくなるように効果的なタイミングで実施することで、より競争力が増すでしょう。

どこかで良いといわれたプロセスを盲目的に当てはめるのではなく、プロジェクトにふさわしいアーキテクチャとプロセスを構築すれば競争力が増し、20年間の遅れは問題にならないと考えています。

まとめ

日本でアジャイル開発の普及が遅れたのは、徹底したDOAが基幹業務の開発に向いていたからで、新規ビジネスの少なかった日本の競争力を支えてきました。基幹業務のノウハウを活かしつつ新しいビジネスを生み出すには、アジャイル開発だけでも、DOAだけでもうまくいかず、バランスを考慮したプロセスが必要でしょう。

この記事ではベーム氏の「アジャイルと規律」をヒントに、ビジネスとプロセスを考慮したアーキテクチャ設計を提案しました。他にないサービスを実現する事でビジネスが成り立つように、ビジネスにあわせたプロジェクトのプロセスを構築する事で他社との差別化が可能になると思います。

ソフトウェア開発だけに注目するとプロジェクトの共通性に目が向きがちですが、ビジネスに注目するとプロジェクトの個別性が目立つようになります。プロセス標準と共に個々のプロジェクトを支援する事も必要です。

ふさわしい組織作りをする際に、コミュニケーション、構成管理、ワークフローなど様々な検討と支援が必要になります。そのような場面で、チケット駆動開発はセメントのように、様々な問題を解決して、組織を形作ってくれるでしょう。

[#Agile] アジャイル開発の課題と対策 その2に続く