Biz | Think and Write

事業を成長に導くアナリティクスチームとは？

本記事はウェブメディア「Modern Times」へ2023~2024年に寄稿したものを同メディアの閉鎖に伴い加筆・修正のうえ再掲したものです。様々な企業でデータアナリティクスチームが新しく設立されています。データを活用して大きく成長する企業があれば成果が出せずにチームを解散させる企業もあります。両者の違いはなんでしょうか。その答えの1つは組織の関係性です。本記事では事業を成長へ導くためにデータアナリティクスチームを社内で信頼できるパートナーに育てるべきだという話を紹介します。失敗するデータアナリティクス部門データの活用が大きく注目されてから数年が経ち、多くの企業で社内外のデータを分析し自分たちのビジネスに活かすため新たにデータアナリティクスチームが創設されてきました。分析者の採用は活発化し関連する設備への投資は盛り上がりました。一方で、チームを作り人材も設備も用意されたというのに成果が挙げられずデータアナリティクスチームの閉鎖や縮小、企業内での立場が弱くなるという結果になっています。なぜ、このようなことになってしまったのでしょうか。データの活用に実は価値がなかったのでしょうか？いいえ、そんなことはないはずです。実際にいくつかの企業ではデータを活用し大きな成長を遂げています。では、成功した企業と失敗した企業では何が違ったのでしょうか。この質問に対する答えは無数にあります。すでに多くの例がインターネットや書籍に書かれています。良い人材を採用できなかった、解くべき課題が立てられなかった、現場が協力を拒んだ…など様々です。この記事で紹介するデータアナリティクスチームを成功させる秘訣は事業部とのパートナーシップを強化し並走することです。事業部からの依頼をこなすだけの下請け組織からの脱却であり、共に事業を成長させるための頼れる専門家集団への進化です。下請け化がもたらす弊害まずはデータアナリティクスチームの下請け化という現象について解説します。多くの企業では事業部がビジネスを営んでおり支援組織としてあとからデータアナリティクスチームを設立することが多いです。そのため、組織内の力関係として事業部本体のほうが強くデータアナリティクスチームが弱い立場になりやすいです。データアナリティクスチームの立ち上がりの初期は事業部に対するドメイン知識が不足しています。一方で事業部側にはデータアナリティクスの知見が不足しているでしょう。そのためデータアナリティクスチームが事業部が知りたいことをヒアリングして具体的な分析方法はチームに一任されるという依頼ベースの仕事の進め方になっていきます。このようにして事業部が主導権を持っている状態が常態化すると次第にデータアナリティクスチームは事業部の下請け組織となっていきます。事業部に言われるがままにデータ集計や分析を行うだけの状態です。この状態が長く続くといつまで経っても事業部とデータアナリティクスチームの間にシナジーが生まれず生産性は上がらないどころかむしろ下がっていきます。なぜ下請け状態になると生産性が下がってしまいやすいのでしょうか。ビジネスでデータを活かすには事業部とデータアナリティクスチームの双方が成長していくことが重要だからです。分析結果を行動に移し行動した結果を分析するというサイクルから学ぶ必要があります。その中でデータの知見がない事業部と事業の知見がないデータアナリティクスチームの間でコミュニケーションが難しくなることは大きな問題になるのです。依頼者と下請けという関係性では前提知識や価値観、優先度の違いから課題感の共有が難しく、お互いの立場の強さや信頼関係から積極的な意見や提案、その実行の柔軟さや迅速性に欠けることになります。本来、意思決定者と分析者は対等な立場であり顧客への還元という共通の目的をもっているはずですが、次第に意思決定者が顧客のように振る舞いはじめます。外部ベンダーを通したITシステムの開発が難しいように、このような状態では柔軟かつ迅速なデータ活用は簡単ではありません。それでは、どのようにしてこの問題を解決していけばよいのでしょうか？私の考える解決方法は事業部とデータアナリティクスチームがパートナーとして並走することです。事業部とデータアナリティクスチームが普段から課題感を共有し同じ方向を向いて課題解決に取り組んでいる状態です。分析とアクションのサイクルを通して成長していくためにはアクションを起こしやすい分析を行い、分析のしやすいアクションを計画していく必要があります。このためにはお互い密な連携が必須です。依頼者と下請けという立場では実現が難しいですが、お互いに並走することで強力なシナジーを生み出すことが可能です。パートナーとして並走する事業部にデータアナリティクスチームがパートナーとして並走することで上手くいくと述べましたが、実際の問題として「明日からパートナーとしてやっていきましょう」と同じ会議室に詰め込んだところで簡単に成し遂げられるわけではありません。最初はお互いに関係性もなくナレッジの共有もできていませんから、挑戦と実績を積み重ねる必要があります。重要なことは小さく挑戦し失敗と成功を積み重ねることです。事業部はデータアナリティクスチームと共にやっていくことにメリットを得られるのか不安を抱えています。データ活用に知見がないのでそこに腹落ちするビジョンを描けていません。一方でデータアナリティクスチームは新しく作られたチームですので早く成果を生み出して信頼を勝ち取る必要があります。このような状況で両チームに必要なのは小さくてもよいので実際に手を動かして実績を積み上げていくことです。良い結果が望ましいですが失敗しても構いません。もちろん、挑戦しただけでは意味がありません。その結果を受けて振り返りを行い改善サイクルを回していきます。分析結果を生かしてアクションを起こす、アクションを起こした結果を分析する。このサイクルを回して効率よく効果的なデータアナリティクスの活用を見出します。これは単純に良い結果を出すという意味ではありません。良いやり方を見つけるということです。人材の配置やデータ連携など設備はもちろん、見るべき指標の精査やデータの処理方法、タスクの決め方や管理方法など、データを活用するということは今まで仕事の進め方を変えるということですので考えなければいけないことは多岐にわたります。このようにして深いパートナーシップを結び成果を生み出せるようになるためには経営層からの強いバックアップが必要不可欠です。事業部とデータアナリティクスチームの双方に方向性を示し軌道修正していくということです。事業の成長のためにそしてユーザのために長期的に改革していくのだということを説明しそのように実行できるよう協力することが経営層の仕事です。事業部とデータアナリティクスチームに丸投げしてはうまくいきません。データ活用の成功も失敗も最終的には経営層の責任なのです。

データ分析基盤におけるMVPの考え方

