業務システムエンジニアに本当に必要なもの〜過労死しない仕事のために - novtan別館
システムエンジニアの過労死の話を聞くと心が冷えます。体の問題も心の問題も個人差がすごくあってそれも才能の一つと考えると不幸せになりますが、現実においては比較的頑強な個人をベンチマークに労働の量が決められてるように思えます。 最近違う現場にヘルプに行くことが多いのです。いわゆる火消しですね。とはいっても、現場と掛け持ちですから管理的なポジションにはつけず、主に実務面のお手伝いをします。すると、設計書を書いたりコーティングをすることになるわけです。だから、比較的若いエンジニアや協力会社の人と接することになるんですが… なぜ火消しに呼ばれるかというと、当然ながら成果物が上がらないからです。なぜ上がらないのか。平たく言ってしまえば、その局面において無能な人しか実務が出来ないからに尽きます。ああ、言っちゃったぜ… 設計書を書ける人は客との無意味な調整とスケジュール管理に忙殺されプログラムを書ける人は
無知なリーダーがもたらす災厄 - rabbit2goのブログ
隣のチームの仕事ぶりを知ると、自チームで当たり前に出来ていることが全然出来ていなかったり、或いはその逆のケースも有ったりして興味深い。ペアプログラミングなんて言う言葉があるけれど、チームリーダは隣のリーダと一緒に働いて互いの働き方から学ぶべきではないかと思ったりする。リーダーがペアでマネジメントを行えば、もう少しマトモになるチームも多いのではないだろうか。 以前に見たある開発チームでは、ソースコードのコミットの度にその旨を通知するメールをメンバー全員に手作業で送っていた。もちろん、手作業だから忘れることもあるし、必要な情報が欠落していたり、誤記が有ったりする。そんな面倒で、しかも不確実な作業をなぜ繰り返し行なっているのか担当者に聞いてみたら「それが決まりだから」という返事しか返ってこなかった。 ルールであることは分かっている。知りたいのは「何のためにそのようなルールがあり、メール送ることが
2011の振り返り - blog.nekokak.org
ちょっと落ち着いたので振り返りなどしてみようかとおもう。 1月 転職を決意し動き出す Teng作ってたみたい Jonkも触ってた 2月 退職の準備とおもいきや１０日で１サイトつくるとかやってた SQL::Objectとかつくってた ３月 転職 地震 ４月 HandlerSocketに興味を持ってたみたい CPANモジュールガイド献本もらったり tmux入門してすぐにscreen回帰した MySQueueとかネタでつくったみたいだ ５月 Yokohama.pmでHandlerSocketの発表とか ６月 Redisの検証をしてた Hokkaido.pmに参加する準備してた DBIx::Handlerを作ったりしてた ７月 Hokkaido.pmに参加。飯が美味かったなり ８月 Web+DBにJobQueueについて寄稿 ９月 Test::Function後のTest::Attribute::
善良で空気の読める人たちがブラック企業をつくる
「自分の子どもや親戚に、自分の勤めている会社を勧められるか？」 この質問の答えを考えた時、答えは明らかにNOだ。 http://anond.hatelabo.jp/20110813184706 を書いた元増田だが、話が発散するので書かなかったけど、もう一つ言っておきたいことがある。 「善良で空気の読める人たちがブラック企業をつくる」ってことだ。 ブラック企業をつくるのは、 ・私利私欲を肥やしたいおっさん ・既得権益を手放さない老害 ・話の全く通じない上司 ・労働者を大切にしない社長 だけではない。こういういかにも悪そうな連中がブラック化の原因ならば解決は見えている。 近づかない、関わらなければ良い。（仕事上、そうはいかない人ごめん！） だけど身の回りをみると、こんなわかりやすい連中、はっきり言って少数派ではないだろうか？ 私利私欲を肥やすことに一生懸命な部長とか、見たことあるだろうか？ 俺
「自分の子どもや親戚に、自分の勤めている会社を勧められるか？」
「自分の子どもや親戚に、自分の勤めている会社を勧められるか？」 この質問の答えを考えた時、答えは明らかにNOだ。 俺が勤めている会社は一部上場企業で、働く人にやさしいことをアピールしている会社でもある。 それなのに、答えがNOにならば、他のブラックで働いている人は想像を絶する環境で働いているのだろう。 なぜ日本企業はブラック化するか？ それはたぶん自分が我慢すればすべておさまると身勝手な考え方をしているのだと思う。 労働時間は空気で決まる先日リストラでチームの人の引継ぎがあった。 チームリーダーによって、作業がリスト化されてそれをどう割り振るか。 「この仕事は新しい人にやってって言えませんね。チーム内で割り振りましょう」 とチームリーダの一言。 ただでさえ忙しいのに、リストラで抜けた人の後任を要求することなくチーム内で吸収を図ろうとしたのだ。 チームリーダは人事権がない。 人事権があるのは
後輩が辞めた。
3年目の後輩が職場を去った。 理由はこの仕事に向いていないから。 本人も周囲もやれるだけのことをやって、そういう結論になった。 可能性だけは腐るほどある若い人に辞められるのは正直辛いけど、それ以上に彼の行く末がとても心配だ。 というのも彼の場合、技術職であるこの業界云々以前に、頭脳労働そのものが無理なんじゃないかという感じだからだ。 一番の問題は、「○○を××する」という業務があったとして、その抽象的な目的を具体的な作業にマッピングするという能力が、遂に身につかなかったことだ。 それどころか、ある程度噛み砕いて指示した作業であっても、常に色々と抜けがあったようだ。 さらに、一人で分からないことを抱え込み、質問することも、自分で調べて解決する能力も育たなかった。 一人前の担当者に求められる、今そこで起こっている事象から原因を推察し、適切な解決策を組み立てるなんて夢のまた夢。 もちろん新人がい
教えても覚えないのが当たり前 - おやじまんのだめだこりゃ日記
昨日の話に関連するが、先日上司から「やり方や考え方をみんなに教えてやらないとダメじゃないか」と言われた事があった。上司の言い分も良く理解できるのだか、俺はあえて「基本的な事を理解していない人はいないはずです。まずはやらせてみて、その上でないと何がわからないのかさえわかりません。そんな人たちに教えることは出来ません。」と突っぱねた。 この「何がわからないのかさえわからない」というのは、PCに関する質問等では特に顕著だ。そういう質問者は対処方法だけを求めていて、根本的な解決方法やその仕組みを理解しようとはしない。その場のトラブルさえ乗り越えられれば良しなので、その後も必ず同じトラブルを起こしその度呼ばれるハメになる。 本当にわからない人間に「自分で覚えろ」というのは時間のロスが大きい。だから初期教育を実施するのは悪い選択肢ではない。問題はその後なのだ。PCの場合もそうだが、頭から「俺には無理」
残業を要求する心理 - がるの健忘録
毒危険。 さて、早速ｗ まぁあちこちで散見されることではあるのですが。いわゆる「残業」に対して、とても強い関心をお持ちな現場とか個人(マネージャもどきさん)とか、がいらっさいます。 一言で迎撃するのは比較的たやすいのですが、少しそこに考察をいれて「丁寧に」迎撃してみよう、というのがこの文章の趣旨です。 「結局迎撃するんぢゃん」とか言わないように B-p とはいえ。先に「要約」しておきますと。 とどのつまり ・管理者が、現場を認識する能力に対して致命的な欠落があり ・故に、現場管理が根本的に出来ていない上で ・そもそもとして、ソフトウェア開発って物を理解しておらず ・故に、「負の生産性」とか「生産性の逆噴射」( http://d.hatena.ne.jp/gallu/20090315/p2 )とか「マイナスの要員」とか、その結果発生する「技術的負債」とかって単語に対して無知に過ぎる のが根本
会議にToDo管理、読書にも――今すぐ真似したい「ポスト・イット」活用術 - はてなニュース
貼ってはがせる便利なメモ「ポスト・イット」。最近ではさまざまな色や形のもの、特殊な機能を持ったタイプなども登場していますよね。そんなポスト・イットをもっと有効に使えるアイデアを集めてみました。はてなオフィスでの活用術もご紹介します。 ■ ポスト・イットで「読書」の記録を 本に挟む“しおり”としても使えるポスト・イット。ちょっとした工夫でさらに効率良く読書ができます。 ▽ ぜいたくポストイット読書術 - ナレッジエース ▽ 365日坊主 ポスト・イットの使い方 読み終わったページの目印としてはもちろん、ページ内の気になった箇所に貼ったり、内容について思ったことをメモしたりすれば、自分の読書の記録を手軽に残すことができます。本に直接書き込めない場合も、後ではがせるポスト・イットなら大丈夫。「たくさんのポスト・イットが貼られている本＝自分にとって重要度が高い」と、後で見返した際にも分かりやすくな
新入社員向けの教育研修--こんなやり方は避けるべき
最近、ある企業に入社したTechRepublicのメンバーが、自らの経験した新入社員に対する教育研修のお粗末さについて詳しく書いてきてくれた。新入社員を対象とする教育研修は、筆者の経験に照らし合わせると、以下のパターンに大別できる。 ベテラン社員に仕事のやり方を教えさせる。 「分からないことがあれば、遠慮せずにマネージャーに質問してほしい」とだけ告げておく。 公式の研修プログラムを1週間に渡って実施する。ただし、当の社員はこういった研修プログラムをあまりにも退屈なものと感じ、大爆発でも起こってその単調さが吹き飛んでくれないかと願うことになる。 OJT（On the Job Training）によって、社員は必要となる知識すべてを魔法のように吸収できるはずであるため、公式の研修は実施しない。 こういったケースのどこに問題があるのだろうか？ ＃1：ベテラン社員に新人教育を担当させる ベテラン社
社内失業、社内ニートはなぜ急増したのか - 社内失業と呼ばれて
社内失業 | 21:18 | | 『社内失業』という言葉を聞いて「会社員なのに失業者？何のこっちゃ？」と疑問に思う方もいると思います。なのでまず、簡単に説明しましょう。『社内失業』とは会社内に居ながらにして仕事を失うこと。つまり『社内失業者』とは、企業に雇用され、出勤していながら職務に従事していないサラリーマンのことをいいます。「聞いたことないな。少なくとも俺の部下にはそんな奴はいないな。ていうか、ごく一部のダメな社員がサボってるか、干されてるだけの話だろ？」そう思われた方もいるでしょう。しかし待ってください。それは誤った認識です。『社内失業』は、「希望・早期退職」「派遣切り」「雇い止め」「内定取消し」など長引く不況の中で語られてきた様々な労働問題に負けない、いやそれどころか最後に登場した非常に重要なキーワードであり、これらの問題とも深い関わりを持っています。なぜでしょうか。まず一つ目に、
第6回 「大丈夫でない」状況を許さないダメ上司
IT業界でプロとして活躍するには何が必要か。ダメな“システム屋”にならないためにはどうするべきか。“システム屋”歴30年を自任する筆者が経験者の立場から、ダメな“システム屋”の行動様式を辛口で指摘しつつ、そこからの脱却法を分かりやすく解説する。（編集：日経情報ストラテジー） ダメな“システム屋”上司 「プロジェクトの状況はどうなんだ？」 部上 「少し遅れが出ています。要件の考慮漏れと、性能問題です」 ダメ上司 「どのぐらいの遅れ？」 部下 「トータルで2日分の遅れです」 ダメ 「で、どうなんだ？」 部下 「要件はユーザーが今日中に決めるので追い付けますが、問題は性能です」 ダメ 「で？」 部下 「まだ原因不明ですので見積もりはできません」 ダメ 「来月1日の稼働予定は分かっているだろうな？」 部下 「もちろんです。明日からの週末も原因究明に当たります」 ダメ 「本番延期はあり得ないぞ」 部
ある程度の年齢を迎えたプログラマが抱える悩み - bkブログ
ある程度の年齢を迎えたプログラマが抱える悩み ある程度の年齢を迎えたプログラマが抱える悩みに、「若手のプログラマと比べて、どうやって価値を出していくか」という問題があります。これは言い換えれば「同じような生産性であれば、相対的に給料の低い若手のプログラマに置き換えられてしまうのではないか」という悩みです。 この問題のひとつの解決策は、プログラマ以外の仕事のポジション（たとえば管理職など）に移ることですが、他のポジションには向いていない、まだまだ現役でプログラマをやりたいという場合にどんな戦略があるか考えてみました。なお、後述するように、以下に挙げた戦略は相反するものではなく、組み合わせが可能です。 エキスパート戦略 この分野ではトップクラス、というレベルの専門性を身につけ、その分野に特化してキャリアを築くという戦略です。たとえば、ネットワークやセキュリティといった分野で一流と認められる専門
在宅勤務のよくない点--陥りやすい10の落とし穴を紹介
筆者は毎日の通勤から解放されて3年になるが、自分が在宅勤務の持ついくつかのあまり魅力的ではない側面の影響を受けていることに気づき始めた。そこで筆者は、少し作業を中断して（項目4参照）、気づいたいくつかの負の側面について書きとめておくことにした。 10．出不精になる 信じられないなら、万歩計を身につけて、朝起きてから寝るまでの歩数を数えてみるといい。コンサルタントの友人はこれを2週間やってみて、1日平均156歩しか歩いていないことを知り、恐れおののいた。これはトイレと冷蔵庫への往復だけの歩数だろう。オフィスでは一般に、食事に行くにも、コーヒーや水を取りに行くのでも、トイレに行くのでももっと多く歩くことになる。それに加え、打ち合わせにも歩いて行くし、煙草を吸いに外に行ったり、友人に会いに行ったりもする。 9．知らず知らずのうちに見苦しくなる しばらく1人だけで仕事をしていると、通常の社会的な抑
昨日、上司にキレた。 - Everything You’ve Ever Dreamed
わりとクソな会社で働いているなかで、唯一やりがいのある仕事だと感じている仕事、胸を張れる仕事がお年寄りや障害をもつ方に食事を提供するビジネスで、あまり利益をもたらすビジネスではないせいか、忌々しい部長は、「あんな陰気な商売」「たいして儲からない」と、ことあるごとに文句をいっているのだけど、昨日、営業で同行した、とある施設で、お年寄り向けに食べやすく加工調理した食品を施設側の人に試食してもらう際に「こんなゲロみたいなもの、俺は食べられない」と言い放ったのには、本気で頭にきた。 それほど大きな声ではなかったが狭い部屋で試食していたのでその場に居合わせた人の耳には届いたはずだ。相手の人も、聞こえないふりをしてくれたけれど、明らかに、一瞬目を見開いていた。部長は問題のある人間だとは思っていたけれど、それは幼稚っぽさからくるもので根っこの部分は腐っていない人間だと僕はどこかで信じていたので、今回の裏
GTD フローチャート
さて頭の中の「気になること」をすべて書き出したあとは、それぞれをしかるべきリストへ転記していくことになります。ここでの作業は一見煩雑に見えますが、慣れてしまえば1つの項目につき、10秒程度で済ませることができます。 まずは慣れるために、2、3個について実際にやってみましょう。右の図のようなフローチャートに沿って処理していきます。 Mさんの最初の「気になること」は「後輩におごる」でした。これについて次のような質問をしていきます。 それはやる必要があるか？ やる必要がない場合、いつかやるのか、それともやらないのか？ 次にとるべきアクションは1つか？ そのアクションが1つの場合、二分以内にできるか？ そのアクションが2分以内にできない場合、自分がやるのがベストか？ 自分でやるべきアクションだった場合、特定の日付にやるべきか？ それとも次にできた空き時間のときに片付けるべきか？ 「後輩におごる」の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
R-style
BLOGOS サービス終了のお知らせ
「要件定義」の4つの構造と依存関係に着目した実践手法
http://japan.internet.com/busnews/20101208/6.html?rss