読書：鬼速PDCA／PDCAノート

みんな大好きPDCA。でも実際の仕事に落としこみにくいのもPDCA。PDCAの導入に悩めるあなたにおすすめしたい本2冊です。

私もチームを持っていますが、自分がPDCAを伝えきれているかというと、できていないと感じています。
皮肉なことに、インシデントが発生して初めてPDCA全体を見直すなんて話はよくあることです。

自分なりに見直し整理するために、PDCAにまつわる本を読みましたのでご紹介です。

職業柄、WEBを中心としたPDCAに意識を向けてしまいがちですが、PDCAは大中小様々に回していくものだということを、あらためて気づかされました。
また、一口にPDCAメソッドといっても、ツールをフレームとして利用するか、基本概念として導入し、ツールはアウトプットであるとするのかで、アプローチは異なります。導入しやすさでいえば前者ですが、応用がきき、チームとして使いやすいのは後者と思いました。

「自分を劇的に成長させる！　PDCAノート」　岡村卓朗／フォレスト出版

PDCAの回し方にフォーカスして「PDCAノートメソッド」というツールで可視化し、仕組みに落とし込んで習慣化する方法論と考え方を、大きな文字と分かりやすい文体で解説した本。
どちらかというと、自分のPDCA整理やアウトプットに向いていると思います。また、PDCAに不慣れなメンバーへの導入に使えると思います。
方眼のノートでPDCAを管理する方法は他でも紹介されているのですが（例：http://dime.jp/genre/235907/?first=1）、PDCAそれぞれのステップと定義、そしてフレームとしての「PDCAノート」を提示していることが目新しいと感じました。
チームへの導入はちょっとやりづらい。担当者レベルでのTODO管理はそれぞれなので、リレーションあるいは統合が紙ベースだと難しい。なので、個人向けと感じました。

「鬼速PDCA」　冨田和成／クロスメディア・パブリッシング

PDCAを「前進するためのフレームワーク」と位置付け、PDCAのうちのAを「Adjust（改善、調整）」と再定義し高速で回していくメソッドを紹介している本です。特に「Adjust（改善、調整）」についてはすごく納得。ビジネススキルとしてのPDCAの解説書ですが、どのシーンでも使えるのではないかと。また、DOとTODOの違い、DOの定量化KDI（KEY DO INDICATOR、冨田氏が作ったワードとのこと）などなど、すっと腑に落ちる説明でした。
個人的には第8章の「チームで実践する鬼速PDCA」が参考になります。なにが“鬼速”かというと、週2回のミーティングで実行サイクルを確認していること。その前提として、鬼速PDCAの概念、落とし込み方が他メンバーも理解していることが必要です。導入にあたって、まずは、付録の「10分間PDCA」や、先に紹介した「PDCAノート」の付録サンプルを使ってみたいと思います。

【解析いろは18】アクセスログ解析のKGIとKPIの意味

昨今、どこのサイトや本にも「ウェブサイトのKGIとKPIを決めてPDCA回そうぜ！」と書いてますが、よくよく読んでみるとKGIとKPIの内容がそれぞれで微妙に違ってます。で、実際、特にこれからウェブサイトのKGIとKPIを策定する場合に悩むことが多いのではないでしょうか。

１．結論
早っ！　いや、これ正解というものを求めると訳が分からなくなるので最初に書きます。　
・大目的（ゴール）、それを達成するための目標と手段と計測手段（指標）の関連性が密であり、 
・レポート内でのそれらの定義をブラさない。
・それらを常に意識して指標を見る。
ことができれば、どれを何と呼ぼうが全然構わないと思います。でも分析する側は、自分の中とクライアントの間に共通の定義を持っておかねばなりません。これは絶対のお約束です。それをどうやって決めているのか（というより、どうしてこうなった！的な）ということをちょっとご紹介します。

「こういう目的のサイトにはこんなKPIを見るといいよ」的な内容を期待されている方もいらっしゃるかもしれません。なので、末尾に参考リンクを掲載しておきます。しかし重ねていいますが、それがあなたのクライアント全てに適しているとは思えません。結局は結論の1～3に戻らざるをえないと思いますよ？
 
2．「日本流」？のKGIとKPI
海外の解析ツールの仕様を確認していたとき、 主な指標が一覧できるダッシュボードで「重要評価指数（KGI）」というタイトルがついてました。
しかし、あるケースでの私のKGI、KPIの考え方は大体下記のような感じだったんです。
  =====================
（例）
★ウェブサイトの目的（ゴール）：企業の活動内容と製品の認知度向上
　■KGIその1：サイト全体の直帰率を下げる
　　　┗KPI(1)　サイト全体の直帰率　／判断指標　サイト全体の直帰率
　　　　　┗想定されるアクション（対策）　直帰率の高いサイトトップページの見直し

