2017年6月14日にエンタープライズアジャイル勉強会主催のイベント「製造業アジャイルの集い」が開催されました。本イベントは製造業におけるアジャイル開発の関心が高まっていることを受けて開催されたもので、多くの方が参加され非常に盛況なイベントでした。当日は、スクラムの成功事例や、ご講演者の体験に基づくアジャイルを展開する上で必要なヒントについての講演を聴くことができました。本記事ではこれらのご講演内容をレポートします。
なお、本記事は記事中の見出しも含め、筆者なりの理解で記載したものです。その点についてご了承ください。

目次

• 「スクラムの成功事例」 Scrum Inc. Joe Justice 様
• 「16年目の話」 関 将俊 様
• 「DevQA: アジャイル開発における、開発とQAのコラボレーション ～エンタープライズアジャイルにおけるQAを考える～」 株式会社日新システムズ　品質保証部　永田 敦 様
• おわりに

講演「スクラムの成功事例」

講演者：Scrum Inc. President Scrum in Hardware, Joe Justice様

講演ではScrum Inc.が製造業を含むさまざまな企業のプロジェクトをスクラムで成功に導いた多くの事例をご紹介いただきました。この中からいくつかの事例の概要をお伝えします。

• 講演資料
  （講演資料の62ページ以降はご講演の中で紹介されなかったため本レポートでは触れていません。）

Medco社の事例：締め切りベースのリリースプランニング

最初はアメリカMedco社（処方箋薬を提供する薬局を開設している会社）の事例です。新システムのリリース期日が間に合わないことが発覚、Scrum Inc.の支援によってスクラムでプロジェクトを立て直し、最終的に新システムの提供機能は狭めながらも締め切りベースのリリース計画によって期日どおりに新システムをリリースした経緯が紹介されました。

約束したリリースに間に合わない

2006年7月、Medco社のCEOはウォールストリートのアナリストに、まったく新しい薬局システムを1年後の2007年7月に提供することを約束。しかし、開発チームに開発期間の確認はしておらず、1年での開発が可能か分からない状態でプロジェクトがスタートした。社内で2006年7月～12月の約半年かけて見積もった結果、新システムは2007年7月には間に合わず1年は遅れそうなことがわかった。そこでMedco社は支援を受けるため2007年12月末にScrum Inc.に相談を持ちかけた。

スクラムでプロジェクトを立て直し

• リリース計画とスプリントの実施

  • 2007年1月からScrum Inc.チームが1週間のリリース計画を実施。計画したリリースポイント数は1000ポイントだった。一方、ベロシティは60ポイント。予測はできたのはよいが、このままでは約束の期日に間に合わないことが分かった。

• ベロシティを上げるための実践

  • そこで、スクラムマスターが障害リスト（つまり、チームが幸せになるためのリスト）を役員に提示して11個の障害を解決したところ、ベロシティは90ポイントに向上した。しかし、これでも約束の期日より2ヶ月遅れの2007年9月完了予定だった。

• バックログを減らすための実践

  • 次に、チームはスクラム緊急手順 Scrum Emergency Procedure を実行し、当初計画していた790ポイントを、2007年7月にリリース可能な550ポイントに絞って開発した。

• 結果

  • 約束した2007年7月に新システムを稼働することができた。

スクラムマスターとプロダクトオーナー双方で成功に導いた

スクラムマスターがベロシティを上げる努力をした。また、プロダクトオーナーもがんばり、締め切りベースのリリース計画によって提供する機能を絞った（製薬処方ロボットを3つ開発する予定を1つに）。スクラムマスターだけでなくプロダクトオーナーも考えることで、結果として約束した期日に間に合わせることができた。

投資家をいかにつなぎとめるか

リリースごとにどれだけ売上げを上げられるか予測。投資家はポイントあたりの売上げを見て評価するようになった。たとえば、ベロシティが上がっていないことを見て、スクラムマスターが障害を取り除けるようにスクラムマスターを教育しなければいけない、という指摘が出るなど。最終的にポイントあたりの売上げは当初から比べて6倍に上がった。

本事例は以下の書籍の6章（chapter6）に詳しく紹介されています。
・Jeff Sutherland, JJ Sutherland , 『Scrum: The Art of Doing Twice the Work in Half the Time』, Crown Business, 2014
・ジェフ・サザーランド著, 石垣賀子 (翻訳), 『スクラム: 仕事が４倍速くなる“世界標準”のチーム戦術』, 早川書房, 2015

事例：分割戦略

つぎは、スクラムで複数チームが開発する際の分割戦略についての事例です。分割の仕方によって効率よく速くリリースすることができることが紹介されました。

