はじめに
こんにちは、こんばんは、新卒一年目のなかじです💪
皆さんは、調査系やお問い合わせ系のタスクのご経験はありますか？
今回、調査系タスクに取り組むにあたって進め方が分からず、タスクを完遂できずに期日を過ぎてしまい、先輩に巻き取ってもらう経験をしました😭
その時の自分自身のタスクの取り組みについて振り返りをしたので、記事にしようと思いました🙆
以前に、似たような記事を書いてます〜！
タスクの期限をすぎてしまった話 〜若手エンジニアがタスクの細分化と見積もりを知る〜
対象読者
- 若手エンジニア
取り組んだ内容
HRBrainには社内コンポーネントのライブラリがあり、その中のDatePickerを使った際に、プロダクトコードで起きるバグの調査タスクです。
- バグの条件：ライブラリのDatePickerをプロダクトコードのReact Hook Formと一緒に使用する
- バグの再現：年または月（日付以外）を入力すると、+9時間ずれ、2回行うと1日日付がズレて表示される
-
10/2 09:00:00→ +9時間 →11/2 18:00:00→ +9時間 →12/3 03:00:00
-
結果：期限内にタスクを完遂することができませんでした
このタスクには期限があり、その期限までに原因を調査することが完了条件でした。
しかし、期限内に完遂することができず、最終的に先輩エンジニアに巻き取ってもらう形になりました。🙇
👍 まずは自分の振り返りから
KPTを用いて、今回のタスクについて振り返りをしてみました。
- [Keep]
- 社内ライブラリの理解が深まったので、良かった。
- 新規立ち上げ中のプロダクトでは既存実装の調査タスクは無いので、今の段階で調査系のタスクに取り組めていい経験になった。
- このタスクの期間に、日報も書いていたので、そこでの整理もできた。
- [Problem]
- とりあえずがむしゃらに手を動かして、原因調査をしてしまった。
- わからないこと・わかっていることの言語化ができていなかったので、何を報告・相談したらいいか分からなかった。
- どんな手段を使っても完遂させる気持ちがもう少しあっても良かったかもしれない。
- 巻き取ってもらう際に、引き継ぎ資料のまとめ方も悪かった。
- [Try]
- 仮説を立てて、検証をし、フィードバックをもらうサイクルを実行する。
- わかっていることの言語化をし、整理をしながら進める（わからないことの言語化）
- どんな手段を使っても終わらせる気持ちを持ち、積極的に周囲に助けを求める。
🔥 何がダメだったのか？
😭 まずはとりあえずがむしゃらに手を動かして、取り組んでしまった
タスクがアサインされた瞬間、とりあえず手当たり次第に手を動かして、タスクを進めてしまいました。
これは、自分の感覚ですが、若手エンジニアあるあるかな思っています。
例えば、なんの根拠もなく「ここら辺とりあえずログ出して見て考えよ」といった具合です。
もちろん、しっかり前提やコード上でのデータの流れを理解した上で、そのログを出す行動に意図があれば良いと思います！
自分の場合は、事前情報だけで、何が問題なのか、影響範囲はどこまでなのか（今回はプロダクトコードと社内ライブラリ）など、何もバグについて理解せずに、手を動かして取り組んでしまったことが問題でした。
具体的には、今回は社内ライブラリとプロダクトコードでデータの一連の流れのサイクルができているはずなので、まず最初に、社内ライブラリかプロダクトコードのどちらがバグの原因なのか、切り離して考えるべきでした。
しかし、この考えができず、「プロダクトコードが怪しいかも」「やっぱり社内ライブラリが怪しいかも」といった報告が二転三転してしまいました💦
😭 わからないこと・わかっていることの言語化ができていなかった
最初の「とりあえずがむしゃらに手を動かして取り組んでしまった」ことにも繋がるのですが、わかっていることとわからないことの整理ができておらず、進捗を報告する際に、段階を踏んで説明することができませんでした！
例えば、社内ライブラリのコードで、以下のようにタイムゾーンを変更している箇所を「ここが怪しそう」と報告したことがありました。
/*
カレンダーの日付生成に （特定のライブラリ） を利用している都合上、
時間が日本時間を考慮していない値が返ってくる
日本標準時間を加算して返却する
*/
const LocaleJS = 9;
export const addLocaleJSTime = (date: Date | number): Date => {
return addHours(date, LocaleJS);
};
社内ライブラリかプロダクトコードのデータの一連の流れ、サイクルを理解していれば、バグが+9時間される事象だから、+9時間されているコードの箇所が怪しいという思考にはならなかったのかなと思っています。
実際、ここはちゃんとした処理であり、順序を追って社内ライブラリかプロダクトコードのどちらがバグの原因なのか、仮説を立てて検証を繰り返すべきでした。💦
また、弊社は、マルチプロダクトで複数プロダクトを開発しているため、複数のプロダクトでバージョンは違えど、社内ライブラリを使っているところが大半です。そのことも踏まえ、他プロダクトでは、似たようなコードの書き方でしっかり動作している事例があり、そのことも、調査の段階で調べておけば、よりクリティカルに近い仮説を立てることができたかもと、振り返りで思いました。
😭 積極的に周囲に助けを求める姿勢が不足していた
これは、マインド的な問題です。
一言で言うと、質問・相談をする際に、プライドを捨てるべきということです。
自分は、フロントエンドがあまり得意ではないため、簡単なことでも知見がなく、「こんな簡単なことを聞いてもいいのだろうか？」「忙しい先輩の手を止めて、こんな簡単な質問をしていいのか？」と悩んでいました。
しかし、タスクには期限があり、それを任された以上は、周りの人の力を借りてでも、タスクを前に進める力が必要でした。
以前、
「タスクを一人で終わらせることも必要な力ですが、本当に困った時に周りの人を巻き込みながら、期限内に終わらせる力も必要です」
とアドバイスされたことがあります。
そのことを考えれば、変なプライドは捨てて遠慮せずに質問したり、他の先輩に相談したりするなど、行動はたくさんあったはずです。
そういう面で、どんな手段を使っても完遂させる気持ちというのが足りなかったなと反省しています。
個人で完結できる仕事はほぼないに等しいので、周りの人を巻き込み、力を借りることも、タスクを進めるための重要な能力とフィードバックをいただきました。
😭 ドキュメントのまとめ方が不十分だった
最後に、ドキュメントのまとめ方についても反省点があります。
引き継ぎ時に、思いやりがなく雑な調査メモを先輩に渡し、「何が書いてあるか分からんよ」と指摘され、そこでも追加で工数がかかってしまいました。
具体的には、
「これを見た次調査を進める人はどんなアクションを取るべきか、どこにあたりを付けて調査を進めればよいかを考えると思います。このNotionから何を読み取りますか？」
「質問の意図としては、次調査を始める人がこのNotionから然るべき情報をInputして、ネクストアクションにしっかり繋げられるのかということです。繋げられないなら時間を掛けてまとめた意味が無くなってしまいます。」
このような指摘を受けました。
今振り返ってみると、自分がメモ代わりに書いたものを、そのまま引き継ぎ資料として共有していたという、かなりまずいことをしていたと気づきました。
指摘を受けて書き直したものが以下です。（before→afterがなくてすみません！）
おわりに
今回は、調査系タスクの進め方が悪く、期限を過ぎてしまった話をしました。
毎回記事に書くのは、失敗談が多いですが、ふと見返した時に成長しているなと実感できる瞬間が最近は多く、なんか嬉しいです！
同じように課題に直面している若手エンジニアの参考になれば幸いです！
では、次の記事でお会いしましょう！👋
参考
- コンサル一年目が学ぶこと
この本は、コンサルに特化した本ではなく、幅広い新人へ向けたビジネス書です
「仮説→検証→フィードバック」のサイクルを高速で回すことで、問題の本質に効率的に辿り着くことができることや、「空、雨、傘」のフレームワークなど、今回の自分の失敗について関連の高いのものを体系的に知ることができました〜
Amazon.co.jp: コンサル一年目が学ぶこと 新人・就活生からベテラン社員まで一生役立つ究極のベーシックスキル30選 : 大石 哲之: Japanese Books
最後に（自分の良くなかった点をもう一個）
わからなすぎて、日報でつぶやいたことに先輩から指摘をもらいました。
タスクの期限を過ぎてモヤモヤした時に、フロントエンドと社内ライブラリが嫌いになりましたと呟いたことの対して以下のような指摘いただきました。
「そう思うのは、すごくわかるけど、皆が見ているところで嫌いと言ってしまったら今後、もしかしたら影響度の高いのタスクを誰かに任せたいなと思った時に、以前この人は嫌いと言っていたなという印象がつくと自然と任せたいなと思われず、せっかくのチャンスを逃すことになるよ！」
とフィードバックいただきました。
自分はなんでも、ズバッと言ってしまうところがあり、まだまだ未熟だったなと思いました。
こういう発言は、以後気をつけたいなと思います！
指摘してくれた、先輩エンジニアには感謝しかないです！🥹