アジャイルモデリングへの道2 スクラム組んで開発しよう！

（本内容は当社Webマガジン「オブジェクトの広場」に掲載した記事を再掲したものです）

今回の記事では, プロジェクト管理に特化したアジャイル開発手法であるスクラムの概要を説明します. また, スクラムによる開発が成功する理由を説明するための理論的なバックボーンとして引用されている知識創造プロセスやコンテキストの概要を紹介します. さらに, 20 名程度の中規模開発チームにおいてスクラムを適用し, 開発に成功した事例を紹介し, その中で知識創造プロセスやコンテキストが生まれたのか否かについて考察します.

目次

• スクラムとは
• スクラム実践事例の紹介
• アジャイル・スクラムに関するトレーニングのご案内

1. スクラムとは

1.1 スクラムの価値と理論的な基盤

スクラム [1] は, Ken Schwaber と Mike Beedle によって考案されたアジャイル開発手法です. スクラムという開発方法論の名称は, ラグビーのスクラムにちなんで名づけられたそうです. スクラムは、Schwaber らがいくつかの失敗プロジェクトを立て直す経験を通じて生み出されたとされています.

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

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

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

スクラムの理論的なバックボーンとして参照されているのが野中らの「知識創造企業」 [4] で述べられている日本企業の新製品開発のプロセス及び組織論です. 知識創造企業では, 日本のメーカがホームベーカリーや低価格コピー機などの画期的な製品を開発できた背景として以下の 2 点の存在が大きく寄与したと説明されています.

• 知識変換に基づく知識創造プロセス
• 日本のメーカは, 図 1で示されるような日本の文化で重視されてきた言葉や文章で表現することが困難な「暗黙知」と西洋の文化で重視されてきた言葉や文章で表現できる「形式知」を相互に変換するプロセスにより, 新しい知識を生み出している
• 知識創造プロセスを促進するコンテキスト
• 日本のメーカには, 知識創造プロセスを促進する以下の５つのコンテキストが存在する
• 知識創造の目標やチームを生み出す「組織の意図」
• チームのメンバーに自由な行動を認める「自律性」
• 組織と外部環境との相互作用を刺激する「ゆらぎと創造的なカオス」
• 組織に組み込まれた意図的な情報の「冗長性」
• 複雑で多様な環境に対応するために組織のメンバーも同程度の多様性を持つ必要があるという「最小有効多様性」

図１ 4 つの知識変換モード

スクラムの価値や後述する開発の進め方は, 知識創造企業で述べられているような知識創造のプロセスとコンテキストを生み出すことを可能にし, それがプロジェクトの成功につながるのではないかというのが Schwaber らの解釈です.

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

スクラムでは, 一定の期間毎に動くソフトウェアを作りながら開発を進めます. 図 2 は, スクラムによる開発の流れを示したものです. 図中の用語の意味は, 以下の通りです.

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

  図２ スクラムにおける開発の流れ

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

スクラムでは, 開発は以下のように進行します.

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

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

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

• プロダクトオーナー: プロダクトバックログを定義し, 優先度を決める人
• スクラムマスター: プロジェクト管理者

スクラムマスターは, 開発者への作業の割り当て, 計画策定, 進捗管理等を行う通常のプロジェクト管理者と異なり, 開発を阻害する様々な障害を解決するのが主任務になっています.

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

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

最終的に割り当てされたタスクの集合がスプリントの詳細目標であるスプリントバックログになります. スプリントの途上では, スプリントバックログの消化状況がグラフ化されてプロジェクトの全体の作業進捗状況として共有されます.

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

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

デイリースクラムは, チーム内のコミュニケーションを促進するとともに, チームメンバー全員がプロジェクトの現状についての認識を共有し, メンバーの連帯を深めるのに有効です.　また, スクラムマスターはデイリースクラムで報告された障害を解決することを支援します. Schwaber らは, デイリースクラムにおいて野中らにより提案された内在知と形式知の変換プロセスが実現しているのではないかと説明しています.

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

2. スクラム実践事例の紹介

以降, 中規模の組み込みシステムの開発にスクラムを適用し, 開発を成功させた事例を紹介します.

2.1 スクラムを選んだ動機

事例として紹介する組み込みシステムの開発は, 以下の２つの課題に対応することを目的として決断されました.

• 課題 1：ハードウェアの構成変更や更新や追加に伴うハードウェア制御用ソフトウェアの改訂及び追加
• 課題 2：ハードウェア制御のための新たなインターフェイスを導入するためのソフトウェアアーキテクチャの変更

