はんなりと、ゆるやかに

アジャイル、スクラムが好きなITエンジニアが日々から学んだことをアウトプット

ファシリテーションの工夫 15のこと

はじめに

一般的にファシリテーションは会議の司会者というイメージが強いですが、会議に限らず色々な場面で発揮できます。広義だとファシリテーションは場を観察して調整し、その場の能力を最大限に引き出す行為だと考えています。僕も色んな場面でファシリテーションを経験してきました。その中で個人的に上手くいくパターンがあると思い、言語化しておこうとまとめた記事です。主に会議に関することですが、抽象化して捉えるとチームのファシリテーションとしても使えると思います。

事前準備

予稿(アジェンダとも言う)は誰でも編集できるようにする

予稿は会議を円滑に進めるために重要です。予稿がないと、何を話すのか分からない。重要な議題が分からない。当日進行するときの時間配分も決められない。とデメリットが多いです。

さらに予稿は参加者全員が編集できるようにすると良いです。Wikiなど共同編集できる場所を作ってフォーマットを決め、共有しておけば誰でも書き込めるようになります。事前に話すことを書いておけば忘れません。また、会議の最後に「他に話したいことはありませんか~」と聞いたときに重要議題が出ることも防げます。

予稿に詳細も書いておく

予稿はタイトルだけ書くことが多いと思いますが、話す内容を全部書いておきます。あるなら図や表も添付します。すると、参加者全員が内容まで分かった状態で参加でき議論が早いです。(色々な事情で読めてない人もいるので当日のMTGで改めて共有はしたほうが良い) また、議事録を書く手間も減ります。

会議中

開始で場を温める

早い話アイスブレイクです。個人的に特別なエクササイズはしなくても良いと思っています。元気よく「おつかれさまです!」で始めるだけでも良いと思います。「おつかれさまです!」というと大体の人は「おつかれさまです!」と声を出してくれます。会議の初めに声を出してもらうのは会議中の発言ハードルを下げる効果があるので、お勧めです。会議の種類にもよりますが、「はい、どーもー、今日もやっていきましょう、〇〇会議」というラジオっぽくはじめてもテンションが上がります。

議題の順番を合意する

予稿が重要順に並んでいない場合は話す順番を決めて、メンバーと合意をとります。議題の最後の方は時間が足りない場合があります。上記で書いたように全員が予稿を書けるようにすると重要順に並んでいないことがあります。

議事を見えるようにする

オンライン会議であれば画面共有、オフラインならみんなが見えるディスプレイに表示したりホワイトボードを出したり、とにかく全員が同じものを見て進行するようにします。よく言われる「問題vs私たち」の状態になれます。また、常に情報が見えていると議論しやすいです。

意識してリアクション

発言してリアクションがないと不安になります。オンラインになってから特にその感覚があります。話し終えて無音だと「あれ、聞こえてます?」と心配になります。オフラインの場合は動きで表現しても良いですが、オンラインは音声で伝えましょう。「はい」とか「そうですね」「ほーー!」とかなんでも良いのです。話を聞いているということを伝えると話し手も話しやすいです。
※ミュートでほんとに聞こえてないときもあるのでリアクションはありがたい。

名指しで指名する

オンラインで良くあるシチュエーション--「〇〇の件、どう思いますか?」「・・・」「・・・」「・・・」「聞こえてます?」--経験ありませんか?
考えさせるような質問のとき、誰かが話すのを待っているときがあります。そのため、「〇〇さん、どう思いますか?」と聞きます。必要なら違う人にも質問します。聞くときは意見を持ってそうな人、意見を引き出せそうな人から質問します

質問を工夫する

上記に書いたように名指しをする場合、その人に合わせた質問をします。曖昧な質問でも良い人、噛み砕いて具体的に質問した方が良い人、色々です。聞きたいことを聞くのですが、聞きたい人が答えられる工夫が必要です。注意点は答えを誘導するような質問にしないことです。また、質問して反応が悪いときは、違う角度の質問に変更します。全体に質問するときも基本は同じです。
質問を考えるときは問いの因数分解:連載「問いのデザインの思考法」第7回 | CULTIBASEが参考になります。また、執筆者の安斎さんの書籍もおすすめです。問いのテザインは読んで記事も書きました。
効果的な問いでファシリテート上手になる / 問いのデザインを読んだ - はんなりと、ゆるやかに 問いかけの作法も読もうと思っています。

