 |
[2005 年 5 月号] |
|
[2005 年 5 月号] |
［技術講座］
今回の記事では, プロジェクト管理に特化したアジャイル開発手法であるスクラムの概要を説明します. また, スクラムによる開発が成功する理由を説明するための理論的なバックボーンとして引用されている知識創造プロセスやコンテキストの概要を紹介します. さらに, 20 名程度の中規模開発チームにおいてスクラムを適用し, 開発に成功した事例を紹介し, その中で知識創造プロセスやコンテキストが生まれたのか否かについて考察します.
スクラム [1] は, Ken Schwaber と Mike Beedle によって考案されたアジャイル開発手法です. スクラムという開発方法論の名称は, ラグビーのスクラムにちなんで名づけられたそうです. スクラムは、Schwaber らがいくつかの失敗プロジェクトを立て直す経験を通じて生み出されたとされています.
スクラムは, 他のアジャイル開発手法と同様に動くソフトウェアを順次作り, そのソフトウェアを発展させながら開発を進める反復的な開発アプローチに基づいています. アジャイル開発手法は一般的に開発チームで共有すべき価値や作業の指針となる原則やプラクティスで開発の進め方を定めていますが, スクラムが定めている価値は以下の 5 点です.
スクラムでは, このような価値以外にも開発の進め方や開発チームにおける役割についても言及していますが, 言及している範囲はプロジェクト管理作業に偏っています. スクラムは, プロジェクト管理的な作業に特化しているため, XP (eXtreme Programming) [2] やUP (Unified Process) [3] など設計, 実装, テストの実践形態を規定している様々な反復的な開発手法と組み合わせやすい開発手法です.
スクラムの理論的なバックボーンとして参照されているのが野中らの「知識創造企業」 [4] で述べられている日本企業の新製品開発のプロセス及び組織論です. 知識創造企業では, 日本のメーカがホームベーカリーや低価格コピー機などの画期的な製品を開発できた背景として以下の 2 点の存在が大きく寄与したと説明されています.
 |
スクラムの価値や後述する開発の進め方は, 知識創造企業で述べられているような知識創造のプロセスとコンテキストを生み出すことを可能にし, それがプロジェクトの成功につながるのではないかというのが Schwaber らの解釈です.
スクラムでは, 30 日間のサイクルで動くソフトウェアを作りながら開発を進めます. 図 2 は, スクラムによる開発の流れを示したものです. 図中の用語の意味は, 以下の通りです.
 |
