Agile2020公募採択とその歩み

世界最大規模のアジャイルのグローバルカンファレンス「Agile2020」に提出していた公募が採択され、登壇させていただくことになりました。2014年以来、2度目の栄誉です。

新型コロナウィルスの影響で、予定通り登壇できるかは正直不透明ですが、主催者によると、本稿執筆時点では予定通り開催するとのことです。

ちなみに、私のセッションの情報はこちらになります。提出した論文などは、こちらからご覧いただけます。

さて今回は、公募採択までの歩みについてまとめてみます。

動機と準備

Agile2014で採択された論文が、現在でも私たちの業務やチームの指針策定にプラスに作用していることが大きいです。個人・チームとして何か問題にぶつかった時に、考え方や解決策の引き出しとして活用できているのです。

一方で、前回の登壇から5年以上経過し、その間私もチームも多くのスキル・経験を蓄積してきました。そろそろ、蓄積してきたスキル・経験を整理して活用できるようにする時期だと判断し、昨年2019年の4月から行動を開始しました。

具体的には、以下のアクションを行いました。

• 業務上の気付き・考えたこと・取った施策・その効果などを、毎日メモとして書き溜める
  • 業務中に書くことがポイントです
  • 常に発信することを前提に、日々の業務を観察し実行していました
• 1週間おきに、書き溜めたメモを文章としてまとめる
  • 1週間スプリント・ウィークリーリリースと書くと、イメージしやすいかもしれません
• 文章の通りが良くなったところで、実際に論文フォーマットを当てはめる
  • 前回すでに論文のフォーマットを入手し、書き方を熟知しているため、早期からリリースできる状態で作りこみました
  • 実際に提出前提のフォーマットで書き出してみると、記述の過不足などがよりクリアになります
• 同僚に定期的にチェックしてもらい、フィードバックを取り込む

上記の結果、昨年11月はじめの時点で、いつでも論文を提出できる状態にできていました。 そして、11/14に公募が開始されたので、早速論文を提出しました。

渋い反応

しかしながら、実際に論文を提出してみると、ネガティブなフィードバックばかりが返ってきました。

いずれにも共通するのは、「too general」というもの。

私はこれを、「記述範囲が広く一般論的な内容になってしまっているので、もっと具体的で踏み込んだ内容にして欲しい」という意味に捉え、年末年始の休みを使って、徹底的に詳細な内容に書き換え、再度提出しました。

しかしながら、以前よりはポジティブなフィードバックになったものの、やはり「too general」とのこと。

この時点で、何かがおかしいと気付きました。

ピボット

私が選択したトラック（＝セッションカテゴリー）は、前回のAgile2014と同じ「Experience Report」でした。 このトラックは、アジャイルを試してみた経験談を深掘りするもので、具体的には「テスト自動化による想定外の学習効果」や「モブプログラミングのon-boardingへのプラスの効果と改善すべき点」といったものが求められます。

一方で私の論文は、SET（Software Engineer in Test）としての戦略策定方針やそのためのステークホルダーからの支持の得方、問題プロジェクトの課題発見とその解決方法、我々が構築した新しいコンセプトのテストツールなど、ここ数年の活動全体を整理・総括したもの。

どうやら、「Experience Report」トラックで求めているものよりも、はるかに広範で多岐にわたる情報をまとめすぎたようです。端的にいうと「書きすぎ」でした。それを「too general」と指摘され続けていました。

一方で私としては、論文でまとめたレベルの全体的な話をしたい、そのレベルの知見をまとめて今後の自身とチームの活動に活かしたい。登壇はしたいけれども、そこは譲歩したくない。

そこで、締め切りまで1ヶ月を切った1月の中旬、私は「ピボット」を選択しました。

改めてトラック一覧を確認し、自分の話したい事に近しいものを探してみたところ、「Development & Testing Practices」を発見。こちらは、30分だけ話せる「Experience Report」とは異なり75分も話せる、論文以外の過去の発表資料も評価対象にしてもらえる、そして何より、自分の話したいこととトラックの求めているものとが一致している！

そこで、ピボットを決意した次の日に、早速「Development & Testing Practices」に公募を提出し直しました。

ちなみにAgile20xxはこのように、トラックごとに応募方法や基準が異なります。

著名人からのフィードバックとサポート

ピボットを決意し公募を提出した次の日、早速ポジティブな反応が返ってきました。

まず、私にTDDを叩き込んでくださったJames Grenningさん。久々の再会です。

テスト駆動開発による組み込みプログラミング ―C言語とオブジェクト指向で学ぶアジャイルな設計

次に、Agile Testingの考え方で日々お世話になっているLisa Crispinさん。まじか！

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects' Archiveソフトウェア開発の実践)

他の方たちからもフィードバックをいただきましたが、いずれにも共通したのは、「方向性は合っている」「より多くの人にアピールできるようにここをこう直そう」という、公募採択とその後を想定した具体的なものでした。

それらのフィードバックをもとに、公募内容の改善のやり取りを続けた結果、採択となりました。勇気を持って選択したピボットに成功したと言えます。

まとめ

公募を出す際も、アジャイルの考え方や方法論は役に立つぞというのが、個人的な所感です。

• 小さく準備しておく
• いつでもリリースできる状態にしておく
• フィードバックをすぐに取り込めるようにしておく／取り込む
• 必要であればすぐにピボットできるようにしておく／する

【Appendix】RSGT2020での発表の補足

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

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

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

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

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

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

（参考）発表資料＆発表内容

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

発表資料はコチラです。

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

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

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

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

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

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

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

サーチ・インサイド・ユアセルフ――仕事と人生を飛躍させるグーグルのマインドフルネス実践法

たった一呼吸から幸せになるマインドフルネス 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

ソフトウェア開発者の評価指標を考えてみた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を増やして無駄を減らした」ものですが、他にも方法はいくらでもあります。

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

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