RSGT2020勝手にプロポーザル紹介（1日目）

約1週間前の8/5（月）に始まった、Regional Scrum Gathering Tokyo 2020の公募。本稿執筆時点で、既に60件ものプロポーザルが登録されています。

今日Facebook上でやっとむさんと雑談していたところ、

プロポーザル出した人が「私はこれも面白そう」って他の紹介をするコーナー、とかあったら面白いかなあ

という話が出たので、早速実験してみることにしました。

その前に自分のプロポーザル紹介！

私たちLINEのSETチームが実施した／している様々な改善施策を、特に技術面から整理して、皆さんの日々の仕事に活かせる知見として紹介されていただきたいと思っています。

発信内容のクレディビリティを高めるため、同僚の高橋勲さんと一緒にお話しさせていただきたいなと。

ちなみにこのプロポーザルは、来年夏にアメリカで開催されるAgile2020向けに現在執筆中の論文の内容をある程度含みます。Agile2020で発表予定（希望的観測）の内容を、日本語で事前に聞きたいという方がいらっしゃれば、是非とも投票していただきたいです。

おすすめプロポーザルの紹介

ここからが本編です。

アメリカのアジャイルカンファレンスでワークショップ枠で登壇された経験をお持ちの、まさにワークショップの達人のやっとむさんによるプロポーザルです。

ここ最近、各イベント・カンファレンスでワークショップブームが来ています。そのブームを一過性のものとするのではなく、継続的に活用できるツールとする観点から、ワークショップの本質を学べる場としてこのプロポーザルを推したいです。

ここ数年彗星のように現れた、ニュースターの森さんによる、ふりかえりをさらに深く追求するワークショップです。

森さんは、真摯にふりかえりの研究にフォーカスし続け、技術書典などでも出版をされている、非常にエネルギッシュな方です。

イベント・カンファレンスに参加しただけでは満足せず、自ら発信する側に回り、日々自身のアイデアを洗練されているその姿勢に、個人的に強い共感を持っていまして。是非とも「次は自分が登壇する！」という方に参加してもらいたいプロポーザルです。

元同僚のさとりゅうさんによる、OSSへの貢献の仕方を実体験できるワークショップです。

さとりゅうさんは様々なOSSにコミットされていて、かつOSS Gateという取り組みにも関わられています。

最近日本のアジャイル系カンファレンスで技術が語られなくなりつつある傾向があるようですが、アジャイルが目指すソフトウェア開発の改善に、技術は必須だと私は考えています。そのような立場から、ぜひこのプロポーザルを推したいです。

アジャイルによる改善を続けていった結果、会社の枠を飛び出してチームごとのFA移籍を実現された、及部さんによるAdvancedなプロポーザル。

実は及部さんは、私にとっての（一方的な）ライバルであり、アジャイルとイベント登壇の仕方を教えてくれた師匠でもあります。

皆さんは及部さんの「派手さ」に目を奪われがちかも知れませんが、彼の積み重ねてきたものは、非常に堅実かつ理にかなったものです。私がアジャイルメトリクスを活用したり、施策の成果を見えやすくしてステークホルダーたちの協力を得るような工夫をしているのは、いずれも及部さんから「盗んだ」ものです。

是非皆さんにも、「派手さ」の裏にある、物事を動かす本質とこれまで生き抜いてきた「ガチの」知識・経験を盗んで、ソフトウェア開発業界にカネの雨を降らせてもらいたいと、強く思う次第です。

私の師匠であり、また日本人で一番スクラムに詳しい（by James Coplienさん）原田騎郎さんによる、Kaizenの本質に迫る内容。

このセッション、過去に私も参加させていただいたことがあるのですが、非常に簡潔かつ分かりやすく、アジャイル実践者として絶対に外してはならないポイントを教えてくれます。ちなみに私は、このセッションで学んだ内容を常に意識しながら、日々仕事を続けています。そういう意味では、一生モノの体験を得られる場になると思います。

つづき

次は、やっとむさんにバトンをお渡しします〜

こちらです。 yattom.hatenablog.com

ユーザーストーリーのフォーマットの小ネタ

