MogLog

メモというか日記というか備忘録というか

『「60分」図解トレーニング ロジカル・ファシリテーション』第5章読んだ

論理を構造化する

  • 議論を構造化する → 出てきた複数の意見がどういう関係にあるかを明快に分かるようにすること
    • 対立構造
    • 並列構造
    • 連関構造
  • 構造化することのメリット
    • 議論の全体像を把握しやすくなる
    • 抽象 ⇔ 具体、主張 ⇔ 根拠、目的 ⇔ 手段、原因 ⇔ 結果という関係が頭に入りやすくなる
    • 今どこの議論をしているかわかりやすくなる
    • ..など

構造化の表現パターンを覚えよう

  • 頭の中で構造化するのは大変なのでホワイトボード上で構造化し、みんなに見せる
  • その際、意見の間の関係を表現するための基本作法を知っておくと良い
    • 関連
    • 対立、対比
    • 順序・連鎖、因果、根拠と結論
    • 並列
    • 上部・下部、抽象・具体

似た意見の塊を作る

  • 構造化の中でもとりわけよく使われるのが、同類の意見のカタマリを作る「グループ化」である(分類とも言う)
  • ファシリテーターは意見を引き出しつつも、これらの意見をどう分類できそうかと常に意識しながら話し合いを進める
  • グループ化するときの原則は「ある特定の共通点を持つ意見をカタマリにする」である

どのような共通点に着目するか?

  • どのような共通点に着目するかは様々なケースが考えられるが、オススメは「抽象的意味合い」が共通している意見をカタマリにすること
    • 抽象的意味合いとは、その意見の中で注目すべき要素だけを充填的に抜き出したもの
    • 例:「発想を広げるにはどうするか?」
      • A「社外の人と飲みに行く」
      • B「他部門の人と話し合う」
      • → これらは「自分とは違う視点の人と意見を交わす」という点において共通している

上手にグループ名をつけるには?

  • 意見のカタマリを作ったら、そのカタマリを総括するようなグループ名をつければ完成する
  • このとき、雑なグループ名にはしないこと。「〜系」といったグループ名はやめておく。
  • 多少長くなっても、そのグループの意味合いを失わないフレーズ感のある名前が良い。論点に答えるようなグループをつけることを心がける

グループ化するときの落とし穴

  • グループ化するときのアンチパターン
    • いきなり大きなグループを作りたがる
      • いきなり大きなグループを作ってしまうと、その後の細かな意見が吸収され消えてしまう
      • 小さなグループをこまめに丁寧に作っていくこと
    • 途中からグループを増やすのが面倒になる
      • いくつかグループができると、その後出てきた意見を無理やり既存のグループに入れてしまう傾向がある
      • 意味合いの違うものは別にわけること
    • はじめに思いついた分類に縛られる
      • うまくいかないグループ化は壊すことも重要

付箋を的確に活用する

  • 付箋を使うときのポイント
    • 大きく太い字で書く
    • 具体的・丁寧に記述する
    • 意見発表は1人1枚ずつ
      • 声のでかい人が最初に全部出してしまうと、後の人ほど重複感もあり残念な気分になるため
    • 似た意見を募集する
      • 1枚出る度に似た意見があれば他の人からも出してもらう。リアルタイムにグループ化が進む
    • 触発されて出た意見を拾う

グループ化が大活躍するシーン

  • 以下のようなシーンではグループ化が活躍する
    • 何らかのリストを作るとき
    • 多視点で根拠を検証したいとき
    • 原因を分析したいとき
    • 皆の思いを出したいとき
  • ※ 書籍内の図を参照するとイメージしやすい

ここまでのふりかえりをする

  • 議論の途中で、ちょっと行き詰まった時や、何を話し合えばよいか迷ったときは、一度立ち止まってここまでの議論をふりかえる
  • ふりかえりでは以下の点を意識する
    • ここまでどんな流れで話が進んできたか
    • 重要な意見としてどんな意見が出てきたか
    • それぞれの意見がどのような関係にあるか
    • 節目節目で何に決着がついたか
    • 今、何の話し合いをしていて、どういう状態なのか
  • 短くコンパクトに話すことが重要。 だらだら振り返ったり、頻繁に振り返るのは禁物。

