- 追加された行はこのように表示されます。
- 削除された行は
このように表示されます。
!!!技術的雑談-やっちゃいけないこと
!!環境
*どこでも。(※人間らしい仕事がしたくない人を除く)
!!現象
*プロジェクトの活気が無い
*会社に行くのが鬱だ、もしくはメンバーにそういう人が見受けられる
*漠然とした危機感があるけど細かいところに行くと「なんとかなるんじゃない」で片付けたがる
*リーダーが脊髄反射でしか物を考えない
*リーダーの言うことが聞く度に変わる
*いつでも残業
*人にやたらと仕事をさせたがる
*常に「忙しい」ばかり言っている
*今日決めた事が明日には変わる。又は制定された決まりが守られない。
!!原因
'''大原則：仕事は仕事のためにしてはいけない！！！'''
まずはそこから変えないといけません。
仕事にやりがいがあるのはわかります。仕事が楽しいのもわかります。
でも、趣味と仕事を混同してはいけないのと同じように、仕事が生活を侵食してはいけないのです。
ここで「いけない」といっている意味は「望ましくない」のではなく「must not」という意味です。
仕事に締め切りがあるように仕事時間にも締め切り＝定時があります。
その中で「キチンと」やるからこそ仕事なんです。
ダラダラと仕事をするといいことは何にもありません。
極たまぁ〜に仕事が好きで好きでしょうがなくて「俺は24時間でも働くぜ！」という人がいますが、それは単なる病気です。
あえて病名をつけるなら「残業性現実逃避病」か「社会生活不適応症候群」か「病的潔癖症の仕事代償型」ですので、周りの人に被害が及ぶ前に速やかに隔離して病院に移送しましょう。
また、「決まりごと」というのはあくまで「仕事を効率良く行う為の手段」として存在するべきです。
浸透しない決まりごとには「構造的な欠陥」か「運用的な欠陥」があると考えるべきです。
!!対処
*「仕事を一生懸命にやって何が悪い！！」という人がいたらこう言ってあげましょう。
**「仕事を一生懸命にやるのは勝手ですが、私はそうは考えません。あなたの教義を押し付けないで下さい」
**「会社はあなたの墓を建ててくれませんよ」
**「残業をすればするほど会社は人数が足りていないことを認識しづらくなります。結果いつまで経っても人を増やしてもらえないし、そんな状況を見てそこに飛び込みたいと思う人を減らします。あなたのやっていることは結果的に会社に対してマイナスになっています。」
*定時後にミーティングをスケジューリングするのはやめましょう。現実的に定時があってなきものであっても、最後にメンバーがあなたに付いてくるのは仁義によるところが大きいです。
*無意味にミーティングを増やすのをやめましょう。多くのリソースを「ロック」するミーティングはいわば「ジャイアント・ロック」です。プログラムでやると「アホ」と言われることを何で人間でやるのですか？
*ミーティングを開催する場合、「主催者」を必ず決めましょう。そして、事前に議題を定義し、「何を話し合うのか」「何を決めるのか」「何で集まらないと決められないのか」を良く考えましょう。そうしないと無駄な井戸端会議になります。
*ミーティングには制限時間を決めましょう。制限時間内に決まらない場合、事前の準備が足りないか、もしくはその議題がミーティングで決定するべき内容としてふさわしくないかのどちらかです。
*開催側も応召側も、ちゃんと前準備をしてミーティングに臨みましょう。ちゃんと用意のされたミーティングは短い時間に整然と終わるはずです。目安として、1議題に15分以上かかるときはその進め方に問題があります。見直しが必要です。
*割り込み仕事を依頼することは基本的に「恥」です。事前に察知できなくてスケジュールできなかったのはあなたの落ち度です。割り込み仕事を依頼した人には必ず「バ〜カ」と言ってあげましょう。痛みがないとなかなか学習できないものです。
*メモを残しましょう。あなたの頭の中はあなたのものです。あなたの頭の中にあるものを欲しがる人は必ずあなたの時間と体を要求します。もしあなたの頭の中に「仕事で必要な情報」が残っている場合はさっさとメモに「フラッシュ」しましょう。
*リーダーは「明日の予定」を語りましょう。今日の対処はメンバーに言わせましょう。おきてしまった事への対処は誰でもできます。これから起きることをコントロールするのがリーダーの仕事です。
*かといってやたらと時間とか「いつまでに？」ばっかり言うリーダーもやめましょう。メンバーからは単なる無能なウザイ人に見えます。期限を人に聞くリーダーは結局自分が予定をわかっていないこと、ひいてはプロジェクトを把握していないことを自ら証明するようなものです。
*情報には必ず「置き場」「更新方法」「参照方法」を付記しましょう。何でオブジェクト指向プログラミングをするプログラマーがデータの操作メソッドを現実では用意しないんでしょうか？
*やたらと何にでも「担当者」を'''その場で先に'''決めるのはやめましょう。仕事や情報は「担当者ありき」ではありません、「目的ありき」です。その目的が達成されるために「担当者」をつけるのが本当にベストなんですか？実は目的の達成過程を把握するのがめんどくさいから誰かに投げて逃げたいだけなんじゃないですか？
*かといって、何でも自分でやるのはダメです。一人で戦って良いのはウルトラマンだけです。しかもウルトラマンはスペシウム光線というキメ技があり、かつ3分しか戦えないことを忘れないで下さい。あなたの人生は3分じゃ終わりませんし、必殺技もありません。
*一人の人間に同時に3つ以上の締め切り間近のタスクが乗っている状態は問題です。管理者か本人のどっちかの仕事に問題がある。また、その状態を把握しておらず放っておく管理者は注意力が足らない。
*無能な管理者は「願望」と「見通し」を混同する。結局、何かがうまくいかないのを作業者の無能のせいにして片付ける。
*「管理」とは、いつも・誰にでもプロジェクトの目的・状況が明確に理解可能に保つことである。状況とは「今までやってきたこと」「これからやらなくてはならないこと」「潜在的なリスクのコントロール」のことである。
*締め切りを設定されたタスクは、その締め切りの直後に評価者が評価できること。提出したら提出者はそのタスクを忘れなければならない。金曜日に締め切りを設定してしまうと結局評価とフィードバックが月曜日になってしまう。結果、提出者はもうその提出物のことは忘れているからフィードバックの効果が薄くなる。万一提出物の手直しが必要になった場合、提出者は提出物を訂正する作業のほかに、そのタスクの内容を「思い出す」作業が必要になり二度手間である。
*一番のリスクコントロールは「シンプルに行う事」です。シンプルで無駄がなければ余計なミスも発生しませんし、それを確認する為のチェックも最小限で済みます。稼働時間が少なければその間に発生するトラブルも最小限に抑えられます。
*バグを発生させない一番の方法は、「プログラムを書かないこと」です。目的はプログラムを書く事ではなく、「命題を正確に効率的に解決する事」です。書かないで済ませられることは書かないようにしましょう。
*各種のプログラミング補助ツールを使っている時に陥りがちな罠。往々にしてそのようなツールは「設計とコード作成が同時にできます」というのがウリになっているが、補助ツールを「使う」事が目的化してしまうと結局のところ設計資料が何も残らず、無意味なドキュメントが大量生成されて後からの参入者や見直しに多大な労力が必要になってしまう。それを避けるには「その工程で明らかにしなくてはならない事は何か？」を常に意識して成果物を残す事が大事。
*ドキュメントは多ければ良いというわけではない。多いだけでわかりづらいドキュメントは結局何の役にも立たない。局面ごとに厳密に分類し、ある目的から明確に簡潔に必要な情報が得られる事が必須。多いだけのドキュメントは実は何の役にも立っていないことが多い。
*メンテナンスされていないドキュメントは無い方がマシ。ましてやそれを共有ドライブでメンバーに公開し続けるのは毒を垂れ流すのに等しい。
!!履歴
*2005/10/25 -- 初版：とりあえず溜まっているものをフラッシュ
*2005/11/03 -- ちょっと追加。
*2006/10/23 -- さらにちょっと追加。
*2009/03/08 -- さらにちょっと追加。
[[技術的雑談]]へ戻る
!!突っ込み
*これ、すごくいいです。私のいるIT関連開発の現場のあらゆるSEに読ませたい。「いつでも残業」から私も逃れたいし。ってか、私自身はかなり勝手に帰る人だからまだマシかも(笑)系列衛星弱小会社の社員SEさんほど悲惨な人生はないですな、とすぐ近くで彼等を見ていていつも思っとります・・・。朝、出掛けに幼稚園の娘に言われるそうでですよ「いってらっしゃーい、パパ。また来てね〜」（泣） - 壱号 (2006年10月27日 11時15分24秒)
*↑全米が泣いた…(T_T) - Tsubasa (2006年10月27日 16時03分12秒)
{{comment}}
[[技術的雑談]]へ戻る
{{trackback}}
[[技術的雑談]]へ戻る