Scrum Alliance の共同創設者の一人で、『アジャイルな見積りと計画づくり』などの著書でも有名な Mike Cohn さんが、ユーザーストーリーのよくある "As a xxx I want to xxx so that xxx" のフォーマットのポイント・長所・短所を、下記のブログにまとめられています。

内容は各自で読んでいただくとして、今回はこのフォーマットにまつわる小ネタを3つご紹介します。

1. フォーマットの名前

なぜかグーグル検索でヒットしづらいですが、名前は「Connextra」ないし「Connextra Format」です。

下記の書籍の著者の一人、Rachel Davies さんの発案によるものです。

アジャイルコーチング

※しれっと前書きを書かせていただいています。

2. 会話を始める「ポインタ」として活用する

このフォーマット（と実際に書くふせん）ですと、ユースケースシナリオのように細かい点まで書き切ることは難しいです。

これは一方で、チームメンバー・PO・他のステークホルダーたちと会話をするのに十分な情報に絞って書き、会話を促す道具として使った方が有効だという見方もできます。

会話によって、認識の違いや新しい情報が出てくることが多いので、「完璧な仕様」を作ろうとすると、無駄な作業になりがちです。

Outcomeに注力するという意味でも、このフォーマットはなりに意味のあるものだと言えます。

※この情報は、Jeff Pattonさんの研修＆対話の内容が大きなベースとなっています。

3. 書く順番は変更しても良い

テスト手法の一つの BDD (Behavior-Driven Development) では、 "In order to xxx" から書き始めることを推奨している書籍もあります。これは、ユーザー視点から考え始めることで、そのテストの目的を明確化しやすくなるからです。

BDD in Action: Behavior-driven development for the whole software lifecycle

ソフトウェア開発者の評価指標を考えてみた2019

私の勤めている会社は、ちょうど今が（人事）評価の時期です。 今日もチームメンバーと「どんな評価指標を使うのが良いのか」という雑談をしていたのですが、その内容が他のチーム・会社でも使えそうな気がしたので、ブログにまとめてみました。ちなみに雑談のまとめなので、あくまでアイデアの1つとして読んでいただければ幸いです。

ちなみに評価対象は、ソフトウェア開発に関わる人、具体的にはプログラマ・インフラエンジニア・QAあたりを想定しています。

1. ダメな評価指標例

まずは、「これは（アカン）」というものから。

(1) プログラム・コードを作成・追加した行数

そもそも、「行数が多い == 生産量が多い」ではないです。

何も考えずに行数だけ増やしてしまうと、メンテナンスコストやバグの混入確率が増え、結果としてチーム・会社にマイナスになります。 （実際に学術的にも実証されています。）

(2) GitHubへのコミット回数

これも、「コミット回数 == ユーザーへ提供した価値」ではないです。

コミットをしただけでは、ユーザーへ何の価値も提供できていないので、評価指標としては使えないです。

(3) 稼働率

稼働率を100%に近づけるということは、それ以外のことをする余裕をなくすということです。

稼働率を高くすることは、チーム・会社にとっては明確なマイナスとなります（これも実証されています）が、不勉強なマネージャーにとっては魅力的な指標に映るのも事実です。

2. 評価指標を考えるための軸

上記のダメな例に共通しているのは、従業員・チーム・会社としてユーザーに提供する価値（outcome/delivery）の観点が抜けている点です。我々は、ユーザーに何らかのソフトウェアの機能を提供し、ユーザーからお金・情報などの対価をいただくことで、社会に存在しています。であれば、我々とユーザーとの接点となるoutcome/deliveryを軸に評価指標を考える必要があると考えます。

以下に、ポイントを列挙してみます。

1. ソフトウェアの機能は、リリースして初めて、ユーザーに価値を提供できる。
2. 従って、ソフトウェアのリリースに関するパフォーマンスを、評価の主軸として考えることには妥当性がある。
3. ソフトウェアのリリースパフォーマンスの向上と、組織のパフォーマンスの向上・従業員満足度との間には、正の相関があるという研究結果が最近出てきた。
4. 個人単位だけではなく、チーム単位でもパフォーマンスを見る必要はありそう。
   
   
   

3. 使いたい評価指標例

