半導体は原料となるシリコン素材を「砥石で削り、磨き、切る」工程を経て作られます。この工程で使用される砥石と工作機器を生産し、全世界の約75％ものシェアを獲得しているのが、日本の「ディスコ」です。そんなディスコで働く従業員には指示を出してくる上司がおらず、意思決定は「Will」と呼ばれる社内通貨システムで決められます。 Can you run a company as a perfect free market? Inside Disco Corp https://www.ft.com/content/c04389a3-c672-43ce-8d9e-724668c0e490 ディスコは約7000人の従業員を抱える創業87年を迎える企業で、世界中の半導体の切断・研磨・ダイシングに使用される機械の約4分の3を製造しています。 そんなディスコでは会社専用アプリがあり、このアプリを通じて従業員は日々

編者を担当した電子書籍『技術リーダーシップのための14のヒント』が、2025年5月1日にオライリー・ジャパンより刊行となりました。オライリー・ジャパンさんのサイトから無料でダウンロードいただけます。 技術リーダーシップのための14のヒント - O'Reilly Japan 本書は、Roy Osherove著『Elastic leadership : growing self-organizing teams』（Manning）の翻訳書籍として2017年に出版された拙訳『エラスティックリーダーシップ : 自己組織化チームの育て方』（オライリージャパン）に、日本語版特典として収録させていただいた日本人執筆者による14のエッセイ部分を、独立した形に再編集したものです。 リーダーに求められる立ち振る舞い、コミュニケーションや情報共有をリードする方法、リーダーと開発者の兼任、チームメンバーが自己組織

記事AI要約 スクラムマスターとしての成功にコミュニティ活動はなぜ欠かせないのか——天野氏と川口恭伸氏による往復書簡では、この問いを実体験から掘り下げます。両氏はコミュニティでの活動が単なるネットワーキングではなく、組織変革に必要な「場づくり」の実践そのものだと論じます。川口氏は「押しつけない」「よいやり方を共有する」というコミュニティ運営の哲学を語り、天野氏は「原動力になり場を作る」「創発的やり取りを最大化する」「貢献に感謝する」という3つの柱を提示。『伽藍とバザール』や『Fearless Change』のパターンも引用しながら、コミュニティ活動が培う「感覚的な学び」こそが組織にアジャイルな文化を根付かせる土壌になると結論づけています。最後に読者へ、コミュニティ参加から社内実践への具体的な橋渡し方法を提案しています。 「組織の中でスクラムマスターとして成功するために、コミュニティ活動は必

2025年1月25日、野中郁次郎先生が逝去された。私は、先生とアジャイル開発のScrumの創始者の一人である Jeff Sutherland を引き合わせた一人であり、また、先生と共著で『アジャイル開...

わいわい🙌 2025年3月26日に新刊が出ます！ 基本的な情報 書誌情報 本書の概要 日本語版訳者あとがき全文掲載 訳者あとがき 謝辞 関連する講演 ハイジの基調講演＠Regional Scrum Gathering Tokyo 2024 大友さんの講演＠Scrum Fest 仙台 2022 ダイアナの基調講演＠Regional Scrum Gathering Tokyo 2022 まとめ 基本的な情報 書誌情報 タイトル：ダイナミックリチーミング 第2版 ―5つのパターンによる効果的なチーム編成 著者：Heidi Helfand（ハイジ・ヘルファンド） 訳者： 永瀬 美穂（ながせ みほ）、吉羽 龍太郎（よしば りゅうたろう）、原田 騎郎（はらだ きろう）、細澤 あゆみ（ほそざわ あゆみ） 出版社：オライリー・ジャパン 発売日：2025/3/26 単行本（ソフトカバー）: 320ページ

ぼくはAmazonのシアトル本社でセールの機能を開発している。Amazonでお買い物をしていると「30%引き」や「20%オフ」のようなディスカウントを発見して喜んでくださっている方もいると思うけれど、あのディスカウントを提供する仕組み自体が一つの大きなプロダクト（システムと言ってもいいかな）になっている。そしてそれを支えるためにシアトル、バンクーバー、ベルリン、バンガロールにまたがるグローバルなチームによって開発・管理している。 そんなわけでぼくはPM (プロダクト・マネージャー) として日々セール機能に関するプロジェクトを回している。たくさんの刺激的で興味深いプロジェクトに恵まれてきたわけだけど、その中で一つとても記憶に残るプロジェクトがあった。 それは「定期おトク便」に関するものだ。定期おトク便というのは、平たくいうと日頃からリピートして買う商品（例えば飲料水や洗剤のような日用品）につ

