RSGT2020の基調講演をやっていただく Jim Coplien さんによる、大規模組織のお話がありました。 この話を聞くのは実は三回目(飲み屋、ウィーンでのScrum Gathering、今回)ですし、ありがたいことに、色んな人に日本語で説明することもあるので、周りの人とも話しながら自分なりの認識がまとまってきました。 いや、お前のまとめなんていらないんだよ、とは思いますが、全体をちゃんと書くのは難しいので(ビデオとっとくべきでした)、ざざっと書いておきます。 人々は組織をツリー構造*1で考えがちで、実際に公式な組織アサインはそのように運営されがちだが、末端のノード間やたすき掛けのようなつながりは自然に起きていて、それによって情報流通の効率性が維持されている。これは、兼務をつけて複数部署にマネージャーを頭出しさせるのとも違うし、マトリックス型組織でプロジェクト運営するのともちょっと違う

Jeff Patton がよく紹介する絵に、モナリザを使ったインクリメンタルとイテレーティブの説明があります。 インクリメンタル = フィーチャごとに作っていく スクラムでは、ユーザーストーリーの独立性を高め、一つ一つのストーリーの独立性を高める事で、スプリント毎に徐々(インクリメンタル)に「出荷可能な増分(Potentially Shippable Increments)」を作っていく、という原則があります。独立性が高ければ、順番を入れ替える事も容易になり、製品開発の方向性を決めるプロダクトオーナーにとっては、現在の状況を見極めてベストな判断を下せる選択肢が増える訳です。 各ストーリーを独立してテストできることで、全体が組み上がった後に膨大なテストをこなすのではなく、各部品(フィーチャー)単位での健全性を確保して、さらに全体を結合したときのテストをしよう、という流れになり、欠陥の発見を早

ITプレナーズさんで主催しているDevOpsの体験型研修がありまして、見学させていただきました。 この研修はオランダに本拠をおく GamingWorks 社が開発したワークショップをITプレナーズさんが日本語化(のお手伝い)をしたものです。GamingWorks 社はAgileやプロマネ向けのゲーム形式研修を手がけているようなので、今後の拡充が期待されます。 https://www.gamingworks.nl/business-simulations/the-phoenix-project/ 継続的デリバリーの先の世界 ここでいう DevOpsについては、Phoenix Project を参考にしていただくとよいかと思います。当初の DevOps の定義はインフラやデプロイの自動化を中心に考えられたものですが、サイロ化が進行した会社が本当に変化のスピードを上げるためには、組織間の連携や会

前回のエントリもずいぶん多くの方に読んでいただいたようで、大変驚いております。 kawaguti.hateblo.jp さらに、いただいたフィードバックから、もう一点補足した方がよいかなと思いまして、このエントリを書き始めました。補足の補足ですみません。 リーダーがITを学ぶのが早いか、IT技術者が経営を学ぶのが早いか 前回、IT技術者ではないキャリアを歩んでいる方々がプログラミングを学んだ事例としてジャパンタクシーの川鍋社長のエピソードと、若手向けプログラミング研修の例を出しました。 ビジネスマンがプログラミングを学ぶ価値 アジャイルジャパン2018で、ジャパンタクシーの川鍋社長が話していたことが印象に残っています。川鍋さんは正月休みを利用して、１週間詰め込み型のプログラミングスクールに行き、Railsを使ったプログラミングを学んだそうです。そこで発見したのは、「一文字間違えただけでも動

昨日のエントリは思いがけずアクセスをいただきまして、はてブのホッテントリにものったようで、驚いております。ありがとうございます。ここのところお腹の中にぐるぐるしている思いを新年にかこつけて吐き出した記事で、切れない「なまくら刀」のような後味で申し訳なく思っております。 kawaguti.hateblo.jp この記事の中で、業務知識という言葉の定義を曖昧なままに使ってしまって、ブクマコメントで「業務知識とはだな...」というご教示をいくつかいただきました。ご指摘ありがとうございます。 SIerで業務知識といえばお客さんの業務に関する知識 システムインテグレーター(SIer)方面の方は「(自分たちはIT知識を持っている前提で)、ユーザー企業の人が持っているべき知識のことを業務知識と呼ぶ」という認識なのだろうと認識します。そういえば、10年以上前になってしまいますが、業務知識はSIerに必要か

Beyond Legacy Code の著者、David Bernstein (@ToBeAgile ) さんの記事を翻訳しました。ソフトウェアエンジニアは新しいことを常に学ぶ必要性がある、 それはなぜか、というお話です。 David  さんは DevOpsDays Tokyo 2019 (4/9-10) の 基調講演で来日予定です。 Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software 作者: David Scott Bernstein 出版社/メーカー: Pragmatic Bookshelf 発売日: 2015/08/03 メディア: ペーパーバック この商品を含むブログ (1件) を見る ソフトウェア開発における学習曲線を受け入れる David Bernstein著 -

外から見ていると、難易度の非常に高い達人の仕事でも、さも簡単にやっているかのように見えてしまう。....これを思い出すような体験をしたのでメモしておく。 スクラムの改善ワークショップで.. こないだ、旧知の方が勤めるある会社さんで、スクラムの基本を紹介するセッションをやった。３時間半から４時間で行うそのセッションでは、ピンポンゲームを使って、改善の仕組みを学んでいただくことが多い。今回はその旧知の方がピンポンゲーム体験済みだったので、ゲームの参加者グループからは外れてもらい、外部からの視点で見ておいてもらうことにした。 一通りゲームが終わり、全体のふりかえりをすることにした。協調問題解決の練習の一環として、参加者全員でそれぞれ気づいたことを付箋に書き出し、全体でまとめていくというプロセスをとる。まとまった付箋について、誰かに立候補してもらって、外側の人間(講師である私)に対して説明していた

Fearless Change のパターンリストを A4 x 2枚 のシートにしました！ PDFファイルはこちらです。 Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン 作者:Mary Lynn Manns,Linda Rising出版社/メーカー: 丸善出版発売日: 2014/01/30メディア: 単行本（ソフトカバー）Fearless Change: Patterns for Introducing New Ideas (English Edition) 作者:Linda, Ph.D. Rising,Mary Lynn, Ph.D. Manns出版社/メーカー: Addison-Wesley Professional発売日: 2004/10/04メディア: Kindle版