オブジェクトの広場はオージス総研グループのエンジニアによる技術発表サイトです

アジャイル

SAFe (Scaled Agile Framework) 3.0 入門 (第1回)

アジャイル開発が生まれた背景とその特徴
株式会社オージス総研 技術部アジャイル開発センター
藤井 拓
2014年3月6日

欧米では、現在日本のソフトウェア開発プロジェクトの多くで使われているウォーターフォール型開発からアジャイル開発への移行が進んでいます。本連載では、アジャイル開発を活用して競争力のあるプロダクトを開発する企業や事業部のあるべき姿を示すSAFe (Scaled Agile Framework) [1]、[2]というフレームワークの概要を紹介します。まず第1回目は、SAFeの基盤となるアジャイル開発が生まれた背景とその特徴を説明します。なお、本記事の後半で過去の記事の内容を再利用していますが、その点をお許し下さるようにお願いします。

1. アジャイル開発が生まれた背景

ウォーターフォール型開発は、図 1に示すように要求を開発初期段階に確定し、確定した要求に基づいて設計、実装、統合、テスティングを順次的に行う形の開発方法です。ウォーターフォール型開発は、日本のソフトウェア開発プロジェクトの半分以上で採用されており、未だ大勢を占めています。

図 1 ウォーターフォール型開発

ウォーターフォール型開発には以下のような長所があります。

  • 開発依頼者側の計画、契約の負荷（リスク）が小さい
    • 開発初期段階に確定した要求に基づいて計画や契約を締結すれば、要求の実現の責任をITベンダーに転嫁できる
  • 分業が可能
    • 開発を複数フェーズに分けて、フェーズ間で文書による引き継ぎを行うことでフェーズ毎に異なる開発者（役割）による分業が可能になる

この「分業が可能」という長所を利用して、日本ではソフトウェア開発において複数の階層にも及ぶアウトソースという形態が一般化しました。また、フェーズ間での引き継ぎのために作成される文書をレビューすることで品質を管理するというアプローチも広まりました。

一方で、ウォーターフォール型開発の短所として以下のような点を挙げることができます。

  • 要求確定後の仕様変更が困難
    • 要求確定後に技術やビジネス状況の変化やビジネスニーズの理解が進んで要求を変更したいと望んでも、対応は次バージョン以降になる
  • 開発上の問題点が開発終盤に顕在化して遅れる
    • 統合段階やテスト段階でアーキテクチャー上の問題やサブシステム間のインタフェースの不整合などの問題が顕在化して納期が守れない

「要求確定後の仕様変更が困難」という点に付随する問題として、「文書で書き表した要求では要求の有効性が判断できない」というものがあります。つまり、開発依頼者が明確に要求を述べられる場合を除いては「要求」がITベンダー主導で決められていき、その結果として「本当のニーズとはかけ離れたソフトウェアが納品される」ような事態に陥る危険性があります。つまり、ウォーターフォール型開発には「ビジネス価値が低いソフトウェアが開発されてしまう」というリスクがあります。また、「開発終盤に開発上の問題点が顕在化して遅れる」ことで結果的には「納期が守られないことで、そのソフトウェアの運用開始が遅れてビジネス上の損害が生じる」ような状況も現実には発生します。つまり、実際には「計画や契約に伴うリスクが高い」こともありえるのです。

これらの長所と短所を考えると、開発依頼者にとってウォーターフォール型開発の長所が発揮できるのは以下のような場合だと考えられます。

  • 要求が開発初期に確定できる
  • アーキテクチャーやサブシステム間のインタフェースの不整合などのリスクが低い

欧米ではウォーターフォール型開発を適用するプロジェクト割合が半分以下に低下し、アジャイル開発を適用する割合が増えているということも報告されています。欧米でウォーターフォール型開発が減少している原因として以下のようなものが考えられます。

  • ビジネスや技術の変化にすばやく対応するための開発が求められている
  • ユーザー企業がある程度開発要員を抱えている