当初の計画段階では, 2 年間程度の開発期間でまず課題 1 に対応した後に課題 2 に対応するという 2 段階の計画が立案されました. この開発計画が承認される段階で, 以下のような厳しい条件が課せられたそうです.

• 従来と比べて開発予算や期間の大幅な削減を達成することが必要
• 過去同じ分野で開発した経験を持つ要員は 3 名程度しか割り当てられない

実際には, 後述するように第 1 段階の開発が 3 ヶ月程度進行した段階でシステムを購入するお客様の意向で残り 9 ヶ月の期間で 2 つの課題とも開発することが求められました. すなわち, 当初の計画を半分の期間に短縮することが必要になったのです. 開発を終わった現時点で振り返ると, この開発期間の短縮がプロジェクトを成功させるために克服すべき一番厳しい条件だったそうです.

開発を推進するリーダは,　開発を進めるために求められた 2 条件を満足するために, 従来の開発のやり方を以下の点で変える必要があると考えたそうです.

1. いままでのウォーターフォール型では、結合テストが始まる後半まで問題が明確にならないことが多く, 後半に大きな手戻りが発生するようなことが多く, 大変になるのでスパイラル的な開発をしよう（一番の動機）
2. 短納期大規模の開発で、客先仕様なども開発を開始してから決めていくような状況やハードウェアの開発も平行して行なっているなどコミュニケーションが大事
3. 今までは横通しの層で設計を分割していたのも、I/F などの問題で、結合時に問題になることが多かった. そのような問題を防止するため, 「縦通しの機能で切って見ては？」との話もあり, 縦で切る場合、縦横のコミュニケーションが大事

これら 3 点については, リーダ自身のコメントをほぼそのまま引用させて頂きました. コメント中の"客先仕様"とは, 開発対象の製品を実際に購入する顧客毎の個別仕様を意味する. また, "横通し"とはソフトウェアの階層毎に分担を決める開発方式を意味し, "縦通し"とはシステムの上位機能毎に分担を決める開発方式を意味します.　"縦通し"は, XP 的に言えばユーザストーリ単位 ( end-to-end ) で開発範囲を設定することに相当します.

さらに, 社内のプロセスコンサルタントに相談した結果, これら 3 点を満足する開発手法としてアジャイル開発手法スクラムを選んだそうです.

2.2 スクラムの実践

当初は課題 1 の対応を先に行うことを目標とし、#1 スプリントは 5 名のチームでスタートしました. その後、スプリント毎に要員を増員しながら #5 スプリントまで 9 名程度のチームで開発を行いました（図３）.

図３ 開発スケジュール

• #1, #2 スプリントでは, 開発内容やスクラムによる開発の進め方を習得することを優先した. この段階では, タスクの粒度, スプリントで消化可能なタスク量, タスクの割り当て方法に戸惑い, スプリントバックログが思ったように消化できなかった. そのため, スプリントの中間点でスプリントバックログの見直しを行いながら徐々に計画と実績のギャップを少なくしていった
• #3 スプリント以降は, 開発内容や開発の進め方に慣れてきたため、30 日間のスプリントでスプリントバックログがだんだん消化できるようになった
• #4 スプリントでアーキテクチャの変更（課題 2 ）を組み込むスケジュールが前倒しになることが決まり, #5 スプリントで新アーキテクチャの実装形式を検証するためのプロトタイピングを行った. 実際には, 新アーキテクチャの実装形式の検証は #5 スプリント後にさらに 2 週間程度の #5.5 スプリントを追加し, 完了した.

各スプリントの最初で持たれたスプリント計画ミーティングでは, スプリントゴールの設定に先立ち, 以降の長期計画を見直しました. すなわち, 前回のスプリントの実績や並行開発しているハードウェアの開発状況を踏まえて, 以降のスプリントにおけるプロダクトバックログ（ソフトウェアの大きな機能）の実装計画を見直したのです.

反復的な開発におけるプロジェクト管理では, 反復 (スクラムではスプリント) 単位の短期計画に加えて, このような長期的な視点で開発のリスクにどのように対処していくかという計画を考えたり, 最終的な開発の達成レベルを予測し, 開発要員の増員の必要性などを判断していくことが重要になります.

新アーキテクチャの形式とインターフェイスの仕様が確定した　#5 スプリントで, 長期的な開発計画を見直した結果, 開発期限までに開発を完了するためには開発メンバーの増員が必要なことが分かりました. そのため, #6 スプリントからチームの増員を行い,　総勢 26 名の開発者で2階層のスクラムチームを編成し, 開発を行いました. (図 4).

図４ ２階層スクラム実践時のチーム構成

