開発チームの改善効果を定量データでアピール！：今日からできる“CMMI流”開発効率改善術（4）（2/2 ページ）

[矢部智, 岡本隆史，＠IT]

目的とプロセスの尺度マトリクス

　CMMIでは、「測定の目的を明らかにする」ことを重視しています。目的とは、例えば「出荷時の品質を担保する」「ユーザーストーリーを実現する」「決められたコスト範囲に収める」といった、ビジネスや開発作業のあるべき姿から設定されるものです。

　次に、測定の基本的な単位として「プロセス」を意識しています。ここでのプロセスとは、ウォーターフォールモデルでしたら「フェーズ」になりますし、スクラムのライフサイクルモデルではスプリントの中の「タスク」といったものを指します。本質的に違う活動は、分けて測るという意味です。

　なぜプロセス単位で測るのが良いのでしょうか。これは「プロセスごとに分けた場合」と「分けずにプロジェクト全体で測った場合」を比較してみれば分かります。「全体の工数が予定をオーバーした」というよりも「要件分析に時間がかかった」という方が、原因が分かりやすいし、対処もしやすいのです。

　これをまとめたのが、目的とプロセスの尺度マトリクスです。

表2 目的とプロセスの尺度マトリクス

　このようにマトリクス形式を用いると、「目的があるのに尺度がないプロセス」などの抜け漏れが確認できるメリットがあります。開発経験が長い組織でも、意外と抜けている尺度があったりするので、一度試しに作ってみてください。

　また、目的がないのに尺度だけある場合はその尺度を廃止できるので、測定にかかる人的コストの無駄をなくすこともできます。

　スクラムでは、規模は全タスクを通じて実現する機能の大きさをチーム内の相対的な

尺度として表したストーリーポイントが使われます。品質については、チームで決めるタスクごとの完了基準（「DONE」の定義）によります。例えば、テストのカバレッジを基準にすると決めたら、そのチームのテストタスクではカバレッジを尺度とします。

　マトリクスではサンプルの尺度を記載していますが、これらはあくまで例で、特定の尺度を推奨するものではありません。尺度はチームや組織の目的、事情に合わせて定めてください。

　尺度の定義ができたところで、実際にどう使うのかを事例で見てみましょう。

3ステップで測定方法を考える

　以下では、単一チームの測定と分析の方法を、テスト自動化ツールの導入という例を用いて説明します。単一チームというのは、同一か類似製品の機能追加開発を繰り返し行っているような集団で、ほぼ同じメンバーが開発に関与しており、開発プロセスもほぼ同じという前提です。

　今回のチームはWebアプリケーションを開発しており、テストの効率改善のため、システムテストの自動化ツールであるオープンソースソフトウェア「Selenium」を導入する予定です。改善の前後を定量的に比較するための測定を行うと仮定します。

　テスト自動化ツールの導入は近年盛んです。「便利だ」「よりクリエイティブな作業に集中できる」という意見がある一方で、「便利なのは分かったが、結局、ビジネスに対してどれくらい貢献したの」という問いに対してはきちんと根拠あるデータを出して説明できているわけではありません。ここが課題と言えるでしょう。

　測定のやり方は、大きく「計画」、「測定実施」、「評価」の3つのステップに分けて考えます。このステップは、テストを開始する前までに検討してください。テストが終わった後に「どうやって評価しよう」と悩んでも、後の祭りです。

ステップ1：計画

　測定の目的は、テスト自動化ツールが「あなたにとって便利か」ではなく「ビジネスに貢献したか」を説明することです。どんな尺度を測れば、ビジネスに貢献したと言えるでしょうか。

　テストを自動化すればテストにかかった時間は減るので、コストも減る、すなわちビジネスに貢献したと考えるなら、テストのコストやテストの工数を測れば良いでしょう。

　そうではなく、テストを自動化して、よりクリエイティブな作業にリソースを振り分けることにより、顧客に提供できるシステムの機能（ユーザーストーリー）を増やすことがビジネスへの貢献だと考えるなら、スプリント1回あたりのストーリーポイント、つまりベロシティを増やすことが重要でしょう。

　このように、改善のための尺度は一律に決まるものではなく、改善の目的に合わせて、その都度尺度を決めることが必要です。

　ここではいったんコスト削減をビジネスの価値としてとらえ、工数を尺度に選んだとします。すでにプロセス単位に分けて測定しているなら、システムテストプロセスの工数に着目します。次に、Seleniumがシステムテストの工数のうち、どの部分にどんな変化を与えるかの仮説を立てます。

