TL;DR
立場によっては、組織全体の生産性の可視化が必要なのはわかる。
ただ、チーム単位での生産性の細かい可視化の話はちょっとこわい。チーム単位での生産性に関しては、ある期間にそのチームがどんな機能をリリースして、それがどうだったか、を評価して、をすればだいたい良いような。
生産性の可視化？
全然知らなかったんだけど、開発生産性の可視化を支援するSaaSがあると先日知った。こちら。
なるほど最近はすごい便利なものがあるなーと思った。
一方で、このツールと日々にらめっこしてるチームはなんか僕が目指したいチームではないなと思った。だから、僕はこういうツールは今の僕の立場としてはいらないなーと思った。
でも、組織に所属するエンジニアが100名、200名とか規模になってるようなとき、その組織のCTOなりVPoE、組織横断の課題を解決するチームなどはこういったツールは必要だとわかる。組織全体の課題を可視化することはメリットがあるだろう。需要があるのもわかる。だってFour KeysとかSPACEとかフレームワークが存在するくらいだし、世界中で必要とされてるんだろう。そりゃそうだ。
違和感の正体？
前述したようにこういったツールは、組織全体の状況を知りたい、というケースとかで助かることはわかる。
けど、普通の開発チームには不要だと思った。EMとしてこういったツールがないとチームの課題を解決できない、というのであれば多分それは別のところに課題があるんじゃないかしら。
さて、それでなんでそんな違和感あるんだろうなーと思っていたのだけど、個人の評価をする目的でコミット数とか稼働時間とかそういった指標を凝視してる、というのがなんか違うんではないか、という思いによると思う。多分それだけ。チーム全体としてその数値を追いかけるのはありかもしれない。が、それをチーム間で比べたりしてはいけない。これはやってしまいそうだけど多分劇薬だと思う。やったことないけど多分そうなのでは。
業界は違うけど、キーエンスの営業の人たちの働き方を見て感じたことが近しい。
世間でブラック企業と噂されるもう1つの理由が、労務管理が厳しいのではないかという見方だ。ネット上ではキーエンスの営業車が高速道路を猛スピードで走る動画が拡散され、競合他社からは「FA業界の宅配業者」と製品を速達する運び屋と揶揄する声も出る。一部報道では営業車にGPSが搭載され、10分単位で時間を監視されているとの話が伝わる。
ある現役社員は「年に数回行われる内部監査で、会社に提出していた営業時間と実際の時間にズレがあったとの指摘を受け、（営業車に）GPSがついていると思った」と話す。
引用：年収2100万円！｢キーエンス社員｣は激務なのか 現役社員やOBが明かした｢働き方の実態｣ | IT･電機･半導体･部品 | 東洋経済オンライン
まず、キーエンスという企業そのものはすごいと思っている。所属している方も色々理解した上で組織に属しているのだから僕がどうこういうことではない。
この話の是非はよく知らないけど、1時間あたりの生産性を追い求めてこういった管理をしている、という趣旨が記事には書いてあった。そういった方向が選択肢としてあることは理解できる。
が、僕個人はそういった文化には溶け込むことができない、多分数日持たない。
僕個人として、こういう生産性を追い求めるような環境というのはなんだか性に合わない、ということかもしれない。多分エンジニア界隈の方の多くもあまりこういった職場は好きではないのかな、と思っている。
他方、前述した通り、組織全体としてこういった指標のトラッキングが必要なことはわかっている。でも、それを個人レベルでトラッキングするべきではないだろうなーと感じている。
チームという単位でのみ、生産性や成長度合いを計測することは良いと思う。チームという単位での活動がソフトウェア開発活動におけるベストプラクティスであることは間違いないと思うし、個人の成果は誰かの貢献があってのこと。一昔前はものすごい能力あるエンジニアがガツッと成果を出していたかもしれないけど、今の時代はそういったことは少ない認識（ないとは言い切れないがまあ稀有だろうなと思う）。
ちなみに、その測定結果をチーム間で競争し合ったり、それを煽るような環境になるともう酷いことになると思う。少なくとも僕はそんな環境で働きたくはない。
だから、こういったツールは良いけど、導入した組織は、誰に、どう見せるか、そしてその結果をどう利用するか、というのは慎重に考えた方がいいと思う。ツールを提供している企業がその辺はさすがに注意喚起しているだろうなとは思うけど。
まとめ
そんなわけで、ツールそのものが必要な背景は理解できるんだけど、なんかそれは大きい組織単位で見るくらいで良くない？と思った。
思考が緊張からほぐれた状態を経て、パッと悩んでたことが解決することってあると思う。
例えば、前日の夜遅くまで悩んで直せなかった不具合が、翌日の朝シャワーを浴びてる時にふと解決策が浮かんだり。休日にゆっくりしていて、ふと困っていた課題へのアプローチ方法に気付けたり。
他にも、僕らは業務後や休日にプライベートでカンファレンスや勉強会に行くことだってある。
こんなことを好きでしてるのがエンジニアという人たちだと個人的には思っていて、そんな人たちを生産性がどうたら、というのってまあなんか違うと思った。
そんなことをぐるぐる考えていたら、そもそも生産性ってなんだろうと思い始めた。僕が変にイライラしているだけのように思った。僕がチームの生産性の可視化に敏感になってるだけなのかな。
そこで、 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング を読み直してたら、生産性に関して以下のように記載があった。
この生産性という概念は日常語として使われている反面、経営的な用語でもあるため、理解が難しいものです。日常語としてはおそらく「たくさんの機能を早く作りたい」というような意味なのでしょう。一方、経営学的な用語で言えば、企業組織全体の労働生産性を上げるということを意味しているのだと考えられます。
なるほど。そうなると、つまりは経営層とプロダクトバックログをしっかり整理して開発どんどんする、ということでいいかなと思った。わかりやすい。
そして書籍内のその後の章では、組織内のコミュニケーションについて取り上げていて、生産性、ていう話だとこっちの方がまず僕は思いつくなーと思った。組織内の伝言ゲームうまくやるかどうかで大規模なアジャイル開発って円滑に出来るか変わってくるし。
生産性、ていう話題難しいな。
以上、生産性の可視化ってこわいな、と思った話でした。終わり。
[追記]
Xでやり取りしていたら、マーティン・ファウラーも同じことを言ってるよ、と教えてもらい、おおお、と思いました。追記終わり。
マーチンファウラー御大も同じような指摘をしていますね。https://t.co/HCAcCCwl54
— Makoto Sakata (@sakatam) 2024年7月7日
ほんとですね、同じこと言ってたので安心しました笑
— Masayuki Tanaka / 田中 優之 (@masayuki5160) 2024年7月7日
You can get a rough sense of a team's output by looking at how many features they deliver per iteration.
