トラブルの原因は曖昧性に有り

ソフトウェア開発の現場では様々な問題が発生するけれど、その大きな原因の一つに曖昧性があると思う。例えば、開発プロジェクトにおいて、こんなトラブルに遭遇した経験が有る開発者は少なくないはずだ。

開発プロジェクトの曖昧性
開発を完了させれば終わりだと思っていたのに、その後もダラダラと開発が継続したり、運用管理の一部までやらされたりする。
対応要件の曖昧性
担当者間の認識の違いにより開発の終盤になって要件の対応漏れが見つかり、急遽追加作業を行ったりする。
作業分担の曖昧性
誰かに任せておいたはずの作業項目がいつの間にか宙に浮いており、代わりに誰が担当すべきか押し付け合いをしたりする。

開発契約や開発計画書で開発の大枠は定義されているとは言え、実際の作業で直面する個々の内容については、そのような書類には明記されていないことが多い。だからこそ、自分に作業が進める際には、どんな細かな点についてでも明確な定義が必要不可欠となる。

対応する項目

要件xxx

対応しない項目

要件xxx

もちろん、自分の裁量だけでは決められない点も有るから、その点については話し合いをして双方で合意を取っておく必要がある。自分が約束した範囲については責任をもって成果物を出すのが開発者の仕事だけど、その事前準備として「何をどこまでやるのか、或いはやらないのか」ハッキリ決めておくこともまた重要な作業のはずだ。断定調のやり取りをすることに苦手意識を持つ人は多いようだけど、そんな曖昧なまま作業を進めてしまうようでは問題は何も解決できない。

経験を積んだ開発者だと、開発案件を示された際に「ここまでは対応するのですよね」「これは対応しなくて良いですね」と個々の項目について確認を求めてくることが多い。昔はそんな確認を何のためにやっているのか分からなかったけれど、今にして思えば自分の作業は何なのか、自分なりに判断を下して担当領域の決める意思決定をしていたのだろうと思う。依頼したつもりにならないためにも、やってくれるハズという思い込みに陥らないためにも、開発者のコミュニケーションは重要だと理解している。