仕様を定義できていない実装への対応は後回しにするという考え方
こんばんは、小谷田です。今日は早く上がって道場の稽古に行きました。
さて、今日は仕様を定義できていない実装があった場合の話です。プロダクトのお話ですね。
前提：プログラム仕様とは？
「Aを押すと〇〇が出てくる」などプログラムがするべき動きの定義のことです。
自動ドアで言うと「自動ドアに付いているセンサーで物体を感知するとドアをあける」という動きのことですね。※実際の自動ドアの仕様は分かっていないです、間違っていたらすみません🙏
私は仕事がらアプリやWebサービスの仕様を決めて仕様書に落とすことを良くしています。
仕様定義外の動きが起こる場合がある
そうしてエンジニアさんに実装してもらう途中、動作試験をしている途中に仕様に定義していない動きを発見する時があります。
そう言った仕様定義漏れを無くすのが私の仕事の１つでもあるので申し訳ない限りなのですが、発生する時はしてしまいます。
そんな時どうするか？
選択肢は色々あると思います。
運用に取り入れて問題ない場合、仕様書に書いて仕様とする
動きを修正したい場合、修正仕様を書いて修正してもらう
動きを修正したい場合ですぐの修正が難しい場合、残タスクとしてチケットなり課題管理表なりに記載する
ここで取り上げたいのは2の『動きを修正したい場合、修正仕様を書いて修正してもらう』時です。
2はいわゆる『手戻り』である
2の『動きを修正したい場合、修正仕様を書いて修正してもらう』は手戻りと言います。本来行うべきではなかったことをプラスで行う、というちょっとネガティブな表現です。
どうして手戻りはネガティブか？
各所手間がかかるんです。
仕様書を直す(私)
試験仕様書も直す(試験者)
実装し直す(実装者)
試験し直す(試験者)
もろもろの管理がかかる(私)
とざっと3箇所で追加作業をする必要があります。上記の選択肢1、3の場合は私が手を動かせば済む話ですが、2の場合は試験する人、実装する人、少なくとも2人の手を動かしてもらう必要があります。(場合によってはもう少し多いかも)
開発する時は事前にスケジュールを作っていますが、手戻りは想定外の作業になるので当然スケジュールを圧迫することになります。それは開発プロジェクトにとってリスクです。リスクはできる限り避けるに越したことはありません。
気持ちの継続も大変
あと、手戻りだと気持ちの継続が大変です。すでに手戻りが発生する部分の実装や試験は終わっている訳で(それらをαとします)、手戻りをすると気持ちαがいつまで経っても終わらずモヤモヤします。気持ち的には「αは終わったのに」となってしまうんですね。
そんな時の解決策
αの手戻りとして対応するのではなく、新たにβとして対応するのが私的にはオススメです。αはαで設計、開発、テストと終わらせたのでそこはそこで終わりとし、追加の仕様部分はβとして新規起票して対応する、そうすると気持ちもリセットされてリスクも分散されます。リスクとは当初想定していたαが終わらないというリスクです。
当初想定＝計画、なのでαの終了とはすなわち計画部分は終わらせているという考え方ができるかと思います。もともとの計画が終わっていないとPJとしては危険信号が付いてしまいます。
新たに発生したβは新規課題として既存課題の後に別途検討すれば良いと思います。リリースまでに対応する必要があればその検討が必要ですし、リリースまでに対応する必要がなければベストエフォートで進める方式で良いと思います。
リリースまでに対応する場合「結局リリースまでに対応するんかい。それってαと一緒に実施するのと同じなのでは？」となるかもしれませんが実はそうではありません。
α＋βの課題か、βのみの課題かというα分が丸々変わっています。αも含めて考えるか否かと言っても良いです。仮に手を動かすことはないとしてもαを加味した思考をする分、負担になります。
そこを切り離せば負担もリスクもグッと減ります。
改めて仕様を定義できていない動きに出会った場合
上述の選択肢を変えます。
(再掲) 運用に取り入れて問題ない場合、仕様書に書いて仕様とする
(新規) 動きを修正したい場合、リソースがあろうがなかろうが別途起票して管理する
新バージョンの2が負担もリスクも下げられる手法かと思います。
タスク管理も同じ考え方
この考え方はタスク管理でも同じです。何かタスクを実施していて想定しなかったタスクが発生した場合、当初タスクの手戻りや追加として対応するか、新たなタスクとして後回しにして対応するかでいうと後者の新たなタスクとして後回し対応の方が良いと思います。
表現を変えると手戻りは『考えるのが大変』と言うことができます。考えるって時間かかるし結構負担が大きいんです。なので既存タスクの追加ではなく新規タスクとして扱った方が負担が減ります。
しかし一概に言えない部分もある
上述の話は絶対ではありません。当然プロジェクトの状況によって手戻りでも何が何でもすぐ対応しなければならない時もあると思います。
何が何でも、のケースではない時の参考としてご認識頂ければと思います。
参考になれば幸いです。
以上『仕様を定義できていない実装への対応は後回しにするという考え方』でした！