開発チームのメンバーに作業を依頼するときに、どのような情報を伝えるかは重要なポイントになります。メンバーが十分に理解して納得して作業に取り組んでもらった方が、認識齟齬によって生じる手戻りを防げるし、メンバー自身にも主体性が生まれるだろうと思っています。
で、伝える情報をどのように整理するか。例えば、次のような観点で整理してみます。
Why
なぜこの作業が必要なのか、エンドユーザーが困っていることは何か、全体を俯瞰して概要や影響範囲を説明します。これから自分が取り組む作業にはどんな意味があって、これをやることでどんな効果があるのかを認識してもらいます。さらに、メンバー自身がこのチームに存在する意義を見出して欲しいと思っています。「自分は誰かの役に立っている」と認識することで、主体性と責任感を持って作業に取り組んでもらえればと考えています。
What
Why の課題を解決するために何が必要か、これから何を作るのか/改善するのかを説明します。Why の内容と対になるように説明することでより理解しやすくなると思います。
How
What をどのように実現するか、どうやって作るか、そのためにどのような前提知識が必要になるかを説明します。メンバーのスキルレベルによって伝える情報の粒度を変えたりします。すでに独力で進められるメンバーであればざっくり説明して任せるし、経験の浅いメンバーであれば図解して説明したりドキュメントに落とし込んで説明します。いずれにしても、何かしらの形で設計のレビューはします。
When (How much)
作ったものはいつリリースするのか、そのためにはいつまでに作業を終えて欲しいかを説明します。リリースやテスト/レビューの時間を考慮していくつかマイルストーンを置きます。あらかじめ無理のないスケジュールを設定しますが、朝会などで進捗を確認して必要に応じて都度調整します。
Who
なぜこの作業をあなたに任せるのかを伝えます。「仕様を把握しているから」「過去に類似の作業をやったことがあるから」「フロントエンド、あるいはバックエンドが得意だから」「詳細なドキュメントを作って欲しいから」など、こちらから伝えられることは伝えるようにします。ただ、このあたりはメンバーの性格や仕事の進め方などを分かっていないと、なかなかこちらの意図通りに伝えるのは難しいかもしれません。
とはいえ、だいたいいつも「今、手が空いてるひとがあなたしかいないのでぇ～」みたいな雰囲気になりがち。
このような観点で情報を整理すると自分の理解にも役立ちます。当然、自分がきちんと理解していないとメンバーに正確に伝えられないので。現場からは以上です。
