元請から下請に変わって、仕事で理不尽な目に遭うことがなくなった話 - 極北データモデリング
人材募集広告の取材の人が会社に来て、私も転職者代表でインタビューを受けた。 前職と比べて何がよいか聞かれたので、こっちではお客さんに賞賛されたり社内で労われたりすることがあって、そんなこと期待したこともなかったので驚いた話をした。 これは何でなのかというと、以前よりお客さんが儲かるシステムを扱っているからだ。 あたりまえだと思われそうな話だが書いてしまう。 年間1億のコスト削減になるシステムなら、10画面ぐらいのWebアプリに数千万円の予算が付いて、納期もまっとうなものにできる。 逆に、できてもお客さんが大して儲からないシステムを企画すると、予算は付かないし納期も無理なものになる。 先方の担当者の構えも違ってくる。稼動しても社内で評価されないシステムなら、担当者に指名されてもやる気が出ないだろう。 また予算がないと、担当者が我々にタダで追加仕事をさせたくなるので、どうしても不幸なネゴシエー
どんな作業のマニュアルでも３時間あれば作れる - 極北データモデリング
例えばお客さんから預かってるサーバの監視とか、いつもの道具立て(ウチなら JSP + Struts + Spring + Spring JDBCとか)でWebアプリケーションを構築するとか、そういう「おおよそ決まった手順があるけど、細部は毎回異なる」作業については、マニュアルを用意して担当できる人を増やさなくてはならないのだが、ウチはそういうものの整備が甘い。これは「マニュアルとは何か」の考え方が統一されてないから。 個人的には以下のようなマニュアル観は間違っていると思う。 不完全なマニュアルを配られても困る マニュアルに書いてある通りにやって問題が起きるぐらいなら、そんなの無いほうがいいんじゃないの 書いてある通りにやって問題が起きても作業者の責任ではない。嘘のマニュアルを書いたやつが悪い マニュアルとは「書いてある通りに作業するためのもの」なのだから、例外事項がたくさんある作業のマニュ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
