柔軟なウォーターフォールはアジャイルと見分けがつかない
2015年10月21日に行われたエンタープライズアジャイル勉強会2015年10月セミナーでの講演『エンタープライズアジャイルと全体最適について ～アーキテクチャ設計とウォーターフォールの必要性～』のレポートです。資料は以下。
講演の後の懇親会で「計画的なアジャイルと、柔軟なウォーターフォールは見分けがつかない。ていうか、名前だけの問題だ」という話になりました。
資料でも書いているとおりエンタープライズ案件はリリース日について厳密なコントロールを求められます。一方で、多くのプロジェクトではリスク管理が重要であることは間違いなく、だからこそ、アジャイルでもウォーターフォールでも（まともなプロジェクトであれば）実質的なオペレーションは似通ったものになるというのです。
確かに、僕の経験から言っても、一度アジャイルを経験してしまうと「ウォーターフォールかどうか」というのは希薄になって「計画すべきはどこか、作って試すべきはどこか」という問いが重要になります。
最近の案件でも「アジャイル開発でやりたい」と言われたところで、結局、リリース日や必須機能が決まっていれば、アーキテクチャ設計を入念にやって、確度が上がったら長めなバックログを作って、中期のマイルストーンを決めて、他システムを巻き込むテスト計画を立てて、となってきて「あれ、これウォーターフォールじゃね？」ということがあります。ただ、もちろんのことながら、必要なだけのプロトタイミングやオンサイトやペアプロやオンライン情報共有や自動化や、様々ないわゆるアジャイルなプラクティスはやればいいだけです。
よって、「十分に柔軟なウォーターフォールはアジャイルと見分けがつかない」というか「十分に計画的なアジャイルはウォーターフォールと見分けがつかない」わけです。こうなってくると、たしかに呼び方だけの問題かもしれません。
喩え話的に「COBOLからJavaが主流になった瞬間、もはやCOBOLで作ろうなんて誰も思わないけど、実際にはCOBOL的なJavaはあったし」というのが引き合いに出たのですが、つまり「ソフトウェア開発といえばアジャイルプロセス」というのが「常識」となった瞬間に「ウォーターフォールはアジャイルの亜種」になるのではないか、というのです。言語と開発プロセスを並べるのは簡単ではありませんが、言いたいことは良く分かります。
僕も「アジャイルを目的にした開発は嫌い」ということは言ってきたのですが、世の中の認識が「普通、アジャイルでしょ」となってきているのであれば「ウォーターフォール的な要素も残そうよ」という言い方にしていってもよいかもしれません。とはいえ、エンプラ系の講演で「もう普通はアジャイルですよね？」とかいうとぽかーんとされそうですが...。
なお、資料の方はプロセスとして「ウォータフォールとアジャイル」、アーキテクチャとして「SOAとMSA」と対比させ、現在は後者を主流としながらも、どちらも必要な要素であることをお話させていただきました。どちらも「トップダウンとボトムアップ」の対比として考えることができますよね。
（SOAとMSAの比較も盛り上がりましたが、それはまた別の機会にでも書きます）
アーキテクチャ設計の意味を問う - クリストファー・アレグザンダーの思考の軌跡
建築家クリストファー・アレグザンダーが「パターン」という概念を広め、それがウォード・カニンガムとケント・ベックによってソフトウェア開発のデザイン・パターンに応用されたことをご存じの方も多いでしょう。
（ご存じでない方には、江渡さんの「パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)
「クリストファー・アレグザンダーの思考の軌跡―デザイン行為の意味を問う
この本を読むと、アレグザンダーは一貫して”数学的”であり、客観的に証明可能な構造を求め続けたからこそ、近年では”神”の視座へと導かれていったのだと分かります。
パターン・ランゲージと設計プロセス
アレグザンダーはパターン・ランゲージによって、モノの”形”と、それに対する人の”価値”の美しい関係性を探求していました。
ある形をデザインする際の難しさは、複数の要求に対して全体的な整合性を取ることです。ソフトウェアのアーキテクチャ設計でも性能と保守性、コストとセキュリティなどの要件は「こちらを立たせれば、あちらが立たず」になりがちです。
そこで、パターン・ランゲージと呼ばれる複数の「部分的な形の基準（＝パターン）」を用意しました。パターン・ランゲージを用いて要求を部分へと分解し、それらを再統合していく過程で、部分ごとに要求と形のギャップを解決していけば、美しい形を自動的に作り上げていけると考えたのです。
パターン・ランゲージが興味深いのは、単に「優れたパターンを用意しました」ということではなく、「パターンを基準として要求とのギャップを探索することで、段階的にデザインが進められる」という設計プロセス論であり、かつ、それは「誰が使っても同じ結果に至る」ことを前提にしていた点です。
機能の限界
しかし、こうした設計プロセスでは「形と価値への探求」が「形に与えるべき機能」と「機能がもたらす価値」という議論に分裂することが分かりました。そして、アレグザンダーは「機能」の議論を突き詰めていっても美しい形にはたどり着けないことに気づいたのです。
そもそも、人は「”形そのもの”に価値を感じる」のではなく、その「”形がもたらしうる機能”を通じて価値を解釈する」こと、言い換えると「形への意味づけ（≒機能）によって価値を考える」ことが脳の構造的に好きなのです。よって、価値と形を直接的には結びつけずに「価値から機能へ、機能から形へという変換」が発生していたのです。
この変換には、どうしてもデザイナーの志向性が反映されてしまうため「誰が使っても同じ結果に至る」ことができないのはもちろんのこと、美しいものとはなりませんでした。
なぜ通販番組で物が売れるのかと言えば、それは「触れて分かる形への直感的な価値を感じた」ではなく「機能への説明に対する概念的な価値を感じた」によるものなのでしょう。しかし、買った物を使い続けられるのかというと、それはまた別の話なのです。「美しいと感じる」ことと「機能が優れている（と納得した）」ことには乗り越えられない壁があるのです。
これは現代的に言われる「デザイン手法」に対する痛烈な皮肉とも捉えられます。つまり、「よく考えられたデザイン」であるほど、それは「機能と価値」という概念的な議論にすぎず、「形と価値」という具体的なモノ（存在）への探求ではないわけです。
中心的な価値基準の存在
この絶望は、アレグザンダーを次の段階へと進めます。
アレグザンダーは『（形に対する）諸価値基準の相違は、ある1つの中心的な価値基準に訴えることで解消できる。＜中略＞それをわれわれは一者（the One）や無（the void）や偉大なる自己（the great self）と呼んでもいいだろう』という、”いっちゃった”考えにたどり着きます。
とはいえ、論理は明快です。人は価値を機能によって考えがちではあるが、理由無く形に感動できるので、やはり、「形と価値はどこか深いレベルで直接的に関係している」としたのです。
そこで「価値は（形の）全体性からもたらされる」と考え、さらに「機能は全体性の動的側面に過ぎない」としました。
たとえば建物というのは、その形が独立して存在するものではなく、その周りにある庭や道路や隣家や、あるいは街や国のような存在から連続した全体性として存在します。そして、機能というのは「全体性の中で（構造が見いだされるときに）立ち現れてくるもの」だとしました。
こうなると機能を追い求めることは無意味となります。機能は全体性から生成されてくるものなので、機能そのものを直接定義することはできないのです。むしろ、優れた機能を提供し続けられる構造そのもの、つまり、形そのものを探求する必要があります。
よって、機能を部分的な静的構造と紐つけたパターン・ランゲージは否定され、価値ある機能を生み出し続けることができる構造を特徴づける幾何学的特徴を探求し、15個の幾何学的特徴を提示しています。
この15個は「自己と似ている形を探し続ける」という不思議な手法で見つけられています。アレグザンダーは形に対して感じる美しさ（≒価値）というのは「自己の中にある究極的な自己」と「全体性から現れる瞬間的な構造」が一体になることでもたらされるとしています。よって、「自己と似ているもの」を探すことが、美しいものを探すことになるのです。
この説明は形而上学的なので一見するとオカルト的ではありますが、形と自己に対する純粋な解釈によって成り立っています。この力強い精神は、納得感とは別として感銘を受けるものです。
戦い
2012年にアレグザンダーは"The Battle"を発表しています。これは日本の盈進学園東野高等学校で起きたことをまとめたものです。東野高校はアレグザンダーの成功例として知られていますが、これを作り上げるにあたり起きた様々な出来事をしるしています。
この部分はぜひ本で読んでいただければと思いますが、ソフトウェア開発の人にとっては「ウォーターフォールとアジャイルのせめぎ合い」を感じることができると思います。
そして、そこで語られるアジャイル的思想の純粋さに恐ろしくなるはずです。開始時点では完成形は分からない、費用は予算によってのみ決まる、実物を触ることでしか設計しない、完成した物に対して常にフィードバックを行って修正する。これをウォーターフォールしか知らない人たちと共にやりきろうとする。これがアレグザンダーが経験した戦いなのです。
ソフトウェア開発におけるアーキテクチャ設計
さて、せっかくですから最後にソフトウェア開発におけるアーキテクチャ設計に寄せましょう。
アレグザンダーがパターン・ランゲージを諦めたからと言って、デザイン・パターンが無意味であったわけではないでしょう。ただ、やはり現代においては意味が弱くなったとは考えたほうが良いように思います。
おそらく、現代のソフトウェアは、アレグザンダーの言う全体性の議論を考慮しないといけないほど、部分では語れない連続的なものへと成長したと捉えるべきなのでしょう。静的（クラスの構造）なパターンは、ある閉じた系においては美しく存在できますが、開いた系では周辺からの圧力によって美しくはなれず、むしろ、美しさとは動的（インスタンスの動作）に現れるものなのです。
これがマイクロサービスアーキテクチャの議論に結びつきます。マイクロサービスアーキテクチャは、静的な構造としてだけではなく、各システム間の依存性や開発プロセスといった動的な要素を取り入れています。これがソフトウェアアーキテクチャ論の進化の方向性であることを感じさせてくれるのです。
最後に「優れた物から見つけられた秩序を他者が実践しても優れた物ができるとは限らない」ことを付記しておきます。「成功した人の手法を真似ても成功するとは限らない」という身も蓋もない話です。アレグザンダーが言うようにデザインとは「する」ものではなく「成る」ものなのです。
企業システムとマイクロサービス #DF15
Salesforce.comのグローバルイベントであるDreamforce 2015（2015/9/15-18）に初参加してきました。仕事ではAWSもAzureも使うのですが、今回は最近なにかと縁があるSalesforceの雰囲気を感じに。
現地では事例セッションを中心に聞いて回りました。ご存じの通りSalesforceはエンタープライズ領域で使われるものなので、事例もエンタープライズ系が多くなります。エンタープライズということは「既存システムがある」ことが前提になるので、それらの既存システムとSalesforceをどのように統合するのか、というのがアーキテクチャ設計上の重要なポイントとなります。
（もちろん、スタートアップのベンチャーがSalesforceを活用してビジネスローンチを早めた、なんて事例もありますが、この場合は既存システムが存在しません）
各セッションでは既存システムを「ドメインサービス（Domain Service）」と表現しており、それらとSalesforce（あるいはHeroku）はAPIを通じて統合されます。
「ドメインサービス」というのはDDD用語ですが、特定のビジネスドメインにおけるサービスを指しています。企業システム全体の視点から見ているので、粒度は「棚卸システム」「商品カタログ」「支払」「顧客情報」なんで感じです。
ドメインサービスは、それがクラウドかオンプレかということは関係ありません。「企業内における特定ドメインのサービスである」ことが重要であって、サービスが提供できていれば実装方式はなんでもいいのです。
以下は百貨店Macy's（メイシーズ）の講演で使われていた資料です。
連携に使われるAPIはバッチ系、オンライン系、画面連携系と類別され、それぞれの統合するデータ量やタイミング、あるいはビジネス上の結合度などで使い分けられます。IoTクラウドも発表されたので、今後はリアルタイムストリーム系という統合も可能になるのでしょうね。
以下は家電量販店Target（ターゲット）の講演で使われた資料。バッチ連携をData、オンライン連携をBusiness、画面連携をUIと表現しています。
また、企業システム内の各サービスを総称して「マイクロサービス」と呼ぶのは一般的なようでした。「うちの企業にはXX個のマイクロサービスがあって、統合されている」という言い方です。
前回のSpringユーザー会の夏イベントでも話しましたが、マイクロサービスアーキテクチャは「マイクロ」という単語に惑わされず「サービスを複数のサービスから構成する」という関係性に注目して理解すべきです。
というわけで、各セッションは「当然そうだよね」という話ばかりだったので違和感もなく聞けました。やはり、エンタープライズの文脈からもマイクロサービスアーキテクチャ的な考え方は有効であり、クラウドも、その一部として配置すればいいだけです。
印象的だったのは上記のようなユーザー事例講演はユーザー企業内のアーキテクトが話をしている点です。やはり企業全体を理解したアーキテクトの存在というのは非常に大きいなと思います。
日本国内において、その役目を誰が担うべきかは簡単な議論ではありませんが、僕自身、そうした立ち位置での仕事も増えており、今後も大きなニーズがあるのだろうことは間違いないでしょう。
さて、来月はJavaOneですね。
マイクロサービスアーキテクチャとは何か
マイクロサービスアーキテクチャ（以下、MSA）という言葉を聞くようになりました。きっかけはファウラーのブログ「Microservices」（2014年3月）ですが、昨年10月のJavaOne SFでも多くの講演でMicroservicesという言葉を聞かれ、多くのエンジニアがすぐに共感していたことが分かりました。今後、日本でも広く知られる言葉になることでしょう。
一方でMSAは誤解を招きやすいバズワードとも言える気がします。というわけで、僕なりのMSAについての考えをまとめてみました。
MSAは「優れたウェブサービスを観察したところ同じようなアーキテクチャだったので、それをマイクロサービスアーキテクチャと名付けた」というものです。逆に言えば「大きなウェブサービスを作ろうと思ったときの定石」といえます。「各要素を疎結合に構成し、連携する」「それぞれの要素に適した技術を使う」といったアイデアは突飛なものではありません。
大きなウェブサービスであればMSAという言葉がある前からMSA的に作っていたでしょうし、僕自身もそのようにシステムを設計していました。もちろん、先進的な企業ならではの取り組みもありますが、基本的な思想は同一です。
ですから、MSAがブームになったからといって「MSAを目的にしたアーキテクチャ設計」をしたところで失敗することになります。対象システムにとって適切な手法を選択したら自然にMSAになるはずです。それを無理にMSAにすべきではありません。アジャイルを目的としたプロジェクトが失敗したように、手段を目的としてはなりません。優れたウェブサービスがMSAであっただけで、MSAを採用したから優れたウェブサービスになるわけではありません。
SOAとMSA
エンタープライズであればSOAとの違いについて考える必要があります。資料中にもありますが、僕はSOAがトップダウンの理想論であったのに対して、MSAはボトムアップの現実論として捉えています。これは時代背景の違いと言えるでしょう。
SOAは「バラバラであったシステム群をいかに統合していくか」が課題であった時代に創られた言葉であり、一方で、MSAは「巨大なサービスをいかに複数のシステム群で構成するのか」が課題の現代における言葉です。SOAからMSAまでの10年で状況が変わったのです。
MSAと政治学
個人的な興味ですが、SOAからMSAへというアーキテクチャ設計の移り変わりは、政治学における「封建制」「君主制」「民主制」という流れと似ていると考えています。
その昔は個別のシステムは個別の部署によって管轄されて独立して存在していました。それぞれの責任は明確であったものの境目は曖昧で、個別に問題解決をしていたといえます。
これが封建制の時代。各領主には主権があり、個別の法制度が許され、比較的独立していたのです。
しかし、1990年代ごろから各システム間の連携が多くなると全体整合性の観点からシステム資産の活用度を高めるニーズが出てきます。そこで提唱されたのがSOAでした。SOAでは各システムのインターフェースに統一のルールが求められました。EAIによるデータ交換のハブ化、MDM（マスタデータマネジメント）によるデータモデルの統制、BPMによるプロセスの自動化など、企業全体を俯瞰した考えです。
これが君主制の時代。一人の王によって法制度が定められ、各地方では領主たちが統治を預けられていた時代です。ただし、君主制には偉大な王が必要であり、多くの君主制は統制の限界を迎えて打倒されていきます。
そして、2000年代を超えてくるとウェブサービスと呼ばれる巨大なシステムが作り上げられるようになりました。ウェブサービスは全体が継続的に稼働することが求められ、それを構成する各システムは切れ目なく連携続けなくてはなりません。各システムはサービス全体に組み込まれるように作られるため、インターフェースは明確なものの、それら自身の構成はライフサイクルやメンバーにしたほうが効率的でした。
これが民主制の時代。国全体としては明確な境界線を持っており中央政府も存在しますが、地方の統治は個別の自治体に任されています。地方自治体には権利はあるものの国としてのまとまりが求められるわけです。
もちろん、細かいアラはあるのですが巨大な企業システムを国に例えると、時代と共に成熟していくのは当然のように思います。
ITサービス運営におけるアーキテクチャの役割
2014年11月15日に開催されたJJUG CCC 2014 Fallにて「Javaエンジニアのためのアーキテクト講座」と題して発表を行いました。資料は以下です。
「良いアプリケーションを作る」時代から「良いITサービス運営を実現する」時代になったことで、アーキテクトの役割はどうなったか、という内容を話しました。
今回は自分なりにITサービス運営というものをモデルを書いてみました。v0.1となっていますが、まだまだ見直せることはあると思っています。
元ネタはソフトウェア品質モデルです。ソフトウェア品質モデルでも「外部」「内部」といった静的な要素に加えて、「利用時」「プロセス」といった動的な要素も含めて、お互いに依存したり影響を与えたりするということが定義されていました。ITサービス運営ということを考えて、もう一歩、複雑な構成となっています。大きく分けて「ITサービスを構成する要素」と「ITサービス運営に関わる利害関係者」となります。
ITサービスを構成する要素
| 要素名 | 特徴 | 例 |
| 利用者の体験価値 | 利用者が体験して感じるもの 利用者によって評価が異なる |
AさんとBさんで評価が異なる |
| サービスの振る舞い | 外部から見てわかる振る舞い 誰がテストしても同じ結果 仕様（機能と非機能） |
仕様とテストケース 品質特性 API |
| 動的な構成 | システム実行時の要素と相互作用 流れ、実行、プロセス |
インスタンス 処理 実行環境/インフラ |
| 静的な構造 | 成果物が配置された静的な構造 後に残り、参照可能 |
ソースコード クラス、テーブル定義 ドキュメント |
ITサービス運営の利害関係者
| 要素名 | 特徴 | 関心事 |
| 企画プロセス | ITサービスの振る舞いを管理する 振る舞いの追加や変更を要求する |
売上 要求 |
| 開発プロセス | 静的な構造を作る 構造を追加し、変更する 素早さが求められる |
リリース計画 開発ツール |
| 運用プロセス | 動的な構成を管理する 動的構成の追加や変更を受け入れる 安定が求められる |
デプロイ 監視 |
| 業務プロセス | ITサービスを利用し、利用者にサービスを提供する 利用者からフィードバックを得る 安定が求められる |
現場 効率化 |
このITサービス運営モデルで考えるべきことは以下の4つです。
- 個別の関心事を持つ利害関係者がいる
- 価値は利用者の体験によって定義される
- 複雑な構成要素によって成り立つ
- フィードバックによって持続的に成長する
これらの観点を考慮しつつ、各要素のバランスをとることがアーキテクチャの役割であり、それをデザインすることがアーキテクトの仕事ということになります。アーキテクチャ設計を進める上でも、そういった各要素を意識することが大事です。
もっと書きたいのですが、時間がないので詳細については資料を確認してください...。
オンラインでのフィードバックを見ていると「内容が難しくて分かりにくかった」というのがいくつかありました。モデルまでは理解していただいていていたようですが、後半のアーキテクトに求められる作業やスキルあたりが飛ばしすぎました。ここは反省をしております。次回、こういった機会には、もっと分かりやすく伝えられるようにします。
最後に書きましたが「アーキテクト的な発想」は職業がアーキテクトでなくてもできます。むしろ、すべてのエンジニアがITサービス運営全体を意識するというのは非常に大事なことだと思っています。
アーキテクチャのトレンドサマリ（2014）
今年はJavaOneに参加できたので、標準Java系は詳しい人に任せて、僕はアーキテクチャ関連の技術紹介や事例系のセッションを回ってきました。このサマリをJavaOne 2014 サンフランシスコ報告会 Tokyoにて発表しています。資料はこちらから。
動画はこちらから（コミュニティアップデートの途中からがアーキテクチャトレンドになります）。
発表時間が30分なのでコンパクトになっていますので、さっくりと見ていただければと思います。
もちろん「明日から案件に使えます」という話ではありません。ただ、JavaOneということもあって、話者はエンタープライズへの適用を前提にしています。よって、単純なスケーラビリティだけではなく、システム連携や信頼性についても意識はしています。意識したうえで「まだ簡単にはいかないけど、こうやっていくべきだ」という話です。
サマリとしては、アーキテクチャ設計をする上のポイントが、
- アプリケーション構築ではなく、サービス運営に目を向けた設計が必要になる
- コンピューティングパワーを効率的に使うためのデザインパターンが「ミドルウェア」として整理されてきているため、それを最大限に活用する設計にする
であり、アーキテクトに求められることは「サービス全体におけるドメインの境界を見分ける力」ということになります。
アプリケーション構築からサービス運営
アプリケーション構築とは「スコープがあり、終わりがある行為」であり、サービス運営とは「常に変化し、終わりのない行為」です。
サービス運営に求められる要素はアジャイル・DevOps・リーンスタートアップといった用語で包含されているので、ここでは詳細は述べません。簡単に言えば「フィードバックを元にした持続的な開発」なので、「いかにフィードバックを効率的に受け取るか」「それをいかに早く反映させ続けるか」といったところでしょうか。
特にIoTと呼ばれるデバイスの多様化は「ユーザーの利用シーン（システムのコンテキスト）」の多様化を引き起こし、より変化の度合いが広がることを意味します。
こうした状況においてアーキテクチャ設計で考慮すべきなのは以下のようなことです。
デザインパターンとしてのミドルウェア
そうした中で注目されているのがミドルウェアの存在です。より変化を受け入れ、早く構築するために必要な設計がパターン化され、ミドルウェアとして提供されているようになっています。
大きく進んだのはクラウドデザインパターン（CDP）でしょう。これはクラウドプラットフォームで提供されているミドルウェアの最大活用を前提にしたアーキテクチャ設計のデザインパターンです。もちろん、この考え方はオンプレミスでも重要です。
OSSのプロダクトを見ていても、アプリケーションフレームワークは少なくなってきて、ミドルウェアが活況です。そのアプリケーションフレームワークも、いかにミドルウェア的な要素を包含するか、というのが1つのテーマでしょう。SpringBootやDropWizardは開発容易性（EoD）を実現しているだけではなく、ルーティングやマネジメントといった要素を最初から取り込んでいます。
アーキテクチャ設計上のとらえ方をすると「固有で複雑な問題を、いかに汎用で単純な問題に置き換えていくか」という活動です。これまでミドルウェアの領域が成熟していなかったため、汎用化単純化に工数をかける意味がなかったのですが、今は違います。
ミドルウェア自体も「設定ファイルなどで行う設定」だけではなく「コードで行う設定」も増えており、適用領域はすごく増えています。インフラ領域で言われているSoftware-Defined Anything（SDx）は「インフラのミドルウェア化」と捉えるとわかりやすいですね。昨今話題のDockerは、その象徴的なものでしょう。
余談ですが「アプリケーションフレームワークの標準化」という考え方は早晩なくなるでしょう。今必要なのは「基盤としてのプラットフォームの整備」であり「各ドメインに最適化されたアプリケーションフレームワークの採用」です（これだけで記事が書けそうフラグ）。
アーキテクトに求められること
この状況でアーキテクトに求められることはなんでしょうか。最も大事なのは「ドメインの境界を見分ける目」だと思っています。ドメインの境界が見えなければ、その後、どのようにシステムを分断し、統合すればよいのかを考えることはできません。
ドメイン境界の発見において特に注目すべきなのが「変化の予測」です。対象となるドメインにおいて、将来発生してくる変化の要因を理解するとドメインの境界が見えてきます。ユーザーの変化であったり、ビジネスの変化であったり、様々なことが考えられるでしょう（これだけで記事が書けそうフラグ）。
DDDは、JavaOneでも最注目されている印象です。ただし、カタログ的な知識だけではなく、対象のシステムをきちんと見て、自分で境界線を発見することは忘れてはいけません。
まとめ
こうしたトレンドの変化は既に起きていることで、着実に進んでいます。エンタープライズでは、まだまだ顧客の意識も付いてきていないですし、レガシーシステムも消えてなくなるわけではありません。でも、5-10年先を見れば、今から取り組んでいかなくはいけません。
2014/10/27追記
動画リンクを追加しました。
アジャイルが否定したものを見直そう
2014/9/6に開催されたXP祭り2014で「アジャイルを手放して得られたこと」という講演をしてきました。Togetterはこちらから。
元々は「アジャイルのダークサイド」の話がしたくて応募したのですが、その後、いろいろと考えているうちに僕自身にも気づきの多い内容となりました。
さて反応を見てると前半のアーキテクチャとマネジメントの話に興味を持っていただいたようです。なので、このブログでは「なぜアーキテクチャとマネジメントの話からアジャイルの話をしたのか」ということを書いてみます。
アジャイルがさまたげたもの
アジャイル開発手法が大きく注目されるのは1999年の「Extreme Programming Explained」の出版であり、2001年の「アジャイルソフトウェア開発宣言」です。1990年代後半から2000年代初頭というのは、IT産業が大きく成長する時代であり、同時に、当時主流であったソフトウェア開発手法（いわゆるウォーターフォール）が世の中にも開発者にも適応しなくなってきた時代でした。
アジャイルは時代の変わり目にあって、過去と決別するために生まれてきたようでした。しかし、そのこと自体が過去にあったソフトウェア開発のあり方への理解をさまたげることになったのです。
ウォーターフォールとアジャイル
ウォーターフォールというのは計画を重視するプロジェクトマネジメント手法です。
プロジェクトマネジメントの基本は「計画・計測・調整」（計画を立案したら、実行をして計画との差を計測し、それを調整しながら進める）です。バイブルたるPMOBKの初版は1987年ですから、1980年代はITに限らずプロジェクトマネジメントがブームだったのでしょう。発行元のPMIは1969年に航空宇宙、建築、防衛などの業界中心となって設立されたもので、1970年代に標準化が進むと1980年代は業界を超えた適用が進みました。
言わずもがな航空宇宙、建築、防衛といった分野は計画通りに進むことが重要です。よって、計画を多角的に検証し、段階的に精緻化していくという「計画重視」の考え方は当然のことでしょう。
しかし、1990年代以降のソフトウェア開発というのは、技術面ではオープン化/ネットワーク化に伴う要素の複雑化、一方、ビジネス面ではIT主導のビジネスモデルの興隆による適用業務の複雑化が発生しており、産業全体が混とんとした状況でした。
つまりプロジェクトマネジメントの観点からすると、ソフトウェアは計画における見積もり精度の低く、かつ、目に見えないために計測が難しいものでした。ですから、計画を重視するタイプのプロジェクトマネジメントがソフトウェア開発に適さなくなっていたのです。
そんな状況で登場したのがアジャイルソフトウェア開発手法です。アジャイルは、
- 計画：精度が出るぐらい小さな計画にしよう
- 計測：動くソフトウェアで計測しよう
- 調整：定期的に関係者全員で調整しよう
と考えました。つまり、アジャイルは「調整を重視するプロジェクトマネジメント手法」といえるでしょう。
しかし、アジャイルにも欠点があります。それは全体設計の軽視です。漸進的に進むがゆえに、個別の成果が全体として整合しているかを確認することが難しいのです。そこを補うのがアーキテクチャです。
アーキテクチャとデザインパターン
そもそも、経験あるエンジニアであればソフトウェアを本格的に作り出す前に構造や構成をデザインし、その時点で性能や拡張性を確保するというのは常識でしょう。アジャイルのように段階的な機能追加を前提とするためには骨組みとなるアーキテクチャ設計は重要な作業です。
このアーキテクチャという考え方も1990年代に流行します。ただし、この時代の「アーキテクチャ」というのはザックマンフレームワークで有名なエンタープライズアーキテクチャを指していたと思われます。
エンタープライズアーキテクチャは1980年代に企業がITを取り入れていくにあって整備された分析・設計手法の集大成で、簡単に言うと企業全体をビジネス＞情報＞情報システム＞データ＞実システムと段階的にモデル化していくものです。ITが企業戦略に組み込まれるようになると、企業全体としてソフトウェアをどのように配置し、機能させるのかというのは重要な課題となってきます。
しかし、一方でビジネスのあり方とソフトウェアの実装をリンクさせるためには広範囲な経験を必要とします。仮に、たいして実装経験もないビジネスコンサルが「アーキテクチャ」と名前でモデル図ばかりを書いていたのであれば、それを実システムに落とし込むために現場の開発者が相当苦労したであろうことは想像に難くありません。当時のアーキテクチャ設計というのは「ビジネスコンサルが作った絵空事」というイメージが強かったように思います。
一方、1995年にはデザインパターンの原点「Design Patterns: Elements of Reusable Object-Oriented Software」が出版されており、ソフトウェアの構成をデザインする際の手法としてはアーキテクチャという言葉よりもデザインパターンのほうが広まった気がします。
デザインパターンはデベロッパー同士がアドホックにコミュニケーションするためには最適のツールでした。ただし、アーキテクチャ設計論のようなプロセスではありませんし、企業システムというよりはアプリケションにフォーカスされていました。とはいえ、そんな形式化がなくとも、優秀なデベロッパーにはデザインパターンさえあれば十分だったのでしょう。
ソフトウェア開発をデベロッパーの手に
こうした時代背景からすればアジャイルがプロジェクトマネージメントやアーキテクチャのアンチテーゼとなったのは必然かもしれません。
見方を変えると、アジャイルという言葉はデベロッパーの手にソフトウェア開発を取り戻すための運動だったのではないでしょうか。その対岸にいて石を投げられたのは開発もできないビジネスコンサルやプロジェクトマネージャーやエンタープライズアーキテクトです。
僕自身も当時はデベロッパーとして仕事をしていました。ソフトウェア開発が民主化し、急速に仕事が増える中で「マネジメントだ、アーキテクチャだ、ごちゃごちゃいう前に作って動かそうぜ」という気持ちになるのは十分に理解できます。この感情をデベロッパー同士で共有するための旗印がアジャイルだったのでしょう。
しかし、非常に残念だったのはアジャイルがウォーターフォールやアーキテクチャを必要以上に否定してしまったことです。その結果、そこにあったノウハウは広く普及しませんでした。しかも、産業の発展、労働者の増加、技術の変化が同時多発に起きたため、ソフトウェア開発における手法の形式化や標準化そのものが軽視されてしまった気がします（フレームワークの標準化は別の話です。いまとなっては残念な歴史ですね）。
アジャイルが否定したものを見直す
そして時代は流れて現在。ITが社会基盤に深く組み込まれ、その重要性が増している時代になったときに、あらためてアジャイルが否定したものの価値を見直すべきではないでしょうか。
ただし、単に計画精度を上げたりや絵空事のモデル図を書けということではありません。僕らは学んだのです。アジャイルの良さを取り入れながら、あらためてプロジェクトマネジメントやアーキテクチャ設計を考えるべきです（そもそもアジャイルの良さを理解しようとしない人もいますが...）。
デベロッパーがどんなに良いソフトウェアを作っても、それが正しく組織に組み込まれ、正しく社会で使われなくては意味がありません。このためにはソフトウェア開発の過程において面倒でもやるべきことがあります。そこに目を向けていくことが、これからのIT業界で大切なことだと信じています。
ウォータフォールやアーキテチャ設計は、ソフトウェア開発を進めるにあたり、利用者を含めたステークホルダーを巻き込みながら全体整合を保ち、ソフトウェアの利用価値を定義することを重視しています。これは非常に重要な考え方です。
だからこそ、アーキテクチャやマネジメントの話からアジャイルを見直していくことで、これからのソフトウェア開発のあり方を考えられると思っています。
まだまだ途上、やるべきことはたくさんあります。もっと良いソフトウェア開発をするための手法を皆で考えていきたいですね。
毎回で恐縮ですが、そんな弊社もデベロッパーを募集しております...。そんなにハードル高くないのでご応募ください...。採用情報｜Growth xPartners Corporate Site