空気を読んで攻める

ファシリテーションしていると、ある問題について議論を避けているような空気を感じるときがあります。そんな時は空気を読んだうえで、その問題を話してみます。嫌だけど話さないといけない場面もあります。

話が盛り上がったら影を潜める

メンバー同士が活発に話し始めたら見守ります。ファシリテーターが常に場を調整しなくても良いです。むしろ、ファシリテーションしなくてもうまく進むなら素晴らしいことです。

話の脱線もいいじゃないか

予稿から話が外れても焦らず少し見守ります。脱線した話が他の議題よりも優先できる内容なら、衝動のままに舵を切りなおします。話を戻したほうが良ければ当然戻します。

要約する

議題によって内容が分からなくなることがあります。また、曖昧だと感じることがあります。そのときは要約して「○○ということですか?」と確認します。合っていればそれで良いですし、間違っていたらどう違うか確認しながら理解していきます。

言葉以外の「感じ」も大切にする

「はい、わかりました。」と言う肯定的な言葉でも納得してない感じの場合は、「納得していないように聞こえますが、気になる部分はどこですか?」と聞きます。言葉以外にも、表情とか空気とか得られるすべての情報を傾聴します

会議の後半

あと、○○分です

3/4が過ぎたあたりで「あと、○○分です。」と言います。メンバー全員が時間を意識すると、会議全体がゴールに向かうことがあります。そのためにも、ファシリテーターは常に時間を意識します。状況によっては早めに「あと、○○分です。」と声掛けをします。

会議後のアクションを明確にする

誰がいつまでに何をするのかを確認し、合意します。たまに、「私じゃないと思ってました」なんてこともあります。

まとめ

会議以外のファシリテーションの工夫も出せるかなと思って書き始めましたが、ほとんど会議のことばかりでした。別の機会に会議以外のファシリテーションで考えていることをまとめようと思います。

Visual Studio Code で Foam を使って良い感じにナレッジ管理 ができるかもしれない

自分にあったナレッジ管理を探しているのですが、なかなかしっくりくるものがありません。無精な性格が邪魔をして自分のスタイルに合わない部分があると長続きしないのです。なにかないかなっと探して見つけた方法の一つがVisual Studio Code(VSCode)+Foam です。VSCodeは普段から使っているツールなので相性が合うかもと思いました。

Foamとは

FoamはVisual Studio Code拡張機能で、RoamResearchにインスピレーションを受け開発された知識管理システムです。GitHubVisual Studio Codeがあればすぐに使うことが出来ます。

foambubble.github.io

使い方

詳細は公式のリンクを確認してください。
Foam | A personal knowledge management and sharing system for VSCode

簡単に説明しますと、
1.GitHubのFoamのページからテンプレートをコピーします。Use this Template のボタンをクリックすればコピーできます。基本的にはプライベートリポジトリにすると良いです。

2. コピーしたテンプレートをCloneしてそのフォルダーをVSCodeで開きます。開くと拡張機能のインストールを進められるのでインストールします。

お勧めにはFoamの拡張機能も含まれています。

3. Ctrl+Shift+Pでコマンドパレットを出して、「Show Graph」と入力します。

ページとのリンクがグラフ化されます。※以下のグラフはテンプレート時の状態です。

まとめ

今回はインストールして使い方を調べるところまで確認しました。使い勝手は引き続き確認していきます。

『スクラムチームの開発者ってどんな仕事?』〜 スクラム Bar #4 に参加した

スクラムチームの開発者ってどんな仕事?』〜 スクラム Bar #4 に参加しました。

chatwork.connpass.com

開発者の視点でスクラムについて語られた会でした。気になったこと、心に残ったことをまとめます。

やり方(How)は開発者に任せよう

Why(なぜ作るのか)、What(何を作るのか)、How(どうやって作るのか)についてのお話で以下のようなトピックがありました。

  • 信頼関係がないとHowについて意見したり、議論することが多い
  • 担当者が決まった後のやり方は任せると摩擦が減る
  • DACIを導入する
  • POはサイズ感を考えるためにHowも考えるけど、最終的なHowは開発チームに決めてほしい
  • POはHowについては文句は言わない
  • 立場によって、WhatのつもりがHowに受け取られることもあるので、スプリントを通して塩梅を見つけていく