• ソフトウェアの機能ブロックに基づき, 下位スクラムチームを 4 チーム編成した
• #5 スプリントまでのスクラムチームのメンバーが 4 つの下位スクラムチームのリーダ及びサブリーダとなり, これらのリーダ, サブリーダと全体を統括するリーダで上位スクラムチームを編成した
• スプリントで各チームが達成すべき大きなレベルのタスクは上位のスクラムチームで決め, 下位のスクラムチームで詳細なタスクの洗い出し及び割り当てを行った
• #6 から #10 スプリントまでは, スプリントバックログの消化に苦しみながらも概ね2階層スクラムチームにより順調に開発が進んだ（図 5 ）

2.3 スクラムの効果と課題

開発メンバーの方々がこれまでの開発を振り返った際に, スクラムを実践して有効だったと挙げているのは以下の 3 点です.

• 人材が育成できたこと
• 現行システムの経験者が 3 名しかいない状況からスタートし, 当初開発は無理かもしれないと思われた. しかし, 開発の初期のスクラム実践過程で経験者のレベルに他のメンバーがキャッチアップできた
• プロジェクト管理のやり方として有効だったこと
• 短期の目標設定, リスク管理, 進捗管理などの点で, 従来のプロジェクトよりプロジェクト管理が効果的に行えた. また, スプリントの期間内に割り込みの排除が排除できたため, 開発に専念することができた
• コミュニケーションとチームワークが良好だったこと
• 開発チームのメンバーが全員同じ部屋で開発を行い, デイリースクラム等により知識共有が効果的に行えた. そのため, プロジェクトメンバーが休んでもプロジェクトの進捗が滞らず,　チームワークに優れたチームが形成された

また, 同時に開発メンバーの方々は以下のような難しさや課題も述べています.

• チーム規模拡大による自律性の低下
• #6 スプリントでチーム規模が大きくなった以降, チームによってはタスクの割り当てをトップダウンで行わざるをえなかった（タスクの割り当て表を作った）
• 開発終盤や環境整備チームの目標管理の難しさ
• 開発の終盤に入り, 開発チーム外からの依頼タスクの割合が増え, スプリントバックログを管理するのが困難になった
• #6 スプリント以降, 環境の準備や対外対応する作業を 1 つのチームに集中したがそのチームについては, スプリントバックログの管理はうまくできなかった
• 開発ペースのむら
• スプリント前半の作業ペースが遅く, 後半に作業ペースが尻上がりに上がる傾向に陥る
• テストの自動化は一部チームしか実現していない
• ハードウェアの動作が複雑であったり, 仕様が確定していなかったため, プロジェクトの限られた予算と期間ではテストの自動化に必要な精度の高いシミュレータやスタブを開発することができなかった

2.4 成功要因の分析

筆者は, #1 スプリントの途中から #5 スプリントまでこのプロジェクトを訪問し, スクラムの実践方法について支援しました. この #5 スプリントまでの観察結果と開発後にメンバーの方々から伺った話を元にして考えた結果, 今回のプロジェクトで開発が成功した要因は以下の 5 点にあったのではないかと筆者は考えています.

1. スプリント単位のフィードバックによる計画の見直し
• 今回のプロジェクトは, 過去開発経験があるメンバーが少なかったり, ハードウェアの開発が並行して進行するなど計画を先行して立案するのが困難な状況で開発を行わざるをえなかった. そのような状況でも, スクラムを適用することにより 30 日間で計画のフィードバックが得られ, 計画をより現実的なものに見直していったことが有効だった
2. スクラムマスターが先頭に立った問題解決
• スクラムマスターは先頭に立ってプロジェクトの外部との交渉と技術的な問題の解決を精力的に行った. そのような姿勢が, チーム内にプロジェクトを前に進めねばならないという使命感を育んだ
3. 開発メンバーが 1 つの部屋に集まったこと
• 厳しい開発スケジュール及び過去に開発経験があるメンバーが少数だった状況では開発内容の習得や開発途上で出る問題点の解決のオーバヘッドを極力抑える必要があった. そのようなオーバヘッドを抑えるためには, 開発メンバーが１つの部屋に集まったことが極めて有効だった
4. 上位スクラムチームのメンバーの高いスキル
• 当初からの開発メンバーから構成される上位スクラムチームのメンバーはなかなか個性的なメンバー揃いでしたが, 開発者として高いスキルを有している点は共通していました. このような高いスキルのメンバーが中心になり, スプリント毎の目標設定や下位スクラムチームの支援を行ったことが 2 階層のスクラムを成功させる原動力になった
5. チーム規模の段階的なスケールアップ
• 開発初期段階に中核メンバーが徐々に増員される過程で中核メンバーが開発内容や開発の進め方を十分理解できたことが, #6 スプリント以降に拡大したチームでスクラムを実践できた大きな鍵になった

