タイトル....すごい大それたことを書いてしまっていますが、
私がPMになってから、特に非エンジニア集団のクライアントの場合に仕様を詰める時に
「気を付けていること」「実践していること」をアウトプットしてみました。
機能リリース後の運用イメージも聞く
要望をいただくときはその後の運用イメージも聞くようにしています。
非エンジニアの方から要望をいただく場合、その要望だけでは運用の改善ができなかったり、
その機能を使った後に、人による手作業が発生していたりするケースが多いです。
例えばなのですが、
「〜のデータをCSVでダウンロードできるようにしてほしいです」
という要望をいただいたとします。
そして、実際に運用イメージを聞くと下記のようなご回答をいただくことがあります。
① ダウンロードしたCSVをスプレッドシートでまとめて毎月分析していきたい
② ダウンロードしたCSVをさらに外部のシステムにインポートしたい など...
①の場合は、CSV出力後
・スプレッドシートにCSVの内容を転記する
・スプレッドシート上の関数とかで計算する
という2つの手作業が発生することが予想されます。
言語にもよるとは思うのですが、2つの手作業は
・システム上で分析結果を表示する
・システムからスプレッドシートに直接書き込みに行く
のような機能を作れば手作業そのものをなくすことができます。
②の場合も、外部システムの仕様にもよりますが、
外部システムを教えていただいた上でAPIなどが存在すれば、システムから直接インポートまですることが可能です。
この辺は、実際に他のシステムなどの知見がないと気付けない部分になってくるので、
非エンジニアの方の目線だと気付けない部分になるのかなと思います。
なので、より知見のあるエンジニア側がアクションを起こしてあげるとクライアントにとって価値のある機能になるのかなと思っています。
※ただし、工数とかクライアントとの契約によってはあんまりいただいた要望以外を行うことができないケースもあると思うのでその辺は柔軟に考える必要があるかな思います...。
できるだけ動くものを見せていく
もし、メンバーのスキルがそこそこあるのであれば、
要望を聞いた上で早急にプロトタイプを作ったりしていました。
プロトタイプを作る時間がかかりそうな場合は、
一旦XDやFigmaなどのツールで画面の動きだけでもサクッと見せれる形を作っています。
これはクライアント先にエンジニアがいようがいなかろうが、やって損はないかなと思っています。
システムを使うのはクライアントですし、
エンジニア目線だけでは気付けない操作のしづらさ、画面項目のわかりづらさみたいなものは
実際に動くものをみないとわからないことが結構多いかなと思います。
私は、実装し始めて「あれ？これ使いづらい...?」みたいなことに気付くことが多いタイプなので、
要望を聞いたら、とりあえず実際のシステムに近い形のものを早めに作り、見せるように気を付けています。
条件が多い場合は、テキストだけではなくパターン表を作る
これは割と本気で気をつけています。
結構私はやりがちなのですが、
条件とかをテキストベースで
「〜の条件でデータを登録するであってますか」
みたいなことをやりとりしちゃってます。
ただ、実際にその条件で実装すると
「あ、この条件の時は〜なんですよー」
みたいなことが検証環境にあげた後で言われることが多々ありました。
なので、テキストだけではなく、もし複数パターン考えられるのであれば、
パターンを表に書き出してクライアントに提出するようにしています。
もちろん、提出するだけでは意味がないので、必要に応じて表の説明・議論を行っています。
ちょっとだけ余裕のある開発スケジュールを組む
基本は余裕のあるスケジュールを引くようにしています。
余裕を持たせるのは
- クライアントから何か共有してもらう必要があるタスク(テキスト内容、リンク先、画像など)
- 開発タスク
- リリースタイミング
です。
（ほぼ全部じゃん....）
私たちエンジニア側にとってもバッファがないと、
急な他の対応だったり、メンバーの体調不良時に
「残業しないと...」
みたいなことになってしまいがちなのですが、
クライアントにとっても、
余裕を持たせておくことによって想定していたリリースタイミングよりも早く、
検証環境にあげる準備ができたりするので、
「え！もう終わったの！」
みたいな感じで少し喜んでもらえたりします（笑）
（喜んでもらえないこともあるのでここは心の持ちようですね...）
最後に
今回は、クライアントから要望をいただいてから機能実装していく中で
「気を付けていること」「実践していること」を書き出してみました。
誰かの助けになれれば幸いです。