DACIフレームワークは初めて知りましたが、良さそうだと思いました。DACIは推進者、承認者、貢献者、報告先を明確にするフレームワークてす。承認者が決まっていると意思決定も早いですね。また、自律的なチームを促すことにも一役買いそうです。「決める人はあなた」が決まっていると意識が変わるんです。やっぱり。
blogs.informatica.com

エンジニアにスクラム知識は必要か?

  • スクラムマスターがフォローできるので、必須ではない
  • プランニングについては知った方が良い

エンジニアにスクラムの知識は必要かどうかという話題で、スクラムイベントのプランニングは知っておいたほうが良いですねという話でした。
プランニングはPOと開発者が対等に話せたほうが良いですし、プランニングの二部は開発者が主体になるので知っておいたほうが良いですね。 

個人的にはアジャイルの考え方も知っておいたほうがスプリント中のイベントで活発に話せたり、改善が進むと思いました。

とはいえ、このあたりはスクラムマスターが頑張るところだと思います。

チケットを積極的に取らない人への対応は?

  • ペアで考えさせながら教えて成功体験を築く
  • 託児所パターン:ベロシティを下げないように生産性に影響しにくいタスクを持ってもらう

託児所パターンは組織パターンという書籍に書かれているようです。ペアやモブで開発するとき初心者に合わせると進捗が出ない、有識者に合わせると初心者がついていけないため、「進捗より教育に重きを置くチーム」と「進捗に重きを置くチーム」に分けるみたいです。新しいことを知れました。両方のメリットを得るのが難しい場合は分ければ良いんですね。

ふりかえりで工夫していること

  • 包みかかさず話す
  • 個人的な意見ではなく、チームの声だと思って聞く

ふりかえりの意見はその人がシステムに言わされていると考えて、その理由を探るのが大事という話は、新しい感覚を掴めた感じがします。システムで捉えるとこの感覚なんですね。

まとめ

DACIフレームワークと託児所パターンは使える場面がありそうです。「システムに言わされる」という感覚は開発をシステムで捉える重要な感覚になりそうです。

今回も参加してよかった!運営の皆さん、参加者の皆さん、ありがとうございました!

notion と GitHub と VS Code で Mermaid の使い勝手を確認してみた


2021年12月にNotion で Mermaid が使えるようになったことが発表されて盛り上がっていました。
dev.classmethod.jp

また、2022年2月にはGitHub で Mermaid が使えるようになったことが発表されて盛り上がっていました。
www.publickey1.jp

さらに、VS Code(Visual Studio Code)も2017年8月頃から使えるようになっていたようです。
marketplace.visualstudio.com

この3つでどのツールが使いやすいのか確認してみました。

Mermaidとは作図ツール

JavascriptベースのMarkdown構文で書ける作図ツールです。
mermaid-js.github.io

各ツールでMermaidを使う方法

notion

こちらを参照
iucstscui.hatenablog.com

GitHub

issue にMermaid構文で記述し、プレビュータブを開けば図が確認できます。

VS Code

拡張機能Markdown Preview Mermaid Support」をインストールし、MarkdownファイルにMermaid構文で記述し、プレビュー表示すれば図が確認できます。(プレビュー表示はWindowsなら 「Ctrl+K」 のあとに 「V」 )

3つのツールを確認

Mermaid公式ページのサンプルをお借りして確認しました。

先に結論

表現できる図
図に崩れがなかったのは notionでした。GitHubはER図、VS Codeガントチャート、パイチャートで見にくくなったり、表記が足りなかったりしました。
図の見やすさ
図の色合いはGitHubが見やすかったです。notion と VS Codeは単色でシンプルですが、比較するとGitHubの方が好みでした。今回は確認してませんが、VS CodeCSSの拡張が出来るようなので活用すれば見やすくなりそうです。
書きやすさ
notion と VS Codeはどちらもリアルタイムにプレビューが更新されるため、書きやすかったです。さらにVS Codeはオフラインでも使えるのがさらに良いところかも知れません。ネットワークが弱い、繋がらない場所でも使えます。GitHubはリアルタイムにプレビューは見れず、プレビュータブを押す必要があり面倒に感じました。

シーケンス図

notion


ER図

notion


GitHub

表示が崩れましたね。

ガントチャート

notion


VS Code