『「60分」図解トレーニング ロジカル・ファシリテーション』第4章読んだ

論理の三角形で意見を引き出そう

  • 主張の妥当性を判断するには根拠が必要。「<主張>。なぜならば<根拠>。」という組み合わせを一人ひとりが提示し、みんなで検討していくことがロジカルな討議に求められる。
  • ファシリテーターは、主張と根拠をワンセットで引き出し、全員で筋道を確認しながらディスカッションできるようにサポートする必要がある
    • 通常、1つの主張を複数の根拠で支える形になる。これを論理の三角形と呼ぶ。
    • 論理の三角形が完成するよう、皆の意見を引き出していく

根拠を引き出す

  • 基本的には参加者が自ずから根拠を出すのを待つ。が、根拠が出てこない場合は質問を投げかける。
  • 以下、根拠を喋ってもらうための質問例。相手を萎縮させたり逆なでしないよう慎重に言葉を選ぶ。
    • 「なぜそうお考えになるのですか?」
    • 「理由を説明していただけますか?」
    • 「その理由は xxx ですね?」

主張を引き出す

  • 論定に対して直接答えている部分が無く、根拠らしき意見が出てくる場合がある。こういうときには「だから何?(So what?)」な質問を投げかけて主張を引き出していく。
  • So what? な質問例
    • 「なるほど、〜だと。...なので?」
    • 「なるほど、〜だと。というと、どうなりますか?」
    • 「なるほど、〜だと。だとすると、おっしゃりたいのは?」
  • 例:「やはり時代はグローバルスタンダードだ。」→「グローバルスタンダードだとすると、今回の件についてはどのような対策を取るべきだとお考えですか?」

よりよい根拠を探す・事実を確認する

  • 主張を支える 妥当な 根拠であるかをチェックする
  • 根拠は、出来る限り以下の条件を満たすものが出てくるようにする
    • 具体的である
    • 事実である
    • 誰でも繰り返し確認できる
根拠 根拠を妥当にする質問
【抽象的】顧客ニーズが高まっている どういうニーズですか?
【個人的意見】彼は実に明晰に私の質問に答えた 明晰に、というのは実際にどのように彼は答えたのですか?
【1回きり】この活動は全社に広げるべきだ。Aさんが先月重要顧客の採用にこぎつけた その活動でうまくいった根本的な要因は何でしょうか?他の顧客にも広く通用しそうでしょうか?
【思い込み】あの部門はこれまでに繰り返しミスを起こしてきた そのミスを起こしている状況を事実ベースで確認しておきませんか。データはどこにありますか?

大事な根拠が抜けていないかをチェックする

  • 主張をより強めるため、今出ている主張と根拠を見比べて、根拠に抜けは無いか、他にどんな根拠があれば良いのかを議論し出していく。
  • 根拠を大きなカタマリで捉えておくと良い

前提を引き出し、妥当性を検討する

  • 同じ事実を根拠にしていても、主張がまったく異なる場合がある。これは互いの持っている前提が違うために起こる。
  • 厄介なことに、前提は発言されずに隠れていることが非常に多い
  • ファシリテーターは主張と根拠のつながりに違和感を感じたら、その前提を引き出していこう
  • 例:「彼は今年37歳だ」
    • Aさん:「(若い人には挑戦させるべきなので、)彼を部長につけよう。」
    • Bさん:「(若い人に部長は無理なので、)彼にはまだ修行をさせよう。」

安易な一般化に注意する

  • 個別の事例をあたかも広くあてはまるかのように言っているパターンがある
    • 例:「最近の新人は挨拶ができない。」→「なぜ?」→「昨日、新人の井上が俺に挨拶をしなかったんだ。」
    • その新人だけが挨拶が苦手なだけかもしれない。年長者も挨拶ができていないかもしれない。
  • このような場合、ファシリテーターは掘り下げをしていく必要がある

