開発のスケジュールを見ると結構余裕あるな？と思ってみると、
査読とかレビューの時間が大半だったりすることが多い。
つまり、ｘｘｘを作るスケジュール＝ソースを作る＋テスト＋ソースレビュー
なのだ。
困ったことにレビュワーの時間なんて都合が付かないことが多い。
なぜなら、レビュワーとして参加する時間はスケジュールに１秒も入っていないのだ。
ま、それはそれで文化なんだろけど、
文化の始まりにはsvnどころかcvsも無かっただろうから・・・（笑
ソースの組み込みはすべて手作業であっただろう。
故にレビューしておかないと知らないうちに
変てこなモノがシステムに組み込まれてしまうからだ。
だから、必要だったのだろう。
長いソースを印刷してレビューすることもある。
しかし、今はsvnやcvsがあるからコミットし、レビュワーに事前に読んでもらうこともある。
そこが一大事。
ソースを配布してからレビューすることになる。
たまにソースが真っ赤っか（シンタックスエラー）なんてことも共有しているソースなんだから起こりうるのだ。
コンパイルできません。
今日は帰るか。
なんて云うこともある。
※云うだけだけどね。
つまり、しっかりレビューをする文化は容易にsvn上でシンタックス・エラーを起こしてしまうのだ。
そんな訳で、安全策として、自分用のローカル・リポジトリと共有リポジトリを分けてるようなものが、だんだん増えている。
GitのGitHubみたいにね。
だが、レビュワー視点でものを考えると、
シンタックスエラーなソースをコミットした奴が悪い程度にしか思わないから、
それで割りを食っているその他大勢のことは無関心で、
そんなものは導入することなぞ、考える余地がある訳もない。
そう先の「後で名前を揃えればいいや！」と同じである。
このように非常に非効率的な仕事のやり方は一般的でドコでもやっている極普通なやり方である。
マネージャ研修でレビューの重要さを叩き込まれても
スケジュール管理の難しさを教えられても
マネージャの都合に見合ったクリティカル・パスを引く。
はっきり云えば何かのイベントをスケジュールに上塗りするだけ。
都合の悪いところにクリティカル・パスを絶対引かない。
スケジュールが送れる予想が付くのが嫌なのだ。
はっきり云えば、スケジュールが間に合うかのようにクリティカル・パスを引いてしまうのだ。
当然だが、
その文化は、毎日せっせと元気良くデスマーチの道を歩むためのものでしかないのである。
南無南無。