こんにちは。
いかがお過ごしでしょうか。
仕様が決まらないなら決めればいい し、前任者のコードをクソだと思ったら直せばいいし、仕様変更や機能追加でつらいなら仕組みを変えればいいし、この世のすべての不利益は当人の能力不足だし、それが嫌なら耳と目を閉じ口をつぐんで孤独に暮らせばいいのでは
— こにふぁー (@konifar) April 4, 2019
こにふぁーさんがこのような事を発言していたので書いてみることにします。
最近役割について考える事が多くなってきています。
僕自身は会社では Head of API / Head of QA という肩書を貰っていて、一般的な会社だと課長クラスって感じじゃないでしょうか。
その肩書に含まれる職務は色々あり、例えば評価・育成・チームビルディング・チームマネジメントなどです。
新任で肩書をもらう時に気をつけないといけないことが1つだけあり、それは本来自分ができることを忘れてしまい、肩書の方の責任のみの振る舞いをすることです。
例えば僕は前職でPM(プロジェクトマネジメント)を複数個のゲームタイトルで兼務していましたが、コードを書いてチームを助けるということをやらなかった(忘れてしまっていた)のです。(その時期は給料も上がらず割と腐っていたし)
その時は多分アサインの意図として、「PMもやってほしいがとにかく成果を出せ」って意図だったのに対して敢えて成果が出にくい方法のみを選んでたのではないかなと。
これを解決するのはもう視座の話でしかないと思ってます。
一部のチームのメンバーの人には伝えたのですが、例えばスクラムなどで開発を行う際に「スクラムをうまくいかせる」と捉えるのではなくて「成果を出すためにスクラムを使っているが、他の方法でも良い」と考えるべきだと考えています。
会社で @yohhatu さんと @futabooo さんが「スクラムは矯正ギブスなんで」と言っているのはそういうことだと思います。
開発チームのベロシティが足りない時にきちんとコードを書く、だったり開発環境を見直してみたりと、色々やってみるべきです。
クエリを書いてKPIを出してみる、なんてのもいいですね。
プレッシャーがでかいほどこの状態になってしまいがちなので、手段にこだわらずやっていきたいですね。
