52 33.1 第 3 章プロダクトオーナーシップ リリース計画 プロダクトオーナーはリリース計画を策定して、初期プロダクトバックログを作 するためだけでなく、そのビジョンに基づいてリーダーとチームを再編成するため て加速度的に成長できます。 Micr 。 s 。 ft の各製品部門では、リリースビジョンを作成 混乱ー統一一機能 (forming-storming-norming-performing) 」・というプロセスを経 先順位に従って作業を行い、自由に意見を述べられるようにすれば、チームは「形成ー めの最高の機会です。チームの全員がビジネス価値と顧客価値を明確に理解し、優 リリース計画は、コンテキストを共有し、高い機能性を発揮するチームを作るた 現時点での要件の優先順位付けを行うことにあります。 スビジョン ( リリースの見通し ) を作り出し、最初のスプリントの開始に備えて、 成します。この作業の目的は、あいまいで矛盾も多いインブットから明暸なリリー と同じくらい難しいという認識が広まっている。 Beinhofer 著「 The Origins of Wealth 」を参照。 ⑨実際、エコノミストたちの間では、長期的なビジネス戦略を正確に見通すのは、正確な天候の長期予報 ・ Bruce Tuckman, "Developmental Sequence in Small Groups,' P c ん 0 / og / c B ″〃ⅲ 63 : 6 ( 1965 ) : 384-99. じることもよくあります。こうすれば間違いなし、という答えはないのです。・ 増大、競争上の脅威への取り組みなど、さまざまな側面があり、その間で矛盾が生 客層の育成、既存顧客層でのシェア拡大、ビジネスパートナーの開拓、販売利益の り口から検討することになります。市場投入までの期間、イノベーション、新規顧 ビジネス戦略の検討に役立つレンズは数多くありますが、どれもそれぞれ異なる切 告書のたびにビジネス戦略に必死に取り組むはずはありません。私の経験によると、 ビジネス戦略は難しい課題です。そうでなければ、あれほど多くの会社が年次報 ビジネス価値 プロダクトバックログ、そして適切なチーム編成です。 計画で目指すところは、信頼できるビジョン、実行スプリントを開始できるだけの メントごとに明暸なバックログを作成し、結果の検査と適応を行います。リリース ムボックスを設定してください。 2 ~ 4 週間のインクリメントを使用し、インクリ 実行スプリントにタイムボックスを設定するのと同様に、リリース計画にもタイ ス優先順位の決定と正式な組織構造の決定を行うことができます。 にもリリース計画を利用しています。これにより、相互に情報を共有しながら、リリー

プロセスサイクルと TFS 2.3.1 2.3 リリース 25 リリースとは、ビジョンを完成したソフトウェアに作り上げるまでのパスのこと です。 Ken Schwaber と Jeff SutherIand は『 Scrum Guide 』の中で次のように述べ ています。 リリース計画とは、「できる限り最善の手を尽くしながらビジョンをどうやって魅 力的な製品に仕立て上げるか」、また「期待される顧客満足と投資収益をどうやっ て達成し、上回るか」という質問に答えるものである。リリース計画では、リリー スのゴール、優先順位の最も高いプロダクトバックログ、主要なリスク、および リリースに含める全部の機能を定める。また、変更が一切発生しなかった場合に 守るべき納品日とコストの見積もりを決定する。・ リリース定義は「プロダクトバックログ (Product Backlog) 」に含まれます。プ ロダクトバックログとは、期待される要件を網羅したものであり、個々の要件は「プ ロダクトバックログ項目 (Product Backlog ltem : PBI) 」と呼ばれます ( 図 2-4 を ① Tom DeMarco and Timothy Lister, ー / にⅲ g with B どハ . ・ Managing R なた 0 〃 Software projects (New 【邦訳】「熊とワルツを一リスクを愉しむプロジェクト管理」伊豆原弓訳 ( 日経 BP 社、 2003 年 ) York: Dorset House, 2 開 3 ) , 130. TScrum Guide] 、 9 ページ。 られるより熱心な推進者と見られるほうが得だと考える者が好んで使う手段であ だ。これは、当初はプロジェクトに反対していたが、プロジェクトの反対者と見 たくさんの機能を追加してプロジェクトをあふれさせ、失敗させようとすること クホルダーと戦わなくて済むからだ。この作り話が原因で生じるもう 1 つの病気は、 そうしておいたほうが、協力の対価として余分な機能を付け加えようとするステー 込みである。このような作り話が多くのプロジェクトでいまだに聞かれるのは、 を治療できる。その 1 つは、製品のすべての部分が等しく重要であるという思い すべての機能に優先順位を付けると、プロジェクトにありがちな 2 つの悪い病気 うに述べています。 にやるべきこと」があいまいにならないようにします。 DeMarco と Lister は次のよ 参照 ) 。プロダクトオーナーは、リリース全体を通じて PBI の優先順位付けを行い、「次