• 分割戦略1：スプリントで結合テストまでできるモジュールの大きさに分割する
  • Wikispeedは車の開発をスクラムで分割して実施。各チームは一つのスプリントで開発からスタブを使った結合テストまでができる量のモジュールを受け持つ。

    チームWIKISPEED は講演者のJoe Justice氏が創設。世界中から集まったボランティアがスクラムでグリーンカーのプロトタイプを作成している。世界をより良く変えることを目標としている。

• 分割戦略2：リスクと、テスト/認証時間で分割する
  • SAAB（スウェーデンの航空機・軍需品メーカー）はジェット戦闘機をリスクとテスト/認証時間で分割して開発。ウォーターフォール開発の同業他社と比べて、プログラムのコストを20%に抑えることができた。さらに、開発が遅れることなく6ヶ月毎に新システムをリリースしている。
  • SAABでは、4096人が1時間で情報を共有。デイリースクラムで解決できないものはスクラム・オブ・スクラムズへ、というように解決できないものを上へ上げていく。

図．SAAB Defense（ 講演資料 スライドより引用）

大規模におけるスクラムの他の事例

SAABのような大規模な他のプロジェクトの事例もご紹介いただきました。

• 3M-HISでは、スクラム・オブ・スクラムズが役員レベルまで上がっていく（エグゼクティブメタスクラム）
• デルタ航空とノースウェスト航空の合併プロジェクトでは10個のチームあったが、デジタルツールは使わずに大きな模造紙に時系列に付箋を貼ってプロジェクトの状況を把握した
• Rosetta Stone社の事例。複数チームで開発時、各チームがそれぞれバッファを持っておき、緊急に対処するべき問題が発生すればバッファを利用して他のチームに振り分けて対応した。

企業が生き残りナンバーワンであり続けるためにはアジャイルが必要

今や、スクラムは業種を問わずいろいろな分野で使われています。今後、企業が生き残るためにはアジャイルが必要であることが説明されました。

• いろいろな企業がスクラムを使うようになってきている。中には、教会の運営や教育に使っているところもある。eduScrumは教育にスクラムを適応した学校。
• 成長著しい産業ではスクラムを使っている
• 企業の平均存続年数は13年である。これを見ると従来型ビジネスの起業はより早く衰退することが予測できる。企業が生き残りナンバーワンであり続けるためには、アジャイルが必要。Tesla（米電気自動車メーカー）もアジャイルを導入しようとしている。

Microsoftの事例：ポイントで見積る、リリースサイクルを短縮する

Microsoftにおけるスクラムの事例です。時間での見積りよりポイントでの見積りの方が正確であると評価されています。

• ポイントによる見積もりの方が正確
  • Microsoftでは時間による見積りをしていた時は見積り精度が悪かった。時間でなくポイントで相対見積りを行うようにしたところ精度が上がった。
• 定期便リリースプランニング
  • 2005年以前は、MicrosoftはTFSの新バージョンを18か月おきにリリースしていた。スクラムを導入するようになって、リリースサイクルを3週間に短縮した。

最も高速に開発できるチームのプロファイル

アジャイルに開発する際、チームはどのように振る舞えばよいのか、高速に開発できるチームのプロファイルとその事例が紹介されました。

20年間4000社の研究によって明らかになった最も早いチームは、以下のスライドにあるとおり、専任（他のチームと兼業しない）、小規模、安定（80%同じメンバーをキープ）、同じ場所、職能横断、スウォーミング（完了するまで一つのユーザーストーリーに集中）、保護された（邪魔されない）です。

図．最も高速に開発できるチームのプロファイル（ 講演資料 スライドより引用）

以下の事例では、有効だったチームの振る舞いが紹介されました。

• 私たちvs彼ら問題
  • ProRail社（オランダの鉄道会社）の事例。私たちvs彼ら問題の解決が有効だった。従来あったチーム間の障壁をなくし、一緒にいることで障害が解決した。
• リリースチームとしてのスクラム・オブ・スクラムズ
  • プロダクトリリースに失敗し、スクラム・オブ・スクラムズを導入。毎日実施することでクロスファンクショナルが機能した。
• SimpliVityのベロシティ向上の事例
  • チームが一つのテーブルに集まった（8ポイント→11ポイント）
  • 作業時間を可視化することでさらにベロシティが上がった
  • パフォーマンスが高いチームの周りに他のチームが座り、パフォーマンスが高いチームの様子を見れるようにしたことでさらにベロシティが上がった

    Simplivityはハイパーコンバージドインフラのベンダー。2017年1月にHewlett Packard Enterprise（HPE）が買収した。