outcome/deliveryを軸に、使いたい／使ってみて効果のあった評価指標を、以下に挙げます。

ちなみに下記 (1) - (4) は、「4 Key Metrics」の名称で、世界的にも利用者が広がり始めています。 www.thoughtworks.com

(1) リリース頻度

「1日あたりのリリース回数をひたすら増やす」ではなく、「3ヶ月に1度リリースしていたものを、1週間に1度まで短くすることが出来た」というようなイメージです。

(2) 機能追加・変更のリードタイム

ユーザーニーズを把握してから、実際にユーザーに価値を提供するまでにかかる時間です。 ユーザーからのフィードバックを、迅速にプロダクトに反映できている指標にできます。

(3) MTTR (Mean Time To Repair)

障害・問題を発見してから、ユーザーに修正版を提供するまでにかかる時間です。 上述のリリース頻度と組み合わせれば、事実上の「品質の向上」とみなすことも可能かも知れません。

(4) Change Failure Rate

リリースしたものに、価値提供に致命的な問題（バグなど）が混入していた比率です。もちろん少ない方が良いです。

(5) Shift Left on Test

一通り開発を終えてから行うQAではなくて、開発より前のフェーズでどの程度テストに関するアクティビティを実践できているか？の度合いです。

要件定義やアーキテクチャ策定の段階から「テストのしやすさ」を組み込めれば、プロダクト開発の早期から「品質の作り込み」がしやすくなります。

また同様のことは、セキュリティや「リリースのしやすさ」についても言えるでしょう。

(6) Rework/Unplanned workの削減量

「品質」が悪いと辛いのは、ユーザーからの評価や利益が減ることももちろんですが、Rework/Unplanned workが増えてしまうことにも当てはまります。 つまり、Rework/Unplanned workを削減することは、QAないし品質に関わる全てのメンバーの評価につなげられます。

ただし、これを指標として使う場合は、テスト自動化・DevOpsは前提・必須となるでしょう。

(7) eNPS (Employee Net Promotor Score)

従業員やチームメンバーの満足度を測る指標の1つで、自分たちの部署およびチームを、友人や同僚にどの程度推奨できるかで計測できます。

詳しくは、こちらをご覧ください。 cultureiq.com

まとめ

• 自分たちは何を持って評価されるか？
• 自分たちは何を持って評価されたいか？
• 自分たちは何を持って他者を評価するか？

これらの問いは、仕事のしやすさやモチベーションにも直結するので、同僚や上司とできるだけ話をした方が良いです。

参考資料

上記の内容の多くは、この書籍を参考にしました。

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations (English Edition)

日本語版も出たようです。

LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する (impress top gear)

2014年にAgile Allianceに投稿した論文。論点が割と今と比較してもブレていなくて、自分でもびっくり。

https://www.agilealliance.org/wp-content/uploads/2015/12/ExperienceReport.2014.Ito_.pdf

長いミーティングの改善例

SNSに溢れる、日々の業務への不満。
その中でも、「ミーティングが長い」「ミーティングが多すぎる」は、皆さんも頻繁に目にされている／経験されているのではないでしょうか？

今回、業務で試してみて一定の効果が見られた、ミーティング時間の短縮の事例を紹介させていただきます。皆さんの不満を減らすヒントになれば幸いです。

1. 課題

複数チーム間で、お互いの進捗状況を報告・共有するミーティングにて。

• 報告の内容・粒度が、チームごとにバラバラ
• 各チームが、自分たちがやったことを事前にまとめたwikiを延々と読み上げていた
• 結果、時間内に終えられず、報告できないチームが出てきていた
• 回を追うごとに各チームの報告内容が長くなり、報告できないチームが増えつつあった
• ただwikiの内容を「聞かされる」だけで、何の意思決定も課題解決もできていなかった

そのため、主催者・参加者の双方が大きなストレスを感じ始めていました。

2. 分析

参加者の一人としてこのストレスを減らしたいと思い、このミーティングの課題を以下のように分析しました。

• 参加者全員が知る必要のない報告・情報が多い
• ミーティングで「やるべきこと」（＝ルール）が不明確である
• ミーティングの目的が不明確である

