なぜエンジニアはマネージャーになるのに不安を覚えるのか - asken テックブログ
こんにちは。askenでエンジニアリング戦略や組織づくりを担当しているやすにしです。 マネジメントを中心にしておりまして、せっかくなのでブログでもマネジメントについて書いてみますね。 私はこれまでVPoEとしてエンジニア組織のマネジメントや、様々な会社でマネージャー向けにコーチング 1 をやってきました。そこで接してきたエンジニアリングマネージャーに共通しているのは「キャリアに悩んでいる」ということです。 例えばこのようなことです。 コーディングをしなくなり、技術的に取り残されて、エンジニアとしてやっていけなくなる感じがする 自分でやらないから成果が見えない。やっている感じがしない。 マネジメントをどうやればいいか、どう学べばいいかわからない。 マネージャーのキャリアで自分は定年（？）まで生きていけるのか？ 共通点は、色々理由を言葉にしているものの、どれもしっくりきている感じではなく、「な
「成果を出せば評価される」という考えが不幸の始まり 人事評価制度に不満の声が出る、必然の理由
人気シリーズ『図解 人材マネジメント入門』や『図解 組織開発入門』の著者であり、企業の人材マネジメントを支援する株式会社壺中天の坪谷邦生氏が、MBO（目標管理）をテーマとした新刊の発行にあたり、各界のエキスパートと対談を行います。第3回の後編は『最高の結果を出すKPIマネジメント』の著者である中尾隆一郎氏と、人事評価制度に不満が出やすい理由や、ハイパフォーマーを育てるマネジメント手法について語りました。 「成果を出せば評価される」という考えが不幸の始まり 坪谷邦生氏（以下、坪谷）：私はもともと人事制度のコンサルタントなので、KPIマネジメントと評価・報酬との紐づけが気になるんです。メールで「密結合ではなく、疎結合にしたほうがうまくいく」と教えていただいたのですが、もう少し詳しく聞かせていただけますか？ 中尾隆一郎氏（以下、中尾）：普通の人は、成果を出したら評価をされて、給料が上がって、昇進
提案を通せない人が押さえるべきビジネスパーソンの思考パターン3つ | BtoCマーケティング支援のホジョセン
ホジョセンは、よくセグメンテーションのお仕事をさせていただきます。消費者・生活者をいくつかのパターンに単純化することで、クライアントさんの戦略や行動の指針とするものです。マーケティングではSTP戦略のSにあたる部分ですので、ご存知のかたも多いと思います。 これを同僚に当てはめてしまえ、というのが今回のコラムになります。社内で自分の提案を通すためにはどのようなアプローチを取るのが効率的なのか、プロジェクトマネジメントを円滑に進める上でどうコミュニケーションをとっていけばよいか、と考えた上で編み出した単純モデルです。 いろんな方といっしょに働く中で多少のアップデートはしましたが、基本的には10年以上使っているパターンです。僕の(元)同僚の皆様は何度も聞いた話だと思いますが、ご了承ください。また、このモデルに落ち着くまでにさまざまな方からのフィードバックをいただきました。諸先輩方、元同僚の皆様に
自社の体制と自分流マネジメント概論 (Engineering Manager Meetup #5).pdf
Engineering Manager Meetup #5 の資料です
仕事と給与と評価の関係
ベイジで新評価システムの運用を開始するにあたって作った、仕事と給与と評価の関係を説明した社内向けのスライドです。会社や経営者によって考え方は変わると思いますが、できるだけ分かりやすく、一般化してみました。何かの参考になれば幸いです。
誰もマイクロマネジメントしたいわけではないだろう - jfluteの日記
何か理由があるんじゃないの？ マイクロマネジメントという言葉を聞くようになりました。 たぶん昔からあったと思いますが、jfluteはあまり馴染みがなかったのですが、昨今「自主的で自由な組織」を目指す会社も増えてきて、否定的な意味で利用される言葉として、よく聞くようになったのかもしれません。 「まあ、それはそれで良いことだなぁ」と思っている一方で、マイクロマネジメントという言葉が独り歩きしているように思うこともあります。 「何がマイクロマネジメントなの？」 「それはマイクロマネジメントなの？」 また... 「マイクロマネジメントはやるべきではないから、じゃあ全く何もやらない...で本当にいいの？」 というのを感じるようになりました。 またまた... 「マイクロマネジメントをやってる人は、本当にマイクロマネジメントをやりたいのか？」 そこも疑問に思うようになりました。誰だってやりたくないと思う
新技術導入を米国並みに！働き方を変えて生産性を高めるための８つの習慣 - メソッド屋のブログ
クロスカルチャーの専門家のロッシェル・カップさんと共同でマイクロソフトの投資の元作成した「働き方を変えて生産性を高める８つの習慣」だが、動画シリーズが完成したので、各習慣の動画をここで整理しておきたい。楽しんでもらえる内容になっているので、是非楽しんでご覧ください！また、すべての項目について、私が過去にこのブログで書いた、各習慣に関するポストへのリンクを整理しておいたので本ブログの集大成になっている。 元々本シリーズは、日本でも、DevOps や Agile を米国並みに実践したいという考えから考察されたものですが、働き方を変えて変化対応性と、生産性を向上させるためのもので、どなたにも楽しんでもらえる内容になっております。早速各習慣のビデオをご紹介させてください。それぞれ１０数分以下のサイズになっています。 序章：イントロダクション ８つの習慣をなぜ作成したのか？どういう効果があるのか？と
アジャイルな見積りと計画づくり：第1部：問題とゴール「２章 なぜ計画づくりに失敗するのか」まとめ - 基本へ帰ろう
個人的まとめ プログラミングを始めた頃に「顧客の価値は何か？」という問に対する意識をどのくらいしただろうか？与えられたタスクをこなし、それで満足していた頃があったのを思い出す。それが本当に価値があるものかどうかを知ることもなく。これはとっても怖いことだ。本当の価値とは何か？と言われると困るが、少なくとも顧客が喜ぶものでないといけない、何かを作り終えて、顧客が嫌な顔をしても、「言われたことをこなしたじゃないか」という文句では、プロジェクトの成功とは言えない。単なる作業ではなく「顧客・ユーザーが喜ぶ良いものを作ろう」と意識しないといけない。仕事とは他人のためにやることだ。それはプロフェッショナルとしての基本なのだけど、日々の忙しさもあって、つい忘れてしまうのではないだろうか。仕事とは他の人に役に立ってこそ仕事なのである。これを肝に銘じよう。 目次 なぜ計画づくりに失敗するのか フィーチャではな
朝会のパターン:立ってるだけじゃないよ - Martin Fowler's Bliki (ja)
以下の文章は、Jason YipによるIt’s Not Just Standing Up: Patterns of Daily Stand-up Meetingsの日本語訳である。Jasonの許可を得て、ここに掲載する。 立ってやるのはミーティングの時間を短くするためだ 朝会（デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル(訳注：ハドルとは群になって集まること)、朝のロールコール(訳注：ロールコールとはメンバが順番に答えていく方式)を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、その
Googleで生まれた「スプリント」――新規事業のリスクを減らし組織で学習する方法 | Biz/Zine
Googleで生まれた「スプリント」――新規事業のリスクを減らし組織で学習する方法 GV デザインパートナー / 「スプリント」の生みの親 ジェイク・ナップ氏 講演レポート 「スプリント」は、Gmail や Google Chromeなど様々なサービスの新規開発や改良に使われ、グーグル社内で浸透した後、ベンチャーキャピタルのGV（旧グーグル・ベンチャーズ）に取り入れられ、Slackやブルーボトルコーヒーなど100以上のスタートアップが実践する開発プロセスだ。その生みの親で元GVのデザインパートナーで、先日、IDEO客員研究員就任の発表があったジェイク・ナップ氏が来日した。当メディアでの連載も好評な池見氏が代表を務める株式会社groovesの主催にて、ジェイク・ナップ氏による講演とスプリントを体験するワークショップが開催された。ここでは、氏の講演の内容をお届けする。 “やってみないとわからな
「伸びる」仕事の頼み方 /how-to-request-work-to-grow
pmjpオフ会#8 での発表資料です。
どのようにエンジニアの目標設定を行うか - $shibayu36->blog;
以前 ゴールを決め目標を決める・解決案ではなく質問する - コーチングの学習で学んだこと - $shibayu36->blog; で、「ゴールを決め、現在位置とのギャップを考え、目標を決める」と良いということをまとめた。イメージとしては以下の図の通り。 しかし、前回の記事だと具体的にどのようにエンジニアの目標設定を行うかイメージが湧かない。そこで、もう少し具体的に最近どのようにやっていたかを書いてみたいと思う。 僕がメンティーと目標設定を行うときは、以下のフローを辿っている。 なんでも良いのでゴールのイメージを明確にする 現在の自分とゴールのイメージのギャップを考える ギャップを埋める目標を考え、アクションを定める ちなみに今回は、チームの成果達成のために個人の目標を決めるのではなく、エンジニアのスキル向上の目標を立てるという前提で書いていく。 なんでも良いのでゴールのイメージを明確にする
1on1ミーティングに備えるアンケート - しるろぐ
最近は、大体月一ぐらいのペースでメンバーと1on1ミーティングをするようにしている。 一人あたり30分から60分ぐらいで、前回のミーティングからの振り返りとその他相談を話す感じ。相談は仕事のことが主だけれど、プライベートな内容もある。 1on1ミーティングにあたって今年から事前アンケートを用意するようにしたのだけれど、そこそこいい感じに回っているのでまとめてみる。 事前アンケートを用意するメリット 話すことが事前に想定できる アンケート自体がアジェンダになるので、ミーティングがコントロール可能になる。 どんな話をするか分かっていると安心感もあるし、話が横道に逸れることもない（雑談は雑談で良いものだけど）。 その場で回答が思いつかなくて適当な返しになることがなくなる（お互いに） 自分の体験談なんだけど、何か質問をされたときにその場では「うーん、今は特に思いつかないです」と答えたのに終わってか
マネジメントスタイルの違いがもたらす「圧倒的スピード感」の違いと「楽しさ」 - メソッド屋のブログ
最近は、ソフトウェアの新しい技術や、考え方の日本に対する導入の遅れをどうやったら無くすことができるか？ということを考えている。今回はインターナショナルチームに参加して感じたマネジメントスタイルの違いについて書いてみたい。 海外企業のリーダーシップスタイルの変化 ソフトウェアの世界では、2001年にアジャイル開発が登場以来、それ以降のパラダイムでは、「サーバントリーダーシップ」と呼ばれるタイプのマネジメントスタイルが主流になっている。 従来型のスタイルは「コマンドアンドコントロール」というスタイルで、リーダーが部下に指示をし、リーダーは部下の状況を把握、確認し、管理していく。一方、サーバントリーダーシップの場合、リーダーは、ビジョンとKPIを示すが、実際にどのようにするかは、チームが自ら考えて意思決定していく。 この考え方は、既に1969年に発表されているらしいというのを下記の本で知った。
ウォーターフォールとアジャイルを考える - arclamp
初めて単独主催の勉強会をしました。ワークショップなので後半の1時間はディスカッションにしたのですが40人のわりには、それなりに面白い話ができた気がしています。資料とワークの結果、あとTogetterは以下から。 togetter.com 今回のプレゼンは純粋な「プロジェクトマネジメント論としてのウォーターフォールとアジャイルの違い」に絞った話をしたので、後半のワークが現実的な話になって面白かったです。話をしたのは以下のようなことです（資料の後半に細かいメモ書きがあります）。 そもそもウォータフォールは必要なのか？ とはいえ、ウォータフォールを採用しなくてはならない状況は？ なぜ、アジャイルを採用できないのか？ チームは重要だけど、どういうメンバーがいいのか？ アジャイルとはいえPM的な人が必要になることってあるよね？ アジャイルの立ち上げってどうするのがいいの？ 偶然、牛尾さんの 私は間違
1 on 1 で 何を話すのか？ マネージャ/ソフトウェアエンジニアの立場から - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
1 on 1 (ワンオンワン) とは1対1のミーティングの事。ここでは毎週もしくは隔週で行われるマネージャとその部下(direct reports)であるソフトウェアエンジニアの 1 on 1 に焦点をあてる。よく 1 on 1 で何を話したらよいか分からない。話題がない。と相談されるので僕の思うところをまとめてみる。 僕はマネージャもソフトウェアエンジニアのどちらも経験があるので両側からの視点を提供できると思う。 マネージャ編 マネージャは 1 on 1 を部下のために開催しなければならない。自分のための時間ではないことを肝に銘じよう。部下には話したいことを何でも話してもらう。事前に「1 on 1 は君のための時間だよ」と説明しておこう。 1 on 1 が始まったら「何か話したいこと、気になることある？」と問いかけよう。焦ってはいけない。じっくりと待ってみよう。 たとえマネージャとしてプ
リーダーとマネジメントの違いについて | oshiire*BLOG
よくまちがわれて使われているので、何か良い文句がないかといつも考えていたんだけれども、今日、紹介された本での説明が分かりやすかったので、それを紹介します。 そもそも、なんで区別しにくいのかってことを考えてみたんですけど、「リーダーシップマネジメント」や「マネジメントリーダー」のように、組み合わさった上、どちらも権限を持ったえらい人という、なんとなくの認識があるのだと感じます。 意味が分かった上でも、よく意味が分かんないですもんね、この言葉。 ひとまず、Wikipediaでも拾ってみましょうか。 まず、”リーダー“には「先頭となるもの」とあります。先頭に立って、牽引していくとか、引っ張っていくなど指していますね。集団を代表する人という意味もあります。このあたりから「えらい人」という何となく漠然とした意味として取りがちなんでしょう。きっと。 次、”マネージャー“です。「マネジメントする人」とい
【後編】苦労の先に掴んだものとは？メルカリ技術トップが20代の日々を赤裸々に語る
＜前編のあらすじと後編のお話＞ 小雨が降る中、本企画のホストである伊藤直也氏（以下「naoya」）と、現在『株式会社メルカリ』の執行役員であり、技術領域のトップとして活躍している、柄沢聡太郎氏（以下「sotarok」）。新卒で数年経験した後、起業し、CTOとして活躍し、その後、買収された経験も持つsotarok氏が、『メルカリ』にジョインする最大のきっかけとはなんだったのか？マネジメントをするうえで重要だと言われている「1on1」についての持論も展開されていくのであった―― ⇒【前編】の記事はこちら — naoya：ところで『クロコス』が『ヤフー』に吸収合併して、部長になったときはどんな感じだったの？ — sotarok：大企業の部長職って自分がプレイヤーではなくなって、本当にマネジメント職を究めるって感じでしたね。自分もマネジメントに意識して取り組むようになり、コーチングの研修とか、1o
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
フロー効率性とリソース効率性について #xpjug
開発組織マネジメントのコツ - Speaker Deck