「世界初のwiki」ことWikiWikiWebで、目に見えやすい目標を安易に設定したことにより本末転倒の結果を招いた事例として、旧ソビエト連邦の靴工場のエピソードが紹介されています。 Soviet Shoe Factory Principle https://wiki.c2.com/?SovietShoeFactoryPrinciple WikiWikiWebの「ソビエト靴工場の原理」の記事によると、ソ連の靴工場には生産ノルマがあり、生産量を増やすようにとの圧力がかけられていたとのこと。しかし、工場は慢性的な材料不足に悩まされていました。 そこで、工場は必要な材料が少ない子ども用の靴の生産量を増やしました。その結果、工場は書類上の生産ノルマを達成したものの、大人用の靴、特に大きいサイズの靴がひどく不足することになったと言われています。 子ども用の靴ばかり作られるのを防ぐためにサイズ制限を設

グーグル（正確にはその親会社のアルファベット）は2023年1月、約1万2000人をレイオフする長期計画を発表しました。これは、全従業員の6％に相当する数です。 グーグルの幹部が「従業員は我が社のもっとも大切な財産です」というようなことを言っているのを聞いたら、そのあまりの言行不一致ぶりに目を剥いても無理ないでしょう。 しかし、同社が従業員をもっとも大切な財産と考えていることは確かなのです。 グーグルの人事部門は長年にわたり、従業員の職場での生活に関してありとあらゆる側面を分析し、生産性やイノベーション、エンゲージメントの向上に取り組んでいます。 その一例が今回紹介する「最高のチームをつくる方法」の分析です。 グーグルも大半の企業と同様に、賢く、創造性が高く、努力をいとわない人たちを雇っています。それでも、会社で成果をあげる人がいる一方で、なかなか成果を出せない人も存在します。 賢く、創造性

はじめにクレディセゾンに来てちょうど５年が経ったので、これまでの取り組みをまとめてみようかと思う。書き進めていくうちにとても長くなってしまったので、1年につき3トピックに絞ってあとはカットした。それでも5年分なこともありかなり長くなったので、目次から各トピックに飛んでもらえればと思う。社内の関係者も読むかもしれず、「自分のやったことが載ってない！」と思うこともあるかもしれないが、内製開発案件だけでも53案件あり全部載せるととんでもない量になるので許してほしい。それから、振り返ってまとめると退職すると勘違いされるかもしれないけれど、退職するわけではありません！ 2019年：ゼロからのスタート1-1. 内製開発エンジニア募集を始める「日本のそれなりの規模の事業会社の中に、内製開発チームを立ち上げることはできるのだろうか？」 2019年3月、クレディセゾンに来たばかりの私にとってはこの質問への答

Measuring developer productivity is a difficult challenge. Conventional metrics focused on development cycle time and throughput are limited, and there aren't obvious answers for where else to turn. Qualitative metrics offer a powerful way to measure and understand developer productivity using data derived from developers themselves. Organizations should prioritize measuring developer productivity

エンジニアリング戦略室の高井といいます。 みなさん、開発生産性を高めていますか？　近頃、開発生産性という言葉をよく聞くようになってきました。開発生産性について書かれたブログや技術イベントでの発表を目にする機会が増えています。これはソフトウェアの重要性が高まってきていることや、またアメリカの金利政策によってマクロ経済状況が変化したという背景が影響しているようにも感じます。開発生産性という言葉がバズワードのようになりつつあります。 誰もが重要だと考えている開発生産性ですが、それが何であるのか、またどのように改善していくのか、という具体的な話になると喧喧諤諤の議論になってしまうようです。開発生産性とは、どうにも茫漠としていて、とらえどころがない、そしてなかなか難しいものです。 本エントリーでは、いくつかの研究を補助線にしつつ、開発生産性というよりも開発者体験にフォーカスしてみた私たちの経験につい

はじめに自分たちのチームがどういう状態なのか推定するための指標として、開発生産性フレームワークSPACEの活用を試みているところです。いまのところは概要記事を読んで、元の論文をざっくり読んで、それをもとに「自分たちで追いかけるならこういう指標かな？」って考えて、チームに共有して、みんなでどうするといいだろうねって考える段階。だからnoteとかにまとめるのは、もうすこしカッチリ言語化できたり、その指標を追うことで何か変化が起こったタイミングにしようと思っていました。 先日参加した「EMゆるミートアップ vol.6〜LT会〜」で、HACOBUのけんにぃさんが「チーム実績をSPACEで表現してみるチャレンジ」という発表をされていました。なぜSPACEで表現してみようと思ったのか、何に気をつけているのかなどがコンパクトにまとまった良いLT資料なのでぜひ目を通していただいたのですが、この発表を聞いて

NTT Comの技術顧問が「目標設定の基本」について講演する「エンジニアリングマネージャーと目標設定」。ここで株式会社アトラクタ Founder兼CTO / アジャイルコーチ兼NTT Comの技術顧問の吉羽氏が登壇。目標設定のやり方とその運用方法について話します。 「定量的に判断できる目標が良い目標」なのかはまぁまぁ怪しい話吉羽龍太郎氏：さて、本題に入っていきたいと思います。今日はどういう方が（このセッションを）聞いているかはわからないんですが、目標設定の時に、特に上司の方からよく言われる話ってこういう話なのかなと思います。 「目標を設定する時は、達成できたかどうかを定量的に判断できるようにしましょう」。「定量的に判断できる目標が良い目標なんだ」と。（言われたことがある方は）リアクションとかで教えてくれるとうれしいです。 僕もいろいろな会社に勤めましたが、若い頃とかによく言われた記憶があり

