『部下が絶対、目標達成する「任せ方」』（中尾ゆうすけ著、PHP研究所）の著者は上場企業の人事部に在籍していたころ、やる気に満ちた、たくさんの課長昇進者の姿を見てきたのだそうです。しかしその一方、職場のエースが課長になったとたん、期待に応えきれずモチベーションを落としていくという現実も目にしてきたのだとか。 課長になる人は、もともとその職場で活躍し、課長に推薦され、一定の試験や社内選考を経て、会社幹部に認められ人選された優秀者であるはず。にもかかわらず、なぜそうした差が生まれてしまうのでしょうか？ 当然ながら、組織の目標達成のために課長がひとりでがんばるには限界があります。そこで部下に適切な業務を与え、目標を持たせ、「絶対部下に目標達成してもらう」ためのマネジメントを行うことが必要になるわけです。だからこそ、課長になる以前となったあととでは、仕事が大きく変わると考える必要があり、いままでの延

上司たちは見ていないようで、部下のことをしっかりと見ているもの。今回の結果と同じようなことをあなたの上司も思っているかも!? 上司たちは、様々な観点から僕らの仕事ぶりを見て評価している。だが、一口に「評価のポイント」と言っても努力すべきポイントは多岐にわたりすぎて、どれが重要なのかはわかりにくいのが実情だ。そこで、僕らの上司層にあたる30～40代の係長以上の役職に就く会社経営者・会社役員・会社員200人を直撃！　社会人の資質として必要と思われる項目のなかから、「部下の資質として『これがないとマズイ』と感じる能力」を選んでもらった。 ●これがないとマズイ！社会人の能力TOP10 （全11項目から上位3項目を選択してもらい、1位＝3pt、2位＝2pt、3位＝1ptとして集計。調査協力／アイリサーチ） 1位　物事に進んで取り組む力　228pt 2位　目標を設定して、確実に行動する力　18

こんにちは、 id:stanaka です。 先日、社内ミーティングでディレクターから「エンジニアの専門性を伸ばすためにディレクターとしてなにができるか」という質問を受けて回答した社内向けエントリを公開します。 (ちなみに、はてなでのディレクターは、エンジニア、デザイナーなどの数名のメンバーからなるチームの率いる、現場にもっとも近いマネージャー、というポジションです。) エンジニアの専門性を伸ばすためにディレクターに気をつけてほしい3つのこと 1. 引き出しの数を増やすことができるようなタスクを振る エンジニアにとって自分が持つ引き出しの数と専門スキルは強い相関関係があります。サービス開発において遭遇するさまざまな局面において、いくつかの選択肢を提示でき、さらにその中から最適なものを選びとれることは、エンジニアの専門性が高いことの証です。 そのためには、いろいろな経験をさせてあげることが大事

チームでの開発って大変だけど楽しいと思ってるみなさんこんにちは。@ryuzeeです。 チームは共通の目標に向かって日々の仕事に取り組んでいくことになりますが、そのためにはメンバーそれぞれが必要なスキルをもっている必要があります。このスキルを見える化するテクニックの1つとしておすすめなのが、スキルマップです。 作り方は簡単で以下の図のように横軸に必要なスキルを、縦軸にチームメンバーの名前を入れます。それぞれのマスでは、その人のスキル度合いを表す印を入れていきます。ここでは、★：エース、◎：得意、○：一人でできる、△：助けがあればできる、空欄：できない、・：今後習得したい、というようにしていますが、この記号はチームで好きに決めて構いません。 このスキルマップの効用と運用について見ていきましょう。 効果：スキルの見える化長い間同じチームで働いていれば、誰が何をできるのかはだんだん分かっていきます

あるとき突然『チームのキーマンが抜ける』というイベントが発生しました！ まあ会社という組織ではよくありますよね（苦笑 チームメンバーが不安がっていたので、以前、楽天の川口さんに教えてもらったドラクエ風スキルマップを使って今の状況を可視化してみました。 これもまさにゲーミフィケーションって感じですねぇ～ スキルマップを作る過程 元々はWebアプリケーションエンジニアのスキルマップだったため、自分達に合うように数人でスキルマップを練り直しました。 これだけでもかなり盛り上がりましたッ！！ 以下は川口さんのオリジナルから変更したところです。 要件定義のスペシャリストとして、商人を追加。 旅芸人はマネージメントのイメージに変更 スキルの方向を上方向に変更 盗賊のスキルレベルの見直し CやC++をイメージして文言を見直し 特性に対応するキーワードを追加 スキルマップを記述する チームメンバーに実際に

