退職エントリーを書かれる前に実践したい、エンジニアが辞めないチームの作り方
採用難に苦しむIT企業でマネジャーをやっている皆さん、こんにちは！ プログラマーにして採用担当、菌類のくせに人類を採用、育成している「きのこる先生」です。 普段はIT企業で働くエンジニアの皆さんに転職やキャリアについてお話していますが、今回は担当編集からのリクエストで、そんなエンジニアたちのマネジャーとして日々奮闘している皆さんに向けてのお話です。 エンジニアに「辞めます」と言われたら いきなり胸が苦しくなるような見出しですが、今回のテーマは「エンジニアの退職」です。 皆さんはマネジメント対象であるエンジニアから「辞めます」と言われたことはありますか？ 菌類は、あります。それはもう、数え上げたらキリがないほど……。 どんな理由であっても、チームのエンジニアが辞めるのはつらいものです。目の前の仕事には影響が出るし、残されたチームメンバーも何だかざわついてしまいます。「今までのマネジメントは間
仕事ができる人ほど、できない人に優しく振る舞うのは、マネジメントの定石。
昔、ある会社の営業MTGで、忘れられないやりとりがあった。 少々詳しく描写すると、出席者は以下の通り。 ・役員（部長） ・リーダー ・メンバー 7名のメンバーの能力は各々、高、高、中、中、中、中、低。 二人ぐらい優秀な人物がいて、一人「できない人」が混ざっているイメージだ。 また、役員とリーダーは切れ者で、部下の報告の論理矛盾やダメな点にはすぐに気づく。 さて、こんな状況で来期の「営業計画」について、MTGが開催された。このMTGの議長はリーダーだ。 リーダーはテキパキと議事を進める。 来期の営業部の方針に始まり、具体的な目標設定、個人の役割など、メンバーへの指示も簡潔でわかりやすい。 ここまではなんの問題もなかった。 だが、今年一年を振り返っての営業報告が始まると、雰囲気が変わった。 無理もない。メンバーの一人ひとりが、自分の過去の実績と、これからの具体的行動を発表しているのだから、緊張
「マネージの意味が“管理”？ ハズレです」田端信太郎が語るマネジメントの本質｜新R25 - 20代ビジネスパーソンのバイブル
社会人になって数年たったR25世代のビジネスマン。 後輩ができてきたり、ちょっとしたチームのリーダーを任せられたりする機会も出てきたはず。 実力に自信はないけど、ちょっとは先輩らしいところも見せなくては…。でも、いわゆる「マネジメント」なんてしたことないから、どうしたらいいのかわからない！ そこで、“新R25レギュラーズ”田端信太郎さんに「マネジメントの本質」を教えていただきました。 〈聞き手：天野俊吉（新R25編集部）〉 【田端信太郎（たばた・しんたろう）】株式会社ZOZO コミュニケーションデザイン室本部長。NTTデータを経てリクルートへ。フリーマガジン『R25』を立ち上げ、創刊後は広告営業の責任者を務める。その後ライブドア、コンデナスト・デジタル、NHN JAPANを経て、2018年3月から現職
やはり俺のスタートアップの意思決定はまちがっている。
フォーカスするためには、たぶんどうやってフォーカスするか（前回）に加えて、何にフォーカスするかを決める必要があって、今回は後者、つまり「フォーカスポイントを決める」方の話です。 スタートアップの初期は Y Combinator 的に言うところの Do things that don’t scale （スケールしないことをしよう）をはじめとした明確なフォーカスポイントがあると思います。ただ次第に自分たちでフォーカスポイントを決めなければいけなくなってきて、そのときにどのようにフォーカス先を意思決定すれば良いのか、どうすれば良い意思決定ができるのか、という問いが出てきて、その際に方法論の必要性が生じます。 そこで意思決定の方法論を検討するのですが、スタートアップのような情報不足や資源の制約下では、ゲーム理論をはじめとしたいわゆる規範的な normative 意思決定理論よりは、行動経済学や認知
ADHDで管理職をやっている者なんだが
週末の借金玉氏(id:syakkin_dama)のエントリやそれを受けて書かれたわかり手氏(id:ganbarezinrui)のエントリ、http://anond.hatelabo.jp/20170227005158 あたりのブコメとか読んでいて、随分と世知辛いねえ、と思ったのだけれど、良い場所が無いので増田にこれを書いている。たぶん超長い。 俺はタイトルに書いてあるようにADHD（診断済み）だ。典型的な注意欠陥・多動性が認められ、一方でASDの症状はゼロという純正ADHDマンである。なので先のお二方のエントリは全力で泣きながら、共感しすぎてヘドバン状態で読んだ。でもわからない人には何が「なので」なのか本気でわからないんだと思うし、それで正常なんだろうということも理解している。 んで、一般的なIT関連の企業で管理職をやっている。それなりに多様な部下もいる。業界的にブラックな香りがするWeb
エンジニア社員「今月から週3回、昼過ぎに仕事抜けてジムに行きたいんだけど。」 僕「」 | maximum80のブログ
新田です。 最近渋谷区の条例で同性パートナーシップの証明書が発行が話題になったり、各所で 多様性 という言葉が注目を集めてますよね。 「指示待ち人間」はなぜ生まれるのか？ 有能な人たちが「働きたくない」と嫌がる会社の特徴。 また最近Facebookで上記のような記事をよくみかけまして、ダイバーシティ・マネジメントについて自分でも考えていることや、同じような壁にぶつかった経験があるので久しぶりに投稿してみようと思います。 エンジニア社員「これから週3回、昼過ぎに仕事抜けてジムに行きたいんだけど。」 僕「」 タイトルにしてみましたが、今からちょうど一年前ぐらいに実際に社内であった出来事です。弊社で働いているカナダ出身のエンジニアの社員から、或る日突然このような提案を受けました。 会社の業態、職種にもよるとおもうのですが、殆どの場合 「え、ちょっと何言ってるかわからないんですが。。」 となって
プロジェクトマネジメントなう＼(^O^)／ | ぽんぽんぺいんなう＼(^O^)／
２０代後半から１５年ほどSIプロジェクトのリーダー／マネージャーをやってきた経験から。 『 監督とは、 他人が打ったホームランで金を稼ぐことだ。 』 ケーシー・ステンゲル（MLB監督） ●ポリシー １）全てのメンバーが目的・段取りのわからない仕事をしない／させない。 ２）プロジェクトの成功には、短期的な成功と中長期的な成功がある。両方を意識すること。 ３）プロジェクトの短期的な成功は、お客さんを満足させることと利益をあげること。 ４）プロジェクトの中長期的な成功は、リーダーとメンバーが成長し、また一緒に仕事をしたいなと思い合うこと。 ５）リーダーとメンバーがフラットでオープンな関係を築けなかったプロジェクトは、中長期的には失敗する。 ６）みんなで得意なことを持ち寄って知恵を出し合ってやってみてダメだったらそれは僕らにはムリな仕事だったということ。 ７）人は一人一人別人であり仕事に対するスタ
プロセスをマネジメントしたければプロセスを削れ: DESIGN IT! w/LOVE
不確実な時代をクネクネ蛇行しながら道を切りひらく非線形型ブログ。人間の思考の形の変遷を探求することをライフワークに。 プロセスマネジメントにありがちな間違いのひとつに、ミスを減らそうとして、そのチェックをするプロセスを増やしてしまうということがある。 もちろん、すべての場合にそれが間違いというわけではない。 そのチェックが機械によって自動的に行われるのであれば大丈夫だし、そもそものプロセスが単純なものであれば、ひとつ工程が増えても大きな問題にはならない。 ミスを減らそうとして、そのチェックをするプロセスを増やしてしまうことが問題になるのは、そのミスが実はすでに多すぎて複雑な工程からなるプロセスそのものが負担となり、業務の遂行を圧迫しているケースだ。 すでに多すぎて複雑すぎるところに新たにチェック工程など追加すれば、業務の圧迫度合いはより大きくなり、また違うところでミスが起きやすくなるのは目
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Loading...
SIerが仕切っている開発現場でありがちなのが、何かミスを犯すと、そのミスを防止するようにすごく手間がかかるチェックが追加されて、開発効率とモチベーションが下がるというダメなパターン。 たとえば、「今年度は申請書(EXCELシート)書いて上司の判子もらわないと svn commit すらできない職場で仕事することになりました。 - SiroKuro Page」とか。 これはプロセスマネジメントでもなんでもない、管理ごっこだ。管理したつもりになって自己満足しているに過ぎない！！ プロセスをマネジメントしたけ