索 引 281 … 21 ムリ . Microsoft Visual Studio Scrum (Scrum) .. MSF for Agile Software Development (MSF Agile) .. . … 21 MSF for CMMI Process lmprovement (MSF CMMI)... 22 プロセスモデル 実証的プロセスモデル ... 定義されたプロセスモデル… プロダクトオーナー プロダクトパックログの手入れ .. リリース計画 ... プロダクトオーナーシップ… プロダクトバックログ… 手入れ… プロダクトバックログ項目 . テスト .. 分岐 .. リリース別分岐 .. 文書化 ... 分析症候群 . 平均故障間隔 . 平均復旧時間 . ペーバープロトタイピング .. ベルソナ .. べロシティ . 変更セット .. 第ほ 法令遵守 .. 保守性 .. ポトムアップサイクル .. ■ま ーティング .. 毎日の現場ミ 満足因子 .. ■み 魅力 .. 魅力性 .. ムダ… 無駄の削減 .. テスト .. 無駄の排除 .. ムラ .. ■め モニター容易性 .. .. 9 , 22 … 51 0 ゆ ユーサーエクスペリエンス .. ... 46 , 50 ユーサーストーリー … 7 , 9 , 25 , 28 テストの状態… ユーザビリテイラボ .. … 21 , 25 .... 206 ユースケース図 .. … 162 ... 165 要件の適切な粒度 .. . … 163 … 42 要件のレベル数 .. … 30 要件劣化 .. 余分な処理 .. … 68 ■り . … 68 リスク管理 .. リスクテスト . … 53 リファクタリング… … 8 , 80 リリース .. ... 129 リリース計画 . リリースビション ... リリース別分岐… メトリクス .. … 69 … 67 … 10 , 21 , 26 , 54 … 203 … 64 0 9 9 -1 … 42 . … 230 … 136 .... 7 , 24 , 25 … 52 … 52 , 54 ... 163 .. 42 … 68 , 103 累積フローグラフ .. ・れ … 165 レイヤー図 .. ... 34 , 77 レッド / グリーン / リファクタリング .. … 56 ロードテスト . ... 60 … 67 ワイヤーフレーム ... … 1 1 割れ窓 ... ... 6 , 10 .... 205 .. 194 … 196 … 136 ... 222 , 226 … 62