10年近く5～6人のチームで回してきて、いくつか自分で学んできたことの中で、 今でも心がけているものを紹介する。 異動により今の環境が大きく変わるため、自分自身の整理の意味も込めてまとめてみた。 優秀な部下は大勢の前ではなく、一対一のときに褒める。優秀な部下は嫌でも目立つ上に、誰の目から見ても明白な成果を継続して上げていることが多い。 そんな部下を例え大きな成果を上げたからといって、 その部下と同列の者の前で大きく褒めると、他の部下の向上心が下がりやすい。 これは対象の部下本人のためというより周りのためだ。 普段優秀でない部下の大きな手柄は、大勢の前で褒める。本人の自信にも繋がる上に、周りから能力を認められているという肯定感が強くなる。 いい意味での周りからのプレッシャーとなり、仕事に対する姿勢も変わってくる。 結果が出ない者は姿勢や努力を褒める。結果として大きな成果に繋がらなくとも、そこ

「○○をやって欲しいと伝えたのに、××さんが動いてくれない」 皆さんの周りで、このような言葉を聞くことはありませんか？ ・自分のコミュニケーションのせいで、チームでやっていた仕事が滞ってしまった ・「何が言いたいのかわからない」と言われてしまった ・何かを伝えた途端に怒られるなど、相手に想定外の反応をされてしまった このような経験をお持ちの方も、少なくないはずです。 これらはすべて「伝える力」に課題があると言えそうです。そこで今回は、「伝える力」を高める3つのポイントについて解説していきましょう。 ポイント1：相手を知る 何かを伝えようとするときには、当たり前ですが伝える相手がいます。まずは、その相手がどういう人なのかを理解することが大切です。 ここで意識するとよいのは、①相手がどのような人なのかを知ること、②相手の社会的な立場（相手が社内であれば社内での立場）について理解することの2点で

１度だけ、自分のクラスが崩壊した経験がある。ただ、若い時で、記録もちゃんと取っていないし、その時は必死になっていたので、いったい何が原因で起こったのか不明である。諸先輩方には連日いろいろアドバイスをいただいたが、結局、収束には至らなかったような記憶がある。 その後の長い教師生活の中で、学級崩壊を間近に見た経験がある。それをここで書きたい。 最初はある、教育に非常に熱意のある、若い女の先生のクラスで起こった。 転勤してきたばかりで、学校や子どもの様子をよく知らない。それなのに、５年生を担任した。 教育に対して非常に熱意のある先生だ。クラスはこうでなければならない、子どもと子どもの関係はこうでなければならない、ということで指導されていた。友だちとは仲良くするものでしょ、力を合わせあうものでしょ、ということを真っ直ぐに子どもに言っていた。 勉強についても熱心に取り組まれていた。力の弱い子どもには

shinshinohara @ShinShinohara 「指示待ち人間ばかり、自分の頭で考えて動かない」という嘆きの声をよく聞く。不思議なことに私の研究室には指示待ち人間は一人もいない。パートの女性３名も他の研究室がうらやむほど優秀。９年連続で私のところに来た学生もことごとく自分の頭で考えて行動する。指示待ち、なんのこと？という感じ。 2015-11-04 20:48:13 shinshinohara @ShinShinohara たぶん私がテキパキ指示を出せない人間なので、そのうち周囲があきれて、自分の頭で考え出すからだろう。私は自分のことさえ心もとなく、パートの方に「今日、お客さんじゃなかったですか？」と念を押されて思い出すこともしばしば。スケジュール管理まで進んでやってもらっている。実に助かる。 2015-11-04 20:52:00

はじめに こんにちは、投稿推進部の勝間です。 約1年前、「サービス開発エンジニアからマネージャになった話」というエントリを投稿しましたが、現在も試行錯誤しながらマネジメントに取り組みつづけています。 「組織は生きもの」とも言いますが、私の部署もまた生きもののように、日々いろいろな課題が生まれ、それに取り組んでいます。今回は、そのような部署で私が感じた課題と、それに対する具体的な取り組みについて、いくつか事例とあわせてご紹介します。 1. 業務外の問題に目を向ける 私の部署では、毎日約5分間の朝会を開いています。 1人30秒くらいで、「今日取り掛かること」「参加するミーティング」「その他勤怠など含めて共有すべきこと」を共有します。 朝会を行うことでそれぞれの業務的な進捗を確認でき、また、内容について疑問に思ったこともすぐに確認、理解できる状態を作ることができていました。 一方で、業務と直接関

