2006-01

なぜITを導入するのか？なぜITが必要なのか？
という問いに対する一つの答えとして、自動化というキーワードがある。

自動化のメリットは、「絶対にミスをしない」「人手がいらない」ということだ。

例えば社員の給料計算を人手で行う場合と、プログラムで自動で算出する場合。
人手の場合は社員が増えれば増えるほど時間も手間もかかり、かつミスも多くなる。
その点プログラムの場合はインプットをしっかりすれば絶対にミスもないし人手もかからない。本当に良いシステムなら、社員10,000人規模の企業でも経理担当者は1人で大丈夫なはずだ。

システム開発自体にも自動化はとても有効で、最近ではテストの自動化は当たり前だし、自動化できるところはとことん自動化することで人手を有効に使うということが日常的に行われている。

自動化というのは、どんどんプログラムに作業を任せて人様は楽をしようという考え方だ。

例えば今日の経験をログとして残すと、知識を他人と共有することができ、かつ、自分自身のリマインダーとしても使うことができる。

日々あったことを詳細に記載すれば、その時は意味のなかったことも後から意味をもつ場合もあるだろうし、自分では役にたたない情報も他の人に役にたつこともある。

そういう意味でブログを書くということは、自分にも他人にもよいことなのだと思う。

ここからはもう一つの話。

ブログを長く続けると、どこに何を書いたのかはすぐにわからなくなる。
それを防ぐために、ブログにはタイトルと内容、日付やグループといった定量データが紐付けられている。（ブログの本文は定性データ）

だからブログの中から探したい情報を探す時は、定量データでデータを絞ってから定性データをチェックする。

The Apple Store (Japan) – PowerBook G4

Mac が欲しいー
今日ヨドバシアキバに見に行ったけど、やっぱりかっこいい。

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

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

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

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

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

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

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

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

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

秋元@サイボウズ研究所プログラマーBlog: CEO Eric Schmidt の語る Google の掟 10 か条