前回の記事ではデータ分析基盤開発において小さく動くものから作ることの必要性を解説しました。では、データ分析基盤におけるMVPとはなんでしょうか？一言でいうならば、意思決定者がデータを取得し意思決定に活かせる最小構成です。ここでは2つの要素を取り上げます。得られるデータがビジネスの意思決定の役に立つこれは言うまでもないことですがビジネスの意思決定の役に立つことが目的です。そのため、大なり小なり意思決定へ寄与することが求められます。なんの役にも立たないデータしか取得できない分析基盤はMVPになりえないという話です。もちろんMVPですからクリティカルで重要な知見を提供する必要はありません。イノベーティブな指標を計算しようとすると仕様を決めるのに時間がかかるので数字がある程度わかっているものを選んだほうがよいくらいです。スプレッドシートで計算しているものを自動化できるくらいでも良いでしょう。自動化されれば手間や品質の改善が起きるのでこれも重要な成果です。大事なのは役に立っているということです。この基準はクイックウィン的な発想も入っています。なにかしら役に立つことを証明し具体的なイメージをもってもらうことでその後の進行が円滑になりますし課題も見えてきます。誰も注目しない数字では次のステップへのブーストになりません。「この数字が見られるならこっちも見てみたいな」そう思ってもらえるようなものをアウトプットすることで初めて積極的な投資が得られます。実はデータ分析基盤のMVPとは利用者側の体勢の検証でもあります。データドリブンな意思決定パイプラインは作れるか？自分たちの意思決定に必要なデータはなにか定義できるか？現場のデータ入力を掌握できているか？こういった問いを自分たちに突きつけるシーンです。データソースからBIまで取得・保存・加工・可視化が一気通貫に動くビジネスの意思決定に役立つことが重要だと述べましたが、そのためには使う側にデータを届けられるシステムが必要です。これを満たすにはデータ分析にかかる一連の処理が一気通貫に動いていることが求められます。重要なのは要件が把握されコントロールできていることです。データ分析基盤を実装するにあたって最大の壁がデータの取り扱いです。実際に実装を始めると想定外のデータの仕様にぶつかります。データソースからデータが取得できない取得したデータのスキーマがおかしい入っているデータの仕様がわからない …etcとさまざまな問題が噴出します。これらの問題について必要な項目は仕様を調査したり対応を実装していきます。ポイントはやりたい分析に必要な仕様がわかっており、必要なデータの取得 ~ 可視化までの処理が可能な限り自動化されていることです。仕様を把握する MVPなので入っているデータについてすべて整形し仕様を把握する必要はありません。はっきりいってデータの仕様はすべてを理解しようとすると莫大な時間がかかります。仕様書に書いてあることと実態がズレていることなんて当然に起きますし仕様書がないことも頻繁です。達成したい最低限の問題についてだけ答えられればよいのでそこに絞って調査をおこないます。指標の集計に必要な仕様の把握は必須です。データの結合方法や集約キーの仕様、絞り込みに使うパラメータなどがあります。使えるとおもっていたデータが実は集計に使えなかったということはよくあります。たとえば、顧客の属性情報がCRMに入力されているが自由記述なので内容がバラバラで簡単に集約できないということはありがちです。実際のデータを見るまでは油断しないほうがいいでしょう。また、データ自体の仕様の整理も必要です。取得するデータがどんな状態なのか実際にやってみるまでわからないことがほとんどです。言い換えると仕様と実態がズレていたり仕様が明瞭でないことが頻繁に起きます。スキーマの破損やデータの欠損などのデータ品質は前処理や集計に関わってきますし、場合によっては自動化の可・不可にまで影響します。人によって入力にばらつきがあるようなデータの不整合は一括で対応できないため自動化ができなくなります。このようなデータの状態は実際のデータを見ないとわかりません。実態を見ながら対応を考え、MVPとしてどのように進めるのか？着地をどうするのか考えていきます。自動化するデータ分析基盤をシステムとして実装している以上は当然自動化が期待されています。最初から完全な自動化が必要というわけではありませんが可能な限り手作業は排除すべきでしょう。処理をコードとして実装し自動で実行できる環境を構築していきます。人がやっているからといって自動化できるとは限りません。それぞれのステップの処理を自動化できるのかどうか、という観点だけでなくステップ同士をスムーズに連携できるかどうかもポイントです。定期実行の設定も重要です。データを閲覧したい時間や更新タイミング、処理の時間は重要な課題です。あるデータは朝に更新され別のデータは夕方に更新されるので統合した結果がわかるのは次の日になってしまう、なんてケースは珍しくありません。 cronなどスケジューラーでもよいので自分たちの用途に合わせて自動化が構築され、あわせて今後の拡張の方向性が見えていることが望ましいでしょう。とはいえ、自動化が難しいケースは珍しくありません。前述したようにデータソースの品質の問題で自動化ができないようなデータはよくあります。無理に自動化を目指してスケジュールが遅れるくらいなら手動でも良いとおもいます。その場合は手作業を前提に誰がいつどのように行うのか？などを明確に整理し動作を検証する必要があります。一方で自動化の仕組みはあるがエラーばかりで全然動かない状態は問題があります。 MVPとはいえスコープの範囲ではそれなりに想定されたとおりにシステムが動いている必要があります。 ...

データ分析基盤はまず動くものを作れ

