The HIRO Says

If you smell what The HIRO is cooking!!!

【Appendix】RSGT2020での発表の補足

f:id:hageyahhoo:20200111122133j:plain

Regional Scrum Gathering Tokyo 2020、個人的には3年ぶりに参加&登壇させていただきました。

久々のRSGTは、私にとっては本当にキラキラした、極上の知的エンターテインメント空間でした。そのような空間を作ってくださった、運営委員・ボランティアスタッフの皆さま、参加していただいた皆さま、そして協力してくださった多くの皆さまに、心から感謝です。

さて、イベントを終えておよべさんと振り返り的な雑談をしていたところ、

初参加や初心者にとっては、上手くいった成果よりも、上手くいかない状況下をどのように考えて乗り越えていったのかの方をより聴きたいかも

という話題になりました。

確かにそれは一理あるなと思いまして、我々の発表での「上手くいかない状況下をどのように考えて乗り越えていったのか」について、補足資料的にまとめてみました。


(参考)発表資料&発表内容

プロポーザルと発表概要は、コチラになります。

発表資料はコチラです。

発表時のTwitterのタイムラインをまとめてみました。


上手くいかない状況とそれを乗り越えた例

1. 失礼なことを言われた時

正直いまでも、アジャイルやテスト自動化などに理解・関心のない人たちから、「あなた方の施策にメリットがあるようには思えない」「スキル不足をアジャイルという言葉で誤魔化しているだけでしょ?」などと言われることは、社内外関係なくあります。私は聖人君子からは程遠い人格なので、そうした言動に対しては、当然怒りやストレスは感じます。むしろ感じやすいタイプです。

しかし、怒りの感情に任せてこちらが暴れたりしたら、私たちを信頼してくれている上司・仲間を裏切ることになります。なので、怒りの感情をコントロールする必要が出てきます。

私の場合は、怒りを感じた場合は、すぐにその場を離れ、マインドフルネス呼吸で心を鎮めるようにしています。そして、心が鎮まってから、冷静な行動をするようにしています。ちなみにマインドフルネスは、継続していくと、ストレスへの対処能力・速度を高められます。ストレスへの対処は、スキルで伸ばせます。

私は下記書籍でマインドフルネスのスキルを日々高めています。

たった一呼吸から幸せになるマインドフルネス JOY ON DEMAND

たった一呼吸から幸せになるマインドフルネス JOY ON DEMAND


2. SNSで愚痴りたくなった時

上記の例とも関連しますが、時には怒りをぶちまけたくなることは、人間ならばどうしてもあります。特にSNSが普及した昨今は、怒りをSNSにぶつけることも容易です。

しかし、SNSでの愚痴は、自身の経験から、却ってストレスを増やしがちです。

そもそもネガティブな感情を持っていることが友人・知人など不特定多数に伝わるため、彼らを心配させたり、場合によっては不快感を与える可能性が高いです。さらに、会社の仲間・上司との繋がりがある場合は、信頼を失い、より辛い出来事を招きかねません。

なので、そもそも愚痴りたい状況が出てきたら、SNSを止めましょう。「SNSデトックス」は、今の時代だからこそ必要です。

3. 勉強不足を感じたり指摘された時

特に私の場合は、技術力の高いエンジニアに囲まれて日々仕事をしているため、「自分が彼らの役に立つことができるのか」という自問自答は日々あります。また、技術的に分からないことが多いと、そもそも話をさせてもらえない人もいます。

したがって、勉強は常に続ける必要があります。私の場合はComputer Scienceの知識が足りなかったため、オンラインで大学の授業を受講できるCourseraを活用して、エンジニアと話せる知識を貯め続けています。

また、技術の世界的トレンドを追う一環で、私はInfoQの記事をなるべく読むようにしています。

4. 提案に理解を示してもらえない時

「Scrumの採用を提案したけれども、上司から却下されました」という話は、世の中に溢れていますよね。当然私たちも、似たような経験をたくさんしてきています。

この点については、私は明確な解を持っています。やったこともないことやろうを提案するのではなく、成果を先に出して追認してもらうのです。勝手に施策をやることを咎められることは確かにたまにありますが、成果が出るかどうか分からないものにゴーサインを出してもらうよりは、よほどスムーズです。

また、提案・説得を試みるエネルギーを、「サクッと見せられる成果」を出すことに転用することで、「何を見せたら納得できるのか」「どうやれば短期間で見せられるものを作れるか」という発想ができます。実はこれ、Scrumやアジャイルの練習と言えますよね。なので、練習を兼ねて成果を見せて上長らをびっくりさせて喜ばせた方が、仮に失敗しても、チームとして得られるものは大きいですよ。

他にも色々と工夫・アイデアはあるのですが、長年の積み重ねで習慣化してしまっていて、すぐパッと言語化できない状況です。言語化でき次第、また追記します。

