任せてみて、見えてきたもの
3ヶ月ほど前に以下のような記事を書きました。
記事を書いた当時は知りませんでしたが、この記事を書いた1ヶ月後に役割が変わり、当時よりも多くの人をマネジメントすることになりました。
この記事では役割が変わってからの振り返りをしつつ、新たに見えてきたものについて書いていきます。(引用箇所は前回の記事で触れていた内容です)
■ 真っ先にやったこと
価値を出してきた、事情を知っている領域を手放さなければならない
元々は1人のソフトウェアエンジニアとして開発に入りコードを書いていましたが、自分がコードを書くことを基本的にやめました。基本的に、というのは例えば緊急対応が入ったり、スケジュールを前倒しにしたい等、特殊な状況においては開発に入るという選択をしますが、平常時にはコードを書く人として扱われないようにしました。
理由としては、前回取り上げていた以下の2つです。
・自分はどこで結果を残すべきか
・時間の価値を意識する
立場が変わったことで、自分が出すべき結果が変わりました。これまではマネジメントをしつつ、ソフトウェアエンジニアとして機能の開発・改修をすることも求められていることでしたが、今の立場ではそこで結果を出すよりも組織運営や事業運営で大きな結果を出すことが求められています。であれば、そのために時間を使うべきだと判断しました。
ありがたいことに任せられるメンバーがいることもあって、このような判断ができています。常に自分が手を動かさなければいけないという状況になっていたら、この判断はしていないでしょう。
振り返ってみると、以前の記事で述べていたことが実際の行動に移せているのは良いなと思います。
大切なのは、自分が残すべき結果は何で、その実現のためにやるべきこと、やらなくてよいことを常に考えて、そのまま続けるのか、はたまた他の人に任せるのかを判断することです。
ここでも重要なのは、自分がやるべきことか否かを軸に判断し、任せられるものは任せていかなければならないです。たとえ、自分の得意領域や好きなことであったとしても、そこで価値を出しきれないのであれば任していくべきですし、時間がかかっても自分がやるべきことはやらなければなりません。
この判断によって生まれた機会がメンバーの成長になっているのであれば、自分としてはとても嬉しいですね。
■ 手放した心境
自分がこれまで最も価値を出してきた部分を手放す形になりましたが、思っているよりもあっさりと手放しました。合理的に考えるとこのままコードを書くことにこだわっているよりも別の動きをした方が良いと思えたからです。
ただ、役割が変わるだけであってソフトウェアエンジニアでなくなるわけではないので、平日の夜や休日など時間があるときにでも開発はやりたいと思います。先日弊社のプロダクトのアプリケーション環境がEC2からECSに移行したこともあって、年末年始にでもECSやFargateについて勉強したいと思っています。
■ 見えてきたもの
役割が人を作る
役割が変わっただけなのに、これまで見えていなかったものが見えるようになってきました。もちろん、情報量がこれまでよりも増えたことは要因の1つだとは思いますが、見ようとしているものが変わったことが大きいと思います。それは組織であったり、事業であったり、もちろんこれまで深く関わっていた開発全般であったりします。そのため、自分の中では「これまでとゲームが変わった」という感覚を覚えました。ただ、これは自分に任された役割を全うしようとしているからこそ生まれた感覚だと思うので健全であると共に自身が成長しているからだと思います。
一方で、状況は何も変わっていないのに見え方が変わったということは、いかに自分が見ようとしていなかったのか、考えられていなかったのかの裏返しになります。これは気づいていなかった・意識できなかったからなので悪いこととは言えません。ただ、こういった視点を持つためには
・役割を任せる(自分から気づく、意識する)
・他の人からの問題提起(他の人によって気づいてもらう、意識してもらう)
この2つのどちらかが必要になることに気づけました。そのため、例えば皆が見えていない問題については、任せることで気づいてもらう・意識してもらう、または気づいた人が問題提起をする必要があります。
どちらかだけをやればいいというわけではなく、どちらの動き方も大切にしなければならないので、任せつつ、問題提起もするという動きをやっていきたいです。
課題は山積み
これまでは開発に入っていたので当事者でしたが、一歩引いて全体を見渡してみると、やらなければならないことは数多くあると思いました。たとえば、情報共有1つ取ってみても一部の人は把握できているけど、全体では把握できていないことがあったり、フローが決まっていないことで毎回同じところで悩んでいたり...と。1個変えることである部分は良くなるけど、また別の問題が生まれてを繰り返していますが、それでも少しずつ前に進んでいる感覚はあるので、状態を見ながらコツコツとやるしかないんだろうなと思いました
■ やっていくこと
小さなボールを拾いまくり、前に進める
自分がメインでコードを書くことはなくなりましたが開発には入っています。たとえば、開発を進めるための調整など、抜け落ちがちなところを拾いまくることで前に進めています。ただ、この辺りは将来的には自分じゃなくても回るようにはしたいので、メンバーのスキルアップや採用をやっていかないといけないと思っています。
また、あったほうが良いけど誰も手がつけられていないものについても動いていきたいと思います。例えば、これをやれば開発効率が上がるだとか、調査が楽になるだとか、そういった今やらなくていいから時間あるときにやっておこう(やらない)と言った落ちがちなところを埋めていこうと思います。
変化を恐れない
一番楽なことは何もしないことです。今の状態が完璧であれば何も変える必要はないと思います。ただ、そんな状態になることはおそらくなく、状況も日々変化しているので、少しずつ変化していかなければなりません。特に自分自身これまで経験したことのない領域に踏み込んでいるので、変化を恐れて硬直しないようにしたいです。
既存の枠でなんとかしようとしない
どうしても手元にあるものの中からなんとかしようと考えてしまいます。これは現時点で存在しないものを考慮しないという前提を置くことで選択肢を減らし、範囲を限定的にすることで考えやすくしているのですが、このやり方だと局所最適になるため未来に広がりがない考え方だと思いました。
もっと大きなことをやろうとしたり、開発スピードを上げる場合に、既存の枠の内側をより良くすることも重要ですが、それよりも枠を外に広げていくことを意識して動く必要もあると思います。
■ 終わりに
役割が変わり、任せることがこれまでよりも増え、自分の動き方も大きく変わりましたが、視野は間違いなく広がっていると思います。一方で、見えるものが増えたことによって関係する変数が増えたので、状況を複雑に捉えたり、思考停止して動きが止まりそうなことを懸念しています。そのため、状況の整理やそもそもの目的をこれまでよりも強く意識した上で、良い方向に進むための解決方法を常に見出す必要があると考えています。まだまだその辺りは弱いので足掻いていきたいです。
この記事が気に入ったらサポートをしてみませんか？