線引いて終りじゃないぞ。

Yasunori Taniike @ytaniike

製造の現場では禁じ手 ＞ RT @jyobi: 「100メートルを９秒で走れる人は、10000メートルを900秒で走れる」なんて言ったらバカだと思われますが、ものつくりの場合、似たような感覚でスケジュールを切ってくるのが平気であるから不思議。

Yasunori Taniike @ytaniike

製造の現場では、製造機械の連続稼動可能時間とかメンテナンス間隔とかメンテナンス時間加味して計画するのがあたり前。

Yasunori Taniike @ytaniike

ソフトウェア開発の場合は、担当者の体調管理を加味すべきはずなのにしていない管理者がほとんど。 人が長続きしないと嘆く前に、この辺ちゃんと考えろと言いたい。

Yasunori Taniike @ytaniike

今だにガントチャート引けば管理できてると思ってんだろうけど。製造管理の知識もロクに持ってないやつがまともなスケジュールなんて引ける訳がない。

Yasunori Taniike @ytaniike

プログラム毎に納期と必要な工数を見積って、担当者割り振っておしまい。 そんな訳ないだろうが！！！

Yasunori Taniike @ytaniike

担当者毎に負荷の山を積んだら、その山が特定の担当者だけ高過ぎないかという評価をして、高過ぎたら負荷を分散するなり、スケジュール引きなおすのが基本中の基本。 これを製造管理の用語では「山崩し」という。

Yasunori Taniike @ytaniike

それと良くあるのが「今このプログラムどこまで進んでる？」「動いてるんですがバグ取りきれてません。」「今の進捗数字で言うとどのくらいかな？パーセントで。」「だいたい 70%」くらいです。 などという会話。

Yasunori Taniike @ytaniike

でこの 70％ を使って進捗報告資料を作ったりしてる。 バカか？

Yasunori Taniike @ytaniike

プロジェクトに開発要員入れる前に、例えば「コーディング着手で 10%」、「コンパイルできて、テスト着手で 30％」、「正常系のテスト完了で60%」、「異常系含めてテスト完了で 100％」などと指標を管理側が用意しとかないと進捗報告なんてできるわけが無い！！！

MURAOKA Taro @kaoriya

@ytaniike プログラムだと負荷分散が難しそうですよねぇ…なんていうか個人の資質に頼ってしまう側面がある。

Yasunori Taniike @ytaniike

@kaoriya 個人の資質に頼るような難しいところは自分か信頼の置ける直属の部下にさせるのが鉄則でしょうね。

MURAOKA Taro @kaoriya

@ytaniike でのその直属の部下の山が積み上がって崩せない、っていうオチが…

Yasunori Taniike @ytaniike

@kaoriya ウッフキャハハなチーム作りなんてことやってるとそうなるでしょうね。 人が面倒みれるのって、5人が限度ですよ。 メンバーが増えるんならそれで階層構造にせざるを得ないです。組織運営のほうのスキルも必要なのです。

Yasunori Taniike @ytaniike

そして、テスト仕様書はレビューしとくのが当たり前なんだが、やってるか？

Yasunori Taniike @ytaniike

汎用機で開発してた頃（15年前後昔の話）でさえ、これくらいやってた。今は進捗を聞いてまわらなくても、git 等を使ってテストも自動化しておけば、楽ができるようになってるはず。

Yasunori Taniike @ytaniike

ちらと聞いたり、目にする話が悲惨すぎる。私くらいの年頃前後の勤め人（部長や課長やマネージャとかだ）に言いたい。 お前らもっと自分の仕事について、勉強しやがれ！！！

Yasunori Taniike @ytaniike

ちなみに私が管理した最大のチームは SE 25人程 + プログラマ 50人程の規模だった。 某都市銀行の第三次オンライン対応の案件だった。 その上某大手 SIer が炎上させたサブシステムを全部やり直し、3ヶ月遅れてたスケジュールを取り戻した。