図 2 に示されている標準, 規約, ガイドラインは, 開発組織において守ることが求められている標準, 規約, ガイドラインを意味します.
スクラムでは, 開発は以下のように進行します.
図 2 のスプリント計画ミーティングは, 2, 3 の 2 ステップとして実行されます.
スクラムでは, 一般の開発メンバーに加えて以下の 2 つの管理的な役割が定義されています.
ススクラムマスターは, 開発者への作業の割り当て, 計画策定, 進捗管理等を行う通常のプロジェクト管理者と異なり, 開発を阻害する様々な障害を解決するのが主任務になっています.
スプリント計画ミーティングでは, スプリントゴールとスプリントバックログが決められます. スプリントゴールは, 製品責任者が中心になって顧客, 管理職, 開発チームとの議論により決定されるスプリントの大雑把な目標です. 例えば, スプリントゴールは"システムを構成する永続性や通信メカニズムを決定する"などと設定されます. スプリントゴールが設定された後, 開発チームのメンバーが主体になってスプリントゴールを達成するために必要なタスクをリストアップしていきます. 各タスクは, 4-16 時間で完了できる粒度で定義されます. さらに, 抽出されたタスクから開発チームのメンバーが話し合いによりスプリントで達成するタスクの割り当てを決めます. 開発チームのこのようなタスクの定義や割り当ては, 顧客や製品責任者の介入なしに開発メンバーにより自律的に行われます.
このような開発チームのメンバー間の自発的な議論を通じて, メンバー間の連携が自然に形成されます. このチーム内の連携が自律的に形成される過程を, Schwaber らは「自己組織化による真のチーム形成」と呼んでいます.
最終的に割り当てされたタスクの集合がスプリントの詳細目標であるスプリントバックログになります. スプリントの途上では, スプリントバックログの消化状況がグラフ化されてプロジェクトの全体の作業進捗状況として共有されます.
デイリースクラムは, スプリントの期間中, 毎日決まった場所及び時間に開催され, 開発チームのメンバー全員が参加するミーティングです. デイリースクラムでは, スクラムマスターが開発チームの各メンバーに以下の 3 点を質問します.
デイリースクラムは, チーム内のコミュニケーションを促進するとともに, チームメンバー全員がプロジェクトの現状についての認識を共有し, メンバーの連帯を深めるのに有効です. また, スクラムマスターはデイリースクラムで報告された障害を解決することを支援します. Schwaber らは, デイリースクラムにおいて野中らにより提案された内在知と形式知の変換プロセスが実現しているのではないかと説明しています.
スクラムの大事な点は, 30 日間のスプリントの期間中は開発チームに外乱を与えず, 開発に専念できるようにすることです. そのような外乱の発生を防ぐため, デイリースクラムには開発メンバー以外の人々も参加できますが, 意見や要望を述べたりすることは許されていません.
以降, 中規模の組み込みシステムの開発にスクラムを適用し, 開発を成功させた事例を紹介します.
事例として紹介する組み込みシステムの開発は, 以下の２つの課題に対応することを目的として決断されました.
当初の計画段階では, 2 年間程度の開発期間でまず課題 1 に対応した後に課題 2 に対応するという 2 段階の計画が立案されました. この開発計画が承認される段階で, 以下のような厳しい条件が課せられたそうです.
実際には, 後述するように第 1 段階の開発が 3 ヶ月程度進行した段階でシステムを購入するお客様の意向で残り 9 ヶ月の期間で 2 つの課題とも開発することが求められました. すなわち, 当初の計画を半分の期間に短縮することが必要になったのです. 開発を終わった現時点で振り返ると, この開発期間の短縮がプロジェクトを成功させるために克服すべき一番厳しい条件だったそうです.
開発を推進するリーダは, 開発を進めるために求められた 2 条件を満足するために, 従来の開発のやり方を以下の点で変える必要があると考えたそうです.
これら 3 点については, リーダ自身のコメントをほぼそのまま引用させて頂きました. コメント中の”客先仕様”とは, 開発対象の製品を実際に購入する顧客毎の個別仕様を意味する. また, ”横通し”とはソフトウェアの階層毎に分担を決める開発方式を意味し, ”縦通し”とはシステムの上位機能毎に分担を決める開発方式を意味します. ”縦通し”は, XP 的に言えばユーザストーリ単位 ( end-to-end ) で開発範囲を設定することに相当します.
さらに, 社内のプロセスコンサルタントに相談した結果, これら 3 点を満足する開発手法としてアジャイル開発手法スクラムを選んだそうです.
当初は課題 1 の対応を先に行うことを目標とし、#1 スプリントは 5 名のチームでスタートしました. その後、スプリント毎に要員を増員しながら #5 スプリントまで 9 名程度のチームで開発を行いました（図３）.
 |
各スプリントの最初で持たれたスプリント計画ミーティングでは, スプリントゴールの設定に先立ち, 以降の長期計画を見直しました. すなわち, 前回のスプリントの実績や並行開発しているハードウェアの開発状況を踏まえて, 以降のスプリントにおける製品バックログ（ソフトウェアの大きな機能）の実装計画を見直したのです.
反復的な開発におけるプロジェクト管理では, 反復 (スクラムではスプリント) 単位の短期計画に加えて, このような長期的な視点で開発のリスクにどのように対処していくかという計画を考えたり, 最終的な開発の達成レベルを予測し, 開発要員の増員の必要性などを判断していくことが重要になります.
新アーキテクチャの形式とインターフェイスの仕様が確定した #5 スプリントで, 長期的な開発計画を見直した結果, 開発期限までに開発を完了するためには開発メンバーの増員が必要なことが分かりました. そのため, #6 スプリントからチームの増員を行い, 総勢 26 名の開発者で2階層のスクラムチームを編成し, 開発を行いました. (図 4).
 |
