管理はだいじ。レビューもだいじ。

進捗管理者はソースを読めず、
作業担当者はソースを読んでいる時間がない。

作業を行わないものならばまだわかる。
しかし。
作業担当者がやるべき仕事を行わずして
短期間で終わる成功プロジェクトなどありえない。

ソースレビューは1回では終わらない。
方針をもった担当者に確認する作業は
本人が理解するまで行われるものだからだ。
何度も繰返されるはずの作業。
地味に時間のかかると思われるこの作業をやるかやらないかで、
後の品質。即ち保守性はえらいかわる。

経験も得意分野も違うプログラマをまとめるのは
ソースレビューが最も効果的である。
似たような機能を全く違う構成で作られることも無くなる。
また、
作っている本人が作っている最中に修正するのが
もっとも作業時間が短くて済むタイミングでもある。
2週間後の自分は他人も同じ。
「後からまとめてやろう」
ってのは他人に任せるも同じこと。

こうしてソースレビューはやり始めに時間を食い、
進捗を若干脅かすように思われるのだが、
その後が違う。
ソース作りの方針をみんなが理解すれば
ソースレビューにかかる時間は少なくなっていく。
作業者がほぼ似たようなソースを作っていれれば
他の作業者がヘルプに入りやすい状況もできる。
ソースを読むのにコードを読む必要があまりなく、
パターンで読めるようになってくるからだ。

それはさておき。
プロジェクトのスケジュールを作るのは管理者である。
しかし、今の世。
ほんとに管理できている人間は少ない。

スケジュールのひきなおし。

これをやれている人がどれだけいるのだろうか。

やってはいても、行えていないから失敗する。
形式上を踏まえたところしか出来ていないから、
現実はついてこない。
ソースレビューの時間をとっていなければ、
それによる若干のリスケジュールも拒絶する。
目先の棒線に目を奪われるから、
棒線が適正であるかどうかの検証もなしに
「適正であるっ」っと信じてしまう。
実担当者としてはこのあたりに抜け道があるのだが、
サボる以外にはあまり使われない時間なので、有効利用したい。
有効利用できないまま、目先の棒線にしたがっていると、
えてしてプロジェクトは失敗に終わる。
目先の棒線に進捗が追いついている〜っということそのものが嘘であることがあるからだ。
プログラマも嘘をつく。
嘘に自ら進んでだまされ、本番を迎えたところで
「動かないプログラム」に出会うから変なことになる。

いままで幾度となく見てきたパターンだ。
こまったもんだ。

まずは自分の身の回りから変えていこう。
っつか正していこう。
着実に成果を残せば後から文句言われることもない。
ちっちゃなことからコツコツと〜だ(´∀｀)

---

追記、文章訂正後のメモ。
酔っ払ったときの文章は読み直してみるとよくわからんな。ヽ(´ー`)ノ