Google社やSalesForce社のようにクラウドでビジネスを展開する企業も、Apple社のようにハードウェアデバイスやソフトウェアでビジネスを展開する企業も、Amazon社のような販売でビジネスを展開する企業も競争に勝つために「ビジネスや技術の変化へのすばやい対応」を重視しています。「ビジネスや技術の変化への対応」というのは以下のことを意味します。

  • ビジネス形態（モデル）や市場の変化に対応する
  • 新たな技術（IT機器）を組み込んだり、移行したりする必要がある

これらの「ビジネスや技術の変化」を事前に予測するのは不可能に近いと言えます。しかしながら、変化に対応した製品やサービスを早く市場に投入しないと高い利益を得ることができません。このような状況に対応するためは、「ビジネスや技術の変化」に柔軟かつスピーディーに対応して開発することが求められます。その結果として、ウォーターフォール型開発からアジャイル開発への移行が進んでいると考えられます。

また、同時に欧米では自社で開発要員を抱えている場合が多いために日本ほど「開発委託側の計画や契約の負荷（リスク）」に対処する必要はありません。つまり、計画や契約という敷居が低いこともウォーターフォール型開発からアジャイル開発への移行が欧米で進んでいる理由になっていると考えられます。

2. アジャイル宣言

90年代の終盤に、顧客と開発者との密な協力に基づいて、顧客に役立つソフトウェアをすばやく開発する手法としてXP(eXtreme Programming) [3]やスクラム[4]などの複数のアジャイル開発手法が登場しました。これらのアジャイル開発手法の提案者達は2001年に集まり、アジャイル開発が共有する価値や原則をアジャイル宣言[5]という形でまとめました。アジャイル宣言の価値は、以下の 4 つの項目で構成されます。

  • プロセスやツールよりも個人や相互作用
  • 包括的なドキュメントよりも動くソフトウェア
  • 契約上の駆け引きよりも顧客とのコラボレーション
  • 計画を硬直的に守るよりも変化に対応する

これらの各行で下線を引いてある右側の部分を左側の部分より重視するということが価値として宣言されたのです。また、アジャイル宣言には、さらに以下のような原則が付随しており、この宣言が推奨している開発の進め方をより具体的に説明しています。

  1. ソフトウェアの早期、継続的な納品により、顧客の満足を達することが最優先である。
  2. 開発の終盤であろうとも、要求内容の変更を歓迎する。アジャイルなプロセスは、顧客の競争上の優位性のため、変化を制する
  3. 数週間から数ヶ月間のサイクルで動作するソフトウェアを納品する。サイクルは短い方が良い
  4. ビジネス側の人間と開発者がプロジェクトを通じて日々協力をしなければならない
  5. 志の高い開発者を中心にプロジェクトを編成する.必要な環境や支援を与え、任務をやり遂げることを信じなさい
  6. 開発チームの内外でもっとも効率的で効果的な情報伝達を行う手段は、顔をつき合わせて話し合うことである
  7. 動作するソフトウェアが主たる進捗の確認手段である
  8. アジャイルなソフトウェア開発は、持続的な開発を促す。開発資金の提供者、開発者、ユーザは、必ず一定のペースを守れるべきである
  9. 技術力と良い設計に絶えず気を配ることで、機敏さは向上する
  10. 不必要なことを行わない技能である簡潔さは、本質的である
  11. 自己組織化されたチームから最善のアーキテクチャー、要求、設計が生まれる
  12. 定期的に、チームはもっと効果的になる道を考え、開発の進め方を調和させ、調整する

アジャイル宣言の原則の内容を大別すると、以下の 5 点にまとめることができます。

  1. チームのあり方: 5, 6, 8, 11, 12
  2. 個人の心構え: 9, 10
  3. 動くソフトウェア: 1, 3, 7
  4. 顧客とのコラボレーション: 4
  5. 変化への対応: 2

A と B は、アジャイル開発の価値である"個人や相互作用"を個人に関する原則とチームに関する原則に分解したものです。アジャイル宣言の1、3、7 の原則は反復的な開発アプローチに関するものです。そのため、"動くソフトウェア"の価値と対応すると考え、C に分類しました。さらに、D と E は顧客のニーズの変化に即応した開発を行うことであり、 顧客本位のソフトウェア開発を行うという方向性を示すものです。