　■KGIその2：企業CSR情報ページを良くみてもらう
　　　┗KPI(1)：CSR情報コンテンツのッション数増加／判断指標　CSRコンテンツのセッション数　　　　┗KPI(2)：ページインデックスの特定のコンテンツ誘導バナーをクリックした数／
  =====================
いわば、KGI＝何がしたい、KPI＝何をする＋その判断、計測の指標をピックアップと、3段重ねでした。 なぜそんなこってこてにしたかというと、このケースにおいて、レポートする先の用語や解析内容の認識など、アクセスログ解析に対するリテラシーがさほど高くないからでした。

（ウェブサイトの本当の意味でのビジネス活用については最近になって浸透してきて、ようやく効果測定しなくちゃねというところに辿り着いたと思います。ですからソーシャル解析とその効果測定については、早いところはやってるけど、まだ少数派だと思います。）

話を戻します。解析ツールでKPIとして表示されている指標は、設定したKPI（を測る指標）として該当するものもあれば、そのままでは出てこないものもあります。ですので「これKPI（ドン！）」と出されてしまうと「じゃあこちらで設定したKPIの扱いはどうすれば？」とちょっと混乱したんです。
開発側にそのKPIの意図を聞いたら、海外ではこれで分かる。日本人が見るとそれまで使ってきたKPIと意味が少し違うようだ。という話でした。
海外がどうか、という話は海外案件をやったことがないのでわからないですが、この差は何かということを考えた場合、ある数値に対する認知、理解なんじゃね？と思った次第です。

アクセスログ解析という多くのユーザーが使うプラットフォームでも、取得する値とそれを当てはめる指標は共通です。 それら数値をどう使うか、というのがユーザーによって異なるだけです。えーとつまり、前記の（例）を書き直すと…
 =====================
★ウェブサイトの目的（ゴール）：企業の活動内容と製品の認知度向上
　■KGIその2：企業CSR情報ページを良くみてもらう
　　　┗KPI(1)：CSRコンテンツのセッション数　（←CSR情報コンテンツのッション数増加を測るため）*この緑の部分は記載しません
  =====================
とまあ、こんな感じです。KPI＝Key Performance Indicator　なのですから本来的にはこの使い方が妥当でしょう。業務上、簡潔に状況把握するにはこちらのほうがやりやすい。数値を見て把握できるわけですから。KPIの判断指標を「なぜそれを見るか」「その数字に対してどういう評価をすればよいか」がきちんと認知されていれば（←～　）は不要なんですね。「共有知」という言葉がしっくりきます。業務で、絶対に会計や営業では売上げや見込みといった指標を元に分析や把握をしてますよね。それが「共通の認識と言語」であれば数値だけで報告は通用するのです。PVやユーザー数の増減を見て一喜一憂しているだけ、というのとの差はここにあります。指標を見るという点では行為は似ていますが得られるものが全然違います。


（なぜ日本の（？）KPIが回りくどいのか、なぜアクセスログ解析の指標が指標単体で「良い・悪い」といった判断基準になりにくいか、というのは特有の理由が思いつくのですが長くなるのでこれはまた今度。（いつだ！））

でも、「共有知」は短時間で生まれるものではありません。だからレポート内容一本で理解してもらうためにブレない程度にKPIを具体的・詳細に書くことも許されるのでは、と考えます。従ってレポートを作る前に、

 ・大目的（ゴール）、それを達成するための目標と手段と計測手段（指標）

は絶対に決めておく必要があるわけです、はい。KGIやKPIを考えるにあたって、どれを使うということを提示する前に、定義の内容と、それでクライアントの理解が得られるか、がとっても重要ですよね、という話でした。

＜参考リンク＞

具体的にどのようなKPIを採用すればいいのか、という参考です。記事の掲載年がちょっと古いのですが、内容はまた賞味期限だと思います。

Web担：Web解析のためのKPI大全

http://web-tan.forum.impressrd.jp/e/2011/04/05/9719

Web担：KPIづくり実践術 徹底解説（1） - ゴールが明確でないサイトでも大丈夫!

http://web-tan.forum.impressrd.jp/e/2010/05/12/7831

 

【解析いろは7】ウェブ解析のＰＤＣAサイクルのP、「仮説」について

ウェブ解析でもPDCAサイクルでの思考がほぼ当たり前になってきてます。その中で仮説を立てるという作業（P＝PLAN） はどういうことなのか。というお題です。
 
