😯

仕様変更をなくすために改善したこと

2023/12/21に公開

最近営業×開発の合同社内LT会が開催され、私は「仕様をどのように決めているか」をテーマに登壇しました。
（実際にはインフルエンザで登壇できず、後日録画する形で共有しました…😭ﾄﾎﾎ）

今回は、仕様をどのように決めていたか、どんな問題点があり、どう改善したかをご紹介したいと思います。

度重なる仕様変更

私は主にコラボフローというワークフロー製品のアップデート開発を担当しています。
仕様を決めるまでの流れは、以下の通りでした。

しかし、完成したあとで主にサポートチームから「これだとユーザーが困る可能性があるから、仕様を変更してほしい」と言われることが多くありました。
期日に間に合うように作ったのに！せっかく作ったのに！キエエエエ！！！😱となり、まぁまぁストレスでした。

1度完成したものを修正するのって、ちょっと悲しいですよね…。

仕様変更が続いたので、以下のように流れを変えることにしました。

実装より前に営業チームとサポートチームに同時に共有することで、相談しながら最終決定することができるようになりました。

実装する前に、仕様を決めるべき人を巻き込むことが重要だと学びました。
また、QAチームにも事前に相談することで、品質を確保する目線が加わりました。

これまで仕様変更依頼があって困る😣ばかり主張してきましたが、私にも問題があることに気づきました。

営業、サポートチームが新規のお客様に分かりやすいか？既存のお客様は困らないか？と考える中、私は「実装できるか？」が心配になっていました。
そのせいで、お客様にとっていい機能になっているかどうかの考えが浅かったように思います。

気づいてからは、以下の点に気を付けるようになりました。

実装できるかはひとまず置いておいて、お客様目線を心掛ける
お客様の要望を満たせる方法はないか深く考えるようにした
（例えば、お客様が〇〇のような機能が欲しい。と言っているからそのまま〇〇を作ることを考えるのではなく、△△がしたいのが本来の要望なのであれば、違う機能でもいいのでは？など）

実装していくと「あ、このパターンは考えていなかった。どうしよう」となることが多々あり、そのたびに仕様を考え、追加修正が必要となることがありました。

検討漏れしていた内容が他の箇所にも影響を及ぼすこともあり、見積もっていた工数より時間がかかってしまう結果となりました。

この点も反省し、自分で仕様を考える際に検討漏れがないか、イレギュラーパターンはないかよく考えるようになりました。

色々なパターンを事前に想定しておくことで、「このパターンのときどうする？」と、相談もしやすくなりました。

仕組みと自分の意識を変えたことで、最近はうまくいっているのではないかなと感じています。
LT会の後、同じ開発チームからも同様の意見をいただけました！

今後も問題があれば、どんどん改善する意識を持ちたいとおもいます✨

私達は『ワークスタイルの未来を切り拓く』という理念のもとワークフローの本質を追求し、新しいワークスタイルを提案するとともに、コラボスタイルが率先して時代に適したワークスタイルを常にバージョンアップし発信していきます。