仕様書は聞いたか決めた事で作られているのではないだろうか

分からない事は聞くか、決めればいいのにそれを怠ってしまうのはなぜだろう。開発の段階で仕様書に書いてないとか、質問事項が山のように出てくるのは、聞き忘れたのか、決めていないのか、書ききれていないかのどれかではないだろうかと考えています。

聞かなければいけない事、決めなければいけない事が洗い出せていないというのもあると思います。この機能は何を実現すべきなのか。実現するためには何をすればいいのか。トップダウンで噛み砕いていけば、精度も上がるものだと思っていますが、なかなかうまくいかない。

仕様書は書き物だから、これから書こうとしている内容で知っている事を無意識の内に省いてしまったり、うまく説明できなかったり、どこか達成感の無いまま作業を完了としてしまっている所、期間の圧迫により妥協してしまった所、いろいろな側面によって質が悪いまま次工程へ進んでしまう事もあると思います。

正解が分からないから決めかねるというのはあるかもしれないが、それも聞けば良いだろうし。今日は丁度良い機会が与えられているので、プロジェクトメンバー各々に「今自分の抱えている作業で納得がいかない所、どうも達成感が無い所は無いか」と尋ねてみたいと思います。その答えはもう分かっていて、それは「ある」です。ではなぜ納得がいかないのか、達成感が無いのかと聞いてみると「分からない所がある」だと思います。ではなぜ分からないのだろうと突き詰めていくと、最終的には「分からない所が分からない」とか「誰かが決めてくれるのを待っていた」とかいろんな意見が出ると思います。

それらを現工程の問題点として挙げて、具体的にどうしたらいいのか。次工程の土台となる現工程の土台を固めるための動きをしてみようと思います。分かっているんだけど、やっていない事、どうすればいいか分からない事というのは絶対にあるはずです。各々が妥協せず達成感を得るためにはどうしたら良いのかという具体的なアウトプット、落とし所の意識合わせも重要そうです。

上流で失敗という小石を転がしたら、下流では巨大な岩になって現場に襲い掛かるはずなので、問題の芽がまだ小さいうちに摘み取ってしまおうと考えています。理想論ですが、できないはずがない。やればできるんだから！できないなら何かが足りないんだから、何かを足せばいい。それは時間との戦いになるんでしょうけど…。

とりあえず成功するための努力を惜しんだ分だけ成功から遠くなるか、成功の質が落ちるんじゃないかと考えて、プロジェクトメンバー全員が成功への意思を持てたらいいなと思っています。