アプリケーションを企画するならば、理想の状態を定義しないと不具合かどうかすら判断できません。

@nabeemichi です。

アプリケーション開発をしていると、テストを行います。 リリース前に評価チームがテストを行い、仕様があっているかや不具合がないのかについてテストを行い、 不具合がある場合は、開発に不具合の修正依頼がきます。

不具合がないアプリケーションなんてものは存在しませんので、テスト段階で不具合修正依頼は必ずきます。 エラーが起こる場合は技術的に間違っているので修正方針もはっきりしていますし、不具合だと特定することができます。 しかし、動作的におかしい場合は話が変わってきます。

動作的におかしい場合は、

アプリケーションとしての理想の状態

を定義していないと、おかしいと判断できないはずなのです。

特定の条件のときに、動作が意図してない状態なので修正してください！

と、依頼されても何が意図していないのかは特定できない。 仕様書を見ても全く記載がない。 僕に決定権がないようなチーム体制で仕事をする場合は、どうしようもなくなってくるわけです。

だってその不具合、開発時に発生したものではなく、企画が仕様書を作った時点で発生している、仕様バグですから。 仕様が不具合なのです。

もし仮に、僕が決定権もっていたら

僕が理想の状態を考えて仕様から修正してしまうのですが、 そもそも、どんな課題を解決するための機能なのかが理解できないと、こっちとしても独断的修正どころか、 仕様の修正方針の提案すらできないのです。

もうこうなると、企画者に理想の状態の定義をしてから、不具合であるかを決めてください！

と、エンジニアは言うしかないのですよ。

仕様書に課題が明記されてたとしよう

この場合は、エンジニアが対応方法を考えて提案できる。 課題から解決方法として、機能を考えられる。 そして、課題が解決された状態が理想の状態であると考えることができるので、 現時点とのギャップがわかる。

ここまでくると、不具合が何であるのか？を定義することができるのです。 これをしないと、対応方針もきまらないし、そもそもユーザーが何したいのかわからないんじゃないの？

なぜやるのか？

なぜつくるのか？

なぜこの機能なのか？

ココらへんを説明してない仕様書やチームと働くと、プログラミングを淡々としてくれるロボット作った方が効率的ではないでしょうかね？