これまでの活動内容テーマ別解説エンタプライズ系事業/非ウォーターフォール型開発

本文を印刷する

エンタプライズ系事業/非ウォーターフォール型開発

ビジネス環境の変化への迅速な対応

ウォーターフォール型でないソフトウェア開発手法、すなわち、アジャイル開発など「非ウォーターフォール型」の開発手法は、日本国内のソフトウェア開発においても、WebアプリケーションやWebサービス開発などを中心に広がり、
  • 競争力のある製品およびサービス開発
  • 顧客ニーズへの迅速な対応
  • 開発者、技術者のモチベーション向上
等に成果を上げています。
IPA/SECでは、「非ウォーターフォール型」開発手法の成果の源を分析し、その適用領域や適用方法について整理するための検討に取り組んでいます。この検討の結果として、日本のソフトウェア産業全体が同様の成果を享受できるようになることを期待しています。
平成21年度に、「非ウォーターフォール型開発研究会」を設置し、非ウォーターフォール型開発に関する調査結果に基づき、我が国における非ウォーターフォール型開発の活用に向けた課題を抽出しました。平成22年度以降、それらの課題についての検討と検討結果の検証を行っています。これらの活動内容は、報告書として公開しています。

アジャイル型開発に注目される背景

現状のソフトウェア開発を取り巻く、次の課題項目が挙げられます:
(1)ビジネス・ニーズへの適切な対応
(2)(純粋な)ウォーターフォール型開発における問題点
(3)ソフトウェア産業構造(多重下請構造)上の課題
これらの課題を解決する一つの方法として、アジャイル型開発が注目されています。

アジャイル型開発への期待

ウォーターフォール型のソフトウェア開発では、品質の高いソフトウェアを生産性高く開発するために、開発初期に要求の固定をはかり、ドキュメントの形で仕様を形式化してソフトウェア・エンジニアリング的な開発モデルに乗せようと努力してきました。しかし、そもそも要求が刻々と変化している場面では、要求を固定すること自体が製品やサービスの販売リスクを拡大してしまう場合が多いのです。また、開発の中には技術リスクが大きく、実際に作ってみないとそのリスクを解消できない場合があります。
このような状況においては、従来のウォーターフォール型ではない、別のソフトウェア開発モデルが必要とされてきています。そのような「非ウォーターフォール型」のソフトウェア開発モデルの代表として、アジャイル型開発が注目されています。

アジャイル型開発に関する検討の意義

ウォーターフォール型開発は、高信頼性が求められる基幹システム等、過去のほとんどの分野で実績があります。これに対し、非ウォーターフォールの一つであるアジャイル型開発は、情報システムを市場へいち早く提供していくことに価値があると考えられる分野に向いています。特に、開発形態が多様化している後者の分野において、非ウォーターフォール型開発の適用に適した領域を見定め、その活用を促進していくことが必要です。
また、現在、非ウォーターフォール型開発があまり適用されていない領域においても、その特質を明らかにすることにより、今後の適用を検討していくことは有意義です。

アジャイル型開発の検討により期待される効果

  1. 日本のソフトウェア産業の実態に適しており、かつ世の中のパラダイム転換に対応することのできるソフトウェアの作り方の提案になります。
  2. グローバルな視点から見た、わが国のソフトウェア産業の競争力を強化することにつながります。
  3. 優先度の高い機能が順次提供され、提供された機能を検証・投入することにより、変化が激しく、優先度も変化するビジネス環境に対応できるサービスやシステムを手に入れられます。
  4. エンジニアが自分自身の成長を実感でき、開発したシステムが利用者の役に立っていると実感できることにより、エンジニア一人ひとりが生き生きと働くことのできる環境の整備につながります。

アジャイル型開発の特徴

アジャイル型開発は、不確実なビジネス環境の中で変化するニーズへの迅速な対応を目的としたソフトウェア開発手法であり、次の特徴を有します。
  • 顧客の参画の度合いが強い
  • 動くソフトウェアを成長させながら作る
  • 反復・漸進型である
  • 人と人のコミュニケーション、コラボレーションを重視する
  • 開発前の、要求の固定を前提としない

アジャイル宣言における4つの価値

2001年、アジャイルな開発手法の提唱者17名が集まり、次のアジャイル宣言(Agile Manifesto)を発表しています。

