最初の100日で何をすべきで何をすべきではないか？｜miyasaka
人は無能に到達するまで昇進するという「ピーターの法則」というのがある。 「階層型の組織においては、どんな人も、昇進を繰り返すことでいずれは能力の限界に達し、十分に職責を果たせなくなって無能化する。その結果、「あらゆるポストは、職責を果たせない無能な人間によって占められる」という。 https://mba.globis.ac.jp/about_mba/glossary/detail-20919.html グロービスとくにリーダーが劇的な環境変化に異動、転職、抜擢で放り込まれるとこの法則が強烈に作用する。なぜなら周りの方が知識や経験があり自分がその組織内で最もそれがない人になってしまうからだ。一方で、この人は何かしてくれるのでは？という期待を関係者からは持たれる。「組織内で最も無能なのに最も期待される」という特殊状態を過ごすことになる。 12年ほど前に突然、社長をというキャリアチェンジを経験を
Engineering Manager の自己効力感下がりがち問題｜qsona
Engineering Manager という仕事をしていると、自己効力感が低下する瞬間がけっこうあると感じる。(多分 Engineering に限らない Manager 一般の話も多いと思うけど、ここではその考察はしない) 仕事において自己効力感が高まる状態というのは、たいてい、自分が何か努力して、それによって目に見える成果が出ているときに生まれるのではないかと思う。ところが、Engineering Manager の仕事というのは基本的に、自分以外のみんなが成果を出せている状態をつくることで、それにより絶妙なズレが生まれると感じる。 Engineering Manager の仕事を例にあげると、個々人のサポートをしたり、チームがうまくいくサポートをしたり、チーム間のコミュニケーションラインを整えたり、チームのはざまに落ちてるタスクを拾ったり、必要な人を採用したり、ビジネスや経営から求め
一部の関係者からしか見えない苦労について、せめて関係者からは労うこと - Tbpgr Blog
仕事の中には、業務を進める上で苦労を伴うことは多々あります。 一方で、その苦労の全てを関係者に共有できるわけではありません。 今回はそういった「見えない苦労」の存在や、それに対する労いの大切さについてまとめます。 見えない苦労 事例を挙げにくい面がありますが、例えば「人に関わる問題」など、一部の問題は発生したことを周囲に伝えない配慮が必要なケースがあります。 結果として、内部の関係者のごく一部しか問題の存在やそれによって必要だった苦労を知らない場合がありえます。 このような問題の存在は「マネージャー、リーダー、直接の関与者の一部」しか知らない状態になりがちです。 つまり「 見えない苦労 」になっているのです。 見えない苦労が見えないことによる影響 見えない苦労は直接関係している人以外からは見えません。 そのため、特にマネジメントに関わらなかったり、個別の担当業務外の組織改善等に関与しない人
管理や報酬と結びついた目標は“チート”を誘発する モラルを崩壊させない「目的ベースの目標設定」のやり方
NTT Comの技術顧問が「目標設定の基本」について講演する「エンジニアリングマネージャーと目標設定」。ここで株式会社アトラクタ Founder兼CTO / アジャイルコーチ兼NTT Comの技術顧問の吉羽氏が登壇。目標設定のやり方とその運用方法について話します。 「定量的に判断できる目標が良い目標」なのかはまぁまぁ怪しい話 吉羽龍太郎氏：さて、本題に入っていきたいと思います。今日はどういう方が（このセッションを）聞いているかはわからないんですが、目標設定の時に、特に上司の方からよく言われる話ってこういう話なのかなと思います。 「目標を設定する時は、達成できたかどうかを定量的に判断できるようにしましょう」。「定量的に判断できる目標が良い目標なんだ」と。（言われたことがある方は）リアクションとかで教えてくれるとうれしいです。 僕もいろいろな会社に勤めましたが、若い頃とかによく言われた記憶があ
「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」とか言うお前らに告ぐ
前提 この記事は内製開発をしているSaaSの中の人であるエンジニアが、SaaSの内製ソフトウェア開発をする上での話として書いています。 前ふり 「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」 「何が原因なんですか？どうすればいいんですか？」 という相談を受けました。 NDAを書いてから、どれどれとチームの状況を見てみました。 該当チームのスプリントゴール 該当チームのスプリントゴールはこんな感じでした。 QAフェーズのプロジェクトAを、QA作業を完了してリリースできる状態まで進める 実装フェーズのプロジェクトBを、フィーチャーの実装率を50%まで進める 設計フェーズのプロジェクトCを、要確認な点を除いて実装レディーな状態まで進める スプリントゴールが3つありますね。とても面白いですね。 思わずボンドルド卿みたいな反応をしたくなりますがここは先に進みましょう。
開発組織の貢献は売上として直接語るのはやはり無理があるのではないかという考察
先日サーバントワークスさんが公開した 計測によるスクラムチームのパフォーマンス向上 を読んで、 以前自分が書いた 開発の改善はKPIに翻訳しなければいけないのか をもうちょっと言語化することができそうだったのでメモ。 TL;DR 結論としては、開発の改善はKPIに翻訳しなければいけないのか でも書いた通り 開発組織はビジネスの実現を担っている職能であり、理想的には 「永久に持続性がある状態」で 「0秒 でしかも 並列数を無限」 でモノが実現されて、「不具合やパフォーマンスの劣化は 0」 であってほしい。もちろん現実世界ではどれも実現できないのでそこにいかに近づけるかということを目的に改善を実施すればよく、売上などのKPIに翻訳する必要性は必ずしもない から考え方は変わってないが、改めて整理して 開発組織は、Ability to Innovate と Time to Market 2つのケイ
リーダーとマネージャの違い - ツナワタリマイライフ
最近見たいくつかのツイートが自分の考えとちょっとズレがあったので考えてみる。 僕はリーダーシップを発揮することとマネジメントを行うことは別な仕事だと考えています。勿論、両方を同時に行える人が素晴らしい成果をだせるだろうという事に異論はありませんが、マネジメント業務からリーダーシップの発揮を少し外してはどうだろうかと考えています。— 太一 (@ryushi) April 16, 2023 例えば、チームビジョンを策定し、それに向かってメンバーを鼓舞するといったような仕事は、マネジメント業務から外してもいいんじゃないか？というのが僕の意見です。— 太一 (@ryushi) April 16, 2023 見つけられなかったのだけど、 マネジメントは欠けている要素を増やす、リーダーは目標を決めてチームを前に進める、やることを減らす、なので本来真逆である、みたいなやつ。 こういうのもか。 組織を成功
リーダー＆マネージャーのためのモブプログラミング / Mobprogramming for managers and leaders
プロフィールやお問い合わせはこちらからどうぞ！ https://agile-monster.com/profile/ https://agile-monster.com/contact/
【資料公開】マネージャーのしごと
みなさんこんにちは。@ryuzeeです。 2022年12月9日に行われたイベント「Developers CAREER Boost」の登壇資料を公開します。 今回は、「マネージャー」と名のつく職種を分類して、それぞれの職務や定義を確認した上で、有効なマネージャーであるにはどうしたらよいかを整理してみました。 資料を作るにあたって、過去の日記を読み返したり記憶を思い起こしたりして、当時の活動や出来事、悩みを整理してみたのですが、自分はやっぱりマネージャーに向いていないし志向していないことを再確認できました（笑）。 全員がマネージャーにならなければいけないなんてことはなく、自分が日々楽しく過ごせるキャリアを選択すればいいと思いますが、資料が少しでも役に立てばうれしい限りです。 本セッションで紹介した書籍は以下のとおりです。 エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーに
エンジニアマネージャー必見：報酬設計の考え方 - Qiita
エンジニアの採用はすごく難しい状況です。エンジニア採用ニーズが多いのに、エンジニアがやる仕事の内容も難しくなってきており、幅も広がってきています。CTO自らが真剣に向き合って考えていく必要があります。 そして、せっかく採用したエンジニアには、長く働いて欲しい、仲間として最高のパフォーマンスを出して欲しいと思います。そのため報酬設計は重要な部分となります。 報酬設計の２つの側面 １．外的報酬 外的報酬といえば、賃金、給与が先ず思い浮かびます。その他にはポジション、地位も報酬の一つと考えられるでしょう。部長や本部長等の役職がつくと社外で名刺交換した時にも見栄えが良くなります。 他にも手当てや秘書がついたり、経費の枠が増えたりと色々とあると思います。 ２．内的報酬 仕事そのものやりがい等です。楽しい仕事と思えていればやる気も湧いてくるし、難しいと思うとやり甲斐を感じる人もいます。エンジニアの場合
目標設定にもアジャイル思想を！複数の目標に対する向き合いかた | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]
目標設定KPIKGIMBOOKRアジャイルSMARTの法則 こんにちは、たむらです。今回は、目標設定に関するお話です。 皆さんの会社では「目標設定」がありますか？また、それにどの様に取り組んでいますか？評価に係わるから頑張ろうと思う人もいれば、毎年目標設定を憂鬱に感じる人もいるのではないでしょうか。 今回は、会社の目標そのものを分解しつつ、会社の目標や自身の目標にどの様に取り組んでいけば良いのかを考えてみたいと思います。 会社でよくある目標設定 デファクトスタンダードなMBO さて、企業の目標設定というと、MBO（Management by Objectives）がまず真っ先に出てくるかと思います。P・ドラッガーが提唱した手法で、「マネジメント層からの指示ではなく、自己管理によるマネジメント」により業務の効率化・利益の向上といった会社のニーズ達成と、従業員の能力・モチベーションの向上の両取
![目標設定にもアジャイル思想を！複数の目標に対する向き合いかた | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/7edc3c2e025ee4a2ffc74dcfccbb8c2dca87dd0e/height=288;version=1;width=512/https%3A%2F%2Ftechblog.raccoon.ne.jp%2Fwp-content%2Fuploads%2F2022%2F10%2Fs_FRS310237-e1666657157259.jpg)
“細かすぎるリソース管理”が「いかにメンバーに空きを作らせないか」という思考の原因になる プロジェクトマネージャーが陥りがちなアンチパターン回避法
アンチパターンその2 「細かすぎるリソース管理」 西郷智史氏：アンチパターンの2つ目は、細かすぎるリソース管理です。先ほど、計画の時にもリソースというキーワードが出ましたが、みなさんはリソースの管理をどのようにしているでしょうか？ よくあるのが、日単位・時間単位でリソースの負荷調整を詳細に行うこと。IT業界でよくやっています。「何にどれぐらいの時間を使ったの？」と後で集計して、この人は設計や会議、管理などにどれぐらいの時間を使っているのか、そういった細かい管理をするケースがあると思います。 （スライドを示して）「Let's Check」の1つ目を見てください。例えば、「Aさんは、Xというプロジェクトに0.5、Yに0.3、それ以外に0.2の割合でアサイン」と、小数点を用いてリソース負荷を管理しているケースはないですか？ マネージャーはよくこのようなことになりがちです。 あとは、すべての負荷が
才能が集まる会社、逃げる会社｜長村禎庸@EVeM
ベンチャーは、いつだって1人の才能が切り拓くプロローグとして、ある出来事について書かせてください。 以前、弁護士ドットコム株式会社代表取締役の内田さん（現取締役会長）、同社専門家プラットフォーム事業担当取締役の田上さん、クラウドサイン事業担当取締役の橘さんに、それぞれマネジメントトレーニングをさせていただく機会に恵まれました。 田上さん、橘さんはお2人とも弁護士資格をもつドメインエキスパートであり、大きな事業を背負う事業家であり、強烈な個性をお持ちの役員です。 「内田さんのおっしゃる通りでございます、仰せの通りにmm」 そんな役員像とは程遠く、時に内田さんに反発しながら、強烈な個性から来る独自の考えでどんどん事業を前に進めます。そのようなお2人を見て、ある時内田さんに尋ねました。 長村「田上さん、橘さんともに強烈な個性をお持ちで、一言で言えばカリスマ経営者だと思います。しかし、内田さんとし
Web開発版「手が遅い」ことへの処方箋（手付け、手戻り編）
これを読んで欲しい人のターゲット像や前提について Web版開発の話をしています ITのソフトウェアエンジニアの話をしています ある程度チームのやり方に対して影響を与えられる権限がある人 マネージャーかメンバーかはあまり気にしないです 「発言するのは自由だが聞き流されるだけ」ならこの記事を読む意味はないです ある程度裁量権があり、ビジネスサイドとも話ができるチームのメンバーを想定しています 作業の流れの前提について チケットがあって 作業者がそれを取って（自分で取るのか他人にアサインされるのかは問わない） PullRequestの形でレビュー依頼をかけてレビュワーがレビューする OKならmergeしてそのうち本番デプロイ 間にQAが入るかもしれないけどそこは問わない 手が遅いとは何か？ ある作業者のサイクルタイムが他の作業者に比べて長いこと 100の大きさの作業があるチケットを渡した際に、ほ
リクルートでも「Will」が書けずに悩む人もいる 取り組みたいことに縛られる“Willの神格化”からの脱却
人気シリーズ『図解 人材マネジメント入門』や『図解 組織開発入門』の著者であり、企業の人材マネジメントを支援する株式会社壺中天の坪谷邦生氏が、MBO（目標管理）をテーマとした新刊の発行にあたり、各界のエキスパートと対談を行います。第6回の前編では、株式会社リクルート 人材・組織開発室室長の堀川拓郎氏と、強みを生かし合う「リクルートのフィードバック文化」について意見を交わしました。 リクルートが目指す人材・組織のありたい姿の変化 堀川拓郎氏（以下、堀川）：どうもです、よろしくお願いします。 坪谷邦生氏（以下、坪谷）：よろしくお願いします。今回の対談のきっかけは、私がTwitterで発信した『図解 目標管理入門』の図が、リクルートで堀川さんが取り組まれていることに近いと、リツイートいただいたことでした。 ※坪谷邦生氏『図解 目標管理入門 マネジメントの原理原則を使いこなしたい人のための「理論と
人材マネジメント🤯 | POSTD
初めて会社を起業する人のほとんどは、集団をマネジメントする方法を学ぶ間に、創業当初の従業員を燃え尽き症候群にさせてしまうと思います。 筆者のアドバイスがそのようなケースを減らせるなら、ここに書いておく価値があるでしょう。 筆者は小規模なチームやスタートアップ企業のマネージャーのためにこの記事を書きました。 ほとんどのアドバイスは、大規模な企業のマネジメントには当てはまらないのではないかと思います。 なお、急成長している企業に入社する人への全般的なアドバイスについてはこちらをご覧ください。 筆者について 中・小規模のエンジニアリングチームを数チーム管理した経験あり On DeckのCTO CoinListの元エンジニアリング担当VP AngelListの元リモート責任者 Product Huntの元CTO それでは始めましょう。 マネージャーはすべての失敗に責任を負う 分かります……とても前
「プレイヤー適性とEM適性は絶対に違う」 3社のCTOとEMが考える“マネージャーに向いている人”
CTOやEMの人が思う、理想の組織と現実のギャップ 屋代昌也氏（以下、屋代）：ほぐれてきたところで次のトークトピックに移ろうと思います。次のトークトピックは、「CTOやEMの人が思う、理想の組織と現実のギャップとは」です。事前にみなさんに回答をもらっています。そこに対して質問したいことももらっていたので、まずはみてねさんの話をうかがいたいと思います。 酒井篤氏（以下、酒井）：理想の組織は、単一責務の原則を当てはめて考えます。自分はプログラミングをする時とあまり変わらない脳の使い方をしていて、プログラミングをする時には単一責務の原則を意識しています。 理想的には、1人のメンバーや1つのチームがあまりたくさんの役割を持たずに、シンプルな目標の中で邁進していくのが一番やりやすいと思っています。しかし、それにはたぶん人が無限に必要だし、本当に線引きできない仕事がたくさんあるので、その中でどううまく
部下は自分の仕事を減らせない、「削る」意思決定こそ上司の仕事
「新しい取り組みを部下に任せているが、思うように進まない」という悩みを持つ人は少なくないでしょう。やる気があり頑張っているにもかかわらず成果を出せていない場合、「頑張っているからこそうまくいかない」という落とし穴に陥っている可能性があります。 一体どんな落とし穴なのか、落とし穴に陥らないようにどう手助けすればよいのか。今回はそれを解説します。 やる気があるのにうまく進まない理由は？ やる気のある人が陥りがちなのは、大きな期待に応えようと、あれもこれも同時並行で手を出してしまうことです。期待が大きければ大きいほどすべきことは増え、手掛ける範囲も広がります。結果として広く薄く手を出すことになり、進捗も芳しくなくなります。 新しい取り組みでは多くの場合、短時間で成功の糸口を見つけることが求められます。広く薄く手を出すのは賢明な方法とはいえません。 こうした落とし穴に陥った部下に対して上司がすべき
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
何のための個人目標設定？
会議で、社員全員に資格取らせるかという話が出た。それなら社長含めた経営陣も全員取るべきでは？となる。→社長「頑張って取ってきた」とtweet