動くものを作らないから失敗する失敗するデータ分析基盤プロジェクトに共通する重要な特徴の1つは「動くものから作らない」ということです。何年もかけて巨大な基盤を構築しすべてが完成してから稼働させるようなやり方は経験上うまくいきません。開発の前にすべての要件を定義し仕様を決めようとする。データ分析基盤の実装をレイヤーごとに進めようとする。こういった進め方をしようとする人は少なくありませんが実際のところうまくいきません。なぜ、このような進め方をするとなぜ失敗するのでしょうか？ 3つの要素にわけて解説します。時間をかけると作った頃には役に立たないまず根本的な問題として、データ分析基盤を何年もかけて作ったとしても完成した頃には情勢が変わっており使い物にならない可能性が高いという点があげられます。これはビジネスを取り巻く環境の影響を受けること、そしてデータ分析基盤は社内の様々なシステムの影響を受けることから発生します。現代の市場は凄まじい速度で変化しておりビジネスの戦略もそれに合わせて日々変わっていきます。ビジネス戦略が変われば知りたい情報もどんどん変わっていきます。何年も前に決めた指標や分析方法が役に立つでしょうか？少なくない割合で変更が求められることは想像に難くないでしょう。このようにして作った瞬間から役に立たないダッシュボードができあがります。また、社内システムが変更されれば取得するデータの性質は変わっていきます。 1つ1つの変更の周期は短くなくとも様々なシステムによってなりたっている現代では毎年のように何らかのシステムが変更されていきます。変更に限らず新たなシステムを導入することも珍しくないでしょう。データ分析基盤は様々なシステムの下流に位置するためそれらの影響を強烈に受けます。また、社内のシステムは変わらずとも法律や規制などによって変更や修正が要求されることもあります。分析に必要なデータソースが増えたり減ったり変更されることで、データの取得方法や前処理、集計の定義すら変わるのです。フィードバックループを回せ次に重要な問題の1つとしてフィードバックループが回らないことが挙げられます。完成まで誰も触らなければ誰も検証できずフィードバックができません。途中で誰かが実際に利用しはじめていれば意思決定に使える分析ができるのか確認できますし問題があれば修正ができます。開発の前に完全な要求や仕様を定義することはできません。事前の想定が間違っていたという自体は当然のように発生します。最初にすべてを定義して設計、実装を行うという方法は絶対に過不足が発生します。分析する側も分析基盤を開発する側も両方でこの問題が発生します。分析する側は実際に分析して意思決定に活かしてみると最初に想定していた指標では上手くいかない、なんてことはよく起きます。これは「考える人のスキルが足りず想定不足だった」という話ではありません。前述したように事業や環境が変わって分析の切り口が変わるケースはその典型例です。探索的に分析を行うことで初めて見えてくるものもあります。やってみないとわからないことがたくさんあるのです。分析基盤を構築する側としては当然上記の分析する側の状況が変化すれば作るものも変わってきます。見たい指標が変わればデータマートやダッシュボードの実装は変化するでしょう。場合によっては中間テーブルでのデータの持ち方や前処理の方法を変更する必要があるかもしれません。想定よりも負荷が高くてうまく運用が回らないというケースもありえます。これらの問題を使う前にすべて洗い出すのはおおよそ不可能であるといってよいでしょう。少なくともすべてを洗い出すコストとリスクを考えると作って使ったみたほうが早くて確実です。地に足のついた議論をするもう1つ重要な問題として進める優先度や方向性を揃えることが難しいという点があります。データ分析基盤は社内の多くのステークホルダーを巻き込んで開発されるものです。意思決定に活かすという性質から上位レイヤーの人間への影響をもちます。その中データ分析基盤ではどれをどの順番で作るのか決めていく必要があります。これが実際に動くものと検証ができない状態だと物事を進めるのが簡単ではありません。データ分析基盤の開発に着手するとき、多くのステークホルダーは具体的なイメージを持てていません。まして自分たちのチーム以外との連携などほぼ不可能といってよいでしょう。しかし実際に開発を進めるには社内のそれぞれのステークホルダーの要望から優先度を決める必要があります。具体的なモノがない状態だと各々の認識をぶつけることになり議論が空中戦になりがちです。結果として社内の力学がそのまま反映されてしまいあるべき姿から歪んでしまいます。しかし、実際に作ったものがあり動かすことができれば多くの人の認識を揃えるやすくなります。荒削りでもダッシュボードがあれば間違っている計算や不足している観点を洗い出すことができます。自分たちのチームで使うならどんなデータが不足しているのか想像することができるでしょう。そのための課題も具体的に見えてきます。動くものがあればできることや難しいことのイメージを捉えやすくなるため進める方向性や優先度の認識が揃えやすいでしょう。おわりにここまでに述べたような理由からデータ分析基盤の構築は使う前から最初に時間をかけて大きく作るものではありません。まずは小さく作りそれを絶えず修正・改善しながら大きく拡張するものなのです。では、具体的にどのように小さく作ればよいのでしょうか？次の記事ではMVPについて考察します。

データ分析基盤を開発するときデータを取得する方法をどうやって考えればいいのか？

