人は無能に到達するまで昇進するという「ピーターの法則」というのがある。 「階層型の組織においては、どんな人も、昇進を繰り返すことでいずれは能力の限界に達し、十分に職責を果たせなくなって無能化する。その結果、「あらゆるポストは、職責を果たせない無能な人間によって占められる」という。 https://mba.globis.ac.jp/about_mba/glossary/detail-20919.html グロービスとくにリーダーが劇的な環境変化に異動、転職、抜擢で放り込まれるとこの法則が強烈に作用する。なぜなら周りの方が知識や経験があり自分がその組織内で最もそれがない人になってしまうからだ。一方で、この人は何かしてくれるのでは？という期待を関係者からは持たれる。「組織内で最も無能なのに最も期待される」という特殊状態を過ごすことになる。 12年ほど前に突然、社長をというキャリアチェンジを経験を

あの頃の俺に伝えたい内容を雑に書く。 本を読め お前が困ってることはたいてい先人の知恵によって体系化されている。経験から学ぶことも大事だが、歴史から学ぶことを常に継続しろ。 他社のマネージャーと話せ 社内のことで手一杯なのはわかるが、思った以上に視野が狭くなっているぞ。社外の人間と話すとそれに気づくはずだ。緊張を乗り越えて直接声をかけたりイベントに出向いたりしてみるといい。思考が整理され、きっと解決の種が育つ。 引き出しを増やせ マネジメントは成長がわかりづらい。不安になったらマネジメントの引き出しを増やすことに集中しろ。メンバーへの物事の伝え方、意思決定の前の整理の仕方、やり方は無数にある。何個違うやり方にチャレンジできたかを数えてみるといい。 どこで成果を出すかを決めろ 自分の期待は自分で合わせろ。やること、やらないこと、頼りたいことを明文化しないと全てが自分の責任のようにすれば感じて

組織の中で何らかの歪みを感じる時、その根っこにはある人が関係する物事について「わからない」「知らない」という感覚があることが多い。 例えば「なんでこんな非論理的な意思決定するのか。アホじゃないのか」と感じた時、本当にアホなこともあるかもしれないが、判断材料となる情報が正しく伝わっていなくてそう感じるだけということも多い。1対1で色々聞いていくと「なるほど、たしかにそれならそうなりますね」と納得できるのに、情報が欠落しているだけで不和を生むのだ。 情報だけではなく、人格も同じである。仲のいい人から言われる冗談は笑ってやりとりできても、よく知らない人から同じことを言われると嫌な気持ちになることもある。 組織において、こういった「わからない」が積み重なると雰囲気が悪くなっていく。「あのチームは」「あの人は」といった形でわからないものを自分とは違うものとして表現して、一体感がなくなるのだ。なんだか

ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話（前編） アジャイル開発の代表的な方法論であるスクラムをテーマに、都内で1月に開催されたイベント「Regional Scrum Gathering Tokyo 2024」で、経験豊富なアジャイル開発のエキスパートとしてウクライナを拠点にアジャイルコンサルタントをしていたドミトロ・ヤーマク（Dmytro Yarmak）氏が、ロシア軍の侵攻後にウクライナ軍に入隊し、中隊長としてリーダーシップを発揮するためにさまざまなメソッドを駆使して軍隊の組織を変革していった経験を語ったセッション「A True Story of Agile Coaching in Ukrainian Armed Forces」が行われました。 軍隊という、企業とは異なる構造や目的を備えた組織で、しかも多くの民間人が入

意思決定の場にいない人に対して決定事項を共有する際、いくつか気をつけておくといいなぁと考えていたことを雑にまとめておきたい。 決定する前から進捗をちょっとずつ共有しておく 決定前の話なので後の祭りかもしれないが、いきなり結果をドーンだと相手を戸惑わせることがあるので事前に議事録を共有したり中間で説明する機会を作ったりするとよい 背景と前提条件を伝える なぜやるのかわからないまま結果だけ共有すると納得してもらいにくい。決定する上での前提条件を知らないと余計な反発をうむこともあるので注意が必要。それまでずっと考えてきた当事者は気づきにくいが、びっくりするくらい前提知識が違うことがある。相手は何も知らないものとして、イチから説明した方がよい 決定までの経緯を伝える 結論より経緯の伝え方が重要。どのような議論があってそんな決定になったか、完結に伝えましょう 捨ててきた選択肢も伝える 結果に至るまで