主張や根拠の一貫性をチェックする

  • 主張と根拠に一貫性が無い場合、どこかにごまかし(あるいは本人も気づいていないなにか)がある可能性が高い
    • A「業績を上げるために顧客訪問人員を増やしたい。」→ B「1人ひとりの訪問件数を増やせばよいのでは?」→ A「それはダメだ」
    • Aの主張には一貫性が無い。ごまかしあるいは何らかの前提が隠れている。
  • バイアスにも気をつける。
    • 確証バイアス:自分の仮説に合った、都合の良い情報ばかりに目がいく
    • 後知恵バイアス:物事が起きてから、それに理屈をつけて正当化する
    • 一貫性バイアス:一貫したストーリーを聞くと信じてしまう
    • その他にも様々なバイアスがある。これらのバイアスを知っておくと吉。

『「60分」図解トレーニング ロジカル・ファシリテーション』第3章読んだ

要点で意見の核心を共有する

  • 議論をかみ合わせるには一人ひとりの意見を正確に理解することが出発点
  • ファシリテーターは、個々の発言に対して「〜ということですね」といったように要約・確認をしていく。これにより、意見の核心を明確にすると同時に他の参加者も聴くことで全員の理解を揃えることができる
  • 要約の第一歩は相手の発言をそのまま返すこと。相手の発言から何も引かず、何も付け足さない(これを「復唱」という)。
    • 例:「私はこの意見には反対だな。」→「なるほど。この案には反対ですか。」
    • 例:「俺はこの意見には反対だな。お金がかかりすぎるよ。」→「なるほど。お金がかかりすぎるから反対なんですね。」

論点が核心の場所を決める

  • 長い発言になってくると、本来の意味での"要約"が必要になってくる。発言を切り詰めて、核心だけを取り出さなければならない。
  • 長い発言の中の一体どこが核心なのか。その判断基準になるのは、ズバリ 論点に答えているところ である。それ以外の部分は、如何に感動的な内容だとしても意味をなさない。
    • 例:「作業完了は3日後になります。担当者がインフルエンザにかかってしまって...。」
    • → 論点が「作業はいつ完了するか」ならば、核心は「3日後」になる
    • → 論点が「作業が遅れている原因は何か」ならば、核心は「担当者がインフルエンザにかかった」になる
  • 論点が変われば、核心となる部分も変わる。ファシリテーターは、常に論点を意識しておくことが求められる

言葉を丸めすぎない

  • 発言を要約する際、その人の使った言葉を尊重すること。 要約後の言葉だけを見て、元の発言が思い出せるかどうか を常にチェックする。
    • 例:「係長クラスは、新人が困ったことがあったら、相談に乗ってあげねばならない」
      • 悪い要約:「係長のマネジメントが大事ということですね。」
      • 良い要約:「係長は新人の相談に乗るべきということですね。」
  • 以下のようなときは、敢えて相手の使っていない言葉で要約をする
    • 発言者が言葉を探しあぐねている
    • もっと的確な表現方法がある
    • 他に真意がある
  • 言葉を丸めすぎず、勝手に変えてしまわず。でも、誠意をもって相手の真意をよりピッタリ表す言葉を探そう。

意見を書いて残す

  • 皆の意見を要約で確認したら、ホワイトボードの上に残す。目で文字を見ながら議論すれば、地に足の着いた議論ができる。
  • 皆の意見を平等に書くこと。 ついつい、自信に満ちた発言や明確化された発言だけを残してしまいがちだが、それでは声の大きい人の意見ばかりがホワイトボードに残るようになってしまう。自信の無さそうな控えめな発言も拾うこと。
  • 要約するとき同様、ホワイトボードにも言葉を丸めすぎないよう気をつけ、的確な要約文を書くこと。

