開発生産性の教科書を読んで、開発生産性について自分なりに考える。
始めに
今回Findyさんのキャンペーンに参加して、
こちらの本をいただきました。
こちらキャンペーンで当たりました！とても嬉しいです まだへっぽこエンジニアには関係ない話かもしれないんですけど いつかそういうことも考えられるエンジニアになりたいですね 大事に読みます#開発生産性の教科書_findy pic.twitter.com/VS4c1drifG
— 柊_RUNTEQ27期生 (@hiiragi_en17) July 24, 2024
元々フワッと聞いたことがあったり、
自分自身も生産性の高い人間になりたいなと感じており、
興味がありました。
こちらはエンジニア組織を強くする、
とある通り、今の自分が読むには早いかなとも思いつつ。
しかしこれを読むことで、
自分の仕事との向き合い方も変わりそうだなと思い、
読ませていただきました。
開発生産性とは。
そもそも開発生産性が示す範囲は広く、
企業やその組織の状態によっても色々変わるため、
一概には言えないと言うのが、また難しいなと感じるところでした。
特にアウトプットとインプットは人によって定義が違うため、
組織間でのすり合わせが大事です。
また下記の動画でも取り上げてくださっているのですが、
一エンジニアだけが頑張って行うと言うより、
やはり、組織だったり会社全体で行っていかないといけなさそうです。
この本では開発生産性を段階ごとに分け、
どう言う指標を使ったりすれば良いかの記載が詳しく、
また5社の取り組みに関しても書いていたため、
開発生産性を上げたい組織にとって正に教科書という感じでした。
あまり詳しくは書けないので、興味がある方は、
まずは上の動画を見ていただき、
更に興味があれば本を手に取って貰えると良いのではないかと思います。
私はとてもわかりやすく、面白く読めました。
一個人として考える開発生産性の上げ方。
この本を読んでまず自分が開発生産性を上げるために、
何ができるのだろうと考えてみて。
今回よく指標として上がっていたのが、
PRの数とレビュー時間でした。
PRの粒度が適切なものであればあるほど、
レビューもしやすくなり、レビュー効率が上がり、
デプロイ頻度も上がり、
それによって開発生産性が上がると言うもので、
とてもわかりやすいなと感じました。
最近の自分のPRを振り返ってみると、
粒度は適切でなく、一機能だけでなく、
沢山の機能をあげたPRを作成していたなと感じました。
一気に作った方が楽だから、という理由で、
レビュアーのことを考えていなかったです。
昔はレビュアーのことを考え、
ケアレスミスはできるだけ防ぎ、
わかりやすいPRを上げることを徹底していたのですが、
案件で納期が短くなると、途端に疎かになりがちでした。
そして納期が短くて、PRも粒度荒いから、
更に適当なレビューになるという悪循環……。
レビューあんまりちゃんとして貰えてない気がすると感じていたのは、
自分のPRの書き方も適切じゃなかったんだなと反省しました。
少し前までは、下記の記事の通り、
PRを上げる前に自分で確認をしたり、
レビューで指摘貰ったことを繰り返さないことを意識していたのですが、
最近は忘れがちだったので初心を取り戻したいなと思います。
後はPRの粒度に関しても、
自分がちゃんとできているかを振り返るべきだと思いました。
タスクの細分化をしようと言う言葉は、
よく聞きますし、重要度はわかっていますが、
今一度開発生産性を上げるという意味で、
ちゃんと取り組んでみるべきことだなと感じました。
組織で開発生産性を上げたいと考えるのなら、
まずは個人の気持ちの持ちようも大事だと思います。
今自身が取り組めることは小さいかもしれませんが、
それでも意識していきたいなと感じました。
今後のことを考える。
私はこれまで、Webエンジニアの人達が気持ちよく仕事ができるような環境を整えられるようなマネージャーになりたいと考えていました。
しかしWebエンジニアの人たちが気持ちよく仕事ができるような環境ってなんだろうと、そこら辺はフワッとしたまま過ごしてきていました。
今回この本を読んで、
開発生産性が高い環境だと、
Webエンジニアは当たり前だけど満足して働ける、
開発者の満足度と幸福度が高いほど、
モチベーションとパフォーマンスに直結する。
開発者の体験を上げること＝開発生産性が高い
と言う図式を見て、
私がやりたいなと考えていることはこれではないかと思いました。
以前世界一流エンジニアを読んだ時に、
外国のマネージャの仕事は、
「仕事を楽しいと感じているか？」
「幸せかどうか？」
を聞く仕事だと書いてあり、多分これだと思ったのですが、
じゃあそのために何をやるべきか？
は書いておらず、結局やっぱり漠然としたままだったのです。
今回この本を読んで、
開発生産性を上げるためのマネジメントというか、
何をやってみたいかが明確になった気がしました。
ただいますぐ、そう言うマネジメントをするには、
圧倒的に実力が足りていないので、
引き続き自分の技術力を高めていかないとなと考えています。
その人に合ったマネジメントや取り組みを提案するにも、
圧倒的に技術が要りますし。
ビジネスサイドや他部署との連携も大事なので、
技術以外の勉強も必要だと考えています。
それでいて、
もし会社が開発生産性とかを上げる取り組みをしたいってなったら、
進んで手を上げたいですし、
自分からそう言う提案をできるような人になりたいなって考えています。
後今後はセキュリティ的な観点とか、
DevOpsとかも学んでいきたいなと考えています。
Webエンジニアって学ぶこと多いし、
それが大変だけど、最近はそれが楽しいなって思えています。
最後に
あまり本の感想という感じでは無くなってしまったのですが、
今回自分が今後何をしたいかを考える機会になったので、
とても良い本を頂けたなと感じました。
この記事が少しでも誰かのためになれば幸いです。
それではここまで読んでくださりありがとうございました。