標準化された開発プロセスとは別に、開発現場ではよく顧客から突発的な依頼がきます。
- 問題が発生したので解析してほしい
- 解析ツールを作ってほしい
- 現状進めているプロダクトに変更を加えたい
などでしょうか。
内容が多種多様なためプロセス化することが難しく、うまく仕事をさばけるかは個々のエンジニアの力量に任されている場合が多い印象です。また、顧客側も全てを理解しているわけではないため、潜在的に思っている要望と依頼した内容に乖離がある場合もあり、比較的難易度の高い業務だと思います。
新人のころは依頼を受けるたびに上司や先輩に確認し、確認漏れを指摘され、顧客との間を往復することになります。業界や職務内容によって把握しなければいけない内容は全く異なるため、ビジネス本を読んでもなかなか自分の仕事に落とし込みづらいところ。最終的には肌感覚で覚えていくしかない！という精神論的アプローチが実行されるのではないでしょうか。私も苦しみながら身につけていきましたが、確認事項リストとか作ってくれていたらこんなに怒られなくて済むのに……と思ったこともありました。
ということで、新人時代をがんばる若手エンジニアのために！そして自己整理のために！「顧客の依頼に対して確認すべきこと」を記載しておこうと思います。スタンダードはないけど、最低限これだけは確認しましょう！というものを私の経験を冷静に記載してみました。拙い内容ではありますが少しでも誰かの仕事に参考になれば幸いです。
※組込系ソフトウェア開発領域の実装担当者レベルの内容です
依頼を受けた時の基本的なAction item
依頼を受けたらすぐに以下の２つのActionを行う必要があります。
- 相手の依頼内容明確化 （真意把握、提示日程決定、完成度を規定）
- 打ち合わせの日程の決定（基本的に中間と最終の２回）
これをやっておけば下手に動き回ることなく、正しい現状把握と目標設定が可能になるかと思います。それぞれの詳細は依頼内容によって微妙に異なりますので、以下の章で依頼内容別に記載していきたいと思います。各確認事項の青地部分は見落としがちですが確認必須の項目。
解析依頼（Issue analysis）
各開発の中間フェーズでリリースしたソフトや、市場にリリースされたソフトで問題が発生した場合に依頼されるもの。上位では基本的な対処方針は決まっていまずが実装担当者レベルに直接依頼がくる内容は毎度異なる対応が必要な場合が多い。ただし基本的なAction itemに対する対応は以下がベースとなります。
相手の依頼内容明確化のための確認事項
- 相手は結果を受け取って誰に何を報告する予定か
- いつまでに結果が必要か
- 解析対象のデータの所在、データ受領日程
- 結果提示のフォーマットは何か（ppt, doc, excel, メールなど)
- 完成度はどのレベルを要求しているか（顧客と共通認識できるレベル設定が必要）
必要な打ち合わせ
- 中間報告（方向性と進捗の確認）
- 最終報告（結果の説明。資料は事前送付）
解析ツール作成依頼（Tool development）
顧客側で解析に使用するツールだけでなく単純に解析用の情報提示を依頼される場合もあります。ここでは解析ツールを作成する場合の確認内容を記載することにします。
相手の依頼内容明確化のための確認事項
- 相手は依頼したツールを受け取って何をする予定か
- いつまでにツールが必要か
- 提示するツールフォーマットは何か（exe, excelなど)
- 完成度はどのレベルを要求しているか（顧客と共通認識できるレベル設定が必要）
必要な打ち合わせ
- プロト完成打ち合わせ（動作状況の共有、Limitationに対する合意）
- 最終品の動作デモ（ツール提供前の動作説明）
- 顧客での動作確認後打ち合わせ（提示後のFollow up）
プロダクト変更依頼（Change request）
開発中、もしくは開発完了後のプロダクトに対して方針変更や追加依頼がなされる場合です。変更依頼として開発費を計上している場合が多いですが、要求仕様に載らないレベルの小規模な変更(開発費がかからない程度)に対しては現場エンジニア間で協議される場合があります。この場合、小規模だと顧客が考えていても実際に実装するには多くのタスクが発生する場合があり開発費を計上する必要がある場合もあり、注意が必要です。
相手の依頼内容明確化のための確認事項
- 変更する目的は何か
- いつまでに変更後プロダクトが必要か
- どのデータで検証すべきか（対象データの有無、取得方法、責任分担、データ量の決定）
- 顧客向けに必要なドキュメントはなにか
- (開発費がかかる規模の依頼) 営業担当とプロジェクトマネージャーへ依頼されているか
必要な打ち合わせ日程
- Feasibility studyの結果共有（実装方針明確化、Limitationに対する合意、開発日程の共有）
- 評価データ取得協議 （対象データの有無、取得方法、責任分担、データ量の決定）
- 評価データ取得結果報告 （課題点明確、検証データ利用方針決定）
- 中間報告 （一部テスト結果の報告、課題点の明確化）
- 課題修正後の結果共有 （中間評価で課題が見つかった場合の対応結果共有）
- 最終報告 （結果の説明。資料は事前送付）
プロダクト開発依頼（RFQ, Development request）
スタンダードな開発なので会社で標準プロセスが記載されているため、ここでは特記しません。
プロジェクトマネージャーが顧客との窓口に立つ場合が多く、現場レベルだと直接顧客から依頼を受けることはほぼないかと思います。プロジェクトマネージャーに情報提供することで対応が完了する場合が大半でしょう。
まとめ
最低限で記載してみました。当然これだけで十分ではないかとは思いますが、まずはここから始めてみてもいいかと思います。また、世の中には素晴らしいビジネス本も多数出版されております。今回のブログテーマとは少し異なりますが「仕事の段取りよくしたい！」とか「スムーズに仕事を進めたい！」という方は以下の書籍が大変おすすめです。仕事においてキモとなる（力を入れるべき）部分が具体的に書かれているので、愚直に実践すればスムーズに仕事が進むようになる良書です。
コメント