曖昧言葉は明確に

  • 色々な意味にとれる言葉、色々なケースが考えられる言葉を放置しておくと参加者間の理解がバラバラになり、後々大きなズレを引き起こす地雷となりうる。
    • 「うちの部署の問題点はなんだろう」→ 「部署内のコミュニケーションが悪いことだよ。」
    • ※ "コミュニケーションが悪い"は曖昧な表現
  • ファシリテーターは、こういった曖昧な言葉・表現を具体的にする必要がある。「例えば?」「具体的には?」と発言者に尋ねれば良い。
  • 曖昧な言葉にアンテナを張ろう。ただし、全ての曖昧言葉を具体化していては議論が進まないので、必要なものだけを選ぶ。

困った人にはリフレーミングで対応

  • 相手の使っていない言葉で要約するのをさらに進めると、相手の発言を「言い換える」という境地に辿り着く。これを フレーミング と呼ぶ。
  • フレーミングがよく使われるのは、ネガティブな表現をポジティブに言い換える(たい)とき
    • 「うちの上司は具体的な指示をしないのです」→「なるほど。それは箸の上げ下げまでうるさく言わない、とも言えますね。」
  • また、綺麗事を並べる人に対処する際など、本音をズバッと指摘したいときにも使える
    • 「その案は良さそうだけど、色々懸念もあるよね。もう少し慎重に決めるべきでは?」→「賛成とも反対とも立場を明らかにしたくないということですか?」

皆にしゃべってもらおう

  • 論理性・妥当性のチェックも大事だが、皆の考えを出し合うことが優先される。
  • 発言しやすい聴き方
    • 発言者に体を向ける
    • 目を合わせる
    • うなずく
    • 柔和な表情をする
    • 相槌を打つ
    • 相手の発言を復唱する
    • 相手の発言を要約して確認する
    • 内容に応じて反応を返す
  • 発言しにくい聴き方
    • ふんぞり返っている
    • 目をつぶって難しい表情
    • ピクリとも動かない
    • ながら作業(スマホ見ながらとか)
    • のっけから疑問・批判
    • 相手の発言を遮る
  • 皆に質問をしたときには沈黙に耐えることも大事。難しい質問ほど考える時間が必要。安易に「まずは自分から・・」などとしてはいけない。
  • 一人ひとりにしっかりと意見を表明してもらうために覚えておきたい方法
    • 2-3分程時間を取って、自分の意見を付箋に書いてもらう
    • 発言順を決めて、順番にぐるぐると意見を言ってもらう
    • 隣同士ペアになってまずは2人で意見交換をしてもらう

『「60分」図解トレーニング ロジカル・ファシリテーション』第2章読んだ

準備のポイントは目的・目標・論点・進め方・宿題

  • 入念に準備するということをまずは心がける
  • 以下の6つの観点を基本に準備を行う
    1. 目的:何のために集まって話し合いをするのか
    2. 目標(ゴール):この会議でどんな成果を出したいのか。どこまでたどり着ければ良いのか
    3. 論点:目標を達成するために、具体的にどのような論点で議論する必要があるか
    4. 進め方:目標を達成するために、どんな順番で論点を取り上げるか(所要時間の目安も)
    5. 宿題:各参加者はどんな材料を持ち寄るべきか
    6. ルール:実りある会議にするために、参加者はどんな心構えで臨んだら良いか

そもそもその会議に開催意義はあるのか?

  • 目的と目標をはっきりさせた上で一度立ち止まって、「この目的・目標を達成するためにわざわざみんなで集まって会議を開く必要があるのか」ということを考えてみる
  • 参加者 についても事前に考慮する。目的・目標を達成するために、どんな顔ぶれが揃っていると良いかを考える。
    • 例:意思決定を必要とする場面では役職者が必要だが、アイデア出しがゴールの会議では役職者を呼ばない方良い
    • 例:多様な意見を出すために、チーム外の人を呼ぶ
    • このように、会議の性質に応じて参加者を決定する