これらの原則から、アジャイル開発にとって"顧客のニーズの変化に即応した開発"が大きなテーマであり、A と B と C がその実現手段だといえます。すなわち、顧客のニーズの変化に即応するためには、一定の作業内容や作業手順に従うだけでは不十分であり、機動性に富んだチームと個人の自律性が必要になるということです。

3. アジャイル開発手法

3.1. アジャイル開発手法の特徴

前節で紹介したアジャイル宣言の原則に述べられているアジャイル開発の特徴を開発手法という観点でまとめ直すと、以下の4点になります。

  1. 反復的な開発
  2. 顧客との連携
  3. チームワークの重視
  4. 技術的な裏付け

A は、１週間から１ヶ月程度の一定の周期で動くソフトウェアを作るという形で開発を進めるということです。この動くソフトウェアを作る１回の周期のことを「反復」と呼びます。A については、反復の期間が固定であることを強調する「タイムボックス」という言葉で表現することもあります。

B は、顧客と連携して顧客のビジネスの成功につながるソフトウェアを作るということです。顧客がソフトウェアに求めることは、顧客を取り巻く状況の変化等により開発途上で変化しえます。このような変化を反復単位で顧客からのフィードバックとして受け、計画に取り込むことで、顧客のビジネスの成功につながるソフトウェアの開発を行うことができます。

C は、開発チームのメンバーの自律性や直接的なコミュニケーションを重視したチームの運営を行うということです。開発チームのメンバーの自律性という点では、従来のような縦割りで計画や作業の割り当てを行い、メンバーが与えられた計画や割り当てを行うというのではなく、開発チームのメンバー間の話し合いで計画や作業の割り当てを決めるということです。このように自律性を尊重することで、開発メンバーのモチベーションが高まり、より良い仕事のやり方を考える改善マインドが生まれます。

D は、要求の変化の結果としてソースコードの変更が発生するが、そのソースコードの変更のコストをなるべく抑えるような技術的な工夫（プラクティス）を講ずるということです。アジャイル開発で広く使われている技術的なプラクティスとしては、以下のようなものがあります。

  • テスト駆動開発（TDD: Test Driven Development）[6]
    • プログラムコードを書くときに、そのコードを検証するための単体テストコードを先に書き、そのテストコードに合格するようにプログラムの本体コードを書く（テストファースト）。作成された単体テストコードにより回帰テストが自動化されるため、以降の開発でコードの変更や改良を安全かつ低コストで行う事ができる。
  • リファクタリング[7]
    • 既に書いたプログラムコードの機能を保ったまま、プログラムコードの品質を高めるための改良を行うこと。コードを改良することで、１カ所のコードの変更が多くの箇所に波及しないようにする。
  • 継続的なインテグレーション (CI: Continuous Integration)
    • 各開発者が開発した本体コードとテストコードが蓄積された構成管理ツール内のコードを自動的にビルドし、テストコードを自動実行し、それらの結果を開発メンバーに通知するというもの。このような環境を構築することで、コード状態を全員で共有し、不具合を起こすような変更を加えた場合に、それをすばやく検出し、低いコストでコードを修正することができるようになる。

これらのプラクティスにより、加えたプログラムコードの変更による回帰エラーの発生をすぐに検知したり、プログラムコードの変更が広範に波及しないようにプログラムコードの品質を高めることが可能になります。このような回帰エラーの迅速な検出やプログラムコードの品質向上によりソースコードの変更コストを削減することができ、アジャイル開発に求められる変化への対応が実現できるのです。

技術的な裏付けは表から見えにくく、理解しにくいかもしれない特徴ですが、これを怠ると開発が進むにつれて開発の生産性が低下したり、コードの保守性やその他の品質が低下する危険性があります。

3.2. スクラム

スクラムの価値

スクラムは、Ken Schwaber とJeff Sutherland、 Mike Beedle によって考案されたアジャイル開発手法です。 スクラムという開発方法論の名称は, ラグビーのスクラムにちなんで名づけられました。 スクラムは、野中先生達が80年代に日本の製造メーカーの新製品開発において欧米のメーカーを凌駕した要因の研究をまとめた「知識創造企業」 [8]などに触発され、Schwaber らがいくつかの失敗プロジェクトを立て直す経験を通じて生み出されたものです。