あなたは町のパン屋さんである。以前は都会でエンジニアとして働いていたのだが、やむを得ぬ事情で郷里のパン屋を継ぐことになった。店は昔ながらの商店街にあり、店の奥では職人が小さな工場（こうば）でパンを焼いている。ところで、地域のチェーンストアからサンドイッチ製造の仕事を依頼されたのだが、受けてみたら大変な仕事だった・・という事情までは、前々回の記事「下請け型受注生産という日本的形態を考える」https://brevis.exblog.jp/28051644/ に書いた通りだ。 何が大変かって？　チェーンストアは、コンビニの向こうを張って、いわゆる「JIT納品」（ジャスト・イン・タイム納品）を要求してくる。1日4回、FAXで注文が来て、2時間以内に納品しなければいけない。おまけに製造後6時間以内の品であること、という鮮度指定もついている。ところが注文を受けてからカツを揚げてサンドイッチを作ってい

まず最初に、この記事の結論を書いてしまおう。 それは、「社員の離職を防ぎたいなら社員の成長を求めるな」だ。 最近は「ひとつの企業にしがみついていては先がない！」という主張が広まり、副業や兼業が推進され、リスキリングという言葉もよく聞くようになった。 個人個人が自分のキャリアに向き合い、企業はそれを支援すべしーー。 そんななかで「社員の離職を防ぎたいなら社員を成長を求めるな」というのは逆張り甚だしいが、それにはちゃんと理由がある。 「よく働く層」を雇い続けるのはむずかしい 働きアリの法則をご存じだろうか。 集団のなかには、よく働くアリが2割、普通に働くアリが6割、働かないアリが2割いる。 たとえ100匹のアリのなかからよく働くアリのみを20匹集めたとしても、そのなかでも結局4匹はよく働き、12匹は普通に働き、4匹は働かなくなるという法則だ。 企業のなかでいえば、モチベが高くより大きな成功を求

テックタッチのエンジニアリングマネージャー堀内です。 テックタッチに入社して以来、職場の心理的安全性が非常に高いと感じています。 私は数社を渡り歩いてエンジニアリングマネージャーを 10 年以上経験していますが、このような組織に出会ったことがありません。 この記事では心理的安全性が高い職場の内側はどのようになっているのか、そしてどのように作られているのかを具体的に解説します。 現在の職場で心理的安全性をどのように作れば良いか悩まれている人や、テックタッチの職場をもっと知りたい人の参考になれば幸いです。 テックタッチのストレスの低さはトップクラス テックタッチは 2023 年 8 月にドクタートラスト社実施の「ストレスチェック」で 957 社（約 21 万名）中 2 位を獲得しました。 職場環境指数で偏差値 91.6 と評価されています。 職場環境優良法人として957社中 2位を獲得！ この

人の一生は重荷を負うて遠き道を行くがごとし、とは徳川家康の言葉らしいですね。この記事では人生という旅路を振り返ること無く歩んでしまうと自己成長と健康に良くないので、ちょいちょい振り返りをするといいですよ、そのためにはコーチングというものを知っておくと捗りますよ。という話をします。 エンジニアにとって振り返りというとポストモーテムのイメージがあるかもしれませんが、今回対象にしているのは個人の活動に対する組織的な振り返りのことで、人材育成の文脈でフィードバックと呼ばれるものです。目標管理（MBO-S）とかOKRとかもこれに含まれます。 読み手としてはマネジメントも想定しますが、どちらかと言えば新社会人ないし組織運営の観点を補強したい方に向けています。コーチングは「コーチングのしかた」という技法も重要ですが「コーチングというものがあるのだ」という認知もまた自己成長と健康に役立つと考えています。よ

この記事は SmartHR Advent Calendar 2023 2nd の12日目の記事です。 こんにちは、SmartHRでプロダクトエンジニアをしているytakaです。 この記事では、チーム間のコミュニケーションにおける、シンプルかつ強力な手法をご紹介します。 それが「ただ話す」です。 ただ話す 「ただ話す」は、チームの輪読会で読んだ『大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法』にて紹介されていたメソッドです。本書には以下のように記載されています。 大規模なグループで何年も働き、複数チームにまたがる調整テクニックを数多く観察した結果、最も上手くいきそうなテクニックを発見しました。手順は次の通りです。 (1) あなたは、チームBとの”調整が必要”なことに気づきます。 (2) 立ち上がって、 (3) チームBのところに歩い

