開発生産性とは「要はバランス」をどう見つけるか

• 開発の生産性ばかり上げてもユーザーに価値を提供する成果物が出来ない

• 成果ばかり求めても開発の生産性を上げる取り組みが進まない

つまり、この２つの間にある「要はバランス」をどの様に見つけるかを喧々諤々していることが開発生産性を考えることなのかな

と、ふと思ったので、思ったことを書いておく
最後まで読んでも結論はありません

色々な手法はあるが、今あるのはプロセスではなく議論の材料かも

スクラム、four keys、SPACE、様々な指標や手法が定義されている。客観的な示唆を与えてくれるが、主観的な感覚を表現するまでに至っていないと感じている (もしかしたらSPACEはかなり緩いので主観的な定量データを指標にできるかもしれないが)

開発チームとビジネスチームがコミュニケーションをする手段以外で中長期の目線をあわせる方法はないだろうか

現状は経験したエンジニアからくる提案が一番強い

様々な経験をしてきたエンジニアがいれば、実装をしたシステムが将来どのような状態になるかを経験しており、次にシステムを作った時には将来の状態を逆算しながら今のエンジニアが取り組むべきことを考えることができる

システムの開発だけして、運用したことがないエンジニアはシステムの未来を経験することができないため、システムを見通す力をつけることが出来ない。つまり、開発生産性の良い塩梅を知ることができない。できるのはリリースまでの開発生産性のトレードオフに限られる

運用や機能拡張の仕事しかしたことがないエンジニアも同様に、立ち上げで得られる経験がなければ現状がなぜこうなったかを体感することはできず、想像するしかないため、経験として片手落ちになってしまう気がする

そして、リリースしたあとの開発価値をふりかえらなければ、失敗も成功もエンジニアにフィードバックされずに経験値にならない。現状は経験値に変換する深い思考はエンジニア個人に期待されているように感じるケースが多い。逆をいうと、若くしてこれをできる人は早々にテックリードになってそうな気がする

つまり、実践的なシステムを見通す視点を得るには経験が必要なのだが、大失敗せずにこの経験を得るためにベテランエンジニアの視点をどうやれば共有できるのだろうか
よくあるのはペアプロ、モブプロだが、何か足りないような気がしていてプラスアルファの型が欲しいな

システムは作れば残り続けるため、複利を得る戦略がポイントになりそう

システムは一度作れば残り続けるため、内部品質を良い状態にしているのが正解だと感じているが、まだまだ主観的な感覚。維持する品質をどの様に定義するのが良いのだろうか？
コスパ良い手段として、開発部門の責任者が信頼を得て、感覚的に行う方法もあるが、できればもっと型化して、誰もが共有できる知識になると嬉しいと思っている

「要はバランス」をどこのタイムラインのどこで生産性価値のピークを実現するかの中長期視点の共有が大事なのかなと感じている
成果は短期的に求めるやすいものであり、生産性は中長期で複利に効くものであり、バランスを決めるときにはタイムラインが重要になる

結論

現状でこれらに向き合うにはコミュニケーションしかないのかな
結論はありません

求む意見