部下を決して怒らなかった上司の話 - ネットの海の渚にて
上司に全く怒らない人がいた。 なにか問題が起きてもその失敗をした部下に、何も言わず事を片付けてしまうそんな人だった。 皆はその上司を「優しい人」と言っていたけれど俺はイマイチしっくりこなかった。 その上司の下で働いていたのはおよそ二年ほどの短い期間だった。 もちろん俺もその間に何度か失敗をしたけれど、その度に何も言われず上司が丸く収めてくれた。 月日が流れていつの日か俺がその上司のポジションについていた。 俺は失敗をした部下に対して厳しい態度で接した。 だからおそらく皆から「怖い人」として認識されていたと思う。 実際に自分が部下を叱責する立場になるとわかることがある。 人を怒るときには自分も相当のストレスを感じるということだ。 誰かを叱責するということは逆に言えばその失敗はもう二度と自分は出来ない。また、この時間でこれをやるようにという指示を出したなら、もちろん自分もそれと同等、もしくはそ
403 Forbidden
＼閉鎖予定のサイトも売れるかも？／ アクセスがないサイトもコンテンツ価値で売れる場合も… ドメインの有効期限を更新してサイト売却にトライしてみましょう
チームが崩壊しうる要素3つを備忘しておく - インターネットの備忘録
急ごしらえのタスクフォースチームに入って慌ただしい数週間なのですが、「あっこの要素はまず潰しておかないと、チームって崩壊するんだな」と感じた点があったのでメモします。まだあるかもだけど、とりあえずこの直近でやばいなと思ったこと。 Why？まで落とさず作業を進める 「なぜその仕事をする必要があるのか」「これはなんのための作業か」を全員が理解しないまま目先の作業に取り組むと、成果物にものすごいバラつきが出てしまう。その資料は何を伝えるものなのか、要求した人は何を知りたくて必要としているのか、をしつこく確認するのは重要で、それを全員に徹底しないと、やり直しが大量に発生するし、やり直させることで作業者のモチベーションも下がる。 やり直しも「頼んだことができてない」はまだよくて、「頼んでないのにできてない」が、なるべく少なく済むようにしないといけない。 これは、依頼側もただ作業手順を伝えるだけじゃな
どのようにエンジニアの目標設定を行うか - $shibayu36->blog;
以前 ゴールを決め目標を決める・解決案ではなく質問する - コーチングの学習で学んだこと - $shibayu36->blog; で、「ゴールを決め、現在位置とのギャップを考え、目標を決める」と良いということをまとめた。イメージとしては以下の図の通り。 しかし、前回の記事だと具体的にどのようにエンジニアの目標設定を行うかイメージが湧かない。そこで、もう少し具体的に最近どのようにやっていたかを書いてみたいと思う。 僕がメンティーと目標設定を行うときは、以下のフローを辿っている。 なんでも良いのでゴールのイメージを明確にする 現在の自分とゴールのイメージのギャップを考える ギャップを埋める目標を考え、アクションを定める ちなみに今回は、チームの成果達成のために個人の目標を決めるのではなく、エンジニアのスキル向上の目標を立てるという前提で書いていく。 なんでも良いのでゴールのイメージを明確にする
エンジニア立ち居振舞い: ミスを個人のせいにしない - だいくしー(@daiksy)のはてなブログ
お題「エンジニア立ち居振舞い」 エンジニアという仕事にミスはつきものである。 あってはならないことだけど、自分が障害の原因を作り込んでしまったり、データベースに対するオペレーションをミスってデータが消えてしまったり、そういうミスをしたことがないエンジニアはたぶんいないだろう。 個人の書いたコードや、オペレーションが起因で発生したエラーは、当然個人の責任になってしまうのだが、それを過度に責めるのはよくない。 ミスが続いて、萎縮してしまうことにより、柔軟な発想が失われたり、さらなるミスを誘発してしまうからだ。 ミスがつきものの職業であるからこそ、ミスに寛容になろうとすることで、品質を向上できることがある。 ミスを個人のせいにしないという状況は、責任を分散できる体制を作ることで実現できる。 コードは必ず第三者がレビューする、危険な操作は必ずペアで実施する、などだ。 こうすることで、個人ではなく、
仕事において「裁量がない」時の精神的負担は、想像するよりも遥かに大きい。
このメディアの書き手の一人である高須賀さんから、メッセージを頂いた。 高須賀さんは、月200時間以上の超長時間労働を経験されたということだったが「結構がんばれていた」という。 ただしそれは「指示を出す側」という条件付きの場合だった。 それでも指示出し側だったのもあって、結構みんながんばれてましたね。逆に指示出される側のコメディカルは、勤務時間が僕らよりも少なくてもバンバン消えてってましたし。やっぱり裁量の有無は大きいなぁと 私も同様の記憶が数多くある。 例えば、私が新人の時に一番キツイと感じた仕事が、実は「上司・先輩のコンサルタントへの同行」だった。 「上司や先輩のコンサルタントへの同行なんて、任せてればいいからラクじゃない」 という方もいるが、とんでもない。あれは一番負荷が大きい仕事の1つだ。 仕事に慣れておらず、自分だけでは何一つできない状態で、先輩からの指示だけ飛んで来る。 ・議事録
上司をナメているのは､絶対にバレている！
コンテンツブロックが有効であることを検知しました。 このサイトを利用するには、コンテンツブロック機能（広告ブロック機能を持つ拡張機能等）を無効にしてページを再読み込みしてください。 ✕
マネジメントの仕事・地位・パワーを混同してはいけない | タイム・コンサルタントの日誌から
ある朝、目が覚めると、あなたはノルウェー国王になっていた。いったいどうしてこんな事になったのか。あなたは自分の名前も、生まれ育った日本の町も経歴も、全部ちゃんと覚えている。なのに、ノルウェー国王になったつい最近のいきさつだけは、すっぽりと記憶から落ちている。 呆然としながらも身支度を終え、質素ながらも立派な朝食を食べて人心地ついたあなたの前に、宰相がやってくる。彼は礼儀正しくあなたに挨拶をすると、いくつかの紙の束を取り出して、あなたの前に置く。「国王陛下。これが本日、発布いただきたい法律と政令です。どうか、ご署名ください。」 念のために言っておくと、北欧の国ノルウェーは、完全な民主主義国家である。法律は国民の選出した議員が国会で決める。だが、すべての法令は、国王の名前で公布するしきたりになっているときく。宰相があなたにサインを求めてきたのは、そのためである。あなたの前には、法令書類一式と、
なぜプロジェクトは炎上するのか？炎上しやすい4つの傾向と、炎上を防ぐ3つの対策 - paiza開発日誌
Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ！』 こんにちは、谷口です。 某Mずほ銀行の案件のニュースが出たとき、弊社でも結構話題になりました。 あんなに巨大なプロジェクトをしずめるのは、もう本当に不可能なんじゃないかと思いますが、どんなに大きな炎上も、恐らくは小さな火種が集まって、やがて大きな炎となってしまった結果だと思いますし、最初の小さな火種の段階からぷちぷち消していけたらこんな結果にはならなかったはず……。 という話をしていたときに、paizaのエンジニアが「かつて炎上しているプロジェクトに自ら突入していくのが趣味だった」などと言い出しました。「そういう性癖なのかな」と思ったんですが、聞いてみると 「炎上しているプロジェクトに行くと『優秀な人たちはどんな振る舞いや働きをして炎上をしずめているのか』『何が原因で炎上したのか、どの時点で何をし
マネジメントを経験してようやくわかってきた、半年で部下を１人前にするコツ - トイアンナのぐだぐだ
試行錯誤しながら手に入れた部下や後輩を半年で１人前にするコツをまとめました。 嫌な先輩から、まあまあの上司になるまで まずは私の経歴を少し。昨年独立するまで外資で働いていました。新卒で入ったのは少数精鋭にしたって、いくらなんでも少なすぎない？ と人事の肩を揺さぶりたくなる部署でした。 入社2年目には「もう１年いるんだからシニアだね！後輩指導よろしく」と宣告され、必死で３人指導してのち転職。その後はプロジェクトごとに部下を持っていました。独立した現在は外注マーケターとしてトレーニング業務も担当することもあります。合計で指導した部下・後輩は約10名前後。 最初は最悪の上司だったと思います。詳しくは「いつの間に自分が「細かいことにウルサイ嫌な先輩」になっていた 」に書きましたが、もうタイトルだけでお察しください案件。自分でもこれはいけないと思い四苦八苦した今、半年くらいで「いいね、それで行こうか
プロジェクトは成功したけどマネジメントに失敗した話。 | meeta MAGAZINE (ミータマガジン)
こんにちは。はてなブログ「プロジェクトマネジメントの話とか」管理人のwiz7です。このたび、meetaMAGAZINE様へ寄稿することとなりました。 僕はIT業界で働いているのですが、今回は僕が過去に経験した、プロジェクト自体はうまくいったけれどもマネジメントに大失敗した話について、お伝えしようと思います。 ビジネスにおける「合理主義」は絶対の正義なのか？ 僕が昔担当した、とあるプロジェクトでの話です。当時の僕は、効率的に爆速で作業を進め、品質をしっかりと担保した形で納期を守ることだけが絶対の正義だと思っていました。逆に言えば、それ以外の犠牲は一切いとわない！論理こそが神！ぐらいの勢いだったのです。狂ってますね（笑） もちろん今でも、仕事を成功させる上で合理主義的な考えは最も重要な要素の一部だと思っていますし、そもそもそうでなければ仕事を遂行することはできず、企業活動としても利益を出せずに
新米プロダクトマネージャーへおすすめしたい12冊 - Noize
プロダクトマネージャーには共通した悩みと、それに対する処方箋がある。 日本最大のプロダクトマネージャーコミュニティ（参加者約800名）「PMJP」。のなかで 「プロダクトマネージャーとしてキャリアを始める際にどんな本を読めばよいか」というトピックが非常に盛り上がった。 そこで、まず新米プロダクトマネージャーがまず直面する課題を4つに分類し、それに対する処方箋となるような本を他薦・自薦含め12冊ほどピックアップしてみました。 決してMECEではないが、特に関心度の高いと感じるセクションについてまとめてみます。 プロダクトマネジメントという概念は形式知としてそこまで蓄えられているものではないため、これらの本が新米プロダクトマネージャーを救うことを心より祈っています。 1 / プロダクトマネージャーの原点とは？ 日本においてはプロダクトマネージャーというポストの存在自体がまだまだ認知途上。新米の
安全第一とはどういう意味か | タイム・コンサルタントの日誌から
ある時、友人がやってきて「車を2，3日貸してくれないか」という。小規模な引越をしたいので車が入り用なのだという。レンタカー代ほどではないが借り賃も払うから、といって謝礼を菓子折と一緒に置いていった。 さて、数日たって友人が返しに来た車を見て驚いた。フェンダーから左のボディにかけてへこみが入り、サイドミラーも折れている。どうして、と聞いたら「左折時に不注意で障害物に引っかけてしまって」という。そして、「すまんすまん。でも、車両保険には入っているんだろ？ たいしたことはないから、すぐ直るよ。事故は一定の確率で起きるもんなんだ。」・・そんな風に友人が言ったら、あなたなら、何と答えるだろう？ 「いや、車なんか大丈夫。それより君に怪我がなければ、何よりですよ。」こう答えられるほど、寛大な度量はわたしには、無い。たぶん頭に来て、「馬鹿野郎！ 人の車を事故っておいて、その言いぐさは何だ。確かに保険にゃ入
はてなブログ | 無料ブログを作成しよう
聖蹟桜ヶ丘へ 今年度の授業が全て終了した。最後の授業はテスト返却とその確認作業の後は特に何をしろとも言われていなかったので、『耳をすませば』の後半、お姉さんと雫が言い争いをする場面を生徒と皆で見た。 この場面。あの場面、お姉さんは雫に「今しなきゃいけないことから逃…
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