データ分析基盤を構築するとき避けて通れないのが「どうやってデータを取得するか」という問題です。 SaaSのETLツールを使うのか、APIを自前で叩くのか、手動でCSVを取り込むのか。データを取得する手法は選択肢が多く状況に応じて最適な手法は変化します。また、技術的な問題だけではなく分析する側であるビジネス上の要求も考える必要があります。本記事では技術選定の判断基準を整理し、筆者の経験をもとに実際によくある検討のパターンを解説します。データの鮮度・更新頻度更新頻度は技術選定に最も直接的な影響を与える要素です。一般にデータを更新する頻度が上がるほど自動化の設計は複雑になります。日次であれば夜間バッチで全件更新というシンプルな仕組みで済みますが、これが数時間おきとなるとAPIのレートリミットを意識した設計が必要になるかもしれません。更にリアルタイムになれば差分検知やリトライの仕組みまで求められます。つまり更新頻度は「どの程度の仕組みを作る必要があるか」を決める起点であり実装・運用コストに直結します。逆にいえば「どれくらいの頻度でデータを更新する必要があるか」を最初に固めることで選択の幅が大きく絞り込むことができます。低頻度低頻度とは年に数回くらいの想定です。こういったデータの場合は手動で全件を更新するというケースが多くなります。データソースと分析上の要求として増分・差分をわざわざ検知する必要がないため全件更新で問題がないこと、そして頻度が低いため自動化のメリットを享受しにくいこと多いためです。更新頻度が低いデータの場合はそもそもデータの形式や用途が安定しないこともあり処理の内容を毎回検討する必要が多いことも自動化の優先度が下がる要因の1つです。自動化を選ばないケースでいうと、たとえば特定のプロジェクトや顧客で単発で発生するようなケースがあります。プロジェクトで単発的にデータが発生したり、顧客ごとにデータの形式にばらつきがあったりという状況です。このような不定期でデータの形式も完全に固まっていない場合は自動化のコストが高くなりがちです。担当者がその都度手動で取り込む運用でも十分でしょう。逆に頻度が低いとはいえデータの形式が固まっており処理が複雑という場合は自動化のメリットが上回ります。エクスポートしたデータをエクセルなどで細々と整理してからアップロードするようなプロセスが必要だとしたら手間もかかりますしミスも起きやすいので自動化が望ましいでしょう。たとえば、年に数回しか更新されないマスタデータがありながらインポートにひと手間必要という場合はこのケースに該当します。完全に自動化する必要もないので無理にワークフローに載せずにスクリプトとして保存しておくなどの対処もありえます。月次・週次月次・週次で更新する場合は全件更新するケースが多くなります。データソースの特性として月次・週次で更新するデータは何らかの作業がひととおり終わったものを保存するというケースが多く、そのため増分・差分を検知して保存するというよりも全件を保存したいことが多いからです。たとえば締め作業が終わって確定した会計データや、週次で棚卸し作業をしている在庫情報などが挙げられます。月次・週次くらいの頻度で恒常的に発生するとなると自動化による作業コストが削減できるメリットが大きくなるため多くの場合で自動化を検討します。 1つ2つくらいのデータソースであればなんとかなりますがデータ分析基盤には多くのデータソースを結合していくことになりますので自動化することを前提に設計するべきでしょう。また、作業ミスによるリスクも考慮に入れるべきです。それなりの頻度で作業することになりますから必然的にミスも発生します。作業ミスはそのままデータ品質の問題に、そして誤った意思決定へと繋がります。より確かな意思決定という観点からも週次・月次くらいの更新頻度が定常的に発生するようであれば自動化が前提という意識でいるのがよいでしょう。日次更新最も一般的な更新頻度です。毎晩にバッチ処理を走らせ朝出社したときには最新のデータが見られるようになっている、というサイクルは多くのビジネスの意思決定に十分なサイクルです。日次の更新ではデータ量がよほど大きくない限り全件を取得してそのまま更新するシンプルな設計をベースに検討します。この頻度になると自動化は原則です。毎日の作業となると手動では作業の負担が大きくなります。あわせて作業頻度が増えることでミスも起きやすくなるため担当者の業務を圧迫します。スケジュール実行で毎日自動的に動くように設計しておくことで安定した運用が実現できます。基本は全件更新ですがデータ量が多い場合は全件更新が難しくなるため増分・差分更新を検討する必要も出てきます。ただし増分・差分更新は実装が複雑になるため、まずは全件更新でシンプルに作り必要に応じて改善するアプローチを取るほうが無難です。現代ではデータの保存・処理コストは非常に安いので実装が複雑になることのデメリットの回避を優先したほうがよいケースは多いでしょう。数時間に一度日次よりも高い頻度で更新したいがリアルタイムだと工数が高すぎるという場合にとる選択肢です。ログデータのような量が多く変化を素早く検知したいようなケースです。もしくは日次だとデータ量が多くなるため分割したいという場合です。数時間おきに更新するときは同時に増分・差分更新が要件となることが増えます。差分を検知して変更があった分だけを取得する設計が取れるか検討しましょう。増分・差分更新が求められがちな理由はいくつかあります。数時間ごとに更新したいデータはログデータのようにデータ量が多く変更よりも追記が多いデータであるため増分・差分更新が要件になりがちです。そうでなくとも数時間ごとに実行すると日次の数倍の処理量になるためさすがにコストが無視できない状況になってきます。合わせてAPIの実行頻度が増えるため毎回全件更新するとAPIのレートリミットに引っかかるリスクも高まります。このような理由の組み合わせから増分・差分更新になりやすくなります。もちろん全件更新で要件として十分なのであればそのほうが望ましいことは言うまでもありません。注意点として、増分・差分更新の実装には「どのレコードがいつ変更されたか」を追うことが必須です。そのためのタイムスタンプや連番IDがデータソース側に存在することが前提になります。これが整備されていない場合は差分の検知自体が難しくなるためデータソースの特性を事前に確認することが重要です。即時〜数分のリアルタイム連携リアルタイム連携はデータソースの変更が即時もしくは数分程度の遅延で反映されるような設計です。ユーザーの行動ログデータや広告データなどデータ量が非常に多く、同時に変化を検知したいという場面で求められることが多いです。リアルタイム連携は更新頻度としては理想ではありますが一方で他の更新頻度に比べて実装・運用コストが高くなります。リアルタイム連携には大きく2つのアプローチがあります。一つはデータソース側で変更が発生した時点でイベントとして通知を受け取るイベント駆動型で、もう一つは数分おきに差分だけを取得するミニバッチ形式です。どちらも「変更をほぼリアルタイムで検知して取り込む」という点では共通しており日次のバッチ処理とは設計の考え方が大きく異なります。どちらのアプローチが現実的かはデータソースの特性やAPIなどのインターフェイスによって変わります。リアルタイムにデータを連携しようとすると要求される技術的な難易度が一気に上がります。単純なAPI連携で全件更新するバッチ処理に比べると差分の検知に加えてリトライ設計や運用の監視など考えるべき要素が増えるためです。障害発生時も全件更新であれば再度実行すれば簡単に復旧することが可能ですがリアルタイム連携の場合はどこまでデータが取れているのか確認する必要があるなど復旧のコストと難易度が高くなります。一方で、リアルタイム連携が求められやすいデータソースは公式や外部SaaSにリアルタイム連携のコネクタが用意されていることもあるのでその場合は比較的実現しやすくなります。 ...

データから大通りを探せ

