はてなブックマーク

はじめに アジャイル開発では「チームワーク」が成果の鍵を握ります。 しかし、チームの中に高い技術スキルを持っていても、協調性に欠けるメンバーがいると、プロジェクトは一気に難航します。 そうした存在は「ブリリアントジャーク（Brilliant Jerk）」と呼ばれます。 私自身、スクラムマスターとして、まさにそのような状況に直面したことがあります。 本記事では、そのときの経験と、そこから得た教訓を紹介します。 ※ご紹介する内容はわかりやすく一般化したもので、実在のプロジェクトや人物とは一切関係ありません。 ブリリアントジャークとは何か ブリリアントジャークとは、優秀だが厄介な人を意味します。 彼らは知識も技術も豊富ですが、他者への配慮や共感が欠け、結果としてチーム全体の心理的安全性を壊してしまうことがあります。 アジャイルでは、透明性・協働・自己組織化が重要です。 しかし、コミュニケーション

AI推進は難しいAI推進がうまくいかない理由を挙げだしたらキリがない。 領域選定のミス、経営陣のリテラシー不足、社内政治（既存部署の抵抗）、推進体制が適切でない、既存業務の再定義が困難　など無限に出てくる。 その中でも今回はKPI設計に焦点を当ててみる。 なぜAI推進においては適切なKPI設計が特に大事なのか そもそも目標設定が大事なのはいうまでもない。 目標がなければ、プロジェクトの成功・失敗の判断を下すことも、関係者間で認識を合わせることもできない。 そんな当たり前の話をしたいわけではなくて、 KPI設計が特に大事な理由は、AI系プロジェクトはAIの性質上、正しくKPI設計をしないと確実に失敗するからだ。 なぜか？ AIは短期では「先行指標」にのみしか寄与できないケースが多いからだ。 先行指標と結果指標について先行指標とは、最終的な成果（例: 売上）につながる「原因」や「プロセス」に関

デイリースタンドアップ、スプリントプランニング、レトロスペクティブ。スクラムのフレームワークは完全に導入した。チームは毎日15分のスタンドアップをしているし、2週間ごとにふりかえりとカイゼンアイテムの特定をしている。でも、何かが違う。現場は相変わらず「忙しい」と言い続け、部門間の壁は高いままで、意思決定のスピードは上がらない。 アジャイルやスクラムを始めたばかりのチームや組織において、このような状況に心当たりがあるのではないでしょうか。問題は、フレームワークそのものではありません。 ここで私たちが直面しているのは、技術的課題と適応課題を取り違えているという、より根本的な問題です。 技術的課題と適応課題 この概念は、ハーバード大学のロナルド・ハイフェッツ氏が提唱したリーダーシップ理論に基づいています。 技術的課題 問題が明確で、解決策がすでに存在する 専門家が答えを持っている 既存の知識やス

みなさんこんにちは。@ryuzeeです。 2025年10月17日に技術顧問先の社内イベントで「生成AIでスクラムによる開発はどう変わるか」というテーマで登壇しましたので、そのときの資料を公開します。 先日発表された「State of AI-assisted Software Development」にもあるように、開発現場でのAI導入は当たり前になりました。 これはすなわち、既存の開発プロセスをAIにあわせてチューニングしなければいけないことを意味します（そしてAI自体が非常に速い速度で変化しているので、それにあわせて継続的な調整が必要です）。 スクラムについても同様で、根底となる価値観や原則に変化はないものの、イベントや作成物などには大きな影響があります。 このセッションでは、複数の支援先を踏まえて、現時点で起こっている変化について説明しました。 参考になれば幸いです。 忙しい方向けのま

【3行要約】 ・現在は多様性重視やパワハラ回避の風潮で、上司が部下への指導を躊躇する傾向が増加。 ・髙桑由樹氏は、セミナー内で「迎合」「説明不足」「暴走・放置」の3つの空回りパターンを解説。 ・チームを機能させるには、部分と全体、表層と本質を多角的に捉える視点が必要です。 髙桑由樹氏：本日は「これでイイのか⁈　『空回りする管理職』チームを機能させる“適切な打ち手”の見つけ方」というテーマで進めます。まず、このセミナーの狙いを共有します。 「空回りする管理職」とは何か。ここでは、管理職の業務で結果につながっていない行動を指すことにします。 もう少し具体化するために、状況を2つの軸で整理します。横軸は経営層との合意形成で、経営層から「それは良い」と認められている状態を○、「何をやっているのか！」と否定される状態を×とします。 縦軸は現場との合意形成で、現場の理解や納得が得られている状態を○、逆