私たちは、ソフトウェア開発の実践を手助けする活動を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは以下のことを重視する:
(1)プロセスやツールよりも,個人と対話を
(2)包括的なドキュメントよりも,動くソフトウェアを
(3)契約交渉よりも,顧客との協調を
(4)計画に従うことよりも,変化への対応を
すなわち、(1)~(4)の各文の前者(「よりも」の前の言葉)に価値があることを認めながらも、私たちは後者(「よりも」の後の言葉)の事柄により価値をおく。

日本でのアジャイル型開発の現状

多くの調査結果は、日本ではあまりアジャイル型開発が行われていないことを示しています。これに対して、米国では、50%以上のソフトウェア開発にアジャイル型開発手法を用いているという調査結果があります。
こうした中で平成21年度に実施した調査において、我が国における22個のアジャイル型開発の事例を収集し、分析・整理しました。その内容をまとめると、次の通りです:
  • 開発チーム:約8割が8名以下 (1例を除き、12名以下)
  • 開発期間:半数は2か月~4か月
  • アジャイルのプラクティス群の中から取捨選択して用いている
  • 内部開発が多い(自社内で利用するソフトを内製,販売するためのパッケージの開発)
  • 受託開発の例では、既存システムの更改および新規案件
  • 効果:要求の変化への柔軟な対応,市場への投入の迅速化
  • 生産性の改善分は、品質や保守性の向上へ
  • 大手SI業者でも、トライアルが行われ、社内標準への取込みが始められている
  • ウォーターフォール型との使い分け
  • 成功体験のウォーターフォール型への取り込み

顧客・経営層への理解促進

適切な領域においてアジャイル型開発手法を活用するためには、顧客・経営層の理解が必須となります。

アジャイル型開発の適用領域・試行領域

すべてのソフトウェア開発にアジャイル型開発手法を適用できる、あるいはすべきだ、という立場ではありません。ビジネスや市場、その他の開発の文脈によって、ウォーターフォール型の開発が適している場面もあれば、アジャイル型の開発が適している場面もあります。
 大まかには、開発当初に要求を確定せず、ビジネス環境の変化に伴った市場や顧客ニーズの変化への対応が最優先される分野が、アジャイル型開発が最も得意とする第一適用領域と言えます。他方、基幹システム等で開発当初に要求をあるレベルで確定可能(あるいは確定すべき)な領域のシステムの開発においては、現在のアジャイル型開発は試行領域となっています。
具体的には、アジャイル型開発は、「顧客の参画の度合いが強い」、「動くソフトウェアを成長させながら作る」、「反復・漸進型である」、「人と人とのコミュニケーション・コラボレーション重視」、「開発前の仕様の固定を前提としない」等を特徴とするため、以下の領域での開発を得意とします:

(1)ビジネス要求が変化する領域
  • 要求の変化が激しく,あらかじめ要求が固定できない領域。
(2)リスクの高い領域
  • 不確実な市場を対象としたビジネス領域(市場リスク)
  • 技術的な難易度が高い開発領域(技術リスク)
(3)市場競争領域
  • 他社に先駆けた製品・サービス市場投入が命題であり、TTM(Time to Market)の短縮が優先となる領域(Webのサービス,パッケージ開発,新製品開発)。
    一方、以下の領域においては、アジャイル型開発による経験が十分には蓄積されておらず、現在、チャレンジと創意工夫が求められています:
  • 大規模開発
  • 分散拠点(オフショア含む)開発
  • 組織(会社)間をまたぐ開発チームによる開発
  • 組込みシステム開発

中大規模プロジェクトへの適用

平成23年度に実施した調査において、我が国における中・大規模な開発にアジャイル型手法を適用した事例を10個収集し、分析・整理しました。 それらの開発において工夫された事項は、次のようにまとめられます。


拡大画像はこちら

顧客・経営層は開発への一層の関与が必要

<顧客(ユーザ)経営層>
ビジネス環境が激しく変化する現状において、ITシステムに関し、従来のように情報システム部門に任せきりでは適切に対応できません。開発形態(*1)にも深く関与する責任(*2)があります。

(*1) アジャイル型開発の採用,クラウドコンピューティングの利用、など
(*2)・情報システムに関する理解の増進
         ・迅速かつ適切な意思決定
         ・関係部門との経営上の綿密な調整

<ベンダ経営層>
俊敏な開発の実績を武器に受注を狙う海外勢等に対抗するためには、自ら俊敏な開発を実施できる体制作りに取り組むと共に、その結果を顧客に売り込む必要があります。