データ分析と戦略と優先度前々回の記事では経営に近い抽象的な指標をそのまま現場に渡しても「何を変えればいいのか」がわからないという問題を取り上げました。解決策として指標をファネルや要素やセグメントに分解し課題の所在を具体的に特定することの重要性を述べています。前回の記事ではその続きとして、分解して見つかった課題に片っ端から対応すればよいわけではないという話をしています。見つかった課題のなかからどこに集中するかを決めること、つまり戦略を立てることが不可欠であり、KPIとはその戦略を定量化した指標だという整理です。この2つの記事を踏まえると「分解して課題を見つけ、戦略的に優先度を決める」という流れが見えてきます。では実際にどうやって優先度を判断すればいいのか。本記事ではその判断軸として「大通り」という考え方を紹介していきます。課題を見つけたら次に考えること指標を分解して分析を進めると課題は次々と出てきます。特定のセグメントでファネルの通過率が低い。ある流入経路だけ転換率が落ちている。こうした発見は分析の成果であり現場への具体的なインプットになり得るものです。しかしそこで一度立ち止まってほしいことがあります。「その課題を改善したとして、どれくらいのインパクトがあるのか」という問いです。たとえば特定のセグメントのファネル通過率が低いとして、そのセグメントが全体売上に占める割合が1%だったとしましょう。仮にその通過率を2倍に改善できたとしても事業全体への影響は微小です。課題を見つけることと、その課題に取り組む優先度を判断することは別の話です。分析で見つかった課題はあくまでも「改善の候補」にすぎません。そのなかからどこに時間とリソースを投じるかを判断するためには自分たちのビジネスのどこが「大通り」なのかを把握しておく必要があります。大通りとは何か大通りとはユーザーがたくさん通りお金が動いているところ、言い換えれば自分たちのビジネスのコアです。都市の地図に置き換えると分かりやすいかもしれません。賑わっている大通りに面した店と人通りの少ない小道に面した店では、同じ改装工事でも集客への影響がまったく違います。大通りに面した店の入り口を広げれば多くの人が入りやすくなりますが、小道に面した店をどれだけ改装しても通行人が少なければ効果は限られます。ビジネスも同じです。大通りを改善すればインパクトが大きく小道を改善してもインパクトは小さい。だからまず自分たちのビジネスの大通りがどこなのかを定量的に把握することが先決になります。大通りの2つの考え方大通りを把握するには2つの視点があります。ひとつ目は「どの商品が誰に売れているのか」という視点です。売上の大部分を占める商品は何か、それをよく買うのはどんなユーザー層なのか。これを把握することで自分たちのビジネスの主軸が見えてきます。全商品・全顧客を均等に扱うのではなく売上構造を正直に見ることがスタートになります。たとえばECサイトで家具・雑貨・インテリア用品を扱っているとしましょう。取扱商品数は雑貨が圧倒的に多いですが売上の大部分はソファやベッドといった大型家具が占めているというケースはよくあります。このとき大通りは大型家具です。商品ページの改善や購買体験の見直しをするなら大型家具を起点に考えることがインパクトの大きい投資になります。ふたつ目は「商品がどのように購入されているのか」という視点です。同じ商品でも購買に至るまでの経路や行動パターンはユーザーによって異なります。よく使われている経路や購買パターンがある。その「よく通られているルート」こそが大通りであり、そこを改善することがサイト全体の購買体験の底上げにつながります。先ほどのECサイトで続けると、ログを分析した結果、大型家具を購入したユーザーの多くがトップページから特集ページを経由して商品ページに到達していたとします。一方で検索機能を使って直接商品ページに来たユーザーの購買率は低い。この場合トップページから特集ページへの導線が大通りです。特集ページのコンテンツを充実させる・季節や用途に合わせた特集を増やすといった施策は多くの購買ユーザーの行動に直接影響しますが、検索機能の改善は通過するユーザーが少ない分インパクトの上限が小さくなります。この2つの視点は排他的ではありません。「大型家具を買うユーザーがよく通る経路」のように掛け合わせることで大通りはより具体的に把握できます。通りの大きさがわかれば施策のインパクトが読める大通りがどこかわかればその通りの規模を使って施策のインパクトをシミュレーションできます。たとえばあるセグメントの転換率を5ポイント改善したとして、そのセグメントの流入数と現在の単価から売上への影響を試算できます。大通りであれば多少コストや工数がかかる施策でも投資対効果が見合いやすく腰を据えて取り組む理由になります。逆に小道であれば「インパクトが小さいのでシンプルな施策に絞る」という制約が自然と生まれ、施策の設計も研ぎ澄まされます。施策のインパクトを事前に試算する習慣は分析チームと事業側の対話を変えます。「この課題を改善しましょう」ではなく「この改善によってこれくらいのインパクトが見込めます」という会話ができるようになれば優先度の議論はより具体的になります。大通りは組織で合意する大通りを定量的に把握することは分析チームの仕事ですが、それだけでは不十分です。分析チームが「ここが大通りだ」と示しても各チームはそれぞれ自分の担当領域を大通りだと思って動きがちです。営業は自分が担当している顧客層を、マーケティングは自分が担当しているチャネルを大通りだと信じている。この状態のまま施策を走らせると前記事で述べたのと同じ問題が繰り返されます。各チームが自分の指標を追っているのに組織として同じ方向に向いていない状態です。大通りの定義は分析チームが示して終わりではなく経営や事業責任者、現場を巻き込んで「ここが自分たちのコアだ」と合意するプロセスが必要になります。合意された大通りは組織の共通言語になります。施策のアイデアが出たときに「それは大通りへの投資か」という問いが自然に生まれるようになれば優先度の判断が組織全体でできるようになります。まとめ分析で課題が見つかることは出発点にすぎません。その課題がビジネスのどこにあるのかを大通りという視点から評価することが次のステップです。大通りとはユーザーがたくさん通りお金が動いているところ。「どの商品が誰に売れているか」と「商品がどのように購入されているか」という2つの視点で把握します。そして把握するだけでなく組織として合意することが大通りを判断の共通言語にするために欠かせません。大通りがわかれば施策のインパクトを読めます。インパクトが読めれば優先度が決められます。優先度が決まれば組織のリソースをコアに集中させることができます。分析から行動への道筋はこの順番で整っていきます。

戦略なくしてKPIなし

課題が見えたら次は何をするか前回の記事では経営に近い抽象的な指標をそのまま現場に渡しても「何を変えればいいのか」がわからないという問題を取り上げました。その解決策として指標をファネルや要素やセグメントに分解し課題の所在を具体的に特定することの重要性を述べました。では分解して課題が見えたとして、見つかった課題に片っ端から対応すればよいのでしょうか？もちろん答えはノーです。課題が見えることと正しく対処できることのあいだにはもうひとつ大事なステップがあります。それが戦略です。見つかった課題をそのまま各チームのKPIに据えて改善を任せるというのはよくある流れです。しかし、このように漫然とした進め方では上手くいきません。マーケティングはリード数を追い営業は成約率を追いカスタマーサクセスは解約率を追う。それぞれは正しく見えますが全体としてどこに向かっているのかが定まっておらず組織の成果につながりにくい状況へなりがちです。課題の特定と施策の実行のあいだには「どこに集中するか」を決める戦略が欠かせません。本記事ではこの戦略とKPIの関係を整理します。全部やろうとすると全部中途半端になる指標を分解すれば改善すべきポイントはいくつも出てきます。たとえば「リード獲得率が落ちている」「商談からの成約率も低い」「既存顧客の解約率も上がっている」など、どれも放置できない課題です。ここで「全部やろう」となるのは自然な感覚ですし危機感の表れでもあります。しかし全体の方向性がないまま各チームが自分の担当する課題に個別に取り組み始めるとそれぞれの合理的な判断が噛み合わず組織として逆方向に進んでしまうことがあります。たとえばこんなケースを考えてみます。マーケティングはリード数を伸ばすために獲得しやすい中小企業向けの広告に予算を寄せる。営業は成約率を上げるために意思決定の早い小規模案件を優先する。カスタマーサクセスは解約率を下げるために一社一社に手厚いサポートを提供する。どのチームも自分の指標を改善するために合理的な判断をしています。しかし結果として起きるのは単価の低い顧客ばかりが増え一人あたりのサポートコストが利益を食いつぶしていくという状態です。仮に本来この事業がエンタープライズ向けに舵を切るべき局面にあったとすれば組織全体が逆方向に進んでいることになります。個々のチームの数字は改善しているのに事業としては悪化している。これは各チームの努力が間違っていたのではなく全体の方向性が定まっていなかったこと、そして事業の方向性と一致していなかったことが原因です。どの課題に優先的に取り組むのかを決める。その判断こそが戦略です。指標の分解は戦略のために行うここで前回の記事を振り返ります。指標を分解して課題を特定することは重要です。しかしその目的を改めて整理すると指標の分解とは戦略を考えるための材料を揃える行為だと言えます。指標の分解はこのプロセスの起点であり手段です。分解すること自体が目的になってしまうと「課題はたくさん見つかったがどこから手をつければいいかわからない」という状態に陥ります。これは分析が足りないのではなく判断が足りないのです。分析チームは指標の分解によって課題の全体像を提示する。意思決定者はそのなかから組織として取り組むべき課題を選ぶ。現場はその判断に基づいて具体的なアクションを設計し実行する。それぞれの役割が噛み合ってはじめて分析から成果につながる流れが生まれます。戦略を定量化したものがKPI ここまでの話を踏まえるとKPIの位置づけも明確になります。指標を分解すれば改善候補となる指標はいくつも出てきます。しかしそのすべてをKPIにするわけにはいきません。すべてを追えばリソースが分散し結局どれも十分に改善できないという先ほどの問題に戻ってしまいます。 KPIとは分解によって見えてきた複数の指標のなかから戦略的な判断に基づいて選ばれるものです。「この課題がいま最も重要でありここに集中することが全体の成果につながる」という意思決定の結果として定められる指標がKPIだと言えます。「KPIはなぜ"重要"なのか」と聞かれることがありますが、KPIとして選ばれた指標が重要たり得るのはそれが戦略を定量的に表しているからです。KPIの背後には「どの課題を優先するか」「なぜその課題なのか」という戦略的な判断があります。それらの戦略の状態や進捗を定量的に示すから Key-Performance-Indicator なのです。言い換えればKPIとは課題がわかるくらいに具体的であり組織としてその改善を優先すると決めた指標のことです。具体性と優先度の両方が揃ってはじめてKPIとして機能します。戦略がなければKPIは機能しないここまでの議論を裏返すと戦略が不在のままKPIを設定することの危うさが見えてきます。戦略がない状態で指標を分解しそのまま各チームにKPIとして渡すとどうなるか。各チームは与えられた数字を改善することに集中します。それ自体は真摯な取り組みです。しかし各KPIのあいだに優先順位がなくそれらがどの方向に向かっているのかも示されていなければ個々の改善努力が全体の成果に結びつきません。問題はそれだけではありません。一度KPIとして設定された数字は組織のなかで独り歩きしやすくなります。「なぜこの指標を追っているのか」という背景が薄れ「この数字を上げなければいけない」という部分だけが残ってしまい、環境が変わっても市場の優先課題がずれてもKPIだけは据え置かれたまま組織が動き続ける、なんてことが起こります。もし戦略に基づいてKPIを設定していれば環境が変わったときにKPIの妥当性を問い直すことができます。「この指標を追う理由は何か」「いまの戦略に照らしてまだ有効か」という判断基準があるからです。しかし戦略がなければその問い直しの根拠がありません。KPIを変えるべきタイミングで変えられず組織が古い指標に縛られ続けるリスクがあります。まとめ指標を分解して課題を見つけることは重要ですがそれだけではアクションにつながりません。見つかった課題のなかからどれに集中するかを決めること、つまり戦略を立てることが不可欠です。 KPIとは戦略を定量化した指標であり分解から生まれた多くの候補のなかから「いまここに集中する」と組織として判断した結果として定められるものです。戦略的な判断がなければKPIは単なる数字の羅列になりかねません。戦略なくしてKPIなし。KPIの設定は分析の延長線上にあるのではなく戦略の延長線上にあるものです。