「本来は意思決定をスムーズに行いたいのに、そのために必要なものが欠けているのではないか？」

そのように仮説を設定した私は、次のような提案を行いました。

3. 対策

私が提案した内容は、以下のような「ミーティングの目的とルールの明確化」です。

• ミーティングの目的を、「チームをまたぐ意思決定を迅速に行うこと」とする
• 意思決定に必要な情報だけを報告することとする
• 各チームが実施したことは、wikiの共有だけとする（各自で読んでもらう＆ミーティングの場での朗読はしない）

また、上記提案を補強するため、私自身が毎回の報告で「具体的なやり方」を示し続けるようにもしました。

4. 結果

• ミーティングが短くなった／時間内に収まるようになった
• チームをまたぐ意思決定を、ミーティング中に行えるようになった
  • （例）提案採用の初回で5件
• 報告が短くなったことで、プラスアルファの情報を得られるようになった
  • （例）
    • Wikiに書ききれていなかった、各チームの課題（Impediments）
    • ミーティングに参加していない他チーム・部署の動向

結果として、このミーティングが「ストレスが少ない」「価値を生み出す場」になりつつあります。 また、このミーティングを参考にした結果、不要と判断されて中止になったミーティングも出てきました。

5. 今後に向けての課題・改善点

回を重ねると昔の癖が戻ってしまい、wikiを朗読し始めるような人がどうしても出てきています。

そのための対策として、いま以下のことを試しています。

• アラートとして、ミーティングの経過時間をメンバーに提示する
• ミーティングが長くなる兆候が現れたら都度、ミーティングの目的とルールを再確認する
• ミーティング用のwikiの冒頭に、目的とルールを明文化する

まとめ

我々が困っていること／疑問に思っていることには、探せば解決策が見つかるものが多いです。 色々と試してみると、解決できないと我々が「勝手に」思い込んでしまっているだけのものが、結構多いことに気づかされます。

今回の例は、「目的・手段を明確にすることで、outcomeを増やして無駄を減らした」ものですが、他にも方法はいくらでもあります。

他者のせいにすることはせずに、考え続けること。

これがポイントかなと、個人的には思っています。

Comparative Agilityどうでしょう

今年夏に参加したAgile2018で、縁あってComparative Agilityの日本語訳をさせていただきました。

※ Comparative Agilityのニュースページにも掲載していただいてます。

今回は、Comparative Agilityがどういうもので、どのように使えば良いのかを、ハンズオン込みで簡潔に説明します。

1. Comparative Agilityとは

Comparative Agilityは、自分たちのチーム・組織・会社のアジャイルの習熟度・成熟度を査定し、他社や業界標準との比較・分析を行うことで、どこをどう改善すれば良いのかのヒントを得ることができるオンラインツールです。

無料で利用することができますが、Scrum Allianceが深く関与していることから、CSP・CEC・CTC・CSTの保持者は、無料でプレミアム版を利用することができます。

（参考）Comparative Agilityの利用料金体系

無料版とプレミアム版との違いは、作成できるアンケートとレポート（後述）の数の上限です。

また、こちらの紹介動画も参考になるかと思います。

2. Comparative Agilityの使い方

それでは、早速使ってみましょう。

1) アクセス（アカウント作成含む）

まず、Comparative Agilityのサイトにアクセスし、右上の「My Account」をクリックします。

アカウントが未作成の場合は、このタイミングで作成します。アカウントを作成済みの場合は、ここでログインをします。

次の画面が出てきたら、アクセス成功です。

2) 習熟度・成熟度の査定

習熟度・成熟度の査定は、アンケート形式で行います。

a) まず「Collector（＝アンケート）」を作成し、アンケート用のURLをコピーします。

b) コピーしたリンクを、ブラウザで開いてみましょう。

c) 右上で日本語を選択できると良いのですが…本稿執筆時点では出来ませんorz

そこで、下記の例のように、URLの"en"を"ja"に変更してみましょう。
https://www.comparativeagility.com/survey/0fc24a7843c4bd45e8e5baa298d839bb662cd64d/en/Ca
　　　　　↓
https://www.comparativeagility.com/survey/0fc24a7843c4bd45e8e5baa298d839bb662cd64d/ja/Ca

