イベントスクラムガイド漫画コミュニティメニューMJ私は日本で活動しています。後にどこかで私たち人間という動物は、自然と目先のことを優先的に考えます。今この場で起きていることに囚われてしまいがちです。人の生活がまだ単純だったころは、これでよかったでしょう。私たちがとる行動は、ときに普段あまり考えていないような結果を伴います。これは、時間(時間が経過した後に発生する場合)、あるいは距離(離れた場所で発生する場合)によるものです。私たちがとる行動が、思わぬときに思わぬところで、あまり関わりのない人やものごとに影響を及ぼすこということです。この盲点は、局所最適化バイアスと呼ばれることがあります。例1次の動画では、典型的な組織での局所最適化が見られます。管理者は、包装されていないチョコレートが隣のラインに混入しないように従業員に指示します。問題なくできています。被害を及ぼしてしまいます。これは滑稽な動画のはずですが、あなたの会社では毎日のように似たようなことが起こっているので、真剣に受け止めてください。例21980年代に、私はしばらくの間IT部門に配属されたことがあります。IS&C在籍中の私の仕事には、エンジニアリングチームが使用したいツールを購入できないようにするということが含まれていました。いうのは、IS&Cは「ほぼ同じ」機能を持つわずかに安い代替品を大量購入することにより経費を節約できる、そして扱いにくいUnivacメインフレームの使用を強制させることにより、全てのデータをコントロールできると考えたからです。したやり方は合理的で、場合によっては正しいこともあります。私の上司は、彼自身の上司に対して自分たちがどれだけ会社の経費を節約したのかを示すレポートを作成しました。この上司のような人々は、自分たちは正しいことをやっていると思いながら定年退職したでしょう。経費をごくわずかに節約するという私の過去の行いが、長期的にはかえって害をなしていたいうことを、私は今になって悟りました。「安物買いの銭失い」は、局所最適化バイアスの一例です。数字の読めないやつは話にならない。数字が見えない現場もいかん。数字しか見ないやつが一番いかん。例3初心者のスクラムマスター(本の著者を含む)は、製品開発組織の教育を改善したり、チームの適応力向上を支援したりするのではなく、単に超生産的(hyperproductive)なチームを作ることに躍起になっています。ソフトウェア開発について深く理解していない人は、大規模なアジリティは複数の「超生産的」なチームの作業の総計だと考えるかもしれません。論理的に思えるかもしれません。馬の足が早ければ早いほど、馬車も速く進むと考えませんか?しかし、賢明な読者のみなさんは、ソフトウェア開発は馬車を引っ張る馬とはわけが違うことは理解しているはずです。全体像を見ると、超生産性を目指そうとする人はだれもかれも、より速い会社ではなく、とてつもない混乱を創り上げるだけです。これでは競合他社に勝つことはできません。局所的な最適化しか行わないスクラムマスターは、まさに大規模なアジリティの大敵です。局所最適化の例がありましたら、ぜひご連絡ください。次へ関連記事スクラムマスターやプロダクトオーナーは、コーディネーター(調整役)ではありません。スクラムおよびLeSSでは、(開発)チームはクロスファンクショナル(機能横断的)であり、自己を管理します。スクラムマスターやプロダクトオーナーではなく、チーム自身が調整や統合を行います。パート1各役割における特徴と責任を特定してください。この練習問題は、匿名で何回でもお試しいただけます。CSMテストには、どのようなトピックが出題されますか?CSM候補の方々の中には、ScrumAllianceの新しい認定テストに若干の不安を抱えている人もいらっしゃると思います。この認定テストを安心して受けていただけるよう、テスト準備のお手伝いをさせていただきます。クイックスクラムクイズ1これはバージョン0.2です。改善にご協力ください。