データ分析からアクションが生まれないのはなぜか？

データはあるのに動けない「データを見ているのに現場が動かない」という話をよく聞きます。ダッシュボードも整備した。数値から課題は見えている。それなのに現場の動きが変わらない。この状況に心当たりがある方は多いのではないでしょうか。分析チームからすると「データは出しているのに活用されない」と感じているかもしれませんが、現場からすれば「その数字を見せられても何をすればいいか考えられない」とおもっているかもしれません。これはどちらかが悪いという話ではありません。この噛み合わなさには構造的な原因があるのです。この記事では、この問題が発生する原因として経営に近い指標は抽象度が高く現場では使いにくいという課題を解説しながら、対策として指標を分解することで現場で使いやすくするという考え方を紹介します。経営に近い指標は現場では使いにくい多くの組織でデータ分析の起点になるのは売上や顧客数といった経営において重要視されている指標です。当然ながらこれらは組織にとって重要な数字であり注視すべきものです。しかしこうした指標をそのまま現場に渡しても「売上が下がっています」「顧客数が伸びていません」という報告にしかなりません。ここに問題の本質があります。売上が落ちていること、顧客数が伸びていないことなんて現場の人間だってわかっています。日々の業務を通じて直感的な理解あるいはそのレベルの数値は現場でも持っていることが多いでしょう。しかも現場はその課題に対してすでにアクションを取っています。施策を打ち改善の努力を続けている。それでも数字が動かないから困っているのです。現場が本当に知りたいのは「売上が落ちている」というレイヤーの事実ではありません。「今やっていることの何をどう変えればいいのか」であり「具体的な問題はどこなのか？」ということです。経営に近い抽象的な指標はこの問いに答えることができません。だからデータを見ても現場のアクションにつながらないのです。指標を分解して深堀りするではどうすればいいのか。答えはシンプルで経営に近い指標をそのまま使うのではなく分解して深堀りすることです。ここでいう分解とは単に数式的・論理的に要素を分けることだけではありません。ファネルの段階ごとに分けたりセグメントごとに切り分けたりすることも含みます。分解の目的は「どこに問題があるのか」を具体的に特定することです。指標が抽象的なままでは打ち手も抽象的になります。分解して問題の所在を絞り込むことで初めて「何を変えるべきか」という現場が求める問いに近づけるのです。分解にはいくつかの視点があります。ファネルでの分解は全体のプロセスをステップごとに分けてどの段階で数字が落ちているかを特定します。これによって「どの工程に問題があるのか」が見えてきます。要素への分解はひとつのステップをさらに構成要素に分けることです。量の問題なのか質の問題なのかといった切り口で課題の性質を特定します。セグメントでの分解は顧客の属性や行動パターンごとに数字を切り分けることです。全体で見ると問題に見えていたものが特定のセグメントに偏っていると気づければ打ち手はぐっと具体的になります。これらの分解は排他的なものではなく組み合わせて使うものです。ファネルで問題のある段階を特定しそこを要素やセグメントでさらに深堀りするというように段階的に絞り込んでいきます。顧客数が伸びないときを例にかんがえてみるここまでの考え方を顧客数の問題を例に見てみます。ファネルでチョークポイントを特定する「顧客数が伸びない」という課題をそのまま扱おうとすると打ち手は漠然としたものになります。まずファネルに分解して問題がどの段階にあるのかを特定します。たとえばBtoBのSaaS事業であれば広告表示→サイト訪問→資料請求（リード獲得）→商談→成約というファネルが考えられます。この各ステップの件数と転換率を並べてみると全体のどこで数字が大きく落ちているかが見えてきます。仮にサイト訪問数は前年並みなのに資料請求数が大きく減っているとしましょう。この時点で「顧客数が伸びない」という曖昧な課題が「リード獲得の段階に問題がある」という具体的な論点に変わります。要素とセグメントでさらに深堀りするファネルからチョークポイントが特定できたら次はその段階をさらに分解します。まず要素への分解です。資料請求が減っているのは量の問題なのか質の問題なのか。サイトへの流入数自体が減っているのかそれとも流入は維持されているのに資料請求への転換率が下がっているのか。量の問題であれば集客施策を見直す必要がありますし転換率の問題であればLPや訴求内容に原因がある可能性が出てきます。これだけでも打ち手の方向性は大きく変わります。次にセグメントでの分解です。流入元の媒体ごとに転換率を見たときにリスティング広告は横ばいなのにSNS広告経由だけが大きく落ちているかもしれません。あるいはターゲットセグメントごとに見ると中小企業向けのリードは堅調なのにエンタープライズ向けのリードだけが減っているかもしれません。業種や企業規模といった属性で切り分けることで全体の平均に隠れていた偏りが浮かび上がります。こうして段階的に分解していくと「顧客数が伸びない」という漠然とした課題が「SNS広告経由のエンタープライズ層のリード獲得率が落ちている」といった具体的な問題に変わります。ここまで絞り込めれば現場は「何を変えるべきか」を考えられるようになりますし分析チームと現場が同じ問題について具体的に議論できるようになります。具体的にすればいいわけでもないここまで指標を分解して具体化する重要性を述べてきましたが注意点があります。具体化しすぎると今度は別の問題が起きます。指標が具体的になるほど現場はその数字を改善することだけに集中しやすくなりますが、これは行動が特定の指標に引っ張られて局所最適に陥りやすくもあります。本来であれば現場にはさまざまなアプローチを試す余地があるはずですが具体的すぎる指標はその多様性を奪います。「この数字を上げればいい」という明快さが逆にアクションの幅を狭めてしまうのです。たとえば「SNS広告経由のエンタープライズ層のリード獲得率が落ちている」という問題に執着してしまうと「SNSではなくセミナーのほうが効率がよいかもしれない」というソリューションにたどり着きにくくなってしまいます。あくまでも本来の目的はリード獲得率の改善ですから、ほかのアプローチを模索したほうが効率がよい可能性もあります。具体的な指標はわかりやすく行動を促す力が強い分だけ視野を狭める力も強くなります。これは分解の粒度を考えるうえで常に意識しておくべきことです。分解の目的はあくまで「どこに問題があるのか」を特定して対話の土台をつくることです。分解した結果をそのままKPIとして現場に渡すこととは違います。分析チームと現場が分解の結果を見ながら「ではどうするか」を一緒に考える。そのプロセスがあってこそ分解は意味を持ちます。まとめデータ分析からアクションが生まれない原因は分析する側の力不足でも現場の理解不足でもありません。経営に近い抽象的な指標がそのまま現場に渡されることで「何を変えればいいのか」「どこに解くべき課題があるのか」という問いに答えられていないことが根本的な原因です。この問題を解決するには指標をファネルや要素やセグメントに分解して「どこに問題があるのか」を具体的に特定していくことが必要です。分解によって問題の所在が明確になれば分析チームと現場が同じ具体的な課題について対話できるようになります。データ分析の価値は数字を出すことではなく「次に何をすべきか」を一緒に考える土台をつくることにあります。そのためにまずは指標の分解から始めてみましょう。

