みなさんこんにちは。@ryuzeeです。 今回は、自称「アジャイル開発をしている」といいつつ、定期的に謎の進捗報告会をJiraで行ない、「効率がどうたら」と口癖のように言っている人たちへの説教です。 スクラムでもスクラムでないやり方でも何でも構わないのですが（その違いは大きな問題ではない）、動作するソフトウェアを定期的に披露しようとすると、さまざまな改善が芋づる式に進みます。 披露しようとすれば、一気通貫で動作し、目で見て分かり、評価可能ものを作ることになります。 部品だけを作っても見えないし分かりません。例えばUIモックだけを作っても実際の操作感は分かりません。 何より動かないものや触れないものは真剣に見ません（モックを事前に送付してコメントがさして無かったのに、実物を見せたら大量にあーだこーだ言われた経験を持つ人は多いでしょう）。 一気通貫で見えるものを提示しようとすれば、短い期間で色

みなさんこんにちは。@ryuzeeです。 別のところで依頼を受けて作った文書なのですが、皆様の参考にもなるかと思いますので共有しておきます。 まずはプロダクトゴールを検討するプロダクトバックログは、プロダクトゴールの実現のために存在します。 つまりプロダクトバックログを作るには、プロダクトとして実現したいゴール、顧客に提供したい価値などをあらかじめ検討する必要があります。 リーンキャンバス、エレベーターピッチ、ユーザーインタビュー、エスノグラフィーなどのテクニックを活用しながら、プロダクトとして解決したい課題、実現したい価値やゴールを評価しますプロダクトを実際に開発するのはお金も時間もかかるので、本来この時点で仮説検証を繰り返し、ダメなアイデアを早めに捨てる必要がありますある程度いけそうなアイデアが出てきたら先に進みますスプリント開始の条件スクラムでスプリントを開始できるのは、プロダクトバ

みなさんこんにちは、@ryuzeeです。 今日はデイリースクラムについて、概要や注意点を紹介します。 なお、あくまで一般論であることに注意してください。スクラムの基本は「透明性・検査・適応」です。自分たちで随時やり方を検査して、もっとうまくできるように適応していかなければ効果はあがりません。 1. デイリースクラムの目的 2. デイリースクラムの参加者 3. デイリースクラムのタイムボックス 4. デイリースクラムの事前準備 5. デイリースクラムのファシリテーション・進行 6. デイリースクラムのアンチパターン 1. デイリースクラムの目的 スクラムを利用するとき「フレームワークで決められているから」というだけの理解で進めてはいけません。これは全てのイベントに当てはまります。 スクラムのイベントはすべて、検査と適応が行われるように明確に設計されています。 デイリースクラムの最大の目的は、

みなさんこんにちは。@ryuzeeです。 2023年5月9日に開催されたNTT Com Open TechLunch #7「エンジニアリングマネージャーと目標設定」の登壇資料を公開します。 このイベントはNTTコミュニケーションズの社内ランチ勉強会を一般に公開しているものです。 ぼくは、NTTコミュニケーションズの技術顧問をしており、顧問業の一環として登壇しています。 多くの組織では、この時期に期初の目標設定を行っているのではないかと思いますが、目標設定の意味や位置づけ、それをどのように使うのか、評価や報酬との関係はどうなるのかといったことについて組織のなかで認識が揃っていることはまれです。 こうなると、人事制度のなかで目標設定をすると決められているのでめんどくさいけどやる、という感じになったり、目標設定が終わったら内容を綺麗さっぱり忘れて、期末になって「あー、そういえば……」みたいなこと

みなさんこんにちは。@ryuzeeです。 2022年12月9日に行われたイベント「Developers CAREER Boost」の登壇資料を公開します。 今回は、「マネージャー」と名のつく職種を分類して、それぞれの職務や定義を確認した上で、有効なマネージャーであるにはどうしたらよいかを整理してみました。 資料を作るにあたって、過去の日記を読み返したり記憶を思い起こしたりして、当時の活動や出来事、悩みを整理してみたのですが、自分はやっぱりマネージャーに向いていないし志向していないことを再確認できました（笑）。 全員がマネージャーにならなければいけないなんてことはなく、自分が日々楽しく過ごせるキャリアを選択すればいいと思いますが、資料が少しでも役に立てばうれしい限りです。 本セッションで紹介した書籍は以下のとおりです。 エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーに

