ダメなグラフが仕事を滅ぼす(「グラフをつくる前に読む本」講演録)

松本 健太郎

 

本内容は、17年10月20日に開催されたDevLOVE関西主催「「グラフをつくる前に読む本 一瞬で伝わる表現はどのように生まれたのか」を語り尽くす」の内容を文字起こししたものです。

当日に投影していたスライドとともにお楽しみください。

 

 

2種類あるグラフの作り方

私の主張は、今回のお題のサブタイトルにもあるように「ダメなグラフが仕事を滅ぼす」です。

大げさな表現に聞こえるかもしれません。しかし、何度もそのような光景を目の当たりにしてきました。

 

その理由を話す前段として、まずグラフの作り方には2種類あるという話をします。

1つ目は、普段から皆さんが特に意識せず行っているグラフの作り方です。

手元にデータがあって、まずグラフにして、そのグラフを見て言いたいことを言います。

一方で、それとは間逆のグラフの作り方があります。

まず言いたいことがあって、それに適した表現方法を考えて、最後にその表現に適したデータを採取するか加工します。

例えば、以下のグラフを見てください。どちらのグラフが適切だと言えるでしょうか?

 

 

どちらも同じ棒グラフで、表現軸が年単位かQ単位に過ぎません。どちらも表現方法に間違いはありません。

しかし、グラフに付けるタイトルが「今期1年すごく頑張りました!」だったらどうでしょう。右の年単位の折れ線グラフを選びますよね。

なぜなら左の折れ線グラフでは、3Qが突出しているので「3Qは偶然じゃないの?」「たまたまじゃないか」というツッコミが考えられるからです。つまり自分の言いたいことを言うのに適した表現方法では無いのです。

左は手元にあるデータをそのままグラフにした。右は言いたいことを言うためにデータを加工してグラフにしたといえるでしょう。

 

そもそもグラフとは何か?

ところで、そもそもグラフとは何でしょうか。

 

私は情報を端的に伝える方法だと考えています。

つまり、情報量はそぎ落とさずに、視覚表現量は徹底的に減らして、パッと見るだけ分かる状態にまで落とし込んだグラフこそ「端的」だと言えるでしょう。

様々なグラフを考案したウィリアム・プレイフェアはグラフについて「表なら1日かかってしまうのと同じ情報の量を、5分で得られるようにする」と言いました。

したがって、グラフにするとは「見える化」とは必ずしも同じとは言い切れないのです。

グラフで表現するとは、見えなかったものを見えるようにするのではありません。ましてや数字の可視化だけを表していません。

見ず知らずの多くの人にデータを容易に伝達するため視覚表現量を減らした方法がグラフなのです。

つまり容易ではない、視覚表現量が減っていないグラフは「見える化」できていないのです。

 

棒グラフ、折れ線グラフ、円グラフそれぞれの特徴

次に、グラフそれぞれの「適した表現方法」についてお話していきます。

最初に棒グラフです。

 

 

棒グラフの棒の高さが、データの量を表しています。だから、1つの棒を基準にその他の棒と高さを比べられるのです。

つまり棒グラフが得意なのは「比較」です。棒の高さを比べて、その違いを感覚的に掴めるのが特徴だと言えます。

したがって何を「比較」するのか、データ項目をどのように並べるのかを考えるべきです。

 

次に折れ線グラフです。

 

 

折れ線グラフの線の位置が、データの量を表しています。だから、データ項目のある点と点を結ぶ線の傾きから傾向が分かるのです。

ちなみに点と点は連続している必要があります。

例えば、A社の売上とB社の売上は「売上」という見方では連続しているかもしれませんが、指標としては何も関係ありません。

指標として関係無い物同士を紐付けて折れ線グラフで表現するのは「もどき」です。だから同じ指標の経過という観点で、折れ線グラフは殆どが時系列データになります。

つまり折れ線グラフが得意なのは「推移」です。時間経過による線の傾きを目で追って、変化を感覚的に掴めるのが特徴だと言えます。

したがって全体を「俯瞰」すれば、推移から傾向も見えるようになります。

 

最後に円グラフです。

 

 

円グラフの円の内角が、全体に占める内訳を表しています。

つまり円グラフが得意なのは「内訳」です。角度を比べて、内訳を感覚的に掴めるのが特徴だと言えます。

ちなみに全体を「俯瞰」して内訳を見れば、万遍無いのか、どこかのデータ項目に偏っているのかも分かります。

 

「仕事を滅ぼすダメなグラフ」はどっちだ

グラフそれぞれの「適した表現方法」が分かったところで、次にダメなグラフを見ていきましょう。

 

 

どちらのグラフが「ダメ」でしょうか。一見して左がダメだと何となく分かりますが、その「何となく」を言葉で表現してみましょう。

私なりの言葉では「円グラフは全体の内訳の表現に適している。だから7年分の売上の年毎内訳を知りたいなら左。しかし部門別だったらともかく、時系列なデータの全体売上内訳に何の意味がありますか?」となります。

次のグラフはどうでしょう。

 

 

どちらのグラフが「ダメ」でしょうか。右はたまに見るダメなグラフです。何がダメでしょうか。

私なりの言葉では「折れ線グラフは推移の表現に適している。各課の売上の推移を知りたいなら左。しかし各課の売上は指標としては別。これは線で紐付けてはいけない折れ線グラフもどきだ」となります。

 

では、ちょっと趣向を変えてみて、次のグラフはどうでしょう。

 

 

言わずもがな、ですね。では、次のグラフはどうでしょう。

 

 

同じグラフでも、添える言葉を変えるだけで「適した表現方法」が変わることが伝わったのではないでしょうか。