データに基づく意思決定と経験に基づく意思決定

はじめにこの記事ではビジネスにおいてデータを分析した意思決定をおこなう目的やメリットを紹介します。さまざまな場所で議論されているテーマですが自分なりの考えをまとめたく記事として残します。似たようなテーマで複数の観点から解説していく予定です。意思決定における2つのアプローチビジネスの現場では複数の選択肢からどれか1つを選ばなければいけないというシーンがよくあります。たとえば、マーケティングにおいて「商品のプロモーション用に広告AとBの2つの候補からどちらを選ばなければいけない」なんてシーンは想像に容易いでしょう。他にも「どの見込み顧客から営業をするべきか？」とか「このプロダクトのボタンは赤と青どちらの色にしたらいいだろうか？」なんてことを考えている人はきっとこの記事を読んでいる方にもいるのではないでしょうか。これは日常的な風景ですが、しかしこれらの意思決定によって売上が変わる可能性を秘めています。下手な広告を選んだら獲得できるリードは減るかもしれませんし、営業の優先順位を間違えば大事な顧客を逃しているかもしれません。ボタンの色が不評であれば機能を使う人が減ってしまう可能性もあります。 1つ1つの意思決定の質が企業の売上や成長へ直結する重要な要素です。では、わたしたちはどのように意思決定をしていけばよいのでしょうか？この問題に対するアプローチを大きく2つにわけて考えていきます。 1つは経験や知識に基づく意思決定、もう1つは客観的なデータに基づく意思決定です。どちらも現代のビジネスにおいて重要な役割を果たしていますが有効なシーンに違いがあります。この2つのアプローチを比較することでそれぞれの特徴を理解し上手い使い方を把握していきましょう。経験に基づく意思決定の特徴と限界長年マーケティング業界で活躍してきたベテラン担当者であれば事例や過去の体験から「このターゲット層にはこういったメッセージが響きやすい」とか「今の時期にはこのタイプの広告が効果的だった」のような経験則を蓄積しているものです。市場や顧客の心理など数値化が困難な要素を感覚的に捉える能力はベテランの貴重な資産といえるでしょう。特に参考となる情報が乏しいまったく新しい市場や商品カテゴリーのような問題ではこのような経験や知識に基づく判断が強力な手法となります。しかし、このような経験に基づく意思決定には欠点がいくつか存在します。その1つは判断の基準が個人の主観的な観察や経験に依存しているということです。例えば、新しい広告を展開した際にたまたま接触した顧客から「この広告は印象的で良かった」という好意的な反応を得たとします。このような直接的なフィードバックは重要ですが担当者に実態以上に強い印象を与えがちで全体の傾向を正確に反映しているとも限りません。接触した顧客層が特殊だった可能性、季節や時期による一時的な要因、さらには観察者自身の期待や先入観が判断を歪めている可能性などさまざまなバイアスが混入するリスクがあります。たまたまその顧客が気に入っただけで多くの人は別の要因で商品を買っただけかもしれませんし、もしかしたら顧客がお世辞をいっただけという可能性もあります。心理学でいう「確証バイアス」により自分の判断を支持する情報ばかりに注目し反対の証拠を無視してしまうこともよく見かけます。経験に基づく意思決定がその人に固有の知識や感覚に強く依存するため、品質のコントロールが難しく再現性や客観性に欠けるという点です。同じ状況でも担当者が変われば全く異なる判断が下される可能性があり、組織として一貫した品質の意思決定を維持することは簡単ではありません。データに基づく意思決定の特徴と優位性これに対して十分なデータが蓄積され適切に分析できる環境が整っている場合、意思決定のアプローチは根本的に変化します。データに基づく意思決定では実際に顧客がクリックしたり売上につながった広告やコンバージョンに結びついた施策を客観的な数値として把握することで感情や先入観に左右されない合理的な判断が可能になります。具体的な例を見ながら広告AとBのどちらがよいのか考えてみましょう。広告A 表示回数10万回クリック数2,000回（クリック率2.0%）コンバージョン数80件（コンバージョン率4.0%）獲得単価5,000円広告B 表示回数10万回クリック数1,500回（クリック率1.5%）コンバージョン数90件（コンバージョン率6.0%）獲得単価4,500円このようなデータがあれば、どちらの広告がより効果的かを明確に判断できます。この例では、広告Bの方がコンバージョン率が高く、獲得単価も安いことがわかりました。それぞれの指標について学んだ人であれば、投資対効果の観点から広告Bが優れていることが数値から読み取ることができるでしょう。 A/Bテストのような事前に準備された実験でデータを収集した場合、データの価値はさらに高まります。 A/Bテストであれば同じ期間、同じ予算、同じターゲット層に対してランダムに異なる広告を展開し統計的に比較することでどちらがより効果的か高い信頼性をもって客観的に判断できます。このような手法では、季節要因、競合他社の動向、市場環境の変化といった外部要因の影響を最小限に抑えることができ、純粋に広告自体の効果を測定することが可能になります。データに基づく判断のメリットは個人の経験や直感に依存度が低く誰が見ても同じ結論に到達できることです。マーケティング部門の新人からベテランまで同じデータを見れば基本的に同じ判断を下すことができます。これは経験に基づく意思決定とは対照的な特徴であり組織全体の意思決定の品質向上に大きく貢献します。データ活用による継続的な学習と改善データに基づく意思決定のもう一つの重要な利点は、継続的な学習と改善のサイクルを構築できることです。広告Aと広告Bの効果を測定した結果、広告Bが優れていることが判明したとします。しかし、データ活用の価値はここで終わりません。広告がどのようなセグメントに効果的だったのか調査することで次回の広告制作時により効果的な施策を企画するために活かすことができます。たとえば「広告Bは都市部のユーザーには効果があったが地方ではいまいちだった」とか「実は広告Aは獲得が難しいセグメントで比較すると優位だった」といったことがわかればターゲットに対して効果的な広告を展開できるようになります。これらの知見は組織の資産として蓄積され強力な武器となるでしょう。また、時系列でのデータ分析により、季節性や市場トレンドの変化も把握できます。「夏季は広告Aが効果的だが、冬季は広告Bの方が良い」といったパターンが見えてくれば、時期に応じた最適な施策を事前に計画することも可能になります。「広告Bはよかったが市場の変化によって費用対効果が悪くなっている」ということがわかれば新しい広告を検討すべきだとわかります。このような継続的な学習プロセスにより組織のマーケティング能力は段階的に向上していきます。データの蓄積期間が長くなればなるほどデータを通した知見も蓄積され意思決定の品質も高まります。これは個人の能力に依存した意思決定だけではなかなか難しいことです。組織全体での意思決定品質の標準化データに基づく意思決定は組織全体での意思決定品質の標準化にも大きく貢献します。経験に基づく判断では意思決定者の能力や経験値によって判断の質に大きな差が生まれます。 20年の経験を持つベテランマーケターと入社1年目の新人を比べたら判断の精度に差が出るのは自然なことです。しかし、データに基づく意思決定の仕組みが整備されていればこの格差を大幅に縮小することができます。新人でも適切なデータの読み取り方と分析手法を身につけることでベテランと同等の判断を下すことが可能になります。これは個人のスキルに依存しない組織として安定した品質の意思決定システムを構築できるということです。 ...

