アジャイル と生産性・１

生産性には２種類ある

エンタープライズアジャイル導入・定着を支援する現場で、次のような質問を受けることがよくあります。
「アジャイルを導入すると、チームの生産性は向上しますか？」
「アジャイルを初めて半年経つが、開発生産性が上がって来ない。どうしたら良いですか？」

これらの問いに対する私の答えは、こうです。
「アジャイルプロセスは、生産性向上の武器になります。しかし、ここで言う「生産性」は、あなたのおっしゃる「生産性」とは違うものかもしれません」

言葉遊びのように思えますか？しかし、これは単なるレトリックではありません。
日頃、私たちが無造作に使っている「生産性」という用語は、その測定方法によって「物的生産性」と「付加価値生産性」に分類することができます。

• 物的生産性：算出された製品やサービスの「物理的な量」（重量や個数など）によって生産性を測る。簡単に言うと「同じ条件でたくさん作る」＝生産性が高い

• 付加価値生産性：算出された製品やサービスに含まれる「付加価値額」（金額）によって生産性を測る。簡単に言うと「同じ条件でより多くの利益を出す」＝生産性が高い

「アジャイルと生産性」に関する誤解

アジャイルに関連して「生産性」という用語が使われるとき、文脈によって物的生産性と付加価値生産性が混在しているケースが多く見られます。 アジャイルプロセス導入の目的と、活動の合目的性を評価する成果指標とで、「生産性」の意味合いが変わってしまうのです。

もう少し詳しく説明して行きます。
アジャイル導入によってどんな効果を得たいか？という問いに、多くのチームが
「開発スピードを速くし、試行錯誤のサイクルを加速したい」
と答えます。 一方で、アジャイル導入の成果を測る指標について聞くと、
「開発チームのベロシティを○％向上させる」
「過去の同規模の案件と比較して、開発期間を○％短縮する」
等の定量目標を設定しているケースは少なくありません。

両者の関係を、注意深く見ていただきたいと思います。

アジャイルの目的は付加価値生産性向上

「アジャイル導入の目的」として語られているのは、「付加価値生産性を向上させる話」と言えます。
今日のプロダクトやサービスの開発では、何を作るべきかに関する「正解」はなく、探索的に「最適解」を見つけることが求められています。
こうしたビジネス環境下では、「いかに少ないトライで最適解にたどり着くか」が重要です。
これは「産出量あたりの付加価値を増やす」という命題であり、付加価値生産性の向上にほからならないのです。

アジャイル導入の効果を測るモノサシは物的生産性？

一方で、「成果指標」の方はどうでしょうか？
こちらは、単位あたりの産出量を増やすこと、すなわち、物的生産性の向上を目指しています。
「ベロシティを成果指標にするのは、アジャイル開発のアンチパターン」という「常識」が定着しつつある昨今では、ベロシティ以外の目標（例えば開発期間など）を掲げるチームも増えています。
しかし、表現方法こそ違っても、「開発チームがバックログをコードに変換するスピード」つまり単位あたりの算出量にフォーカスする考え方は、「物的生産性を向上させる話」です。

目標と成果指標の「ねじれ」がひずみを産む

では、開発チームの物的生産性を向上させることは、事業の付加価値生産性向上につながるのでしょうか？

この問いの答えは「否」だと私は考えます。
無論、すべての開発チームにおいて物的生産性向上に価値がない、と言いたいわけではありません。
たとえば、新しい技術を習得する途上にあるチームや、若手エンジニアを中心とするチームにおいては、ベロシティの向上と安定は重要なテーマです。

問題は「速くたくさん作る」能力だけでは、競合との差別化は実現できないという点にあります。
達成したい目標（事業の付加価値生産性向上）と、成果指標（チームの物的生産性向上）との間に「ねじれ」が生じているのです。

アジャイル導入の目的（事業としての付加価値生産性向上）と、手段（ソフトウェア開発チームの物的生産性向上）の「ねじれ」を放置したままでは、開発チームの努力を事業成果につなげることは困難です。
その結果、次のようなことが起こりがちです。

• IT部門は設定した目標を達成しているのに、事業全体としての効果が実感できない

• プロダクトやサービスの運営は「イイ感じ」に回り始めたが、IT部門の貢献度を定量評価することができない

冒頭に紹介した「アジャイルで生産性は上がるの？（上がっているの？）」という悩みも、同じ根から派生する枝です。

目標と成果指標のねじれが生じる構造

では、なぜこのような「ねじれ」が起きるのでしょうか？
主要な原因は「分業」にあると私は考えています。

日本の伝統的な企業の多くは、機能別に分割された組織構造を持っています。 プロダクトやサービスに関しても、企画、マーケティング、IT、営業、オペレーション関連、管理・監査関連、といった多くの機能をそれぞれの部門が分担して事業を遂行しています。
事業活動の評価と深く関わる個人の目標設定も、部門内で完結するケースがほとんどでしょう。

この構造が効果を発揮するためには、機能の境界が安定していることが重要な要件となります。そして、そのためには、事業活動の「正解」が明確になっている必要があるのです。
各部門の責任範囲とやるべきことが明確になっているならば、分担して、それぞれの役割を全うすることが全体の成果につながり、効率的でもあります。

しかし、今日のプロダクトやサービスの開発・運営では「これをやればうまく行く」という正解の活動がわかりにくくなっています。 リリースすべきフィーチャー、実施すべき施作は、試行錯誤を通じて探索するしかなく、必然的に部門間の役割分担も揺れ動きます。
反面、人事評価とも関連する指標設定や評価に関しては、厳然たる部門の壁があります。 現実の事業活動においては他部門と連携して動いていても、成果指標の設定においては、他部門の「縄張り」に踏み込めない不文律が存在するのです。
この結果、成果指標は自部門マターに閉じた項目に限定され、現実の事業活動の一部しかカバーできないものになって行きます。

多くの企業にとっては常識ともいえる「機能別の分業」が、アジャイルプロセスの効果測定を分かりにくくしているのです。
これが、先に述べた「目標と成果指標（目的と手段）のねじれ」が生じる構造であると、私は考えています。

アジャイルの効果を正しく評価する方策

この難題に対する根本的な解決策は、エンドトゥエンドのチームを作って成果を評価すべきだ、ということに尽きます。
平たく言えば「機能別の分業をやめる」ということなのですが、現実問題としては、いきなり根本解決に飛びつくことができる組織は、多くはありません。
そこで、私たちは、エンドトゥエンドのチームが実現するまでの過渡期的な手段として、物的生産性向上に代る開発チームの評価方法を提案しています。

次回は、アジャイルプロセスの効果を合理的に評価する、成果指標設計について解説します。