組織によっては、スクラムチームの開発者が複数チームを兼務することがあります。たとえばAのプロダクトに半分、Bのプロダクトに半分といった具合です。 スクラムではこのような兼務を明示的には禁止していません。 ただしスクラムガイドは「やってはいけないこと」をすべて定めるようなものではなく、最低限の原則と守るべきことを述べたものに過ぎません。 したがって兼務にお墨付きを与えるものではないと理解してください。 その上で、スクラムの5つの価値基準のうちの1つである「集中」を踏まえると、複数チームの兼務は集中を阻害する要因になります。 またスクラムが土台とする「リーン思考」はフローを重視しており、兼務によってフローが阻害されることは間違いありません。 スクラムの理論以外だと、ジェラルド・ワインバーグ氏によると、2つを兼務すると20%のオーバーヘッドが生まれ、3つ兼務すると40%のオーバーヘッドが生まれる

みなさんこんにちは。@ryuzeeです。 アジャイルコーチでもスクラムマスターでもエンジニアリングマネージャーでも、新しいチームと一緒に働くことになった場合にまず必要なのが情報収集です。 チームの様子を観察したり、1on1で聞いてみたり、ドキュメントを読んでみたりとさまざまな方法があります。 そこで、今回は直接チームのみんなに話を聞いて情報収集する場合に、5個だけ質問できるとしたら何を聞けばよいか考えてみました。 まず、初期の段階では、単に開発プロセスがうまく回っているかどうかだけを聞いてもあまり意味がありません。 そこでプロダクト、意思決定の方法、デリバリー、改善、チームのことを聞いてみようと考えてできたのが、以下の5つの質問です。 プロダクトは顧客の課題解決に役立っていますか？役に立つかどうか、役に立っているかどうかをどうやって確かめていますか？いま開発している機能は誰にとってどう役に

みなさんこんにちは。@ryuzeeです。 スクラムは、スクラムガイドで定義されています。したがってスクラムを学習したり実践したりする際には、まずスクラムガイドを読むのが大前提となります。 とはいえ、短時間で人に説明したり、リファレンスが必要になったりすることも多いので、ぼくが使っている用語集を共有します。 基本用語プロダクトオーナー開発するプロダクトにおける責任者である。そのプロダクトが実現するビジネス価値に対して責任を負う。 主な役割としてプロダクトのビジョンを明らかにして周りに伝える、プロダクトバックログのメンテナンス、プロダクトバックログアイテムの優先順位付け、リリース計画の立案、開発者が作成したインクリメントを受け入れるか受け入れないかの判断、ステークホルダーとの調整などをおこなう。作業自体は委任できるが、最終的な責任はプロダクトオーナーが負う。 実施中のスプリントをキャンセルする

カンファレンスの詳細は技術評論社のサイトで。 開催は品川のコクヨホールで、12時開場、13時基調講演という流れで進んだ。 先着200名に本をくれる＆さらに先着でPokenをくれる、ということなので、丁度12時くらいに行ったのだが、既に結構並んでいた。(実は同じ本を持っていたことが判明。最近このパターン多い) 参加者は300人ということだったが、ほぼ満席で、かつスーツな方が7割(僕は当然私服)ということでマネージャ層あたりまでAgileへの関心を持ち始めているんだなぁという印象。Certified Scrum Master研修とは明らかに来ている客層が違う感じだった。 個別セッションの感想を以下に。 Thought Works社のXiao Guo氏の基調講演 通訳がgdgdだったので英語で拝聴。CSM研修でのミルズさんの通訳の素晴らしさを改めて認識 「大規模システムでのベストプラクティスとそ