すると、日本語で回答できるようになります（今回私たちが翻訳した部分です）。

d) 回答を終えると、この画面が表示されます。

e) Collectorを確認すると、回答が1つ増えていることを確認できます。

3) 査定結果の比較・分析

アンケート結果が溜まってきたら、他社や業界標準との比較・分析をしてみましょう。

a) まず「Analysis」タブを選択し、アンケート結果と比較対象を選択し、レポートを生成します。今回は、Comparative Agilityが初めから用意している全世界の情報と比較してみます。

b) このようなレポートが生成されます。

c) 自分たちのチーム・組織・会社の全体像を把握できます。

d) どの項目に改善の余地があるのかを、このように確認できます。

この例では、ペアプロやリファクタリングをあまりやっていないことが白日のもとにw

e) レーダーチャート形式での確認も可能です。

4) 作成したレポートの再表示・修正

一度作成したレポートは、「Analysis」タブから再表示・修正が可能です。

3. （おまけ＆実験）ハンズオン

どんなツールも、慣れるには実際に使ってみることが一番です。

そこで今回、皆さんがお試しで回答できるアンケートを作成してみました。 URL : https://www.comparativeagility.com/survey/3de9280772f8d1df9d0eb137114be2009fcb98d8/ja/Ca

試しに、自分たちのチーム・組織・会社がどういう状態にあるのか、適当に回答してみてください。

• こちらから回答者を特定できないことは確認済です。

• アンケート結果が5件以上集まったら直ぐ or 2019年1月4日までに1件でも集まったら、レポートを公開します。

4. （おまけ）翻訳の経緯

Agile2018 3日目夜のパーティで、Scrum Allianceのスポンサーブースをたまたま訪れたところ、Comparative Agilityの作成者の一人のAlmir Drugovicさんにお会いしました。

私もComparative Agilityをたまたま試していたため話が弾み、気がついたらAlmirさんから「日本語訳をやってみませんか？」とオファーをいただいていました。

せっかくの機会なので、他の日本人のカンファレンス参加者にもこのオファーを話してみたところ、川口　恭伸さんと横道　稔さんが手を挙げてくれ、3人で協力して翻訳した次第です。（川口さんのレスポンス速度＆翻訳量が尋常ではなかったことは明記せねばなるまい。）

こういうチャンスがあちこちに転がっているのも、海外カンファレンスの醍醐味です。

Agile2018ふりかえり

Agile2018が開催されたSan Diegoの風景。真ん中の建物が会場のホテル。

もう年の瀬ですが、夏に参加した大きなイベント「Agile2018」の話をあまりしてこなかったことに気づいたので、忘れる前にまとめてみました。

1. 資料群

1) 速報レポート（スライド・英語）

This is a flash report of Agile2018 by The HIRO! from LINE Corporation

本当はSlideshare上のタイトルも「From Output to Outcome」にしたかったのですが、社内手続きのミスが重なったため、そのままとしています。

2) 詳細レポート（ブログ・英語）

上記1)の速報レポートでは書ききれなかった、参加セッションの詳細や、参加者とのディスカッション内容などをまとめています。

3) 報告会＆Togetterまとめ

Agile2018の日本人参加者4名＋αが、各々の視点で整理・報告したイベントです。

2. カンファレンストピック

上記資料群でも触れていますが、「Business Agility」「Outcome」といった言葉が、ほとんどのセッションで頻繁に言及されていました。 要は、開発チーム内の改善に閉じるのではなく、経営層も広く取り込んだ改善を行い、ビジネス的な成果の実現・達成に視野を広げていくべきだ、という考え方です。

一方で、議論の多くが抽象論に止まっていて、具体的な方法論や事例についてはまだまだ「浅いな」とも感じました。

これを「面白くない」と考えるか、「チャンス」と考えるか。

答えは、皆さんの手に委ねられています。

3. 今回の工夫点

私は今回で6回目の参加になります。そのため過去の経験を活かし、今回は次のような様々な工夫を凝らしてみました。

1) 速報レポートの高速リリース

上述のスライドの公開日付を、改めてご確認ください。カンファレンスが終了したのが8/10（金）で、スライドの公開日が8/13（月）。つまり、カンファレンス終了・帰国後の最初の営業日に公開しています。

