規定時間外労働で見える本音
土曜日に久しぶりの休日出勤してきました。
極力土日は出ないようにしてるんで。
うちのプロジェクトって開発量は多いけど、
極力土日は出ないなんて目論見がまかり通ってるぐらいだから、
意外と生ぬるい環境なんでしょうね。
何だかんだblogで偉そうなこと言ってても
自分なんかまだまだ甘ちゃんSEなんだなーと
つくづく思い知らされます。
休日出てちょっと思ったことがあったんですけど、
規定時間外の労働ってメンバーの本音でますよねー。
他人の悪口言ってたり、
会話が仕事のことじゃなくて趣味の話に走ったり。
普段合わないなーって思ってる人とは
いつもより会話が少なかったり。。。
うちは休日出勤のときは私服なんですが、
スーツと時間という規則から解放されて
裸になった人間の姿が見えますね。休みの日の労働ってのは。
今日の教訓
「あの人自分のことどう思ってるんだろーなんて悩んでる人は
その相手と残業や休日出勤してみるとよい」
極力土日は出ないようにしてるんで。
うちのプロジェクトって開発量は多いけど、
極力土日は出ないなんて目論見がまかり通ってるぐらいだから、
意外と生ぬるい環境なんでしょうね。
何だかんだblogで偉そうなこと言ってても
自分なんかまだまだ甘ちゃんSEなんだなーと
つくづく思い知らされます。
休日出てちょっと思ったことがあったんですけど、
規定時間外の労働ってメンバーの本音でますよねー。
他人の悪口言ってたり、
会話が仕事のことじゃなくて趣味の話に走ったり。
普段合わないなーって思ってる人とは
いつもより会話が少なかったり。。。
うちは休日出勤のときは私服なんですが、
スーツと時間という規則から解放されて
裸になった人間の姿が見えますね。休みの日の労働ってのは。
今日の教訓
「あの人自分のことどう思ってるんだろーなんて悩んでる人は
その相手と残業や休日出勤してみるとよい」
試験工程について考える２ － テストはサディストにやらせるべき
■ どんな人が鬱状態になるのか
鬱になりやすいのは、真面目な人が多いとよく言われますが、
本当に当たっています。
これに付け加えるならば、相手の気持ちを考えて行動できる人。
こういう人は一般的には良い人とされますが、
試験工程でとくに鬱状態に陥りやすいのではないでしょうか。
そのような人はテストで担当している部分を開発している他メンバーへの
指摘や質問をためらう傾向があるようです。
全てを自分一人で抱え込んでしまい、がんばりすぎる。
そして最終的には精神的に疲弊してしまうのです。
そのような人は本人が鬱状態に陥るだけでなく、ソフトウェアの品質に関しても
悪い影響を与えかねません。
■ テストはサディストにやらせるべき
そこで考えました。
テストはサディスティックな性格の人物を中心にやらせるべき、と。
唐突な結論ですが、そう考える理由はこうです。
テスターというのはバグ探し（他人を責められる理由を見つけること）に
快感を感じる人物でないとまともに務まらないでしょう。
『闘うプログラマー』
『ピープル・ウェア』
にも書かれていますが、テスターというのは開発者から敬遠される傾向にあります。
「人が作ったプログラムにケチつけやがって」とか
「テスターのくせに・・・」とか
「忙しいのにうるさいやつだなぁ」とか。。。
そういった態度に対して、
「敬遠されるのは自分にも原因があるのだ。
相手も忙しいのにいきなり悪い知らせをしてしまうなんて。。。
相手の都合も考えて行動しなくてはいけない。」
などと反省してしまう「良い」人ではキツイ仕事でしょうね。
嫌われても全部相手のせいにして平然としていられる気丈（異常？）な人物の方が
テストには向いてるように思えます。
プライベートでは関わりたくありませんが。
鬱になりやすいのは、真面目な人が多いとよく言われますが、
本当に当たっています。
これに付け加えるならば、相手の気持ちを考えて行動できる人。
こういう人は一般的には良い人とされますが、
試験工程でとくに鬱状態に陥りやすいのではないでしょうか。
そのような人はテストで担当している部分を開発している他メンバーへの
指摘や質問をためらう傾向があるようです。
全てを自分一人で抱え込んでしまい、がんばりすぎる。
そして最終的には精神的に疲弊してしまうのです。
そのような人は本人が鬱状態に陥るだけでなく、ソフトウェアの品質に関しても
悪い影響を与えかねません。
■ テストはサディストにやらせるべき
そこで考えました。
テストはサディスティックな性格の人物を中心にやらせるべき、と。
唐突な結論ですが、そう考える理由はこうです。
テスターというのはバグ探し（他人を責められる理由を見つけること）に
快感を感じる人物でないとまともに務まらないでしょう。
『闘うプログラマー』
『ピープル・ウェア』
にも書かれていますが、テスターというのは開発者から敬遠される傾向にあります。
「人が作ったプログラムにケチつけやがって」とか
「テスターのくせに・・・」とか
「忙しいのにうるさいやつだなぁ」とか。。。
そういった態度に対して、
「敬遠されるのは自分にも原因があるのだ。
相手も忙しいのにいきなり悪い知らせをしてしまうなんて。。。
相手の都合も考えて行動しなくてはいけない。」
などと反省してしまう「良い」人ではキツイ仕事でしょうね。
嫌われても全部相手のせいにして平然としていられる気丈（異常？）な人物の方が
テストには向いてるように思えます。
プライベートでは関わりたくありませんが。
試験工程について考える１ － テストと鬱
■ テストと鬱
SEというのは他の職業に比べて鬱との関わりが深いのですが、
試験工程になるとそれが顕著に表れます。
僕が関わっている通信系ソフトウェアのテストは過酷です。
通信系ソフトってのは交換機や基地局といったものに乗っけるので
小さなバグ一つで何十万人ものユーザーに影響が出ます。
よって、テストの項目数も天文学的な数値になります。
単体テストでやった項目をまた結合テストでやったり、
システム統合テストでは全く同じテスト項目を環境を変えて
最低３回は繰り返します。
項目の質や観点よりも「いっぱいやったもん勝ち」
なところがあるのは否めません。
そして何よりテストというのは設計やコーディングに比べると
創造的な作業ではありません。
機械的な作業の連続が身も心も疲れさせていき、
しまいには鬱状態に陥るメンバーが出てくるのです。
＞「試験工程について考える２」に続く
SEというのは他の職業に比べて鬱との関わりが深いのですが、
試験工程になるとそれが顕著に表れます。
僕が関わっている通信系ソフトウェアのテストは過酷です。
通信系ソフトってのは交換機や基地局といったものに乗っけるので
小さなバグ一つで何十万人ものユーザーに影響が出ます。
よって、テストの項目数も天文学的な数値になります。
単体テストでやった項目をまた結合テストでやったり、
システム統合テストでは全く同じテスト項目を環境を変えて
最低３回は繰り返します。
項目の質や観点よりも「いっぱいやったもん勝ち」
なところがあるのは否めません。
そして何よりテストというのは設計やコーディングに比べると
創造的な作業ではありません。
機械的な作業の連続が身も心も疲れさせていき、
しまいには鬱状態に陥るメンバーが出てくるのです。
＞「試験工程について考える２」に続く
進捗阻害要因ベスト５
どうも仕事というのは思うように進みません。
いまだかつて予定通りに仕事が進んだことがない奴です。
自分の力量不足でしょうが・・・
何が進捗妨げているのか？
自分が本来抱えている仕事以外に何をしているか記録していった結果、
次のような結果になりました。
ベスト１．新規参入者へのサポート
最近うちのプロジェクトにも新しい顔が増えてきて、まだ１年目にも関わらず
２人の新規参入者のサポート担当になりました。
仕方の無いことですが、このサポートってのはあらゆる意味で稼動を喰う。
よほど自己中心的な人物で無い限り、相手のことが気掛かりになって
仕事が以前よりも進まなくなるのではないでしょうか。
ベスト２．打ち合わせ
一気にメンバー全員の進捗をその場で聞くという形式をとっているのでとにかく長い。
そして打ち合わせの時にどこどこの進みが悪いという問題が分かるのです。
「問題の対策」から進捗が始められればいいのですが。。。
ベスト３．突発的なトラブル対応
全く予期できないが予期すべき？トラブルというのがこの仕事にはあります。
バグの発生、試験用マシンの不具合、顧客からの調査依頼、
このトラブル対応ってやつはほとんどが緊急を要するので
他の仕事は一切手につかなくなり、ようやく終えた頃には何をやっていたのか
忘れていたりします。。。
またトラブルの発生率ってのは１．と相関関係にあるような気がします。
ベスト４．無駄話
これが意外と多いです。無駄話なんかするなと言われても仕方ないのです。
話の中身は本当に無駄なことばかりですが、話すこと自体が重要なのです。
グループ意識の強いプロジェクトほど、話せない奴は暗い、変人などの
レッテルを貼られてチームののけ者にされますから。
ベスト５．連絡事項の確認
グループウェアを導入しているせいか、ついついこまめに確認してしまいます。
グループウェアってのは書いたもん勝ちです。
「グループウェアに書いたでしょう！？」と言われないための対策です。
設計書を書く、プログラムを書く、試験をする
という成果が見える可視的な仕事だけが「仕事」でないことをしみじみと実感しました。
今日の教訓
「目に見える作業量だけでは予測は立てられない」
いまだかつて予定通りに仕事が進んだことがない奴です。
自分の力量不足でしょうが・・・
何が進捗妨げているのか？
自分が本来抱えている仕事以外に何をしているか記録していった結果、
次のような結果になりました。
ベスト１．新規参入者へのサポート
最近うちのプロジェクトにも新しい顔が増えてきて、まだ１年目にも関わらず
２人の新規参入者のサポート担当になりました。
仕方の無いことですが、このサポートってのはあらゆる意味で稼動を喰う。
よほど自己中心的な人物で無い限り、相手のことが気掛かりになって
仕事が以前よりも進まなくなるのではないでしょうか。
ベスト２．打ち合わせ
一気にメンバー全員の進捗をその場で聞くという形式をとっているのでとにかく長い。
そして打ち合わせの時にどこどこの進みが悪いという問題が分かるのです。
「問題の対策」から進捗が始められればいいのですが。。。
ベスト３．突発的なトラブル対応
全く予期できないが予期すべき？トラブルというのがこの仕事にはあります。
バグの発生、試験用マシンの不具合、顧客からの調査依頼、
このトラブル対応ってやつはほとんどが緊急を要するので
他の仕事は一切手につかなくなり、ようやく終えた頃には何をやっていたのか
忘れていたりします。。。
またトラブルの発生率ってのは１．と相関関係にあるような気がします。
ベスト４．無駄話
これが意外と多いです。無駄話なんかするなと言われても仕方ないのです。
話の中身は本当に無駄なことばかりですが、話すこと自体が重要なのです。
グループ意識の強いプロジェクトほど、話せない奴は暗い、変人などの
レッテルを貼られてチームののけ者にされますから。
ベスト５．連絡事項の確認
グループウェアを導入しているせいか、ついついこまめに確認してしまいます。
グループウェアってのは書いたもん勝ちです。
「グループウェアに書いたでしょう！？」と言われないための対策です。
設計書を書く、プログラムを書く、試験をする
という成果が見える可視的な仕事だけが「仕事」でないことをしみじみと実感しました。
今日の教訓
「目に見える作業量だけでは予測は立てられない」
イラストで見る管理者の４タイプ
プロジェクトの成否は各メンバーの能力でなく管理者の手腕にこそ掛かっている、
ってよく言われるけどホントだなーって思った理由は、
別の機会に書くこととしまして・・・
うちの職場の管理的立場にある人ってだいたいこの４タイプに分類されます。
１．ピエロ型
部下の前でピエロを演じることができる管理者。
場の雰囲気を和ませることが得意で人情味あふれる性格。
しかし、真面目な性格の人間やネクラな人まで無理やり笑わせようとして
敬遠されることも。。。
２．検察官型
このタイプの好物は、責任問題やトラブル。
あんたホントはバグが発生してほしいんじゃないの？
ってぐらい何かある度に食いついてくる。
基本的にこのタイプは頭脳明快で理論派。
しかし理論の中身は単純。要するに「私が正しい。お前が悪い！」それだけ。
３．うつぼ型
あまり目立たず大人しい。普段はうつぼのように影でひっそりしているが、
意外と要所要所で表に出てきて、いいところを持っていく。
まあ、第３者から見たらただの平社員にしか見えませんが。
４．ただのガキ
感情のままに動き、部下には「やれ」というがフォローは無し。
できないと「なんでできないんだ！」と怒り心頭
全てが自分の思い通りに進まないとダダをこねる。
その滑稽な様は、欲しいおもちゃを買ってもらえなくて
泣きじゃくる子供と同列に見ても差し支えないだろう。
こんな感じです。
まあ、４のタイプの管理者が管理するところは色々な意味で
悲劇的な状況にあることは言うまでも無いのですが、
個人的に１と３の管理者が良い管理できてるんじゃないかなーと思います。
（そう思う理由はおいおい・・・）
２のタイプは管理者というか独裁者にしか見えないのですが。。。
ってよく言われるけどホントだなーって思った理由は、
別の機会に書くこととしまして・・・
うちの職場の管理的立場にある人ってだいたいこの４タイプに分類されます。
１．ピエロ型
部下の前でピエロを演じることができる管理者。
場の雰囲気を和ませることが得意で人情味あふれる性格。
しかし、真面目な性格の人間やネクラな人まで無理やり笑わせようとして
敬遠されることも。。。
２．検察官型
このタイプの好物は、責任問題やトラブル。
あんたホントはバグが発生してほしいんじゃないの？
ってぐらい何かある度に食いついてくる。
基本的にこのタイプは頭脳明快で理論派。
しかし理論の中身は単純。要するに「私が正しい。お前が悪い！」それだけ。
３．うつぼ型
あまり目立たず大人しい。普段はうつぼのように影でひっそりしているが、
意外と要所要所で表に出てきて、いいところを持っていく。
まあ、第３者から見たらただの平社員にしか見えませんが。
４．ただのガキ
感情のままに動き、部下には「やれ」というがフォローは無し。
できないと「なんでできないんだ！」と怒り心頭
全てが自分の思い通りに進まないとダダをこねる。
その滑稽な様は、欲しいおもちゃを買ってもらえなくて
泣きじゃくる子供と同列に見ても差し支えないだろう。
こんな感じです。
まあ、４のタイプの管理者が管理するところは色々な意味で
悲劇的な状況にあることは言うまでも無いのですが、
個人的に１と３の管理者が良い管理できてるんじゃないかなーと思います。
（そう思う理由はおいおい・・・）
２のタイプは管理者というか独裁者にしか見えないのですが。。。
SEの職場環境がなかなか改善されない理由
土曜日に会社の労働組合の大会に行ってきました。
組合加入者の20分の１ほどの参加者を前に
組合役員が延々と形式的に原稿を読み上げるその様は
まるで生きた化石のよう。
組合はあまり正常に機能していないようです。
IT業界の職場環境に対する不満ってよく聞きますが、
実際それで行動を起こしてる人ってどれくらいいるんでしょうか。
労働組合自体がないっていう会社もあるでしょうし、
会社への依存度が低く、技術的な事柄だけに関心が向きがちな
SEっていう仕事は職業柄、組合とかそういうものには
興味がないのかもしれません。
それに派遣やら常駐やらやってる会社の社員って連帯できそうもないですし。
何より毎日残業で仕事疲れな状態では、
職場環境の改善なんかに努める気力もないですよね。
今日の教訓
「↓IT業界の現状」
組合加入者の20分の１ほどの参加者を前に
組合役員が延々と形式的に原稿を読み上げるその様は
まるで生きた化石のよう。
組合はあまり正常に機能していないようです。
IT業界の職場環境に対する不満ってよく聞きますが、
実際それで行動を起こしてる人ってどれくらいいるんでしょうか。
労働組合自体がないっていう会社もあるでしょうし、
会社への依存度が低く、技術的な事柄だけに関心が向きがちな
SEっていう仕事は職業柄、組合とかそういうものには
興味がないのかもしれません。
それに派遣やら常駐やらやってる会社の社員って連帯できそうもないですし。
何より毎日残業で仕事疲れな状態では、
職場環境の改善なんかに努める気力もないですよね。
今日の教訓
「↓IT業界の現状」
金はプログラマーの精神を蝕む
ソフトウェア開発の現場に出て、実際にプログラムを読んだとき驚いたこと。
・コメントが異常に少ない。ひどいと関数概要しか書いていない始末。
・関数が長い。長すぎる。読み終わったときの感想は、
「で？結局この関数は何がやりたいの？」
・著しく共通化されていない。全く同じ記述をコード中に何度も見つける。
はじめて見たときは「これを書いた奴はバカか･･･？」と思いましたが、
先輩の一言でようやく商用のプログラムが醜い訳が分かってきました。
「ライン数（＝金）稼げるからねー。」
今日の教訓。
「金はプログラマーの精神を蝕む」
・コメントが異常に少ない。ひどいと関数概要しか書いていない始末。
・関数が長い。長すぎる。読み終わったときの感想は、
「で？結局この関数は何がやりたいの？」
・著しく共通化されていない。全く同じ記述をコード中に何度も見つける。
はじめて見たときは「これを書いた奴はバカか･･･？」と思いましたが、
先輩の一言でようやく商用のプログラムが醜い訳が分かってきました。
「ライン数（＝金）稼げるからねー。」
今日の教訓。
「金はプログラマーの精神を蝕む」
人月の神話は本当に神話だった
うちの事業部で去年の暮れから新規プロジェクトが始まりました。
僕もその時の上司にプロジェクトに来ないかと誘われたのですが、
いつの間には話は流れ...
そのプロジェクト、いま惨然たる状況です。
大幅な遅延とバグの続出。幾度の手戻りの発生。
開発しているオフィスの明かりが消えたことが今年に入ってから一度もないらしい。
「もう終わりだ。。。」
こんな声も聞かれます。
その新プロジェクトには既存のプロジェクトから
エース級のSEがほとんど引き抜かれていきました。
そして今僕が所属している別プロジェクトの2倍の人員も投入されました。
にも関わらず、なぜこんな状況になったのか。
ある日、そのプロジェクト開始当初から参加した同期から
こんなことを聞きました。
「人が増えても、新規参入者で知らない人ばかりだから
こんな状況だと足手まといになるだけ」
あー、これか。。。
いやー、僕も一応新人なんで耳が痛いのですが、
これが遅延プロジェクトの実情ってやつなのですね。
『人月の神話』の著者フレデリック・ブルックス氏は、
人が増えるとその分教育とコミュニケーションの必要性が
発生すると言っていますが、そのプロジェクトでは、
必要性は発生しても実際の教育やコミュニケーションはあまり発生していないそうです。
そりゃ新しいメンツばかりだから全体的にまとまりもないし、
深夜になってもオフィスの明かりが消えない状況じゃ、
みんなピリピリして人に教える心の余裕なんて持てないでしょうからね。
新規プロジェクトの永遠のテーマですね。。。
今日の教訓
「教育とコミュニケーションの必要性は発生しても、
実際に教育とコミュニケーションは発生はしない。」
僕もその時の上司にプロジェクトに来ないかと誘われたのですが、
いつの間には話は流れ...
そのプロジェクト、いま惨然たる状況です。
大幅な遅延とバグの続出。幾度の手戻りの発生。
開発しているオフィスの明かりが消えたことが今年に入ってから一度もないらしい。
「もう終わりだ。。。」
こんな声も聞かれます。
その新プロジェクトには既存のプロジェクトから
エース級のSEがほとんど引き抜かれていきました。
そして今僕が所属している別プロジェクトの2倍の人員も投入されました。
にも関わらず、なぜこんな状況になったのか。
ある日、そのプロジェクト開始当初から参加した同期から
こんなことを聞きました。
「人が増えても、新規参入者で知らない人ばかりだから
こんな状況だと足手まといになるだけ」
あー、これか。。。
いやー、僕も一応新人なんで耳が痛いのですが、
これが遅延プロジェクトの実情ってやつなのですね。
『人月の神話』の著者フレデリック・ブルックス氏は、
人が増えるとその分教育とコミュニケーションの必要性が
発生すると言っていますが、そのプロジェクトでは、
必要性は発生しても実際の教育やコミュニケーションはあまり発生していないそうです。
そりゃ新しいメンツばかりだから全体的にまとまりもないし、
深夜になってもオフィスの明かりが消えない状況じゃ、
みんなピリピリして人に教える心の余裕なんて持てないでしょうからね。
新規プロジェクトの永遠のテーマですね。。。
今日の教訓
「教育とコミュニケーションの必要性は発生しても、
実際に教育とコミュニケーションは発生はしない。」