s

今の職場

久しぶりにブログを更新します。

内容は、現在出張中の職場についてです。

私は今プロジェクトのプログラマーとして働いており、他のメンバーにPM、PL、設計者、プログラマー、テスターがいます。(一人が複数の役割を担当していることもあります) 当プロジェクトには、要件定義書、基本設計書があります。他にもコーディング規約やレビュー規約があり、ソース管理、バグ管理システムもあります。ですが詳細設計書はありません。

その結果、プロジェクトの成果物であるコードを見ると、やはり行き当たりばったりのコードが多く見受けられます。仕様を全て洗い出していない状態でコードを書き始めているので、書いている途中で新しい仕様が必要になり、その度に付け足すというコーディングをしている為に起きている現象です。開発中に気づかれない仕様も多くあり、その度にバグが報告されます。不完全な状態でも一旦仕様を凍結すれば、事態は収束するのに、いつまでたっても仕様が凍結されることはありません。納期まじかになってもまだ仕様は変わり続けます。

テストに関しても仕組みは素晴らしいです。Junitをカスタマイズし、DBとの比較も簡単にできるようになっています。null同士の比較ができない?などの漏れもありますが、それでもとても使いやすいです。ただ仕様がないので、完全なテストはもちろんできません。

また基本設計書をもとに開発し、開発中に付け加えられたり、改変された仕様はドキュメントのどこにも残っていません。保守作業をする人はコードを見るしかないんでしょう。

と、不満をずらずらと書いてみました。ここから、これらの不満を解決する手段を考えてみます。

これらの問題を解決するには、基本設計書の粒度をもっと細かくし、詳細設計書を作成することだろうと考えています。ですが、詳細設計書の作成はプロジェクトの方針として作成しないと断られてしまいました。ということはあとは基本設計書の粒度を細かくし、単体テストを完璧なものにするという方法しか考え付きません。

ということで、来週月曜日は基本設計書の漏れや不具合をバグ管理システムに上げ、仕様が決まった機能から単体テストに入っていこうと思います。唯一の気がかりはスケジュールから約3週間遅れていることです。。