カスタマーサポートの機能を整理する
カスタマーサポートの機能について自分なりの考えを整理してみたので、備忘録として残しておく。以下、カスタマーサポート＝SP、カスタマーサクセス＝CSとする。
SPのアウトカム
- プロダクトをストレスなく活用できるようにする
- そのために、ユーザーが機能面で戸惑ったときに支援をする／ニーズを吸い上げて新規機能開発の起点となる
※ 問合せに回答するのは手段でしかない
SPの機能
- ①すでにできることをできるようにする
- ②まだできないことをできるようにする
- ③上記2点の機能を最適化する
※SPの領域を機能＝技術仕様に限定して、CSは目的＝活用方法の模索を取り扱う形が1つの考え方。CSにエクスパンションの役割を担わせるのであれば、CSはBiz側／SPはDev側で切り分けるこのやり方は妥当に思う。どう分けるかは目的次第。
改善に向けた検討の観点
①すでにできることをできるようにする
- 問合せから回答までの業務フローは以下の通り。とにかく早く回答するのはもちろん、できれば今後発生しうる問題も予防しておくのがポイント。
1）問合せを発生させない
- そもそも問合せが発生するのはプロダクトが使いにくいからであり、ストレスなく活用してもらうには問合せを撲滅する努力が必要である。
- 根本解決するには、プロダクトにわかりにくい／誤解を招くものを残さない。ユーザー視点での体験設計が重要となる。
- 仮にわからないことがあったとしても、ユーザーが自己解決できるようにする。静的＝サポートページを充実させる、動的＝チャットボットで対応する、そしてそこまでの導線をわかりやすくする。
2）問合せ内容を明確にする
- 問合せ内容の詳細を確かめるためにコミュニケーションをするのは、ユーザーにとって手間なこと。一方で、詳細の確認には詳細な情報が必要になる。
- そこで、問合せ内容をフォーマット化や注意書きをすることによって、ユーザーからもう少しリッチな情報を出してもらうのは1つの方法となる。
- ただし、上記はユーザーに負荷をかけることになるので、システムログから操作環境を特定したり、別システムから顧客情報を取得するなど、補完情報を取得するやり方がある。
3）回答精査のコストを削減する
- 自分でわかっているから回答できる（自力）、確認すれば回答できる（セルフサービス）、相談すれば回答できる（SPチーム／Devとの協力）、の3つの方法があり、前のものほど望ましい。
- 自力：既存機能の理解と新規機能のキャッチアップが必要になる。前者はアサイン時のオンボーディングでの対応、OJTでの対応、日常のナレッジ共有で対応できる。後者は開発時のQAに参加したり機能共有の場を設けるほか、開発に関与するのも役に立つ。
- セルフサービス：過去の回答履歴の蓄積、ドキュメントの整備などで対応できる。
- SPチーム／Devとの協力：相談する際のフローやツールが最適化できるとよい。また、個別事案が蓄積されてセルフサービスの情報源とするのも想定しておく。これもなるべくなくす方向で取り組むのが重要である。
4）問合せを予防する
- 問合せをもらっていた内容そのものに回答することはもちろん、過去の対応履歴からここで疑問を抱くとその後ここで疑問が発生しやすいというのを踏まえて、先回りした助言を入れておく。
- 予防の観点に関わらず、補足情報を合わせてお知らせするのは顧客体験にとってはよいことである。
- また、作業代行は原則してはいけない。ユーザーの利用能力を伸ばすのが基本の考え方となる。
②まだできないことをできるようにする
- 問合せから回答までの業務フローは以下の通り。基本対応としては、一次回答として代替案を提示し、中長期的には機能開発を進める。このとき、スケールするかの観点から個社対応は受けないこともあるので、返答の際には期待値のコントロールが重要になる。
1）顧客要望の開発要件への読み替え
- 顧客の問合せ／要望は言葉のままに受け取らず、何が目的で、それはマクロにみたときにどれだけのインパクトがあるのかを考える。
- SPのみで進められる話ではないので、どこまでをSPで対応するかは組織内での文脈次第になる。
2）開発効率化への寄与
- 開発を進めていくにあたって発生した不確実性について、場合によっては問合せのあった顧客も巻き込みながら解消に努める。
- こちらもどこまでやるかは文脈次第ではある。
3）開発完了の報告
- 問合せ進捗と開発進捗は別管理されていることが多いので、完了した開発課題がどの問合せに紐づいているのかを特定して報告する。
③上記2点の役割を最適化する
- 上記のような内容を業務プロセスに落とし込むために、現状の理解と打ち手の整理や実装を行う。いわゆるOpsの役割となる。
- 業務フローを回すことでデータが自然と生成されるような仕組みを作る。なるべくシステムから拾えるデータはシステムから拾い入力負荷を軽減する。仮に負荷がかかる場合には、コストに対するリターンを正しく提示する。
- 業務フロー上で生成されたデータを蓄積し、現状のプロセスの理解や打ち手の検討に使えるようにする。
- システム内部にストックされたデータを、人間の認知負荷を補完するようにチャットツールなどのコミュニケーションフローに落とし込む。
- 業務プロセスを適切に回せるようにするため、個々人の能力の底上げを行う。いわゆるイネーブルメントの領域。
- 原則、運用メンバーは認知負荷を軽減するためインターフェイスは限定するため、裏の仕組みはブラックボックスになりやすい。負債化しないように、複数人で運用できる体制やドキュメントを残しておく。
- 運用とOpsをジョブレベルで切り分けるのは、もちろんグロースするプロダクトでスケールする体制を整備するのもあるが、フォーカスするイシューを短期と中長期で切り分けて、自然と中長期のイシューにリソースを配分できるようにするためであるとも思った。
THE MODELは本当に使えるやり方なのか？
以前の記事「マーケティングをわかりにくくしているのは何か」で、マーケティングの意味することを3種類にまとめて、では何がマーケティングを考える上で重要なのかについて、別の記事「マーケティング推進のための7つの重要な観点」で整理してみた。今回は、多くの企業で導入されてきたTHE MODELの営業プロセスモデルについて、これが本当に使えるやり方なのかについて考えてみたい。
先に結論
THE MODELは使えるモデルだと思う。ただし、それが本当に使えるかどうかは個々の業界や組織の文脈に依存するので、自身の文脈においてはこういう調整を行った方がいいのではないかと正しく考えることが必要になる。そして、そのときに以前の記事は役に立つはずなので、ぜひ読んでみてください（笑）
THE MODELとは何か
THE MODELとは、Salesforceの事例に基づいて定式化された営業プロセスモデルの名称であり、マーケティング（見込顧客の開拓）→インサイドセールス（見込顧客を顧客化）→フィールドセールス（クロージング）→カスタマーサクセス（クロスセル／アップセル）と顧客の購買プロセスに合わせて営業・販売活動を分業化していくというものである。
顧客の購買プロセスを基準とすることで、顧客の検討のポイントに合わせた情報提供と段階移行の促進活動が円滑に行えるほか、検討フェーズによって対応すべき内容と求められるスキルセットが異なるため、分業と専門化によって個々の業務が効率化されることになる。購入側も販売側もいいことのように聞こえる。
とはいえ、単純にこのモデルをそのまま導入すれば成果が出るわけではない。とりあえず入れてみたけれど、上手く機能していないという声はよく見かける。ここを考えるためには、「Salesforceの事例に基づいて定式化された」点を考えてみるとよい。
THE MODELの文脈を考える
THE MODELは、Salesforceの事例に基づいて定式化された。では、この事例における文脈とはどういうものなのだろうか。
①そもそも、なぜ顧客の購買プロセスが変わったのか
THE MODELの背景には、売り手の都合ではなく買い手の都合に着目する重要性が高まっているということがある。これはなぜ起きたのか。それは、一定の品質のプロダクトについてはある程度の競合があり複数から選択できる状態になっていることと、顧客が自身で取得できる情報量が格段に増加したことで、顧客自身が検討を深い水準まで進められるようになったことによる。過去であれば情報の非対称性を悪用して誤認により買わせることができたのが、今ではその余地が狭まっているのである。
②欧米の労働市場の特性
日本の労働慣行は個々のジョブ単位ではなく組織人員の単位で雇用を行うメンバーシップ型と呼ばれる形になっているが、Salesforceは米国企業であり当然ジョブ型雇用を前提としている。社会全体としてジョブ型雇用がベースになっている場であれば、分業化した営業プロセスモデルを設計するのは至極当然のことである。
③フィールドセールスのコスト感覚
インサイドセールスは日本においては最近発生してきたものに過ぎない。これは訪問されてこそ誠意があるというような営業慣行も当然背景にあるが、それに加えてフィールドセールスのコスト感覚が違うということもある。米国の広大な国土を思い浮かべてみれば、フィールドセールスをしようとしたときにかかるコストが段違いなことは容易に想像できるだろう。
④メトリクスを適切に計測するデータ基盤
THE MODELの考え方には、検討プロセスを順序関係のあるファネルの形として捉えることで、フェーズの意向を数値として把握可能ということがある。当然ながら、これをやろうとすると適切にメトリクスを計測することが必要で、Salesforceというソフトウェア企業がデータ基盤の構築に秀でていたのは言うまでもないことである。
日本での応用を考える
上記の文脈を考えると、逆にどういった点を踏まえて調整しなければならないかがわかってくる。
①買い手の都合への着目
購買の意思決定をする主導権が購入側に移ったということは、それを前提にしながら検討プロセスごとに必要な情報を出し分けたり、探そうとしたときに必要なコンテンツを見つけやすいようにする必要がある。無理やり購入させようとするのは顧客の反感を生むことになるので、より相手の立場を踏まえた営業行為が必要になっている。一方で、ジョブベースで動いていない日本では商材によっては顧客のリテラシーが上がっていない領域もあると想定され、場合によっては使い分けをすることも考えうる。
②適正な人材を採用できるか
THE MODELがはまり易いBtoB SaaSをはじめとしたソフトウェア企業は別だが、労働市場にTHE MODELの個々の職務に関して十分に経験のある人材は限定的にしか存在しない。分業をさせた個々の職務の人材要件を明確にし、かつ最適な人は見つからない前提で転用できる経験を持った人を育成する視点が必要になる。このとき、その後のキャリアパスの観点についても検討ができると望ましい。
③フィールドセールスの有効性
コストが低いならという販売側の都合でもそうであるし、顧客側として安心感／信頼感が大きいからという理由でも、フィールドセールスをどこまで使うかは検討の余地がある。もちろん、フィールドセールスの方が安心感／信頼感があるのではないかという前提を疑うことも大事ではある。ここは個別の文脈によることなので、小さく実験をしながら、どこまではオンラインでも可能で、どこからがオフラインのが望ましくてという境界を理解し、最もレバレッジの効く体制にすることが望まれる。また、初期のイノベーター／アーリーアダプターはインサイドセールスベースで、グロースをして顧客の特性が変わってからフィールドセールスやパートナーセールスを組み合わせるというのも検討のポイントになるだろう。
④メトリクスを正しく使う
メトリクスを計測するのは前提である。事業会社内部でのソフトウェア開発能力が貧弱な日本企業では、この時点で若干怪しいところが出てくる。また、データを精緻に取るために、営業に細かい数値まで報告義務を課して従業員体験（EX／Emploee Experience）が悪くなるというのもよくありそうな話である。なるべく人間の負担がかからないよう自動化すべきだし、人間に負荷をかけなければならないやり方は小さく始めたり、何より負荷の分だけリターンが返るよう設計することが重要である。
正しく全体最適をさせる
以上、4つの観点から整理をしてきたが、全体最適の観点でも述べておくべきことがある。それは、やっぱり市場やプロダクトの特性によって違うよね、という話である。
新規リード／既存リードの割合
リードとして新規が多いか既存が多いかによっても、使い方が変わってくる。新規リードが多い場合にはマーケティングが大きな役割を果たすだろうし、既存リードが多い場合にはルートセールスのなかで広げていくことや、CSを通した売り上げ拡大の役割が大きなこともある。どの領域に力を入れるかは、文脈によって調整する必要がある。
プロダクトの特性
取り扱っているプロダクトやサービスの多様性が大きく、運用不可が高い場合は分業以前にセールスの負担を軽減させるような仕組みを入れる方が効果的かもしれない。あくまでも、現在の営業活動のなかで何がボトルネックになっているかという課題の分析が重要である。
そもそもプロダクトは優れているのか
PMFをしていないプロダクトであれば、いくらTHE MODELでプロセスの最適化を図ろうとしても成果は出ない。数値管理が重要だと思っていても、そもそもプロダクトの品質が悪いことが自明なのであれば、まずは定性調査をしてプロダクトの改善を優先すべきこともある。
分業に由来する分極化を回避する
分業をして専門性を高めて効率化するというのは、口で言うのは簡単であるが、追いかけるメトリクスにより利害が分断しコミュニケーションが希薄化することで、結局社内政治に陥ることがある。マーケティングがもたらすリードの質が悪いのか、セールスのクロージング能力が低いのかという争いはよくあるし、はたまた風呂敷を広げるだけ広げて受注したことでCSが頭を抱えることなどよくある話である。
これを回避するには、一番には「顧客の役に立つ」というビジョンを強く持ち組織に浸透させること、そしてそれに合わせて共通のメトリクスを設計するなど、利害が相反しないような設計上の仕組みを入れることが重要になる。
最後に
THE MODELは役に立つがとても奥が深いと感じている。まだ導入していないのであれば、この形を取るかは別にして、モデルとの比較をすることで見えてくることが必ずあるだろう。これから導入しようと思っている、既に導入しようと思ったがうまくいっていないのであれば、自身のおかれている「文脈」に意識的になることで、きっと改善をしていくための糸口が見えてくるのではないだろうか。
業務改革を進めるための3つの方法／3つの対象／3つの保険
何度も煩雑な作業をやらざるを得ないことにつらさを感じてしまう性分なので、普段から業務改革を率先して進めることが多い。深く考えていこうとすると考えるべきことは多いものの、ここを押さえておけばスムーズに進められると考えていることがある。その内容を3つの方法／3つの対象／3つの保険としてまとめてみる。
3つの方法
煩雑な作業を簡単にしようと思ったときに、その解決には自動化／標準化／スキル化の3つがある。
自動化
これはその言葉の通り、インプットさえしてしまえばブラックボックスの自動処理によってアウトプットが出てくるような形である。してしまって問題ないのであれば、このような形にしてしまうのが最も望ましい。処理をソフトウェアに委ねることによって、個人に由来する品質の揺れがなくなる。
標準化
次は、処理は人間で行うものの、その難易度を下げる方法としての標準化である。ある程度決まった手順やフレームワークに則ることで、誰がやっても一定の品質が担保される。個人のスキルレベルへの依存も小さい。自動化と比較すると品質に若干の差異は発生するが、逆に自動化するほど定型化されていないものを柔軟に取り込める形でもある。
スキル化
最後に、集団のスキルを全体的に向上させることによって、専門知に基づいて処理をされることで方法にばらつきがあっても品質を担保する方法である。上の2つよりも対応としては難しいが、最も応用性が高いものになる。また、自動化や標準化は手続きの合理性に対する疑問を失わせる方向に機能するので、さらにインプットやアウトプットが変わったときにも適応が可能な形でもある。
3つの対象
煩雑な作業を課題として解決しようとしたとき、その課題としてどこまでを対象にするかによって、運用で回避／ボトムアップの改善／バックキャストの改革の3つがある。
運用で回避
問題発生自体を解決しにいかずに、問題発生時の事後対応を円滑にするのが運用で回避である。基本的にはこれはなるべくやめる方がよいが、ここでとどめるか先にまで踏み込むかは、その作業が発生する頻度と発生時の対応の負荷によって考えればよいだろう。
ボトムアップの改善
次に、問題自体は解決しにいくが、その問題が解決すればいいという形のボトムアップの改善である。問題の発生自体をなくすか、問題の発生頻度を下げるか、解決の効果にはグラデーションがある。
バックキャストの改革
最後に、その問題を解決するついでに、周囲にある問題も合わせて解決するという形のバックキャストの改革である。この解き方で進めようとするには、今の運用をどう円滑にするかという視点ではなく、本来的に実現すべきアウトカムを実現するための理想像を描いて、そこと現状の差分を埋めに行く必要がある。本質的な課題設定のスキルが求められるので、やや難易度は高いが、当然効果は大きくなる。
3つの保険
方法と対象と合わせて考えないといけないのが、業務改革によって短期／中長期に新たな問題が発生しないかということである。そこで、保険としてスコープ調整／高度化の抑制／人材育成の3つに注意する必要がある。
スコープ調整
どこまでをスコープにすべきかは結構悩ましい話だが、指標としてはROIが重要な観点である。問題自体の発生頻度と影響を起点にして、解決の際の効果の程度、それから運用設計および運用変更をする際のコストを考えることになる。3つの対象をいずれを取るかはここが基準になるので、意図的に運用で回避でとどめるべきときもあれば、頑張って改革をしにいくべきときもある。
高度化の抑制
運用としてはある程度整理できたとしても、その実行をするのが難しかったり、運用変更をするのが難しかったりすることがある。まず、その部門に採用や異動で新規参入者が生じたときに、それでも運用を回せるかは大事な観点である。また、運用設計者が頑張って設計をしても、その人が異動や退職でいなくなったときに運用変更ができないリスクもある。RPAが普及してきたときに「野良ロボット」が話題になっていたが、仮に運用設計者にはできるとしても、そのレベルまで高度化させないことは案外重要である。
人材育成
上記では人員の流動に伴ってリスクが発生するという話であったので、逆に言うとみんなができる状態であればリスクにはならない。ということで設計能力を育成するような形を取るか、あるいは人員配置の際に最低限の知識／スキルのスクリーニングを行うことが予防策になり得る。また、もし育成をベースにするのであれば、スキルアップは一朝一夕で進むわけではないので、ある程度中長期で考えないといけないのも意識しておくとよい。
最後に
ここまで、どう解くか、どこまで解くか、何に気を付けるべきかについて簡単にまとめてきた。個別の業務改革の際はこれらを考えればよいが、一方でどこまで解くかに関するリソース配分を適切にしておくことも大事に思う。なぜなら、業務が大量であると、余裕がないので運用で回避を選択し、運用で回避が蓄積するので業務がさらに増えるというループに陥りかねないからである。
日常の業務のなかで、どこまでの時間を改革に割けているかを意識し、状況に応じてやめる業務を探すのか、業務の配分を変えるのか、あるいは人員を増強するのかも含む、全体のマネジメント機能の良し悪しが業務改革の成果を決めるのだろう。
チャットを正しく使いこなすための基本・応用・土台
組織のDXを進めるなかで、ビジネスチャットの導入は初歩的な取り組みとして多く取り上げられる。しかし、単純に導入しただけではその価値をうまく引き出せないことがある。そしてうまく機能していないにしても、惰性で続いている情報量のない挨拶をなくす口実を作ることで*1、多少の業務効率化にはつながってしまい、明確に大失敗にもならないのでたちが悪い。
チャットの活用事例として高度な個別のプラクティスは多くある。ただ、チャットが上手く機能しない背景には、そういった個別の取り組み以前に導入時に前提の考え方を伝えていないことが問題の原因なのではないか。ということでその点について考えてみることにする。
①基本：帰属の設計
チャットの基本は、帰属の設計である。メールとチャットではこの点は大きく異なり、勘違いするとメールの使い方を引きずってしまう。
コミュニケーションの帰属
メールはメールボックスを起点に設計されている。メールアカウントは個人に付与するものなので、メールが蓄積されるのは個人になる。念のため共有しておきたければ、CCに入れて該当者のメールボックスに格納をさせる。これがとりあえず連絡されるマネージャーのメールボックスが爆発する要因である。
一方、チャットは場に蓄積される。グループ、チャネル、スレッドを適切に配置することで、場に連絡を残すことができる*2。場に投げられたチャットをどう通知するかは、送付側のメンション／受信側の通知設定により調整することができる。つまり、投稿されたコミュニケーションを通知するかをソフトウェアで統制することができる。
ここを理解して上手く使うことができれば、組織内の情報の透明化／事後的な情報の検索性の向上／異動・離職に伴う情報損失の回避に寄与することができる。一方、失敗するとDMが蔓延し、情報が閉鎖されメールと大して変わらないものになる。
ドキュメントの帰属
次に、クラウドで同期させることが基本にあると、ドキュメント管理の方法が変わってくる。（かつての）メールではメールを送るごとにファイルが複製されるので、日付や「_v1」による、ファイル名ベースのバージョン管理がなされていた。
一方、クラウドでのファイル管理が当たり前になると、同一ファイルに対してアプリケーションの機能としてバージョン管理するようになる。同一ファイルを同期／非同期で自由に編集できるようになる。共有フォルダでフォルダ構造で整理をするやり方から、検索やリンクによってファイルにアクセスするあり方や権限の調整も利用することができるようになる。このとき、コミュニケーションの帰属と合わせて、グループで活用する場にファイルを帰属させることができる。
ただ、チャットツールとオンプレの共有フォルダが並立していたり、フロー情報とストック情報をいかに使い分けるか、ストック情報をいかに更新していくか、適切なアクセス管理を行えるのかに取り組むのは結構難しいことでもある。あまりよくわかっていないと、ファイルが乱立しときには退職と共に消失したりして、ドキュメントが闇に包まれてしまうことがある*3。
②応用：エコシステムの設計
コミュニケーションやドキュメントだけでなく、サービス間をつなぐインターフェースとなれるのもチャットの優れたところである。直接的に関係のない他部門の動向を追うことができたり、何らかの行動が行われたことをトリガーとして通知をすることができたりする。さらには、外部サービスとAPI連携することによって、チャットを打つことで画面を切り替えることなくそのサービスを活用することができる。
これは少し技術がわかっていればそれほど難しいことではないのだが、データのエコシステムをつくる意識が必要だったり、そもそも連携できるサービスを実験的に導入する意思決定ができるかがボトルネックだったりして、デジタルリテラシーの低い組織では意外と難しいことでもある。
③土台：組織文化／基礎スキル
①であれ②であれ、それ以前に組織レベルで土台がないと、あらゆる運用が絶望的に上手くできない。チャットの活用には下記のようなことも重要である。
性善説or性悪説の組織文化
制度設計には、性善説（人間は本質的に善だと捉えて自由を与える）／性悪説（人間は本質的に悪だと捉えて制約を与える）の2つの考え方がある。チャットは情報を公開することに価値があるので、あれもこれも規制して悪いことをさせる余地をなくす性悪説の考え方の下ではポテンシャルを生かし切ることはできない。
マネジメントスタイル
合理性よりも権力関係の方が重視され、情報の非対称性を濫用した組織政治が横行する組織ではチャットは上手く使えない。そういった組織では、DMの割合が高くなったり、肝心なことは電話で連絡することで重要な情報が場に残らないようになる。
ドキュメント活用のスキル
情報を効果的に蓄積して活用するには、文字で情報整理する習慣、文字で要点をまとめる思考力、文字から情報を読み取る読解力が求められる。何をフロー情報にして、何をストック情報で整理し直すかも含めて、ドキュメントを上手く活用できないと情報が爆発して結局流れていくだけになりかねない。
最後に
チャットを効果的に使うには、それまで使っていたツールに対してどういう考え方の変更を行わないといけないのか、それを実現するための土台には何が必要なのかを理解することが重要である。そして、導入時にきちんと運用の思想を伝え、場合によっては活用の効果を最大化するためのトレーニングも必要かもしれない。たかがチャットにそこまでやる？という印象を持つ人もいるかもしれないが、日常の情報流通が効果的に行えない組織が、生産性高く事業成果を上げられるはずはないのである。
マーケティング推進のための7つの重要な観点
以前の記事（マーケティングをわかりにくくしているのは何か）で、マーケティングがわかりづらいのは、同じ言葉でも大別して下記3種類の意味合いがあり、話者によって言葉の意味が違っているからという整理をした。
今回は、前回のうち①の内容を念頭に置きつつ、②や③を効果的に実践していくにあたっても、マーケティングを推進していくための重要な観点を7つに整理してみた。
この整理の意義は何か
マーケティングとして語られるものが用語の多義性や実践の多様性もあり膨大にあるなか、仮に個々の情報発信の位置づけや内容を理解できたとしても、ではどのように自身の事業に還元できるのかを考えるのは非常に難しい。なぜなら、個別施策が成果を上げるかどうかは、組織内での意思決定プロセスや、市場や商材の特性によって異なるからである。
そこで、個別の議論や事例を目の当たりにしたときに、自身の事業と接続するために立ち返る観点があると、収集した情報をいかに使っていくことができうるかを検討する手助けになると考えている。
マーケティング推進のための7つの重要な観点
マーケティング推進のためには、下記の7つが重要なものだと考える。
- ①顧客の体験への固執
- ②顧客の特性の理解
- ③顧客の課題の理解
- ④課題に対する解決策の適合性
- ⑤商材に由来する購買プロセス、商流の特徴理解
- ⑥購買意欲／購買能力の担保
- ⑦実現する組織構造、部門間連携、基本概念や専門知のマネジメント
以下、これらについて簡単に取り上げる。
①顧客の体験への固執
第一に重要なのは、顧客の体験を考えるのにとにかくこだわることである。なんとなくそれっぽくまとまっているけれど、実際に顧客のニーズにささらない商材など無数にある。この要因として、検証を欠くことで売り手の妄想に過ぎない企画が立案され、実際に上手くいかなかったら営業や販促プロセスのせいにするような姿勢がある。顧客は売り手の事情などほとんど考慮してくれない。
この話に関連して、プロダクトアウト／マーケットインという整理があるが、これらは事業立ち上げの段階ではどちらでもいいのではないかと思っている。プロダクトアウトから始まった事業でも、創業者の信念が込められたいい事業になったものは多くあって、それらが上手くいっているのはマーケットのニーズに対するセンスだけではなく、きちんと検証を回して事業拡大の際にマーケットニーズを的確につかむよう学習を回せていたからではないかと推測している。
また、SDGsなどの流行もあり、社会的意義を踏まえたブランドも多く立ち上がってきているが、こういったものでも実際のプロダクトが低品質だと意識の高い人が中心の小さなマーケットでとどまってしまう。市場を広げていこうとすると、社会的意義の背景がなくともプロダクトの品質がよく、「買ったら結果的に社会的意義も高いものだった」という形でないと難しいのではないか。
②顧客の特性の理解
次は、顧客の特性を理解することである。これはプロダクトの購買以前の前提として把握が求められる。例えば、Netflix／Prime Videoは動画視聴サービスという観点では直接の競合だが、限られた顧客の可処分時間を取り合うという意味では、TwitterやLINEとも競合している。目的消費で特定のドメイン内の競合のみを考えればいいものと、ドメイン外を例えば娯楽というもう少し広い水準や、可処分時間というさらに広い水準まで広げて考える方がよいものがある。
また、実際に顧客にプロダクトを認知させ購買までさせていく際に、どういう方法がよいかを考える素材にもなる。普段利用しているメディアが何なのか、そのメディアをどう使っているかによって、広告面としての有効性や実施する施策の方式が変わってくる。
③顧客の課題の理解
ある程度顧客のおかれている文脈を踏まえた上で、では顧客はどのような課題を抱えているのかというのが次に重要なことである。このとき、toBとtoCでは若干考え方が変わってくる。
顧客への提供価値を考える際に、ペイン（負の体験）の除去とゲイン（正の体験）の付与という整理がある。例えば、書類をいちいち郵送するのが手間でつらいのが電子申請で簡単に済むようにするのはペインの除去だし、映画を見て感動するのはゲインの付与である。
toBでは何らかのプロダクトを購入するのは、事業上の目標の達成に寄与すると考えられるからなので、事業上上手くいっていない課題（ペイン）を解決できるからというのが基本になる。一方、toCでは購買行動をするのは必ずしも目的合理的ではなく、楽しそうだから／好きだからという快楽目的であることもある。
対応しようとしている課題が、ペイン／ゲインのいずれなのか、またそれらが顧客にとってどれほど重要なことなのかを認識しておく必要がある。そうでないと、できたらいいかもしれないが高いお金を払うほどでもないとして事業にならないことがある。
④課題に対する解決策の適合性
顧客の課題を理解したら、そこに対しての解決策を設計していく。このとき、課題をどの程度解決できるのかというのと、不随して発生するデメリットはないか、関連してまとめて解決できるものがないかというのが考えるべきポイントになる。
例えば、用紙をもらって手で記入していた書類が、電子で記入して印刷して郵送提出する形になった場合、用紙をもらう手間の削減と記入の利便性は上がるが郵送の手間は解決していない。またこの場合だと、印刷するための環境が新たに必要になる。
一方、起案→申請→承認→事後処理というのをワークフローの形として抽象化すると、電子申請のシステムを導入することで他の申請業務もまとめて効率化し、申請記録を蓄積することまで合わせて実現できるかもしれない。
⑤商材に由来する購買プロセス、商流の特徴理解
この点はtoBとtoCに分けて考えるとわかりやすい。概して、 - toB：高単価で事業目標の実現のために購買されるため、目的適合性と集団的意思決定がなされ、営業担当の顧客組織内の意思決定支援も有効 - toC：低単価で自身の快楽のために購買されることが多く、衝動買いも頻繁に行われる、反復購買も多い
のように大別される。もちろん、例えば不動産や結婚式などはtoCのなかでも高単価、平均購買回数が低く、集団的意思決定がなされるという点でややtoB商材に近いものがあり、だからこそコンシェルジュの存在に価値が生まれてくる。
また、商流という点では製造～顧客の手元に渡るまでの流れを考えればよい。例えば、飲料では小売店に卸す、自動販売機で提供するなどというような方法がある。小売店では製造会社の意図通りに棚を作ってもらえるとは必ずしもいえないなか、いかに目立つ場所に取り上げてもらうよう小売店に働きかけたり、競合がひしめく売り場のなかで目立たせるかというのが課題になる。
⑥購買意欲／購買能力の担保
ここまでの内容を踏まえた上で、顧客が購買の意思決定をするには、購買意欲と購買能力の両側面を満たすことが必要になる。購買意欲としては、解決策にインパクトが十分であること、競合他社と比較したときに相対的優位性を持っていること、そのプロダクト／事業者に対するイメージなどがある。これを適切なチャネルで適切な表現で的確に伝達することが求められる。購買能力としては、顧客が購買可能な場を提供していることと、販売価格が顧客にとって妥当性を持っていることなどがある。そのために、小売／自動販売機／EC／販売代理／直販／フランチャイズなど購買の場の拡大と、価格戦略が必要になる。
ちなみに、競合他社に対する相対的優位性は、必ずしもそのプロダクトの有効性が優れているか否かではない。プロダクト／事業者のブランドが強いと比較なしで指名購買されることはあるし、単体ではそうでなくとも一連のパッケージとして利便性が高いからや、いつもよくお世話になっているあそこのプロダクトなのでということもある。
⑦実現する組織構造、部門間連携、基本概念や専門知のマネジメント
そして最後に、これまでの内容を担保するような運用面の設計がある。何が最適なあり方かというのは市場や商材特性によって変わってくるが、顧客体験を正しく捉え、それを商品企画～販売～提供までつなげていくために、組織内での権限配分や情報流通の最適化、共通認識の浸透を行い、全体最適の取り組みを進めていく必要がある。
最後に
マーケティングの重要課題は時代によって大きく変わってきた。供給＜需要の時代は認知の最大化が重要課題であり、需要＜供給の時代は認知の統制が重要課題であった。そして、行動データが膨大に幅広くとれるようになった今は、顧客の購買プロセスに合わせた全体最適化が取り組むべき課題になっている。これは、当然解決するのが難しいものである。しかし、かつてはデータ取得が限定的であったため、多くの人には検討すらも難しかったことでもある。 今こそ、いかに顧客の役に立つかという事業の原点に立ち返って、取り組みを劇的に変えられうるのではないか。それは、大変なことではあるが、取り組みがいのある面白いこととも思える。
なるべく短い正規表現で住所を「都道府県/市区町村/それ以降」に分けるエクストリームスポーツ（Pythonで挑戦）
住所データを整形する用事があったので、調べてみたらなるべく短い正規表現で住所を「都道府県/市区町村/それ以降」に分けるエクストリームスポーツという広く参照されている記事があるようだった。もちろんそのコードをまるっといただくのが早いが、正規表現に触れたことがなかったので、いい勉強になると思いPythonで挑戦してみた。
１．テストデータの準備
郵便局のHPから、かの有名（悪名高い）なKEN_ALL.csvをダウンロードしてくればよい。「かの有名」というのはググってみると色々出てくる*1。
今回はKEN_ALLの仕様は関係ないので、Pythonで読み込んで都道府県/市区町村/それ以降を結合し、これを再び分割することで適切に処理できているかの答え合わせをする。
import csv, re
with open('KEN_ALL.csv', encoding='sjis') as f:
reader = csv.reader(f)
data = [row for row in reader]
address_list = []
for i in range(len(data)):
address_list += [[data[i][6] + data[i][7] + data[i][8], data[i][6], data[i][7], data[i][8]]]
２．まずは都道府県
都道府県については簡単である。reモジュールの使い方は[Python]正規表現のみで住所を「都道府県/市区町村/その他」に分割する方法を参考にした。正規表現は今回の挑戦を通して基本的な正規表現一覧を死ぬほど見返した。
pattern = '''(...??[都道府県])'''
match_count = 0
for i in range(len(data)):
result = re.match(pattern, address_list[i][0])
if result.group(1) == address_list[i][1]:
match_count += 1
else:
print(address_list[i][1], result.group(1))
print('データ数=', len(data),'マッチ数=', match_count, 'アンマッチ数=', len(data)-match_count, 'マッチ率=', match_count/len(data))
結果：データ数= 124556 マッチ数= 124556 アンマッチ数= 0 マッチ率= 1.0
結果は100％で問題なし。注意点は少し書き方を間違えると京「都」府が「京都」でマッチングするくらい。
３．次は市区町村
同様に市区町村で実験してみる。
単純
まずは普通に市区町村。
pattern = '''(...??[都道府県])(.+?[市区町村])'''
match_count = 0
for i in range(len(data)):
result = re.match(pattern, address_list[i][0])
if result.group(2) == address_list[i][2]:
match_count += 1
else:
if i % 50 == 0:
print(address_list[i][1], address_list[i][2], result.group(2))
print('データ数=', len(data),'マッチ数=', match_count, 'アンマッチ数=', len(data)-match_count, 'マッチ率=', match_count/len(data))
結果：データ数= 124556 マッチ数= 106216 アンマッチ数= 18340 マッチ率= 0.8527569928385625
結構マッチングできないものがある。なおアンマッチのものの一部を抽出しているのは、基本的に隣合ったデータは市区町村以下が微妙に違うだけなので、確認の際に見やすくするため。
～市～区
次はアンマッチのサンプルから～市～区（札幌市中央区など）となっているものが多く見受けられたので、その分を処理する（pattern以外は同じなので略）。
pattern = '''(...??[都道府県])(.+?市.+?区|.+?[市区町村])'''
結果：データ数= 124556 マッチ数= 122151 アンマッチ数= 2405 マッチ率= 0.9806914159093099
マッチ数が急速に上昇した。どうやら政令指定都市のデータが多く拾えたことが理由らしい。考えてみると人口が多いので郵便番号も多いからか。
～郡～町・村／～区／～市
～郡～町・村（西村山郡河北町など）が多く見られたのでその点と、新宿区市谷が新宿区市になるのでその点と、～市は先に拾わないと～村～市（武蔵村山市など）を拾えないので優先対応。
pattern = '''(...??[都道府県])(.+?郡.+?[町村]|.+?市.+?区|.+?[区]|.+?[市]|.+?[町村])'''
データ数= 124556 マッチ数= 123006 アンマッチ数= 1550 マッチ率= 0.9875557981951893
郡が混在するところ（大和郡山市など）と、政令指定都市ではないけれども～区が存在する市（旭川市４区など）でうまく抽出できていないものが残っていた。
～市～区を再考する
ざっくりいけるここからさらに減らしていこうとしたときに、ほかの人の方法では対象市区町村を個別に例外処理することが多いようだった。ただ、そのやり方だと例外に上げている基準がいまいちわかりづらい。
そもそも～市～区をどう処理するかの基準は、政令指定都市は区まで拾い、それ以外は市まで拾うということなので、今後も変化があまりないであろう政令指定都市をベースにした方が理解しやすいのではということで試してみる。
pattern = '''(...??[都道府県])((?:札幌|仙台|さいたま|千葉|横浜|川崎|相模原|新潟|静岡|浜松|名古屋|京都|大阪|堺|神戸|岡山|広島|北九州|福岡|熊本)市.+?区|.+?郡.+?[町村]|.+?[市]|.+?[区町村])'''
データ数= 124556 マッチ数= 123836 アンマッチ数= 720 マッチ率= 0.9942194675487331
ビンゴ。結構減った。あとは細かい例外処理*2。
市区町村が混ざるものをやっつける
鈴鹿市郡山町／長浜市小谷郡上町／長浜市小谷郡上町／高槻市郡家新町など、市で切れればいいものを拾うために、市が入っていないといけないものだけ例外処理する。また、玉村は佐波郡玉村町という村と町が混在したもの。そして市の前に市が入る野々市市／四日市市／廿日市市を抽出する。
pattern = '''(...??[都道府県])((?:札幌|仙台|さいたま|千葉|横浜|川崎|相模原|新潟|静岡|浜松|名古屋|京都|大阪|堺|神戸|岡山|広島|北九州|福岡|熊本)市.+?区|(?:余市|高市|[^市]+?)郡(?:玉村|.+?)[町村]|[^市]+?[区]|(?:野々市|四日市|廿日市|.+?)[市]|.+?[町村])'''
データ数= 124556 マッチ数= 124397 アンマッチ数= 159 マッチ率= 0.9987234657503452
残りもあと一息になる。
郡が混ざるものをやっつける
これで残りは蒲郡市／大和郡山市／杵島郡大町町の郡が混在する3つになる。大町町とはややこしい・・・
pattern = '''(...??[都道府県])((?:札幌|仙台|さいたま|千葉|横浜|川崎|相模原|新潟|静岡|浜松|名古屋|京都|大阪|堺|神戸|岡山|広島|北九州|福岡|熊本)市.+?区|(?:蒲郡|大和郡山)市|(?:余市|高市|杵島|[^市]+?)郡(?:玉村|大町|.+?)[町村]|[^市]+?[区]|(?:野々市|四日市|廿日市|.+?)[市]|.+?[町村])(.+)'''
データ数= 124556 マッチ数= 124556 アンマッチ数= 0 マッチ率= 1.0
マッチ率100％で完了！
３．挑戦の成果
文字数
先人の成果
(...??[都道府県])((?:旭川|伊達|石狩|盛岡|奥州|田村|南相馬|那須塩原|東村山|武蔵村山|羽村|十日町|上越|富山|野々市|大町|蒲郡|四日市|姫路|大和郡山|廿日市|下松|岩国|田川|大村)市|.+?郡(?:玉村|大町|.+?)[町村]|.+?市.+?区|.+?[市区町村])(.+)
151文字
挑戦の成果
(...??[都道府県])((?:札幌|仙台|さいたま|千葉|横浜|川崎|相模原|新潟|静岡|浜松|名古屋|京都|大阪|堺|神戸|岡山|広島|北九州|福岡|熊本)市.+?区|(?:蒲郡|大和郡山)市|(?:余市|高市|杵島|[^市]+?)郡(?:玉村|大町|.+?)[町村]|[^市]+?[区]|(?:野々市|四日市|廿日市|.+?)[市]|.+?[町村])(.+)
183文字
・・・全然だめやん（笑）
再挑戦の成果（最後のあがき）
よく考えたら市での例外処理が減ったので、余市や高市をいじらなくてよくなった。
(...??[都道府県])((?:札幌|仙台|さいたま|千葉|横浜|川崎|相模原|新潟|静岡|浜松|名古屋|京都|大阪|堺|神戸|岡山|広島|北九州|福岡|熊本)市.+?区|(?:蒲郡|大和郡山)市|.+?郡(?:玉村|大町|.+?)[町村]|[^市]+?[区]|(?:野々市|四日市|廿日市|.+?)[市]|.+?[町村])(.+)
167文字
・・・結局だめやん（笑）
読みやすさ
文字数では全然だめだが、設計の意図は読み取りやすいようになっていると思う。ただ、結局政令指定都市とそれ以外で例外処理を2種類やっているのが長さの要因で、読みやすさと長さはトレードオフになっているということで・・・
４．最後に
そもそも本編のエクストリームはここから先の話なので、私はエクストリームに至るまでに力尽きました。
*1:私も過去に使えないか試してみたが、複数行に分かれているとか以下に掲載がない場合とか飛び地があるとか、尋常じゃなく深い闇だったので諦めたことがある。
*2:なお、?:は括弧内を切り分けるかを決めるもの。入れないものを試してみると意味がわかる。 参考：後方参照が不要なグループ化「(?: )」
マーケティングをわかりにくくしているのは何か
マーケティングを学びはじめたときに、様々な人が全然違うように思われるようなことを言っていて、結局マーケティングとは何なのかがよくわからなくなっていた。ある程度を理解してから気づいたのは、「マーケティング」の意味が人によって違うのが、マーケティングをわかりにくくしている要因だということだ。 そこで、今回はこの点を簡単に解きほぐしてみる。マーケティングを学びはじめる人はぜひ押さえておくとよいだろう。
「マーケティング」の意味は、3種類ある
マーケティングが意味することは、3種類ある。ここを押さえておかないと、前提の認識が合わないことで情報収集においても業務上のコミュニケーションにおいても非効率が生じるてしまう。 この3種類とは、
である。それぞれによって視点や示す領域の範囲が異なるので、その点が意識できるとよい。
① 全体最適としてのマーケティング
これはいわゆる「売れるしくみをつくること」を意味する。プロダクトが顧客に購買されるためには、
- ユーザーの特性を理解する
- ユーザーの課題を特定する
- ユーザーの課題に対して適切な解決策を設計する
- プロダクトの価値をユーザーに適切に届ける
- プロダクトのビジネスモデルを設計する
- これらのオペレーションを着実に遂行する組織を構築する
ことが必要になる。単に販促キャンペーンをすればいい、単に営業を強化すればいいという小さな話ではない。
ROI高く事業を改善していこうとすると、全体を俯瞰したうえでボトルネックがどこにあるのかを考えるのがとても重要である。そしてそれを考えるためのものとして、特定の部門や機能に限定されない全体最適としてのマーケティングがある。
著名なマーケターの森岡毅さんが『マーケティングとは「組織革命」である。』という本を出しているもの、おそらくこういうことなのだろう。（引き合いに出しておきながらこの本はまだ未読ですが…ただ『確率思考の戦略論：USJでも実証された数学マーケティングの力』は名著でした。）
ちなみに、全体最適を念頭においているので、要因を分割した個別論も論点に入ってくる。個別論で見ると、例えばコトラーの考え方とバイロン・シャープの考え方では異なる、みたいな見解の相違が出てくる。
ただそこまで理解しようとすると初学者は困惑してしまうので、はじめはこういった個別の相違まで受け取りすぎず、とにかく全体最適としてどう考えるかを意識できるとよいだろう。
② 販促施策としてのマーケティング
全体最適をの理想像を考えることができるにしても、実務上それを組織横断的に実現するのは難しいことでもある。なぜなら、部門が分割されていることによる限定された情報の非対称性に対応し、普段追いかける普段追いかける指標や実績評価の観点も異なる他部門を巻き込みながら、自身に配分されている権限を越えて取り組みを進めていく必要があるからである。
そこで、全体最適ではなく部分最適のレベルのものとして、販促施策としてのマーケティングがある。
例えば、
など。これは単なる販促施策にすぎないのに「マーケティング」とつけるのがややこしい要因なので、素直に「プロモーション」と呼べばいい。
③ THE MODELの一機能としてのマーケティング
①②とは若干毛色の違うものとして、THE MODELにおけるマーケティングがある。THE MODELとはSalesforceの事例に基づいて定式化された営業プロセスモデルの名称であり、マーケティング→インサイドセールス→フィールドセールス→成約→カスタマーサクセスと顧客の購買プロセスに合わせて営業・販売活動を分業化していくというものである。
このとき、マーケティングはリードジェネレーションおよびリードナーチャリングを行い、インサイドセールスに渡すまでの機能を担うことになる。簡単に言うと、顧客がプロダクトを認知するところから購買意欲が高まり商談化できる前までを担当する*1。
ある程度②と重複するところはありつつ、リードナーチャリング／購買意欲の醸成までが視野に入ることで、CRM／MAなどについても重要な論点となってくる。そして、何よりこの話をする際には、THE MODELの営業プロセスモデルの存在が前提になっている。
ちなみにTHE MODELはSalesforceをベースにしている以上、米国の商習慣や高単価のBtoBプロダクトであることが隠れた前提になっており、本当はこれをどう日本の商習慣／業界／商材に合わせてカスタマイズするかが重要になるが、その点はまたどこか別で書くかもしれない。
まとめ：「マーケティング」の意味を意識しよう
マーケティングがわかりづらいのは、話者によって「マーケティング」の意味が異なっているからである。このままでは情報収集もコミュニケーションも円滑に行えない。
そこで、個々の場面においてどういう意味かを考えるように注意することと、場合によっては使う言葉をより明確な意味になる別の言葉に言い換えると、もう少しマーケティングが学びやすくなるだろう。
はてなブログの魔改造
最近、Webマーケティングにかかわる比重が高くなったので、基本知識としてGoogle Analyticsの機能は理解しておかないとなーと思っている。 ただなかなか実務で触る機会がないので、それなら自分で遊んでしまえということでブログを始めることにした。
投稿がいつまで続くか大変怪しいけれど（笑）、ひとまず作成するにあたっていろいろと設定を行ったので、備忘録として書いておく。 まだ計測が機能していないので、詳細はまたあとで確認することにする。はるか昔に使っていたMarkdown記法の復習もついでの気持ちで。
１．計測系
Google Analytics
- Google Analyticsの設定→Google Tag Managerの設定とすすめていったが、そもそもどの順番が正解なのかはよくわからない*1
- 参考：Googleタグマネージャーの使い方
- 生成されるタグは2種類あり、貼り付け位置も指定される*2が、はてなブログではタグのIDだけ入れればよい*3
下のコードをコピーして、ウェブサイトのすべてのページに貼り付けてください。
このコードは、次のようにページの <head> 内のなるべく上のほうに貼り付けてください。
<!-- Google Tag Manager -->
<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','[タグのID]');</script>
<!-- End Google Tag Manager -->
また、開始タグ <body> の直後にこのコードを次のように貼り付けてください。
<!-- Google Tag Manager (noscript) -->
<noscript><iframe src="https://www.googletagmanager.com/ns.html?id=タグのID"
height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript>
<!-- End Google Tag Manager (noscript) -->
- HTMLを確認してみると、1つ目のタグしか反映されていないが、調べてみると後者のタグはJavaScriptが正常に動作しないときのためのようで、今どきそんなのはほとんどないので問題ないということなのだろうか・・・
- 参考：Googleタグマネージャのスニペットタグが更新されました
- そのほか、はてなブログではいくつかカスタムディメンションを設定するとより使えるらしい（未検証なので詳しくはまだわからない）
- 参考：はてなブログで Google アナリティクス 4の設定が可能になりました
Google Search Console
- こちらはほぼ瞬殺だった
- 参考：はてなブログにグーグルサーチコンソールを導入する方法
- ひとつ注意点としては、前述の通りはてなブログではGA（GTM）はタグのIDだけで設定する形になっていて、noscriptのタグは埋め込まれないようなので、Search Console用のタグでサイトの所有権の確認をする必要がある
２．表示系
Twitterタイムライン埋め込み
- Twitter Publishで埋め込みタイムラインのコードを生成
- デザイン＞カスタマイズ＞サイドバー＞モジュールを追加＞HTMLで埋め込む
- デフォルトだと長すぎてしまうので、
data-tweet-limit="7"などでツイート数を制限するとよい - コードはこんな感じ
<a class="twitter-timeline" href="https://twitter.com/[TwitterのID]?ref_src=twsrc%5Etfw" data-tweet-limit="7">Tweets by [TwitterのID]</a> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
３．泥沼（沼）
- いろいろめんどくさいのですべて無料で済ませようとしたところ、Notion／STUDIO／WixはGAを埋め込めないので除外、Jimdoはなんとなく気が進まないのでやめて、WordPressかはてなブログで考えることに
- どちらも昔使っていたことがあるのでなじみがあり、WordPressにでもしようかと思ったら、今はローコード編集の仕様になっているので、タグの埋め込みがうまくできず
- 結局はてなブログに落ち着くのだが、計測系の対応が楽でとてもよかった
- Twitter埋め込みがぜんぜんうまくいかずに泣きそうになっていたところ、原因はFirefoxがはじいていたことのようで、Safariなら表示されるというオチであった・・・
- GAの反映がやたら遅いなと思っていたら、これもFirefox／Safariでトラッカーをブロックしているというオチであった・・・
- 自分で自分をブロックしないように注意しましょう（苦笑）
魔改造とかタイトルにつけておきながら大したことをしていないですが、私が触っていたころのはてなブログは計測などあまりない牧歌的な時代だったのです。
