前記のような技術的不確実性を抱え、新システムの開発とハードウェア・ソフトウェアスタックの検証を並行してプロジェクト推進する同社。検証の過程で設計に影響を与えるような変更が発生することが十分に見込まれる中では、プロジェクトの工程をフェーズごとに分割し、段階的に成果物を確定させていく、従来のウォーターフォール型開発では対処が難しいことが予想された。
このような状況下で、アークシステムが提案したのは、アジャイル型のスクラム開発によるプロジェクト推進である。
スクラム開発とは、プロジェクトを１～４週間程度の「スプリント」と呼ばれる短い期間で区切り、各スプリントの中で優先度の高いシステム要件から開発していく手法だ。システム要件は全て「プロダクトバックログ」と呼ばれるユーザーにとって価値のある単位に細分化され、規模の見積、優先度付けがなされる。スプリントを繰り返すごとに、ユーザーにとって価値があり、優先度の高い機能が出来上がることになる。また、この繰り返しの中で、システム開始時には気づかなかった要件やビジネス要求の変化に合わせてプロダクトバックログリストを絶えず洗練させ続けることで、ユーザーにとって真に価値あるものの開発に集中できる。
アークシステムの提案のポイントは、技術的不確実性への対処とシステム要件を等しくプロダクトバックログとして扱うというところにある。
技術的不確実性への対処が当初想定規模を超え、システム開発の進捗を圧迫しそうになった場合でも、顧客価値という一貫した基準で優先度を付け、対応可否を判断する。そうすることで、システム要件の開発を先送りしてでもリスクに対処するのか、それともある程度リスク対処したところでシステム要件の開発を優先するのか、プロジェクトが進行する中でも柔軟に対応することを可能にしたのである。
仮に技術的不確実性への対処が想定より膨らんでしまった場合に備え、金額・スケジュールのバッファを積んでおくのではなく、優先度の低いシステム要件を開発することを止めることで対応する。これまで、前工程の要件定義でユーザーと合意したシステム要件は全て提供することが当たり前であったA社にとって、システム要件に優先度を付けること、ましてやスコープアウトはなじみの薄い概念であったが、納期とコストを一定に抑えたまま、プロジェクトを推進できることが評価され、両社で協力してシステム開発にあたることとなった。
プロジェクト開始当初、アジャイル型の開発に不安を抱えていたA社であったが、プロジェクトの進捗とともに徐々に不安は解消されていき、安心感を得られたとの声をいただけた。それは、下記のような導入効果が実現したためであろう。
プロジェクト進捗の見える化
システム開発における進捗報告は、当初計画に対し今現在どの程度進んでいるのか進捗率で報告したり、課題一覧を共有したりする場となる。おおよそ1～2週間隔で行われるのが多いのではないか。
前記の通り、本プロジェクトにおいてはすべてが見える状態で進めたため、課題の発生や解決の状況は、定例の場を待たずに共有される。また、進捗状況もただの数字としてではなく、実際に動作するアプリケーションとして表現されるため、一目瞭然である。
受発注両社にとって納得感のあるプロジェクト進行
要件に対する認識の齟齬や、そもそものビジネス環境の変化による変更要望などは、ともすれば受発注両社の対立を引き起こす要因となり得る。本プロジェクトのように、大きな技術的不確実性がある場合、それをどちらがリスクとして背負うかで対立を引き起こすこともある。
スクラム開発を選択し、協力し合うチームとして信頼関係を深めつつプロジェクトを進めたことで、プロジェクト開始時には分からなかったユーザー要件が明らかになったり、技術的課題が持ち上がったりしても、対立するのではなく、協力して解決に当たることができるようになった。
結果として、大きな技術的不確実性があったにもかかわらず、本プロジェクトは当初想定したスケジュールとコストの範囲内で無事にカットオーバーを迎えた。本プロジェクトのように、事前に影響範囲を評価することが難しい不確実性を抱えたプロジェクトにとって、スクラム開発に代表されるアジャイル型のプロジェクト推進手法は特に有効ではないだろうか。