人はどんなときに開発生産性を考えるのか

開発生産性に関する次の記事がQiitaのトレンドに入っていました。

この記事は、たしかに開発生産性について様々な観点が羅列されていましたが、Twitterを眺めていると、今ひとつ主旨がわからなかったという人もいたようでした。
なるほど、たしかに個々の事実の羅列を通して、その結論が「開発生産性を考える事は一般に難しく、またセンシティブである」みたいなことであったとするならば、「結局何が言いたいのか」という感想にも一理あるように思います。
そこで、この記事では、そもそも人はどんなときに開発生産性を考えるのか、ということをいくつか分類して考えてみたうえで、開発生産性についての記事を読んだ上で"実践"する場合にどんな事に気をつけるべきなのかを考えます。

シチュエーションを分類する軸

開発生産性を向上したいのか、したくないのか

開発生産性について考えるとき、その開発生産性を向上することが目的なのか。それとも、必ずしも開発生産性の向上は目的ではないのか。
例えば、単純に作業量などを評価する材料に開発生産性を使いたいという場合には、必ずしも直ちにその向上が目的ということではありません。これは意外かもしれませんが、例えばどら焼きを生産する機械Aが一定時間に生産できる量を測定することは、「この機械が何台あれば必要などら焼きを時間内に作れるか」あるいは「受注したどら焼きをすべて生産するにはどれぐらい時間がかかるか」かもしれません。
これは所要時間について概数で予測を立てるためかもしれませんし、根本的に開発生産性を向上したいのかもしれません。

現状に問題があるのか、ないのか（あると思っているか、ないと思っているか）

現状について問題意識があるかないか。つまり、開発効率が低いとなんとなく思っているか否か。
もし、現状に問題があるという意識が先行しているとすれば、開発生産性の測定が直ちに糾弾になるような場合もあり得ます。
そういった問題意識はないが、単に測定して改善する方法を検討したい、という事かもしれません。

2つの軸の組み合わせパターン

この2つの軸の組み合わせだけでも、以下のようなパターンを考えることができます。

問題解決：向上したい・問題あり

現状に問題があって、それを解決したいという場合です。この場合の目的は、ずばり改善による問題の解決という事になるでしょう。
ただ、この場合は問題ありと思っていても実はそこには問題がなかったり、直接的な解決が容易ではないといった場合も考えられます。その場合には、損切りができずに苦しむといったケースも考えられます。そもそも本当に問題があると言えるのか、という事をフラットに問うことが必要と思われます。

糾弾：向上したくない・問題あり

現状に問題があるが、それを向上することが目的ではないという場合です。この場合に厳しいパターンとしては「問題点を糾弾するための材料を探している」といったものがあります。あるいは、解決できない問題点を示すことで、現状が改善不可能であるという議論にも使えます。いずれにしても、これだけを切り取るとあまり建設的ではないようにも感じますが、一方で損切り・判定等には有効な事もあります。

改善思考：向上したい・問題なし

現状に特に問題は無いと思われるが、より改善をしたいというポジティブな考えです。
それ自体はよい事であるようにも思われますが、この考えに基づいてオーバースペックな改善をしてしまう可能性もあるので、直ちに全面的に良い考え方であるとも言うことはできません。特に、この改善を行うこと自体の生産性があるのか？といった事にも目を向ける必要があります。

興味：向上したくない・問題なし

シンプルに、ただの興味です。ひょっとすると問題があるかもしれない、というのもこれに分類されるかと思います。
状況を把握することは重要と思われますが、一方で目的なくコストを使って情報を仕入れて考えるとしたら、それは非効率かもしれません。

どのシチュエーションかによって返すべき言葉は異なる

仮に経営者が開発生産性について知りたいと思った場合にも、この4つのどのシチュエーションであるかによって、返すべき言葉・進めるべき議論は変わってくると思います。つまり、いずれの場合であっても「開発生産性が多義的である」という事には意味がある上に正しいですが、しかしただそれを述べたのでは、会話として噛み合いません。極端な事を言えば、そのような知識の羅列をする事自体が経営者の求めている行動ではないという可能性もあります。

一般論として、開発者が機能を実装するときには、非開発者が作って欲しいと言った機能をただ実装しようとするのではなくて、そもそもその機能がなぜ必要なのか・その目的を達成するのに本当にその機能実装がベストなのかといった事を考えるべきである、などと言われます。
それに照らせば、経営者が開発生産性を知りたいと言った場合にも開発者は同じような行動をとるべきで、つまり「なぜ開発生産性を知りたいのか」を問うて目的を確認することが重要であるように思います。そこで必要なのは多様な生産性を羅列的に定義していくという事ではなくて、まず何のために生産性を知りたいのかを明らかにすることである、ということです。
その上で、目的に合わせた適切な開発生産性の指標があるとすれば、その指標を提案検討するといった事は有効です。

同じことを言い換えると...
ある機能を開発実装したいと問われた時に、その機能を実現し得るアーキテクチャをいきなり知っている限り全て並べて経営者と共有しようとする、例えばデザインパターンを全て列挙して共有しようとするのは、すごく理解のある経営者であれば効果的かもしれませんが、普通の開発者が時間をかけてようやく理解する事について経営者が概要理解する事を求めるのは、現実的ではないように思います。
仮に、羅列的な知識を経営者に理解することを求めてしまったとしたら、まさにそれと同じような事をしているのではないかな？と思います。多分、実際に必要なのは、そういう事ではないですよね。

まとめ

開発生産性を分類して把握することは有用ですが、それを直接的に経営者にぶつけたりすると、「結局何が言いたいの」となってしまう可能性があります。様々な開発生産性があることを踏まえて、「結局あなたは開発生産性を知ることで何をしたいのか」という、その目的を大事にすると、いろいろな話がスムーズになり、実りがあるかもしれません。

おまけ

不用意に非開発者と開発者の間で開発生産性についての話をしようとすると、意見が食い違って分断が発生する元になる場合があります。
一般に、分断を防ぐにはどうすればよいのか、といった事について考察した記事を書きました。もし興味をお持ち頂けたら、ぜひ次の記事も一読ください。（相互リンクしています）