"エンタープライズアジャイル” という分野（市場）が登場したのは、まだこの2-3年のことと思います。言わんとしていることは何となくわかるのですが、受け手にとって思い描くイメージが少しずつ異なっているようです。そのため、営業の場でこのキーワードを説明しても、話が噛み合わないこともしばしばです。
そこで私なりに、このキーワードの本質を解釈することを試みます。最初は「いやいや、そうではないよね？」という誤解から並べてみました。
誤った用法
仕様が決められない案件はエンタープライズアジャイル
ユーザが「仕様を決められない」ことの免罪符として使う意図が込められたケースです。仕様が決められないことがダメだということではなく、トライ＆エラーで開発する案件であると（ユーザと開発者の間で）合意をとりつつ、ユーザも主体的に仕様策定に関わる体制づくりにつながれば良いのですが、単にあとはよろしくという丸投げにつながるのであれば、まったく本来の解釈からずれていると言わざるを得ません。
安くあげたいからエンタープライズアジャイル
エンタープライズアジャイルなら安くなるんだよね、という誤解は数万年前に絶滅したと思っていましたが、実際はまだまだそうではないようです。開発方式と、価格算定方式はもちろん別の話です。
ウォーターフォールのプロジェクト成功率は低いが、エンタープライズアジャイルは高い
エンタープライズという冠をはずして、そもそもアジャイルには早い段階で失敗を重ねることで、答えのない「正解」をみつけるプロセスが含まれています。プロジェクトの最後で失敗を悟る（認める）のではなく、早い段階で方向性を変えることを良しとする企業文化とセットなのですが、この点を理解しないまま「率」だけを追うと火傷をすること必定です。
ウォーターフォール型開発にアジャイルのメリットを取り入れたい
上で述べた「誤解」を取り除いたとして、ではエンタープライズ開発のマネージャ層が期待することは何かといえば、もちろんアジャイルという言葉そのものがもつ「俊敏性」つまり「開発スピード」を上げたい、という点に集約されるといっていいでしょう。現在のエンタープライズ開発分野には俊敏性が足りないので、アジャイル文化を取り入れることで俊敏性を高める、つまり開発スピードを上げるというのがゴール、となります。
それではいよいよ、成功している（他社の）アジャイル開発チームが、俊敏性を高く保つために行なっているメソッドを（我が社の開発チームに）取り入れたいと考えたとき、何からはじめようか、ということになります。壁一面にタスクリストを書き出す？ 毎朝、ミーティングする？ それともアジャイル界隈で有名な各種のツールを導入する？ アジャイルを成功に導くコーチを招聘する？
このようなアプローチでの成功例として、若手エンジニアを中心としたベンチャー企業や、大手企業でもWebサービスを開発しているチームの話などは、よく目にします。しかしガチのエンタープライズ開発でアジャイル的な要素を取り入れているという事例はなかなか登場しません。それはなぜでしょうか。
エンタープライズ開発の文化とアジャイルの文化は、そもそも土台が違います。エンタープライズ開発では、仕様を大きく削減したり、段階的にリリースすることが難しいのが一般的です。作る内容はほぼ明確で削減の余地は乏しく、また周辺システムとの運用連携のため、いつまでにこの内容を一気にリリースしないといけない、ということを決めておかないといけません。そのような文化にアジャイル性を持ち込むというのは、明治維新の頃の「和魂洋才」に匹敵するような、アクロバティックな取り組みが求められます。つまり難易度が高いのです。
難易度の高いテーマに取り組むときには、成功と失敗をわける分岐点 - 少なくとも、これを達成しないといけない、という本質的な何か、を最初にモノにすることです。そこを押さえれば、あとは好循環サイクルに入ることができます。最初の歯車をみつけ、それを一回転させることが重要です。
ここで私が考えるエンタープライズアジャイルの本質を述べます。それは「少人数で大規模システム開発を行う体制」です。
成功しているアジャイル開発事例は例外なく、少人数のチーム構成です。一方、エンタープライズアプリケーション開発には、多くの開発者が関わるというイメージがあります。関係者の数が増えるほどコミュニケーションコストが増大し、誤解を防ぐための資料作成コストが膨らみ、全体の意思統一は遅れます。そのためにコミュニケーションツールを導入しよう、というのは対症療法でしかありません。本質的には、少人数のチームで大規模なエンタープライズアプリケーション開発を行う「仕組み」づくりが不可欠です。
この仕組みをもう少し噛み砕いてみていきます。次のようなことができれば合格でしょう。
- 少人数のチームで、組織全体の「データ」と「プロセス」を把握できている。
- 新システム開発と、既存システムの変更作業に差がない。新規開発も既存更改も、基本的には同じ開発プロセスであり、関わる人も同じである。
- 開発と運用にも差がない。つまり同じチームで開発と運用の双方に関わっている。
- ドキュメントはもちろん存在する。そのドキュメントと、稼働するシステムは完全な整合性がとれており、ドキュメントが古いということは仕組み上、ありえないようにする。
- 開発（更改を含む）の結果をすぐに本番リリースできるよう、デグレードがないかどうかのテストは自動化されている。
ここで述べた内容はほぼ、アジャイルを実践するチームにとって目新しいものはないはずです。すなわち “エンタープライズな" アジャイルとは「少人数で大規模開発を行う体制を基盤としているか」と言い換えることができる、というのが私なりの解釈です。
仕組みづくりは掛け声ではなく技術が必要
ではトップダウンアプローチで、これからは少人数で大規模開発を行うように、などと指示すれば現場は大混乱に陥るだけです。これは昨今の"働き方改革”の議論に似ています。仕組みをつくるには、それを支える技術が必要不可欠です。技術的な裏付けのない、掛け声だけのアプローチはその場限りであり、決して根付くことはありません。
超高速開発という分野の存在意義は、まさにこの点にあります。少人数で大規模開発を行うためには、最低限、システムの設計情報と実際のソフトウェアの整合性を完全に担保できる「仕掛け」が必要です。言い換えると現在のエンタープライズ開発が少人数でなしえないのは、設計情報があまりにも人間寄りの表現で記述されているため解釈の幅があり、これをソフトウェア化することに時間（工数）がかかりすぎるためです。
超高速で開発する、というのは、魔法ではありません。設計情報の記述を標準化し、そこからソフトウェアを生成するという技術を土台にすることで成し得るだけのことです。タネも仕掛けもわかってしまえば当たり前のことですが、よく考えてみると "エンタープライズアジャイル” というキーワードの実現にはうってつけの技術体系であることがわかります。
まとめますと、ある種のキーワードはゴールを示しますが、その道程はさまざまです。しかしこれを気合いと根性で達成するのではなく、技術、それもソフトウェア技術を組み合わせることが現代では不可欠です。それが「（現代は）ソフトウェアの時代である」という解釈につながっています。
今回は "エンタープライズアジャイル” というキーワードを考察しました。ゴールは「開発スピードを上げる」ですが、そのためには「少人数で大規模システム開発を行う体制」づくりが必要であり、そのための仕掛けとして「超高速開発」という技術はうってつけである、というのが私の持論です。