「AIがコードを書く時代、スクラムは本当に最適解なのか？」 この問いに、あなたは即答できますか？ 開発現場で起きている静かな革命 AIによるコーディングが当たり前になりつつある今、ソフトウェア開発の進め方そのものを見直すタイミングが来ています。 多くのチームがスクラムを採用していますが、AIが主導する開発（AI駆動開発）では、実はウォーターフォールの方が合理的なのではないか？ という問いが浮かびます。 ただし――速度は従来のスプリント並み。つまり、「遅いウォーターフォール」ではなく、「Water-Scrum-Fast」という新しい形が現実解です。 スクラムがAI駆動開発に噛み合わない理由 AIによる実装は、以下のようなサイクルで進みます： このサイクルは極端に短く、AIが生成するコードは**「曖昧な仕様」に敏感**です。そのため、要件や非機能要件をしっかり定義しておかないと、AIは暴走しま

スクラム祭り2025 発表資料です https://confengine.com/conferences/scrummatsuri/schedule p.5 [EMがマジ価値を届けきるために考え行動したこと ](https://speakerdeck.com/matsu0228/enginee…

■セッション概要 生成AIの登場により、ソフトウェア開発はかつてないスピードで変化しています。 コーディングやドキュメント作成、資料作成といった“作業”は加速度的に効率化が進み、Vibe CodingやAgentic Codingのように、開発の役割や働き方そのものを揺さぶる変化も生まれています。 …

■セッション概要 このセッションでは、これからスクラムをはじめるチームやスクラムをはじめたばかりのチームが知っておきたいコツを紹介するセッションです。私自身のスクラム実践知や、アジャイルコーチとしてさまざまなチームのスクラム立ち上げを観察・支援する中で得た知見をピックアップしてご紹介します。スクラムガ…

こんにちは。AIやっていきチームの加瀬（@Kesin11）です。 先日開催されたVSCode Dev Days Tokyoにて「Issue, Pull-request, GitHub Copilotによる『普通』の一人チーム開発」というタイトルで発表させて頂きました。 vscode.connpass.com この発表ではGitHub Copilotと共同で機能設計の壁打ち、タスク分解、実装、コードレビュー、という開発プロセスを使い慣れたGitHubで行う方法を紹介しました。 現地の発表ではスライドをほとんど用意せず、最初から最後まで実際のデモを行いながら説明するという一発勝負スタイルでしたので、発表スライドの代わりにデモの台本をこちらで紹介することにしました。 当日のデモでは時間の都合上、かなりの駆け足でしたし、実は泣く泣く省略した内容もたくさんありました。そのため、この台本は当日に参加さ

多くの人が「スクラム＝ソフトウェア開発手法」と認識している現状を見て、少しもったいないなと感じることがあります。実は、スクラムの源流は経営学の巨人・野中郁次郎先生（1935-2025）の研究にあり、その本質はもっと深く、もっと広範囲にわたるものなのです。 私は初めてスクラムを知ったとき、その背景に野中先生の影響があることに驚きました。そこから多くを学んでいく中で、日本のプロダクト開発黄金期にあったはずのものを、どうやったら取り出して、現代の私たちとして活用することができるだろうか、と考えてきました。野中先生、ジェフ・サザーランド博士、本間さん、竹内さん、南野さんのご協力を得て、できる限りの情報を集めて、スクラムの枠組みだけではくみ取れない、成功のためのディテールを集めてきました。 （2025年1月25日、野中先生がご逝去されました。先生のご冥福をお祈りするとともに、その偉大な知的遺産を受け

こんにちは、Repro Boosterの開発責任者・プロダクトマネージャーの Edward Fox です。全国的に長く続いた酷暑も少し落ち着きを見せ始め、朝晩は涼しく感じるようになってきましたね。 はじめに 2021年からプロトタイプ開発を始めたRepro Boosterですが、2022年の8月頃に正式なプロジェクト・チーム化しました。開発チームにはRepro社歴が長いメンバーも多く、チームが組成されてからこれまで大きな入れ替わりもなく開発を行ってきたのもあり、非常に安定した組織運営ができていると感じています。 これ自体は素晴らしいことであり、チームの成熟度が高い証でもあります。しかしながら、新規事業の本分は「非線形的な成長」であり、安定の先にある未来の解像度が高く持ててしまっている点に、得も言われぬ不安を感じるようになったタイミングがありました。プロダクト・事業の成長に「天井」が見え始め