顧客・経営層が開発上で考慮すべき点

  • 顧客・経営層は、アジャイル型開発の採用を決断した時点で、顧客がチームの一員として参画し、タイムリーな意思決定を行い、品質や進捗状況の把握等に関し、主体的に開発に関わらざるを得ないということに十分な理解と覚悟を持つこと。
  • アジャイル型開発においては、反復の都度、コードを書き変えていくスタイルが採られるため、品質に重大な悪影響が及ぶかどうかの観点での、プロダクト品質の見える化が必要なこと。
  • アジャイル開発の特徴に応じた「見える化」項目を用いて開発プロジェクトとの円滑なコミュニケーションを図り、アジャイル型開発の採用の本来の目的が損なわれないように努めること。

アジャイル型開発のための技術・スキル

非ウォーターフォール型開発にとって重要なスキルとして、以下が挙げられます:
  • プロジェクトのアウトプットに関わる判断ではなく,アジャイル型開発の進め方を踏襲させるためのファシリテーションスキル
  • 反復活動の中で,実際に動くものを作りながら,小規模に,かつトータルにプロジェクトのアウトプットを積み重ねていくスキル
  • 設計,コーディング,テストを一貫して実施出来るスキル
これらのスキルを身につけるためには、アジャイル型開発の価値(及び原則)の理解が必須であり、プラクティスの全てを完全に身につけるより,価値に従って行動する習慣を確実に身につけることが重要です。

日本におけるアジャイル型開発にふさわしい契約モデルの提案

アジャイル型開発には、ウォーターフォール型開発と比較し、次の特徴があります:
  1. ユーザとベンダの緊密な協力体制が必須
    - 相手方の問合せへの迅速な応答
    - 担当作業の迅速な実施
    - ユーザ/ベンダ間の責任分担が不明確になりがち
  2. ユーザ要求の詳細が契約時点では未確定
    - 何を作るか決まっていない(成果物未定)
    - 性能・品質等が不明確
    - 工数見積りが困難(コスト未定)
  3. 開発途中でのユーザ要求の変化を柔軟に受け入れる必要
    - 決定した事項も変更されることがある

すなわち、そもそも「契約」とは、合意内容を固定して、当事者を法的に拘束するものであるのに対し、アジャイル型開発は、変化に対応すべく、合意内容の変更を柔軟に認め、当事者をなるべく拘束しないという特徴を有することから、「契約」とは相容れないことになります。
したがって、開発内容が決まっていない段階で、開発プロジェクト全体につき、一つの請負契約を結ぶのは適切ではありません(何をいくらで完成させるか不明です)。他方、開発プロジェクト全体を準委任契約にすることは、ベンダが完成義務を負わない点で、ユーザ側に不安があります(たとえ成果物が完成しなくても、ユーザは対価を支払う必要があります) 。また、アジャイル型開発の特徴であるユーザとベンダの協働関係を、契約に取り入れる必要があります。
このような状況に対し、IPA/SECでは日本におけるアジャイル型開発にふさわしい契約モデルとして、次の2つを提案しています。

基本/個別契約モデル

プロジェクト全体に共通する事項につき、基本契約を締結し、小さな機能単位ごとに、開発対象と費用がある程度確定したタイミングで個別契約(請負/準委任)を順次締結します。


拡大画像はこちら

組合モデル

ユーザとベンダが共同でジョイント・ベンチャーとしての「組合」を組成し、協力してシステム開発(収益性のあるもの)を企画・製作する(開発された成果から得られた収益は、ベンダとユーザに分配される)ものです。


拡大画像はこちら

アジャイル型開発手法の導入に向けて

アジャイル型開発手法を導入する際のポイントは、次の通りです:
  1. 適切な開発手法の選択
    開発対象の特徴や開発組織の置かれた環境などを加味しつつ、適切な開発手法を選択する・新たに考案する
  2. プラクティスの活用
    それぞれのプロジェクト・組織(企業)で、自らの開発に合った方法を、プラクティスを選択あるいは参考にして利用する
  3. 開発手法に対する正しい理解の促進
    プラクティスの意図やプラクティスが提唱されている背景についても理解を深める
ただし、「銀の弾丸はない」ということを肝に銘じておく必要があります。すなわち、実践現場でのたゆまない問題解決の積み重ねを続けることが最も重要です。
プラクティスの利用については「プラクティスリファレンスガイド」WORD文書をご参照ください。

報告書・セミナー・イベントの紹介

活動報告書・調査報告書
最近のセミナー資料
最近のイベント
主なリンク

テーマ別解説