Regional Scrum Gathering Tokyo 2019 ディスカウントコード問い合わせの例文

Regional Scrum Gathering Tokyo 2019 チケット販売スケジュール - kawaguti’s diary

会員だしディスカウントは受けたいけど、英語が不安だという方はこの例文を参考にしていただければと。

Hello Scrum Alliance,

   I hope to attend Regional Scrum Gathering Tokyo 2019.
   Please let me know the discount code for this conference.

   My name : Yasunobu Kawaguchi
   My registered e-mail : kawaxxxx@xxxxx.com
   My member page : https://www.scrumalliance.org/community/profile/ykawaguchi

Best Regards,
Yasunobu Kawaguchi
CSM/CSPO/CSP-SM/CSP-PO

楽天を退職します。

9月末日をもちまして、楽天株式会社を離れることにいたしました。

2012年4月に入社しましたので、6年半の間、お世話になったことになります。アジャイルのトレーナーやコーチとして各部門のチームをお手伝いさせていただいたり、外部のスペシャルなトレーナーの研修を運営したり、楽天テクノロジーカンファレンスを運営したり、新卒研修をやったり、ラッカソンをお手伝いしたり、英語公用語化のコンサルをしたり、本当に色々とやらせていただきました。こうしてふりかえってみると、あまり前例のないことを、思い切って任せていただいた件ばかりで、ご信頼をお寄せいただいた皆様には、感謝の念にたえません。

今後はしばらくお休みをいただきながら、次のステップを考えていくつもりです。この機会に話したい！という方がいらっしゃいましたら、ぜひお声かけくださいませ。

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

ユーザーストーリーマッピング

ジョイ・インク 役職も部署もない全員主役のマネジメント

Software in 30 Days スクラムによるアジャイルな組織変革"成功"ガイド

アジャイルエンタープライズ (Object Oriented SELECTION)

どうしたら実現できるのか？

どうしたらこれを実現できると思いますか？って聞かれたりすることがあったりします。割とシンプルで、

• 具体的にする
• 許容量以内にする
• 期間を十分にとる

ぐらいしかなさそうです。スコープとリソースとスケジュールですね。

スコープはだいたい曖昧性が敵で、なんで曖昧かというと、知らないからとかやったことがないからということが多そう。

許容量はそもそも把握できてないことが多そう。ベロシティですね。

期間が足りないのは、上の二つの理由がやっぱり引き起こすんですけど、もう一個あって、気づくのが遅くて動きはじめるのが遅かった。

で、基本的にはやることを最小にして、効果を最大にするってことをずっと考えて、日々やってくしかないかなぁ、という気もします。

あと、ちょっと危険なのが、将来の頑張りの経験的見積もり。苦労の記憶はみんな大好きなので、精一杯やって克服したことを再現したくなるんですけど、２回目も同じことやってたらアホなわけです。実績値を持って改善するのがよさそうです。学びこそすべて。

Regional Scrum Gathering Tokyo 2019 チケット販売スケジュール

 (スクラムギャザリング東京実行委員会より)

Regional Scrum Gathering Tokyo 2019 (2019/1/9-11) の
チケット販売スケジュールは以下の通りといたします。

1. October Ticket (10/1-10/31)
2. November Ticket (11/16-11/30)
3. December Ticket (未定 確定: 12/11 12pm JST)

チケット料金 JPY30,000 + Fee
Scrum Alliance 会員の方は10% Off (Scrum Alliance から別途アナウンスがあります) 

セッション公募期間は October Ticket 販売期間と重なりますが、落選の方には November Ticket 期間に、 November Ticket とは別途チケットをご購入いただけますので、先行して購入する必要はございません。なお、スピーカー採択された場合の購入済みチケットの払い戻しはいたしません。

Powered by Eventbrite

というブログ部品を置いてみるテストでした

属人性があって再現性がないからスケールしない話

研修とかコンサルみたいなことをやってると属人性があってスケールしないからきついねーって話になったりします。新規事業開発のミッションとしてはもう10倍くらいは最低でも稼がないとだめで、誰に言われなくてもそう思うんだけど、一方で...。

客商売なんてものは、目前のお客に何を気に入ってもらってお金をいただくかなので、再現性なんてそんなにないものだとも思うんですよ。再現性はない....けど、類似のお客様がいれば水平にリピートオーダーは広がる...というものなんじゃないかと。(営業経験あんましないので自信がない)

求められる信頼・期待に対して、提供できる便益と価値のマッチングが毎回あるわけです。

簡単に売れて行くキラーアプリが生み出せるといいんですけど、それには業務知識の蓄積と、技術と、ものすごいタイミングが必要で、そのどれも不足してるときに、蓄積しながらタイミングを待てる技術もまた、大事なんじゃないかと。

「こういうのが欲しいんです。」「そうですか。じゃあそういうの作ります。」「いいですね。使います。」なんてなったの見たことないんです。そこそこうまくてきたとしても売れたのは見たことない。要求がザルだったり、業務知識が足りなかったり、作れなかったり、そもそも時期がダメだったり ... 。

