僕の職業はアジャイルコーチだ。いろんな組織やチームの課題を解決するお手伝いをしながら、自分たちで問題を解決できるように、組織、チームや個人をバージョンアップするのが仕事である。最近、たてつづけに「開発生産性とは何か？」について考える機会があった。そこで「生産性って聞くととても嫌な感じがするのはなんでなんだろうね？」と後輩との1on1で話してみたら、いろんな発見があったのでまとめておく。
開発生産性は計算しにくく活かしにくい
生産性の計算は面倒くさい。たとえば、プログラマの場合、さまざまな変数を計測して総合的に判断しなければならない。たとえば、「品質が高い」とは以下を指すはずだ。
- コードが短く読みやすいこと
- コードにバグがないこと
- 短い時間で良いコードが書けること
- 要求を汲みとったコードになっていること
- ・・・
よく勘違いされるのだが、ベロシティだけで生産性は測れない。上記のように、それ以外の変数も合わせて総合的に計算する必要がある。
そして、生産性がわかっても、次に繋げるアクションも難しい。いったいどうやって生産性の高いプログラマを育てていけばいいのか？ 時間もお金もかかる。
これらを数値化する/していくコストと、それを得た後に得られるメリットとどちらが大きいのだろう？
わざわざ詳しく調べなくても、気がつけるチームであれば「なんかこのスプリント、バグが多かった気がする」みたいな意見がでてきて、ふりかえりで議論されるだろう。
だったらそれでよくね？
昔、似たようなことにチャレンジしたことがあるが、チームの負担と得られるメリットを加味すると、「やるメリットがまったくない」という結論にいたったことがある。
開発生産性情報を提供する人のメリットがほとんどない
生産性を考える人はマネジメント層が多い。そりゃ、ビジネスなので、開発に投資した金額分、売上が上がっているか、マネジメント層が気になるのは当たり前だ。
ただ、「1分で終わるから、どれぐらいの時間がかかったか毎日報告してほしい」を100人の社員にお願いするだけで、一日100分失われる。先にも書いたが、これに見合う結果を得られるのかを考える必要がある。生産性を数値化することがゴールになってしまうケースもたまに見かける。これじゃ、現場は骨折り損のくたびれ儲けだ。
もう一つ大切なのは、情報を提供した側にどれだけのベネフィットがあるか？だ。
今丁度読んでいる「PMP教科書」には、出典が何かはわからないが「スクラム手法では競争やチーム比較は動機づけにならない」という記述があった。ベロシティを比較したがる顧客も多いが、先にもあるようにベロシティだけを比較できないし、競争しだすとおかしくなる。
生産性に限らず、社員に何かを強いるときに、その価値を説明しきれていないマネージャが多いように思う。
「いいからやれ」や「周りと比べてどうだ」は、動機づけにならない。
開発生産性の範囲が広すぎる
開発には様々な人が関わる。それぞれが役割を果たしながら開発する場合、それぞれの生産性をどうやって数値化すればいいのだろう？
たとえば、プロダクトマネージャの生産性のひとつに「良いアイデアを出してビジネスに貢献できているか」があるとする。たとえば、アイデアは素早くだせた。しかし、様々な要因でデリバリに時間がかかってしまった場合、このプロダクトマネージャの生産性は高いのだろうか？
たとえば、「バグを早急に検知し、市場に問題をリリースしない」ことを生産性と定義したテスト部隊が、時間をかけて念入りにバグを潰した。しかし、デリバリが遅れて強豪に先を越され、ビジネス的な損失が生まれてしまった。テスト部隊の生産性は高いだろうか？
生産性の高いグループがあつまれば、そのプロジェクトは生産性が高くなるのだろうか？
従来型の計画重視型のプロセスだと、それぞれのプロセスと役割とチームが比較的分離されているので、各自の生産性向上が、全体の向上につながるかもしれない。
しかし、昨今の複雑なソフトウェアであったり、さまざまな役割がもとめられる開発チームの場合、生産性そのものが複雑であり、それぞれがつながっているため、一部だけ向上しても意味がないし、全てを向上させるのも難しい。
となると、「だったら成果で測ればいいじゃん」という話になる。
開発生産性に対する価値観は複数ある
後輩との1on1で、「生産性はその人の価値観に左右されるのではないか？」ということに気がついた。
ひとつめは、「出力（Output）」を価値観とする生産性だ。
出力を監視したいわけだから、従業員が1日8時間効率的に働いているかどうか？ リモートでサボっていないか？をいつも気にする。マニュアルワーカー。消費した時間に価値を置く前時代的工業的な思想だろう。監視ソフトを社員端末に入れたり、活動した時間を記入させたりしている企業もあると思う。
ようするに、社員を信用していない。
おそらく、こういった価値観を持つ生産性の現場では、自己組織化したチームに権限を移譲していくスタイルを好むアジャイル開発は向かない。デリバリスピードや価値提供よりも、出力のほうが大事だから、向かないと言うより、そもそも思想が合わない。
余談だが、後輩とは「1日8時間働いたらいい結果になるとはかぎらない」、「倍働いたら倍の生産性になるとは限らない」と、出力重視型生産性には否定的な意見が多く出た。まぁ、僕らがアジャイル開発を信じているから仕方ない部分もある。
ふたつめは「成果（Outcome）」を価値観とする生産性だ。
これまでは計画重視だったので、決められたものを高出力で作れば問題なかった（今の時代もそれでうまくいくものはそうすればいいと思う）。
しかし、今は不確実性が高い時代なので、いくら出力が高くても、無駄なものを作っていたら意味がない。ナレッジワーカーが必要で、時間よりも成果や価値に重きを置く。セオリーとしては、チームを信じ、管理よりも裁量をあたえ、支援していく形が取られる。
これらの価値観は、それぞれが両極端にあるので共存できない。だから、お互いがお互いに対して嫌悪感を感じてしまうのではないかと思う。そら話が合わんよね。
＊
僕は性格上、管理されたくないし、信用されたいので、後者を選ぶ。ただ、前者を選ぶ人をどうこう言うつもりはない。こういうのは本人が選択すればいいだけの話だ。
ただ、もし、後輩にこの話をするときにはいつもこういうたとえ話をする。
自分の生産性をがんばって高め、2倍の生産性になったとしよう。2倍働くのと、2倍の給料もらうのではどっちがいい？
旅と子育てとアジャイルコーチのブログ「世界」 