会員事業部の森田です。 対象と内容 この記事は、クックパッドと同じような200～300名規模の組織で働く、「最近調整が多くてコードを書く時間がないなぁ」と思い始めた30代エンジニアを対象として、日々の調整の負担を減らすための「考え」と「行動」を整理し、まとめたものです。 組織における分業と調整 組織に所属する人たちは協力して組織目標の達成を目指します。みんなで同じことをしてもしょうがないので、必然的に役割を分担(分業)をします。分担した仕事はなんらかのタイミングで統合する必要があります。その統合が調整です。つまり分業と調整はセットです。じゃどういう分業があるのかといえばそれは組織構造によります。今回は私達が採用している事業部別組織下*1 での調整の話をします。 分業の種類 事業部別組織では垂直と水平の2つの分業が存在します。それぞれに少し毛色の違う調整が発生するわけですが、いくつかのことを

“COOL JAPAN”の代表作 米型グローバルスタンダードの侵食、ITリテラシーによるギャップ、そして終身雇用の崩壊といったここ10数年でのパラダイムシフト。そしてその後のビジネスシーンでのマネジメントは明らかに変質を期し、マネジャーにとっては頭の痛くなる問題の1つが部下のマネジメントではないだろうか。 いやそれは今に限らずむしろ本質的なればこそマネジャーにとっては悩ましく、世にその指南書の類は事欠かない。 個の時代といわれて久しいが、先の見えない時代に個人と企業の関係も変質せざるを得ないのが21世紀の日本の現実とすれば、集団を重んじる大企業の体育会体質も懐かしくさえ思えてくる。 “COOL JAPAN”の代表作と言われるアニメーション作品「攻殻機動隊」の中で扱われる物語はそんなパラダイムシフトが一段も二段も進行し、世界大戦を更に2度経た後の近未来である。 「攻殻機動隊 STAND AL

「組織の公安9課モデル」とは何か。「攻殻機動隊」好きにはお馴染みの公安9課だが、9課課長の荒巻大輔の以下のセリフが象徴するような組織のことをいう。 我々の間にチームプレイなどという都合のよい言い訳は存在せん。あるとすればスタンドプレーから生じるチームワークだけだ。 昨今は「ホラクラシー」などといわれたりもするフラットな組織が話題になっている。 「ホラクラシー」（holacracy）とは、従来の中央集権型・階層型のヒエラルキー組織に相対する新しい組織形態を示す概念で、階級や上司・部下などのヒエラルキーがいっさい存在しない、真にフラットな組織管理体制を表します。ホラクラシーの下では、意思決定機能が組織全体に拡張・分散され、組織を構成する個人には役職ではなく、各チームでの役割が与えられます。細分化されたチームに、それぞれ最適な意思決定・実行を行わせることで、組織を自律的・自走的に統治していくシス

★この記事が漫画になりました！★ ↓↓↓ hikarujinzai.hatenablog.com 「あの人って仕事できるよね」「あいつ仕事できないよね」というようなセリフを一日に一回くらいは耳にしませんか？ご自分でもお使いになりませんか？私はよく耳にもしますし、頻繁に使ってしまっています。でも仕事ができるできないの明確な共通の判断基準って存在するのでしょうか？ 「彼のどこがこうだから仕事できる」とか、「彼女には○○力が欠落しているから仕事できない」みたいなきちんとした判断理由を付け加えた使い方って日常会話ではほとんどされないですよね。もちろん世間話ではそれで全然いいでしょうし、逆にいちいち理由付けなんかしてると「お前面倒くさい奴だなあ、仕事できるできないなんて、そんなの雰囲気でいいんだよ雰囲気で！」って嫌われるのがオチですよね。 私も世間話をするときはそんな理由付けなんかしませんが、人事で

