【資料公開】目標設定の基本
みなさんこんにちは。@ryuzeeです。 2023年5月9日に開催されたNTT Com Open TechLunch #7「エンジニアリングマネージャーと目標設定」の登壇資料を公開します。 このイベントはNTTコミュニケーションズの社内ランチ勉強会を一般に公開しているものです。 ぼくは、NTTコミュニケーションズの技術顧問をしており、顧問業の一環として登壇しています。 多くの組織では、この時期に期初の目標設定を行っているのではないかと思いますが、目標設定の意味や位置づけ、それをどのように使うのか、評価や報酬との関係はどうなるのかといったことについて組織のなかで認識が揃っていることはまれです。 こうなると、人事制度のなかで目標設定をすると決められているのでめんどくさいけどやる、という感じになったり、目標設定が終わったら内容を綺麗さっぱり忘れて、期末になって「あー、そういえば……」みたいなこと
【資料公開】マネジメント向けアジャイル開発概要
みなさんこんにちは。@ryuzeeです。 2020年1月20日にとある企業の経営レベルの方向けにアジャイル開発の概要について説明した際の資料を公開します。 自社で経営者の方やマネージャーの方にアジャイル開発がなぜ必要なのかを説明する際の参考になれば幸いです。 （スライドはこちらからもご覧いただけます：https://slide.meguro.ryuzee.com/slides/101） 本資料は、なぜ今アジャイルが必要なのかという点をまず理解していただけるようにコンテキストのすり合わせに主眼を置いています。 経営者やマネージャーの方にとってはスクラムの具体的なやり方といった手法部分はあまり関係なく、それによって組織がどういう影響を受けるのか、組織としてどんな取り組みをすべきなのかが分かることが重要なためです。 単一チームや小さなプロダクトでアジャイル開発をするのと、組織的にそれをスケールし
【資料公開】Effective Retrospective (効果的なふりかえり)
みなさんこんにちは。@ryuzeeです。 2017年3月18日におこなわれたProductivity Engineering − Forkwell Meetup #4の登壇資料『Effective Retrospective』の資料を公開します。 登壇の時間が20分ですので基本的な内容になっていますが、これからふりかえりを始める方やなんとなくいまのやり方がうまくいかないと思う方には役にたつと思います。 もっと詳細が知りたい場合は、アジャイルレトロスペクティブズを一読することをお勧めします。2007年の本ですがまったく陳腐化していないので参考になると思います。 なにかご質問があればTwitterなどでお知らせください。それでは。 アジャイルコーチングやトレーニングを提供しています株式会社アトラクタでは、アジャイル開発に取り組むチーム向けのコーチングや、認定スクラムマスター研修などの各種トレー
プロジェクトが失敗する10の兆候
今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス
採用プロセスを真剣に考えろという話
人材流動性の高まりを日々感じているみなさんこんにちは。 最近いろんな会社にお呼ばれしていて、その中でエンジニアの採用の話になることがとても多いのでちょっと整理しておきます。 ポイント▼「面白いプロダクトもないし、仕事内容は面白いとは思えないし、よい給与は払えないし、仕事環境にも自由はないけど、良い人雇いたいんだけど、どうしたらよいですか？」悪いが諦めろ。良い人は当然のことながら複数の会社が興味をもつことになるし、働く場所を自分で選択します。Pros/Consを見極めて選ぶことになるので、Prosがない場所で働く理由がありません…だとあまりに冷たいので、もしあなたが次に転職するとして、それでも今の会社に入るのであればあなたを惹きつける理由が何かあるはずで、それをアピールしよう▼「入社してから期待値にあっていないことが分かる、ってことが多いんだけどどうしたらよいですか？」期待値を明文化している
【資料公開】トヨタ生産方式の基本と考え方
いまは時間があるので呼ばれればお伺いして相談にのったり、社内勉強会で喋ったりしているのですが、珍しく毛色の違う話をしてきたので資料を公開しておきます(内容は非常に基礎的な話です)。 呼ばれた先でよく言われるのが「スクラムがうまくいっていない」「スクラム的に正しいかどうか分からない」「DevOpsになかなか切り替わらない」といった話なのですが、 そういうのを聞くたびに危ないなぁという感覚を持ちます。スクラムをやるのも、DevOpsな方向に進めるのもビジネス上の目的や課題があるからそうするはず(すなわちスクラムをやるのは目的じゃない。クラウドも同様)なのですが、どうも話が手法やツールに関連する話に閉じてしまう。もしくは本当に開発部門が全体の中での一番の問題なのかも分からないうちに、「開発」側だけの観点でみて全体のプロセスを大きくいじくろうとしてしまうケースもあるようです。(仏作って魂入れず、み
【資料公開】強いチームの作り方 | Ryuzee.com
2015年11月10日に某社の社内勉強会で、「強いチームの作り方」というテーマで話をしたのでその際の資料を公開しておきます。 内容自体は、WEB+DB PRESS 83号に書いた内容なので興味があればそちらを参照ください。 最近DevOpsの文脈ですぐに「インフラ自動化しないといけない」とか「ツール使って効率化」みたいな話を頻繁に聞きます。 が、端的にいえば、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」というデマルコの一節の通りであり、 DevOpsの本質もツールではなく、CLAMS(Culture、Lean、Automation、Measurement、Sharing)であって、土台となるのはやはり組織やチームの文化になります。 一度自分たちのチームや組織について考えてみるとよいと思います。 アジャイルコーチングやトレーニングを提供しています株
【資料公開】いつまで開発のやり方ばっかり語ってるの？
みなさんこんにちは。@ryuzeeです。 2013年1月15日、16日にScrum Alliance Regional Gathering Tokyo 2013が開催されました。 まずは実行委員として、ご来場頂いた参加者の皆様、登壇者の皆様、スポンサー各社様、様々なコミュニティの皆様、ほかご協力いただいた全ての方に感謝したいと思います。ありがとうございました。 僕は1日目の達人に聞けのセッション、2日目のScrum The Next Generationに登壇させていただきましたが、2日目の資料について以下で公開しておきます。 大胆不敵にも本イベントの実行委員長（僕らはプロダクトオーナーというロールにしています）が基調講演の裏で、とんがったセッションをやりたい、ということでこのセッションは企画されました。 したがって僕のスライドも結構過激になっています。 単に字面だけみて誤解をしないように
【資料公開】アジャイルな開発からアジャイルな組織へ
みなさんこんにちは。@ryuzeeです。 2012年3月16日に実施されたAgile Japanの大阪メイン会場に登壇させていただきました。 発表の資料を以下に公開します。 会場の外まで立ち見が溢れるくらいの多くの方にお越しいただき感謝するとともに、ご不便をおかけした方にはお詫びしたいと思います。 僕が話した内容は、実は単に実際の現場で、現場を良くしたいと思っている皆さんの胸のうちを代弁しただけです。 アジャイルという単語、スクラムやXPといった手法の名前自体の認知度があがって、ともすればこれらを導入すれば全てうまくいくんだ、と誤解を生んでいるのではないかと感じています。 でも手法は手法でしかなく（したがってスクラムやXPを導入しているからといって自分たちのアジャイル度合いが高いとは限らない）、目的に応じてそれにあった方法、自分たちがゴールを達成するのに最適だと思う方法を脳みそ振り絞って考
ゴールを決め過ぎてしまうことによって陥る罠
みなさんこんにちは。@ryuzeeです。 Bob Hartman氏のAgile antipattern: Target fixationが良い記事なので、抜粋・意訳にてご紹介します。 日本でよく言われるのが、「期日までに使わない（と思われる）機能も全部作れ、契約だから」。 限られた時間軸の中で変化を受け入れながら進めている中でこういうのを要求されると、品質やチームのモチベーションやコラボレーションを犠牲にしはじめてしまいます。 このような状況が続けば焼畑農業のようにチームには何も残らなくなります。 結果として顧客にとっても幸せな結果にはなりません。 期日を約束したりストーリーポイントのゴールを約束したり、その他のゴールが命取りになることがある。これらだけでは本質的に悪くは無いとしても、下記に述べるその他の項目と組み合わさると、問題となるだろうチームはゴールを達成するために品質を端折り始める
カンバンを導入する間違った理由5個
みなさんこんにちは。@ryuzeeです。 ちょっと古い記事ですが、TargetProcessのサイトMichael Dubakov氏による5 Wrong Reasons To Apply Kanbanという良い記事があったので、抜粋・意訳にてご紹介します。 5つの間違い1.ユーザーストーリーの多様性我々のストーリーは1ポイントから40ポイントまでさまざまなので、大きいストーリーがスプリントに入らない。なのでカンバンを使う 2.スプリントがうまくいかない1スプリントの中でほとんどのストーリーが完成しない。なのでカンバンを使う 3.ふりかえりミーティングがうまくいかないふりかえりミーティングが無駄になっている。チームメンバーはプロセスの改善に協力してくれず、ミーティング自体をなくしたい。なのでカンバンを使う 4. 人的リソースの共有と機能別組織開発チームが１つで、プロジェクト間でメンバーを共有
プランニングポーカーのやりかた | Ryuzee.com
かわぐちさんが簡単ガイドを作られていたので僕も普段研修とかコーチングで使っているマテリアルを晒しておきます。 色々なやり方があるので、どれがあってるとか間違っているとかは無いですし、認定スクラムマスター研修なんかでも講師によって若干やり方が違ったりします。一例ということで。 なお、僕が普段コーチをする上でよく言っている点を以下に書いておきます。 大きすぎると見積り精度はどんどん落ちる。ストーリーがでかいと思ったら分割するそれに関連して僕は1,2,3,5,8,13,?くらいしか使わない。20は使う必要ないなぁみんなが似たような数字出したからといって中身の完成イメージが同じとは限らない。見積もる際の議論大事タイムボックス大事。だらだら時間かけてやらないプロダクトバックログの見直し（リファインメント）同様に、見積りも定期的に見直す追記 いま日本でプランニングポーカーを入手する方法は以下の通りです
[Agile]Agileチームのアセスメントの方法 | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 アジャイルな開発を行っているチーム（やっていなくても構いませんが…）のアセスメントを行う方法について考えてみました。 あくまで一例でこれが最適とは限りませんが、コーチとしてリアルなプロジェクトの具体的なところではない原点の部分を軸にしてチームの成熟度を把握できるようになりたいなぁということで、アジャイルマニフェストの12の原則をベースにして考えてみました（今後継続的に足していったり、現場で試してみる予定です）。 1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。プロとして顧客のために行動できているか正しいことを行っているかどうかを常に意識しているか顧客のためとは顧客の言う事をすべてやることではないことを理解しているか価値は提供する側が決めるものではないことを理解しているか顧客にとって価値がなかったらどうなるか理解しているか2
![[Agile]Agileチームのアセスメントの方法 | Ryuzee.com](https://cdn-ak-scissors.b.st-hatena.com/image/square/df332fc34a3fa52667d1fd10e539a45e2f6a3550/height=288;version=1;width=512/https%3A%2F%2Fwww.ryuzee.com%2Fcontents%2Fblog%2Fimages%2F4657%2Fthumbnail.png)
チームワークに関するよくある6つの誤解
環境の変化に素早く対応しなければならない組織において、ミッションを達成するためには、チームワークとコラボレーションが必要不可欠だ。私のアメリカのインテリジェンス・コミュニティーでの研究では、その考えを支持しているが、プロダクティブなコラボレーションから外れてしまう可能性のあるチームワークに関する多くの誤った考え方を目にする機会が多い。 誤解1 調和は役にたつ。共同作業者との間でのスムーズな相互作用が、どうやって進めるのが一番良いのか、という時間のムダになる議論を避けてくれる。実際 まったく正反対の結果を調査結果が示している。よい感じでマネージされていてチームの目的にフォーカスしている場合、衝突はよりクリエイティブなソリューションを生み出すことができる。(衝突がないグループよりもだ)。衝突が仕事それ自体に関するものである限りは、意見の相違はチームにとって役にたつものだ。実際に、過去の研究では
態度重要
みなさんこんにちは。@ryuzeeです。 今度翔泳社さんから発売される、「100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊」という本に明らかに場違いな感じ(まわりの人凄過ぎる)ですが、寄稿させていただきました。 100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊著者／訳者：出版社：翔泳社発売日：2012-02-22単行本（ソフトカバー）：216ページISBN-13：9784798126005ASIN：4798126004 原稿を公開して良い、ということなので、公開しておきます。他の寄稿者の方は本当にすごい方ばかりで、いままでにないタイプの本だと思いますので、本当にオススメです。 僕が選んだ本は、あえてアジャイルプラクティスです。 アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣著者／訳者：Venkat Subramaniam、Andy Hunt
資料公開 Scrumはじめの一歩
2011年9月3日(土)に早稲田大学理工学部で行われたXP祭り(記念すべ第10回！)で、Agile Buffetというワークショップセッションを長沢さん(マイクロソフトの凄腕エバンジェリスト)、海江田さんと一緒に、Scrumはじめの一歩という初心者向けセッションを、西村さん(アジャイルサムライ監訳者)と一緒に実施してきました。 ご参加頂いた方、お手伝い頂いたスタッフの方、こっそり紛れ込んでもらった仲間たちありがとうございました。 Agile Buffetについては長沢さんのブログ等で公開されると思いますので、ここでは、「Scrumはじめの一歩」について資料を公開いたします。 今回は90分コースでしたので、全体の概要をざっくり抑えたうえで、ワークショップをやって実際のScrumのイメージを掴んでいただくことを目的としてます。次はフルコースで聞きたいという方は是非Scrum Boot Camp
コミットメントとは何か？ | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 昨年夏に同人誌として刊行された「Ultimate Agile Stories」に寄稿させていただいたのですが、昨日のJim Coplien氏の認定スクラムマスター研修でもコミットメントの話が出ていましたので、参考までに僕の考えを転載します。 なお、Ultimate Agile StoriesはIteration2として今年も刊行を計画されるそうなので、是非動向をウォッチしておいてください。昨年は平鍋さんをはじめとする日本のアジャイルコミュニティを牽引するすごい方たちがたくさん寄稿されていました。 システム開発をしていると「コミットメント」という単語をよく耳にするだろう。アジャイル、特にスクラムの文脈においては「コミットメント」は重大な意味を持っている。本稿ではシステム開発における「コミットメント」とは何なのかについて考察してみたい。 1. 辞書の定
そもそもアジャイルって何だろう？
Q:あなたは以下のどの理由でアジャイルではないのでしょうか？以下から１つ以上選んでください。 a デイリースタンドアップミーティングしていないb ペアプログラミングをしていないc TDDをしていないd 象徴となるような人を雇用していないe スクラムマスターがいないf イテレーション計画ミーティングをしていないg インデックスカードを使っていない 答えはHで、上のどれでも無いです。 プラクティスは「アジャイルであることを助ける」ための道具であって、それ以上ではありません。 アジリティの意味するところは、頻繁に継続的に顧客のニーズにあった高品質なソフトウェアを届けることができる、ということに他ならないのです。 以下いくつかよくある例や思ったことの補足をしておきます。 RedmineとかTracとかJIRAとかRTCとかTFSみたいなWeb系のアジャイル支援ツール使っている＝アジャイルである、と
Impediments（障害事項）への対応
みなさんこんにちは。@ryuzeeです。 Impediment（障害事項・妨害事項）について、海外で良い記事がいくつかあったのでご紹介しましょう。 Recognizing ImpedimentsThe biggest impedimentImpedimentとはスクラムでよく使う単語で、プロジェクトを進めていく上での障害や妨害になる事項のことです。 人的なもの、プロダクトに関するものなど全てを含みます。 例えば以下のようなものが一例になります。 未完了なままの作業情報の不足繰り返しの作業待ち依存先の欠如割り込みバグ官僚主義間違った、もしくは不明瞭なコミュニケーション意思決定がなされない間違った推定時間がたりないパーツがないよく知らない新しい技術 などなど、ほかにもたくさんあります。 当然のことながら、これらの障害事項を把握することは大事ですし、日々の活動の中で優先順位をつけて改善していかな
資料公開 タスク管理超基礎(学生向け)
先週金曜日に慶應SFCのPBLの授業の中でチーム開発ではなぜタスク管理が必要なのか、タスクはどのように作るべきなのかについて基本中の基本を説明しました。 その際の資料を公開しておきます。 既にチームとして開発を行っている方にはたいして役にたたないと思いますが、新入社員とかへの説明には役にたつかもしれません。 プロの方でも役にたつかもしれないのは最後のページだと思うので再掲しておきます。 タスクの管理の仕方。 やらなければいけないことをなるべく網羅する（いきなり全部は無理） 誰がみても分かるように 何が出来るとそのタスクが終わるのかの条件をはっきりさせる 計画をたてやすくするために大きなタスクは処理しやすい大きさに分ける 進捗状況を分かるようにする（誰がやってる？もう終わった？） リストは定期的に見直す
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
