エンタープライズアジャイルは「アジャイル開発が大人になった姿」らしい

日経コンピュータ２０１４年５月号の記事にエンタープライズアジャイルの記事があったのでメモ。
ラフなメモ書き。

【参考】
日経コンピュータ2014.05.15｜HATのブログ

リックテレコム 書籍情報「ハイブリッドアジャイルの実践」

ハイブリッドアジャイル開発・変形WF型開発のプロセスパターン: プログラマの思索

【1】日本でもアジャイル開発の流れが来ている、という記事。
平鍋さんが「エンタープライズアジャイルについて、アジャイル開発が成熟した大人になったことの現れ」と評価している文章が興味深かった。

事例はいくつかあがっていた。
但し、佐野さんがおっしゃるように、IBMのRUP発のDADとSAFeの話が中心で、「ハイブリッドアジャイルの実践」本にあるような日本発の事例や運用ノウハウが紹介されていなかったのは残念かな。

僕は、RUPの案件に開発者として携わった経験があるが、正直、WF型開発と何ら変わらない印象を持っているので、RUPそのままでは日本には受け入れ難いだろうと思っている。

【2】記事を読んで、エンタープライズアジャイル、つまり、基幹系業務システムの開発にアジャイル開発を導入して成功させるには、少なくとも2点は抑えるべきポイントがあると思う。

一つ目は、全体見積りや開発スコープが未確定になりやすい問題をどのように解決するか。
もう一つは、請負契約と委任契約の2つの契約スタイルをどのように使い分けて契約すべきか。

【2－1】前者は、アジャイル開発では、頻繁にVerUpしながら機能を拡張し、品質を改善していく開発スタイルなので、全体見積りができず、開発スコープが未確定になりやすいこと。

普通は、ユーザ企業が年間の予算を立てて、その予算枠内で開発するから、最初に全体見積りが必要になる。
しかし、リーンスタートアップのように、まずはWebサービスをとにかく作って提供し、ユーザの反応を見ながら機能拡張していく開発スタイルは、基幹系業務システムの開発には流石に合わない。
ユーザ企業の情報システム部門からは、必ず、システムの全体見積りを問われるからだ。

また、最初に要件定義で、システム全体の開発スコープを確定させるわけではないので、開発スコープがあいまいになりやすい。
すると、スコープクリープという問題が発生しやすい。

そして、リーンスタートアップでは、最初にシステムのゴールを確定せず、状況に応じてゴールを変える。
しかし、基幹系業務システム開発では、ゴール不明のシステムは、投資対効果（ROI）を計測しにくい。
投資対効果を考え、数年先を見据えたビジネスモデルを提示しなければ、そのままでは受け入れ難い。

【2－2】前者の問題については、ハイブリッドアジャイル開発やウォータースクラムフォールという開発スタイルである程度解決されている。
すなわち、要件定義や外部設計のレベルまできちんとモデリングして、見積りや開発スコープを確定してから、アジャイル開発を実践する方が安全だ。

ウォータースクラムフォールのような手法は、大規模なWF型開発において、要件定義～外部設計や委任契約で作業して、外部設計終了後に再見積し、開発工程以降は請負契約で進めていく手法の考えとほぼ同じだと思う。
つまり、外部設計レベルまで実施しなければ、開発スコープの確定はできないのだ。

「ディシプリンド・アジャイル・デリバリー」「アジャイルソフトウェア要求」の本を立ち読みしただけにすぎないので完全に理解していないけれど、DADもSAFeも、ウォータースクラムフォールに似た開発スタイルのように感じた。

【2-3】後者の問題の本質は、アジャイル開発は本来、請負契約が向いているのか、委任契約が向いているのか、という話だと思う。

請負契約はSIに成果物責任があり、瑕疵担保責任も負う。
委任契約は、SIに成果物責任はなく、工数ベースの作業に過ぎず、作業報告書だけでSIがお金をもらえる。

普通は、アジャイル開発は委任契約が向いていて、成果物を明確に定義する請負契約は相容れないと言われていた。
日経コンピュータの事例でも、すべての開発作業を委任契約している事例もあった。

請負契約がソフトウェア開発者を苦しめている: プログラマの思索

しかし、僕は、本来はアジャイル開発は請負契約が向いていると思う。
つまり、1～数ヶ月のサイクルで請負契約を結んで、順次リリースしていくスタイルが向いていると思う。

アジャイル開発は工事進行基準と相性が良いという仮説: プログラマの思索

元々、アジャイル開発は現物主義だ。
1イテレーションないし1スプリントが完了した後には、必ず「出荷可能な成果物」が作られる前提だ。

イテレーションのサイクルで次々にリリースしていく「小規模リリース」こそがアジャイル開発の本質だ、と僕は思っている。
だから、1ヶ月で成果の出ない開発は、アジャイルではない。
つまり、1ヶ月でリリース対象の成果物が作れない開発はアジャイルではない、と思う。

リリースできる成果物があるからそ、ユーザもスプリントデモでレビューできるし、開発チームも、自分たちの作業や技術のフィードバックを得て、次のイテレーションへ改善していくことができる。

すると、1スプリントの単位で作る対象をスプリント計画時に立てて、開発スコープを確定しておけば、成果物責任のある請負契約を実現することもできるはずだ。
実際、Scrumでも、スプリント実行中の期間は、スコープは固定だ。途中からの割り込みは受け付けられないのが基本だ。

すると、1ヶ月単位の請負契約を小刻みに契約している開発スタイルがアジャイル開発に向いているのではないか、と思う。

しかし、「最初にシステム全体の見積りや開発スコープを確定できない」問題があるので、最初の数イテレーションは、要件定義と外部設計を行う期間を別途設けるのが現実的だと思う。

XPやScrumでも、新しいフレームワークなどの技術を検証したり、開発環境を整えるだけで成果物を出さないという、Zeroリリースないしアーキテクチャスパイクという特別なイテレーションを持つ。
だから、最初の数イテレーションは、新しいフレームワークやクラウド環境でプロトタイピング開発したり、要件スコープを概算見積もりできるレベルまで要件定義と設計を行うようにすると良いと思う。

【3】いわゆるハイブリッドアジャイル開発については、以前Blogで、考えられるパターンについて書いてみた。

アジャイル開発とWF型開発をハイブリッドにしたマネジメント・デザインパターン: プログラマの思索

ハイブリッドアジャイル開発・変形WF型開発のプロセスパターン: プログラマの思索

ハイブリッドアジャイル開発の中でも、ウォータースクラムフォールは一番使われる開発スタイル。
また、保守作業でも、上限となる工数をあらかじめ決めておき、実施中に要件の優先順位を入れ替えながら順次リリースしていく「リーンWF」というやり方もある。
「リーンWF」も請負契約でやりやすい開発スタイルだ。

他にも色々考えられると思う。

ハイブリッドアジャイル開発・変形WF型開発のプロセスパターン from akipii Oga