世の中に流布している「プログラマー35年定年説」は、大きく以下の3つに分類できる。 プログラマーは激務なので、35歳を過ぎると体力低下のために続けられなくなる(体力低下説) プログラマーは常に新しい情報を吸収しなければならないが、35歳を超えると脳の働きが低下して新しいことを覚えられなくなるために続けられなくなる(学習能力低下説) プログラマーは35歳を超えると開発ではない業務を求められるようになるので、技術職としてのプログラマーのキャリアが途絶える(マネージメント原因説) 以下、ひとつずつ検証していく。 体力低下説 まず1つ目の「体力低下説」だが、これについてはそれほど深く考る必要がなさそうに思える。周知の通り気力や体力には個体差があり、若くても元気がないひともいれば歳をとっても元気なひともいる。また、35歳あたりの体力低下の原因としては、単純な加齢というよりも生活習慣の要因の方が大きそ

ヒビノケイコの日々。人生は自分でデザインする。 ３０代、移住13年。都会から山奥へ。ヒビノケイコの日々。 悩みながら成長し作ってゆく、新しいライフスタイル。 松下幸之助さんのことば 『私は貧乏で、体が弱くて、学歴がない(中卒)。　だから成功できた』パナソニックを一代で築きあげた松下さんの言葉にこんな言葉があります↑ ・貧乏だから→ハングリー精神が養われる。前に進もうと思える。 ・体が弱いから→体を大切にし、仕事を人に任せるようになる。 マネジメント力があがり、自分の役割に集中することにつながる。 ・学歴がないから→謙虚、素直な気持ちで人に聞くことができる。 一般的に負の条件といわれることを、こんな風にうけとめてこられたんですね。 「なんで、自分はこんなに不運なんだろう？」とか「自分は～だったからできないんだ」と考えるよりも、つねに今ある状況をふまえ「じゃあ、どうするか？」を考えてこられた方

柄にもなく健康の話をします。 去年の今頃は京都から東京に引っ越してきたところでした。まだはてなで働いていましたが、勤務形態は自宅からのリモートが主になっていました。週に6日は家から出ずに家でコードを書いていました。昼から早朝まで書いて昼からまた早朝までコードを書くような、ある意味規則的な生活です*1。 この間、生産性はかなり上がっていて、起きているときはもちろん、寝ている間も脳が活動を続け、睡眠中に考えたアイデアを唐突に起き上がってホワイトボードに書き込むみたいな状態でした。 しかし、1ヶ月くらいすると体調が悪くなってきます。なんか左脳の後ろ側が死んでるみたいな。 なんか脳が欠けてる感じがする— fukamachi (@nitro_idiot) January 12, 2014 あと心臓が異常にバクバクする。座るのもきつくなってくるのでだいたいダメ人間ソファに沈んでHHKB叩いてるみたいな

私は毎日、 Teamed.io で働くことに興味のあるプログラマから何通かメールをもらいます。彼らへの最初の質問は「あなたのレートは？」（ 当社は時給ベースで給与を計算します ）ということです。何より驚かされるのは、2つの方向性で、誤った試算をしているプログラマが多く見られるということです。 時給5ドルから500ドル（600円から60,000円）まで答えはさまざまです。決して否定はしませんが、私自身で代案を出してみます。このブログ記事では、どういった要素を計算に入れるか、または入れないかを述べたいと思います。私の個人的なキャリアもありますが、これが業界のスタンダードとは思わないでください。あくまで客観的で論理的だと思っていますが。それでは説明しましょう。 オープンソースへのコントリビューション ソフトウェア開発者にとってまずポイントとなり、かつ重要となる特性です。あなたはオープンソースプロ

フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発

転職・求人情報サイトのtype エンジニアtype 働き方 エンジニアのキャリアパスを再定義する新人事制度をビズリーチが導入――「現場かマネジメントか」で悩むのはもう古い？ ビズリーチCTOの竹内真氏 開発現場に留まり続けるか、それとも一線から退き組織のまとめ役に徹するか。 いまだ多くの日本企業には、一定の年齢に差し掛かったエンジニアに、「スペシャリストかマネジャー」かという二者択一を迫る風潮がある。そして評価の面でも、現場エンジニアよりマネジメント側に回った方が年収が高くなるように設定されているなど、「生涯現場」を貫きにくい環境が一般的だ。 だが、本当にエンジニアが組織で生きていく道はこの2つしかないのか？ 『ビズリーチ』や『careertrek（キャリアトレック）』といった転職サービスや、学習暗記帳アプリ『zuknow（ズノウ）』などを開発・運営しているビズリーチのCTO竹内真氏は、日