こんにちは。クラウド&ネットワークサービス部で SDPF のベアメタルサーバの開発をしている山中です。 先日、Google Workspace で利用できる Gemini API を活用して、日々の業務ログから日報を自動生成し、Slackに自動投稿する仕組みを構築しました。 その具体的な方法と、実際に導入してわかった想像以上の効果をご紹介します。 デイリースクラムの悩み、AIで解決しませんか？ やったこと：情報を集めて Gemini に日報を書かせる 1. 各種ツールから活動ログを収集 2. イベント情報を時系列で整理 3. プロンプトを作成し Gemini API を実行 4. Slack への自動投稿 想像以上の効果！情報共有が劇的に改善 シンプルに楽！「昨日何してたっけ？」からの解放 口頭の問題点を解決 完璧を求めない柔軟な運用 完璧じゃないからこそ面白いAIの活用法 テキスト文化と

ハーバード・ビジネス・レビュー2025年9月号の入山章栄先生の連載にて、パラドキシカル・リーダーシップという概念が紹介されていた。近年勃興しつつあるリーダーシップ理論とのことで、Webで検索してみると2023年あたりから関連する書籍や記事が見つかる。その出自も含めてEMと深い関連性が感じられ、エンジニアリングマネジメントをうまくやる上で参考になる理論のひとつになるように思った。この記事では当該連載を参照しながらパラドキシカル・リーダーシップを簡単に紹介し、わたしの体験や考えを踏まえたEMとの関連性について議論する。 パラドキシカル・リーダーシップとは パラドキシカル・リーダーシップとは、不確実性の高い環境に適応するため、一見矛盾するように見える複数のリーダーシップスタイルを統合して発揮するあり方とされている。このハイブリッド型の像を理解するためには、ここに至るまでのリーダーシップ論の変遷を

■参考リンク RSGT2025 クロージングキーノート - 本間日義 https://www.youtube.com/watch?v=Z5lBjmPy5QI プロダクトマネジメントリーダーズ!POとSMの原点の原点をさかのぼって学ぶ初代主査 中村健也の働き方 - @_N_A_ https…

はじめに こんにちは。普段は事業会社でエンジニアとして働いている「たいのー」です。 現在はエンジニアチームのマネージャーっぽいポジションをしているのですが、この立場になってからミーティングのファシリテーションを任されることが多くなりました。 あまり場を仕切ることも得意ではなかったので、最初の頃は失敗の連続でした。 沈黙が続くと焦って「じゃあ次は…」と無理やり話題を進めてしまったり、議論が堂々巡りになって時間だけが過ぎたり。終わった後に「今日のミーティング、意味あったのかな…」と落ち込むこともよくありましたね（笑） でも、何度も試行錯誤するうちに、少しずつ「ファシリテーターとして意識すべきこと」が見えてきました。 今回はその中から、特に役立っている個人的な3つの心得を整理してみたいと思います。 これからエンジニアチームのマネージャーやチームリーダーになる方にとって、少しでも参考になれば嬉しい

#levii 主催のオンラインイベント「エンジニアリングマネージャーのための設計再考」 ( https://levii.connpass.com/event/363660/ )での発表資料 ・開発組織のパフォーマンス向上と技術的負債 ・技術的負債を解消する効果 ・技術的負債を解消する費用 …

カミナシでプロダクトマネージャーをやっています、よしおかしおり（@oriori440）です。 「作るのが簡単になった今、機能を「大きく」「たくさん」作っていませんか？」 生成AIの進化や、ノーコードツールの充実で、非エンジニアでも「とりあえず形にする」くらいなら誰でもできるようになりました。 私自身、ちょっとしたプロトタイプはFigmaMakeやv0を活用してシュッと作り、お客様にあてることができています。 そんなある日、弊社のエンジニアがSlackにこんな投稿をしてくれました。 私は以前から「作らない」ことや「小さく作る」ことを大切にしていましたが、AIで作るのが簡単になった今だからこそ、よりその考えを大事にしながら、一方でアップデートもして行く必要があると感じています。 ▼過去に発信していたnote 今回は、私がカミナシで「小さく作る」ためにやったことや、あるいは「作らない」ためにやっ

こんにちは。Findy Tech Blog編集長の高橋（@Taka-bow）です。 前回の記事では、全体の44.3%が開発生産性に前向きという結果をご紹介しました。今回は開発手法別に深掘りすると、予想外の事実が浮かび上がってきました。 開発生産性への印象は多様 ── 約半数が中立的立場も抵抗感は少数派 意外な結果 ── アジャイル実践者の59.6%が開発生産性に前向き なぜアジャイル実践者は開発生産性に前向きなのか アジャイルの価値観と生産性改善の親和性 Kent Beck氏が語る測定の本質 ── 「測定が目標になると、システムは歪む」 アジャイル実践者の「前向きさ」に潜む3つの勘違い 何を測るべきか ── Kent Beck氏が示す価値創造の道筋 測定を「コントロール」ではなく「認識」のツールとして ── Kent Beck氏の4つの提言 次回予告 【調査概要】 調査対象：ソフトウェア開

