この記事はモチベーションクラウドシリーズ Advent Calendar 2020の10日目の記事になります。
はじめに
20年新卒でモチベーションクラウドの開発を行っております。
8月末まで、RubyやRuby on Railsの研修を受けた後、エンジニアグループに参画しました！
これまでに四か月弱実務に当たる中で、いろんなつまずきがありました。
しかし、新人エンジニアが少し意識してコミュニケーションをとることで、回避できる箇所が多いと思いました。
技術的に考える時間を増やすために、新人の成長角度を最大化するために、意識すべき観点3選として、この記事を書きたいと思います。
実際に何が起きたか
意識すべき観点を抑える前に、実際にこのようなことが起きていました。
- 先輩から、「三時間ぐらいで終わると思う」と言われたものが二日経っても終わらない
- やっとの気持ちで作ったアウトプット物が、先輩の考えていたものと違った
- どのように作業を進めていけばいいかわからなくなって、考えているつもりがいつの間にか悩んでしまうことがある
自分の中で自分と先輩の違いが何かを考えてみたら、以下のようなことが出てきました。（もちろん他にもあるかと思います。。。）
- 自分がどれぐらいの時間で出来るかイメージがついていない
- 先輩は簡単にできると思っている
- 自分は今考えている一通りでしか実現できないと思っている（さらに、具体的にどんなコード、コマンドを試すかあまりイメージがついていない）
- 先輩は複数のやり方が思い浮かんでいる（さらに、具体的にどのように試そうかイメージがついている）
- 自分は出来上がったもので何ができるかぼんやりとしかわかっていない
- 先輩は出来上がったもので何ができるか明確になっている
ここを解決するぞ〜という課題感で、抑えていったポイントをご紹介させていただければなと思います！！
抑えるべき三つのポイントとは
- アウトプット物を明確にせよ！！
- 段階に分けて定義せよ！！
- 最初の作業を言語化せよ！！
と、分類しました！
それぞれ具体的に説明していきたいと思います！
その前提として。。。
この記事のターゲットは新人のエンジニアや、その人たちと業務の中で頻繁にコミュニケーションをとる人たちです。
以下のポイントは実際にコミュニケーションをとる相手と合意することが大切だと思っています。（前提がないといきなりめっちゃ質問してくるやん。考えろよって思われてしまうかもしれません）
1. アウトプット物を明確にせよ！！
必ずしも、先輩が明確なアウトプットのイメージを持っているわけではありません。そのため、答えを聞きに行くわけではないです。
大切なことは、すり合わせることです。
最終的なアウトプットの具体的なイメージを先輩と共有する作業になります。
先輩が作って欲しいと思っているものが、自分が思い描いているものと一致していなくとも、同じ方向をむいている必要があります。
先輩は自分が今、どれぐらい理解していて、何を考えているかどうかはわからないので、毎回、確認すべきだと思います。
お互いの中で、当然そうだよね。とわかり合うまでは確認すべきだと思います。
例えば、「ちょっと計算早くしたいから、やってみて？」という依頼だったら、
- 「変更範囲をDraftでPR出しておけばいいですか？」
- 「スプレッドシートに結果を一覧でまとめた方がいいですか？」
- 「変更分の性能調査はしておいた方がいいですか？」
など、質問すればアウトプット物が明確になり、認識の齟齬はなくなっていったかと思います。
アウトプット物の認識を握って、ずれを無くしていきます！！！
その際に意識する観点としてQCDの観点というものを意識しておりました。
QCDとはそれぞれ
- Quality:どのような内容のものか
- Cost:どれぐらい時間をかけるものか
- Delivery:いつまでに終わるべきものか（締め切り）
と定義されており、図式化すると以下のようなトレードオフな関係になっています。
引用：生産管理の「QCD」とは？プロセス改善で向上する企業の提供価値
この観点から、タスクを切り分けて**「いつまでに、どんなものを、どのクオリティで出すか」**を具体化していきます！！
2. 段階に分けて定義せよ！！
段階に分けるって何？と思われるかもしれませんが、
先輩が、**「どれぐらいのレベルでやってほしいと思っているか」**という期待値で分類することを意味しています。
- このタスクの最高の期待値って何ですか？
- このタスクのそこそこの期待値って何ですか？
- このタスクのミニマムの期待値って何ですか？
と、実際に質問してそもそもどの程度のタスクと認識しているのかを知ることから始めます。
例えば先ほどと同様「ちょっと計算早くしたいから、やってみて？」という依頼だったら
- 最高の期待値：人の助けを借りながら実装して、仕様によって変化するリスクを洗い出し、影響範囲が小さい仕様を検討出来ている状態
- そこそこの期待値：人の助けを借りながら実装して、計算が早くなり、変更した際の影響範囲を洗い出せている状態
- ミニマムの期待値：人の助けを借りながら実装して、計算が早くなり、ひとまず動かせるようになっている状態
といったような内容になります。
これをしてみてよかったなと思うのは、
- 先輩が自分の能力をどれぐらいと思っているかわかる
- 自分が出そうと思ってたアウトプットより、質の高いものにチャレンジできる（大体最高の期待値は自分が考えもつかなかったようなものです）
- 最低限守るべき箇所がわかる（ミニマムの期待値）
期待値をすり合わせ続けていくことで、お互いの認識の齟齬がなくなっていき、自分が本当に求められているものを作っていくことが出来るようになってきました！！
3. 最初の作業を言語化せよ！！
最後は具体的にどのように手を動かしていこうか最初に言ってみることです。
初心者あるあるだと思うのですが、僕はそもそも先輩エンジニアと上手く言葉のキャッチボールが出来ませんでした。（言葉を正しく使えておらず、聞いている先輩が首を傾げながら聞いていることが多いです）
正しく言葉を使えるようになるという観点からも、言語化して、最初の一歩が間違っていないかすり合わせました。
例えば、先ほどと同様「ちょっと計算早くしたいから、やってみて？」という依頼だったら、
- 最初はクエリでどのようなデータが入っているか見ていこうと思います
- その次にデバックして既存のデータがどのようになっているかを確認します
- 次に、どのようなデータが返ってきて欲しいかを考えます
など、具体的な自分の作業手順のようなものを確認しました。
作業をする中で、都度確認もし辛い状況でしたので、最近はslackを使って、非同期的に確認してもらうようにしています！！
ここに、自分のメモ書きのようなものをどんどん残していくと、先輩も見やすい時に確認してくださるようになりましたし、振り返る時もどこで時間が多くかかったか、どのようなエラーで詰まっていたのかを簡単に共有できるようになりました！！
（↓以下のような例）
やってみて変わったこと
変わったことは自分の中でしっかり振り返りが出来るようになったことです。
ゴールを明確にして、自分がどこで詰まっていたのかがわかりやすく残っているので、同じようなことで詰まったときに振り返ることができますし、
間違った理解をしている箇所が、他の人からわかりやすくなるので、どこで勘違いが起きているかを指摘していただけるようになりました！！！
自分の修正ポイントや、伸ばしていくべきポイントがブラッシュアップされてきてるかなと思います！
まとめ
（僕自身そうなんですが、、、）求められると「やります！！！」って言いたくなるし、結果を残そうと思ってしまうのですが、簡単に結果が出ないことの方が多いです。
その中で、自分ができることは早く貢献できるように成長することが大切だなと思っています。
そのために、最初はとても時間がかかってしまうかもしれませんが、丁寧にコミュニケーションをとって、常に考えて、技術を伸ばしていける状態を作ることが大切だなと思っています。
僕自身書いたことを常に実行できているわけではないですが、意識して少しづつ行動を変えていきたいと思います！！！
誰かの参考になれたら嬉しいです！！！
明日は、フロントエンドエンジニアとデザイナーの関係構築についてデザイナー杉江からの記事になります。楽しみ、、！！