9-3 ■各チームで、基本的な内容を修正するよりも、生産過剰が推進されるように なります ( つまり、好きな機能ばかりに手をかけるようになります ) 。 VS 2005 後の改善 241 93.1 ・プロジェクトの終わりが非常に予測しにくくなります。水面下にどのぐらい 大きな氷山が隠れているのか、つまりリリースまでにどのぐらいの実作業が 残っているのかは、誰にもわかりません。 当然のことながら、 VS 2005 のリリースサイクルではスケジュールの大きなすれ が生じ、そのすれた時間だけ、士気に大きなばらっきが生じました。 vs 2005 後の改善 れの変更について順に説明していきます。 言えば、次のリリースサイクルでは 7 つの変更を導入しました。以降では、それぞ それでは、次のリリースではどのようにやり方を変えたのでしようか。大まかに ・「完了」の定義 ・エンジニアリングの原則 ■スプリントバックログ プロダクトバックログ ■フィーチャークルー ・タイムボックスの短期化 ・健全な状態の実現と維持 ストで確認する ) か、永久にクローズするということです。これにより、以前のリリー のリリースから持ち越されたすべてのバグを修正する ( そして、自動化した回帰テ 我々の目標は、 MQ の終わりに既知のバグをゼロにすることでした。つまり、前 間の大きな発生源でした。 る主な 2 つの領域は、バグとテストでした。この 2 つはどちらも二度手間、三度手 の累積を防ぐ工ンジニアリングシステムを導入することでした。技術的負債が生じ Quality:MQ) を策定しました。 MQ の目的は、技術的負債を取り除き、今後もそ 製品の作業を開始する前に、我々は品質のマイルストーン (Milestone for 健全な状態の実現と維持

236 第 9 章 Microsoft DeveIoper Division で得た教訓 私は 2003 年に Microsoft DeveI 叩 er Division (DevDiv) に加わり、世界で最も人 気がある「個人向け」開発環境である Visual Studio (VS) を、世界で最も人気があ る「チーム向け」開発環境に変えるというビジョンに関与することになりました。 それはもちろん、顧客のために最新のソフトウェア工ンジニアリングプラクティス を取り入れるということでした。 同時に、 DevDiv は自分たちのアジリティを改善するという重大な課題にも直面 していました。我々のチームに求められたのは自らの文化やプラクティスやツール を見直すということであり、 つきませんでした。そして、 この先どれほど長い道のりが続くのか、私には見当も この興味深い旅は今も続いています。 ます、この仕事の規模をおさらいしておきましよう。 DevDiv の担当は、 VS 製品 ラインと . NET Framework を提供することです。この章では、 . NET Framework 2.0 を使用する VS 2005 と、 . NET Framework 3.5 を使用する VS 2008 のリリース を比較します。・これらのメジャーリリースは、世界中で何百万人ものユーザーが 使用しています。サポート契約の期間は 10 年です。 9 つの言語でローカライズされ ています。 3 , 500 人を超えるエンジニアが、このスタックのリリースに取り組んでい ます。 DevDiv が利用している Team Foundation Server (TFS) では、 20 , 000 , 000 個を超えるソースファイル、 700 , 000 件を超える作業項目、 2 , 000 件を超えるマンス リービルド、および 15 テラバイトを超えるデータを管理しています。・ また、自社製品とプロセスの「ドッグフーディング」も継続的に行っています。 これはつまり、顧客にリリースする前に社内で使ってみるということです。たとえば、 階層的なプロダクトバックログが初めて正式にサポートされたのは TFS 2010 です が、我々は TFS 2005 の時点で階層的なプロダクトバックログを実装しており、社 内で使用した経験に基づいて TFS 製品に変更を加えました。次の章では、社内で一 足先に体験し、 VisuaI Studio 11 ( 開発コード名 ) でリリースされる予定のさまざま なプラクティスについて説明します。 弊社製品をご利用いただいている多くの顧客と同様、我々も、 TFS を利用するに Visual Studio 統合開発環境、 TFS 、および ALM コンポーネント ( 以前の Team System) の細かい区別 はしないものとする。また、これらのメジャーリリースの合間に公開された数多くの強力なツールや lnternet lnformation Services (IIS) 、 ASP. NET 、 Silverlight などのリリースについても触れないものと する。 ンスについて説明している。 ①便宜上、この章ではこれらを VS 2 開 5 と VS 2 開 8 と呼び、 . NET プラットフォームコンポーネント、 ② Microsoft にはその他に約 30 個のインスタンスがあるが、ここでは私が直接扱った DevDiv のインスタ

3.2 スクラムでは、「プロダクトオーナー」がプロダクトバックログの保守を行います スクラムのプロダクトオーナーシップ スプリントを取り巻く多くの活動サイクルから、プロダクトバックログに情報が う。図 3-4 を見てください。 を求めます。ここで、プロダクトオーナーの仕事をもう少し広い視野で見てみましょ プロダクトオーナーはチーム全体および関係するすべてのステークホルダーに協力 ( スクラムの用語では、この作業を「手入れ (grooming) 」と呼びます ) 。そのために 取り入れられます。以下では、これらの点について詳しく説明していきます。 リリース 顧客 フィードバック ビジネス 価値 リリース 計画 リリース バックログ プロダクト バックログ 手入れ プロダクト フィードバック 潜在的に 出荷可能な インクリメント ディリ スクラム バックログ スプリント テスト 受け入れ スプリント △図 3-4 スプリント実行の外側で行われる多くのサイクルがプロダクトバックログに影響 を及ぼす。

6-6 バージョンのすれの防止 163 ・チームごと、機能ごと、または目的ごとに作業を分離する ( フィーチャー別 リリースパージョンを保守用とホットフィックス用に分離する ( リリース別 分岐 ) 分岐 ) 分岐を常にリリース可能で安定した状態に維持し、リスクを最小限に抑えることが 了した PBI は逆方向の統合で「メイン」分岐にマージします。これにより、「メイン」 岐プランの例を図 6-37 に示します。こでは、開発作業は「開発」分岐で行い、完 に影響を与えずに新しいことを試す目的で行うものです。 2 つの分岐を使用する分 実験的な分岐の作成があります。実験的な分岐とは、並行して進んでいる他の作業 作業の分離の例としては、大規模なチームを効率よくサポートするための分岐や、 できます。 チェックイン スプリント 1 チェックイン スプ丿ント終了 のラベノレ 順方向 の統合 スプリント 2 逆方向 メイン 分岐 開発 △図 6-37 逆方向 の統合 逆方向 の統合 チェックイン チェックイン ( ユーサー ストーリー 1 完了 ) チェックイン 競合の 解決 順方向 の統合 解決 競合の ストーリー 2 完了 ) ( ユーサー チェックイン チェックイン の統合 解決 競合の ストーリー 3 完了 ) ( ユーサー チェックイン チェックイン フィーチャー別分岐を行うと、チームは並行して作業を進めていき、完了基準を 満たした時点で変更を統合することができる。 分岐をよく使う状況としてもう 1 つ挙げられるのは、 1 つのソリューションにつ いて複数のリリースパージョンを追跡する場合です。これはたとえば、バージョン 1 をリリースした後に、ます分岐を行ってから、バージョン 2 の作業を始めるとい うやり方です。後でバージョン 1 のバグを修正したり、新しい環境用のサービスリ リースを発行したりする必要が出てきた場合は、バージョン 1 の分岐で作業をすれ ばよいため、バージョン 2 のコードに影響を与えずに済みます。このような分岐の ことをよく「リリース別分岐」と呼びます。分岐プランの例を図 6-38 に示します。

164 第 6 章開発 この 2 つの 「開発」分岐は シーケンシャルな タスクとして 作成されているが、 ひとまとまりの 作業である。 開発 - 1 ! 三 A サービスパック 「メイン」分岐が リリースできる 状態になったら、 「サービス / ヾック」分岐、 「ホットフィックス」分岐、 「 RTM 」分岐を 同時に作成する。 「 RTM 」分岐はリリース 内容の読み取り専用 コピーとなる。 RI (SP) RI (SPO) RI(SPI) R2(SP) 日 2 (SPO) ホットフィックス △図 6-38 これは、開発系のラインにはフィーチャー別分岐、メインのラインにはリリース 別分岐を使用した入念な分岐プランである。詳しくは http://vsarbranchingguide. codeplex.com/ を参照 Visual Studio では、分岐は特別な種類のフォルダーとして扱われ、特別なアイコ ンで表示されます ( 図 6-39 を参照 ) 。通常のフォルダーの機能に加えて、所有者と 説明が割り当てられており、分岐の関係は階層構造で表されます ( 図 6-40 を参照 ) 。 を判断できる。 凵色、リ 0 朝上 田一己 v ぎ、 81 田辷 11 田 [ 」メ「 0 ( e T 0 5 コ 日 5 、・ゴ t 。信に翻 e ( ー △図 6-39 異なるアイコンで表示される。これにより、作業対象の関連する分岐フォルダー TFS のソース管理工クスプローラーでは、分岐は特別な種類のフォルダーとして

9.5 予期せぬ結果の法則 253 9.5.2 いマネージャーの多くは、 MQ を策定せず、バックログの計画や手入れを行わすに 自信満々で仕事に取りかかりました。結果的に、 VS 2010 のリリースへの道のりは 大幅な後戻りを何度か経験することになりました。 これは 1981 年の米大統領狙撃事件後の一幕を思い起こさせます。暗殺未遂によっ て Ronald Reagan 大統領が職務を遂行できなくなったとき、副大統領は海外にいて 不在でした。そこで、 Alexander Haig 国務長官がホワイトハウスの記者団を招集し、 冷笑を買うことになりました。なぜなら、 20 年前の憲法修正で定められた、大統領 権限の承継順序についての自分の無知を明らかにしてしまったからです。 VS 2008 「私がここを統括している」と発表したのでした。 Haig 長官はすぐに多くの人から の製品リリース後の再編では、いくつかのポジションが通常よりも長く空席になる こうして自ら宣言した権限はやはり機能しませんでした。 ことがあり、その間に、何人かがリリース計画を管理すると自ら名乗り出ました。 当然ながら、 きく、そこから我々はエンジニアリングに関するいくつかの教訓を得ました。 ありました。特に 2008 年のずさんなスタートと MQ の省略がもたらした影響は大 中で最高のリリースになりました。しかし、そこにたどり着くまでには紆余曲折が DevDiv はなんとか立ち直り、最終的に、 VS 2010 はこれまでの VS 製品ラインの ( 再び ) 得た教訓 オーナーシップが欠けていたことでした。その結果、 VS2010 の 2 つのべータ版では、 クログに適切な要件を設けていなかったことと、これらに対する明確なプロダクト 特に不注意だったのは、パフォーマンスや信頼性などの基本項目にまつわるバッ バックログはサービスの品質を保証する必要がある 判断基準に逆戻りしてしまいます。 べていい加減なものに見えます。そのため、各メンバーは自分の考え方に最も近い 顧客価値をはっきりと把握できるバックログがないと、優先順位付けの決定はす プロダクトバックログの計画と手入れは省略できない ロセスがなかったので、共通認識について再度話し合うことが必要でした。 行えず、考え方の競合を解決することができません。当時はまだ一貫した組織的プ プロダクトオーナーシップがあいまいでは、バックログの明確な優先順位付けが プロダクトオーナーシップには明示的な契約が必要である

第 9 章 Microsoft DeveIoper Division で得た教訓 252 0 VS 2008 の Beta 1 でのバグ負債の合計 VS 2005 と VS 2008 の Beta 1 時点でのバグ負債の比較。左側のチャートは図 9-2 と同じものであり、右側のチャートは VS 2008 の Beta 1 に到達するまでのバグ 負債の合計を示す。製品サイクルのほぼ同等の段階で比較して、バグが 30 , 000 個 から 2 , 000 個に減っていることは大きな改善である。 0 ・、 4 つ ) △図 9-10 予期せぬ結果の法則 VS 2005 から VS 2008 への過程で達成した改善はまぎれもなく現実のものでした が、後で驚くことがいくつかありました。ニュートンの第 3 法則にもあるように、 作用には反作用がありますが、ときにそれは望ましいものだったり、望ましくない ものだったりします。 DevD ⅳの場合は、人にかかわるソフトな問題による反作用と、 工ンジニアリングプラクティスの不測の影響の結果による反作用がありました。 Microsoft では、製品リリースにこぎつけると通常は人事異動が行われます。社員 にとって、この人事異動は、キャリアを開発し、新しい挑戦を行って個人の満足度 を高める好機です。実際、 Micr 。 soft のいくっかの部署では、再編期間をリリース計 画の始めに組み込んでいます。これは企業にとっても社員全体にとっても健全なや り方ですが、短期的には一種の記憶喪失状態を生み出すことになります。 共通認識には更新が必要 9.5.1 残念ながら、長期的な習慣を作るには 1 つの成功だけでは足りません。 DevDiv は、 2008 年に製品リリースを無事に完了した後で、過度の楽観主義に陥りました。新し