先日、『質の高い課題解決できる人が「こうすべき」を主張すべきだけど、それが苦手な人も多いからチームで解決したら良いのでは』という雑な考えを書いたのですが、僕のブログにしては多くの人に読んでもらえました。 読んでくれた人、ありがとうー fujii-yuji.net ただ、この記事へのコメントで「質の高い決定ができない上司や社長はダメだろ」みたいな意見もそれなりに多くあって、けっこう驚いたのですよね。 僕が雑に書いたわかりにくい文章だったことが原因で誤解されてしまったのでしょうけれど、今日は補足として「部下がやれることを上司もやれる必用はないですよね」的な話を書きます。 上司が「自分ではできないからお前に頼むわ」と言ってくれたお陰で、"上司のして欲しいこと探し"をしなくて済んだ。 僕が若いころお世話になった上司はよく「自分ではできないからお前に頼むわ」と言っていました。 実際のところ、その上司

1. はじめに ソフトウェア開発のチームに、新しいメンバーが入ってくることはよくあります。 以前に新卒社員がチーム入ってきた場合の育成方法を紹介しました(こちら)。 今回は、新卒社員ではなく、他の会社から中途入社か同じ会社の部署異動で来る新メンバーの話です。 (エンジニアが数百人などで規模が大きい会社の場合、部署が違うと仕事のやり方が全く変わる場合があるので、今回は中途入社と他の部署からの異動を同じように「新メンバー」として扱います) 会社や部署が変わると仕事のやり方が大きく変わるため、仕事のやり方に戸惑うことが多いと思います。 本稿では、そのような「新メンバー」を活躍しづらくしてしまうアンチパターンとその対策を紹介します。 2. 中途入社や部署異動で来た新メンバーが適応することの困難さを理解する 中途入社や部署異動で来た新メンバーが組織に適応することは、新卒社員のそれとは別の難しさがあり

Autonomous Database - Dedicated 技術詳細 / adb-d_technical_detail_jp

9割シリーズ この記事は、けっこう前にClassiの社内ブログ記事として書いたものだ。一般論として通用する内容だし、社内に閉じておくのはもったいないと思ったので転載する。 プロジェクトの成功は、キックオフの成功にかかっています。なぜなら、キックオフとはプロジェクトの出発点であり、そのキックオフの準備こそがプロジェクトを始める準備であるからです。 準備に失敗することは、失敗する準備をしているようなものです。 https://www.atlassian.com/ja/work-management/project-management/project-kickoffプロジェクトのキックオフの目的プロジェクトキックオフとは何ですか? それは、プロジェクト チームの...最初のミーティングです。このミーティングは、共通の目標とプロジェクトの目的を確認するための機会です。 キックオフミーティングなし

言った人と聞いた人の認識がずれやすい言葉というのがあると思っていて、その話を雑に書いておきたい。 自分はこれらを"要注意ワード"と呼んでいて、出てきたら真意を確認するようにしている。無意識的にやっている人は結構いると思うので、同じような"要注意ワード"の知見吸いたい。 リスク 「リスクがある」と言われたときは、何のリスクのことを言っているかを確認している。 たとえば何かの開発を1週間後にリリースしたい、と言った時に「いやーこれは結構怖いしリスクありますよね」みたいな話になったとする。ここでいうリスクは何を言っているのだろうか。なんとなく品質が担保しきれないリスクのことを言っているような気がするが、実は間に合わないかもしれないことをリスクと言っているのかもしれない。あるいは、チームメンバーのモチベーションが下がることをリスクと言っている可能性もある。 何のリスクのことを言っているのかすり合わ