前半の2つは見ただけでダメと分かる表現方法を使っていました。しかし後半の2つは、どちらも表現としては間違っていないけど、言いたい内容に沿えていないことが分かるかと思います。

世の中、前半のようなグラフだけでなく、後半のようなグラフも飛び交っていますよね。

 

なぜダメなグラフが仕事を滅ぼすのか

最初に、グラフの作り方には2種類あるという話をしました。

手元にあるグラフをそのままグラフにする場合と、自分の言いたいことをグラフにして纏める場合です。前者は数字をジックリ見るために視覚表現量を減らして見るため、後者はパッと見てパッと分かるため、グラフにするのです。

すなわち、グラフには論理的にジックリ考えるためのスロー思考用グラフと、直感的に直ぐに分かるためのファスト思考用グラフの2種類あるのです。

 

今年(2017年)のノーベル経済学賞は行動経済学でしたね。2002年にノーベル経済学賞を受賞したダニエル・カーネマンが著した「ファスト&スロー」を読まれた方もいらっしゃるでしょう。それはグラフにも当てはまるのです。

スロー思考が求められる現場で「考えられるグラフ」を作れなかったら負けだし、ファスト思考が求められる現場で「考えさせないグラフ」を作れなかったら負けです。負けっぱなしの現場が多いから仕事が滅ぶんです。

例えば、ソフトバンク株式会社のIRプレゼンテーション資料をご覧になられた方はおられますか? 「考えさせないグラフ」のオンパレードです。直感的で、パッと見たら「凄い!」となりますが、10秒見続けたら頭の中が疑問だらけに埋め尽くされます。

作り手がファスト&スローに合わせているんですよね。

 

ここで、もう1度、最初に見せたグラフを紹介します。

 

 

左がスロー思考グラフ、右がファスト思考グラフですね。

どちらが良いか悪いかという議論ではありません。

僕は「グラフを作る手間を省いて、ファスト思考の場にスロー思考なグラフを持ち込むな」と言っています。

ただえさえ、エンジニアの人が監視しているツールのグラフは見にくいのです。

その見にくいグラフを、意思決定というファスト思考の場に持ち込めば、待ち構えるのは「混乱」しかありえません。だから仕事が滅びるのです。

すなわちダメなグラフとは、ファスト思考の場におけるスロー思考なグラフであり、スロー思考の場におけるファスト思考なグラフです。

 

練習問題

さて、ここで練習問題です。実際にグラフを作ってみましょう。

まず状況を説明します。

みなさんは、あるプロダクトの開発チーム陣です。プロダクトリリース後、不具合が立て続いたため、えらい人が集まる会議での説明が求められています。不具合の対応した結果、手元にあるデータを使って「もう大丈夫!」とえらい人たちを安心させてください。

不具合1つ目です。深夜に実行されるバッチ処理の遅延です。 SLOでは30分以内としているが、 5日連続して60分を超過して、6日目にハード増設により縮小、12日目に30分以内に収まりました。

 

日にち バッチ稼働(分)
10月12日 70
10月13日 60
10月14日 61
10月15日 66
10月16日 70
10月17日 53
10月18日 50
10月19日 47
10月20日 45
10月21日 41
10月22日 39
10月23日 35
10月24日 27
10月25日 25
10月26日 23
10月27日 27
10月28日 29
10月29日 23
10月30日 26
10月31日 24
11月01日 21


 

不具合2つ目です。機能1~7のリリース後、画面上で障害が多発しました。しかしトリアージして無事に解決しています。

 

箇所 影響範囲 不具合件数 修正工数
機能1 6 21
機能1 3 5
機能2 1 1
機能2 2 10
機能3 2 7
機能3 8 12
機能6 3 3
機能6 9 21
機能6 11 23
機能7 2 7
機能7 1 2
機能7 2 4


 

さて、それぞれどのようなグラフが適切でしょうか。

人それぞれだとは思いますが、私ならこのようなグラフに仕上げます。まず、1つ目について。

 

 

殆どの人が折れ線グラフで描くでしょうが、あえて私は棒グラフにしました。折れ線グラフは推移を表現するので、どうしても6日目の10月17日~23日にかけて緩やかに減少した箇所に目が向きます

なぜもっと早く解決できなかったのか?という誰もが浮かぶ疑問を描きます。色々と理由はあるのだし、それを隠すつもりも毛頭無いし、説明するのはやぶさかではないが・・・というエンジニアの心情が浮かびます。

だったら棒グラフで表すべきです。棒グラフは「比較」に使われますが、基準無しに比較するのは難しいのです。だから障害発生期間中を赤く塗り、それらのおおよその時間を基準にします。

17日も19日も30日も俯瞰で同時に見ることに多くの人は慣れていませんので、「ハード増設後に処理時間が縮小」と言葉を添えれば良いでしょう。

 

次に、2つ目について。

まず障害が多発していると言っても、影響範囲の狭い「低」が半分を占めていることをシンプルに棒グラフで表現しましょう。

積み上げ棒グラフや円グラフでも良いかもしれませんが、割合にしてしまうと実際の件数に都度置換するという脳内計算が発生するので、あまり使いたくありません。

そして、今回は取り上げていませんでしたが、ヒートマップも使います。どの機能で、どれくらい障害が多発しているのか、色で分かります。

 

 

このヒートマップで大事なのは、機能4と5には不具合が無いことを「ない」とキチンと表現している点です。無いものを無いとグラフで表現するのも大事です。俯瞰してみれば機能3と機能6に障害が多発しているので他に不具合が無いか調べると補足しても良いかもしれませんね。

 

最後に

グラフの作成はセンスではなく、理論・理屈です。「理」が大事です。

「理」を分かるためにも、ぜひ僕の本を買ってください(笑)。ご清聴ありがとうございました。