だから、調べながら作りながらもがく。カッコ良くもないし、理想的でもないし、いろいろ言われたりするけど、たぶん蓄積は味方だから。だんだんわかっていくのも楽しいですし...。

はじめからスケール前提でドーンといけるソリューション考えるのキツイと思うんです。少なくとも私にはきつい。なので、細い糸を手繰りながら、しばらく泥の中を泳がないと...。

未来に発展も変革も無いと信じる理由は無いのである

(ハリー・セリンジャー監督からの引用。ハイキュー21巻第187話)

でもまぁ、本当は、もっと楽にポーンと行きたい...です。

Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)

ユーザーストーリーマッピング

ハイキュー!! 21 (ジャンプコミックス)

よい仮説とは棄却しやすいものである

昔社内勉強会で読んだ本で、よい仮説の話があって、今日ちょっと質問を受けたので、その部分を第2版から抜き書きしました。いや、勉強になった。

（読んだというか、統計に詳しい後輩の人たちに教えてもらう会でした。）

Karl Popper was the first to point out that a good hypothesis was one that was capable of rejection. He argued that a good hypothesis is a falsifiable hypothesis. Consider the following two assertions:
1. there are vultures in the local park
2. there are no vultures in the local park
Both involve the same essential idea, but one is refutable and the other is not. Ask yourself how you would refute option A. You go out into the park and you look for vultures. But you do not see any. Of course, this does not mean that there are none. They could have seen you coming, and hidden behind you. No matter how long or how hard you look, you cannot refute the hypothesis. All you can say is "I went out and I didn't see any vultures." One of the most important scientific notions is that absence of evidence is not evidence of absense.

[ざっくり翻訳]

Karl Popperは、よい仮説とは棄却可能なものであることを最初に指摘しました。 彼は良い仮説は偽にできる仮説であると主張しました。次の2つの言明を考えてみましょう。
　A.近くの公園には大鷲がいます
　B.近くの公園には大鷲はいません
どちらも基本的な考え方は同じですが、一方は反駁可能であり、他方は反駁的ではありません。 どうやったらAを否定できそうか、考えてみてください。あなたは公園に出て、草原を探します。しかし、あなたは何も見ませんでした。もちろん、これは存在しないという意味ではありません。大鷲はあなたが来たので、見えないところに隠れたのかもしれません。 あなたがどれほど長い時間を費やし、頑張って探したとしても、仮説を否定することはできません。 あなたに言えることは「私は行きましたが、いかなる大鷲も見ませんでした」ということです。 最も重要な科学的考え方の1つは、証拠がないことが不在の証拠ではないということです。

 棄却しやすいのに棄却されないとなれば、その分、仮説(インサイト)としては強そうです。「全ての人が朝歯磨きをする」という仮説は一人でも歯を磨かない人がいれば棄却できます。それなのに、ずーっとインタビューしても否定されないとなれば.... その仮説の有効性にはかなり自信を持つことができるんじゃないでしょうか。(以前テレビでインド人は夜カレーを食べる、というのを数十軒回って証明してまして。正しくないにしてもインサイトはあるもんだなと思いました) 逆に、歯を磨かない人もいるよね、というのは、調べるまでもなく、正しそうです。そこにインサイトはなくて。ある属性の中で、80%の人は歯を磨く、というのも意味がありそう。そうやって、属性を絞っていって、80%の人がやるような行為が見つかれば、なんかできそうな気がします。

Statistics: An Introduction Using R

ポジティブふりかえりマッピング

アジャイルバンクーバー2010で行われた、リンダ・ライジングさんのポジティブレトロスペクティブと、ジェフ・パットンさんのユーザーストーリーマッピングを活用したふりかえりについてのブログエントリの翻訳です(著者のSteve Rogalskyさんの許可をいただきました)。翻訳にあたっては高橋陽太郎(@poohsunny)さんにレビューのご協力をいただきました。ありがとうございました。

 

ポジティブな点を述べることで「行った事実」にフォーカスできることと(課題を言うとwishが増える)、インデックスカードで整理する手法を組み合わせているところがよいなと思いました。

 

原文はこちら

Agile Retrospectives - a Rising Patton Fusion

http://winnipegagilist.blogspot.com/2010/11/agile-retrospectives-rising-patton.html

 

アジャイル・レトロスペクティブ - リンダ・ライジングとジェフ・パットンの融合

 

アジャイル・バンクーバー2010の最後のセッションは、リンダ・ライジング(Linda Rising)さんがアジャイル・バンクーバーのオーガナイザーたちとカンファレンスのレトロスペクティブ(ふりかえり)をする....ところをみんなで見る...というユニークな機会でした。彼女がどうファシリテートするのかを見るのは面白く、私はいくつかのテクニックを持ち帰って試せるよう、メモしました。翌日のチュートリアルでは、ジェフ・パットン(Jeff Patton)さんが彼のストーリーマッピング手法を組み合わせ、興味深いミニ・レトロスペクティブを指導しました。二人の手法の融合はどんな結果になるでしょう？

 

