2022年で得た気づき

まだ12月も2週間ほど残っていますが、仕事の案件が落ち着いたので2022年で得た気づき、来年取り組みたいことを文字起こししておきます。

適度に成果を伝えること

今年の5月のことです。自分はAWS資格のSAPとDOPの試験を受験して、運良く合格することができました。(ラッキーもあったと思います) 自分が所属している会社では、AWSのプロフェッショナルレベルの資格を取得すると表彰されるのですが、私は周りに合格したことを伝えていませんでした。

合格したことを伝えていなかったのには意図がありました。私自身、「自分の成果を誰かに伝えると、褒められることで自己満足してしまい、成長が止まってしまう」と考えていたためです。そのため、成功したときこそ誰にも言わず、「なぜ成功したのか」を振り返るようにしていました。「なぜ成功したのか」を振り返ること自体は、とてもよい習慣になっていると思います。

ただその後、自分が想定していなかったことが起きました。社内で表彰されることで、「AWSといったら〇〇さん」と評価していただき、社内でも大きな案件にアサインされることになったのです。それまでの会社からの評価は、至って普通だったと思います。そのため、たった一つの出来事がきっかけで自分の評価が大きく変わったことは印象的でした。

今回は自分から成果をアピールしたわけではなかったですが、「成果をアピールしないこと」にこだわっていた自分にとっては印象的な出来事でした。当然のことですが、成果を伝えないと相手もどう評価していいかわからず、適切な評価がされないと思います。結果的に、ミスマッチな案件や部署にアサインされてしまう可能性もあるため、自分にとっても、会社にとってもマイナスな状態になってしまうと感じました。そのため、適度に成果を伝えることは、時に大切だと考えるようになりました。

インフラ設計・構築を1人で行って得た気づき

AWS資格を取得したことによって、新規開発の案件にアサインされることになりました。担当はインフラの設計・構築です。当時、「インフラの知識を身につけたい」と考えていたので、案件にアサインしてくれたことには本当に感謝しています。

蓋を開けてみれば中々ハードな案件でしたが、色々と学べたことが多いのも事実でした。学んだことはたくさんありますが、今回は以下の内容に絞って振り返ります。

振り返り

  • 責任のスコープを明確にすること
  • 大きなタスクは小さな積み重ねで考える
    • タスクを細分化することで、大きなタスクの進捗を管理しやすくなる
    • 細分化されたタスクが完了することで、「仕事に追われる」から「仕事を追う」意識になれる

責任のスコープを明確にすること

プロジェクトが進む際、責任のスコープが不透明なタスクがありました。タスクの進捗は宙ぶらりんになってしまい、あとになって自分たちの首を締めることになってしまいました。

振り返ると、もっと自分に責任のスコープを意識できる余裕があれば、対処できていたと思います。自分の弱さが露呈した気がして、かなり反省しました。 それ以降、「インフラに関することは全て自分が責任を負う」と考えるようになりました。インフラ担当ということもあり、必然的に新機能のデプロイ作業やデプロイスケジュール、ブランチ運用など、プロジェクト全体まで考えることが増えました。その思考を繰り返すことで、以前よりもプロジェクト全体を見て行動できるようになった気がします。(まだまだ努力は必要ですが)

大きなタスクは小さな積み重ねで考える

当初のゴールは「インフラを構築する」という大きなタスクでした。また、インフラに関するタスクは基本的に全て1人で行ったため、やることがたくさんありました。そのため、ただ目の前のタスクをがむしゃらにやっていくのではなく、ゴールから逆算してタスクを細分化するようにしていました。これは以下の点でよかったです。

よかったこと

  • タスクを細分化することで、大きなタスクの進捗を管理しやすくなる
  • 細分化されたタスクが完了することで、「仕事に追われる」から「仕事を追う」意識になれる

タスクを細分化することで、大きなタスクの進捗を管理しやすくなる

極端な話、「インフラを構築する」といった大きな粒度では、どこまで順調に進んでいるかを把握するのが難しいと思います。そのため、タスクの内容を細分化して実装を進めるようにしていました。タスクを細分化することによって、どれだけタスクを消化したか把握しやすく、結果として全体の進捗を管理しやすかったのはよかったです。

