既存サービスとして既に運用がスタートしているシステムの改修プロジェクトに私は開発側メンバーとして参画していた。
改修後のシステム要件を詰める際、意思決定に時間が掛かり、なかなか要件を詰めることができない場面に何度も遭遇した。
皆さんにも同じような経験はないだろうか？
原因は色々あると思うが、その1つとして私が体験した「無邪気な要望」について触れたいと思う。
- 開発側にとって要望とは
- 無邪気な要望とは
- どうして無邪気なのか
- 要件を詰めていくために
1：開発側にとって要望とは
そもそも、開発側にとって要望とは何か。
「開発側にとって要望とは、本来受け取るものであって開発側で要望・要件内容を決められるものではない。」
要望や要件は、開発側で勝手に決められるものではないので
案件の意思決定者に何をどうしたいのか、明確な意思と決断を示してもらわないと始まらない。と私は考えている。
本来は意思決定者から何をどのようにしたいのか、をまずは要望を投げていただかないことには要件を詰めていけないのだ。
2：無邪気な要望とは
では「無邪気な要望」とは何なのか。
「そもそも要望として挙がってくる内容がおかしかったり、何をどうしたいのか意思なく直接要望内容をシステムに尋ねてくること」
上記のような要望を私は「無邪気な要望」と呼んでいる。
意思決定者が既存サービスとかけ離れた内容の要望や、既に実装済み機能であるにも関わらず同じ内容を追加要望として挙げてくるといったケースや
どのように改修すればよいか、を直接システム側に意思決定を丸投げするケースにこれまで遭遇してきた。
3：どうして無邪気なのか
なぜなのか。
「無邪気な要望」が挙がってくる背景として以下のようなことが考えられる。
- 意思決定者が現仕様を把握していない
- 意思決定者が運用フローを把握していない
これは意思決定権を持つ方が、対象サービスの現仕様内容から理解が離れていたり
現状の運用フローを外部委託先に任せているため実態を把握できていないことが多い。
その結果、意思決定者がふわっとした理解で要望を語ってしまうので自身でも内容の誤りに気づけなかったり
サービスとしてあるべき姿を正しくイメージできていないので本人ではわからず手っ取り早くシステム側へ直接尋ねてしまう＝「無邪気な要望」を生んでしまうのだ。
そうして、結局意思決定ができず、要件詰めに時間が掛かってしまうのである。
4：要件を詰めていくために
できるだけこの「無邪気な要望」の頻出を避けつつ、意思決定を円滑に進めなければいけない。
そのためにも、意思決定者だけでなくシンプルにまずは、初期段階でシステムを含めたプロジェクトに関わる全てのメンバーと
既存「仕様」「運用フロー」を復習・すり合わせし、皆が共通の認識理解を持つことを徹底するのだ。
意思決定者1人だけが、全ての仕様や運用を理解しようとしても限界がある。
意思決定者、システムの双方で互いの認識レベルを揃えることでシステムからも意思決定のためのフォローができるので
「無邪気な要望」ではなく実態に沿った要望が挙がってくるようになるので、要件決めの意思決定は加速するのである。
プロジェクトがある程度進んでいたとしても、認識齟齬からくる後々のしわ寄せダメージを回避するため是非時間をとって行ってほしい。