ハードウェア開発におけるスクラム

続いては車の製造における先進的なスクラムの取り組みについて紹介がありました。

• Wikispeedの事例。5人×5チームで車を製造する。一度に新車の開発、テスト、組み立てを同時に行うことで、1週間で新車の開発を行うことができた。
• Teslaは複数のロボットアームがModel Xを生産、組み立てる映像を公開した。車は1ヶ所に止めてロボットアームが複数出てきて作業する。各ロボットは単一工ではなく多能工。部品に変更があってもインターフェイスが同じであれば対応できるため、新しいバージョンにすぐ対応できる。これで一日一回新しいバージョンの車をリリースできる。

大規模プロダクトのためのScrum@Scale

前半にも大規模におけるスクラムの事例が出てきましたが、ここではScrum Inc.が提案する、スクラムをビジネス全体にスケールするためのScrum@Scaleが紹介されました。

• スクラムはオブジェクト指向組織フレームワーク
• チームを基本単位として、チーム間はPOのうち一人がチーフPOとして振る舞う
• 結合テストをデモしてチーフPOがリリース可能か判断する
• メタスクラムでチーム間のつながりを見直す

スクラムがうまくいかない場合、どうすればよいか

講演の最後に、アジャイル推進者が直面し得る、スクラムがうまくいかない場合にどうすればよいかを具体的なステップと共に教えていただきました。

どうするとスクラムが失敗するか（症状）

• 名前はスクラムだが実際はウォーターフォールプロセス：要求スプリント、実装スプリント、テストスプリントのように名前はスクラムでも、実際はウォーターフォールのプロセスである。
• 長大で詳細な要求仕様をバックログと呼ぶ
• 信頼とコミットメントの欠如：スクラムチームがサブグループに分かれてデイリースクラムを行い、それを管理職が監視する

どうすれば失敗したスクラムを救えるか（作戦）

作戦としてはスクラムを実装する。リリースバーンダウンチャートをかくために、スプリントバックログを作り、見積り、ベロシティを測る。以下、ステップに分けて説明する。

• Step1：完成の定義を変える
  • 旧：コードがチェックインしている → 新：リリース可能であるに変えた。これに対応するため、チームにテスターを加えた。
• Step2：プロダクトバックログを作る
• Step3：プロダクトバックログを見積る
• Step4：スプリントを実施する
  • 最初の2スプリントでベロシティを測った。1スプリント目は計画通りできず（見積り30ポイント、実績9ポイント）やる気が低下した。なお、ベロシティを測るため本当は3スプリント回したかったが時間がなく2スプリントで測定。
• Step5：現実を見つめる＆計画を見直す
  • バックログのポイント数とベロシティからリリース可能な日を予測すると、約束したリリース日より1年以上遅れることが分かった。
• Step6：バックログを減らしてベロシティを増やすための実践（ Medco社の事例 と同様）
  • バックログを減らすための実践（プロダクトオーナー）
    • スコープを減らす
      
    • インクリメンタルにリリースする
  • ベロシティを増やすための実践（スクラムマスター）
    • 障害（チームへのプレッシャー、効率の悪いビルドとテスト環境、チームワーク・規律・モチベーションの欠如、割り込み、非現実的な期待）を除く
    • 会社の優先順位を明確化（1.運用、2.プロジェクト、3.その他）

結果

ベロシティは25～30に向上。何も対処しなければリリースは1年遅れだったところを2ヶ月程度の遅れに抑えてリリースできた。

学びのポイント

最後にこの事例の学びのポイントが紹介されました。「自分の計画を信じてはいけない」「低すぎるベロシティはない。あるのは現実のベロシティと現実的あるいは非現実的な計画」「品質を作りこむ」「優秀な人が入るだけでは足りない」「劇的な改善は短期間で達成できる」など、製造業だけではなくアジャイルを推進する人が持ち帰りたいポイントが詰め込まれていました。

図．学びのポイント（ 講演資料 スライドより引用）

所感

講演で伺った数々の成功事例は気持ちよく耳に入ってきました。1年遅れだと見積もられたシステムがスクラムで立ち直り期日通りのリリース、チームを同じ場所に集めた結果ベロシティが目に見えて向上、4000人以上の大規模プロジェクトでも1時間で状況共有、新車の開発も戦闘機もスクラムで。これらの成功事例を聞くとナンバーワンであり続けるためにはアジャイルで、というメッセージも素直に受け取れました。 私にとってはスケールの大きい事例もありましたが、講演の最後のスクラムがうまくいかない場合どうすればよいかについては一つのチームレベルで適用できる話だったのでまずはここから学んでいきたいと思います。