論点は問いで提示する

  • 論点の設定について、我々は無神経になりがちである。曖昧な論点設定は、人によって発言のポイントをバラバラにさせてしまう
  • 論点は極力、「問い」「疑問文」にする。そうすることで、話し合うこと・考えるべきことに焦点を絞ることができるようになる
  • ダメな例
    • 「今期施策」
    • 「本年度の節電について」
    • 「間接費削減について」
  • 良い例
    • 「間接費削減は我々にとって重要な議題か?」
    • 「間接費を削減するために何をすべきか?」

ゴールイメージを設定する

  • 会議が終わったときにどこまで到達していたいのか」を設定する
  • 何でもかんでも最後になんらかの"まとめ"が必要であるという強迫観念から離れる
    • 例えば、「無駄だと思う業務を洗い出す」がゴールであれば、ホワイトボードに無駄な業務の例がいっぱいになっていれば目標は達成されている
悪い例 良い例
今期施策を共有する 今期施策の意味・意義を全員が理解し、各自のプランをすぐに実行できる状態にする
問題の原因を分析する 問題の原因を分析し、手を打つべき箇所を特定する
ネーミングのアイデアを出す ネーミングのアイデアを100個出す
現状の打開策を検討する 現状の打開策として有望な案を5つ出す
打ち手案を検討・決定する 打ち手案を検討し、やる・やらない・精度を高め次回再検討、を個々に決める

難しい話し合いのゴールイメージの定め方

  • 決め事をしたい話し合い(特に意見が割れている状況)では、目標設定に一工夫すると良い
  • 目標設定の段階で、「いよいよ決まらなかったらどうするか」を参加者に提示し、必要ならみんなで討議して、合意しておくことが有効
  • 交渉の世界ではこれを BATNA(Best Alternative To a Negotiated Agreement) と呼ぶ

進め方を構想する

  • 会議の進め方は、目標達成のためにどのようなステップで議論していけばいいかを考えて設計する
  • 論点の時系列的並びを作る
  • 例:「今年の合宿先を決める」が会議の目標の場合
    1. 目的確認:合宿の主目的は何か?
    2. 与件確認:前提条件は何か?
    3. 各人要望洗い出し:どんなところに行きたいか?そこに行きたい理由は何か?
    4. 判断基準設定:行き先としてふさわしい基準は何か?
    5. 再検討:判断基準から考えて、もっと良い行き先候補は無いか?
    6. 評価決定:判断基準に照らし合わせて、最も良い行き先はどこか?
  • 現実にはこの通りに会議が進まないこともあるが、進め方の青写真を描いておくことで、途中で議論が混乱したときに立ち戻る場所が分かるようになる

イデア出しと評価選択を分ける

  • 進め方を検討するときには、「アイデア出しと評価選択を分ける」のが大原則である。アイデア出しと評価選択が同時並行で進む会議は、重苦しい雰囲気になってしまう場合がある。
  • 例:若手のスキルアップについて何をすべきか考える会議
    • A「外部のセミナーを受けるのはどうか?」
    • B「会社経費でそこまではできないな」
    • A「では社内で勉強会を開くのはどうか?」
    • B「業務で忙しいので皆が集まれるとは思えない」
    • A「...」
  • 案出し → 基準設定 → 評価選択の流れが良い

進め方の典型パターンを活用する

  • 会議の進め方の設計を楽にするために、テンプレを持っておこう、という話。
  • 問題解決型
    1. 何を解決しようとするのか
    2. 数ある問題の中でどれが深刻なのか
    3. その深刻な問題を引き起こしている原因は何か
    4. その原因を解消する打ち手は何か
  • イデア創出型
    1. 情報収集
    2. イデア発想
    3. 発想企画化
    4. 企画具体化
  • ビジョン策定型
    1. 過去を振り返る
    2. 現在を見つめる
    3. 未来を思い描く
    4. 決意を明らかにする

進め方を「見せる」

  • 会議の目的・目標を事前にメールで伝えたり会議冒頭で口頭確認するなどしても、それだけでは忘れてしまいがち
  • 目的や目標、論点、進め方、ルールをホワイトボードや紙に書いて掲示すると良い
  • 終了時刻も書いておくと良い

