新卒の研修のときにグループワークで、ある課題を抱えた顧客にシステム提案をする、という研修があった。
提案依頼書(RFP)的な資料は渡されていて、書かれていない要件のうち提案書に必要な情報は、顧客役の講師に確認しに行く必要がある、という形だった。
特に事前の説明なく始まったグループワークだったけれど、定石というか、時間内にそれなりの成果物(提案書)を作成するための手法(🟰研修的には"正解")があったことが最後に答え合わせ的に開示された。
・RFPから、顧客要望を読み取り、チームで合意する
・提案書のある程度の目次を作成する
・RFPの内容を細分化し、それぞれチーム内の個人に役割を決める
・役割ごとに、提案方針を検討し、提案にあたって必要な情報を各々洗い出す
・洗い出された情報を取りまとめて顧客へまとめて確認する
・チームに戻ってまた役割ごとに目次に沿って提案書へ落とし込み
・マージして全体の体裁や文脈を整える
ここで重要なのは「個々人に必ず役割を振ること」「顧客への確認は1名ないし2名でとりまとめて行うこと」の2点。
役割が曖昧なままなんとなくみんなで始めると、時間制限的に完成が難しい状況だった。｢アサイン、タイムキーパー、とりまとめ｣の役割の人(今回は規模的にまとめて1人でok)を最初に決めるのが吉。
顧客確認については、気になったことをバラバラ各々確認しにいって顧客のリソースを浪費してはいけない、という減点ポイントだった。
ただ、今実業務に携わっていて、新入社員研修で教わるレベルのこの2点、できてないこと結構あるなと思ったり。
役割があいまいなままアサイン待たずに｢まぁやるか｣となし崩しで始まる業務(というかアサインする人自体不明確)、色んな視点からバラバラと顧客確認が入る課題管理、よくないんだろうけど、やらないと進まないしな。
顧客側もそこはわかっているしなんなら要件定義フェーズで追加要件が向こうからバラバラ出てくるとか言ってること変わってくるとかもあるあるなので、お互い様な部分もあったりする。
そういうのに臨機応変に対応してくのが仕事なんよね、研修で定石を学ぶのはそれはそれで大事だったと思うけどね。
新入社員研修の季節で（全然関わっては無いけど）思い出した思い出話でした。
Sponsored Link