記事中では触れませんでしたが講演では世界銀行のデータを使って、技術革新によって貧困層が減少する現象から、スクラム（技術革新）で世界の貧困層をなくす、というメッセージもありました。このような大きな社会問題にもスクラムが関わるのかと思うとドキドキします。

講演「16年目の話」

講演者：関 将俊 様

組み込み系で16年くらいXP（eXtreme Programming）をしているチームの体験をもとに、反復開発がうまくできていないことに困っている人に向けて、反復開発の難しいポイントに対応するためのヒントを教えていただきました。

• 講演資料

反復開発とは

反復開発がよさそうな理由

プロジェクトが終わったときもう一度やったらうまくいくような気になる。仕様、技術、やり方などについてあの時こうすればよかった、と作ることで分かることがある。また、不具合は上流工程で混入し、下流工程で発生することが多い。しかし、ウォーターフォールでは開発工程は順次進むが、問題が発生したときの戻りはnステップとなり手戻り・再作業が発生する。たとえば、テストで仕様不具合の問題が発覚したら、上流工程の要求定義に戻って再作業が発生してしまう。

それなら開発期間を繰り返すように、分けて開発してみては？

反復開発とは

一つの反復ではV字モデルの全行程をする。一つの反復で動くものを作る。次の反復では前の反復で作ったものを改造する。このとき、前の反復で気付いた知見を活かしながら開発する。この反復を繰り返す。ただし、気を付けないといけないのはじわじわ作るのとは違うということ。じわじわ、というのはV字の底に当たる単体テストあたりだけを繰り返すこと。単体テストだけが完了しても結合されていないと完了したと言えない。結合時に問題が発生するので、結合しないということは問題を先送りしているだけになる。

反復開発することのお得さ

反復毎に製品を確かめることは、不具合を確認するだけではない。製品を前にして様々なことを発見できる。製品を見たら欲しいものが変わる。

製造業では製品寿命が長く、開発期間も長い。反復開発のよさを活かして本来難しいが価値のある、よい「仕様」の開発がしやすい。

関さんの体験からのヒント

短期間で全行程を繰り返す反復開発ならではの大変さがあります。そこで、関さんの体験からのヒントを教えていただきました。まず、原則は「無理をしない」。みんなで無理をするのではなく、無理をしないですむように進めていくということです。それに加えて、反復開発において難しそうなポイントのうち、以下にご紹介するサブシステム間のペースの違い、工程別チーム間の壁、ストーリーの開発、についてどう考えて対応していけばよいかヒントを教えていただきました。

サブシステム間のペースの違い

大きなシステムでは全員同じペースではないかもしれない。ペースの違いから衝突が起こりがち（サブシステム別チームなど）。

ヒント

• 実はペースを混ぜても大丈夫。全体から見ればノイズ程度。ただし、結合されていない部分はリスクと認識し、結合された状態での確認は必要。
• 反復が揃うことは重要でない。
• となりのチームのペースを無理に変えない。遅いのではなく、実はタイミングが合わないことが不満なのかも。相手の都合を聞いてみる。
• うまくやるために、となりのチームの人たちも同じチームの人たちのように考える。

工程別チーム

工程別やロール別にチームを作る場合、チーム間が仲が悪くなりがち。

ヒント

• 自分の工程がうまくいっているかは製品で確かめる。
• 前後の工程がうまくいくようにする。

別の視点でのヒント

• 反復開発をしていると、開発者（プログラマ）はテスターのロールも含むようになるかもしれないがこれが自然。テストが得意になる。

ストーリー

要求分割のテクニックについて。要求を分割したのがストーリー。このストーリーにブレークダウンするのがとても難しい。

ルール

ストーリーは結合したシステムで確かめられること。価値があること。

おすすめの方法

• 起動、主処理、終了までのブランチしない単純なフローを見つける。まず、このフローの起動と終了だけ作る（ゼロ機能）。意外とめんどくさいが乗り越えると主処理のコードに集中しやすい。起動と終了の間を徐々に作り単純なフローに近づける。
• 次に、基本のフローに枝葉を増やす。

注意すること

作業管理にチケットを使っている場合、管理しやすいチケットを作ってしまうのでストーリーと合わなくなることがある。

所感

16年目の話、というタイトルが16年間XPを続けている関さんのチームのことだと理解したとき、これだけ長く続いているチームのすごさを想像して敬服しました。講演では反復開発で直面する難しさについてのヒントを分かりやすく説明していただきました。Joeさんのお話でパフォーマンスの高いチームを見ることで他のチームのパフォーマンスも上がるとありましたが、そういう意味で関さんのチームを見たいと思いました。