サマリー：本稿では、マイクロソフトがどのように組織文化の変革を実現したのか、筆者が実施した調査を元に解説する。一定の利益を出す既存事業に安住してしまう状況は、組織文化が旧来のままであるために起こった。その後、サ...　もっと見るティア・ナデラの下で、組織変革を遂げ、いまに至る。その変遷を、グーグルと対比しながら解説する。　閉じる マイクロソフトはどのように組織文化を変えたのか ハイテク業界では長年、マイクロソフトはウィンドウズで市場を独占したことにあぐらをかいている前世紀の成功企業とみなされてきた。なにしろ同社はもう数十年も、画期的なイノベーションを起こしていない。他社を素早く追従するファストフォロワー戦略を取れるだけの潤沢な資金はあるが、どの市場においてもリーダーになるには大きすぎ、官僚的すぎた。アマゾン・ドットコムのジェフ・ベゾスは東を指差し、社員に「シアトルの隣人のように自己満足に陥

マネージャーは非常に重要な役割であり、従業員の業績に大きな影響を与えます。優れたマネージャーの条件を共有し、能力開発の機会を提供し、優れたマネージャーを称賛するなどの方法で、従業員をサポートしましょう。 Google はこれまで、マネジメント業務の大切さを必ずしも正当に評価してきたわけではありません。2002 年、すべてのマネージャーを廃止して管理職のいない組織にするという「実験」を行いました。しかし、この実験は失敗に終わりました。2008 年には、調査チームが、マネージャーは重要な存在ではないという一部の意見を証明しようと試みますが、すぐにまったくの正反対であることがわかりました。つまり、マネージャーはきわめて重要な存在だったのです。 そこで、Google における優れたマネージャーの条件とは何かを正確に突き止めるため、「Project Oxygen」という調査プロジェクトが実施されまし

8月に出る新刊のお知らせです！ 企業でよくある人事制度では、技術職の上位職としてテクニカルスペシャリスト職とマネジメント職が用意されている、というのをよく見ます。 わたしも前職でまさにそういう人事制度のもと、管理職として本を読んだり研修を受けたり相談したり、いろいろやってた記憶があります。 いざ管理職になるといっても、用意されている研修プログラムは薄らボンヤリした一般的な内容で（そりゃそうですよね、マネジメントって人が相手なのにその実装を抜いた話はボンヤリするに決まってる）、結局マネジメントのしかたなんて誰も教えてくれないし、上司やデキる人の真似をするぐらい。個人が体得していく専門性なんて怪しいもので、センスのある人はいいマネージャーになるけど、センスがない人は全然ダメ。センスのないマネジメントの部下になんてなったら最悪。そもそもセンスってなんだ！ いいマネージャーかどうかって何をもって評

2018年6月1日に株式会社メルペイに入社して、4年が過ぎました。入社当時は、定年が60歳と聞いていたので、1年半の勤務だと思っていましたが、実際の定年は65歳であり定年まであと2年半です。 ソフトウェアエンジニアにとって重要な能力と（私は考えるが）、身に付けるのが難しいのが現実だと、この4年間で再認識したのは次の三つです。 開発の最初にAPI仕様をきちんと書けるソフトウェアエンジニアは少ない テストファースト開発を行っているソフトウェアエンジニアは少ないか、いない Tech Blogなどの執筆で、読み手を意識して、分かりやすい文章を書く、ソフトウェアエンジニアは少ない API仕様については、このブログでも何度か書いています（「API仕様を書く」）。テストファースト開発についても、「テストファースト開発」を書いています。分かりやすい文章については何も書いていないですが、「伝わる技術文書の書

fukabori.fm fukabori.fmは2018年からiwashiさんが運営している（すごい！）、技術・組織・開発などを中心に話すTech系のPodcastです。 実はお仕事のご縁でiwashiさんの社内向けラジオ（一般公開なし）に出たことがあるのですが、 それ以来ひさびさにお声がけいただき、2021年12月に発売された拙訳『チームトポロジー』について話してきました。 （話の中でたまに "チームトポロジーズ" って言ってるんですが、正しくは "チームトポロジー" ですね。英語タイトルが "Team Topologies" だったので…） fukabori.fm 月並みな感想ですが、社外の人と雑談をすること自体も久しぶりで楽しかったです。 ライブ感のある収録で、聞き直してみると「あー、ここは言葉が足りなかったな」とか思うところはあったり、ちいとぽ関係ないじゃんみたいな話も盛り上がって