短納期の開発プロジェクトにアサインされちった。。。
アサインされちった、といっても、もう3か月前のことなんだけどね。いつもの開発リーダー（サブPM）ポジションで。
このプロジェクト、見積もりの規模からするとかなり期間が短い。しかもシステムの特性上、納期はずらせない。
まぁ、客の初動が遅かったり、発注が遅かったり、要件が固まってなかったり、そりゃ遅れるよねと。
こちらはこちらで、新しいフレームワーク使ってみたもんだから、設計で四苦八苦。
「アレできる？」
「標準機能からそれるんで期間が足りません」※注１
「ソレできる？」
「標準機能からそれるんで・・・」
「じゃあコレは？」
「標準ｋ（ｒｙ」
納期短いからオシャレさ、便利さよりも有りもので間に合わせる、といった具合。
「客のために納期厳守」を合言葉に、心を鬼にして要望を潰して潰して潰しまくる。ただでさえ残業できないワケだしね。
もし、俺が時短じゃなかったとしたらどうだろう？
「残業すれば間に合うなぁ（コストは別として）、要望だしやってあげないとなぁ」になっていたかもしれない。
そういうプロジェクトって大体は火を噴くんだよねぇ。QCDで言えばDが最優先なのに、そこを間違えたり、途中で方針がブレたりすると、結局Dが満たせなくなっちゃう。
時短の人間に短納期のプロジェクトやらせるなよ、って思ったりもしたけど、時短だからこそシビアにスケジュール管理しようとするメリットはあるんだなぁ。時短が仕事に活きたな、と初めて思った。俺のスケジュール管理意識は一段高いレベルに到達したのだ！
問題は、ほかのメンバーがそこまで時間にシビアじゃないことなんだよなぁ。事あるごとに設計変えたり、複雑な仕組みを作ろうとしたりする問題児がいて頭痛のタネ。チームメンバーで意識を共有するのもリーダーの仕事なんだけどな。言っても聞きゃあしない。まぁその話は機会があれば次回にでも。
あでゅー
※注１：部品を組み合わせて使う開発フレームワークを採用していて、部品をそのまま使えば一瞬でシステムが作れるが、ちょっとでも違うことをしようとするとむっちゃ時間がかかるのだ。
