新米エンジニアが依頼を受ける前に確認すればよかったと後悔したこと

今日伝えたいこと

「気づいたら複数プロジェクトを抱えて身動きが取れない…」
「途中で要件が変わって見積もりの3倍かかった…」

こんな経験、ありませんか？私はめっちゃあります。

受ける前に確認すべきことを確認できていないから、受託可能かどうかを判断できず、無理な仕事を引き受けてしまう。。。

本記事では、依頼受諾前に確認すべき質問テンプレートを作ったので紹介します。
(随時アプデしていきます)

「要望をもらったら、とりあえずできそうか判断して返答する」

この単純なプロセスをやりがちでした。。。

例えば「企画書を出して」という依頼。メモ帳の箇条書きでOKな場合もあれば、PowerPoint数十枚が必要な場合もありますよね。

この認識のズレが、手戻りや追加作業を生み出しているんです。

まず確認すべきは、具体的な内容と時間的制約ですね。

自分が持っていない知識領域の業務を受けると、学習コストで見積もりが大幅に超えることがあるので要注意ですよ。

また実務で私があるあるだったのが。。。
「開発テストまで12/1」のつもりで依頼を受けていたのが、「検証環境への移送まで12/1」のパターン。
チャットでもいいので、これは聞いておいた方がいいです。

リソース制約の見落としが遅延の主要因になっていることが多いんです。

例えば、前段のシステムが未開発なのに、後続作業を受けてしまった場合、
モノがないので作りようがないですよね。私一回これやったことあります。。。
また、リリース直前に偉い人のレビューが入って落とされる、なんてことも見かけました。

スコープクリープ（要件拡大）を防ぐための事前合意が大切ですね。

「この機能を追加すると納期が5日延びます」のように定量的に伝えると、依頼主も適切な判断ができますよ。

依頼主は忙しいですからね。「絶対必要な5つ」に厳選して、詳細は段階的に確認しましょう。

「できるだけ早く」には「具体的には○月○日ですか？」と追加質問しましょうね。

テキストで記録して依頼主にも確認を取れば、「言った、言わない」を防げますよ。
議事録は正義。

「今○○で手いっぱいなので、□日遅れます」と事前共有しないと、後で信頼を失いますからね。
手いっぱいと伝えることは全然悪じゃないです。信用を失うこともありません。

今日は依頼を受けるときに「これやっておけばよかったなあ。。。」をまとめてみました。
他にも意識すべきこと、たくさんあると思うので、ぜひコメントください！