新米エンジニアが依頼を受ける前に確認すればよかったと後悔したこと
今日伝えたいこと
- 依頼の詳細を把握しないまま「できます」と言うのが、パンクの最大原因
- テンプレート化して、確認事項を覚えておこう
はじめに
「気づいたら複数プロジェクトを抱えて身動きが取れない…」
「途中で要件が変わって見積もりの3倍かかった…」
こんな経験、ありませんか？私はめっちゃあります。
受ける前に確認すべきことを確認できていないから、受託可能かどうかを判断できず、無理な仕事を引き受けてしまう。。。
本記事では、依頼受諾前に確認すべき質問テンプレートを作ったので紹介します。
(随時アプデしていきます)
なぜパンクするのか？
「要望をもらったら、とりあえずできそうか判断して返答する」
この単純なプロセスをやりがちでした。。。
例えば「企画書を出して」という依頼。メモ帳の箇条書きでOKな場合もあれば、PowerPoint数十枚が必要な場合もありますよね。
この認識のズレが、手戻りや追加作業を生み出しているんです。
質問①：業務の詳細と期限
まず確認すべきは、具体的な内容と時間的制約ですね。
- この業務の具体的な内容を教えてください
- 含まれる作業範囲と含まれない範囲を整理させてください
- 納品形式は何ですか？
- 納期はいつで、柔軟性はありますか？
- この業務の背景や目的は何ですか？
自分が持っていない知識領域の業務を受けると、学習コストで見積もりが大幅に超えることがあるので要注意ですよ。
また実務で私があるあるだったのが。。。
「開発テストまで12/1」のつもりで依頼を受けていたのが、「検証環境への移送まで12/1」のパターン。
チャットでもいいので、これは聞いておいた方がいいです。
質問②：前提条件
リソース制約の見落としが遅延の主要因になっていることが多いんです。
- 必要なデータや素材はいつまでに提供されますか？
- 開発環境（サーバー、ライセンス等）は準備済みですか？
- レビューやフィードバックはどなたが行いますか？
例えば、前段のシステムが未開発なのに、後続作業を受けてしまった場合、
モノがないので作りようがないですよね。私一回これやったことあります。。。
また、リリース直前に偉い人のレビューが入って落とされる、なんてことも見かけました。
質問③：変更への対応方針
スコープクリープ（要件拡大）を防ぐための事前合意が大切ですね。
- 変更や追加要件への基本方針は？
- 追加機能の判断基準と優先順位は？
- 変更の承認体制はどうなっていますか？
「この機能を追加すると納期が5日延びます」のように定量的に伝えると、依頼主も適切な判断ができますよ。
注意点
質問過多に注意
依頼主は忙しいですからね。「絶対必要な5つ」に厳選して、詳細は段階的に確認しましょう。
曖昧な回答は深掘り
「できるだけ早く」には「具体的には○月○日ですか？」と追加質問しましょうね。
合意内容は必ず記録
テキストで記録して依頼主にも確認を取れば、「言った、言わない」を防げますよ。
議事録は正義。
現在のキャパを開示
「今○○で手いっぱいなので、□日遅れます」と事前共有しないと、後で信頼を失いますからね。
手いっぱいと伝えることは全然悪じゃないです。信用を失うこともありません。
まとめ
今日は依頼を受けるときに「これやっておけばよかったなあ。。。」をまとめてみました。
他にも意識すべきこと、たくさんあると思うので、ぜひコメントください！