こんにちは。
社内の発信から、アドベントカレンダーの参加オファーを受けたことをきっかけに、Qiitaを始めました。
今回は、自分のテストを兼ねて、「開発畑でない開発マネジャーのお仕事」について書いてみます。
私は、プロフィールに記載したようなキャリアなのですが、そんな私だからこそできること、苦悩していることを書きます。もちろん、両方たくさんあるのですが、その中から一つずつ取り上げます。
①できること
開発部門に来てしばらく過ごして、最も強く感じたのは、「開発者にとって、学び、遊びがとても重要」ということです。
コンサルタント部門では、目の前のお客様の対応に追われる日々でした(※もちろん喜びもありましたが)。開発部門にも、そこへの支援を求めてきたと思います。はい、これは実際、かなり強く求めてきました。当時から、うるさいだろうなという自覚はありましたし、今でも、これはこれで必要なことであるとも思っています。
しかし、開発者が100%、そこにフォーカスしてしまうと、解決策がどうしても場当たり的なものになり、プロダクトが抱える根本的な問題の解決が、二の次、三の次になってしまいます。問題を根本から解決する機能の追加やリファクタリング、製品の技術的負債の解消などです。
これを繰り返すと、開発者は「場当たり的な問題解決のスキル」が向上していきます。結果、それを繰り返す方が楽で、根本解決は大変だからやらない、という方に傾いていってしまうのです。
「それで回っているなら良いのでは？そういうもんじゃない？」という意見もあるかも知れませんが、この点は今回、割愛します。私は、それではダメだと判断しました。
そこで、一例として、自部門内で「Bukatsu」という取り組みを始めました。これは、簡単に言うと「業務時間の10%程度を、学びのための時間に当ててください」というものです。これにより、今使っている技術や言語、機能に寄った発想に限らない問題解決のアプローチを見出せる開発者を育てたい、そういう開発組織にしたいということです。
アイディア自体はありふれたものと思いますが、一つは、これを「開発畑でない人間が立ち上げた」ことに意味があると思っています。
開発畑の開発者が、「開発者にとって、学び、遊びがとても重要」と主張することは、もちろん可能です。しかし、それを他の部門の人間はどう感じるでしょうか。また、開発者本人もそれを感じて、声を大にして主張することは難しいかも知れません。
しかし私の場合、「あいつが立ち上げた」という時点で、既にある程度、他の部門の人間の納得を得ることができます。もちろん、それでも納得できない人もいるかも知れませんが、その場合も、その声を私が受けることができます。
こういった、「ときに第三者目線」でいられるからこそ言い易いことを発信し、出せる価値を出していくことは、仕事の一つであると思っていて、日々の活動でも意識しています。
②苦悩していること
できることで尺を取ってしまったので(汗)、今回はシンプルにいきます。
端的に言って、コーディングスキルでメンバーに敵わないので、殆どのコードレビューで、中堅以上のメンバーにレビュワーとして同席してもらう形になっています。
そうでなくてもレビュワーは複数いるべきだよね…説もありつつ、若手メンバーが書いてきたソースの書き直しの具体案などもそういったメンバーに出してもらったりしていて、まぁ、ここは正直複雑なところもありますね…。
では、今回はこの辺で。