Edited at

要件、仕様を削る技術

More than 1 year has passed since last update.


64%の機能はほぼ使われない



エンジニアが足りていない

どこの勉強会に行っても、

「We are hiring!!」

ABテストしたけれど全面展開できなくて、モチベーションなくす

→離職率の低減

楽しい仕事したいでしょ!?



要件、仕様を削ることが必要だ!



5W1Hで確認


  • Why?
    なぜ必要か

  • How?
    どうやって
    How often? どのくらい
    How much?
    いくらまでなら出せるか
    お金、リソース
    How many?
    いくつ

  • Who?
    誰がやるのか
    誰が使うのか

  • What?
    何が必要か

  • When?
    いつまでに必要か

  • Where?
    どこでやるか



Why? なぜ必要か


質問例


  • その機能の背景にある課題は何ですか?

  • その機能があることによって、誰がどの程度幸せになりますか?

  • その機能がないことによって、致命的な問題、課題はありますか?



やり取り例

「こういう条件の帳票を出力して欲しい」

→「何のための帳票ですか?」

→業務の流れをよく確認したら、とあるデータの準備・整合性をあわせるための帳票だった。データ発生時に対応すれば帳票は不要だし、業務の流れもシンプルに

「このメールを配信して欲しくないというクレームが来ているので、配信設定で外せるようにして欲しい」

→「致命的ですか?」

セキュリティ、致命的なクレームに発展する可能性がある場合、利用頻度は少なくても、必要性は高いので、対応する



How? どうやって

Howに加えて、


  • How often
    どのくらいの頻度

  • How much?
    いくらかかるか?
    どの程度?

  • How many?
    いくつ


質問例


  • いったん人が運用してみて効果を測ることは可能ですか?

  • それはどのくらいの頻度がありますか?

  • それはユーザの8割は使うような機能ですか?

  • 機能を追加するにしても、どこまで対応する必要がありますか?



やり取り例

「ユーザとのやり取りの記録を管理したいんだけど・・」

→「いったんスプレッドシートで管理できませんか?」

「XXを一括登録する機能が欲しいのだけど」

→「項目が多く、複雑なので、1人月くらい必要なのですが、それでもやりますか?」



Who? 誰がやるのか 誰が使うのか


質問例


  • その機能を作るとして、誰が初期データを用意するのか

  • その後、誰がデータを更新するのか



やり取り例

「ユーザにXX希望設定ができるようにするといいんじゃない?」

→ユーザはわざわざ設定しますかね?最初に設定したとして、データが古くなりません?

→ユーザの操作ログデータを使う方がよっぽどスジがよい

「XXデータにYYな項目を追加したいんだけど・・」

→元データってあります?無かったら、用意できますか?更新どうします?

→要望出した人が別の興味に移って、対応はお流れに



What? 何が必要か


質問例


  • 具体的な機能の仕様はありますか?

  • 具体的な利用シナリオはありますか?



やり取り例

「うちのサービスもAIでなにかできないかな」→

「どういう点で利用しようと思っています?もうちょっと詰めてから持ってきてもらえますか?」



When? いつまでに必要か


質問例


  • その機能を使う繁忙期はいつですか?

  • 優先順位はどの程度ですか?



やり取り例

「この機能ないと困るんだけど」

→「今、事業として、XXを最優先事項としているのですが、XXよりも重要ということを事業責任者に承認取ってもらえますか?」

→後回しにしていたら、要望を出していた人の熱が下がったり、異なる運用方法を思いついて、対応できていたり、そもそも事業の優先順位が変わっていたりする

→後回しにできるものは後回しに



Where? どこでやるか どのシステムで対応するか


質問例


  • その機能はXXというサービスでできるんじゃないですか?



やり取り例

「こんな文面でユーザに同時に一括メールを送信したいんだけど・・」

→都度ベースなメールであれば、独自システムで対応するより、会社で使っているメール配信システム使っては?



最後に注意点


  • 要件、仕様を切るだけだと、信頼関係が崩れるので、代替案、たまにはこちらから要件案を出すのが大事

  • 信頼関係によって、さらに要件、仕様を切りやすくなる