一日の平均残業時間が2〜3時間です。夕飯には間に合わないかもしれませんが,趣味の時間は確保できるでしょう。一日の平均残業時間が3〜4時間です。帰宅は22時を越すでしょう。筆者がこんな時間に帰宅すると余暇の長さに呆然としてしまいます。一日の平均残業時間が4〜5時間です。その日のうちに帰宅するのが難しくなってきます。自分の境遇や会社に対し怒りを覚え始めます。転職や人生の意味について考えてみたりもします。一日の平均残業時間が5時間程度で,休日出勤も追加されてます。納期直前だと徹夜もします。納期直前でこのぐらいなら許容範囲としておかないと,同業他社に転職してもきっと同じ目にあいます。一日の平均残業時間が6時間程度で,帰宅は午前様が基本です。週休2日の会社でも休日は1日でしょう。運が悪ければ土日とも出勤です。たまの休日はひたすら眠ります。遊びに行って体力を消耗するなんてとんでもない。思考能力が麻痺してきて,今の状況を抜け出すことしか考えられなくなってきます。会社に泊り込んでます。平日だろうと休日だろうと早朝だろうと深夜だろうと仕事をしています。仕事をしていない時間は食事をしているか,寝ているかどちらかです。ねむくてねむくてしょうがないです。思考の大半は睡魔との戦いです。睡魔以外にも目がかすむ,手足がしびれる,耳鳴りがするといった身体の不調を訴える人も多く,寿命を縮めてるというヤバイ実感があります。感情も麻痺し,会社や状況に対して怒る気力すら沸いてきません。人というよりはもはやロボットです。どこからをデスマーチとして認定するか友人や後輩と議論した結果,100時間超の残業が数ヶ月続くとデスマーチではないかという結論になりました。デスマーチには近寄りたくないのですが,避けられるものではないのが難しいところです。上司を経由してデスマーチから迫ってくるのが困りものです。だれかどうにかしてください。日本一短い上司からのメール筆者があるデスマーチに放り込まれたときの出来事です。この案件は他社と仕様の扱いで揉めており,部課長を含めてメールが飛び交っていました。筆者「弊社は2ヶ月以上前に仕様書を提出している。御社の指摘は仕様書に記載済みの事項である。他社「御社では仕様と言うが,御社の仕様は弊社の要求事項を満たしていない。筆者「そのような指摘は仕様書のレビュー時にすべき事項である。御社として問題ないと判断したから合議したのではないか。他社「そうは言っても御社の...」この議論に負けると自分たちのチームが悲惨な目にあうことは確定です。プログラムの根幹に関わる仕様変更なのでソースの修正量がハンパじゃありません。ソースを修正すると今までのテスト成果もパアです。テストを一からやり直す羽目になります。今でも休日も会社に来てるし,平日の帰宅は午前様なのです。これ以上の作業が増えると徹夜以外に選択肢がありません。自分だけならまだしも同僚たちも同じ目にあいます。負けるわけにはいきません。他社も同様の状況らしく担当者は相当熱くなってました。こんな状態のある日,幹部からメールが届きました。事態を打開する素晴らしいメールに違いないとワクワクしながらメールを開きました。この素晴らしいメールの本文を全文引用します。XXXの扱いについてよろしく。肝心な部分を省略しているわけではありません。全文を引用してもたった5文字です。誰に何を指示してるんでしょうか。幹部もボケたのでしょうか。徹夜の後でもあり相当頭にきました。幹部に文句を言おうかと考えたぐらいです。すると,部長から信じられないようなメールが返ってきました。Re:XXXの扱いについて指示いただきありがとうございます。次のように対処します。XXXの扱い弊社の見解は仕様です。プロジェクト完遂のため要望事項にあわせて仕様を変更します。対策期日ソースの修正が必要となるため提供を○月に延期します。他社でのテストが滞らないようにテスト用のモジュールは別途提供します。日程は別途相談します。要員テスト工程以降に人員をX名追加します。...メールの内容自体はこちらが譲歩した場合の案であり違和感はありません。先ほどのメールのどこに指示があったのでしょう。筆者には全然分かりませんでした。あまりに不思議だったのでタバコ部屋に部長が行ったときに直接聞いてみました。部長「今の状態だとお互いに不幸だよね。こっちが泥をかぶって相手に貸しを作るわけ。今回の相手とは今後もつきあうので,ここで貸しを作っておけば後で困ったときに有利に働くしね。部長「君たちのチームが厳しいのも分かるけど,相手の会社にも余裕がないみたいだね。実はテストに割り振るチームの当てはあるけどこの案件で使っていいか迷ってたんだ。そこにさっきのメールが来たでしょ。あれはテスト用のチームを使っていいという幹部からの許可なんだよ。部長「事態が膠着するまで放置するとは何事だ。相手との信頼関係の問題にもなる。対処しろというプレッシャーもあのメールにはこめられてるんだよ。筆者「そうは読めませんでしたが。部長「似たような局面で『何事だ!』と怒鳴り散らしたことがあったからね。幹部が課長の頃からのつきあいだから,あれで十分な指示なんだよ。」まさに以心伝心というやつでしょうか。|2005年06月06日カエサルのものはカエサルへ今回の記事ではオブジェクトの多態性について解説します。日本語と英語に対応したメッセージの処理を考えます。メッセージの出力処理として直感的に思いつくのは次のようなコードではないでしょうか。){System.out.println(msg_en.getMessage());}}}このようなコードでも動作しますがカッコ悪いです。呼び出し側(この場合はmain)にメッセージ出力用の条件分岐があるあたりにセンスのなさを感じます。メッセージを出力するたびに条件分岐を書けということでしょうか。コードを書いたのが後輩だったら体育館の裏に呼び出してヤキを入れるところです。呼び出し側で条件分岐を書いてしまうと保守性が格段に悪くなります。日本語,英語の他にドイツ語をサポートする場合は呼び出し側の全てのif文を修正しなければなりません。一箇所でも漏らすとバグとなるのでホントに勘弁してくださいって感じです。いった場合はインターフェースを共有するか共通の親を持つ子クラスを作成します。Message.getInstance();System.out.println(msg.getMessage());}}このコードではエラー処理をサボっています。納品するソースがこのままだったらやはり体育館の裏に呼び出すでしょう。多態性を利用することで,呼び出し側は抽象クラスのメッセージ出力処理を記述するだけでよく,英語と日本語を判定する余分な処理から解放されます。メッセージ出力処理はメッセージ出力クラスの責任なのでメッセージ出力クラスに仕事をさせるべきです。人に仕事をおしつけないように配慮してクラス設計を行いましょう。ChipsSeesaaブログ広告この広告は60日以上更新がないブログに表示がされております。以下のいずれかの方法で非表示にすることが可能です。「広告を表示しない」にチェックを入れて保存する。ブログ×この広告は180日以上新しい記事の投稿がないブログに表示されております。