#11 スプリント以降, 緊急にデモを動かす依頼に対応したり, ハードウェアの動作検証を集中的に行う必要が生じ, スプリントの最初で先行してタスクのバックログを定義するのが困難になりました. そのため, #11 以降ではスプリントの目標設定やバックログ管理を諦めたそうです. 最終的には, #12 で必要な機能の実装とシステムテストを完了し, 納品期限内に製品をお客さまに納品できたそうです.
 |
今まで開発チーム側だけでの開発の進行だけを述べてきましたが, 今回の事例では製品の仕様をお客様と協議して決めることも必要であり, その仕様策定は開発チームと別チームが担当していたそうです. スクラムはどちらかというと製品開発を意識した開発手法ですが, このように開発チームとは別に要求定義を行う人やチームを設ければ受託開発にも適用できる可能性があります.
開発メンバーの方々がこれまでの開発を振り返った際に, スクラムを実践して有効だったと挙げているのは以下の 3 点です.
また, 同時に開発メンバーの方々は以下のような難しさや課題も述べています.
筆者は, #1 スプリントの途中から #5 スプリントまでこのプロジェクトを訪問し, スクラムの実践方法について支援しました. この #5 スプリントまでの観察結果と開発後にメンバーの方々から伺った話を元にして考えた結果, 今回のプロジェクトで開発が成功した要因は以下の 5 点にあったのではないかと筆者は考えています.
これらの要因の中で D, E は, 今回のプロジェクトの開発分野の特殊性やチーム規模に対応するために求められたものであり, 通常スクラムで想定している 7 名前後のチームでは必ずしも必要な条件ではないでしょう. それに対して, A, B, C はおそらくスクラムを成功させるための基本的な条件だと言えるのではないかと思います.
さらに, 今回の事例のプロジェクトにおいて野中らの知識創造プロセスやコンテキストが実際に実現されたかどうかという点を考察した結果が, 以下のとおりです.
今回のプロジェクトでは, 過去に例を見ない画期的な新製品を作ることを目的としていなかったので, スクラムが知識創造において有効だったかどうかについては判断できません. しかしながら, 納期の短さ, 経験者の少なさ, ハードウェアとの並行開発という点で今回のプロジェクトはかなり厳しい状況だったと思いますが, その中で開発が成功した大きな要因として「知識創造プロセスを促進するコンテキスト」の多くが存在したことも寄与したのではないかと考えられます. すなわち, 個々のメンバーの能力が有機的に連携し, 強力なチームを形成するうえで「知識創造プロセスを促進するコンテキスト」の多くが必要だったのではないかと考えられます.
最初に詳細計画を立案し, それを守らせることが中心だった従来のプロジェクト管理の作業に慣れた人には, スクラムで求められているような「スプリント単位のフィードバックによる計画の見直し」や「スクラムマスターが先頭に立った問題解決」の実践は難しそうに感じられるかもしれません. そのような人にとっても, 若手の開発リーダの協力が得られるならばスクラムのような開発手法を使うことでより良いチームワークの下で開発を進めることが可能になるのではないかと思います.
逆に, スクラムは「スプリント単位のフィードバックによる計画の見直し」や「スクラムマスターが先頭に立った問題解決」ができる人であれば, 詳細計画を立案するスキルや経験を問わず実践できます. そのため, プロジェクト管理経験が浅かったり, 皆無な若手の開発者が小規模の開発チームで開発とプロジェクト管理を両方行わなければならなくなったような場合にも適用できる開発手法だと思います.
どちらのケースであっても, スクラムのような開発手法が日本でも広がり, 市場競争力の高いパッケージソフトウェア製品や組み込みソフトウェアの開発に活かされることを筆者は願っています.
また, 開発事例の「スクラムの実践」の節の最後で述べたように, スクラムはどちらかというと製品開発を意図した開発手法ですが, 要求定義を行う人やチームを設ければ受託開発にも適用できる可能性があります. 今後, 受託開発でスクラムをどのように適用すればよいかについても検討していく必要があります.
本記事で事例として取り上げたプロジェクトに関与する機会を与えてくださった日立オムロンターミナルソリューションズ（株）の冨永様, 鳥海様, オムロン（株）の濱崎様, 及び開発チームのメンバーの方々にこの場を借りてお礼をさせて頂きます.
| © 2005 OGIS-RI Co., Ltd. |
|