ウェブ解析のフローにPDCAサイクルを当てはめることが流行ってます（流行ってるっていうな）。「そんな風に具体的に説明するとなんとなーく説得力があるから」という実利的な理由もあります。
本音はさておき、PDCAサイクルに解析業務を当てはめるのは、ウェブサイトが業務の内容として占める比重が大きくなり、よりビジネスに貢献することが求められるようになってきたからですね。ウェブ解析は単発では あまり役に立たないですしね。現状把握ができたとして、次に改善したときに効果を検証するには、やっぱり解析が必要です。その意味では現時点では合理的な説明方法といえます。まあ、ただ現場で本気でPDCAに取り組んできたおっちゃんたちには「はぁ？ウチらとっくにそういうのやってんだけどー」という生温い気持ちにもなりかねません。企業の人たちは本当に本気で会社の業務を回してきるのですよ。そこへ外部の人間がドヤ顔でPDCAが・・・なんて語りだしたらどうなるでしょう。
ぺらっぺらな言葉だけで語るのではなく、「御社と同様のビジネスの理論を根底に、我々もウェブをビジネスとして真剣に考えてます」という姿勢を提示すべきだと思います。

長いマエフリになりましたが。PDCAサイクルに則って考えよう、のうちのP=PLAN、仮説立案についてちょっと考えてみました。かつて、すごく率直な疑問を投げかけられたことがあります。
(1)「ウェブ解析での仮説はどのくらいの精度（信憑性）なのか」
(2)「その仮説は仮説を立てる人の思考やスキルに依存しているのではないか」

(1)「ウェブ解析での仮説はどのくらいの精度（信憑性）なのか」
多くの人はどれくらい、という程度を示すのに数字を使いたがります。そうすることで論理の信憑性を補強したいわけです。
これが統計であれば、絶対的・客観的な統計データを元に%の確率で・・・という数字が出せるかもしれませんが、そもそもウェブ解析のデータは「相対的な」数字の上に成り立っています。 そこから生じる仮説の実効性の確率をはじき出すのは困難ですというかムリです。
例えば、研究開発におけるPDCA。数ある遺伝子のうち、ある細胞を作るたに働く遺伝子を特定しなければならない。その場合、数字的な確証を持って実験を行うだろうか？もし数字的な確証を持ってやれるのならそれはすでに確立した理論であって他の人もやっていることではないか。と。

数字や科学反応といったものへ信頼の根拠を求めるのは、不安があったり納得していないからではないでしょうかね？

私の（現時点での）結論は、相対的な、固有のデータを見て、集計して、そこからわかること、推察できることに確率としての数字は出せません。 ですので、その考えに至った思考過程と根拠となるデータを提示します。その上で、私はこう思います。このことにはこういう対応が可能です。と、私なら答えます。
間違ってはいけないのは、ウェブ解析は「答え」を出す行為ではないはずです。ビジネス的な、DO（実行）の判断をするのはあくまでもクライアントで、我々は情報を提供し、最大限協力はできますが、ビジネスの主体はクライアントなのです。 数字への信頼ではなく、ウェブ解析をするプロとしての信頼を得ることが重要と思ってます。答えになってないって？だから答えは出すものではなく・・・
 
(2)「その仮説は仮説を立てる人の思考やスキルに依存しているのではないか」
人間が介在する以上、依存すると思います。正直、経験の差もありえます。
解析担当として、その仮説に不安がある、自分でもちょっと・・・と思う場合は、営業ふくめ社内で検証してみるといいでしょう。ピンの場合は？　守秘義務の範囲内で同業に意見を求めるのも手だと思います。最終的には自分が責任をもってレポートを提出するわけですから、論理破綻がないようにだけは気をつけないといけません。
正解や答えを出そうとすると、数字に基づいたありきたりな内容、ベタベタな指標の説明のみに落ち着きかねません。わかったようでわからないレポートだけが後に残り、読み捨てられていくのです。（アイタタター）
徹底的に調べる・時に他者の参考意見を聞く・論理の道筋が通っていることが「仮説」の信頼性をより厚くすると思っています。
さっきの細胞の話に戻りますけど、可能性のある細胞をひとつの培養皿で培養しました。乱暴な話ですよね。でもそこに至るまでに、膨大なDBを解析し、徹底的に調べ、可能性のある細胞を24個に絞り込んでいるのです。もちろん、はずれる可能性だってあったでしょう。はずれても恐らく、この実験をした人はまた解析し、調べて、別の細胞で検証したと思います。ああ、見事なＰＤＣAサイクル・・・（仮想の話です）。
つまり、仮説というのは想像でも妄想でもヤマ勘でもありません。そこに至るまでの筋道があり、ある程度の精度を備えている。もし成果がでなければ、その筋道を変えてみる。経験やスキルで仮説の差が出るのは、その道筋を経験則（成功体験あるいは失敗）である程度把握し、理解しているから結論への道が短いということだと思います。経験者も失敗しますし、初心者だからこそ鋭い洞察が可能なことがあります。なので、一概に経験数で語れない、ということも仮説にはあります。私個人は経験則や経験年数はあまり信用してません。判断が古いデータに基づく場合も多いからです。 経験をもちつつ、経験に依存しない、まったいらな目でデータを解析できる人が優れた解析者だと思います。そうありたいなぁ・・・と思います。