これは、カンファレンスの開始前から狙っていた目標でした。

これを実現するために私は、次のことを実施しました。

• 全てのセッション情報を事前に一通り確認し、全体的なテーマ・トピック・トレンドの仮説を立てておく。

• カンファレンスの場で各セッションに実際に参加し、上述の仮説が正しいかを確認。外れていれば即ピボット。

• カンファレンスの参加者・スピーカー・知人にスライド案を毎日レビューしてもらい、常に最新の状態をキープ。

  • Woody Zuillさん・Chris Lucianさん・David Bernsteinさんら、多くの方にご協力いただきました。

• 帰国後、社内のDevRelチーム（＝技術広報）に即日レビュー依頼し、即日リリース。

  • DevRelチームの迅速さ・柔軟さに、大いに助けられました。

また、スピードを重視するために、速報レポートでは全体像の説明に絞り、各セッションの詳細は後日ブログで発信することにしました。

2) 報告イベントの高速実施

速報レポートを予定通りリリースできたので、次は報告イベントの早期開催に動きました。

ここで意識したことは、次の点です。

• カンファレンスが開催された8月中に行うこと（ここでもスピード重視）

• 日本からの参加者たちの中で、一番最初に報告会を行うこと（インパクトを狙いました）

• 他社の参加者も巻き込むこと（報告の多様性の確保＆各社とのWin-Winな関係の構築）

おかげさまで、定員の倍近い応募をいただくことができました。

3) レポートの英語化

スライドもブログも英語で書きましたが、これは次のことを狙っていました。

• カンファレンスのリアリティ・臨場感を読者の皆様にお届けすること

• 全世界向けに情報を発信すること

• 社内の英語圏の同僚にも読んでもらうこと（今後の仕事のプラスにするため）

ただ…日本でのビュー数が全然伸びなかったので、これは失敗だったかなと思っていますw

おしらせ

来年のAgile2019のセッション公募が始まっています。我こそはという方は是非！

技術面に特化したカンファレンス「deliver:Agile 2019」のプログラムが公開されています。

Facebookに、アジャイルカンファレンス参加者用の専用グループ「Let's go to the Agile Conference Group」を用意しています。興味のある方は、是非ご参加ください〜

ストレスは「受け容れる」と改善するらしい

9月に入ってから、右腕と右脚に痛みや麻痺の症状が出てきたので、JR東京総合病院（AH東京総合病院とも云うらしい）で検査を受けてきました。
一時は脳梗塞を疑われたのですが、7時間に及ぶ検査の末、

• 右肩・腕の神経の損傷（電車のつり革につかまっている時に負傷したと思われるとのこと）
• 仕事での過労やストレスで体が拒否反応を起こしている

ということが分かりました。確かにここ数ヶ月、無茶な仕事をいくつもこなしていたぞ（白目）

ところで、今回診察していただいた医師から、興味深い指摘をいただきました。
曰く、「ストレスは我慢したり無視するのではなく、ストレスだと認めた方が解決が早い」と。

何でも人間は、病気や不調があった場合、それを特定できないと、どんどん心理的に自分を追い込むと。特にストレスが原因の場合、今の西洋医学のあり方では原因がそれと言いづらいことが多いため、結果より自分を追い込み、結果鬱などへ深化してしまうと。

一方で、ストレスが原因であると自分ではっきりと認識するようにすると、そこで自分を追い込むプロセスが止まるため、症状の悪化が止まることが多いのだとか。

私はここ半年ほど、マインドフルネスを活用して、ストレスをすぐに軽減するようにしてきたのですが、それ以上に仕事をしていた・多くの人の相談を受けすぎたことに気づきました。「生産性」を単に増やせばよいということではない。自分のキャパシティを知り、その範囲内でパフォーマンスを最大化すること。それが大事。

常に自分以外を優先する生き方では死ぬので、折り合いをつけないとですね。

PS

• しばらく右手がダメなので、タイピングが遅くなります。
• XP祭り2018でやる予定だったAgile2018の報告会は、体調が回復したら、それっぽい場を設けて実施します。