スクラムは、他のアジャイル開発手法と同様に動くソフトウェアを順次作り、そのソフトウェアを発展させながら開発を進める反復的な開発アプローチに基づいています。アジャイル開発手法は一般的に開発チームで共有すべき価値や作業の指針となる原則やプラクティスで開発の進め方を定めていますが、スクラムが定めている価値は以下の 5 点です。

  • 確約 ( Commitment )
    • 約束したことを確実に実現すること
  • 専念 （ Focus )
    • 確約したことの実現に専念すること
  • 隠さない ( Openness )
    • たとえ自分にとって不利なことでも包み隠さないこと
  • 敬意 ( Respect )
    • 自分と異なる人に敬意を払うこと
  • 勇気 ( Courage )
    • 確約し、隠さず、敬意を払うために勇気を持つこと

筆者は、スクラムを書籍で初めて学んだときにこれらの価値に共感したのですが、スクラムコミュニティーでは現在これらの価値が示されていないような気がします。その点が個人的に残念です。

スクラムでは、このような価値以外にも開発の進め方や開発チームにおける役割についても言及していますが、言及している範囲はプロジェクト管理作業に偏っています。 スクラムは、プロジェクト管理的な作業に特化しているため、XPや統一プロセス(UP)など設計、実装、テストの実践形態を規定している様々な反復的な開発手法と組み合わせやすい開発手法です。

スクラムにおける開発の進め方

スクラムでは、 1 週間から 4 週間のサイクルで動くソフトウェアを作りながら開発を進めます。 図 2は、スクラムによる開発の流れを示したものです。図中の用語の意味は、以下の通りです。

図 2 スクラムにおける開発の流れ
図 2 スクラムにおける開発の流れ
  • プロダクトバックログ: 開発対象のソフトウェアに対する要求のバックログ
  • スプリント: 1週間から4週間サイクルの反復
  • スプリント計画ミーティング: スプリントの開発目標 ( スプリント目標 ) とスプリントバックログを設定するミーティング
  • スプリントバックログ: スプリント目標の達成に必要なタスクのリスト
  • デイリースクラム: 日毎の進捗確認ミーティング
  • 実行可能なプロダクトのインクリメント: スプリントの結果として作成される実行可能なソフトウェア

図 2 に示されている標準、規約、ガイドラインは、開発組織において守ることが求められている標準、規約、ガイドラインを意味します。

スクラムでは、開発は以下のようなステップで進行します。

  1. ソフトウェアに要求される機能とその優先度をプロダクトバックログとして定める
  2. プロダクトバックログからスプリントで実装するべき目標（ スプリント目標 ）を選択する
  3. スプリント目標をより詳細なタスクに分解したスプリントバックログを作成し, タスクの割り当てを行う
  4. スプリントの間, 毎日決まった場所及び時間で開発メンバーが参加するデイリースクラムというミーティングを開催する
  5. 1 回のスプリントが終了すると, スプリントレビューミーティングを開催し, 作成されたソフトウェアを評価する
  6. 開発メンバー全員で完了したスプリントに対する振り返りを行う
  7. 次回のスプリントに備えてプロダクトバックログの内容と優先度の見直しを行う

図 2のスプリント計画ミーティングは、2、 3 の 2 ステップとして実行されます。

スクラムでは、一般の開発メンバーに加えて以下の 2 つの管理的な役割が定義されています。

  • プロダクトオーナー: プロダクトバックログを定義し, 優先度を決める人
  • スクラムマスター: プロジェクトが円滑に進むように支援する人

スクラムマスターは、通常のプロジェクト管理者のように開発者への作業の割り当て、計画策定、進捗管理等を行うことではなく、スクラムに関する教育を行うとともに開発を阻害する様々な障害を解決することを主任務とします。

