実母が乳ガンの手術を受けるってんで、急遽帰省中。
去年は手前の鎖骨折ったり顔縫ったりと忙しかったけれど、今年は実父が脳梗塞でブッ倒れたり実母がガンになったりと、相変わらず忙しいこった。( A )
これで養父母までブッ倒れたらどーすっか、と鬱になる。
ま、そんときゃ気が滅入ることばかりの今の仕事を辞めて、転職するいい機会かもｗ
--------
で、仕事の話。
また大きな波がやってくる。まぁ、派生ばっかりとはいえ、ソフトはそれぞれカスタマイズしまくりになるんだろな。
昨日一日かけてソフト課全体の４ヶ月負荷予報を試算してみたら、総員23人の課で、ずーっと２～７人ばかり足りないｗ
先日首相を辞めた大仏様(謎)等を呼び戻しにかかったとしても、まだ２～３人足りない。
帰国することになったBさんの穴のデカい。
で、例によって例の如くテーマリーダにコッテリ絞られる。
モノの言い方に大概問題ある人だが、仕事に関して彼の言うことは大概正論だ。ここみたいなスケジュールもロクに引けない環境で開発を続けるための引き出しも、おそらく彼が一番たくさん持っている。
幸いにも、彼はオイラを一応は見切らずに、まだ鍛えようとしてくれているらしい。
茶碗についたご飯粒一つ残さず平らげるのがオイラの流儀。自ら脚を使って精力的に学んでまわる努力はあんまりしない代わりに、その場で学べることは全て学び尽くす所存。
- 「仕様ありき」の考え方はそろそろヤメロ
「客先から仕様が出てこないから規模もわからない」
「規模がわからないからスケジュールも引けない」
→完璧な仕様なんて、今まで一度だって客から出てきたことなんて無いだろう？中途半端な仕様が有るのと、仕様がまるで無いのの間に、何の違いがあるのかサッパリわからない。
一件暴論だが、「納期は絶対変わらない」のが宿命の業界では、こういう考え方もありなのかも。
同じ機能を持つモノの機種展開をやってるわけだから、客先仕様の有無にかかわらず、基本機能が動作することが前提の筈。客から言われなくても、各社で仕様が異なる通信機能なんかは変わるの分かってる。
そういう方面の仕様のdraft版でもいいからもらえませんか？と客先と交渉して、それでも何も出てこないなら、その客先の旧機種の仕様に載せ替えます、と宣言して、手前で勝手に仕様作って開発に着手しちゃう。
通信が機能しなけりゃ、モノとして動かない。納期が来て、「何も出来てません」じゃ、客先の開発は停止する。客先がフルに満足する仕様ではなくても、とにかくモノとして動いてりゃ、不満を聞いて変更する、という次のステージに進める。
客先から仕様が出てこないなら、自分で仕様を作って、それをもとに規模を見積もりスケジュールを引いて、開発に着手しろ。後で仕様が出てきて、変更が必要なことが分かったら、リスク見積内に納まる範囲内ならやりくりすりゃいいし、許容範囲を超える変更になるなら、超える分を仕様側で抑えるなり、相手に開発の一端を負ってもらうなりすればいい。
- スケジュールが引けなくても、想定される必要人員の半分、最低でも一人は主力級の作業者を確保しとけ
山ほど降ってくる仕事を少ないリソースでやりくりするウチみたいな部門では、いつもテーマ間で作業人員の取り合いが発生する。
全体的な観点からすれば、手の空いた人員を流動的に動かすのが効率的なように見える。しかし、「中身はまだワカランが、ココにこんな仕事の納期がある」ことが決定事項なら、その納期に間に合う期間、最低一人は人員を押さえてないと取り返しがつかないことになる。
- 見積もった仕事量でそのまま人員を配置するな
やっと仕様が出てきたとしよう。聞いた仕様で規模を見積もり、規模に見合った人員を配置すると…客先と整合した受注時の人員計画を大幅に超えてる、なんてことがよくある。
そもそも、聞いた仕様が受注時の計画時の規模よりデカいことが分かった時点で、仕様を減らす調整をやるのが当たり前。
ウチのソフトのメンバは、受注時の計画を殆ど知らない。だから聞いた仕様を真に受けてマンニングしちゃう。結果、予算は溢れるわ期初の人員計画はすぐ崩壊するわ。
ソフトリーダは、まずテーマリーダが見積もった人員計画のソフト要員分を知っておけ。その上で仕様を聞き、期初計画をはみ出すようなら、客先と整合してる投入人員数を盾に、計画内に納まるよう、ウチが開発する分の規模を調整しろ。
