基本的な設計が終わったらコーディングして設計上のミスを発見する＋コーディング結果を詳細設計とする

※下記で説明する手法は一般的に知られたものであり、また、私が今関わっているプロジェクト内でしか通用しない可能性があります。

基本的な設計が完了し、顧客要件も粗方吸収し終えたら、次の設計フェーズに入るポーズをしつつ、そのままコーディングを実際にやってしまうという方法を今やってる。

完璧なコーディングを目指さないで、だいたい処理を記述してしまう。こういう場合、抽象コードを書く人もいるのだろうが、私は最後まで残るコードを直接ガリガリ書く。今使っている言語はJavaだから、Javaでゴリゴリ書く。実際にある程度手を加えれば動くレベルのものを。処理の本質に関わらないようなトリビアルなコードはTODOコメントだけ書いて省略。（こうしておけば後でEclipseのタスクビューでピックアップできる）

あえてコーディングにすぐ取り掛かることで、仕様に何が必要か、何が抜けていたか、実際に実現可能か、何がポイントか、どのようなものを実装しようとしているのかがシームレスに分かってくる。

そうして先にコーディングした内容を詳細設計書としてしまう。

逆じゃん、って感じだけど、詳細な設計書ほど『コードを劣化させたものにすぎない何か』になってしまうので、詳細な設計書フェーズではコーディングを優先させる正当性は十分ある。

もちろん一番なのはそんなソースコードの腰巾着にしか過ぎない設計書を作らないことだ。ただ、私が今いる現場は開発プロセス中の設計書が全部ガチガチに指定されてるから詳細設計書を作らないのは無理。（とはいえ、完全に作らないとなると、それはそれでシステム引継された後任者が困ることだろう）

こういう、一見真面目な一般人から見るとフザけたことをやると普通は嫌われる*1。その点、私に限って言えば、十二分にプロジェクトを牽引した実績があるし、なにより今の開発には自信があるし、楽しいし、実際工期圧縮という点で合理的なので周囲から受け入れられている…　ような気がする。

ただ、複数社そろって同じ開発プロセス・手順を組み込んでいるような現場なので、この開発手順は他社には公にはしない。あいつらにどう妨害されるか分かったものじゃない！

*1:大変残念なことに、皆で同じことをやって失敗するのは許されるが、誰か一人が別のことをやって失敗するのは全く許されないのだ。そのため、プロジェクトリーダーの想像力の範囲内の作業しか行ってはいけないことになっている。その点私は安い賃金で雇われているサラリーマンなので、そんな柔軟な想像力に従う義理はないという態度だ。酷い、管理者泣かせだ。