エンジニアに限らずかもしれませんが、社会人として生きていると度々「上司の仕事を奪っていこう」と言われます。
上司の仕事から、自分に出来そう（もしくはやらなければならない）ものを奪っていこうとすることはよくあるのではないでしょうか？
僕自身一年半ほどソフトウェア開発に携わってきており、上司のタスクを奪っていこうと奔走していました。
やっていることを見様見真似で真似して、タスクを進めていました。
しかし、
「上司がやってる時は上手く進んでいるのに、自分がやり始めた途端、何だか上手くいかない」
「なんで同じようにやってるはずなのに、上手くいかないんだ」
...
果てには「俺は何やってんだ？？これって何のためにやっているんだ？？」状態に陥っていました。
なので、今回は僕と同様の悩みを持ったことがある若手の方向けの記事として、これを読むとより良い仕事の奪い方が出来るような思考やコミュニケーション方法をまとめてみましたので、参考になると幸いです！
※ この記事はモチベーションクラウドシリーズアドベントカレンダー2021の1日目の記事です。
何が起きているのか
まず、目の前の仕事に取り組んでいるのに「俺は何やってんだ？？」に陥るパターンがなぜ起きるのか。
タスクを実行していく行為は課題解決行為と同義だと思います。
全ての課題解決行為には「なぜ解決するのか(Why)」「何を解決するのか(What)」「どのように解決するのか(How)」があります。
僕が陥ってたパターンはこのHowの話に終始し、「Why/What」が擦り合わないままタスクを実行していました。
その結果、いつもと少し違うパターンになるとやることがわからなくなったり、やっているけど上手く行ってるかどうかわからなくなったりしてしまいました。
なぜこのようなことが起きるのか？
このようなことが起きる原因の一つが、
上司と自分の関係が、依頼者と実行者になっていることだと思います。
上司は僕に対して、出来そうなタスクを見繕ってくれています。
僕自身、何がどれぐらい出来るかも不明瞭なので、とりあえず言われたことをやろうとしています。
この関係こそが「Howのみを擦り合わせてしまう」ことの構造上の問題だと思います。
この問題をどのように捉え直すと良いか
結論から言うと上司部下の関係性のアップデートが必要かなと思いました。
なぜ「How」のすり合わせに終始してしまうのかでいうと、自分と上司の関係が、依頼者と実行者であることです。
教える人 vs 教えてもらう人から同じ課題解決に向かう協働者として自分と上司の関係を捉え直し、コミュニケーションや行動を変えると自分としては、上手く行き始めたことが多かったように思います。
今回は、自分の経験として上手くいった観点を、日本古来からある考え方の「守破離」になぞらえて整理してみました。
今回整理した守破離とは
すでにご承知の方も多いかと思いますので、コトバンクさんにここの説明はお任せします
「守」は、師や流派の教え、型、技を忠実に守り、確実に身につける段階。
「破」は、他の師や流派の教えについても考え、良いものを取り入れ、心技を発展させる段階。
「離」は、一つの流派から離れ、独自の新しいものを生み出し確立させる段階
今回僕なりに守破離を割り当てて、整理しました。
守: 行動だけではなく観点も真似せよ！
大事なことは、アウトプットを真似することではありません。自分自身が再現性高く同様の問題を解決できるようになることです。
行動を真似するというところでよくあることはアウトプットのみを比較してしまいます。
発言としては
「そんなこと知らなかったよ。」とか「そんなの言ってくれてなかったよ...」とかがあると要注意です。
僕のこの発言の背景は、
「教えてくれてないから出来なくても仕方がなかった」でした。
ここで捉え直すべきことは
「どうして自分はその情報に辿り着けなかったのか？」
「どの場面でどのようにしていたら、出来るようになっていたか？」を考えることでした。
これをソフトウェアに例えると...
1. I/Oが一緒かどうかを比較してみる
2. アルゴリズム（スループット）のチューニングを行う
かなと思います。
I/Oが一緒かどうかを比較してみる
優秀な人は普段どのような観点で情報を収集しているのか、どこにアンテナを立てているのかから真似しましょう。
そもそもそのタスクを行う上での必要情報が欠けていては、出せるアウトプットも変わります。
幸い、オンラインでのコミュニケーションツールが発達していることもあり、さまざまな情報はオープンな場でやりとりされていることが多いです。
上司がどこの会話を普段チェックしていて、自分の中で整理しているのかを真似することは大切だと思います。
僕は自分が参加しているプロジェクトや上司の名前をカスタム通知に登録して、通知が来るようにしていました。
あまりにも作業が中断されるぐらい通知が飛んでくるようになると生産性は下がってしまうと思いますが、手が空いた時に確認するのにとても有用でした。
アルゴリズム（スループット）のチューニングを行う
次に大切な観点は思考フローの真似です。
同様の情報をインプットとして、プログラムを回したとしても中身のアルゴリズムが異なれば、アウトプットは大きく変わります。
アウトプットを真似しようと心がけるのは大切ですが、アルゴリズムを修正しないといつまで経ってもアウトプットは改善されません。
上司の方が優れた（一般的に仕事上での課題解決という意味で）アルゴリズムを持っているので、そこを真似しましょう。
「最初はどのような選択肢がありましたか？」「このタイミングでは〇〇のようなことを考えていたのですがいかがでしょうか？」など、
アルゴリズムの分岐点で、デバックを行い自分と上司で差分が生まれたタイミングを明らかにすることで、そこのチューニングを行いましょう。
破: 自分のやりたいことを口に出そう！
ここまでひたすら真似をしてきて、ある程度擦り合う場面が多くなってきたら、次は「他からより良いものを自分にFBする」ことが大切です。
それは自分が得意な分野から得てもいいと思いますし、自分の苦手な分野に挑戦することから補うもよいと思います。
今回の他という言葉は、「今の自分の視界で見えないこと」を意図しています。
弊社では、「輝かしい未来を考える会」という取り組みもあり、現在の状況とかはひとまず考えずに、１年後や３年後の自分のなりたい姿を上司や先輩と決めるような機会がありました。
具体的には、以下のようなフォーマットで定義します。
- ３年後本当になっていたい自分の姿
- そのために必要な１年後の自分の姿
- 現在自分が置かれている状況
- １年後の自分との差分を埋めるために必要な経験（達成困難な壁）
- 壁を乗り越えるための具体的なアクション
自分が本当にワクワクする未来のために、直近何が必要なのかを関係者と視界を合わせます。
そうすることで直近３ヶ月や半年の行動をもう一度見直し、今後どのようなタスクに取り組むべきかを考えることができました。
僕自身、これまで一貫してバックエンドの開発を行っていたのですが、
「将来的には機能開発の全工程に関わりたいなと思っているので、そのためにフロントやインフラ面も業務で触れるようになってたいです。」とか
「最近設計のタスクが多いのですが、もっと実装力を磨きたいと思っているので、実装をしていきたいです。」など、日々のタスクの積み上げでは考えられていなかったことが考えられるようになりました。
今の自分の考えだけで判断するのではなく、他者の意見から自分のアルゴリズムをチューニングしてもらいましょう。
離: 役割の前にやるから、役割が与えられる！
今の自分の役割の範囲で、仕事をし続けていると上司と自分がお互いに挑戦することなく、現状の積み上げで物事を考えてしまいがちです。
欲しい仕事、やりたいことがあるなら、まず勝手に自分でできるようになっておくのが最も手に入れやすい方法だと思います。
具体例として、（チーム事情も多分に良い意味で影響しているのですが、）以下のようなコミュニケーションができました。
「今後長期的なチーム事情を考えるとフロントの工数が少なくなると思います。将来的にはフロントエンドも書けるようになりたいですし、最近勉強しています。簡単なタスクもありそうなので、そこから着手し始めるとリスクも小さいと思うのでフロントの実装に入っても良いでしょうか？」
社会人として、自分のやりたいことだけではなく、組織の合理視点も大切です。その中で、自分の役割を変更するなら、それが出来るようになっておくことが最も手っ取り早いかなと思います。
もちろん、毎回上手くいくわけではないですが、普段から意識してコミュニケーションを取ることで、自分に与えられるチャンスは増えるのではないかなと思います。
上司の中にある自分という認識をチューニングして書き換えましょう。
あとがき
まだまだ若造ですが、周りの人の上手くいっているところや、自分の良かったなと思うところを守破離の観点で整理してみました。
思い返してみると、上手くいかない多くの原因が自分の手の届かない範囲だと諦めてしまうことが多かったです。
ただ、整理すると実際に起きていることは自分と上司の認識のずれが多かったように思います。
自分が取れる解決策はそのずれを地道に修正していく行為なのかなと思いました。
今回整理したフローが、同じような悩みを抱えている若手のエンジニアの人の参考になれば幸いです。