講演「DevQA: アジャイル開発における、開発とQAのコラボレーション ～エンタープライズアジャイルにおけるQAを考える～」

講演者：株式会社日新システムズ 品質保証部 永田 敦 様

本講演では、エンタープライズアジャイルにおける成果物の品質保証について、QAが早いうちから開発と一緒に品質保証に取り組むDevQAの考え方についてご紹介いただきました。

• 講演資料

QAから見たアジャイル開発の問題点をDevQAで解決

QAから見たアジャイル開発の問題点

• バックログの先送りが最後のスプリントに送られる（技術的負債）
• システムテストが終盤で、システムテストで漏れたバグが市場に流出する
• 要求のクリープ（なし崩し的な要求の変更、追加）が起こる。システムテストが終わらない。
• 大規模開発において複数チームのうち一つのチームが完了しないとき、リリースできない。また、リリースタイミングを終盤で合わせるのは難しい。

早期からQAが介入してシステムテストを実施する：DevQA

• 上記のような問題を解決するため、QAが開発の早い段階から介入してシステムテストを実施する
• 「組織パターン」でも4.2.29「品質保証を巻き込め(Engage Quality Assurance)」とある

DevQAの形

DevQAでは以下のように、DevとQAがフィードバックループを回して品質保証に取り組みます。

図．DevQAループ（ 講演資料 スライドより引用）

• QA→設計
  QAは設計に品質をフィードバックする（品質の見える化）。QAは品質情報提供サービスをする。
• 設計→QA
  設計からQAに必要な情報が渡る。必要な情報とは、QAが設計に品質をフィードバックするために必要な情報。情報を収集するためにQAが朝会、スプリントレビュー、振り返りに出ることもある（口出しするのではなく情報を得るために出る）。

DevQAの改善事例

最後にDevQAの改善事例として、QA、スクラムマスター、プロダクトオーナーが一緒に品質保証に取り組むことで従来に比べて品質が改善した事例をご紹介いただきました。

スクラムマスターとQAが一緒にテスト設計

スクラムマスターがQAと一緒にテスト設計した。従来のように、QAがシステムテストだけスポットで入るのでは製品の中身は分からない。製品を知っている人がQAをすればよい。テスト設計で足りないインプットはPO（プロダクトオーナー）に質問。スクラムマスター、QA、PO間のフィードバックを繰り返すことでテストケース、仕様が洗練されていく。

• フィードバックループによってQAが得たもの
  ドメイン知識（最初から入ることで仕様の認識違いが減る）、テストの情報、バグの報告に対する「仕様通り（バグではない）」という件数の割合が半減！など

• フィードバックループによってPOが得たもの
  QA視点での仕様改善や仕様漏れの指摘があるなど

開発がQAのテスト設計をレビュー

実施しているテストに無駄はないか開発視点でレビューする。

• フィードバックループによって開発が得たもの
  評価内容を設計段階から把握したためQA評価前にバグが潰せた、近くにいるためバグ修正に関する認識違いが減るなど

• フィードバックループによってQAが得たもの
  開発視点の指摘によりテスト設計の精度が上がる、QA前からフィードバックしているため品質の高いものが出てくるなど

DevQAの改善事例の効果

• DevQAを実行することで、従来の方法で進めたプロジェクトと比べ、QA前にバグが除かれた
• バグが65%減少し、コード品質が改善した

所感

印象に残ったのは開発とQAがフィードバックループを回すために、QAが開発チームに邪魔することなく入っていくということでした。コミュニケーションを取って信頼関係を築き、必要な情報を収集してテスト設計につなげると言うことです。私の立場はQAではないですが、プロジェクトの外からメトリクスを測定することがあり、その時にプロジェクトの情報をもっと欲しいと思うことが多々あります。開発チームに入っていくという方法があったのか、と驚きでした。

おわりに

本イベントでは三つの講演で企業レベルでのスクラムの数々の成功事例、XPを長年継続する成熟したチームからのヒント、アジャイル開発におけるQA、と言った非常にバリエーションに富んだお話を伺うことができました。この講演を通じて、私は基本的なことの大切さも改めて感じました。プロジェクトのゴールはよいプロダクトを市場に出すこと。そのためにアジャイルにプロジェクトを回し、チームをうまく機能させるための改善をしながら取り組むこと。チーム間の壁はしばしば障害になりますが、ゴールが明確でありそれを共有できていれば自ずとチーム間の壁もなくなることを改めて感じました。

写真は、講演後のパネルディスカッションの様子です。