これらの要因の中で D, E は, 今回のプロジェクトの開発分野の特殊性やチーム規模に対応するために求められたものであり, 通常スクラムで想定している 7 名前後のチームでは必ずしも必要な条件ではないでしょう. それに対して, A, B, C はおそらくスクラムを成功させるための基本的な条件だと言えるのではないかと思います.

さらに, 今回の事例のプロジェクトにおいて野中らの知識創造プロセスやコンテキストが実際に実現されたかどうかという点を考察した結果が, 以下のとおりです.

• 知識創造プロセス
• 今回のプロジェクトで新しい知識が生まれたどうかは定かではない. しかし, 知識の変換の場であるデイリースクラムはチーム内での情報共有を促進したり, プロジェクトの連携を深めたり, 障害の解決には有効だったと思われる.
• 知識創造プロセスを促進するコンテキスト
• 以下のように, 知識創造プロセスを促進するコンテキストの多くは存在したと思われる
• 「組織の意図」: 新たな知識を生み出すということが主目的ではなかったので, 研究開発という点での戦略的な意図との結びつきはない
• 「自律性」: スクラムメンバーによるタスクの洗い出しによりスプリントの目標や進捗管理で実現
• 「ゆらぎと創造的なカオス」: 大きなレベルでは, プロジェクトを開始する際の制約として与えられた. 小さなレベルでは, プロダクトオーナーとスクラムチームの話し合いによるスプリントのゴールの決定過程で実現
• 情報の「冗長性」: デイリースクラムによる情報共有により実現
• 最小有効多様性」: 個性的で技術的スキルの高いメンバーが参加したことで実現

今回のプロジェクトでは, 過去に例を見ない画期的な新製品を作ることを目的としていなかったので,　スクラムが知識創造において有効だったかどうかについては判断できません. しかしながら, 納期の短さ, 経験者の少なさ, ハードウェアとの並行開発という点で今回のプロジェクトはかなり厳しい状況だったと思いますが, その中で開発が成功した大きな要因として「知識創造プロセスを促進するコンテキスト」の多くが存在したことも寄与したのではないかと考えられます.　すなわち, 個々のメンバーの能力が有機的に連携し, 強力なチームを形成するうえで「知識創造プロセスを促進するコンテキスト」の多くが必要だったのではないかと考えられます.

3. 最後に

最初に詳細計画を立案し, それを守らせることが中心だった従来のプロジェクト管理の作業に慣れた人には, スクラムで求められているような「スプリント単位のフィードバックによる計画の見直し」や「スクラムマスターが先頭に立った問題解決」の実践は難しそうに感じられるかもしれません. そのような人にとっても, 若手の開発リーダの協力が得られるならばスクラムのような開発手法を使うことでより良いチームワークの下で開発を進めることが可能になるのではないかと思います.

逆に, スクラムは「スプリント単位のフィードバックによる計画の見直し」や「スクラムマスターが先頭に立った問題解決」ができる人であれば, 詳細計画を立案するスキルや経験を問わず実践できます. そのため, プロジェクト管理経験が浅かったり, 皆無な若手の開発者が小規模の開発チームで開発とプロジェクト管理を両方行わなければならなくなったような場合にも適用できる開発手法だと思います.

どちらのケースであっても, スクラムのような開発手法が日本でも広がり, 市場競争力の高いパッケージソフトウェア製品や組み込みソフトウェアの開発に活かされることを筆者は願っています.

また, 開発事例の「スクラムの実践」の節の最後で述べたように, スクラムはどちらかというと製品開発を意図した開発手法ですが, 要求定義を行う人やチームを設ければ受託開発にも適用できる可能性があります. 今後, 受託開発でスクラムをどのように適用すればよいかについても検討していく必要があります.

謝辞

本記事で事例として取り上げたプロジェクトに関与する機会を与えてくださった日立オムロンターミナルソリューションズ（株）の冨永様, 鳥海様, オムロン（株）の濱崎様, 及び開発チームのメンバーの方々にこの場を借りてお礼をさせて頂きます.

参考文献

• [1] ケン・シュエイバー, マイク・ビードル: アジャイルソフトウェア開発スクラム, ピアソンエデュケーション, 2003
• [2] ケント・ベック: XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法, ピアソンエデュケーション, 2000
• [3] イヴァー・ヤコブソン他: UMLによる統一ソフトウェア開発プロセス, 翔泳社, 2000
• [4] 野中郁次郎, 竹内弘高: 知識創造企業, 東洋経済新聞社, 1996

アジャイル・スクラムに関するトレーニングのご案内