重なって見にくいですね。プレビューエリアを広げれば良くはなるのですが、なぜかガントチャートはエリアを広げてから更新ボタンを押さないと見た目が反映されません(VS Codeの他の図はリアルタイムに反映されます。)ガントチャートは苦手なのかもしれませんね。

パイチャート

notion


VS Code

項目名が出ませんね。

その他

クラス図、状態遷移図、ユーザージャーニー、要求図はそれぞれのツールで問題なく表示されていました。

特定ラベル付きのプルリクエストがマージされたときに GitHub Actions を実行

特定のラベルが付いたプルリクエストがマージされたときにGitHub Actions を実行する方法を調べたのでまとめます。

最終設定ファイル

name: RunLabel

on:
  pull_request:
    types: [closed]
jobs:
  RunLabel:
    runs-on: ubuntu-latest

    if: (github.event.pull_request.merged == true && contains(github.event.pull_request.labels.*.name, 'runAction'))

    steps:
      - run: echo "Hello World!"

プルリクエストのマージをトリガーにする

プルリクエストがマージされたときを表すイベントはありません。closedgithub.event.pull_request.merged == trueを組み合わせてマージと判断します。

https://docs.github.com/ja/actions/using-workflows/events-that-trigger-workflows#running-your-workflow-when-a-pull-request-merges

特定のラベルのときに実行する

contains関数を使うと特定のラベルかどうか判断できます。最終設定ファイルの
contains(github.event.pull_request.labels.*.name, 'runAction') の部分です。この設定では、runActionというラベルの付いたプルリクエストのときにTrueが返ります。

https://docs.github.com/ja/enterprise-cloud@latest/actions/learn-github-actions/expressions#contains

まとめ

特定のラベルが付いたプルリクエストがマージされたときにGitHub Actions を実行する方法をまとめました。調査に使ったリポジトリはこちらです。
github.com

Release Drafter と GitHub Actions でリリースノートを自動化する

GitHub Actions でリリースノートを自動化する方法を調べていると Release Drafter というツールを見つけました。これを使うと簡単に良い感じにリリースノートが自動化できそうです。

Release Drafter

github.com

こちらがrelease-drafterです。プルリクエストがマージされるときにリリースノートのドラフトを自動で作成してくれます。

試して詰まったところ

早速試してみたところ、以下のエラーで躓きました。

Error: Validation Failed: {"resource":"Release","code":"invalid","field":"target_commitish"}

「対象のcommitishが無効です。」というエラーです。target_commitish の説明は以下を参照。
docs.github.com

ツールのサンプルの対象ブランチが main ではなく master だった

本ツールのサンプルコードの指定ブランチ名は master です。しかし、GitHubは2020年10月からデフォルトのブランチ名を master から main に変更していて、master というブランチはありませんでした。単純なミス。。。対象ブランチにコミットがないため、エラーになってしまいました。
github.blog

サンプルコードをコピーした場合「.github/workflows/release-drafter.yml」の以下の部分が master になっているため、mainに変更が必要です。(正しくはリポジトリのデフォルトブランチを指定)

on:
  push:
    # branches to consider in the event; optional, defaults to all
    branches:
      - master

修正して試した結果

修正した結果以下のようなリリースノートが自動で作成されてました。2つのプルリクエストをマージしており、ラベルはfeature、bug をそれぞれに付けています。(ラベルを付けると項目ごとに記述されます。)
f:id:iucstscui:20220405002330p:plain

サンプルのリポジトリは以下です。
github.com

まとめ

  • Release Drafter というツールを使うと簡単にリリースノートが自動化できます。
  • プルリクエストのタイトル名がそのままリリースノートに使われるため、プルリクエストのタイトルは分かりやすくする必要があります。
  • デフォルトブランチ名に合わせた設定変更が必要です。

心理的安全性のつくりかた が とても良い本だった

心理的安全性のつくりかた」という書籍を読みました。心理的安全性の書籍の中で個人的にお気に入りの一冊になりました。理論と実践のバランスが僕にちょうどいい。また、多くの賞を受賞されていることから色んな方にも刺さる一冊なんだろうと思います。

心理的安全性を説明している本ではありますが、それだけではありません。心理的安全性を高めてチームのパフォーマンスを上げましょう。具体的には〇〇をしましょう。理論だけでなく実践に活用しやすい。そういう本です。そのため、チームや組織に関心がある人にも参考になる部分があると思います。

本書を読んで、実践しようと思ったことを中心にまとめていきます。