話しやすい場所を能動的にしつらえる

  • 元々あった配置で会議をしてしまいがちだが、これをやめる
  • 適度な広さ、話しやすい距離感、ホワイトボードの配置、おやつの準備など、会議の環境を能動的に作る
  • ガイドライン
    • 人数に合わせた会議室を使う
    • 机はくっつけたほうが一体感が出る
    • お互いの距離をなるべく近づける
    • 全員がお互いにアイコンタクトを取れるようにする
    • 全員からホワイトボードが見えるようにする
    • なるべく、上席・下席が明確に認識されない配置にする

『「60分」図解トレーニング ロジカル・ファシリテーション』第1章読んだ

かみ合わない会議をなんとかしよう

  • よくある会議の悩み
    • 意見が出ない
    • 議論がかみ合わない
  • 本書では後者の「議論がかみ合わない」会議を改善するためのコツに焦点を当てる

個人の論理思考能力任せでは限界がある

  • 議論がかみ合わない最大の原因は、会議の参加者一人ひとりの論理思考能力の欠如にある
  • しかし、参加者全員にその力を期待するのは現実的に厳しい
  • 我々は、ロジカルな人もそうでない人も集まった多様さが存在する場で、いかに議論をかみ合わせるかに挑む必要がある

ファシリテーターの存在意義

  • ファシリテーターとは、人がチーム活動をするときにそれが容易に進むように支援する役割を担う人のこと。当事者から一歩引いて、なるべく中立的な立場で、議論が少しでもまともになるようにお手伝いをする。
  • その人が意見の中身そのものを言わなくても、会議の進め方(プロセス)に介入することで、チーム活動を支援できる。これがファシリテーションの根底にある考え方。
  • ファシリテーターの役割は多岐にわたっており、議論をかみ合わせることだけではない。 が、本書では議論をかみ合わせることに焦点を当てる。

議論をかみ合わせるためのファシリテーションスキル

スキル 説明 必要となる場面の例
設定力 どういう会議をするのかを明確にして、参加者全員の意義を揃える 会議前・冒頭のお膳立て
要約力 個々の意見の重要なポイントを明らかにして、全員の理解を促す 意見出し
論拠検証力 根拠を引き出し、主張とつなげて、個々の主張の妥当性を検証する 意見出し
構造化力 個々の意見の相互関係を明らかにして、全体像・重点を把握する 議論の全体像・重点の明確化
合意形成力 意見の対立を乗り越え、全員の合意点を積み重ねて結論に辿り着く 最終意思決定
枠組み力 ふさわしい議論の観点を設定し、抜け無く、ブレにくい議論を実現する 会議全体

ファシリテーター = 司会進行役」か?

属人化の排除と責任感のトレードオフについて

スクラムでプロダクト開発をするようになって、約1年が経過した。

スクラムは実によくできたフレームワークであり、スクラムから得られたものはたくさんある。 例えば..

  • 今自分がやっていることに対して納得感を持って取り組むことができるようになった
  • 発生した問題に対して、その場しのぎではなく仕組みで解決することができるようになった
  • 同じゴールを共有するようになったことで、"チームでやっている"という感覚が強くなった。そのおかげで心理的負担が減り、同時にメンバー間も仲良くなった(と思う)
  • 優先順位に基いて業務を進めるようになったことで、属人化が減った

などである。

その一方で、デメリットとして最近感じているのは属人化を排除することで同時に個々人の責任感も削り落としてしてしまったのではないかという点である。

スクラム導入以前は、AさんはサービスAを担当し、BさんはサービスBを担当、というように個人が持つ領域が明確に分けて開発・運用をやっていた。今考えても、限られた人数でそこそこの規模のプロダクトを効率良く運営するにはこれ以外に良い方法が思い浮かばない。