細分化されたタスクが完了することで、「仕事に追われる」から「仕事を追う」意識になれる

タスクを細分化する良い点として、「仕事を追う」意識になれることが挙げられると思います。「仕事に追われる」という意識は、「仕事が終わらない」という結果から生まれる気がします。であれば、できるだけ「仕事が終わった」と感じる機会を増やすことで、「仕事に追われる」という意識を改善できるのではないか?と考えました。細分化された小さなタスクであれば、タスクを終わらせることも難しくないはずです。小さなタスクの積み重ねが、結果として大きなタスクの完了に繋がり、「仕事を追う」意識になれた気がします。

来年取り組みたいこと

来年は以下のことに取り組みたいと考えています。

  • 振り返りの仕組みを整える
  • 技術を深ぼる

振り返りの仕組みを整える

一時期、「振り返りの仕組みを作れないか?」と考え、以下のようなフォーマットで振り返りをしていました。

look back

この仕組は一時的には効果がありました。特に以下の点でよかったです。

よかったこと

  • 自分の課題を可視化できる
  • 一日を過ごす際に振り返りの項目を意識することができる

自分の課題を可視化できる

一週間を振り返った際、同じ項目でずっと評価が低い場合は、何か改善のアクションを取る必要があることが分かりました。また逆に、評価が高い日も可視化されるため、「なぜ評価が高いのか」と成功の要因を探ることにも役立ちました。そういった要因を探る際は、YWTのフレームワークを使っていました。結果的に、自分の成長をサポートする習慣になっていたと思います。

一日を過ごす際に振り返りの項目を意識することができる

「一日の終わりに振り返る」という習慣が出来上がったため、一日を過ごす際に振り返りの項目を意識することができました。例えば、自分は「Concentration(集中力)」という項目を入れていたため、普段の業務や自己研鑽の際に集中力を意識して一日を過ごすことができました。結果的に、生産性が少しだけ上がった気がします。

悪かったこと

ただ逆に、悪かったこと(もっと改善できたこと)もあります。以下の点は良くなかったなと反省しています。

  • 評価の定義が曖昧だった
  • 単純に継続できなかった

評価の定義が曖昧だった

色々と振り返りの項目を用意しましたが、評価の定義が曖昧だったため、その日のさじ加減で振り返りをしてしまっていました。予め評価の定義を明確に決めておけば、もっと精度よく振り返りができたと思います。ただ、評価の定義に関しては、自分がレベルアップする毎に基準が上がると思うため、適宜調整しながら進められればと考えています。

単純に継続できなかった

継続できなかったことに関しては、フォーマットが悪いというより、完全に自分自身の状態に左右されるものでした。既に触れましたが、インフラ設計・構築の案件がかなりハードで忙しかったため、途中から振り返る余裕がなくなってしまいました。今思えば、そういった時こそ振り返るべきだった気がします。結果的に、徐々に振り返りの時間を取らなくなってしまいました。今は案件も落ち着き、一年の節目とタイミングがいいので、来年は継続して振り返りができるように習慣を見直そうと思います。

技術を深ぼる

来年は技術に関して学ぶ際、深いところまで理解するように取り組みたいと考えています。そう考えたきっかけは、インフラ設計・構築をした際の失敗経験です。インフラを1から構築して、サービスリリースも無事できました。ただ、各AWSリソースの特性やオーバーヘッドなどを考慮できれば、もっとよい設計を考えられたと感じています。

具体的な例を上げると、バッチ処理に関する設計で後悔がありました。現状、バッチ処理はEventBridgeとECSの組み合わせで実装しています。ただ、バッチ処理の数だけEventBridgeのルールが増えてしまったり、手動でバッチ処理を実行できないなど、ベストな設計ではないと後から気づきました。本来であれば、StepFunctionsを噛ませてバッチ処理を実行するべきだと考えています。手動で実行できたり、バッチ処理の実行結果を確認できるなどのメリットがあるためです。

上記の後悔は、単純に自分の知識不足が原因だと感じています。悔しい気持ちになりましたが、「もっとよいサービス、価値を提供したい」と考えるようになったきっかけでもありました。同じような後悔をしないためにも、更に技術の理解を深めていこうと思います。