目次

第1章 チームの心理的安全性
第2章 リーダーシップとしての心理的柔軟性
第3章 行動分析でつくる心理的安全性
第4章 価値とルールでつくる心理的安全性
第5章 心理的安全性導入ガイド

心理的安全性はチームや組織のパフォーマンスがあがる

心理的安全性が高まるとチームの学習が促され、中長期的にパフォーマンスが上がることが分かっています。これは前回読んだ書籍でも同じことが書かれていました。
iucstscui.hatenablog.com

本書では、心理的安全性が高いと同じ問題や事象の意見の食い違いがあった場合は業績がプラスになると書かれています。心理的安全性が高いと建設的に議論できるからですね。意見が違うことは良いことです。

日本版の心理的安全性の4つの因子

日本で心理的安全性を向上させる4つの因子が紹介されています。「話しやすさ」「助け合い」「挑戦」「新奇歓迎」です。小さい時から言われているようなことだなと思い、小さい時から言われているからこそ変わらず大事なことで、そして実際に行動に移せないことなんでしょうね。

4つの因子の名前が柔らかいので、共有しても引っかかりなくイメージしやすそうだと思いました。ぜひ、心理的安全性を高める要素として「話しやすさ」「助け合い」「挑戦」「新奇歓迎」という4つがあることを共有しようと思います。さらに、今のチームで弱いところはないか話し合ってみたいですね。

本書ではこの4つの因子を向上させる行動を増やしていきましょうと書かれています。本書で良いと思ったポイントの1つとして、この「行動」に着目している点です。

機能的文脈主義と行動

機能的文脈主義と行動について説明されています。機能的文脈主義について調べてみたのですが難解ですね。。。本書がいかに分かりやすく説明してくれていたのか理解できました。本書はブーケ(花束)を例に紹介していました。花束は1本1本の花の集まりであり、花束を変えるためには1本1本の花を変えることだと。また、他のことも同じで、「やる気」というのも「やる気があるように見える行動の集まり」で、やる気を出せといって発揮するのはその行動だということです。「話しやすさ」「助け合い」「挑戦」「新奇歓迎」も一緒で、それ自体を向上させるのではなく、それに関連する行動を強化しましょうねという話です。

機能的文脈主義という考えは初めて知ったのですが「ふりかえり」や「フィードバック」するときにも使えそうですね。何か抽象的な判断(例えばあの人はやる気がない等)と思ったときは、どういう行動を見てそう思ったのか考え直して、その行動についてフィードバックしようと思いました。

心理的柔軟なリーダー

心理的安全なチームリーダーには「心理的柔軟性」が必要だという提案もありました。

  • 柔軟1:変えられないものを受け入れる
  • 柔軟2:大切なことへ向かっていく
  • 柔軟3:それらをマインドフルに見分ける

個人的にも大切にしていることでした。僕もコントロールできることに目を向けて、コントロールできないことは気にしないようにしています。そうすることがポジティブさを保つ秘訣だと思っています。本書では心理的柔軟性という言葉で紹介しています。

行動分析で心理的安全性を高めよう

行動分析学を活用して心理的安全性を高めましょう紹介されています。本書では「きっかけ→行動→みかえりフレームワーク」として紹介されています。「行動のきっかけ」と「行動後のみかえり(フィードバック)」を工夫して心理的安全性が向上する行動を増やしていきましょう。たとえば寒いとか暑いとかきっかけがあると、エアコンをつける行動をし、適温になるみかえりがあります。その経験があれば、また暑かったときに同じ行動を繰り返すことが増えます。

この考え方は行動に注目したシステム思考のループ図のような印象を受けました。改めて要素と要素のつながりを把握する大切さを感じます。増やしたい行動、減らしたい行動を見つけたときは、それに関連する要素にも着目しようと思います。スクラムマスターに求められるスキルの一つである「チームを観察すること」に繋がる気がしますね。観察って結局何をするのか分かりづらいのですが、行動のつながりを見つけて改善ポイントを探すことなんでしょうね。

まとめ

心理的安全性のつくりかた」を読みました。心理的安全性に関して、理論や考え方を専門家でなくても理解できるように簡潔に優しく説明してもらえる。さらに具体的な実践方法まで学べる書籍でした!心理的安全性を知りたい方、チームのパフォーマンスを上げたい方にお勧めの一冊です。