当然この運営スタイルは属人化を強めてしまい、AさんはサービスAしか見れないし、また担当外のサービスBについてはほとんど関心が無いという状態になってしまった(少なくとも自分はそうなった)。 一方でメリットもあった。それは担当しているサービスに対する責任感が人一倍強くなるという点だ。障害が起きれば真っ先に対応するし、ユーザや関係者からの問い合わせがあればそれについても真っ先に対応する。サービスの短期的な面だけでなく、将来的な面についても検討することができていた。

スクラム開発では、スプリントバックログという形で1スプリントで取り組むタスクを優先順位で並べて可視化すると思う。優先順位でタスクを消化していくため、誰がどのタスクを取ることになるかはわからない。言い方を変えれば、どのタスクを取っても大丈夫という状態になっていなければならない(と理解している)。 このようなスタイルで開発を進めていくため、属人化された業務が減っていくわけだ。 そして、みんながサービスに対してある程度の知識を持つようになったことで、"ここは自分がやるんだ"という責任感も弱くなった。

心理学的に言えば 社会的怠惰 という現象に当てはまると思っている。「誰かがやってくれる」「自分が前に出なくても誰かが..」といった意識が無意識に働いているような気がする。 また「自分は1人ではなくチームでいる」という安心感が、危機感すらも鈍らせてしまったように思う。これまでは「何が何でも解決しなければならない」という気持ちだったものが、「今やれることをやっていこう。無理をしても仕方がない。」という方向になりやすくなった。

エンジニアの中で 属人化は悪 というのは常識のように語られ、自分もそれを信じていた。 しかし、もちろん自分の弱さもあるが、実際にそのデメリットを肌で感じることでこの通説に疑問を抱くようになった。今でも属人化が良いとは思っていないが。

何か、良い感じにバランスをとっていけるやり方は無いかなぁ。

...といったことを考えつつ、初心に帰ってスクラムの書籍でも読んでみようと思った2017年の秋だった。

SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK

とりあえずこれ買ってみた

『SRE サイトリライアビリティエンジニアリング』第6章読んだ

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

以下、『SRE サイトリライアビリティエンジニアリング - Googleの信頼性を支えるエンジニアリングチーム -』の第6章を読みながらメモをとったもの。第6章は「分散システムのモニタリング」というタイトル。


定義

  • モニタリング
    • システムに関するリアルタイム定量データの収集、処理、集計、表示を行うこと
    • 例:クエリの回数と種類、エラーの回数と種類、処理時間
  • ホワイトボックスモニタリング
    • システムの内部によって公開されているメトリクスに基づくモニタリングのこと
  • ブラックボックスモニタリング
    • ユーザが目にする外部の振る舞いをテストする
  • ダッシュボード
    • サービスの主要メトリクスのサマリビューを提供するアプリケーション
  • アラート
    • 人間に読まれることを意図した通知で、メールアドレスやページャなどのシステムにプッシュされる
  • 根本原因
    • ソフトウェアの欠陥やヒューマンエラーのうち、修正されれば同じことが同じように起こることがないと確信できるもの
  • ノードとマシン
  • プッシュ
    • サービス動作中のソフトウェアあるいはその設定に対する変更
    • memo: デプロイに近い??

モニタリングの必要性

  • なぜシステムをモニタリングするのか。その理由。
  • 長期的なトレンドの分析 のため
    • 日次のアクティブユーザがどういったペースで増加しているのか、など
  • 時間や、実験グループ間での比較 のため
    • ライブラリAとライブラリBではどちらの方が高速なのかを比較したり、サイトの速度が先週と比べてどうなっているかを比較したり
  • アラート のため
    • 何かが壊れていることや壊れそうなことを通知する
  • ダッシュボードの構築 のため
    • ダッシュボードは、サービスに関する基本的な疑問に答えるべきもの
  • アドホックな振り返り分析の進行(デバッギングなど) のため
    • レイテンシが急上昇したが、同タイミングで他に何らかの変化が生じていなかったか、など

