arclamp

ITアーキテクト 鈴木雄介のブログ

アジャイルが否定したものを見直そう

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