請負仕事の愚痴

このところ愚痴っぽい記事や、説教臭い記事が続いてますが、お盆休みも取れずに、さらに徹夜をしたりなんだりで、こんな時に柔らかい記事が書けるほど器用ではないので、地のままで。。

あるプロジェクトで、とにかく工程管理やドキュメント管理が厳しく求められていて、メンバーも疲弊しており、精神状態や体調にまで影響が出るほどの状態（大げさでなく）なのですが、私は何度も書いているように、短期間のプロジェクトで、なおかつ、試行錯誤が必要なプロジェクトでは、ウォーターフォール型の進め方は無理があると考えています。

私もこのプロジェクトの一部を担当しています。まず、元請けさんから、基本設計書が出てきます。それをベースに詳細設計書を作成するのが本来の流れなのですが、私は交渉して（踏み倒して？）コーディングに着手しました。すると、想定通りなのですが、基本設計書で記述が足りない点がどんどん出てきました。

これは当たり前なのです。机上での設計を100%完璧な状態にするためには、途方もないほどの労力と時間が必要です。実際にコーディングしてみれば、足りないパラメーターや機能は、その箇所を作ろうとするときにすぐに気がつくのです。プログラムを動かすためには、決まっていない部分があったのではコードがかけませんから、嫌でも気がつくのです。

なぜコーディングの前に詳細設計が必要なのかが、私には理解できません。もちろん、画面設計やDB設計、プロトコル設計など、作るために必要なネタはあります。が、それすらも、実際にコーディングをしながらでないと抜けになかなか気がつかないものです。

まあ、実際には、詳細設計がコーディングの前に必要な理由が明確にあるのです。ウォーターフォール型の進捗管理では、各工程ごとにレビューポイントがあり、コーディングの前に詳細設計書のレビューを実施してOKが出たかどうかが重要なのです。後で問題が出たときに、ちゃんとレビューをしたじゃないか、という責任のなすり合いの為みたいなものです。でも、実際には大勢のお偉方が資料を眺めたところで、抜けなど分かるわけがありません。大抵は体裁やボリュームで評価されるという感じでしょう。

不思議なのは、コーディングのレビューはないことです。詳細設計の次のレビューは、単体テスト結果でしょうか。またドキュメントです。単体テストなど、ドキュメントを作るものではありません。ソースを書きながら、どんどん動きを確認するのは当たり前です。単体レベルの内容を後でまとめてテストなど無理です。無理矢理単体テスト結果を資料として出せといわれるので、無駄な工数をそこにつぎ込み、ドキュメントをでっち上げるのです。そんなものをレビューしても意味がないのは当たり前です。なぜソースコードのレビューをしないのかは・・・言うまでもありませんね。。

結合テスト・総合テストは、手順書も意味があります。仕様にしたがって作られているかなどを確認するのですから、仕様書からテスト項目を起こすことができます。従って、本来は、設計した側、あるいは依頼した側がテスト項目を作るべきです。自分が希望した通りに動くかどうかを確認する為ですから。ここもどうもそうなっていないプロジェクトが多い気がします。。

まあ、こんなふうに愚痴を書いてもどうなるわけではないのですが、少なくとも、私は交渉します。意味のないことに労力をかけたくないのと、そんな暇があったら、より良くする工夫に時間をかけたいからです。周りからは「踏み倒し」と言われますが、よく言えば「より良い進め方の提案」です。

なんでこんなやり方が通っているのか、、ということですが、一つは、責任の所在を明確にしたいから・・・というより、責任のなすり合いをしたいからでしょう。もう一つは、コーディングする側の立場が一般的に弱く、提案などできる雰囲気にないからだと思います。厳しい管理をすれば上手くいくというものではありません・・・。

こんな状態だから、なおさら請け負い仕事から優秀な人がいなくなり、製品開発など、提案型をやりたがるのですよねぇ。私もそうです。

あぁ、愚痴っぽい。。