最近zatsuを書いてなかったので、「理想のOKRとは何か」をハンターハンターを例にして書く。必要な前提知識は8巻にある。 高いObjectiveの設定とは何か クロロ「全部だ」「地下競売のお宝 丸ごとかっさらう」 8巻 P152~153 これが高いObjectiveの設定である。 戦略発表前にはメンバーは「どこ狙うと思う？あたしは古書全般だと思う。団長本好きだし」「違うね。きとゲームね」などと色々な予想をしていたが、それをはるかに超えた目標を掲げている。そう 「全部盗む」である。 OKR シリコンバレー式で大胆な目標を達成する方法では、『Objectiveは達成確率が60〜70%程度になるくらいの高い目標を設定せよ』とあるが、このクロロのセリフはまさにそれだと言っていい。 合意のプロセスとは何か OKRの運用において一番大事なのは、所属するメンバーとそのObjectiveについて話して納

何かを決めるゴールを設定した会議において難しいのは、議論を収束させていくフェーズである。 議論の抽象度の高さによって難易度は変わるが、収束させるにあたってここは抑えておくとよいみたいなTipsはあると思うので書き出してみる。 決めることがゴールという認識を合わせる そもそも決める場だという認識が揃っていないと収束させるのが難しい。会議のフォーマットに目的やゴールを明記しておくとよい 最終的な決め方を決める 最終決定者、時間、多数決などなんでもいいが、最後にどう決めるかを決めるのが大事。できれば議論が始まる前にやっておくと、議論中もそれを意識して進められるのでやりやすい 決めるための材料の認識を合わせる 判断軸とも言える。議論が何かうまくいかない時にはだいたいこのへんの認識が揃っていない。言葉に対する認識が揃っていないこともあるので齟齬をなくしておくの大事 決めるための材料を今揃えられるかを

チームの方針を伝えたはずなのにうまく伝わっていないということはよくある。そういう時、「前にも言いましたけど」みたいな話をしだすと不幸にしかならない。情報のやりとりは伝える側と伝えられる側双方の協力が不可欠だが、コントロールしやすいのは伝える側である。方針が浸透していない時に確認したいチェックリストを雑にまとめておく。 理解してくれているか 同じ言葉でも認識が違うことは多い 特に方針はキャッチーな表現を使って抽象度が高いこともある 具体も伝えて理解しているかどうかを確認すること 納得してくれているか 意義を感じていないと浸透しない 説明する側が納得していることはもちろん、納得させられるまで話すこと 方針の背景や議論の流れ、最終決定事項までアクセスしやすくして個々人が自律してキャッチアップできるようにしておくことも重要。いわゆる情報の透明性、フラットさ どちらかに決めて進む必要があることも多い

7月にEMをやめたのだけれど、実は最近マネジメントロールに戻った。 1on1などで自分や組織の至らないところについてメンバーから率直なフィードバックをもらうことが多く、そのたびに本当にありがたいと思っている。ちなみに最近もらってよかったフィードバックは、「ハレーションを恐れすぎ」です。 メンバーからのフィードバックは受け手のスタンスや振る舞い次第で何も言ってもらえなくなったり信用をなくしたりすることもあるので、「メンバーからのフィードバックに向き合うとはどういうことか」を雑にまとめておきたい。 フィードバックをもらうまで フィードバックを受け付けていることを伝える 言いにくい話も多いので、スタンスを明確に伝えておかないとフィードバックはもらえない 予定が詰まっていると遠慮されてしまうので「予定は調整するのでいつでも声をかけてほしい」と伝えるとか 意見を持ってそうな人には直接声をかけるのもよ

自分が会議を設定する時は必ず決めていることがある。 と言っても、そんなに特別なことはない。2点守るだけだ。 アジェンダとたたき台を用意する 予定の時間は厳守 アジェンダは、GoogleDocsで作っておく。 項目は会議によって少し変えたりするけども、だいたいこんな感じ。 参加者 資料 目的 ゴール 注意点 たたき台 目的とゴールとたたき台が重要。 目的が明確じゃない会議は要らないので、そこを箇条書きで整理して最初に伝えるようにしている。 ゴールは目的と似ているが違う。ゴールは、これが達成できたらこの会議は成功だよという指標になる。 ゴールが明確じゃないと会議がダラダラしてしまう。目的を具体化して会議で到達するべきラインを明文化したものがゴールという感じ。 注意点には、進行しやすくするための工夫を書く。例えば、今回はこういう面からの指摘はいったんナシでお願いしたいとかそういうことを書いておく