【Appendix】RSGT2020参加後の勉強・情報収集Tips

Regional Scrum Gathering Tokyo 2020に参加された皆さま、お疲れ様でした!

さて、参加された方たちから、「今後どのように勉強を進めていけば良いのか?」という質問を多くいただきましたので、私なりのオススメを軽く紹介させていただきます。今後のステップアップの参考になれば幸いです。

Scrumを実践する際の課題とその解決方法が簡潔にまとめられた良書です。
RSGTの実行委員の方の多く、また3日目のクロージングキーノートスピーカーの高橋さんが、2010年代初頭のScrum実践で参考にされていた書籍の1つです。また私も、アジャイルコーチを始める際に川口さんに叩きこまれたものです。非常にオススメです。

2日目のキーノートスピーカー、Michael Sahotaさんの書籍です。
アジャイルを普及させようとする際の、組織(文化)・マネージャー・メンバーなどとの衝突のパターンとその解決のヒントとを得られます。Sahotaさんの発表内容の源流を辿られたい場合は、一読をオススメします。

日本のアジャイル界のパイオニア、平鍋さんによる、アジャイルラクティスと技術とのバランスのお話です。どちらかだけではダメですよーというお話。ちなみに、Sahotaさんの上記書籍に基づいた、Agile2012でのセッションからインスパイアされたお話だったりします。

Scrumの理論的・概念的な背景・構成を、パターンランゲージで整理した書籍です。個人的には、初学者よりも、2-3年Scrumなりアジャイルを経験して、自分なりに課題発見・解決を繰り返した人が読んで考えるヒントを得られる書籍かなと思います。

Scrum Allianceの創設者の一人、Mike Cohnさんの会社のサイトです。このサイトの右下にある「Get Weekly Email Tips」をクリックして一通り情報を入力すると、毎週1-2回の頻度で、Scrumを実践する際にぶち当たりがちな課題とその乗り越え方を、メルマガ方式で購読できます。内容が平易なので、英語の勉強としてもオススメです。

ScrumMaster Personal Improvement
※動画です
Scrum Allianceの認定を取ると使える(らしい)、Scrum Alliance公式のツールです。以前私が日本語訳に関わらせていただいた、「Comparative Agility」の改良版とのこと。チームや組織のアセスメント・成長度合いの評価と、次に学ぶべきことのヒントを得ることに活用できます。

それでは皆さん、楽しいアジャイルライフを。

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

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)

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

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

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

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


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

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

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

f:id:hageyahhoo:20190519163221p:plain

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

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

1. 課題

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

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

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

 

2. 分析

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

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

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

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

3. 対策

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

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

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

4. 結果

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


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

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

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

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

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


まとめ

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

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

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

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

Comparative Agilityどうでしょう

f:id:hageyahhoo:20181222170636p:plain

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

Comparative Agilityのニュースページにも掲載していただいてます。 f:id:hageyahhoo:20181222170743p:plain

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

1. Comparative Agilityとは

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

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

(参考)Comparative Agilityの利用料金体系

f:id:hageyahhoo:20181222170915p:plain
無料版とプレミアム版との違いは、作成できるアンケートとレポート(後述)の数の上限です。

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

2. Comparative Agilityの使い方

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

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

まず、Comparative Agilityのサイトにアクセスし、右上の「My Account」をクリックします。 f:id:hageyahhoo:20181222172207p:plain

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

次の画面が出てきたら、アクセス成功です。 f:id:hageyahhoo:20181222172702p:plain

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

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

a) まず「Collector(=アンケート)」を作成し、アンケート用のURLをコピーします。
f:id:hageyahhoo:20181222172317p:plain

b) コピーしたリンクを、ブラウザで開いてみましょう。
f:id:hageyahhoo:20181222172344p:plain

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

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

すると、日本語で回答できるようになります(今回私たちが翻訳した部分です)。
f:id:hageyahhoo:20181222172428p:plain

d) 回答を終えると、この画面が表示されます。
f:id:hageyahhoo:20181222172447p:plain

e) Collectorを確認すると、回答が1つ増えていることを確認できます。
f:id:hageyahhoo:20181222173100p:plain

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

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

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

b) このようなレポートが生成されます。
f:id:hageyahhoo:20181222175447p:plain

c) 自分たちのチーム・組織・会社の全体像を把握できます。
f:id:hageyahhoo:20181222175507p:plain

d) どの項目に改善の余地があるのかを、このように確認できます。
f:id:hageyahhoo:20181222175528p:plain
この例では、ペアプロリファクタリングをあまりやっていないことが白日のもとにw

e) レーダーチャート形式での確認も可能です。
f:id:hageyahhoo:20181222175546p:plain

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

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

3. (おまけ&実験)ハンズオン

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

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

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

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

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

4. (おまけ)翻訳の経緯

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

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

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

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