注意：このレトロスペクティブは、インデックスカードを活用して、机の上でアイデアを簡単に並べ替えたりグループ化します。壁とポストイット使う場合でも、少し工夫すれば大丈夫です。

 

ステップ1 - トーンを設定する：

Norm Kerth*1の最優先指令(prime directive)*2 を思い出します。（リンダはこれを暗誦してました）：

どんな道をだどったにせよ、当時の知識・技術・能力・利用可能なリソース・状況の中で、みんなができる限り最高の仕事をしたはずです。それを心から信じます。

これを復唱したら、レトロスペクティブの間、この声明を支持し、非難なし(No Blame)ルールに同意するかどうかを、チームメンバー一人一人に尋ねます。簡単に「はい」と合意を示してもらえばOKです。「口に出して合意する」ことは、ふりかえりのトーンを設定するのに役立つ、簡単で影響力のある戦略、ないしパターンです。

 

ステップ2 - レトロスペクティブのフレーミング：

ファシリテーターは、あなたの会社の廊下で同僚に会ったというストーリーを話します。同僚からの「あなたはプロジェクト[X]にいますよね。プロジェクトはどうでしたか？」という質問に対して、それぞれのメンバーが「...という点が素晴らしかったです。」と答えます。大声で応える代わりに、各人に3枚ずつインデックスカードを渡し、黙って答えを書いてもらいます。こうすることで、人々の性格に関係なく各人から意見が出るようになり、回答があなたの影響を受けてしまうのも避けられます。

 

各人がそれぞれ3枚のカードを記入し終えたら、各カードを読み上げながらテーブルに置いていきます。すべてのカードがテーブルに置かれたら、各テーブルで黙って答えをグループ化しました。内容が近いカードは近い場所に動かし、内容が異なるカードは離します。 パットン氏によると、この作業を黙々とやるのは、そのほうが(話しながらやるよりも) 作業が迅速になり、多面的に整理されるからです。私たちの作業でも、その通りになりました。

 

「よいこと」がグループ化されたところで、別の色のインデックスカードを使って、各グループの要約をつけます。例えば、「一緒にうまく作業できた」「ボブが私の仕事に協力してくれた」「チームはストーリーを完成させるために団結した」といったストーリーを「素晴らしいチームワーク」と要約しました。

 

ステップ3 - ほかの方法：

先の声明で、「直近のプロジェクトやイテレーションはよいものだった」と合意しているので、もし全く同じ方法でもう一度やったなら、かならず完璧なプロジェクトになるはずだ、という点をチームに思い起こしてもらいます。でも実際は、他にもやり方があるものです。そこで「ほかの方法」の案を考え、一人3枚以上のインデックスカードを黙って書くようチームに依頼します。非難や間違いの指摘、問題解決の試みなどは書かないようにします。このステップでは、ほかの方法にはどんなものがあるか、見つけたいのです。

 

全員がカードを完成させたら、テーブルに置きます。そしてまた、みんなで黙ってグループ化し、別の色のインデックスカードに要約を記入します。ファシリテーターは、チームがカードを読んだり要約している間、問題解決や非難をしないよう、繰り返し指摘する必要があるかもしれません。

 

ステップ4 - 投票：

次のステップでは、チームが「ほかの方法」リストのどの項目が最も重要かについて合意します。公平で公正な投票のために、各メンバーには、上位３つの項目をインデックスカードに記入してもらい、ファシリテーターに集めます。ファシリテーターは投票結果を集計し、要約カードに投票数を記録します。ドット投票を使用することもできますが、私はドット投票があまりに簡単に「攻略される」ことと、最初の投票が後で投票する人々に影響することを発見しました（グループ思考）。

 

ステップ5 - 実験：

上位一位ないし二位の投票項目について、グループを分けて議論します。1項目につき1つのグループに分かれます。グループごとに、次のイテレーションで試せそうな小さな実験や調整を議論します。頻繁にレトロスペクティブを実施している場合、問題解決や根本原因分析をする必要はありません。目標は、問題の解決に向けた小さな実験について、すばやく同意することです。根本原因分析の専門家には怒られるかもしれませんが、問題解決に深い洞察力を使う代わりに、チームで何ができるかを実験してください。この部分は最大10分または15分のタイムボックスに収めます。

 

次に行う実験を決めたあとで、各テーブルの誰かにアイデアを発表してもらいます。出てきたアイデアはイテレーションのバックログに入れ、（個人ではなく）チームとしてイテレーション中に実験をし、完了することをコミットします。

 

 

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

ユーザーストーリーマッピング

Project Retrospectives: A Handbook for Team Reviews (Dorset House eBooks)

*1:アジャイルのレトロスペクティブの源流になった "Project Retrospectives"という本の著者

*2:もともと第一原則と訳していたのですが、prime directiveはスタートレックの用語ということなので、そちらの訳 "最優先指令" に合わせます。安井力さん情報ありがとうございます。