症状と原因

  • モニタリングシステムは、2つの疑問に答えなければならない。それは、 “何が壊れたのか"と"なぜ壊れたのか” という疑問である。
    • “何が壊れたのか"という疑問は 症状 を示す
    • “なぜ壊れたのか"という疑問は 原因 を示す
  • “何が"と"なぜ"の区別は、シグナルを最大化し、ノイズを最小化する優れたモニタリングルールを書く上で最も重要な区別である

症状と原因の例

症状 原因
HTTP500もしくは400が返されている データベースサーバが接続を拒否している
レスポンスの速度が低下している CPUに過大な負荷がかかっている

4大シグナル

  • モニタリングにおける4大シグナルは、 レイテンシ、トラフィック、エラー、サチュレーション である。ユーザが直接利用するシステムで、メトリクスを4つだけ計測できるとするならば、この4つに集中する
  • レイテンシ
    • リクエストを処理してレスポンスを返すまでにかかる時間
  • トラフィック
    • システムに対するリクエストの量で、システム固有の高レベルのメトリックで計測される
    • Webサービスの場合、通常は毎秒のHTTPリクエスト数で計測されるが、リクエストの性格によって区分けされることになる
      • オーディオストリーミングのシステムであれば、ネットワークIOレートや同時セッション数に計測の焦点があたるが、キーバリューストレージシステムであれば、毎秒のトランザクションや取得数を計測することになるだろう
  • エラー
    • 処理に失敗したリクエストの割合
    • 失敗には明示的な場合、暗黙的な場合、ポリシーによる場合とがある
      • 明示的な場合:HTTPの500番台
      • 暗黙的な場合:HTTP200の成功レスポンスが返されているが、内容に間違いがある
      • ポリシーによる場合:例えば「レスポンスタイムを1秒以下にすると約束しているなら、1秒以上かかったリクエストはエラーである」というようなもの
  • サチュレーション
    • サービスがどれだけ「手一杯」になっているかを示す
    • そのシステムにおいて最も制約のあるリソース(メモリ、IOなど)に重点を置いて、システムの利用率を計測する

テイルレイテンシに関する懸念

  • 平均値のメトリクスの収集は危険になる場合がある。例えばCPU使用率やデータベースの平均使用率など、状況によって簡単にアンバランスになり得るものがあるため
  • 動作させているWebサービスの平均のレイテンシが毎秒1000リクエストの状況下で100msだったとして、リクエストの1%が5秒を占めることは容易に起こり得る
  • 低速な平均と、非常に低速なリクエストの「テイル」を最もシンプルに区別するには、レイテンシそのものよりも、レイテンシでパケット化したリクエストカウントを収集する。
    • 例:0 ~ 10ms、10 ~ 30ms、30ms ~ 100ms、100 ~ 300msといったような時間で処理したリクエストはそれぞれいくつだったかを見る

適切な計測の粒度の選択

  • システムの様々な側面は、粒度のレベルを変えて測定するべきである
  • 例えば、CPU使用率を毎秒収集すれば興味深いデータが得られるかもしれない。しかしこのような頻度での計測は収集、保存、分析のコストが非常に大きくなる。
  • サーバ内でサンプリングを行っておき、それらのサーバから順次データを収集して集計を行うように外部システムを設定すればそれらのコストを下げることができる(あくまで例)

可能な限りシンプルに、ただしやり過ぎないこと

  • これらの要求を全て積み上げると、モニタリングシステムは非常に複雑になってしまう
  • モニタリングシステムの設計をする際は、シンプルさに目を向けるようにする。以下は、モニタリングの対象を選択する上でのガイドライン
    • 本当のインシデントを最も頻繁に捉えるルールは、可能な限りシンプルで、予想しやすく、信頼できるものであるべき
    • ほとんど実施されないデータの収集、集計、アラートの設定は削除すべき
    • 収集されてはいても、事前に作成されたダッシュボードのいずれにも表示せず、どのアラートにも使われていないシグナルは、削除の候補

原則の取りまとめ

※ ここは全くの写しになりそうなので書籍参照。