3分間プログラマ 〜その3〜。

http://d.hatena.ne.jp/zenkaifc/20081013:Title=3分間プログラマ　〜その1〜。
http://d.hatena.ne.jp/zenkaifc/20081014:Title=3分間プログラマ　〜その2〜。
の続き

人的リソースの管理。

いやまぁ、誰がいつからいつまで何の作業をするのかっていう割り振りのコトだけどね。
ウチみたいに小さい会社って、一人一人のこなす作業の幅が広い。ほかの小さな会社も似たり寄ったりだと思う。
ちょうどいい量の仕事が継続的に入ってくればいいんだろうけれども、なかなかそういうわけにはいかない。
オイラ、会社の中では下の方の立場だから、あんまり管理っていう視点で物事を考えたりしないんだけど、何年か職場を見て思ったことがいくつか。

ヒマな人が必要。

「遊んでいるなら仕事取ってこい！！」
というのはドラマでよく見る（笑）。
でも、ヒマな人は必要。それも比較的高い技術を持っているような人。
簡単に言えば、火消し役。高い技術の人が炎上しそうなプロジェクトに入って、ササッと作業をする。それ以外の時は、ネットでもやっててください。実はそれでも十分ペイできます。なんせその人がいれば炎上しないんだから。

はじめちょろちょろ中ぱっぱ、赤子泣いても蓋取るな

• はじめちょろちょろ。

初めは少人数でいい。要件定義だとか基本設計から製造部隊をドカドカ引き連れたって、やることはない。

• 中ぱっぱ

その代わり、設計ができたら一気に製造部隊を投入すること。

• 赤子泣いても蓋取るな

何があってもテスト人員は減らさないこと。蒸らさないご飯は食えたモノではない。最後の仕上げが一番大切。

新人に研修担当は無理。

自分がそうだったんだけれども、プログラムを始めて1ヶ月でさらに新人のプログラミング研修とかって、それはちょっと無理なんじゃないかと。いや、しっかりとした教材があればやってやれないことはないけれども、それにしたってクオリティは低いし、なにより頼れない。
言い方は悪いけれども、相手を屈服させるほどの知識量に説得力がなければしっかりした教育なんて期待できない。
こういうところで小さい会社は離される。人材の少ない、教育担当の候補が少ない会社ほど後の製品クオリティだとか定着率の高さに悪影響が出ると思う。なんせ尊敬される先輩社員がいませんから。

人月計算。

要件が固まってないのに、なんで総合的な見積金額を出せるの？バカなの？死ぬの？（部下が）
自分の会社の悪口なんて言いたくないけれど、正直、見積もりはちょっと適当な感がある。
何でその金額なのかを突っ込むと、すぐに黙ってしまう。
ハードウェアの見積もりがそう。なんでこのシステムにこのハードウェアが必要で、なんでこのスペックなのか。全く回答が出ない。
そして初回の概算見積もりで値引きってなんだよ・・・。
ソフトウェアもそう。
結局、客の納期に適当な人月をあてているだけなんじゃね？もしかして。

とは言っても、難しいよね、見積もり。自分のところだけ儲かったってしょうがないんだしさ。人員によって開発の速度なんていくらでも変わっちゃうし。結局、お互いにちょうどいいところを探っていくしかないんだよなぁ。

　
･･････続く（たぶん）