　システムテストを大まかに分けると、「準備（環境構築やテストケース作成など）」「実行」「後処理（バグ対応など）」となります。Seleniumでどの工数が減るかというと、実行の部分だけです。それぞれの工数の比率があらかじめ分かっていれば、ツールを入れたときの効果はシステムテスト実行の工数の範囲内であることが予測でき、ツールを導入する前に「これだけ減る予定ですからやりましょう」と主張できるメリットがあります。

図1 自動化によるテスト工数の改善

　さて、皆さんのチームにおいて、準備、実行、後処理と細かく分けた工数データはすでにありますか。通常はありませんよね。私もそんなに細かいデータを取っているチームはほとんど見たことがありません。では、せっかくツールを入れるタイミングで、わざわざ比較のためにツールを使わない場合のデータをこれから収集するのでしょうか。それもおかしなことです。そこで、過去に細かい単位でデータを取っていなかったときに何ができるかを紹介します。

　やり方は簡単です。システムテストを行っている人たちにアンケートを取ります。準備、実行、後処理という3つの区分で、どれくらいの割合の工数を要していますかと。

　アンケート方式なら、あらかじめ全てのデータを細かく測っておく必要はありません。アンケートデータは5人、10人と集めれば、平均値はだいたい妥当な値に落ち着きます。

　精度は高くありませんが、トレンドはつかめるので、「この程度減る予定です」と客観的に説明できます。

　アンケートデータが分析できたら、測定実施のステップに進みます。

ステップ2：測定実施

　システムテストの準備、実行、後処理の工数をそれぞれ測ります。測るときの注意点として、測定を行う人（この場合はテストをする人）に、事前に測定の目的と、測定方法をトレーニングしておくことです。工数を分けて測定するのはなぜか、それを実施するとどんな良いことがあるのか、準備というのは作業でいうとどこまでで、実行はどこからどこまでなのか、データの投入方法やタイミングはいつかなど、一通りのことは資料にまとめてレクチャーすると良いでしょう。

　測定を始めた後も、人によるばらつき、測定ミス（特に新しい測定項目を追加した場合）が発生する可能性があります。最初の数日間は測定データが正しく投入されているか監視するなど、こまめにフォローをすると良いでしょう。

ステップ3：評価

　計画時にアンケートで予測したデータと実績を比較します。

○ほぼ計画通りの場合

　効果が予定通り証明できました。このデータをほかのチームにも紹介して、ツールの利用範囲を増やせるかを検討しましょう。

○計画を下回った場合

　事実を基に振り返りましょう。自動化できるテストが少なくて、実施の削減が思うようにいかなかったのか、自動化するテストの準備に思ったより時間がかかったのか、副作用みたいなものがあったのか、原因はいろいろ考えられます。この事実を基に、今後も続けるのか、やめるのか、ほかのツールに変えるのかについて考えるきっかけにします。

○計画よりよくできた場合

　この場合も振り返りましょう。アンケートによる予測が誤っていたのか、副作用で思わぬ良い影響があったのか、今後自動化ツールを使う予定の別のプロジェクトでも同じ条件なのか、などを分析します。

　以上が単一チームにおける定量的な改善効果の測定です。自動化のメリットを説明するために、明確に目的を決め、アンケートを活用することにより、少ないデータ収集で客観性のあるアピールにつなげることができました。

　上位のマネジャーへも自動化ツールのメリットをカタログの受け売りではなく自分たちの実績データで説明できるようになるので、組織全体への普及展開もよりスムースに運ぶのではないでしょうか。

---

　測定によって改善の効果が定量的に実感できると、仕事のやり方を変えていくことが楽しくなり、それに触発されていろいろなメンバーからより多くの改善提案が出てくる活発な組織になっていくのです。何かを改善したいと思ったら、変更する部分だけで良いので、今回紹介したような方法で測定してみてはどうでしょうか。

　次回は、組織全体で定量的な改善を進めていく上での注意点について説明します。

著者紹介

▼矢部 智（やべ さとし）

NTTデータ

SEI認定CMMI(SCAMPI)高成熟度リードアプレイザー、SEI認定CMMIインストラクター。日本人資格者としてCMMI V1.2以降で初のレベル4以上のCMMI評定を実施。ソフトウェアプロセス改善全般に取り組み、CMMI評定を中心としたプロセスアセスメント（30回以上）、ソフトウェア開発における定量データの分析、プロセス改善教育、標準プロセスの作成支援などを行っている。

▼岡本 隆史（おかもと たかし）

NTTデータ

認定スクラムマスター。OSSのプロジェクト管理ツールのスクラム対応の強化や、分散バージョン管理の勉強会、執筆を通し、オープンソースで企業が気軽に導入できるプロジェクト管理ツールの開発を進める。業務ではクラウド基盤の研究開発に従事。