結論
- 結局コミュニケーションが大切
- 習うより慣れよ
はじめに
本記事は、エンジニアとしてまだまだ勉強中の身でありながらテックリードの任を受けた筆者が、これまでの経験で直面した壁とそこから学んだ仕事をする上で大切にしていることを記したものです。
結論がありきたりで興味を失ってしまった方も多いとは思いますが、それだけ気軽に読める内容なので身構えずにご覧ください。
なお、経験豊富な先輩諸兄にとっては本当に暇つぶしにしかならないことを先にお伝えします。
自己紹介
社会人６年目のサーバーサイドエンジニア
プロジェクトによってはフロントも触るが知識はほどほど
大学時代に一応情報系の学部を専攻しており、素人に毛が生えた程度のベースがあった
最初の壁 - これ聞いていいのかな
前述の通り全くの初学者と言う訳ではなかったことと、着任したプロジェクトがリリース前の新規タイトルでゴリゴリ開発していたこともあり、トレーナーの方にマンツーマンで指導を受けると言うよりは、最初から小さいタスクを割り振ってもらってわからないことがあれば聞いて方式でした。
当然最初のうちはお作法的な部分とか採用されてるフレームワークのディレクトリ構造などわからないことがたくさんあったので質問をしていました。
が、2ヶ月ほど経って少し慣れてきた頃から、タスクの難易度も徐々に上がっていき、どうやって作ればいいかもわからない時がやって来ることに。
そこで思ったのが「これ聞いていいのかな」
忙しい中時間を取らせるのは申し訳ない気持ちと、できないとは言いたくないプライドというか、失望されたくない気持ちから生まれた思いでした。
この後の流れから結論までありきたりなので詳細は割愛するが、当然結論としては無駄な時間掛けずに確認せよです。
ただ、１ミリも考えず最初から教えてもらうスタイルだといつまで経っても自分で開発することができないので、筆者の場合は最大1時間まで自分で試行錯誤してみて無理だったら確認する方式を採用しました。
この結論に辿り着いたおかげで無駄にスケジュール遅延を発生させずに開発完了させることができるようになりました！
第２の壁 - 仕様書は完璧ではない
単純な開発にも慣れてきた頃、DBやAPI設計から対応することも増えてきた。仕様書を設計に落とし込むことになるが、与えられた設計書通りに書くだけだった頃より遥かに考えなければならないことが増えてお腹いっぱいになりました。
めちゃくちゃ考えて完璧だ…と思ったものも、レビューしてもらったらはちゃめちゃに指摘をいただいてしまうこともしばしば。
筆者の力量とか経験不足が招いたものは一旦置いておいて、ここでは外的要因、つまり仕様書に問題があるケースについて触れます。
そう。
「xxxの場合はaになることが正しい」というパターンが仕様書に網羅されていなかったり分かりづらかったりしました。
当然仕様書を書くのは人間なので、完璧な人はいないと思って良いでしょう。
ということで仕様確認をする必要があるのですが、これがまた難しい。。。
基本的に暇な人などいない上に部署が違うと本当にいつレスポンスが返ってくるか読めなかったりする。
中には本当に忙しすぎてチャットを追えていなかったりほぼ一日中会議で捕まらない場合もありました。
なので工夫をする必要がありました。
筆者は緊急度に合わせて以下の３パターンの手法をとっていました。
- 緊急度:高 → チャットで要点をまとめて確認事項を期日と共に投げつつ、直接聞けそうだったら聞く
- 緊急度:中 → チャットで要点をまとめて確認事項を期日と共に投げて待つ。期日の三日前くらいに直接聞けそうだったら聞く
- 緊急度:低 → チャットで要点をまとめて確認事項を期日と共に投げて待つ。期日の前日にリマインド
チャットなんてせずに最初から直接聞けばいいのでは、と思った方もいるかもしれない。
安心してください。理由ありますよ！
第一に、要点をまとめる作業を行うことで自分が質問したい内容を整理することができる点。
これは社会人なら必須スキルかと思うが、意外と何を聞きたいのかわからない質問をしてくる人がいる。
入社当初の筆者もそうでした。今でも自分の中で整理しきれてないときはよくわからない質問をしてしまっているかもしれないが、当時よりは遥かにマシになっているかと。鍛えてくれた当時のトレーナーさんには感謝してもしきれない。
第二に、相手の都合に合わせて回答してもらえる点。
前述した通り暇な人などいないので、すぐに確認してもらえるなどと思わない方が吉です。また、自分1人で仕事をしている訳ではないので、常に相手へのリスペクトを忘れないように心掛けたいですね。
第三に、証跡を残せる点。
口頭確認だけでは後々言った言わない問題やあれ、なんて言ってたっけ。。。と余計なトラブルを生むリスクがあります。
テキストとして残しておけばお互いにとっての備忘録となり設計の根拠としてチャットのリンクでも貼っておけばレビュワーにとっても安心材料になりますよね。
そういう訳で、口頭で確認した場合もチャットに確認した内容を追記するのがベターだと思います。
長々と書き連ねましたが、とにかく質問するときは以下３点を意識していれば大体うまくいくと思います！
- 自分の中で要点を整理する
- 自分本位の聞き方をしない
- 文章で残す
第３の壁 - 売上視点
ここまででそれなりに経験を積んできた筆者にやってきた最大の壁が、ビジネスとして成立させるために売上を意識する必要があるということでした。
プランナーが売上を出すために考えた仕様なので、100%開発することが売上に繋がるハズだが、限られた工数の中では最初に上がってきた仕様をフルで開発できることの方が稀だったりする。
そんな時に、一部分を丸っと削ったりもう少し工数を抑える内容に変更できないか、あるいは開発工数を追加するように提案・相談を行うのもエンジニアの仕事です。
ここで重要なのが、工数ではなく売上への影響を最大の判断基準とするべきということ。
極端な話、工数カツカツだからと超ミニマムでとりあえず実装したところで何も売上にプラスされなければ、その開発に掛けた工数の分だけ損失ということができる。
売上を立てるために必要な要素は残しつつ、工数に収まるようにプランナーとしっかり話し合うことが重要です。
また、筆者の場合は開発工数都合で一度何かの機能を削った場合、次の機能開発では多少無理してでも頑張るとか、突発対応を断らないとかでバランスを取るように心掛けている。
信頼関係が成り立っていないと仕事を円滑に進めることができないと考えているためです。
まとめ
全ての壁に共通して言えることは、適切なコミュニケーションを取りましょうということです。
また、コミュニケーションを取る前提ではありますが、最終的には物量によって磨かれた勘が全てを解決すると筆者は思っています。
筆者が憧れた先人達は大体勘所が冴えているというか、経験に裏付けされた勘によって颯爽とトラブルを解決していました。
なので、とにかく積極的に案件をこなして色んな経験値を蓄えていくのが優秀なエンジニアへの近道だと思って、筆者自身まだまだ精進していきたいと考えています。
最後までお付き合いいただいた皆様、ありがとうございました！