この方法で質問をすると重宝してもらえたり、PJTの仕事が早く覚えられる場合が多いです。自分自身の失敗体験がベースになっています。
関連記事
>> 【体験談0回目】フリーランスになる前の悩みあれこれと解決策
>> 【体験談1回目】エンジニアがWordPressで技術ブログを始める３つのメリット
>> 【体験談2回目】クラウドワークスで登録初日に案件受注した方法
>> 【体験談3回目】フリーランスエンジニアになるのに年齢が関係あるか
>> 【体験談4回目】40代の社内SEがフリーランスエンジニアを選んだ理由と手順
>> 【体験談5回目】2022年の振り返り／2023年の目標設定／想定リスクと対処法
>> 【体験談6回目】はじめてのPJTでスムーズにパフォーマンスを出すため質問の仕方
その１ タスクを振られて質問が出てきたときに使うと良い言葉３選
タスクは無茶振りの場合もありますが、大抵は5分から10分程度簡単な頭出しをもらえるか、Slackなどのテキストベースで要件と背景をもらえることが多いです。
開発現場はみんな忙しいので、マンツーマンで教えてもらえることは中々ないです。軽く要件をヒアリングした後で、一旦タスクを進めてみて分からないことが出てくるのが普通です。
そんな時に使い勝手が良い言葉３選です。
質問に先立って使える言葉３選
- 少し不安がありますので、途中段階ですがプルリクエストを出すので見てください
- 実装（設計）方針を調査、整理して固まったら、一旦ご報告します
- すでに似た実装（設計）はどこかにありますか
先輩目線のメリットは以下の通り
- 先に分からないままタスクを進められるよりも仕事が回りやすい
- もし間違っていても早めに方向修正してもらえる
- 実際にタスクを進めて質問しても、スムーズに回答してもらえる（先輩に心構えができるため）
- 結果として同じ量の質問をしていても、事前に上記のような言葉があるだけで報連相がしっかりしている印象を与えることができる
その２ 質問の仕方
先輩エンジニアが優先順位を取りやすい質問の仕方を心がけると、スムーズにタスクが回る印象です。
Aパターン 回答に時間がかかってもいい場合
◯○でうまくいっていません。他の所の実装を進めます お時間あるときにご回答をお願いします。
Bパターン 急ぎの場合
◯○でうまくいっていません。ここができないと全ての実装に影響があります。 お早めにご回答いただければと思います。
Bパターンは頻発するとウザがられるので注意
その３ 質問前にハマっている部分が仕様なのか、技術的な所なのか切り分ける
ハマっている部分が仕様の場合
- これは先輩に聞かないと永遠にわからない
- すぐに聞きましょう
- 自分で考えて（調べて）分からないことはすぐに聞きましょう。
- 先輩や同僚が忙しそうなら（お手すきで教えてください…）とslackで投げればOKです。
- 極力相手が立て込んでる時や、集中して乗ってる時に割り込まない配慮が必要です
ハマっているのが技術的な部分の場合
- 自分で調べることが可能
- 「ここまで調べましたがこの方向でよろしいでしょうか」とクローズ質問を投げると大体優しく返してくれます
その４ 質問時のルールを決める
- ○○分考えて分からなければ質問する
- 質問はテンプレ文を使い回す（その都度書くのは時間効率が悪い）
- 質問文での可読性を重視しましょう。極力相手に無駄な時間をかけさせないのが吉です
- ガッツリ時間をとって教えてほしい時は、スケジュールを押さえて時間をとってもらいましょう
＃テンプレ例
お疲れ様です。
お時間がある時にご確認をお願いします。
■チケットナンバー
■事象
○○の設計でハマってます
■質問の背景（あれば）
■試したこと（例）
○○類似の設計がないか、ドライブ内を検索しましたが見当たりませんでした。
■知りたいこと
類似設計がどこかにあるかご存知でしょうか。その５ 雑談、ランチ、ミーティングの使い方
ここ数年はリモートワークが進んで、立ち話や雑談が少なくなりました。先輩エンジニアや同僚と絡む機会は有効活用しましょう。
先輩とのランチや立ち話ができる場合
- 今はまっている点をさりげなく伝えるのが吉
- 「◯○の実装ですが、ちょっと苦戦してまして。。。」みたいに。。。
- じゃあ、後で手が空いたら見ますよ！と言ってくれる場合が多い
- 後から炎上したり、かなり時間が切迫してから報告するより100倍いい
ミーティングではでは正直に進捗を報告する
- ドツボにハマった後で報告しても、先輩側もリカバリー期間が短いので大変
- 正直に状況を伝えて、早めに方向修正してもらう
- 問題なければそのままタスクを進めればOK
- リモートワークが進んできたので、ミーティングが唯一の報告場所になっている場合が多い
- 進捗状況、自分自身の焦りや緊張感（あれば）をしっかりと伝えられるよう意識して行動する
その６ 個人学習の方法
PJTでパフォーマンスを出すために、自己学習が必要になる場合があります。その際の注意点です。
注意点
- 技術的な不明点と仕様的な不明点を切り分ける
- 仕様上の不明点はPJT内でしか解決できない場合が多いので、勤務中に解決
- 技術的な不明点はプライベート時間で調べてキャッチアップできる場合が多いので、プライベート時間でキャッチアップ
- ※勤務時間は学習に使わないほうがベター（勤務時間はアウトプットして価値を出す時間と捉える）
- ※手が空いてれば多少は学習してもOK
# 例
# 筆者がある社内システムをオンプレミス → クラウド（AWS）に移行した際のやり方
要件は上司からざっくりヒアリング（google meetで。10分くらい。）
↓
システムの仕様は以前設計構築した先輩からヒアリング（slackで。テキストベースで。）
↓
Ruby on Rails, MySQL, Apache, Passengerの理解が必要なことが判明
↓
自宅で上記についてざっくり学習（技術的な部分）
↓
自宅で無料で検証環境（AWS）を構築／開発、実装し、手順をブログにまとめる
↓
勤務時間中にブログを見なが構築、実装
※上記の流れを色々なタスクで繰り返すことで、爆速で成長できました。その７ 先輩や同僚から業務レクチャーを受けるときの注意点
これは筆者のやり方です。ご参考になれば。
インフラや情シスだと、定型作業やツールの使い方などをレクチャーしていただく場合があります。コード化できている作業ならいいのですが、コード化していない作業も多いので、レクチャーを受ける場合は、以下の方法をとっています。
- 作業のリスクを聞いておく（戻せる作業なのか？／戻せない作業なのか？／戻し方は？／ユーザー影響は？）
- 同じことは2度聞かなくて済むようにレクチャー内容をドキュメント化する
- 作ったドキュメントは必ずレビュー依頼する／そして見える化する（ドライブ上に格納してチーム内に周知するなど）
- 作業は記憶でやらない。手順書やドキュメントに従ってやる（作業品質を一定に保つため）
- 修正のたびに報告する
- 繰り返しが多い作業であれば、自動化する（スクリプト化、ロボット化）
同じことは2度聞かなくて済むようにレクチャー内容をドキュメント化する
なんでもドキュメント作成してしまう事にネガティブな意見もあるかもしれません。でも筆者の場合は脳の癖で聞いことを必ず忘れるか、認識違いしてしまうので、ドキュメント化しています。
よくレクチャー内容はメモをとるか取らないかとかの議論があるかと思いますが、どちらでもいいかと。ちなみに筆者はメモの他に、必要であれば動画や写メも使います（貸与スマホを使います）。
大切なのはプロセスではなくで、レクチャーしていただいた内容を次回以降に自分で同じ品質で再現できるかです。
20代の頃に、先輩エンジニアに同じことを何度も聞いて、しかも何度もミスをしてめちゃくちゃ怒られたのをきっかけにこの方法をとっています。
それ以降は怒られたことはないのでまあまあ有効性はある方法かと思います。また、業務引き継ぎ時やナレッジを横展開する場合も有効です。
繰り返しが多い作業であれば、自動化する（スクリプト化、ロボット化）
業務効率化をして怒られたことは、あまりないです。積極的にやりましょう。
その８ 上記の質問をして横暴な態度をとる先輩エンジニアがいた場合
- 上記のような対応をしても技術的にマウントをとってくる先輩エンジニアがいるかもしれません。
- 早く技術を身につけてそのPJTを卒業しましょう！
- あまりにもストレスが大きければ、すぐに撤収しましょう！