SQLでカテゴリごとに最大・最小の値を持つ行を取得する

SQLではよくあるケースだけど案外書くのが難しい書き方。これが一番簡単だと思いますが、もっといい方法があったら教えてください。やりたいことなんらかのカテゴリーごとに順番で並べて一番数値が高い行の他のカラムのデータを取得するクエリです。たとえば、下記のitemsというテーブルがあったときcategoryごとにpriceが最も高いnameを取得するという問題です。 itemsテーブル category name price belt a 2000 belt b 10000 belt c 4000 wallet d 3000 wallet e 60000 wallet f 15000 wallet g 20000 求める結果 category name price belt b 10000 wallet e 60000 クエリの例この問題はwindow関数でrow_number関数を使うことで記述する方法がオススメです。 select category, name, price from ( select category, name, price, row_number() over (partition by category order by price desc) as price_order from items ) where price_order = 1 なにをやっているのか簡単に言うと partition by category でcategoryごとにわけて order by price desc でprice降順で並びかえたところに row_number() で順番に番号を割り当てています。これによってpriceが最も高いとprice_orderカラムに1が入り降順で番号が割り当てられます。これをサブクエリとして price_order = 1 に絞り込むことで最大の値が手に入るという仕組みです。注意点として同じpriceの行が複数存在する場合はどれか1行しか得られません。 ...

ゼロからM2 MacにPython環境構築

プライベートで使っているPCをApple Silicon M2チップを搭載したMac mini 2023に変えたのでPythonの環境をゼロから構築しました。 macOSのバージョンはVentura 13.2.1です特に大したことはしていないですが備忘録として。環境構築 Homebrew まずはHomebrewから入れます。とにかくこれを入れないと何も進まないので。公式のページにインストールするときのコマンドが書かれているのでこれをそのまま実行します。インストール自体はこれだけで完了ですが、たぶんインストールの一番最後に「PATHを通せ」みたいなメッセージが表示されているのでそれも実行してください。 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" pyenv Pythonのバージョン管理は定番のpyenvです。これはbrewと使えば簡単にインストールできます。 brew install pyenv これだけだとPythonの向き先がシステムのPythonになったままになってしまうのでPATHをとおします。コマンドは公式のreadmeに書いてあるのでそれをそのまま実行しましょう。 https://github.com/pyenv/pyenv#set-up-your-shell-environment-for-pyenv echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.zshrc echo 'command -v pyenv >/dev/null || export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.zshrc echo 'eval "$(pyenv init -)"' >> ~/.zshrc 最新のPython ほしいバージョンのPythonをpyenvをとおしてインストールします。今回は何も考えずに一番新しいやつを入れます。一点だけ注意ですが、pyenvを経由してPythonをインストールするときxzをインストールしないと ModuleNotFoundError: No module named '_lzma' って怒られるので先んじて対応しておきます。（先に pyenv install しちゃった場合はxzを入れただけだと上手く動作しないの一度pyenvのPythonをアンインストールして pyenv uninstall 3.x.x そのあと再度インストール pyenv install 3.x.x してください） brew install xz あとは最新のpythonのバージョンを確認して ...