キャリア台帳チームでエンジニアリングマネージャーをしている溝渕です。 私が所属するSmartHRでは、多くのチームでスクラム開発を採用しており、労務ドメインではScrum@Scaleの運用も開始しています。ちなみに、どの程度スクラムが採用されているかと言うと、スクラムとか色々やめましたというブログが出るぐらいには普及しています。 そんな中、キャリア台帳は2024年2月にリリースされ、2024年9月からスクラム開発をスタートさせました。 この記事では、もともとスクラムを取り入れたいと思っていたわけではないキャリア台帳チームが、どのような軌跡を辿ってスクラム開発へ移行したのかお伝えします。 キャリア台帳チームでスクラムを採用していなかった背景 最初に、SmartHRでは多くのチームでスクラム開発を採用しているにもかかわらず、キャリア台帳チームでは採用していなかった理由をご説明します。私の入社前

【Unit4 ブログリレー1日目】 エムスリー エンジニアリンググループの関根です。 医療従事者向けポータルサイト「m3.com」のサイトプロモーションを行う、「Unit4」というチームに所属しています。 エムスリーテックブログリレーもUnit4のターンが回ってきました。 トップバッターである私からは、チームについての紹介と、利用技術や開発スタイルをご紹介します。 Unit4は m3.com の玄関口として、30を超える多種多様な技術スタックを持つサービスを15人前後のエンジニアで開発・運用する、ちょっと変わった（でも面白い！）チームです。 新しい技術への挑戦や幅広いスキルの習得、自由度の高い開発など、チームの魅力をお伝えできればと思います。 Unit4のミッション Unit4の特徴 技術スタック 多彩な利用言語 代表的なシステム構成 サーバレスサービスの活用 幅広い技術スタックに対応する

こんにちは。「カミナシ 教育」というプロダクトを作っているふじはら（@daipresents） です。毎日アイスを3本以上食べてます。 僕は「カミナシ 教育」のサービスチーム（スクラムチームみたいなチーム）でマネジメントを担当していますが、それ以外ではダブルワークでアジャイルコーチとしていろんな企業の開発支援も行っています。 カミナシでは各チームが自律して動くことを求められ、それぞれが試行錯誤しながらがんばっています。なので、カミナシではあんまりアジャイルコーチの仕事はしていないのですが、自分のチームを俯瞰して見ていると、自然とアジャイルな見積もりと計画づくりをしていないことに気がつきました。 『アジャイルな見積もりと計画づくり』は名著です。だから、僕はチームでの開発にかかわる方に、この本をいつもおすすめします。なのになぜ、このチームはやらないのか？ 具体的には スプリント計画 ストーリー

こんにちは、椎葉です。カケハシでVPoT（VP of Technology）をやっています。技術的な視点で現場と経営をつなぐ活動の一つとして、実際にチームに入って開発業務をサポートしています。今日はその中のひとつの事例を紹介します。 Pocket Musubiチーム 今年の6月からPocket Musubiチームのみんなと一緒に開発業務に取り組んでいます。Pocket Musubiは、薬局と患者さんをつなぐ「服薬フォローシステム」です。Musubi電子薬歴と並んで、カケハシの中でも主要なプロダクトのひとつになっています。 チームはエンジニア5名、SRE2名、QAエンジニア3名をはじめとした10数名のメンバーで構成されており、少人数でさまざまな案件を進めています。そんなチームが少し悩んでいそうだったので、サポートへ入ることにしました。 「いいチームだなぁ」 最初の1スプリントは、デイリースク

プロダクトゴールはなぜ1つだけなのか？スクラムには5つの価値基準があります。その中の1つが 集中（Focus） です。 本当に重要なことに集中することで、ゴール達成の可能性を高めます。 そのためスクラムでは、スプリントゴールもプロダクトゴールも1つです。 しかし、研修やコーチングで「スプリントで複数ゴールを設定したいんですが……」 とか 「今回のプロダクトゴールは3つです！」みたいな話をよく聞きます。 本当に達成すべきゴールが複数あるなら、まず1つを選んでそれを確実に達成することに集中しましょう。 その上で、次のスプリントやゴールを考えてください。 でも、まだ1つのゴールすら明確に描けておらず、1つのゴールを達成した実績もないのに、いきなり複数設定しようとするのは、無謀としか言いようがありません。どうせ達成できません。 「全部大事」は「何も大事じゃない」と同じです（何度言っても「でもでも、