アジャイル導入の移行シナリオ

日本でもアジャイル開発を適用するプロジェクトが少しずつ増え、アジャイル開発が普及してきました。その背景の1つに、ビジネス競争の激化があります。新たな製品やサービスをいかに早く市場に投入できるかで、ビジネス競争に優位に立てるかが決まることもあります。

しかし、ビジネス競争に勝つためのソフトウェアを早く作ると言っても、そのようなソフトウェアのニーズは不確定で、あらかじめ要求を予測するのが困難なことが多いでしょう。開発途上で要求が変化することも考えられます。

このようなソフトウェアの開発を考えたとき、ウォーターフォール型開発のような、開発の初期段階で要求を確定する手法で開発すると、開発が終わってリリースした時点には市場ニーズが変わり、無駄な機能を作ったことになった、というようなことも起こりかねません。

一方、アジャイル開発のメリットは、要求の変化に対応しながら開発できることです。アジャイル開発では、反復毎に動くものを作って実際に動かして検証し、機能を作り上げていくため、不確定なニーズに対処しながらソフトウェアを開発することができるのが特徴です。つまり、先に述べたビジネス競争に勝つためのソフトウェアを早く作るのにもっとも適した開発手法がアジャイル開発だと言えます。

アジャイル開発は、要求の変化に早く対応しながら開発する必要があるような状況で求められるでしょう。

これまで従来手法で開発していた組織やプロジェクトがアジャイル開発を導入しようとした時、さまざまな障壁によってアジャイル開発の導入をあきらめてしまう現場が中にはあるかもしれません。

アジャイル導入の障壁となるのが、従来手法とアジャイル開発のギャップです。従来手法と比較して、アジャイル開発は顧客の負荷、要求の不確定性と契約形態、要員の確保、品質管理の考え方が異なります。また、開発者の立場で言うと、従来手法にはなかった、反復と言う、一定の期間で開発を繰り返す進め方に対して抵抗感や不安がある場合もあり、これも導入障壁となるでしょう。

このようなアジャイル開発に対するニーズとアジャイル開発の導入障壁と言った現状と、当社のこれまでの経験に基づき、従来手法からアジャイル開発に移行する以下の2つのシナリオを考案しました。

• 「一気に導入」シナリオ
• 「一歩ずつ導入」シナリオ

各シナリオではこれまでの経験に基づいてオージス総研が考案したアジャイルに関する手法やフレームワークを組み合わせています。これらの組み合わせを当社ではアジャイル開発フレームワークOSAM（OGIS Scalable Agile Method）と呼んでいます。

要求の変化を受け入れながら早く開発することのニーズが強く、従来手法で開発を進めるのが難しい状況ではアジャイル開発を一気に導入するシナリオを提案します。

メンバーにはアジャイル開発のトレーニングを実施し、マルチタレントで変化に柔軟に対応できる開発者を集め、変化への対応力を付けることがポイントとなります。

アジャイル開発の導入では、具体的にはスクラムを実施しますが、スクラムがカバーしていない要求定義の具体的な実現方法、受け入れテストの実施を補うため、スクラムにアジャイル要求（DtoD）と受け入れテスト駆動開発（A-TDD）を組み合わせます。この組み合わせをOSAM2.0基本形と呼んでいます。

まずチーム単位でOSAM2.0基本形を実践し、これがうまくいけば次のステップとして、チームを超えたアジャイルの適用を行うためにSAFeを適用します。これをOSAM2.0の発展形と呼んでいます。

アジャイル開発を一気に導入するシナリオでも、トレーニングの実施、OSAM2.0基本形、OSAM2.0発展形と言った段階を踏む必要があるでしょう。

当社の経験では、アジャイル開発を導入し始めたときに役立つノウハウは、チーム間で似通っていることが分かっています。トレーニングでカバーしきれない実践レベルの細かなノウハウは、開発ガイドなどの形で、組織内で共有するのもアジャイル開発をうまく実践できる1つの方法だと考えます。

要求の変化への対応は最優先ではなく、従来手法とアジャイル開発のギャップに対する懸念が大きいような状況では、アジャイル開発を一歩ずつ導入するシナリオを提案します。

従来手法とのギャップの低減に注力し、段階的にメンバーを育成する目標を立て、反復に慣れることに焦点を置きます。要求の変化への対応などアジャイル開発によるメリットの享受は限定的にしてバランスを取ることがポイントです。

従来手法とのギャップを低減するには、従来手法で取られている以下のような進め方を反復開発と融合する方法としてアンカー留めスパイラルモデルを取り入れた反復開発を進めるとよいでしょう。

• 開発初期に要求の大半を確定してアーキテクチャを決める
• 要求とアーキテクチャがほぼ決まったら開発を進める
• 作業の途中にレビューを入れる
• システムテストや移行作業は開発終盤に行う

このようにギャップを低減しながら、まず、反復することに慣れ、顧客と開発チームが成功体験を共有して信頼関係を築くことを目指します。そして、以下のようなステップを経て、徐々に変化への対応力を増やしてアジャイル開発に移行していきます。

• 開発初期の要求を確定する割合を減らす
• 反復期間を短くする
• 開発メンバーの自律性を尊重する
• アジャイル技術プラクティス（継続的なインテグレーション、テスト駆動開発など）を導入する

これは、OSAM1.0の構成要素を段階的に導入することに等しくなります。

反復開発においても、一気に導入シナリオのところでも述べたように、複数のプロジェクトで共通するノウハウを開発ガイドとして蓄積し組織内で共有するのが有効です。

例えば当社の経験では、複数のプロジェクトが同じような要因によって生産性が低下しているケースがありました。一方、反復の経験を積んだメンバーが率いるプロジェクトでは、最初の反復で明らかになった問題点を次の反復で改善し、生産性と品質を上げたケースがありました。このような実プロジェクトの例をもとにしたノウハウを共有することで、反復開発に慣れないチームがより早く成功を体験できる可能性があります。

また、アジャイル開発を一歩ずつ導入する状況では、アジャイル開発に関連する管理者やユーザー部門の方にアジャイルの良さを共感してもらうことも必要でしょう。

• 従来手法からアジャイル開発への移行において、アジャイルへのニーズと導入障壁のバランスで2つのシナリオがある
  • 「一気に導入」シナリオ
  • 「一歩ずつ導入」シナリオ

• 「一歩ずつ導入」シナリオの第一歩として反復開発（アンカー留めスパイラルモデル）が活用できる。このシナリオで、反復に慣れながら「フィードバック」というメリットを活かし、小さな成功を積み重ねることができる。
• 「一歩ずつ導入」シナリオはOSAM1.0の構成要素を段階的に取り入れるという形で実現できる
• 「一気に導入」シナリオでもスクラムを補うものが必要であり、そのためにOSAM2.0が有効である
• アジャイルを導入した企業の全体像を提供するものとして、SAFe（Scaled Agile Framework）というものがある