スプリント計画ミーティングでは、スプリント目標とスプリントバックログが決められます。 スプリント目標は、プロダクトオーナーが中心になって顧客、管理職、開発チームとの議論により決定されるスプリントの大雑把な目標です。 例えば、スプリント目標は"システムを構成する永続性や通信メカニズムを決定する"などと設定されます。スプリント目標が設定された後、開発チームのメンバーが主体になってスプリント目標を達成するために必要なタスクをリストアップしていきます。各タスクは、4-16 時間で完了できる粒度で定義されます。さらに、抽出されたタスクから開発チームのメンバーが話し合いによりスプリントで達成するタスクの割り当てを決めます。 開発チームのこのようなタスクの定義や割り当ては、顧客やプロダクトオーナーの介入なしに開発メンバーにより自律的に行われます。

このような開発チームのメンバー間の自発的な議論を通じて、メンバー間の連携が自然に形成されます。このチーム内の連携が自律的に形成される過程をSchwaber らは「自己組織化による真のチーム形成」と呼んでいます。

デイリースクラムは、スプリントの期間中に毎日決まった場所及び時間に開催され、開発チームのメンバー全員が参加するミーティングです。 デイリースクラムでは、スクラムマスターが開発チームの各メンバーに以下の 3 点を質問します。

  • 前回のデイリースクラム以降の作業内容
  • 次回のデイリースクラムまでの作業予定
  • 作業を進める上での障害

デイリースクラムは、チーム内のコミュニケーションを促進するとともに、チームメンバー全員がプロジェクトの現状についての認識を共有し、メンバーの連帯を深めるのに有効です。また、スクラムマスターはデイリースクラムで報告された障害を解決することを支援します。

スクラムの大事な点は、スプリントの期間中は開発チームに外乱を与えず、開発に専念できるようにすることです。そのような外乱の発生を防ぐために、デイリースクラムには開発メンバー以外の人々も参加できますが、意見や要望を述べたりすることは許されていません。

以上説明したようにスクラムは「アジャイル開発のミニマムセット」と呼ばれるぐらいシンプルなフレームワークになっており、それがゆえに手法としては全世界で最も普及したものになっています。但し、スクラムを実践すればそれで十分かというとそうではありません。スクラムには、「技術的な裏付け（プラクティス）」が含まれないという点に注意する必要があります。そのため、「スクラム」だけを単純に実践していると、開発が進むにつれて開発の生産性が低下したり、コードの保守性やその他の品質が低下する危険性があります。

第1回の終わりに

今回の記事では、アジャイル開発が登場した背景とアジャイル開発の特徴、さらにはアジャイル開発の具体例としてスクラムというフレームワークを説明しました。あとの回でより詳しく説明しますが、SAFeが目目指すのはアジャイル開発の背景で述べた「『ビジネスや技術の変化』に柔軟かつスピーディーに対応して競争力のあるプロダクト/サービス/システムを開発する」ことです。それをスクラムが前提とする7±2名のチームより大きな規模で行うということです。これは、欧米でアジャイル開発が一般化してきている状況の中でチームを超えた規模でのプロダクト/サービス/システムの開発にもアジャイル開発が適用されていることを表しています。

アジャイル開発を大規模化する場合には以下のような課題に直面します。

  1. 企業の投資戦略との関係
    • 開発が大規模化したり、事業への影響度が高い場合、開発自身に経営陣や事業部長のような戦略レベルの意思決定を下す人達がどのように関与すべきか?
  2. 中間管理職の役割
    • 自律性を重視するアジャイル開発において中間管理職はどのような役割を担えばよいか？
  3. 要求の表現形式
    • 過度に文書化するというオーバーヘッドを避けつつ、要求をどのように表現すればよいか?
  4. プロジェクト管理の方式
    • 複数のチームで連携して開発する場合に、どのように計画策定し、どのように開発を進めていけばよいか？

これらの課題に対して、「アジャイル開発の長所」をうまく活かしつつ回答を提供するものがSAFeになります。また、これらの課題に関与する人達は開発チームのみならず、企業や事業部の様々な立場の人達です。それらの人達がうまく連携するためには本記事で述べた「アジャイル宣言」のような共有できる理念が必要になります。

次回は、アジャイル開発とともにSAFeの思想的なバックボーンを提供する「リーン思考」と「プロダクト開発フロー」の概要を説明する予定です。

参考文献