[{"content":"1.1 背景と本書の目的 現代のビジネス環境では多くの会社がデータの活用を進めています。データを分析してビジネスに活かすという取り組みは昔からあるものですが、特にビッグデータブームを期に多くの企業が興味をもちはじめ、DXブームによってそれは大きく加速されました。\nそんなデータを分析するためのインフラとしてデータ分析基盤に投資することは、少し前までは先進的な企業が取り組むことのように扱われてきました。ですがデータ分析ブームも今は昔。現代ではデータ分析基盤の開発に取り組んでいて当然という環境になりつつあります。\nしかし、データ分析基盤の理解は簡単ではありません。ITシステムとして技術的な難しさがありながら、一方で利用するビジネス側の要求を理解しなければいけません。さらに会社組織として活用するための管理についても把握する必要があります。\n本書はデータ分析基盤の全体像から実際の構築方法まで体系的に学習できることを目指しています。技術的な仕組みだけでなく運用・ガバナンス・組織への導入まで含めて実践的な知識を提供することで読者が自分の組織でデータ活用を推進できるようになることが本書の目標です。\n本書は1時間程度の読了予定です。データ分析基盤について全体像を素早くキャッチアップすることを目的としており、概要の説明を中心に重要なポイントに絞って解説をしています。本書を読んだ後に必要に応じて詳しい情報にあたると良いでしょう。\n1.2 読者が得られる知識 本書を読むことで以下の知識を習得できます\nデータ分析基盤の主旨\n単なるデータベースではなく企業のデータ活用能力を変革するシステム全体の役割と価値を理解できます。従来の部門別の業務システムとの根本的な違いと専用基盤の必要性を具体例とともに学びます。\nシステム構成の全体像\nデータの収集から保存・加工・分析・可視化まで一連のプロセスの役割と連携を理解できます。また3層アーキテクチャ（データレイク・データウェアハウス・データマート）をベースとした段階的なデータの加工と品質向上の仕組みを学びます。\n実装時の重要なポイント\nデータ収集の課題を踏まえた典型的なアプローチを理解できます。データ品質管理とメタデータ管理の重要性と具体的な実装方法も学習します。セルフサービス環境の構築によるデータの活用の展開についても説明します。\n運用・ガバナンス体制\n構築後の継続的な運用に必要なデータガバナンス体制とアクセス権限管理について学びます。組織のデータ活用能力を継続的に向上させるための改善サイクルも理解できます。\n1.3 想定読者 本書は以下のような方々を対象として執筆されています\nソフトウェア開発エンジニア\nデータ基盤全体の設計思想を理解しシステム要件の整理や技術選定の判断ができるようになります。また実装時の課題と対処法を事前に把握することで効率的な開発を進められます。\nデータ分析基盤の開発経験がなくとも、基本的なデータベースやクラウドサービスの知識があるならば具体的な開発のイメージをもつことができるようになるでしょう。\nデータ活用推進担当者・ビジネス側の意思決定者\nデータ分析基盤導入プロジェクトやビジネス側のステークホルダーの方に技術的な全体像と実装上の課題を把握することができます。予算計画や体制構築の判断材料として活きるでしょう。\n営業・マーケティング・経営企画などの部門でデータ分析の必要性を感じている方にデータ分析基盤の概要を理解してもうらのにも有効です。知識のベースラインを向上することでスムーズな導入が期待できます。\n1.4 本書の構成 第2章では従来システムの限界とデータ分析基盤の必要性を説明し、第3章で全体アーキテクチャを俯瞰します。第4章から第7章で技術的な実装内容（データ保存・収集・品質管理）を詳説し、第8章でデータ活用とガバナンスについて解説します。\n","permalink":"https://kenjiusui.github.io/blog/books/data-platform-intro/01_introduction/","summary":"\u003ch2 id=\"11-背景と本書の目的\"\u003e1.1 背景と本書の目的\u003c/h2\u003e\n\u003cp\u003e現代のビジネス環境では多くの会社がデータの活用を進めています。データを分析してビジネスに活かすという取り組みは昔からあるものですが、特にビッグデータブームを期に多くの企業が興味をもちはじめ、DXブームによってそれは大きく加速されました。\u003c/p\u003e\n\u003cp\u003eそんなデータを分析するためのインフラとしてデータ分析基盤に投資することは、少し前までは先進的な企業が取り組むことのように扱われてきました。ですがデータ分析ブームも今は昔。現代ではデータ分析基盤の開発に取り組んでいて当然という環境になりつつあります。\u003c/p\u003e\n\u003cp\u003eしかし、データ分析基盤の理解は簡単ではありません。ITシステムとして技術的な難しさがありながら、一方で利用するビジネス側の要求を理解しなければいけません。さらに会社組織として活用するための管理についても把握する必要があります。\u003c/p\u003e\n\u003cp\u003e本書はデータ分析基盤の全体像から実際の構築方法まで体系的に学習できることを目指しています。技術的な仕組みだけでなく運用・ガバナンス・組織への導入まで含めて実践的な知識を提供することで読者が自分の組織でデータ活用を推進できるようになることが本書の目標です。\u003c/p\u003e\n\u003cp\u003e本書は1時間程度の読了予定です。データ分析基盤について全体像を素早くキャッチアップすることを目的としており、概要の説明を中心に重要なポイントに絞って解説をしています。本書を読んだ後に必要に応じて詳しい情報にあたると良いでしょう。\u003c/p\u003e\n\u003ch2 id=\"12-読者が得られる知識\"\u003e1.2 読者が得られる知識\u003c/h2\u003e\n\u003cp\u003e本書を読むことで以下の知識を習得できます\u003c/p\u003e\n\u003cp\u003eデータ分析基盤の主旨\u003cbr\u003e\n単なるデータベースではなく企業のデータ活用能力を変革するシステム全体の役割と価値を理解できます。従来の部門別の業務システムとの根本的な違いと専用基盤の必要性を具体例とともに学びます。\u003c/p\u003e\n\u003cp\u003eシステム構成の全体像\u003cbr\u003e\nデータの収集から保存・加工・分析・可視化まで一連のプロセスの役割と連携を理解できます。また3層アーキテクチャ（データレイク・データウェアハウス・データマート）をベースとした段階的なデータの加工と品質向上の仕組みを学びます。\u003c/p\u003e\n\u003cp\u003e実装時の重要なポイント\u003cbr\u003e\nデータ収集の課題を踏まえた典型的なアプローチを理解できます。データ品質管理とメタデータ管理の重要性と具体的な実装方法も学習します。セルフサービス環境の構築によるデータの活用の展開についても説明します。\u003c/p\u003e\n\u003cp\u003e運用・ガバナンス体制\u003cbr\u003e\n構築後の継続的な運用に必要なデータガバナンス体制とアクセス権限管理について学びます。組織のデータ活用能力を継続的に向上させるための改善サイクルも理解できます。\u003c/p\u003e\n\u003ch2 id=\"13-想定読者\"\u003e1.3 想定読者\u003c/h2\u003e\n\u003cp\u003e本書は以下のような方々を対象として執筆されています\u003c/p\u003e\n\u003cp\u003eソフトウェア開発エンジニア\u003cbr\u003e\nデータ基盤全体の設計思想を理解しシステム要件の整理や技術選定の判断ができるようになります。また実装時の課題と対処法を事前に把握することで効率的な開発を進められます。\u003cbr\u003e\nデータ分析基盤の開発経験がなくとも、基本的なデータベースやクラウドサービスの知識があるならば具体的な開発のイメージをもつことができるようになるでしょう。\u003c/p\u003e\n\u003cp\u003eデータ活用推進担当者・ビジネス側の意思決定者\u003cbr\u003e\nデータ分析基盤導入プロジェクトやビジネス側のステークホルダーの方に技術的な全体像と実装上の課題を把握することができます。予算計画や体制構築の判断材料として活きるでしょう。\u003cbr\u003e\n営業・マーケティング・経営企画などの部門でデータ分析の必要性を感じている方にデータ分析基盤の概要を理解してもうらのにも有効です。知識のベースラインを向上することでスムーズな導入が期待できます。\u003c/p\u003e\n\u003ch2 id=\"14-本書の構成\"\u003e1.4 本書の構成\u003c/h2\u003e\n\u003cp\u003e第2章では従来システムの限界とデータ分析基盤の必要性を説明し、第3章で全体アーキテクチャを俯瞰します。第4章から第7章で技術的な実装内容（データ保存・収集・品質管理）を詳説し、第8章でデータ活用とガバナンスについて解説します。\u003c/p\u003e","title":"はじめに：この本について"},{"content":" 本記事はウェブメディア「Modern Times」へ2023~2024年に寄稿したものを同メディアの閉鎖に伴い加筆・修正のうえ再掲したものです。\n先行指標と遅行指標 データ分析の現場ではさまざまな指標が使われていますが、その指標が事象に対して先んじた数値なのか、それとも後から結果を説明している指標なのか、という違いは重要です。前者は先行指標、後者は遅行指標と呼ばれます。\n先行指標と遅行指標にはどのようなものがあるでしょうか？例えば、あなたがSaaSのような月額課金サービスを提供しており将来のユーザ数を知りたいとしましょう。この数値に影響を与える指標はたくさんありますが、そのなかでも獲得しているリードの数は先行指標になります。一方で顧客の離脱率は遅行指標です。\n先行指標は現在の活動のうち将来に影響を与える要因を数値にしたもので、これから起きうる事象を推測するために使えます。たとえばリード数は将来ユーザになる見込み顧客の数なのでリード数に課金率を掛けることで獲得顧客数を見積もることができます。\n遅行指標は過去の成果を測定した指標であり既に起きたことを示す数値です。結果を表す指標なのでサービスの成功や失敗を評価するのに役立ちます。たとえば顧客の離脱率は既にサービスから離れてしまった顧客の割合です。これは結果そのものでありサービスの性能を明確に示します。\n先行指標のもつ課題 では、先行指標と遅行指標のどちらが有用な指標でしょうか？同じことがわかるならば先にわかるほうが役に立つことは間違いありません。サービスから離脱した顧客の数がわかってもその顧客へ対策することは難しいですが、サービスを離脱しそうな顧客の数がわかれば先んじて対策を打つことができます。ですが実際のところそんな簡単にはうまくいきません。先行指標は有用ですが遅行指標と比べたときにいくつかの弱点があるのです。\n先行指標がもつ弱点の1つは先行指標を決めることが簡単ではないということです。遅行指標はいわば結果なので直感的に決めることができますが先行指標はそこからカスタマージャーニーを遡ったりサービス上の行動を深堀りするなど調査が必要になります。ビジネスはさまざまな要因が同時に影響し合うため有用な先行指標を特定することは簡単ではありません。特にサービスを立ち上げた初期はデータが不足しているためどの指標が先行指標たりうるのかわからないことも少なくありません。\n2つ目の問題は、先行指標には不確実性が伴うことです。遅行指標は結果そのものなので将来予測という意味での不確実性はありません。離脱率は離脱という事実の集計値であり、そこに「これからどうなるか」という曖昧さはありません。一方、先行指標は現時点の状態から将来の値を推測するものなのでどれだけ精度を上げても予測が外れる可能性は残ります。現在の見込み顧客数から将来の獲得顧客数をある程度は予測できますが、実際にその値になるかどうかはやってみないとわかりません。自分たちが知らないところで問題が起きて推測値より大きく下がるかもしれませんし、そうでなくても様々な要因で上下にブレが発生することは容易に想像できるでしょう。\n遅行指標の有用性 このように先行指標には課題がいくつかありますが、一方で、遅行指標にも問題はあります。遅行指標は既に起きてしまったことから集計された値ですので、その問題そのものを解決することはできません。たとえば離脱率を計測しても既に止めてしまったユーザそのものを復帰させることは極めて難しいでしょう。\n遅行指標は結果そのものであり確実な指標になります。そのため問題を特定する旅の出発点として有用でしょう。先行指標から課題を探すには先行指標がもつ不確実性に目を向ける必要があります。その指標がもつリスクを理解しなければ誤った分析をしてしまう可能性があります。それに比べて遅行指標は明地に足のついた指標で何を示しているのか明確です。そのため遅行指標を起点に課題を探すことで空回りを減らし、結果として早く改善サイクルを回すことが可能になります。\n立ち上げたばかりでデータが少ないサービスでは先行指標を探すことが困難というのは先に述べたとおりです。さらに、自分たちのサービスの価値や課題に対する知見が溜まっていない状態で課題を探すのは難しいものです。それよりは、まず遅行指標から自分たちの明らかな課題を解決し顧客を理解しながら徐々に先行指標を探索していくとよいでしょう。\n先行指標と遅行指標の特徴を活かす KPIはさまざまな側面から見ることが重要です。先行指標という不確実性をもった早期発見と遅行指標という遅れて届く確実な報告、このどちらもが必要になります。どちらか片方ではなく両方を上手く組み合わせることで自分たちの意思決定をより良いものにすることができます。\n自分たちの細かいアクションの効果は先行指標が敏感に反応するため便利でしょう。施策の効果が遅行指標に現れるまで待つ必要がなく次々と手を打つことができます。しかし、先行指標はあくまで予測でしかありません。最終的な成果は遅行指標を見ることによって正しく評価する必要があります。この先行指標を見ながら改善を行い遅行指標で確認するというサイクルを回すことで早く確実に改善を実施することができるようになります。\n冒頭のSaaSの例で具体的に考えてみましょう。まず遅行指標である離脱率を見て「契約から3ヶ月以内の離脱が多い」という確実な課題を見つけます。次にその原因を遡り、たとえば「オンボーディングで特定機能を使ったユーザは定着しやすい」という仮説を立て「初週の機能利用率」を先行指標として設定します。あとはオンボーディング施策を打ちながら、この先行指標が日次・週次でどう動くかを見ながら施策を打ち、数ヶ月後に離脱率という遅行指標で本当に効果があったかを答え合わせします。先行指標で素早く回し遅行指標で確かめるというのがこのサイクルのポイントです。\n先行指標は将来の成果を予測する道標、遅行指標は過去の成果を評価する物差しです。この2つを組み合わせて初めて早く・確実に改善を進めることができるのです。\n","permalink":"https://kenjiusui.github.io/blog/posts/biz/025_%E5%85%88%E8%A1%8C%E6%8C%87%E6%A8%99%E3%81%A8%E9%81%85%E8%A1%8C%E6%8C%87%E6%A8%99%E3%82%92%E7%B5%84%E3%81%BF%E5%90%88%E3%82%8F%E3%81%9B%E3%81%A6%E6%97%A9%E3%81%8F%E3%81%A6%E7%A2%BA%E5%AE%9F%E3%81%AA%E6%94%B9%E5%96%84%E6%B4%BB%E5%8B%95%E3%82%92%E9%80%B2%E3%82%81%E3%82%88%E3%81%86/","summary":"\u003cblockquote\u003e\n\u003cp\u003e本記事はウェブメディア「Modern Times」へ2023~2024年に寄稿したものを同メディアの閉鎖に伴い加筆・修正のうえ再掲したものです。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch1 id=\"先行指標と遅行指標\"\u003e先行指標と遅行指標\u003c/h1\u003e\n\u003cp\u003eデータ分析の現場ではさまざまな指標が使われていますが、その指標が事象に対して先んじた数値なのか、それとも後から結果を説明している指標なのか、という違いは重要です。前者は先行指標、後者は遅行指標と呼ばれます。\u003c/p\u003e\n\u003cp\u003e先行指標と遅行指標にはどのようなものがあるでしょうか？例えば、あなたがSaaSのような月額課金サービスを提供しており将来のユーザ数を知りたいとしましょう。この数値に影響を与える指標はたくさんありますが、そのなかでも獲得しているリードの数は先行指標になります。一方で顧客の離脱率は遅行指標です。\u003c/p\u003e\n\u003cp\u003e先行指標は現在の活動のうち将来に影響を与える要因を数値にしたもので、これから起きうる事象を推測するために使えます。たとえばリード数は将来ユーザになる見込み顧客の数なのでリード数に課金率を掛けることで獲得顧客数を見積もることができます。\u003c/p\u003e\n\u003cp\u003e遅行指標は過去の成果を測定した指標であり既に起きたことを示す数値です。結果を表す指標なのでサービスの成功や失敗を評価するのに役立ちます。たとえば顧客の離脱率は既にサービスから離れてしまった顧客の割合です。これは結果そのものでありサービスの性能を明確に示します。\u003c/p\u003e\n\u003ch1 id=\"先行指標のもつ課題\"\u003e先行指標のもつ課題\u003c/h1\u003e\n\u003cp\u003eでは、先行指標と遅行指標のどちらが有用な指標でしょうか？同じことがわかるならば先にわかるほうが役に立つことは間違いありません。サービスから離脱した顧客の数がわかってもその顧客へ対策することは難しいですが、サービスを離脱しそうな顧客の数がわかれば先んじて対策を打つことができます。ですが実際のところそんな簡単にはうまくいきません。先行指標は有用ですが遅行指標と比べたときにいくつかの弱点があるのです。\u003c/p\u003e\n\u003cp\u003e先行指標がもつ弱点の1つは先行指標を決めることが簡単ではないということです。遅行指標はいわば結果なので直感的に決めることができますが先行指標はそこからカスタマージャーニーを遡ったりサービス上の行動を深堀りするなど調査が必要になります。ビジネスはさまざまな要因が同時に影響し合うため有用な先行指標を特定することは簡単ではありません。特にサービスを立ち上げた初期はデータが不足しているためどの指標が先行指標たりうるのかわからないことも少なくありません。\u003c/p\u003e\n\u003cp\u003e2つ目の問題は、先行指標には不確実性が伴うことです。遅行指標は結果そのものなので将来予測という意味での不確実性はありません。離脱率は離脱という事実の集計値であり、そこに「これからどうなるか」という曖昧さはありません。一方、先行指標は現時点の状態から将来の値を推測するものなのでどれだけ精度を上げても予測が外れる可能性は残ります。現在の見込み顧客数から将来の獲得顧客数をある程度は予測できますが、実際にその値になるかどうかはやってみないとわかりません。自分たちが知らないところで問題が起きて推測値より大きく下がるかもしれませんし、そうでなくても様々な要因で上下にブレが発生することは容易に想像できるでしょう。\u003c/p\u003e\n\u003ch1 id=\"遅行指標の有用性\"\u003e遅行指標の有用性\u003c/h1\u003e\n\u003cp\u003eこのように先行指標には課題がいくつかありますが、一方で、遅行指標にも問題はあります。遅行指標は既に起きてしまったことから集計された値ですので、その問題そのものを解決することはできません。たとえば離脱率を計測しても既に止めてしまったユーザそのものを復帰させることは極めて難しいでしょう。\u003c/p\u003e\n\u003cp\u003e遅行指標は結果そのものであり確実な指標になります。そのため問題を特定する旅の出発点として有用でしょう。先行指標から課題を探すには先行指標がもつ不確実性に目を向ける必要があります。その指標がもつリスクを理解しなければ誤った分析をしてしまう可能性があります。それに比べて遅行指標は明地に足のついた指標で何を示しているのか明確です。そのため遅行指標を起点に課題を探すことで空回りを減らし、結果として早く改善サイクルを回すことが可能になります。\u003c/p\u003e\n\u003cp\u003e立ち上げたばかりでデータが少ないサービスでは先行指標を探すことが困難というのは先に述べたとおりです。さらに、自分たちのサービスの価値や課題に対する知見が溜まっていない状態で課題を探すのは難しいものです。それよりは、まず遅行指標から自分たちの明らかな課題を解決し顧客を理解しながら徐々に先行指標を探索していくとよいでしょう。\u003c/p\u003e\n\u003ch1 id=\"先行指標と遅行指標の特徴を活かす\"\u003e先行指標と遅行指標の特徴を活かす\u003c/h1\u003e\n\u003cp\u003eKPIはさまざまな側面から見ることが重要です。先行指標という不確実性をもった早期発見と遅行指標という遅れて届く確実な報告、このどちらもが必要になります。どちらか片方ではなく両方を上手く組み合わせることで自分たちの意思決定をより良いものにすることができます。\u003c/p\u003e\n\u003cp\u003e自分たちの細かいアクションの効果は先行指標が敏感に反応するため便利でしょう。施策の効果が遅行指標に現れるまで待つ必要がなく次々と手を打つことができます。しかし、先行指標はあくまで予測でしかありません。最終的な成果は遅行指標を見ることによって正しく評価する必要があります。この先行指標を見ながら改善を行い遅行指標で確認するというサイクルを回すことで早く確実に改善を実施することができるようになります。\u003c/p\u003e\n\u003cp\u003e冒頭のSaaSの例で具体的に考えてみましょう。まず遅行指標である離脱率を見て「契約から3ヶ月以内の離脱が多い」という確実な課題を見つけます。次にその原因を遡り、たとえば「オンボーディングで特定機能を使ったユーザは定着しやすい」という仮説を立て「初週の機能利用率」を先行指標として設定します。あとはオンボーディング施策を打ちながら、この先行指標が日次・週次でどう動くかを見ながら施策を打ち、数ヶ月後に離脱率という遅行指標で本当に効果があったかを答え合わせします。先行指標で素早く回し遅行指標で確かめるというのがこのサイクルのポイントです。\u003c/p\u003e\n\u003cp\u003e先行指標は将来の成果を予測する道標、遅行指標は過去の成果を評価する物差しです。この2つを組み合わせて初めて早く・確実に改善を進めることができるのです。\u003c/p\u003e","title":"先行指標と遅行指標を組み合わせて早くて確実な改善活動を進めよう"},{"content":" 本記事はウェブメディア「Modern Times」へ2023~2024年に寄稿したものを同メディアの閉鎖に伴い加筆・修正のうえ再掲したものです。\n定量的な評価が野心的な目標を阻害するという誤解 近年、ビジネスや組織の世界では定量的な目標管理が重要視されています。組織全体が一体となり戦略的方向性を確保しながら成果を最大化するためには明確な目標設定とそれに伴う定量的な測定が両方が必要だからです。\n一方で、定量的な評価に対する誤解も少なくありません。「定量的な評価は野心的な目標の策定を妨げる」「数値で表現できる目標しか設定できない」「定性的な目標は定性的にしか評価できない」といったものです。これらは典型的な誤解で、実際には野心的で定性的な目標を掲げながら達成度を定量的な指標で評価することは十分に可能です。\nこのような組み合わせをうまく組み合わせたのがOKRと呼ばれるフレームワークです。本記事ではOKRとKPIの関係を説明しながら野心的な目標を定量的に評価する方法を解説します。\nOKRの概要と特徴 まずはOKRについて簡単に解説しましょう。OKRとはObjectives and Key Resultsの略称で組織やチームが目標に対する成果管理を効果的におこなうためのフレームワークです。このフレームワークは組織の方向性を明確に示し目標に向かってチームが一体となって動くためのツールになります。\nObjectives（目標）は組織やチームが達成したい具体的な目標や方向性を示します。これらの目標はビジョンや目的を示しチームメンバーに組織の方向性とその意義を明らかにします。基本的にはこのままだと達成が無理だろう、というくらいのストレッチした目標を設定します。\nKey Results（成果指標）はその目標の達成を評価するマイルストーンです。Key Resultsは目標達成の進捗状況や成功度を測定するための指標であり基本的に数値によって表現されます。これらの成果指標は目標達成度を客観的に評価し、チームが目標に向かって前進するための進捗度を定量的に把握することができます。\nOKRは組織やチームの目標を明確にし透明性とフォーカスを高めることでチームメンバーが共通の目標に向かって協力するための枠組みです。70%も達成できれば成功といえるようなストレッチゴールを設定することで、野心的な目標を掲げながら達成度を客観的かつ定量的なマイルストーンによって評価できます。このように野心的な目標と定量的な評価を組み合わせたものがOKRです。\nお互いに補い合うOKRとKPI 次はOKRとKPIの関係についてかんがえてみましょう。少なくない人たちがOKRとKPIについて「OKRを導入するためにKPIは必要ない」とか逆に「KPIがあるならOKRはいらない」とか「OKRは難しいからKPIがあれば十分」だという人もいます。このような認識はあまり正しいとはいえません。OKRとKPIは組織と目標の管理についてお互いに別の存在でありながらお互いに補完しあう存在です。\nOKRは野心的な目標の設定とそれに対するマイルストーンを示す枠組みです。Key Resultsはあくまでも目標に対する進捗を示す期間限定の目標値です。そのため、プロジェクト単位や四半期といった区切りごとに設定し直されます。この仕組みはチームの向き先を揃え評価軸をクリアにすることで集中力を高めます。\n一方でKPIはサービスのパフォーマンスを評価する総合的な指標の集まりです。自分たちのサービスの現状を評価するために組織が継続的に監視すべきいわば健康診断です。目標へのマイルストーンというよりは現在がどのような状態なのか確認するために使うという向きが強いでしょう。\n同じ数値を扱っていてもOKRのKey Resultsは前に進むための「狙い」であり、KPIは健全さを保つための「定点観測」という役割の違いがあります。この役割の違いがあるからこそ両者は相互補完的に機能するものなのです。\nOKRとKPIを連携させる手順 では、OKRとKPIを使った仕組みを構築しようとしたとき両者は自然と統合するのでしょうか？そんなことはありません。お互いの特徴を考慮したうえで上手くすり合わせることが不可欠です。\nOKRとKPIどちらから手をつけるべきでしょうか？まずはKPIからスタートしましょう。自分たちの組織やビジネスにおいて把握するべき重要な指標を見つける必要があるからです。どんな指標が自分たちにとって重要でありアクションを生み出すことができるのか知らなければOKRに利用することもできません。\nKPIが整理されてきたら次は組織やチームで長期的な目標をOKRのフレームワークで検討します。目標は具体的で野心的なものであるべきであり組織全体が共有する方向性を示すものとしましょう。そして、この目標を達成を示すKey ResultsとしてKPIを中心に議論し選択します。\nKey Resultsの選定には目標との関連性や測定可能性、具体性などを考慮しながら目標達成を示すための指標であることも重視されます。KPIを分解したり、その周辺の指標をピックアップすることもあります。\nさらに組織やチームは定期的なレビューや進捗報告をとおしてOKRとKPIの連携を確認し調整をおこないます。OKRもKPIも一度作って終わりではなく継続的に改善をする必要があります。特にOKRは設定したもののKey Resultsがマッチしていなかったということはよくあります。レビューや報告の際に得られたフィードバックや洞察を活用し改善していきましょう。\nこのようにしてOKRとKPIを統合することでOKRによる定性的な目標と定量的なマイルストーン、そしてKPIという総合的な定量評価が協働するようになります。組織やチームは目標を達成するための組織の方向性と定量指標を通した効果的なマネジメントが可能になるのです。\nケーススタディをかんがえてみる それでは、具体的にOKRとKPIをどのようにして連携させればよいのかWeb広告運用の組織を元に簡単な例をかんがえてみましょう。Web広告運用をするのであれば購買へ繋がったユーザーの流入経路であったりセグメントごとのインプレッション数、コンバージョン率、広告のコストなどの数値が重要な指標であることは明らかでしょう。つまり、これらの指標がWeb広告運用におけるKPIとなります。\nこの状態から新しいキャンペーンをおこなうとしたらどのようなOKRを立てるべきでしょうか？たとえばObjectiveとして「新しいキャンペーンを成功させる」とおいてみましょう。このときKey Resultsとして「キャンペーン広告のインプレッション数を他広告の150%に向上させる」「キャンペーン広告のCTRを他広告の120%に向上させる」「キャンペーン経由のROASを2.5以上にする」といったものがかんがえられます。これらはどれもKPIとして使っている指標に定量的な目標値を設定したものです。これはObjectiveのKey ResultsをみながらKPIも監視している状態になります。\nここで注意したいのは、同じ「インプレッション数」という指標でも、Key Resultsとして使うときとKPIとして使うときでは見方が変わるという点です。Key Resultsの「他広告の150%」はキャンペーン期間中に狙う野心的な目標値であり、ストレッチゴールとして設定するなら70%程度の達成でも成功とみなせます。つまり未達を前提に高く掲げる数値です。一方で、KPIとしてのインプレッション数は「ふだんの水準から大きく落ち込んでいないか」や「キャンペーンによってどれくらい変化したのか？」を継続的に監視するための指標であり達成・未達という発想では捉えません。同じ指標でもマイルストーンとして捉えるKey Resultsと健全性を定点観測するKPIと2つの側面があるわけです。\nこのようにして、キャンペーンの成功を目標にKey Resultsの進捗を追いかけることでOKRの進捗を定量的に把握することができました。同時に、インプレッション数やCTR、ROASなどの指標はふだんからKPIとして追いかけているものですからチーム全体の健全性も管理することができています。もしOKRだけ見ていると集中こそできますが目標以外の側面で組織を管理することができず、いつのまにかサービスは不健全な状態に陥っているかもしれません。逆にKPIだけでは野心的な目標とその進捗を管理することは難しいでしょう。両方を協働させるように設定することで野心的な目標へのフォーカスと組織の管理を上手くおこなうことができるのです。\nOKRとKPIは組織やチームが目標を達成するために欠かせない要素です。両者は異なる側面を補完し合い組織やチームが目標に向かって効果的に進むための道しるべとなります。OKRとKPIを連携させることで共通の目標へ集中しながら同時に組織全体の健全性を保つことができます。そのためには両者が相互に補完しているということを理解し活用することが重要なのです。\n","permalink":"https://kenjiusui.github.io/blog/posts/biz/024_okr%E3%81%A8kpi%E3%81%AE%E9%80%A3%E6%90%BA/","summary":"\u003cblockquote\u003e\n\u003cp\u003e本記事はウェブメディア「Modern Times」へ2023~2024年に寄稿したものを同メディアの閉鎖に伴い加筆・修正のうえ再掲したものです。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch1 id=\"定量的な評価が野心的な目標を阻害するという誤解\"\u003e定量的な評価が野心的な目標を阻害するという誤解\u003c/h1\u003e\n\u003cp\u003e近年、ビジネスや組織の世界では定量的な目標管理が重要視されています。組織全体が一体となり戦略的方向性を確保しながら成果を最大化するためには明確な目標設定とそれに伴う定量的な測定が両方が必要だからです。\u003c/p\u003e\n\u003cp\u003e一方で、定量的な評価に対する誤解も少なくありません。「定量的な評価は野心的な目標の策定を妨げる」「数値で表現できる目標しか設定できない」「定性的な目標は定性的にしか評価できない」といったものです。これらは典型的な誤解で、実際には野心的で定性的な目標を掲げながら達成度を定量的な指標で評価することは十分に可能です。\u003c/p\u003e\n\u003cp\u003eこのような組み合わせをうまく組み合わせたのがOKRと呼ばれるフレームワークです。本記事ではOKRとKPIの関係を説明しながら野心的な目標を定量的に評価する方法を解説します。\u003c/p\u003e\n\u003ch1 id=\"okrの概要と特徴\"\u003eOKRの概要と特徴\u003c/h1\u003e\n\u003cp\u003eまずはOKRについて簡単に解説しましょう。OKRとはObjectives and Key Resultsの略称で組織やチームが目標に対する成果管理を効果的におこなうためのフレームワークです。このフレームワークは組織の方向性を明確に示し目標に向かってチームが一体となって動くためのツールになります。\u003c/p\u003e\n\u003cp\u003eObjectives（目標）は組織やチームが達成したい具体的な目標や方向性を示します。これらの目標はビジョンや目的を示しチームメンバーに組織の方向性とその意義を明らかにします。基本的にはこのままだと達成が無理だろう、というくらいのストレッチした目標を設定します。\u003c/p\u003e\n\u003cp\u003eKey Results（成果指標）はその目標の達成を評価するマイルストーンです。Key Resultsは目標達成の進捗状況や成功度を測定するための指標であり基本的に数値によって表現されます。これらの成果指標は目標達成度を客観的に評価し、チームが目標に向かって前進するための進捗度を定量的に把握することができます。\u003c/p\u003e\n\u003cp\u003eOKRは組織やチームの目標を明確にし透明性とフォーカスを高めることでチームメンバーが共通の目標に向かって協力するための枠組みです。70%も達成できれば成功といえるようなストレッチゴールを設定することで、野心的な目標を掲げながら達成度を客観的かつ定量的なマイルストーンによって評価できます。このように野心的な目標と定量的な評価を組み合わせたものがOKRです。\u003c/p\u003e\n\u003ch1 id=\"お互いに補い合うokrとkpi\"\u003eお互いに補い合うOKRとKPI\u003c/h1\u003e\n\u003cp\u003e次はOKRとKPIの関係についてかんがえてみましょう。少なくない人たちがOKRとKPIについて「OKRを導入するためにKPIは必要ない」とか逆に「KPIがあるならOKRはいらない」とか「OKRは難しいからKPIがあれば十分」だという人もいます。このような認識はあまり正しいとはいえません。OKRとKPIは組織と目標の管理についてお互いに別の存在でありながらお互いに補完しあう存在です。\u003c/p\u003e\n\u003cp\u003eOKRは野心的な目標の設定とそれに対するマイルストーンを示す枠組みです。Key Resultsはあくまでも目標に対する進捗を示す期間限定の目標値です。そのため、プロジェクト単位や四半期といった区切りごとに設定し直されます。この仕組みはチームの向き先を揃え評価軸をクリアにすることで集中力を高めます。\u003c/p\u003e\n\u003cp\u003e一方でKPIはサービスのパフォーマンスを評価する総合的な指標の集まりです。自分たちのサービスの現状を評価するために組織が継続的に監視すべきいわば健康診断です。目標へのマイルストーンというよりは現在がどのような状態なのか確認するために使うという向きが強いでしょう。\u003c/p\u003e\n\u003cp\u003e同じ数値を扱っていてもOKRのKey Resultsは前に進むための「狙い」であり、KPIは健全さを保つための「定点観測」という役割の違いがあります。この役割の違いがあるからこそ両者は相互補完的に機能するものなのです。\u003c/p\u003e\n\u003ch1 id=\"okrとkpiを連携させる手順\"\u003eOKRとKPIを連携させる手順\u003c/h1\u003e\n\u003cp\u003eでは、OKRとKPIを使った仕組みを構築しようとしたとき両者は自然と統合するのでしょうか？そんなことはありません。お互いの特徴を考慮したうえで上手くすり合わせることが不可欠です。\u003c/p\u003e\n\u003cp\u003eOKRとKPIどちらから手をつけるべきでしょうか？まずはKPIからスタートしましょう。自分たちの組織やビジネスにおいて把握するべき重要な指標を見つける必要があるからです。どんな指標が自分たちにとって重要でありアクションを生み出すことができるのか知らなければOKRに利用することもできません。\u003c/p\u003e\n\u003cp\u003eKPIが整理されてきたら次は組織やチームで長期的な目標をOKRのフレームワークで検討します。目標は具体的で野心的なものであるべきであり組織全体が共有する方向性を示すものとしましょう。そして、この目標を達成を示すKey ResultsとしてKPIを中心に議論し選択します。\u003c/p\u003e\n\u003cp\u003eKey Resultsの選定には目標との関連性や測定可能性、具体性などを考慮しながら目標達成を示すための指標であることも重視されます。KPIを分解したり、その周辺の指標をピックアップすることもあります。\u003c/p\u003e\n\u003cp\u003eさらに組織やチームは定期的なレビューや進捗報告をとおしてOKRとKPIの連携を確認し調整をおこないます。OKRもKPIも一度作って終わりではなく継続的に改善をする必要があります。特にOKRは設定したもののKey Resultsがマッチしていなかったということはよくあります。レビューや報告の際に得られたフィードバックや洞察を活用し改善していきましょう。\u003c/p\u003e\n\u003cp\u003eこのようにしてOKRとKPIを統合することでOKRによる定性的な目標と定量的なマイルストーン、そしてKPIという総合的な定量評価が協働するようになります。組織やチームは目標を達成するための組織の方向性と定量指標を通した効果的なマネジメントが可能になるのです。\u003c/p\u003e\n\u003ch1 id=\"ケーススタディをかんがえてみる\"\u003eケーススタディをかんがえてみる\u003c/h1\u003e\n\u003cp\u003eそれでは、具体的にOKRとKPIをどのようにして連携させればよいのかWeb広告運用の組織を元に簡単な例をかんがえてみましょう。Web広告運用をするのであれば購買へ繋がったユーザーの流入経路であったりセグメントごとのインプレッション数、コンバージョン率、広告のコストなどの数値が重要な指標であることは明らかでしょう。つまり、これらの指標がWeb広告運用におけるKPIとなります。\u003c/p\u003e\n\u003cp\u003eこの状態から新しいキャンペーンをおこなうとしたらどのようなOKRを立てるべきでしょうか？たとえばObjectiveとして「新しいキャンペーンを成功させる」とおいてみましょう。このときKey Resultsとして「キャンペーン広告のインプレッション数を他広告の150%に向上させる」「キャンペーン広告のCTRを他広告の120%に向上させる」「キャンペーン経由のROASを2.5以上にする」といったものがかんがえられます。これらはどれもKPIとして使っている指標に定量的な目標値を設定したものです。これはObjectiveのKey ResultsをみながらKPIも監視している状態になります。\u003c/p\u003e\n\u003cp\u003eここで注意したいのは、同じ「インプレッション数」という指標でも、Key Resultsとして使うときとKPIとして使うときでは見方が変わるという点です。Key Resultsの「他広告の150%」はキャンペーン期間中に狙う野心的な目標値であり、ストレッチゴールとして設定するなら70%程度の達成でも成功とみなせます。つまり未達を前提に高く掲げる数値です。一方で、KPIとしてのインプレッション数は「ふだんの水準から大きく落ち込んでいないか」や「キャンペーンによってどれくらい変化したのか？」を継続的に監視するための指標であり達成・未達という発想では捉えません。同じ指標でもマイルストーンとして捉えるKey Resultsと健全性を定点観測するKPIと2つの側面があるわけです。\u003c/p\u003e\n\u003cp\u003eこのようにして、キャンペーンの成功を目標にKey Resultsの進捗を追いかけることでOKRの進捗を定量的に把握することができました。同時に、インプレッション数やCTR、ROASなどの指標はふだんからKPIとして追いかけているものですからチーム全体の健全性も管理することができています。もしOKRだけ見ていると集中こそできますが目標以外の側面で組織を管理することができず、いつのまにかサービスは不健全な状態に陥っているかもしれません。逆にKPIだけでは野心的な目標とその進捗を管理することは難しいでしょう。両方を協働させるように設定することで野心的な目標へのフォーカスと組織の管理を上手くおこなうことができるのです。\u003c/p\u003e\n\u003cp\u003eOKRとKPIは組織やチームが目標を達成するために欠かせない要素です。両者は異なる側面を補完し合い組織やチームが目標に向かって効果的に進むための道しるべとなります。OKRとKPIを連携させることで共通の目標へ集中しながら同時に組織全体の健全性を保つことができます。そのためには両者が相互に補完しているということを理解し活用することが重要なのです。\u003c/p\u003e","title":"OKRとKPIの連携"},{"content":" 本記事はウェブメディア「Modern Times」へ2023~2024年に寄稿したものを同メディアの閉鎖に伴い加筆・修正のうえ再掲したものです。\nデータ分析はますます企業や組織において不可欠な要素となってきました。しかし、データをビジネスで活用するためには単なる数値や統計の分析だけではなく特定の業界や領域に対する深い理解が必要です。本記事ではデータ分析者が身につけるべきドメイン知識とはなにものなのか探っていきます。\nドメイン知識の無い分析は間違った意思決定を招く データ分析者のスキルの1つとしてドメイン知識が重要であることは多く言われていますが、そもそもなぜドメイン知識が必要になるのでしょうか？データ分析者が特定の業界や領域のドメイン知識を持つことが、データをただの数字の集まりでなく意味のある情報として扱うことができるようになるからです。\nビジネスにおいては、商品や市場の特性、法律、規制、商習慣、サプライチェーン、ビジネスモデル\u0026hellip;etc とデータ分析を行うにあたって考慮すべき事項は多くあります。ドメインに関する理解という下地が不足した分析は正しい結論が得られないどころか誤った意思決定を加速させてしまいます。\nなぜこのような状況が起きるのでしょうか？1つはドメイン知識の不足は課題を理解するうえで大きな障害となることにあります。分析の課題がどのような背景から発生し、どのような分析を行えば解決にたどり着けるのか把握するためにはその分野を理解している必要があります。\n2つはデータは常にドメインの商習慣などの影響を受けているにも関わらずそれを理解せずに分析した場合は間違った解析結果を生んでしまう点にあります。たとえば、ある月の売上が突出していたとき、それを単なる外れ値とみなして除外してしまうと分析を誤ることがあります。実際にはその業界では決算期に需要が集中するという商習慣があり、その山こそが事業を理解するうえで最も重要なシグナルだった、というような事態は珍しくないでしょう。ドメインを知らなければ「意味のある偏り」を「ノイズ」として捨ててしまいかねません。\nデータ分析における課題の設計・データの処理・データの解釈というすべてのステップでドメイン知識は影響してくるということです。\n3種類のドメイン知識 それではドメイン知識にはどのようなものがあるのでしょうか。たとえば法律や規制、ビジネスモデル、プロダクトの知識…などなど個別に挙げれば枚挙にいとまがありません。ここでは3つのジャンルにわけて整理します。\n1つ目は業界の知識です。これは特定の企業によらず、その業界全体に共通する外部環境に関する知識を指します。法律や規制、商習慣のような知識がこれにあたります。医療や金融のように法律や規制が厳しい業界であれば非常に重要になります。そうでなくても商習慣のような知識は課題を理解するうえで有用です。特に意思決定者とスムーズなコミュニケーションをとるために背景となる業界の知識が求められます。\n2つ目は業務の知識です。これは特定の職種や現場のオペレーションがどのように回っているか、どのような分析が求められるのかという点に関する知識を指します。業界をまたいで共通する点が多い点が1つ目の業界の知識との違いです。たとえばWeb広告の分析を行うならWeb広告運用の知識が必要です。営業なら営業、カスタマーサポートならカスタマーサポートの知識が求められます。具体的にデータを分析して現場のマネージャーとコミュニケーションして業務改善をしていくならば業務理解が重要です。\n特に分析者の目線でいうならば、データドリブンが広まった現代では業務ごとによく行われている分析やKPIがありますので、そのような定番のやり方を知っておくと有用です。教科書的なテクニックは書籍や勉強会などで共有されているものも多くあり学ぶことが可能です。\n3つ目は自分たちのサービスの知識です。これは自社の事業に固有の外からは見えない内部の知識を指します。自社のビジネスモデルやサプライチェーン、システムの設計などがあたります。このような知識は自分たちのサービスを改善するときに強く求められます。プロダクトマネジメントにデータを活用するならば必須となるでしょう。その会社の事業特有の知識となるため一般化しにくく社内での経験値が必要です。\n実際にデータを分析するにはデータがどこからどのように作られているのか知る必要があります。そのためには自分たちのサービスの仕組みを知らなくてはいけません。これはデータベースの構成のような限られた話ではありません。誰がどのようにどのタイミングでデータを入力するのか、そのデータが自分たちの分析環境までどのような処理がされているのか把握するということ観点も必要です。\nビジネスにおいては、業界の知識、業務の知識、サービスの知識の3つのドメイン知識を必要に応じてバランスよく学ぶことが求められます。実際の分析を考えると、どれか1つだけあればよいというものではありません。たとえば、データの偏りはシステム・業務・業界どの要因でも発生しうるものです。妥当なデータ分析を行うためには幅広く必要な知識を身に着けておく必要があります。もちろん、それらをすべてを完全に理解することは不可能ですが、必要に応じて理解を深めていくことが求められます。\nどのようにして学んでいけばよいのか？ ドメイン知識について大きく3つに分類して整理しましたが、それでは実際にドメイン知識を学ぶためにはどのようにすればよいのでしょうか？最も基本的な学び方は専門家に相談することです。専門家というのは同じドメインの分析者に限りません。その分野で仕事をしているさまざまな方から学ぶことがたくさんあります。\n業界の知識が必要であれば分野のスペシャリストに相談すれば良いでしょう。どのような場面でも分析対象のスペシャリストがいるはずですので、知っておくべき基本的な知識やそれを学ぶための方法を尋ねてみましょう。業界でよく読まれている書籍などを教えてくれるはずです。業務であれば部門のマネージャに相談すればチームの研修資料があるかもしれません。システムの知識であれば現場の開発者が参照しているwikiなどのナレッジが参考になるでしょう。\n効率的に学ぶにはすべてを学ぼうとしないことが重要です。まずは目の前の分析の意思決定に直結する知識から優先的に押さえ関係の薄い領域は後回しにする。限られた時間のなかでは優先順位づけそのものがスキルになります。質問をするときは分析と紐づけると学びが多いです。「この業界について教えてください」ではなく「このデータでこの月だけ値が跳ねているのは何か理由がありますか」と手元のデータに紐づけて聞くことで専門家から引き出せる情報の質が大きく変わります。そして、なによりも学んだことをドキュメントやデータ定義として残し次の分析や他のメンバーが再利用できる資産にしていきましょう。\n独学で抱え込むのではなく専門家を起点に学んでいくことがドメイン知識を得るうえでもっとも近道です。データ分析者は各分野のスペシャリストであることは多くありません。全く知見がないという状況もあるでしょう。そのようなときに無理に独学で知識を得ようとするのではなく素直に専門家を頼るべきです。\n「わからないことは専門家に相談する」というとなんだか単純で当たり前のことをいっているように見えるかもしれません。ですが、分析の対象がコロコロと変わることの多いデータ分析者という仕事をうまく回すには、その当たり前をうまくやるというキャッチアップの技術も必要です。\n冒頭で述べたとおり、ドメイン知識は課題の設計・データの処理・解釈というすべての段階に影響します。だからこそ、その知識をいかに速く・的確に身につけるかというキャッチアップの技術は分析スキルそのものと同じくらい高い価値のアウトプットを出すために重要なのです。\n","permalink":"https://kenjiusui.github.io/blog/posts/biz/023_%E3%81%AA%E3%81%9C%E3%83%87%E3%83%BC%E3%82%BF%E5%88%86%E6%9E%90%E3%81%AB%E3%81%AF%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E7%9F%A5%E8%AD%98%E3%81%8C%E5%BF%85%E8%A6%81%E3%81%AA%E3%81%AE%E3%81%8B/","summary":"\u003cblockquote\u003e\n\u003cp\u003e本記事はウェブメディア「Modern Times」へ2023~2024年に寄稿したものを同メディアの閉鎖に伴い加筆・修正のうえ再掲したものです。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eデータ分析はますます企業や組織において不可欠な要素となってきました。しかし、データをビジネスで活用するためには単なる数値や統計の分析だけではなく特定の業界や領域に対する深い理解が必要です。本記事ではデータ分析者が身につけるべきドメイン知識とはなにものなのか探っていきます。\u003c/p\u003e\n\u003ch1 id=\"ドメイン知識の無い分析は間違った意思決定を招く\"\u003eドメイン知識の無い分析は間違った意思決定を招く\u003c/h1\u003e\n\u003cp\u003eデータ分析者のスキルの1つとしてドメイン知識が重要であることは多く言われていますが、そもそもなぜドメイン知識が必要になるのでしょうか？データ分析者が特定の業界や領域のドメイン知識を持つことが、データをただの数字の集まりでなく意味のある情報として扱うことができるようになるからです。\u003c/p\u003e\n\u003cp\u003eビジネスにおいては、商品や市場の特性、法律、規制、商習慣、サプライチェーン、ビジネスモデル\u0026hellip;etc とデータ分析を行うにあたって考慮すべき事項は多くあります。ドメインに関する理解という下地が不足した分析は正しい結論が得られないどころか誤った意思決定を加速させてしまいます。\u003c/p\u003e\n\u003cp\u003eなぜこのような状況が起きるのでしょうか？1つはドメイン知識の不足は課題を理解するうえで大きな障害となることにあります。分析の課題がどのような背景から発生し、どのような分析を行えば解決にたどり着けるのか把握するためにはその分野を理解している必要があります。\u003c/p\u003e\n\u003cp\u003e2つはデータは常にドメインの商習慣などの影響を受けているにも関わらずそれを理解せずに分析した場合は間違った解析結果を生んでしまう点にあります。たとえば、ある月の売上が突出していたとき、それを単なる外れ値とみなして除外してしまうと分析を誤ることがあります。実際にはその業界では決算期に需要が集中するという商習慣があり、その山こそが事業を理解するうえで最も重要なシグナルだった、というような事態は珍しくないでしょう。ドメインを知らなければ「意味のある偏り」を「ノイズ」として捨ててしまいかねません。\u003c/p\u003e\n\u003cp\u003eデータ分析における課題の設計・データの処理・データの解釈というすべてのステップでドメイン知識は影響してくるということです。\u003c/p\u003e\n\u003ch1 id=\"3種類のドメイン知識\"\u003e3種類のドメイン知識\u003c/h1\u003e\n\u003cp\u003eそれではドメイン知識にはどのようなものがあるのでしょうか。たとえば法律や規制、ビジネスモデル、プロダクトの知識…などなど個別に挙げれば枚挙にいとまがありません。ここでは3つのジャンルにわけて整理します。\u003c/p\u003e\n\u003cp\u003e1つ目は業界の知識です。これは特定の企業によらず、その業界全体に共通する外部環境に関する知識を指します。法律や規制、商習慣のような知識がこれにあたります。医療や金融のように法律や規制が厳しい業界であれば非常に重要になります。そうでなくても商習慣のような知識は課題を理解するうえで有用です。特に意思決定者とスムーズなコミュニケーションをとるために背景となる業界の知識が求められます。\u003c/p\u003e\n\u003cp\u003e2つ目は業務の知識です。これは特定の職種や現場のオペレーションがどのように回っているか、どのような分析が求められるのかという点に関する知識を指します。業界をまたいで共通する点が多い点が1つ目の業界の知識との違いです。たとえばWeb広告の分析を行うならWeb広告運用の知識が必要です。営業なら営業、カスタマーサポートならカスタマーサポートの知識が求められます。具体的にデータを分析して現場のマネージャーとコミュニケーションして業務改善をしていくならば業務理解が重要です。\u003c/p\u003e\n\u003cp\u003e特に分析者の目線でいうならば、データドリブンが広まった現代では業務ごとによく行われている分析やKPIがありますので、そのような定番のやり方を知っておくと有用です。教科書的なテクニックは書籍や勉強会などで共有されているものも多くあり学ぶことが可能です。\u003c/p\u003e\n\u003cp\u003e3つ目は自分たちのサービスの知識です。これは自社の事業に固有の外からは見えない内部の知識を指します。自社のビジネスモデルやサプライチェーン、システムの設計などがあたります。このような知識は自分たちのサービスを改善するときに強く求められます。プロダクトマネジメントにデータを活用するならば必須となるでしょう。その会社の事業特有の知識となるため一般化しにくく社内での経験値が必要です。\u003c/p\u003e\n\u003cp\u003e実際にデータを分析するにはデータがどこからどのように作られているのか知る必要があります。そのためには自分たちのサービスの仕組みを知らなくてはいけません。これはデータベースの構成のような限られた話ではありません。誰がどのようにどのタイミングでデータを入力するのか、そのデータが自分たちの分析環境までどのような処理がされているのか把握するということ観点も必要です。\u003c/p\u003e\n\u003cp\u003eビジネスにおいては、業界の知識、業務の知識、サービスの知識の3つのドメイン知識を必要に応じてバランスよく学ぶことが求められます。実際の分析を考えると、どれか1つだけあればよいというものではありません。たとえば、データの偏りはシステム・業務・業界どの要因でも発生しうるものです。妥当なデータ分析を行うためには幅広く必要な知識を身に着けておく必要があります。もちろん、それらをすべてを完全に理解することは不可能ですが、必要に応じて理解を深めていくことが求められます。\u003c/p\u003e\n\u003ch1 id=\"どのようにして学んでいけばよいのか\"\u003eどのようにして学んでいけばよいのか？\u003c/h1\u003e\n\u003cp\u003eドメイン知識について大きく3つに分類して整理しましたが、それでは実際にドメイン知識を学ぶためにはどのようにすればよいのでしょうか？最も基本的な学び方は専門家に相談することです。専門家というのは同じドメインの分析者に限りません。その分野で仕事をしているさまざまな方から学ぶことがたくさんあります。\u003c/p\u003e\n\u003cp\u003e業界の知識が必要であれば分野のスペシャリストに相談すれば良いでしょう。どのような場面でも分析対象のスペシャリストがいるはずですので、知っておくべき基本的な知識やそれを学ぶための方法を尋ねてみましょう。業界でよく読まれている書籍などを教えてくれるはずです。業務であれば部門のマネージャに相談すればチームの研修資料があるかもしれません。システムの知識であれば現場の開発者が参照しているwikiなどのナレッジが参考になるでしょう。\u003c/p\u003e\n\u003cp\u003e効率的に学ぶにはすべてを学ぼうとしないことが重要です。まずは目の前の分析の意思決定に直結する知識から優先的に押さえ関係の薄い領域は後回しにする。限られた時間のなかでは優先順位づけそのものがスキルになります。質問をするときは分析と紐づけると学びが多いです。「この業界について教えてください」ではなく「このデータでこの月だけ値が跳ねているのは何か理由がありますか」と手元のデータに紐づけて聞くことで専門家から引き出せる情報の質が大きく変わります。そして、なによりも学んだことをドキュメントやデータ定義として残し次の分析や他のメンバーが再利用できる資産にしていきましょう。\u003c/p\u003e\n\u003cp\u003e独学で抱え込むのではなく専門家を起点に学んでいくことがドメイン知識を得るうえでもっとも近道です。データ分析者は各分野のスペシャリストであることは多くありません。全く知見がないという状況もあるでしょう。そのようなときに無理に独学で知識を得ようとするのではなく素直に専門家を頼るべきです。\u003c/p\u003e\n\u003cp\u003e「わからないことは専門家に相談する」というとなんだか単純で当たり前のことをいっているように見えるかもしれません。ですが、分析の対象がコロコロと変わることの多いデータ分析者という仕事をうまく回すには、その当たり前をうまくやるというキャッチアップの技術も必要です。\u003c/p\u003e\n\u003cp\u003e冒頭で述べたとおり、ドメイン知識は課題の設計・データの処理・解釈というすべての段階に影響します。だからこそ、その知識をいかに速く・的確に身につけるかというキャッチアップの技術は分析スキルそのものと同じくらい高い価値のアウトプットを出すために重要なのです。\u003c/p\u003e","title":"なぜデータ分析にはドメイン知識が必要なのか？"},{"content":" 本記事はウェブメディア「Modern Times」へ2023~2024年に寄稿したものを同メディアの閉鎖に伴い加筆・修正のうえ再掲したものです。\nどのように指標を選べばよいのか 前回の記事ではデータドリブンになる良い指標について解説しました。良い指標とは学ぶことができる指標であり、行動を変える指標です。このような良い指標についてより深く解説していきます。\n学ぶことができる指標を考えるときなにから考えればよいでしょうか？実際のところ、まずは教科書的な指標からスタートするケースがほとんどだとおもいます。現代では多くの分野で定番とされるような指標が知られています。たとえば顧客の離脱率や顧客単価、広告のCTRやコンバージョンレート、NPS\u0026hellip;などはよく使われる指標です。これらの指標を起点に使うべきKPIを考えていきます。\nこれらの指標をそのままKPIにすることもあれば、分解して使うこともありますし、セグメントなどでスコープを狭めて使うこともあるでしょう。たとえばCTRはインプレッション数とクリック数に分解できるのでそれぞれ別に追いかけたほうがよい場合もあります。特定のユーザ属性でセグメントにわけることが有用なケースもありますね。\n他にも、重要な指標に関係がありそうな数値をKPIとして選ぶこともあります。問い合わせ満足度の改善では解決率や応答率を見ることがあるでしょう。機能の利用率や到達率などはサービスの改善で定番です。これらの指標もさらに分解したりセグメントで切り分けることもあります。\nいずれにせよ、指標は切り方を変えたり細かく具体的にするなどいくらでも作ることが可能です。\n気温をKPIにしても何も学べない 指標は作ろうと思えばいくらでも作ることができますが、どの指標が最も自分たちの今一番ほしい学びを与えてくれるのでしょうか？学ぶことができる指標の重要な条件は、その数値を改善したくてたまらない上に自分たちにその指標を改善できそうな仮説があることです。\nたとえばアイスの売上と気温に相関があると言われていますが、アイスを売りたいからといって気温をKPIにしても意味がないことはすぐにわかるでしょう。気温は私たちにコントロールできない変数であり、ただ受け入れることしかできません。自分たちのアクションで動かせない数字をいくら眺めても、そこからは何も学ぶことができないのです。\n顧客満足度をKPIにするのはどうでしょうか？顧客満足度はぜひ改善したい数字ですし、なんだか改善するアイディアもありそうです。これが、ユーザが100人のサービスであれば、たしかにアイディアから試行錯誤して数値を改善することは可能かもしれません。もしユーザが10万人のサービスだったらどうでしょう。アイディアがあったとして施策と数値を関連付けて改善サイクルを回すことができるでしょうか？なかなか難しそうですね。なにをやっても良かったのか悪かったのかぼんやりとしてしまいそうです。\nユーザが10万人のサービスでも特定のセグメントに絞り込めば対象となるユーザを減らすことはできます。顧客満足度を改善したいとして性別や居住地、年齢、行動などからスコープを小さくすることは可能です。そうして100人のユーザに絞り込むことで改善サイクルを回すことは可能になるでしょう。しかし、この場合は全体への影響が限定的になります。改善できるが影響は小さい、逆に全体を狙うと改善サイクルが回せない。このトレードオフは指標を選ぶとき重要な論点です。\nもちろん、これは極端な例になります。実際の現場ではこれほどわかりやすくありません。多くの指標は改善ができそうなできなさそうな…と曖昧なレベルであることがほとんどだとおもいます。では、その中から自分たちにとって有用な指標をどのように探せばよいのでしょうか？\n指標のバランス ちょうどよい指標を探すにあたって課題になるポイントは、同じ指標でも状況次第で良い指標にも悪い指標にもなりうるということです。あるときは妥当なKPIであっても次第にサービスの種類や規模、目標が変化することで学びを得ることのできない不適当な指標となります。\n指標を検討するときは対象となるユーザの規模や自分たちの施策の影響が及ぶ範囲から考えるとよいでしょう。数字から学ぶためには自分たちのアクションと指標が対応している必要があります。ユーザが増えれば特定のセグメントに対する施策が増えていきますし、その効果を見たいならばそのセグメントの数値に注目したほうがわかりやすいということです。\nサービスの立ち上げ期はアクティブユーザ率やChurn Rateのような定番のユーザ全体に係る抽象的な指標をKPIとして選ぶことが多いでしょう。このような指標はビジネスに直結する指標であり、最終的に改善したい指標となります。このフェーズではサービスの課題が多くアクションがユーザ全体に影響を与えることが多いため、これらの指標をそのまま使うことで多くのことを学ぶことができます。むしろ、ユーザが少ないので細かい指標を見ようとしてもノイズがひどくて知見を得ることが簡単ではありません。\n一方で、サービスが成熟してくると上記のような指標では学ぶことが難しくなります。これはユーザが増えれば増えるほど指標の変化が小さくなり施策による効果がわかりにくくなるためです。多様なユーザが増えればそのぶん施策を検討する幅も広がります。そのため、指標を分割したりセグメントを切ったりしてスコープを狭めた指標を大本のKPIの下位にぶらさげてツリーとして利用します。たとえば、特定の機能の利用率のような具体的なユーザの行動をChurn Rateの下位においたり、全体のコンバージョンレート改善に対して特定の流入経路やユーザの属性をセグメントとして絞り込んだ指標を参照するやり方は広く行われています。\n指標は分割したりスコープを狭めたりすれば理解しやすくコントロールしやすい数字にすることができますが、本来改善したい指標への影響が限定的になったり、本来改善したい指標と実際に追う指標の距離が離れて両者の因果が不確実になっていきます。このトレードオフに対してちょうどいいバランスの指標を探す必要があるのです。\n指標は常に模索するもの 抽象的な指標から始まり次第に具体的な指標を見るという流れはデータドリブンな組織だと自然に行われています。最初はChurn Rateや顧客満足度のような指標を追いかけたとして、次第にサービスが拡大し施策が具体的なターゲットへ移っていくため自然と指標も具体的なKPIが設定され改善活動を行うことになります。\nなにか素晴らしい指標を見つけたとして、それをずっと追いかけているだけではデータドリブンになることはできません。変化の激しい現代では市場やビジネスが変化し続けることが前提となります。そうなれば、当然、追いかける指標も改善されなければいけません。\nデータドリブンな組織はKPIから自分たちがなにか新しいことを学ぶことができているのか常に考えています。指標を使って改善サイクルを回すだけでなく良い指標を探して改善するサイクルを回すことがデータドリブンでは重要なのです。\n","permalink":"https://kenjiusui.github.io/blog/posts/biz/022_%E5%AD%A6%E3%81%B9%E3%82%8B%E6%8C%87%E6%A8%99%E3%82%92%E6%8E%A2%E3%81%9D%E3%81%86/","summary":"\u003cblockquote\u003e\n\u003cp\u003e本記事はウェブメディア「Modern Times」へ2023~2024年に寄稿したものを同メディアの閉鎖に伴い加筆・修正のうえ再掲したものです。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch1 id=\"どのように指標を選べばよいのか\"\u003eどのように指標を選べばよいのか\u003c/h1\u003e\n\u003cp\u003e前回の記事ではデータドリブンになる良い指標について解説しました。良い指標とは学ぶことができる指標であり、行動を変える指標です。このような良い指標についてより深く解説していきます。\u003c/p\u003e\n\u003cp\u003e学ぶことができる指標を考えるときなにから考えればよいでしょうか？実際のところ、まずは教科書的な指標からスタートするケースがほとんどだとおもいます。現代では多くの分野で定番とされるような指標が知られています。たとえば顧客の離脱率や顧客単価、広告のCTRやコンバージョンレート、NPS\u0026hellip;などはよく使われる指標です。これらの指標を起点に使うべきKPIを考えていきます。\u003c/p\u003e\n\u003cp\u003eこれらの指標をそのままKPIにすることもあれば、分解して使うこともありますし、セグメントなどでスコープを狭めて使うこともあるでしょう。たとえばCTRはインプレッション数とクリック数に分解できるのでそれぞれ別に追いかけたほうがよい場合もあります。特定のユーザ属性でセグメントにわけることが有用なケースもありますね。\u003c/p\u003e\n\u003cp\u003e他にも、重要な指標に関係がありそうな数値をKPIとして選ぶこともあります。問い合わせ満足度の改善では解決率や応答率を見ることがあるでしょう。機能の利用率や到達率などはサービスの改善で定番です。これらの指標もさらに分解したりセグメントで切り分けることもあります。\u003c/p\u003e\n\u003cp\u003eいずれにせよ、指標は切り方を変えたり細かく具体的にするなどいくらでも作ることが可能です。\u003c/p\u003e\n\u003ch1 id=\"気温をkpiにしても何も学べない\"\u003e気温をKPIにしても何も学べない\u003c/h1\u003e\n\u003cp\u003e指標は作ろうと思えばいくらでも作ることができますが、どの指標が最も自分たちの今一番ほしい学びを与えてくれるのでしょうか？学ぶことができる指標の重要な条件は、その数値を改善したくてたまらない上に自分たちにその指標を改善できそうな仮説があることです。\u003c/p\u003e\n\u003cp\u003eたとえばアイスの売上と気温に相関があると言われていますが、アイスを売りたいからといって気温をKPIにしても意味がないことはすぐにわかるでしょう。気温は私たちにコントロールできない変数であり、ただ受け入れることしかできません。自分たちのアクションで動かせない数字をいくら眺めても、そこからは何も学ぶことができないのです。\u003c/p\u003e\n\u003cp\u003e顧客満足度をKPIにするのはどうでしょうか？顧客満足度はぜひ改善したい数字ですし、なんだか改善するアイディアもありそうです。これが、ユーザが100人のサービスであれば、たしかにアイディアから試行錯誤して数値を改善することは可能かもしれません。もしユーザが10万人のサービスだったらどうでしょう。アイディアがあったとして施策と数値を関連付けて改善サイクルを回すことができるでしょうか？なかなか難しそうですね。なにをやっても良かったのか悪かったのかぼんやりとしてしまいそうです。\u003c/p\u003e\n\u003cp\u003eユーザが10万人のサービスでも特定のセグメントに絞り込めば対象となるユーザを減らすことはできます。顧客満足度を改善したいとして性別や居住地、年齢、行動などからスコープを小さくすることは可能です。そうして100人のユーザに絞り込むことで改善サイクルを回すことは可能になるでしょう。しかし、この場合は全体への影響が限定的になります。改善できるが影響は小さい、逆に全体を狙うと改善サイクルが回せない。このトレードオフは指標を選ぶとき重要な論点です。\u003c/p\u003e\n\u003cp\u003eもちろん、これは極端な例になります。実際の現場ではこれほどわかりやすくありません。多くの指標は改善ができそうなできなさそうな…と曖昧なレベルであることがほとんどだとおもいます。では、その中から自分たちにとって有用な指標をどのように探せばよいのでしょうか？\u003c/p\u003e\n\u003ch1 id=\"指標のバランス\"\u003e指標のバランス\u003c/h1\u003e\n\u003cp\u003eちょうどよい指標を探すにあたって課題になるポイントは、同じ指標でも状況次第で良い指標にも悪い指標にもなりうるということです。あるときは妥当なKPIであっても次第にサービスの種類や規模、目標が変化することで学びを得ることのできない不適当な指標となります。\u003c/p\u003e\n\u003cp\u003e指標を検討するときは対象となるユーザの規模や自分たちの施策の影響が及ぶ範囲から考えるとよいでしょう。数字から学ぶためには自分たちのアクションと指標が対応している必要があります。ユーザが増えれば特定のセグメントに対する施策が増えていきますし、その効果を見たいならばそのセグメントの数値に注目したほうがわかりやすいということです。\u003c/p\u003e\n\u003cp\u003eサービスの立ち上げ期はアクティブユーザ率やChurn Rateのような定番のユーザ全体に係る抽象的な指標をKPIとして選ぶことが多いでしょう。このような指標はビジネスに直結する指標であり、最終的に改善したい指標となります。このフェーズではサービスの課題が多くアクションがユーザ全体に影響を与えることが多いため、これらの指標をそのまま使うことで多くのことを学ぶことができます。むしろ、ユーザが少ないので細かい指標を見ようとしてもノイズがひどくて知見を得ることが簡単ではありません。\u003c/p\u003e\n\u003cp\u003e一方で、サービスが成熟してくると上記のような指標では学ぶことが難しくなります。これはユーザが増えれば増えるほど指標の変化が小さくなり施策による効果がわかりにくくなるためです。多様なユーザが増えればそのぶん施策を検討する幅も広がります。そのため、指標を分割したりセグメントを切ったりしてスコープを狭めた指標を大本のKPIの下位にぶらさげてツリーとして利用します。たとえば、特定の機能の利用率のような具体的なユーザの行動をChurn Rateの下位においたり、全体のコンバージョンレート改善に対して特定の流入経路やユーザの属性をセグメントとして絞り込んだ指標を参照するやり方は広く行われています。\u003c/p\u003e\n\u003cp\u003e指標は分割したりスコープを狭めたりすれば理解しやすくコントロールしやすい数字にすることができますが、本来改善したい指標への影響が限定的になったり、本来改善したい指標と実際に追う指標の距離が離れて両者の因果が不確実になっていきます。このトレードオフに対してちょうどいいバランスの指標を探す必要があるのです。\u003c/p\u003e\n\u003ch1 id=\"指標は常に模索するもの\"\u003e指標は常に模索するもの\u003c/h1\u003e\n\u003cp\u003e抽象的な指標から始まり次第に具体的な指標を見るという流れはデータドリブンな組織だと自然に行われています。最初はChurn Rateや顧客満足度のような指標を追いかけたとして、次第にサービスが拡大し施策が具体的なターゲットへ移っていくため自然と指標も具体的なKPIが設定され改善活動を行うことになります。\u003c/p\u003e\n\u003cp\u003eなにか素晴らしい指標を見つけたとして、それをずっと追いかけているだけではデータドリブンになることはできません。変化の激しい現代では市場やビジネスが変化し続けることが前提となります。そうなれば、当然、追いかける指標も改善されなければいけません。\u003c/p\u003e\n\u003cp\u003eデータドリブンな組織はKPIから自分たちがなにか新しいことを学ぶことができているのか常に考えています。指標を使って改善サイクルを回すだけでなく良い指標を探して改善するサイクルを回すことがデータドリブンでは重要なのです。\u003c/p\u003e","title":"学べる指標を探そう"},{"content":" 本記事はウェブメディア「Modern Times」へ2023~2024年に寄稿したものを同メディアの閉鎖に伴い加筆・修正のうえ再掲したものです。\n意思決定を駆動しないデータたち 勘や経験だけではなくデータに基づき客観的な意思決定をおこなうデータドリブンという考え方はビジネスの世界でも広く使われるようになりました。多くの企業ではデータ分析チームを組織しデータを意思決定に活かそうとしています。しかし、本当にデータによって駆動できている会社は多くありません。\nデータを集めてもデータドリブンでない企業はそれを眺めているだけになっています。さまざまな指標を集計したりダッシュボードを作成したりしていますがそれで満足しているのです。データから自分たちの意思決定を改善したりユーザを理解することができていないのであれば、それはデータドリブンとは言えないでしょう。\n自分たちが重要だと考えている指標が上がったり下がったりしたとき、自分たちの考えや行動はどのように変わるでしょうか？この質問はデータドリブンな組織において非常に重要です。もし答えられないのであればデータが組織を駆動しているとは言い難いでしょう。データドリブンな企業ではデータが意思決定を改めるのです。\n優れた指標によって自分たちの意思決定を駆動しましょう。良い指標を設定することができれば、組織の意思決定は指標によって突き動かされていきます。では、そのような優れた指標とはどのようなものなのでしょうか？良い指標と悪い指標の違いは？データドリブンな指標の考え方について解説していきましょう。\n優れた指標とはなにか？ 意思決定に使えるデータドリブンな優れた指標はどのような指標なのでしょうか？良い指標には大きく3つの条件があるとわたしは考えています。値の変化から学べること、その学びによって行動が変わること、そして施策による変化を捉えられることです。逆にいえば、指標を設定してもそこから学ぶことができない、行動が変わらないのならば良い指標とはいえないでしょう。\nまず、自分たちがおこなった施策が良かったのか悪かったのか知ることで次に活かすことができる指標は学ぶことができる指標だといえるでしょう。たとえば広告の改善を考えたとき、改善の前後でクリック率やクリック後の課金率などを比べることによってどのような改善がユーザに対して効果があるのか学習することができます。このような指標を追いかけることで施策の実験を行い改善サイクルを回すことができます。\nどの施策へ投資するか判断できる指標もよい指標です。複数の広告の成果を比較してどの広告に投資するべきか判断できるなら、それはデータドリブンな意思決定ができる指標だといえます。その指標を使うことで適切な広告へ予算を効率よく使うことができます。\nでは、学ぶことができて行動が変わるような指標とはどのような指標なのでしょうか？自分たちの興味があるドメインを定量的に測定できて施策によって変化する指標がよい指標になります。たとえば、プロダクトマネジメントではただのユーザ登録者数よりもアクティブユーザ率や重要な機能の利用率などユーザのエンゲージメントを示すような指標が好まれますし、Web広告であればインプレッションよりもアカウント作成や課金率が重要になるでしょう。\nもちろん、優れた指標を見つけることは簡単ではありません。ビジネスや組織の変化に伴って適切な指標も変わっていきます。自分たちのビジネスを助けるような素晴らしい指標は試行錯誤しながら模索することが必要です。\n良い指標について具体例を考える 具体的に優れた指標はどのようなものがあるのか考えてみましょう。たとえば、ライブ配信や動画投稿ができるサービスを通して活動するならばどんな指標が自分たちに有効でしょうか。この問題は場合によって様々な考え方がありますが、ここではシンプルに考えてみます。\nライブ配信や動画投稿について多くの人が気にしている数値はなんでしょう？おそらくほとんどの人がフォロワー数を話題にするのではないかとおもいます。人気の指標として挙げられることの多い指標です。では、これは配信者や動画投稿者が自分たちの意思決定を改善するにあたって良い指標でしょうか？わたしはあまり良い指標だとは考えません。\n実際のところ、フォロー解除は多くないためフォロワー数は時間経過によって右肩上がりに推移します。問題は右肩上がりそのものではなく、累積していくだけの指標ではどの配信や施策が効いたのかを切り分けられない点にあります。フォロワー数が増えていてもユーザが自分のことをどのように思っているのかはわかりませんし、自分の配信や動画のどれがよかったのか学ぶこともできません。\nライブ配信をするならば同時接続者数が手がかりになるとわたしは考えます。リアルタイムに配信に参加してくれる人の多くはファンですからユーザのエンゲージメントが数値化されていると言えるでしょう。配信中も数値が上下するので細かく自分のアクションに対する考察を得ることができます。ただし同接は配信の長さや時間帯にも左右されるので、単純な大小だけで判断せず変化の傾向として見るのがよいでしょう。\n動画や配信の再生回数はどうでしょうか？これはフォロワー数よりはよいでしょう。コンテンツごとに数値がわかるのでそれぞれの良し悪しを振り返ることができます。しかし、再生回数も右肩上がりの指標ですのでエンゲージメントを測ることが簡単ではありません。動画投稿してすぐに1万再生された動画と1年経って1万再生された動画は同じくらい人気の動画でしょうか？もちろん違いますね。コンテンツが増えれば増えるほど再生回数は使いにくくなってしまいます。\n再生回数でも累計ではなく投稿してから1日〜1週間程度の短期間における再生回数は示唆に富む指標です。期間を絞ることで自分の動画をいつも追いかけてくれているファンのエンゲージメントを数値にできています。ただの再生数というだけでは時間が経つとあまり役に立たなくなりますが、投稿直後の再生回数は今の状態を明確に示してくれる指標です。\nこのように、再生回数そのものはあまり良い指標とは言えませんが期間を絞ることで良い指標となります。同様にフォロワー数も一定期間における増加量に着目すれば学びのある数値です。冒頭であげた「施策による変化を捉えられる」という条件は、こうして期間を制限したり数値の変化を見ることで満たされます。変化を捉えられれば施策の効果を検証できるようになるからです。\nイノベーティブなアイディアを生み出すにはデータだけでは足りない ここまでデータドリブンな良い指標について解説してきました。しかし良い指標は施策の良し悪しを教えてくれる一方で、施策そのものを生み出してくれるわけではありません。データドリブンには限界があるということも同時に理解しておく必要があります。良い施策と悪い施策をデータを使うことで見分けることができますがデータだけでは良い施策そのものを生み出すことができません。データは細かい改善をすることは得意ですが、データがあるからといって良いアイディアを思いつくわけではないのです。データがあればイノベーティブな発想が生まれてさまざまな問題が解決するだろう、という考えはデータドリブンに対するよくある誤解です。\nでは、どのようにして良い施策を考えれば良いのでしょうか？それはデータだけではなくビジネスやマーケット、ユーザに対して理解と考察を深めることが重要です。データだけではなく勘や経験のようなものが必要になります。直感的な発想によって革新的なアイディアが大きな進歩を作り出し、データによって細かい改善を行っていくのです。\nデータドリブンな企業では数値だけにビジネスを任せることはしません。数値にできる限界を理解しているからです。数値という理性と考察から生まれる直感のバランスが重要です。この2つを上手く組み合わせることでイノベーティブな進化と高速な改善の両方のサイクルをつくり全体を最適化することができるのです。\n","permalink":"https://kenjiusui.github.io/blog/posts/biz/021_%E6%84%8F%E6%80%9D%E6%B1%BA%E5%AE%9A%E3%82%92%E9%A7%86%E5%8B%95%E3%81%99%E3%82%8B%E8%89%AF%E3%81%84%E6%8C%87%E6%A8%99%E3%81%A8%E3%81%AF/","summary":"\u003cblockquote\u003e\n\u003cp\u003e本記事はウェブメディア「Modern Times」へ2023~2024年に寄稿したものを同メディアの閉鎖に伴い加筆・修正のうえ再掲したものです。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch1 id=\"意思決定を駆動しないデータたち\"\u003e意思決定を駆動しないデータたち\u003c/h1\u003e\n\u003cp\u003e勘や経験だけではなくデータに基づき客観的な意思決定をおこなうデータドリブンという考え方はビジネスの世界でも広く使われるようになりました。多くの企業ではデータ分析チームを組織しデータを意思決定に活かそうとしています。しかし、本当にデータによって駆動できている会社は多くありません。\u003c/p\u003e\n\u003cp\u003eデータを集めてもデータドリブンでない企業はそれを眺めているだけになっています。さまざまな指標を集計したりダッシュボードを作成したりしていますがそれで満足しているのです。データから自分たちの意思決定を改善したりユーザを理解することができていないのであれば、それはデータドリブンとは言えないでしょう。\u003c/p\u003e\n\u003cp\u003e自分たちが重要だと考えている指標が上がったり下がったりしたとき、自分たちの考えや行動はどのように変わるでしょうか？この質問はデータドリブンな組織において非常に重要です。もし答えられないのであればデータが組織を駆動しているとは言い難いでしょう。データドリブンな企業ではデータが意思決定を改めるのです。\u003c/p\u003e\n\u003cp\u003e優れた指標によって自分たちの意思決定を駆動しましょう。良い指標を設定することができれば、組織の意思決定は指標によって突き動かされていきます。では、そのような優れた指標とはどのようなものなのでしょうか？良い指標と悪い指標の違いは？データドリブンな指標の考え方について解説していきましょう。\u003c/p\u003e\n\u003ch1 id=\"優れた指標とはなにか\"\u003e優れた指標とはなにか？\u003c/h1\u003e\n\u003cp\u003e意思決定に使えるデータドリブンな優れた指標はどのような指標なのでしょうか？良い指標には大きく3つの条件があるとわたしは考えています。値の変化から学べること、その学びによって行動が変わること、そして施策による変化を捉えられることです。逆にいえば、指標を設定してもそこから学ぶことができない、行動が変わらないのならば良い指標とはいえないでしょう。\u003c/p\u003e\n\u003cp\u003eまず、自分たちがおこなった施策が良かったのか悪かったのか知ることで次に活かすことができる指標は学ぶことができる指標だといえるでしょう。たとえば広告の改善を考えたとき、改善の前後でクリック率やクリック後の課金率などを比べることによってどのような改善がユーザに対して効果があるのか学習することができます。このような指標を追いかけることで施策の実験を行い改善サイクルを回すことができます。\u003c/p\u003e\n\u003cp\u003eどの施策へ投資するか判断できる指標もよい指標です。複数の広告の成果を比較してどの広告に投資するべきか判断できるなら、それはデータドリブンな意思決定ができる指標だといえます。その指標を使うことで適切な広告へ予算を効率よく使うことができます。\u003c/p\u003e\n\u003cp\u003eでは、学ぶことができて行動が変わるような指標とはどのような指標なのでしょうか？自分たちの興味があるドメインを定量的に測定できて施策によって変化する指標がよい指標になります。たとえば、プロダクトマネジメントではただのユーザ登録者数よりもアクティブユーザ率や重要な機能の利用率などユーザのエンゲージメントを示すような指標が好まれますし、Web広告であればインプレッションよりもアカウント作成や課金率が重要になるでしょう。\u003c/p\u003e\n\u003cp\u003eもちろん、優れた指標を見つけることは簡単ではありません。ビジネスや組織の変化に伴って適切な指標も変わっていきます。自分たちのビジネスを助けるような素晴らしい指標は試行錯誤しながら模索することが必要です。\u003c/p\u003e\n\u003ch1 id=\"良い指標について具体例を考える\"\u003e良い指標について具体例を考える\u003c/h1\u003e\n\u003cp\u003e具体的に優れた指標はどのようなものがあるのか考えてみましょう。たとえば、ライブ配信や動画投稿ができるサービスを通して活動するならばどんな指標が自分たちに有効でしょうか。この問題は場合によって様々な考え方がありますが、ここではシンプルに考えてみます。\u003c/p\u003e\n\u003cp\u003eライブ配信や動画投稿について多くの人が気にしている数値はなんでしょう？おそらくほとんどの人がフォロワー数を話題にするのではないかとおもいます。人気の指標として挙げられることの多い指標です。では、これは配信者や動画投稿者が自分たちの意思決定を改善するにあたって良い指標でしょうか？わたしはあまり良い指標だとは考えません。\u003c/p\u003e\n\u003cp\u003e実際のところ、フォロー解除は多くないためフォロワー数は時間経過によって右肩上がりに推移します。問題は右肩上がりそのものではなく、累積していくだけの指標ではどの配信や施策が効いたのかを切り分けられない点にあります。フォロワー数が増えていてもユーザが自分のことをどのように思っているのかはわかりませんし、自分の配信や動画のどれがよかったのか学ぶこともできません。\u003c/p\u003e\n\u003cp\u003eライブ配信をするならば同時接続者数が手がかりになるとわたしは考えます。リアルタイムに配信に参加してくれる人の多くはファンですからユーザのエンゲージメントが数値化されていると言えるでしょう。配信中も数値が上下するので細かく自分のアクションに対する考察を得ることができます。ただし同接は配信の長さや時間帯にも左右されるので、単純な大小だけで判断せず変化の傾向として見るのがよいでしょう。\u003c/p\u003e\n\u003cp\u003e動画や配信の再生回数はどうでしょうか？これはフォロワー数よりはよいでしょう。コンテンツごとに数値がわかるのでそれぞれの良し悪しを振り返ることができます。しかし、再生回数も右肩上がりの指標ですのでエンゲージメントを測ることが簡単ではありません。動画投稿してすぐに1万再生された動画と1年経って1万再生された動画は同じくらい人気の動画でしょうか？もちろん違いますね。コンテンツが増えれば増えるほど再生回数は使いにくくなってしまいます。\u003c/p\u003e\n\u003cp\u003e再生回数でも累計ではなく投稿してから1日〜1週間程度の短期間における再生回数は示唆に富む指標です。期間を絞ることで自分の動画をいつも追いかけてくれているファンのエンゲージメントを数値にできています。ただの再生数というだけでは時間が経つとあまり役に立たなくなりますが、投稿直後の再生回数は今の状態を明確に示してくれる指標です。\u003c/p\u003e\n\u003cp\u003eこのように、再生回数そのものはあまり良い指標とは言えませんが期間を絞ることで良い指標となります。同様にフォロワー数も一定期間における増加量に着目すれば学びのある数値です。冒頭であげた「施策による変化を捉えられる」という条件は、こうして期間を制限したり数値の変化を見ることで満たされます。変化を捉えられれば施策の効果を検証できるようになるからです。\u003c/p\u003e\n\u003ch1 id=\"イノベーティブなアイディアを生み出すにはデータだけでは足りない\"\u003eイノベーティブなアイディアを生み出すにはデータだけでは足りない\u003c/h1\u003e\n\u003cp\u003eここまでデータドリブンな良い指標について解説してきました。しかし良い指標は施策の良し悪しを教えてくれる一方で、施策そのものを生み出してくれるわけではありません。データドリブンには限界があるということも同時に理解しておく必要があります。良い施策と悪い施策をデータを使うことで見分けることができますがデータだけでは良い施策そのものを生み出すことができません。データは細かい改善をすることは得意ですが、データがあるからといって良いアイディアを思いつくわけではないのです。データがあればイノベーティブな発想が生まれてさまざまな問題が解決するだろう、という考えはデータドリブンに対するよくある誤解です。\u003c/p\u003e\n\u003cp\u003eでは、どのようにして良い施策を考えれば良いのでしょうか？それはデータだけではなくビジネスやマーケット、ユーザに対して理解と考察を深めることが重要です。データだけではなく勘や経験のようなものが必要になります。直感的な発想によって革新的なアイディアが大きな進歩を作り出し、データによって細かい改善を行っていくのです。\u003c/p\u003e\n\u003cp\u003eデータドリブンな企業では数値だけにビジネスを任せることはしません。数値にできる限界を理解しているからです。数値という理性と考察から生まれる直感のバランスが重要です。この2つを上手く組み合わせることでイノベーティブな進化と高速な改善の両方のサイクルをつくり全体を最適化することができるのです。\u003c/p\u003e","title":"意思決定を駆動する良い指標とは"},{"content":" 本記事はウェブメディア「Modern Times」へ2023~2024年に寄稿したものを同メディアの閉鎖に伴い加筆・修正のうえ再掲したものです。\n組織構造がデータの活用を促進する データ駆動型の経営を実現するためにデータ分析チームを新設する組織が増えてきました。データアナリストやデータサイエンティスト、データ基盤エンジニアなどデータ分析に係る人材を採用し新たなチームとして立ち上げたという話は枚挙にいとまがありません。\n一方で、データ分析チームを組織においてどのような配置にするべきかという点はあまり話題になりません。どこの企業も独立したデータ分析チームとして配置されているケースがほとんどでしょう。果たして、それは適切な組織構造に対するアサインなのでしょうか？\n配置を誤るとせっかく採用した人材が事業部とうまく噛み合わず分析が意思決定に使われないまま埋もれてしまいます。データドリブンな意思決定を行い事業の変化に迅速に対応できるようになるためには事業部とデータ分析人材の連携が必要です。同時に、データ分析基盤やBIツールなど様々なシステムを導入し運用していく必要もあります。そのためにデータ分析人材が動きやすく能力を発揮しやすいようにアサインされていなければなりません。適切な配置が組織全体のデータ活用を促し、競争上の優位性を確保できるようになるのです。\nそれではデータ分析人材の配置はどのように考えるとよいでしょうか？会社のビジネスモデルや組織構造によって考えるべきポイントはたくさんあります。まずはシンプルに中央集権型組織と分散型組織、そしてその2つを組み合わせたハイブリッド型について考えてみましょう。\nリソース配分しやすい中央集権型組織 わたしが知る限りほとんどの企業で、この中央集権型の組織構造をとっています。中央集権型組織ではデータ分析者というジョブに対してデータ分析チームという1つの組織を割り当てられ、複数の事業部や組織を横断して分析業務にあたります。原則として分析者を含めてデータ分析基盤エンジニアなど分析に関わる人材をこの分析チームに集めます。\n中央集権型組織のメリットは分析人材を一元管理できるため組織で一貫した方針や計画に向けて効率よくリソースを配分できることです。組織とビジネスは常に変化するものですので、重点的にリソースを割きたい対象も変わっていきます。そのようなときに柔軟に向き先を変えながら手厚く人材をアサインすることができます。\nこのメリットはデータ活用を始めた段階で特に恩恵があります。初期フェーズでは人材の数が少なく分析に必要な環境も乏しいでしょう。そのような状態で人材を分散させてしまうと一向にデータ活用の実績をあげることができず導入に失敗するような事態になりかねません。最初は実績をあげるために1つの目標に対してチームが一丸となって取り組むほうがよいでしょう。\n一方で、中央集権型のデメリットは事業部とのコミュニケーションコストが高いため迅速で柔軟な意思決定が難しいことにあります。構造上、事業部と分析チームが異なる組織であるため社内受託のような状態になりがちです。そうなると素早い意思決定や複雑な課題の解決は難しくなるでしょう。また、依頼する側・受ける側というあたかも上下関係のようなものが生まれてしまい組織の関係性に問題が起きやすくなります。これは分析者のモチベーション低下にもつながります。\nコミュニケーションしやすい分散型組織 中央集権型組織の特徴について掴んだところで、次は対角にある分散型組織の場合を考えてみましょう。分散型組織ではデータ分析人材を事業部ごとに配置します。それぞれの事業部と共同でデータ分析業務を進めていきます。\n分散型組織のメリットは事業部とデータ分析人材が同じ組織にいるため密な情報連携が可能になり素早く柔軟な意思決定が可能になります。距離が近くなればコミュニケーションを増やすことも容易ですから分析を利用した改善活動がしやすくなるでしょう。事業の細かい方針転換にも素早く対応することが可能です。\nまた、現場と分析者の距離が近くなることで分析人材が業務について深く理解できるようになり、実際的な分析結果を提供しやすくなります。データ分析業務ではドメイン知識の理解が非常に重要ですが、コミュニケーションコストが高いとドメイン知識の理解も簡単ではなくなってしまいます。事業部と分析者が密接に連携できる環境であればそれも容易になり、より本質的な分析を行うことができるようになります。\nでは分散型組織のデメリットはなんでしょうか？それは組織をまたいだプロジェクトを実行しにくいため全体最適化が難しくなることです。事業部内部で閉じるような問題であれば高速に実行できますが組織をまたいだ問題解決には時間がかかります。また、分析人材同士の交流が減るため分析に関する知見を深めにくくなります。\nハイブリッド型組織で現実的な解決を目指す 中央集権型と分散型組織の2つの特徴を踏まえたうえで、どのような組織を作っていくべきなのでしょうか？実際のところ、組織をこの2つのどちらかというよりも2つを組み合わせたようなハイブリッド構造を長期的に目指すのが望ましいでしょう。\n分析組織の立ち上がりはほとんどのケースで中央集権型からはじまります。そのため実際のところ分析組織は中央集権型から徐々に分散型の要素を取り入れてハイブリッド型へと変遷を辿っていくことになります。中央集権型で事業部の依頼された分析に対応するという形から一部の事業部にメンバーをアサインして密に連携をとれるようなケースを増やしていくのは私もよく提案する進め方です。\nデータ活用を進めて事業部と分析チームでデータ活用の方向性がよりはっきりした事業部から人材のアサインを進めることでデータ活用のモデルケースとしての活躍が期待できます。うまくいきそうな場所に投資を強めるという極めて当たり前の話ではありますが、データ活用のように新しい概念を持ち込むときはうまくいくケースがあるということはその後の展開に重要です。\n人は分散させても基盤は集約する ここまで人材の配置を考えてきましたがデータ分析基盤については別の見方が必要です。人材は事業部へ分散させてもデータ分析基盤はデータ分析チームで一貫した指針のもと開発していくことが望ましいことが多いでしょう。企業全体で一元化された分析基盤はとても重要です。それを維持するには事業部への分散を強めるよりも分析チームとして1つの方針に統一したほうが進めやすいものになります。\nもちろん現場とのコミュニケーションが問題になりかねませんが分析者が現場へ分散して貢献していればその問題の多くは解決されるでしょう。また、そのような問題をより強力に解決する手段としてデータ分析基盤エンジニアとデータ分析者の中間にデータスチュワードのようなロールが入ると円滑に進められるでしょう。\n組織構造がデータ活用を決める データ活用を進めるに当たって組織構造は重要なポイントです。コンウェイの法則にあるように組織とシステムは密接な関係があります。組織を超えたやりとりが多いため組織構造が適切なものになっていなければ機能不全に陥ります。これは分析者や事業部の担当者など個人だけではどうしようもない問題です。もし社内でデータの活用が進まないのであれば、組織構造による連携の問題が発生していないか検証してみるのはいかがでしょう？\n","permalink":"https://kenjiusui.github.io/blog/posts/biz/020_%E6%8E%A1%E7%94%A8%E3%81%97%E3%81%9F%E3%83%87%E3%83%BC%E3%82%BF%E5%88%86%E6%9E%90%E4%BA%BA%E6%9D%90%E3%82%92%E3%81%A9%E3%81%AE%E3%82%88%E3%81%86%E3%81%AB%E9%85%8D%E7%BD%AE%E3%81%99%E3%81%B9%E3%81%8D%E3%81%8B/","summary":"\u003cblockquote\u003e\n\u003cp\u003e本記事はウェブメディア「Modern Times」へ2023~2024年に寄稿したものを同メディアの閉鎖に伴い加筆・修正のうえ再掲したものです。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"組織構造がデータの活用を促進する\"\u003e組織構造がデータの活用を促進する\u003c/h2\u003e\n\u003cp\u003eデータ駆動型の経営を実現するためにデータ分析チームを新設する組織が増えてきました。データアナリストやデータサイエンティスト、データ基盤エンジニアなどデータ分析に係る人材を採用し新たなチームとして立ち上げたという話は枚挙にいとまがありません。\u003c/p\u003e\n\u003cp\u003e一方で、データ分析チームを組織においてどのような配置にするべきかという点はあまり話題になりません。どこの企業も独立したデータ分析チームとして配置されているケースがほとんどでしょう。果たして、それは適切な組織構造に対するアサインなのでしょうか？\u003c/p\u003e\n\u003cp\u003e配置を誤るとせっかく採用した人材が事業部とうまく噛み合わず分析が意思決定に使われないまま埋もれてしまいます。データドリブンな意思決定を行い事業の変化に迅速に対応できるようになるためには事業部とデータ分析人材の連携が必要です。同時に、データ分析基盤やBIツールなど様々なシステムを導入し運用していく必要もあります。そのためにデータ分析人材が動きやすく能力を発揮しやすいようにアサインされていなければなりません。適切な配置が組織全体のデータ活用を促し、競争上の優位性を確保できるようになるのです。\u003c/p\u003e\n\u003cp\u003eそれではデータ分析人材の配置はどのように考えるとよいでしょうか？会社のビジネスモデルや組織構造によって考えるべきポイントはたくさんあります。まずはシンプルに中央集権型組織と分散型組織、そしてその2つを組み合わせたハイブリッド型について考えてみましょう。\u003c/p\u003e\n\u003ch2 id=\"リソース配分しやすい中央集権型組織\"\u003eリソース配分しやすい中央集権型組織\u003c/h2\u003e\n\u003cp\u003eわたしが知る限りほとんどの企業で、この中央集権型の組織構造をとっています。中央集権型組織ではデータ分析者というジョブに対してデータ分析チームという1つの組織を割り当てられ、複数の事業部や組織を横断して分析業務にあたります。原則として分析者を含めてデータ分析基盤エンジニアなど分析に関わる人材をこの分析チームに集めます。\u003c/p\u003e\n\u003cp\u003e中央集権型組織のメリットは分析人材を一元管理できるため組織で一貫した方針や計画に向けて効率よくリソースを配分できることです。組織とビジネスは常に変化するものですので、重点的にリソースを割きたい対象も変わっていきます。そのようなときに柔軟に向き先を変えながら手厚く人材をアサインすることができます。\u003c/p\u003e\n\u003cp\u003eこのメリットはデータ活用を始めた段階で特に恩恵があります。初期フェーズでは人材の数が少なく分析に必要な環境も乏しいでしょう。そのような状態で人材を分散させてしまうと一向にデータ活用の実績をあげることができず導入に失敗するような事態になりかねません。最初は実績をあげるために1つの目標に対してチームが一丸となって取り組むほうがよいでしょう。\u003c/p\u003e\n\u003cp\u003e一方で、中央集権型のデメリットは事業部とのコミュニケーションコストが高いため迅速で柔軟な意思決定が難しいことにあります。構造上、事業部と分析チームが異なる組織であるため社内受託のような状態になりがちです。そうなると素早い意思決定や複雑な課題の解決は難しくなるでしょう。また、依頼する側・受ける側というあたかも上下関係のようなものが生まれてしまい組織の関係性に問題が起きやすくなります。これは分析者のモチベーション低下にもつながります。\u003c/p\u003e\n\u003ch2 id=\"コミュニケーションしやすい分散型組織\"\u003eコミュニケーションしやすい分散型組織\u003c/h2\u003e\n\u003cp\u003e中央集権型組織の特徴について掴んだところで、次は対角にある分散型組織の場合を考えてみましょう。分散型組織ではデータ分析人材を事業部ごとに配置します。それぞれの事業部と共同でデータ分析業務を進めていきます。\u003c/p\u003e\n\u003cp\u003e分散型組織のメリットは事業部とデータ分析人材が同じ組織にいるため密な情報連携が可能になり素早く柔軟な意思決定が可能になります。距離が近くなればコミュニケーションを増やすことも容易ですから分析を利用した改善活動がしやすくなるでしょう。事業の細かい方針転換にも素早く対応することが可能です。\u003c/p\u003e\n\u003cp\u003eまた、現場と分析者の距離が近くなることで分析人材が業務について深く理解できるようになり、実際的な分析結果を提供しやすくなります。データ分析業務ではドメイン知識の理解が非常に重要ですが、コミュニケーションコストが高いとドメイン知識の理解も簡単ではなくなってしまいます。事業部と分析者が密接に連携できる環境であればそれも容易になり、より本質的な分析を行うことができるようになります。\u003c/p\u003e\n\u003cp\u003eでは分散型組織のデメリットはなんでしょうか？それは組織をまたいだプロジェクトを実行しにくいため全体最適化が難しくなることです。事業部内部で閉じるような問題であれば高速に実行できますが組織をまたいだ問題解決には時間がかかります。また、分析人材同士の交流が減るため分析に関する知見を深めにくくなります。\u003c/p\u003e\n\u003ch2 id=\"ハイブリッド型組織で現実的な解決を目指す\"\u003eハイブリッド型組織で現実的な解決を目指す\u003c/h2\u003e\n\u003cp\u003e中央集権型と分散型組織の2つの特徴を踏まえたうえで、どのような組織を作っていくべきなのでしょうか？実際のところ、組織をこの2つのどちらかというよりも2つを組み合わせたようなハイブリッド構造を長期的に目指すのが望ましいでしょう。\u003c/p\u003e\n\u003cp\u003e分析組織の立ち上がりはほとんどのケースで中央集権型からはじまります。そのため実際のところ分析組織は中央集権型から徐々に分散型の要素を取り入れてハイブリッド型へと変遷を辿っていくことになります。中央集権型で事業部の依頼された分析に対応するという形から一部の事業部にメンバーをアサインして密に連携をとれるようなケースを増やしていくのは私もよく提案する進め方です。\u003c/p\u003e\n\u003cp\u003eデータ活用を進めて事業部と分析チームでデータ活用の方向性がよりはっきりした事業部から人材のアサインを進めることでデータ活用のモデルケースとしての活躍が期待できます。うまくいきそうな場所に投資を強めるという極めて当たり前の話ではありますが、データ活用のように新しい概念を持ち込むときはうまくいくケースがあるということはその後の展開に重要です。\u003c/p\u003e\n\u003ch2 id=\"人は分散させても基盤は集約する\"\u003e人は分散させても基盤は集約する\u003c/h2\u003e\n\u003cp\u003eここまで人材の配置を考えてきましたがデータ分析基盤については別の見方が必要です。人材は事業部へ分散させてもデータ分析基盤はデータ分析チームで一貫した指針のもと開発していくことが望ましいことが多いでしょう。企業全体で一元化された分析基盤はとても重要です。それを維持するには事業部への分散を強めるよりも分析チームとして1つの方針に統一したほうが進めやすいものになります。\u003c/p\u003e\n\u003cp\u003eもちろん現場とのコミュニケーションが問題になりかねませんが分析者が現場へ分散して貢献していればその問題の多くは解決されるでしょう。また、そのような問題をより強力に解決する手段としてデータ分析基盤エンジニアとデータ分析者の中間にデータスチュワードのようなロールが入ると円滑に進められるでしょう。\u003c/p\u003e\n\u003ch2 id=\"組織構造がデータ活用を決める\"\u003e組織構造がデータ活用を決める\u003c/h2\u003e\n\u003cp\u003eデータ活用を進めるに当たって組織構造は重要なポイントです。コンウェイの法則にあるように組織とシステムは密接な関係があります。組織を超えたやりとりが多いため組織構造が適切なものになっていなければ機能不全に陥ります。これは分析者や事業部の担当者など個人だけではどうしようもない問題です。もし社内でデータの活用が進まないのであれば、組織構造による連携の問題が発生していないか検証してみるのはいかがでしょう？\u003c/p\u003e","title":"採用したデータ分析人材をどのように配置すべきか？"},{"content":" 本記事はウェブメディア「Modern Times」へ2023~2024年に寄稿したものを同メディアの閉鎖に伴い加筆・修正のうえ再掲したものです。\nデータの民主化を阻む壁はなにか？ 現代のビジネスにおいてデータ分析の重要性は高まっており、意思決定のプロセスにおいて欠かせない存在となりつつあります。データを使って企業の戦略策定のレベルを上げ競争力を高めることはもはや当たり前のこととなってきました。しかし、多くの企業でデータの活用は中央集権的なアプローチとなっており、データの活用は限定的なものになっています。\n組織の多くの人がデータを利用する際に課題となるポイントはデータに対する理解が必要であり学習コストが高いということです。これはデータを分析するためにSQLやDBの知識が必要という技術的な問題だけでなく、そのデータそのものについて理解しなければならないという課題です。目の前にあるデータがどこから来て、どの程度信頼性があり、ほしい情報を生み出すためにどんな加工が必要なのか把握することは熟練の分析者でも時間がかかります。\nデータの信頼性については前回の記事にあるように品質を保証するような取り組みを行う必要があります。誤りや矛盾などの問題がないような正しいデータを作ることがまず必要です。当然ですが、正しいデータを用意することはすべての前提として求められるものです。まずはデータの品質が高める必要があります。\n品質の高いデータの次は利用しやすいデータを整えることが求められます。正しいデータがあるだけでは専門家以外の人が気軽に分析することは難しいでしょう。たとえば、必要なデータを抽出・集計するためにどのようにデータを結合し処理していけばよいのか理解する必要があります。これは一般的な技術だけではなく分析の目的やビジネス、ドメイン、データベースの特性を踏まえて考えなければいけないため複雑で変化しやすく簡単ではありません。\nこの問題への解決策の1つがデータマートを構築することです。データマートは特定のドメインや部門に合わせて加工・整理されたデータセットを指します。全社のあらゆるデータを幅広く集約したデータウェアハウスから、ある用途に必要な部分を使いやすく整えたものとイメージするとわかりやすいでしょう。大きな倉庫から必要な商品だけを選んで並べた売り場（マート）を作るようなものです。特定の用途に絞り込んだデータセットを利用することで幅広い人がデータへアクセスして迅速かつ適切に分析を実行する一助となります。\nデータマートの有用性 データマネジメントを料理に例えるなら、品質の高いデータとは質がよく最低限の下処理がされた食材です。魚であれば新鮮で血抜きと内臓がきれいに取り除かれたような状態でしょう。ここから自分たちが食べたい料理を作るには必要な食材を選び切ったり焼いたりと調理する必要がありますので、そのためには多様な知識と経験が求められます。それに対して、データマートはミールキットのようなものです。必要な加工や調理が完了しており、必要に応じてちょっとした一手間でほしい料理を作ることができます。ミールキット自体を作る手間が必要ですし他の料理にすることは難しいですが、ほしいものが決まっているなら便利な存在です。\n具体的に考えてみましょう。たとえば、マーケティングチームにおけるデータマートの活用を考えてみます。Webマーケティングはデータの活用が最も進んでいる分野の1つといっても過言ではないでしょう。全体の予算やコスト、獲得の進捗、コンバージョンレートなどの指標をユーザーの属性、行動などを紐づた分析を行ったりキャンペーンごとに効果を検証するような分析が必要となります。そのような数値を分析できるデータマートを準備することでマーケティングチームは簡単な分析ならば自立して実行することが可能です。\nデータマートの一番の利点は特定のビジネス領域にフォーカスされたデータセットなので現場のメンバーが直面している問題に関連したデータであることです。課題解決に必要なデータを用意することで分析が簡単になります。たくさんのデータから自分たちに必要なデータを抽出するのではなく整理された必要なデータを利用することで、どのデータをどのように使えばよいのか明確になります。これによりデータの使い勝手が向上し迅速に分析を進めることが可能になるのです。\n分析が主たる業務でないメンバーがデータを活用できるようにするためには学習コストを下げて簡単に扱える必要があります。データの扱い方が明確になってわかりやすい、ということは重要です。データマートは事前に処理され品質管理されたデータであるため、どのように分析すればよいのか・どのようなことができないのか明確になっています。分析に要求されるデータ解釈のスキルが低減されるのです。これによって多くの人がデータを利用しやすくなります。\nデータマートとどう付き合うか データマートは深いデータの理解がなくてもデータを分析してビジネスに活かすことができる便利で重要なしくみです。しかし、当然ですがデータマートを構築し運用するために多くの時間と人が必要になります。言うは易し行うは難し。利便性の高いデータマートを構築し利用できる状態を維持し続けることは簡単ではありません。コストと組織への効果を考えながらちょうどよいバランスを模索していく必要があります。\nもっとも、データの民主化を後押しする手段はデータマートだけではありません。近年はBIツールやAIの進化によってSQLを書かずに分析できる環境も広がってきました。技術的な壁は着実に低くなっています。それでもデータがどこから来て何を表すのかを理解し整える壁は残り続けます。むしろ手軽に分析できる時代だからこそ用途に合わせて整理されたデータマートの価値は失われません。\n冒頭で挙げたデータの民主化を阻む壁、つまり専門知識や学習コストの高さをデータマートは現実的に引き下げてくれます。分析の専門家でなくても自分の業務に必要なデータへ手を伸ばしデータをもとに判断できる人を組織に増やしていく。データマートはデータの民主化を一歩ずつ前へ進める実践的な手段なのです。\n","permalink":"https://kenjiusui.github.io/blog/posts/biz/019_%E3%83%87%E3%83%BC%E3%82%BF%E3%83%9E%E3%83%BC%E3%83%88%E3%81%8C%E3%83%87%E3%83%BC%E3%82%BF%E3%81%AE%E6%B0%91%E4%B8%BB%E5%8C%96%E3%82%92%E4%BF%83%E9%80%B2%E3%81%99%E3%82%8B/","summary":"\u003cblockquote\u003e\n\u003cp\u003e本記事はウェブメディア「Modern Times」へ2023~2024年に寄稿したものを同メディアの閉鎖に伴い加筆・修正のうえ再掲したものです。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"データの民主化を阻む壁はなにか\"\u003eデータの民主化を阻む壁はなにか？\u003c/h2\u003e\n\u003cp\u003e現代のビジネスにおいてデータ分析の重要性は高まっており、意思決定のプロセスにおいて欠かせない存在となりつつあります。データを使って企業の戦略策定のレベルを上げ競争力を高めることはもはや当たり前のこととなってきました。しかし、多くの企業でデータの活用は中央集権的なアプローチとなっており、データの活用は限定的なものになっています。\u003c/p\u003e\n\u003cp\u003e組織の多くの人がデータを利用する際に課題となるポイントはデータに対する理解が必要であり学習コストが高いということです。これはデータを分析するためにSQLやDBの知識が必要という技術的な問題だけでなく、そのデータそのものについて理解しなければならないという課題です。目の前にあるデータがどこから来て、どの程度信頼性があり、ほしい情報を生み出すためにどんな加工が必要なのか把握することは熟練の分析者でも時間がかかります。\u003c/p\u003e\n\u003cp\u003eデータの信頼性については前回の記事にあるように品質を保証するような取り組みを行う必要があります。誤りや矛盾などの問題がないような正しいデータを作ることがまず必要です。当然ですが、正しいデータを用意することはすべての前提として求められるものです。まずはデータの品質が高める必要があります。\u003c/p\u003e\n\u003cp\u003e品質の高いデータの次は利用しやすいデータを整えることが求められます。正しいデータがあるだけでは専門家以外の人が気軽に分析することは難しいでしょう。たとえば、必要なデータを抽出・集計するためにどのようにデータを結合し処理していけばよいのか理解する必要があります。これは一般的な技術だけではなく分析の目的やビジネス、ドメイン、データベースの特性を踏まえて考えなければいけないため複雑で変化しやすく簡単ではありません。\u003c/p\u003e\n\u003cp\u003eこの問題への解決策の1つがデータマートを構築することです。データマートは特定のドメインや部門に合わせて加工・整理されたデータセットを指します。全社のあらゆるデータを幅広く集約したデータウェアハウスから、ある用途に必要な部分を使いやすく整えたものとイメージするとわかりやすいでしょう。大きな倉庫から必要な商品だけを選んで並べた売り場（マート）を作るようなものです。特定の用途に絞り込んだデータセットを利用することで幅広い人がデータへアクセスして迅速かつ適切に分析を実行する一助となります。\u003c/p\u003e\n\u003ch2 id=\"データマートの有用性\"\u003eデータマートの有用性\u003c/h2\u003e\n\u003cp\u003eデータマネジメントを料理に例えるなら、品質の高いデータとは質がよく最低限の下処理がされた食材です。魚であれば新鮮で血抜きと内臓がきれいに取り除かれたような状態でしょう。ここから自分たちが食べたい料理を作るには必要な食材を選び切ったり焼いたりと調理する必要がありますので、そのためには多様な知識と経験が求められます。それに対して、データマートはミールキットのようなものです。必要な加工や調理が完了しており、必要に応じてちょっとした一手間でほしい料理を作ることができます。ミールキット自体を作る手間が必要ですし他の料理にすることは難しいですが、ほしいものが決まっているなら便利な存在です。\u003c/p\u003e\n\u003cp\u003e具体的に考えてみましょう。たとえば、マーケティングチームにおけるデータマートの活用を考えてみます。Webマーケティングはデータの活用が最も進んでいる分野の1つといっても過言ではないでしょう。全体の予算やコスト、獲得の進捗、コンバージョンレートなどの指標をユーザーの属性、行動などを紐づた分析を行ったりキャンペーンごとに効果を検証するような分析が必要となります。そのような数値を分析できるデータマートを準備することでマーケティングチームは簡単な分析ならば自立して実行することが可能です。\u003c/p\u003e\n\u003cp\u003eデータマートの一番の利点は特定のビジネス領域にフォーカスされたデータセットなので現場のメンバーが直面している問題に関連したデータであることです。課題解決に必要なデータを用意することで分析が簡単になります。たくさんのデータから自分たちに必要なデータを抽出するのではなく整理された必要なデータを利用することで、どのデータをどのように使えばよいのか明確になります。これによりデータの使い勝手が向上し迅速に分析を進めることが可能になるのです。\u003c/p\u003e\n\u003cp\u003e分析が主たる業務でないメンバーがデータを活用できるようにするためには学習コストを下げて簡単に扱える必要があります。データの扱い方が明確になってわかりやすい、ということは重要です。データマートは事前に処理され品質管理されたデータであるため、どのように分析すればよいのか・どのようなことができないのか明確になっています。分析に要求されるデータ解釈のスキルが低減されるのです。これによって多くの人がデータを利用しやすくなります。\u003c/p\u003e\n\u003ch2 id=\"データマートとどう付き合うか\"\u003eデータマートとどう付き合うか\u003c/h2\u003e\n\u003cp\u003eデータマートは深いデータの理解がなくてもデータを分析してビジネスに活かすことができる便利で重要なしくみです。しかし、当然ですがデータマートを構築し運用するために多くの時間と人が必要になります。言うは易し行うは難し。利便性の高いデータマートを構築し利用できる状態を維持し続けることは簡単ではありません。コストと組織への効果を考えながらちょうどよいバランスを模索していく必要があります。\u003c/p\u003e\n\u003cp\u003eもっとも、データの民主化を後押しする手段はデータマートだけではありません。近年はBIツールやAIの進化によってSQLを書かずに分析できる環境も広がってきました。技術的な壁は着実に低くなっています。それでもデータがどこから来て何を表すのかを理解し整える壁は残り続けます。むしろ手軽に分析できる時代だからこそ用途に合わせて整理されたデータマートの価値は失われません。\u003c/p\u003e\n\u003cp\u003e冒頭で挙げたデータの民主化を阻む壁、つまり専門知識や学習コストの高さをデータマートは現実的に引き下げてくれます。分析の専門家でなくても自分の業務に必要なデータへ手を伸ばしデータをもとに判断できる人を組織に増やしていく。データマートはデータの民主化を一歩ずつ前へ進める実践的な手段なのです。\u003c/p\u003e","title":"データマートがデータの民主化を促進する"},{"content":" 本記事はウェブメディア「Modern Times」へ2023~2024年に寄稿したものを同メディアの閉鎖に伴い加筆・修正のうえ再掲したものです。\nデータ分析のロジスティクスとデータの品質 前回の記事では企業におけるデータの民主化において、ロジスティクスとガバナンスこそが重要であるという点について解説しました。多くの人が効率よく安全にデータ分析できるような環境を整備したり、リーガルの問題へ取り組んでいかなければいけません。今回の記事ではそのロジスティクスのなかでも、分析を支えるデータの品質に目を向けてみましょう。\nデータを活用するにあたって分析者の多くがほとんどの労働時間をデータセットの構築や維持に費やしていることが様々な調査からわかっています。ロジスティクスと一言にいっても、データ分析においてどこからどこまでをロジスティクスと呼ぶのか曖昧です。しかし、明確に分析者の手間がかかっているポイントがあります。それは使えるような形になったデータを構築し維持する作業です。そして、この作業の成否を左右するのがデータの品質にほかなりません。\nただ何も考えずにデータを集めただけでは分析に使うことはできません。分析に必要な情報を集めて、保存し、整理されて初めて分析で使うことができます。このように書くとごく当たり前のように聞こえるかもしれませんが、実際のところ、分析を意図した体制が整っていない企業ではデータが分析できる状態でないことが多くあります。データの抜けや漏れがあったり、更新されていないデータがあったり、いつどこで誰が変更したのかわからないようなことがあります。このような質の低いデータでは適切な意思決定をおこなうことは難しいでしょう。\nデータを活用している企業では高い品質のデータを準備することに非常に多くの労力を割いています。ビジネスの変化にともないデータ量は常に増え続け構造はより複雑化していきます。その最中において、データを分析し活用するためのデータマネジメントを実施していくことが求められるからです。本記事では、データを分析するために求められる品質とその改善について解説していきます。\nデータの品質基準 ビジネスでデータを活用するためにはデータの品質が重要です。データを用いた意思決定では正しいデータが大前提となっています。当然ですが、正しくないデータから適切な意思決定をすることはできません。間違ったデータから得られるのは不適切な意思決定だけです。\nそれでは、データの品質とはどのように定義すればよいのでしょうか？データの品質に対して具体的な要求を考えてみましょう。たとえば「毎日朝の9時まで必要なデータが入っている」とか「顧客の名前や連絡先など必須の情報に入力の抜けがない」といった要件が思いつきます。\n各企業ごとにビジネスモデルや組織体制、システムの環境などから具体的に必要とされる要件に違いはあります。とはいえ、抽象的に求められるものはどこの企業でも大きな差はありません。ここでは抽象的に品質が高いデータの基準として国際基準であるISOや日本政府の提供している評価基準を参考にピックアップしてみましょう。\n正確性\nデータの正しさです。データと実態に齟齬がない状態を目指します。例えば、CRMで顧客の名前や連絡先が間違っていたら正確なデータとは言い難いでしょう。誤字脱字も問題になります。\n完全性\n抜けや漏れの少なさで、分析のために必要なデータが存在することです。たとえば入力が必須項目であるはずが空欄のまま保存されていたら完全性に欠けたデータといえるでしょう。システム上の不備で一定期間のデータに抜けがあるような状態も避ける必要があります。\n一貫性\nデータ同士の整合性です。データに矛盾があったりズレが存在すると分析するために前処理をする必要が生まれたり、そもそもデータとしてどれを信用したらよいのかわかりません。たとえば、郵便番号と住所が違っていたらどちらを信用すべきでしょうか？全角や半角、記号の表記ゆれなどは細かな差異のように見えますが分析では重大な問題になりえます。\n最新性\nデータの新しさを示します。いつまでも古いままのデータでは変化の激しいビジネスの現場では使い物になりません。定期的な更新が必要です。加えて、更新の頻度も重要です。1日ごとの更新、1時間ごと、1分ごと、随時更新\u0026hellip;と更新の頻度は高ければ高いほど望ましいですが保守・運用コストも高くなります。\n追跡可能性\nデータがどこからきて、どのような変更が起きたのか追跡できることです。たとえば売上と一言にいっても請求書や入金で差が生まれますし広告やECサイトならプラットフォームのダッシュボードの数値もあり更新頻度や対象とする範囲が違いますのでどこの数値を見ているのかわかる必要があります。CRMを使っていれば入力後に変更されたりしたら誰がどのように変更したのか追跡しなければデータの信頼性に関わるでしょう。\nデータの品質を向上させるためのアクション 前述のようにデータの品質を定義する様々な基準を確認しました。それでは、これらの基準に対して品質を改善するにはどのような活動をしていけばよいでしょうか？当然、すべてを一瞬で解決できる銀の弾丸はありません。品質の改善は穴の空いたバケツを塞ぐようなものであり地道な対策を積み重ねることが必要です。\nそれでは暗中模索で対策を試すしかないのでしょうか？いいえ、そんなことはありません。データの品質を改善する基本的なプラクティスは多く存在します。プラクティスの実行だけで100点になるわけではありませんが多くの場合で効果が期待できます。ここではいくつか例を紹介しましょう。\nデータ品質を意識したプロセスとシステムの再設計 データは業務の様々な場所から発生しますが各々の業務フローは自分たちの事情に対して最適化されているものです。データの品質を改善するという目線から全体を設計しなおしていくことがまず必要になります。\nたとえば、CRMのデータに抜け漏れが多いという問題があり原因が入力する時間を取ることができないことだとしたら、業務フローとして入力する時間を確保していく必要があります。場合によってはチーム内で確認しあうようなフローも良いでしょう。データを入力すること、品質の高いデータを作成することも業務の1つとして組み込むのです。このようにしてデータ品質の問題を解決できるような業務フローを構築していきます。\n業務フローと同時に作業するためのシステムを変える必要もあるかもしれません。業務のやりやすさだけでなく、データ分析のために品質を高められるようなツールへと変えていきます。たとえば顧客情報を入力するならスプレッドシートよりCRMを使ったほうがデータ品質へのサポートが手厚いことがほとんどです。求められるデータを入力できることはもちろん、サービス同士の連携や統制、追跡がやりやすいツールを選ぶ必要があります。\n既存の業務フローやシステムを変えることは簡単ではありません。慣れた方法を変えることはそれだけでもストレスがかかりますし、変えたせいで生産性が悪化したのでは意味がありません。現場のメンバーに悪い影響を与えないように必要な要件を整理したうえでスムーズに移行していけるように進める必要があります。\nデータ入力の統制 データの品質を向上させるためにはやはり入り口であるデータを入力するシーンで改善することが最も効果的です。データの品質を低下させる要因の多くは人間が手で入力するシーンにあります。アンケートやプロフィール、CRMなどは人間がデータを作成します。このような状況への対策として人間が監視して品質を上げる方法は実質的に不可能でしょう。\nシステマティックな対策として入力できる値を制限して統制する方法があります。顧客情報を表計算ソフトに直接入力しているような組織も少なくないでしょう。入力フォームを使うことでデータ入力を統制するやり方は定番の解決方法です。郵便番号のように入力された値が一定のフォーマットであることが期待できるなら自動でチェックする機能も役に立ちます。\n「注意深く入力すればミスを減らすことができる」と考える人は少なくありません。しかし、人間の注意力は有限でありミスを減らすにも限界があります。誤字・脱字、数字や記号の半角・全角のゆれなどは注意していても気がつけないものです。機械的に解決できるものであれば可能な限りそのような手段で解決していくことが望ましいでしょう。分析する側から見ると「半角と全角の揺れがないように気をつけて入力している」というデータでは常に集計漏れの不安が残りますが「システム側で数字を常に半角にしている」というデータであれば安心して分析が進められます。\nデータの定義の整理 入力されているデータの意図が明確に言語化されていないと曖昧になり入力がブレがちです。表記ゆれや入力の矛盾、不整合がおきる要因としてそもそも定義が曖昧なまま認識が一致できていないことがあります。たとえば顧客情報を入力する際に「連絡先」という項目名だけではメールアドレスを入れる人と電話番号を入れる人どちらがいてもおかしくありません。定義を明確にし期待する入力をわかりやすくすることが必要です。\n定義とはいつ、どこで、誰が、なにを、どうやって入力するのか明確にすることです。たとえば、お客様とアポイントが取れたことをCRMに保存している場合、どの段階で「アポイントが決まった」と定義するのか人によってブレがあります。口頭、メール、日程が決まる\u0026hellip;etcなど段階によって確度が違いますので、分析する際にこの違いは重要です。定義として明確にしておくべきでしょう。\n定義を整理し言語化することはデータの品質を高めるだけでなく、その後の分析の効率化にも貢献します。分析では集めたデータがそれぞれどのような背景で集められたデータなのか解釈をしながら進めることになります。その際に、それぞれのデータの定義が明確になっていることは有用です。\nデータの品質を高める組織づくり データの品質を高めるための手法や戦略のプラクティスは多くありますが、一度実施して終わることはなく継続した取り組みが必要です。そのためには、データの品質を改善することを組織として推進していかなければいけません。\nデータを入力する部門がシステムや業務フローを改善するためにはその部門や事業部の協力が必要になります。そのためにはデータの品質についてオーナーシップの一端をその部門がもたなければいけません。責任を持たなければいつまでも他人事です。データを軸とした改革を進めるためにはデータ分析者と事業の責任者の両方が責任を持つべきです。\n現場からしたらデータのことは分析チーム側で解決してほしいと思っているでしょう。逆に分析側はデータは現場で発生するから現場に対応してほしいと考えているでしょう。これはどちらが正しいなどと議論することに意味はありません。対立するのではなく歩み寄って問題を解決していく必要があるのです。\n高い品質のデータを集めることはより良い意思決定に繋がり、ひいては組織全体への影響を与えます。データの品質改善はデータ分析部門だけの問題ではありません。会社のすべての人が関わる問題なのです。多くのステークホルダーがいるなかでうまく利害を調整しながら前進していく必要があります。そのような組織を作ることもまたデータ活用のためのデータマネジメントといえるでしょう。\n","permalink":"https://kenjiusui.github.io/blog/posts/biz/018_%E3%83%87%E3%83%BC%E3%82%BF%E3%82%92%E5%88%86%E6%9E%90%E3%81%99%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AB%E6%B1%82%E3%82%81%E3%82%89%E3%82%8C%E3%82%8B%E3%83%87%E3%83%BC%E3%82%BF%E3%81%AE%E5%93%81%E8%B3%AA%E3%81%A8%E6%94%B9%E5%96%84/","summary":"\u003cblockquote\u003e\n\u003cp\u003e本記事はウェブメディア「Modern Times」へ2023~2024年に寄稿したものを同メディアの閉鎖に伴い加筆・修正のうえ再掲したものです。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"データ分析のロジスティクスとデータの品質\"\u003eデータ分析のロジスティクスとデータの品質\u003c/h2\u003e\n\u003cp\u003e前回の記事では企業におけるデータの民主化において、ロジスティクスとガバナンスこそが重要であるという点について解説しました。多くの人が効率よく安全にデータ分析できるような環境を整備したり、リーガルの問題へ取り組んでいかなければいけません。今回の記事ではそのロジスティクスのなかでも、分析を支えるデータの品質に目を向けてみましょう。\u003c/p\u003e\n\u003cp\u003eデータを活用するにあたって分析者の多くがほとんどの労働時間をデータセットの構築や維持に費やしていることが様々な調査からわかっています。ロジスティクスと一言にいっても、データ分析においてどこからどこまでをロジスティクスと呼ぶのか曖昧です。しかし、明確に分析者の手間がかかっているポイントがあります。それは使えるような形になったデータを構築し維持する作業です。そして、この作業の成否を左右するのがデータの品質にほかなりません。\u003c/p\u003e\n\u003cp\u003eただ何も考えずにデータを集めただけでは分析に使うことはできません。分析に必要な情報を集めて、保存し、整理されて初めて分析で使うことができます。このように書くとごく当たり前のように聞こえるかもしれませんが、実際のところ、分析を意図した体制が整っていない企業ではデータが分析できる状態でないことが多くあります。データの抜けや漏れがあったり、更新されていないデータがあったり、いつどこで誰が変更したのかわからないようなことがあります。このような質の低いデータでは適切な意思決定をおこなうことは難しいでしょう。\u003c/p\u003e\n\u003cp\u003eデータを活用している企業では高い品質のデータを準備することに非常に多くの労力を割いています。ビジネスの変化にともないデータ量は常に増え続け構造はより複雑化していきます。その最中において、データを分析し活用するためのデータマネジメントを実施していくことが求められるからです。本記事では、データを分析するために求められる品質とその改善について解説していきます。\u003c/p\u003e\n\u003ch2 id=\"データの品質基準\"\u003eデータの品質基準\u003c/h2\u003e\n\u003cp\u003eビジネスでデータを活用するためにはデータの品質が重要です。データを用いた意思決定では正しいデータが大前提となっています。当然ですが、正しくないデータから適切な意思決定をすることはできません。間違ったデータから得られるのは不適切な意思決定だけです。\u003c/p\u003e\n\u003cp\u003eそれでは、データの品質とはどのように定義すればよいのでしょうか？データの品質に対して具体的な要求を考えてみましょう。たとえば「毎日朝の9時まで必要なデータが入っている」とか「顧客の名前や連絡先など必須の情報に入力の抜けがない」といった要件が思いつきます。\u003c/p\u003e\n\u003cp\u003e各企業ごとにビジネスモデルや組織体制、システムの環境などから具体的に必要とされる要件に違いはあります。とはいえ、抽象的に求められるものはどこの企業でも大きな差はありません。ここでは抽象的に品質が高いデータの基準として国際基準であるISOや日本政府の提供している評価基準を参考にピックアップしてみましょう。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e正確性\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eデータの正しさです。データと実態に齟齬がない状態を目指します。例えば、CRMで顧客の名前や連絡先が間違っていたら正確なデータとは言い難いでしょう。誤字脱字も問題になります。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e完全性\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e抜けや漏れの少なさで、分析のために必要なデータが存在することです。たとえば入力が必須項目であるはずが空欄のまま保存されていたら完全性に欠けたデータといえるでしょう。システム上の不備で一定期間のデータに抜けがあるような状態も避ける必要があります。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e一貫性\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eデータ同士の整合性です。データに矛盾があったりズレが存在すると分析するために前処理をする必要が生まれたり、そもそもデータとしてどれを信用したらよいのかわかりません。たとえば、郵便番号と住所が違っていたらどちらを信用すべきでしょうか？全角や半角、記号の表記ゆれなどは細かな差異のように見えますが分析では重大な問題になりえます。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e最新性\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eデータの新しさを示します。いつまでも古いままのデータでは変化の激しいビジネスの現場では使い物になりません。定期的な更新が必要です。加えて、更新の頻度も重要です。1日ごとの更新、1時間ごと、1分ごと、随時更新\u0026hellip;と更新の頻度は高ければ高いほど望ましいですが保守・運用コストも高くなります。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e追跡可能性\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eデータがどこからきて、どのような変更が起きたのか追跡できることです。たとえば売上と一言にいっても請求書や入金で差が生まれますし広告やECサイトならプラットフォームのダッシュボードの数値もあり更新頻度や対象とする範囲が違いますのでどこの数値を見ているのかわかる必要があります。CRMを使っていれば入力後に変更されたりしたら誰がどのように変更したのか追跡しなければデータの信頼性に関わるでしょう。\u003c/p\u003e\n\u003ch2 id=\"データの品質を向上させるためのアクション\"\u003eデータの品質を向上させるためのアクション\u003c/h2\u003e\n\u003cp\u003e前述のようにデータの品質を定義する様々な基準を確認しました。それでは、これらの基準に対して品質を改善するにはどのような活動をしていけばよいでしょうか？当然、すべてを一瞬で解決できる銀の弾丸はありません。品質の改善は穴の空いたバケツを塞ぐようなものであり地道な対策を積み重ねることが必要です。\u003c/p\u003e\n\u003cp\u003eそれでは暗中模索で対策を試すしかないのでしょうか？いいえ、そんなことはありません。データの品質を改善する基本的なプラクティスは多く存在します。プラクティスの実行だけで100点になるわけではありませんが多くの場合で効果が期待できます。ここではいくつか例を紹介しましょう。\u003c/p\u003e\n\u003ch3 id=\"データ品質を意識したプロセスとシステムの再設計\"\u003eデータ品質を意識したプロセスとシステムの再設計\u003c/h3\u003e\n\u003cp\u003eデータは業務の様々な場所から発生しますが各々の業務フローは自分たちの事情に対して最適化されているものです。データの品質を改善するという目線から全体を設計しなおしていくことがまず必要になります。\u003c/p\u003e\n\u003cp\u003eたとえば、CRMのデータに抜け漏れが多いという問題があり原因が入力する時間を取ることができないことだとしたら、業務フローとして入力する時間を確保していく必要があります。場合によってはチーム内で確認しあうようなフローも良いでしょう。データを入力すること、品質の高いデータを作成することも業務の1つとして組み込むのです。このようにしてデータ品質の問題を解決できるような業務フローを構築していきます。\u003c/p\u003e\n\u003cp\u003e業務フローと同時に作業するためのシステムを変える必要もあるかもしれません。業務のやりやすさだけでなく、データ分析のために品質を高められるようなツールへと変えていきます。たとえば顧客情報を入力するならスプレッドシートよりCRMを使ったほうがデータ品質へのサポートが手厚いことがほとんどです。求められるデータを入力できることはもちろん、サービス同士の連携や統制、追跡がやりやすいツールを選ぶ必要があります。\u003c/p\u003e\n\u003cp\u003e既存の業務フローやシステムを変えることは簡単ではありません。慣れた方法を変えることはそれだけでもストレスがかかりますし、変えたせいで生産性が悪化したのでは意味がありません。現場のメンバーに悪い影響を与えないように必要な要件を整理したうえでスムーズに移行していけるように進める必要があります。\u003c/p\u003e\n\u003ch3 id=\"データ入力の統制\"\u003eデータ入力の統制\u003c/h3\u003e\n\u003cp\u003eデータの品質を向上させるためにはやはり入り口であるデータを入力するシーンで改善することが最も効果的です。データの品質を低下させる要因の多くは人間が手で入力するシーンにあります。アンケートやプロフィール、CRMなどは人間がデータを作成します。このような状況への対策として人間が監視して品質を上げる方法は実質的に不可能でしょう。\u003c/p\u003e\n\u003cp\u003eシステマティックな対策として入力できる値を制限して統制する方法があります。顧客情報を表計算ソフトに直接入力しているような組織も少なくないでしょう。入力フォームを使うことでデータ入力を統制するやり方は定番の解決方法です。郵便番号のように入力された値が一定のフォーマットであることが期待できるなら自動でチェックする機能も役に立ちます。\u003c/p\u003e\n\u003cp\u003e「注意深く入力すればミスを減らすことができる」と考える人は少なくありません。しかし、人間の注意力は有限でありミスを減らすにも限界があります。誤字・脱字、数字や記号の半角・全角のゆれなどは注意していても気がつけないものです。機械的に解決できるものであれば可能な限りそのような手段で解決していくことが望ましいでしょう。分析する側から見ると「半角と全角の揺れがないように気をつけて入力している」というデータでは常に集計漏れの不安が残りますが「システム側で数字を常に半角にしている」というデータであれば安心して分析が進められます。\u003c/p\u003e\n\u003ch3 id=\"データの定義の整理\"\u003eデータの定義の整理\u003c/h3\u003e\n\u003cp\u003e入力されているデータの意図が明確に言語化されていないと曖昧になり入力がブレがちです。表記ゆれや入力の矛盾、不整合がおきる要因としてそもそも定義が曖昧なまま認識が一致できていないことがあります。たとえば顧客情報を入力する際に「連絡先」という項目名だけではメールアドレスを入れる人と電話番号を入れる人どちらがいてもおかしくありません。定義を明確にし期待する入力をわかりやすくすることが必要です。\u003c/p\u003e\n\u003cp\u003e定義とはいつ、どこで、誰が、なにを、どうやって入力するのか明確にすることです。たとえば、お客様とアポイントが取れたことをCRMに保存している場合、どの段階で「アポイントが決まった」と定義するのか人によってブレがあります。口頭、メール、日程が決まる\u0026hellip;etcなど段階によって確度が違いますので、分析する際にこの違いは重要です。定義として明確にしておくべきでしょう。\u003c/p\u003e\n\u003cp\u003e定義を整理し言語化することはデータの品質を高めるだけでなく、その後の分析の効率化にも貢献します。分析では集めたデータがそれぞれどのような背景で集められたデータなのか解釈をしながら進めることになります。その際に、それぞれのデータの定義が明確になっていることは有用です。\u003c/p\u003e\n\u003ch3 id=\"データの品質を高める組織づくり\"\u003eデータの品質を高める組織づくり\u003c/h3\u003e\n\u003cp\u003eデータの品質を高めるための手法や戦略のプラクティスは多くありますが、一度実施して終わることはなく継続した取り組みが必要です。そのためには、データの品質を改善することを組織として推進していかなければいけません。\u003c/p\u003e\n\u003cp\u003eデータを入力する部門がシステムや業務フローを改善するためにはその部門や事業部の協力が必要になります。そのためにはデータの品質についてオーナーシップの一端をその部門がもたなければいけません。責任を持たなければいつまでも他人事です。データを軸とした改革を進めるためにはデータ分析者と事業の責任者の両方が責任を持つべきです。\u003c/p\u003e\n\u003cp\u003e現場からしたらデータのことは分析チーム側で解決してほしいと思っているでしょう。逆に分析側はデータは現場で発生するから現場に対応してほしいと考えているでしょう。これはどちらが正しいなどと議論することに意味はありません。対立するのではなく歩み寄って問題を解決していく必要があるのです。\u003c/p\u003e\n\u003cp\u003e高い品質のデータを集めることはより良い意思決定に繋がり、ひいては組織全体への影響を与えます。データの品質改善はデータ分析部門だけの問題ではありません。会社のすべての人が関わる問題なのです。多くのステークホルダーがいるなかでうまく利害を調整しながら前進していく必要があります。そのような組織を作ることもまたデータ活用のためのデータマネジメントといえるでしょう。\u003c/p\u003e","title":"データを分析するために求められるデータの品質と改善"},{"content":" 本記事はウェブメディア「Modern Times」へ2023~2024年に寄稿したものを同メディアの閉鎖に伴い加筆・修正のうえ再掲したものです。\nBIツールを導入しただけでは「データの民主化」は進まない DX推進の要素の1つとしてデータの民主化は重要なトピックスです。目まぐるしく変化する現代のマーケットにおいて、意思決定の精度と速度を向上させるために定量的で客観的な評価が必要でしょう。そのためには組織のメンバーが幅広くデータにアクセスし活用できる必要があります。しかし、実際にデータの民主化を進めるにあたってなにから始めればよいのか苦悩している会社も多いのではないでしょうか。\nデータの民主化を成し遂げるためのアクションとしてBIツールの導入やSQLの教育といったアイディアは非常に頻繁に提案されることの多いテーマです。つまり、多くのメンバーがデータを扱えるような設備や教育を整えようということです。彼らがデータを活用するためにはデータにアクセスする手段が必要であり、BIツールやSQLはその手段として汎用的で定番だと言えるでしょう。しかし、実際のところBIツールを導入しただけではデータの民主化を達成することはできません。BIツールのようなデータを扱うツールというものはデータの民主化に対してほんの一要素でしかないからです。\nなぜデータを分析する手段ばかりが話題に上がりやすいのでしょうか？これは分析をしたことのないほとんどの人がデータさえ触れれば分析できると勘違いしているからです。分析者であればそれが間違いだと知っているでしょう。調理方法を知っていても材料がなければ料理は作れないのです。\nそこで本記事が注目するのがデータのロジスティクスとガバナンスです。ここでいうロジスティクスとは分析に使うデータを準備し流通させ使いやすく整備するまでの一連の営みを指します。ガバナンスはそのデータを安全かつ適切に扱うためのルールや管理の仕組みです。データを活用するためには様々な要素が必要ですがこの2つは多くの人に軽視されがちでありながら実際には必要不可欠な論点です。本記事ではその価値について解説します。\nなぜ分析ツールだけでは足りないのか データを分析するツールを運用するためには、まず分析できるデータを用意するシステムと分析するインフラが必要になります。社内で利用するならルールの策定が必要ですし個人情報保護や規約違反を犯さないかリーガルチェックをする必要もあるでしょう。\nロジスティクスやガバナンスの問題はツールの導入では解決することができません。これがデータ分析ツールだけではデータの民主化ができない大きな要因です。ロジスティクスやガバナンスが整ったうえで分析ツールを導入することで初めて多くの人が正しく効率よく分析ができるようになります。\nデータを分析する技術や設備を導入するだけのアプローチではこうした裏側にあるデータのロジスティクスやガバナンスの問題はほとんど解決できません。それらが不必要なわけではありませんが分析できる手段だけを用意してもほとんどの企業においてデータを十分に活用することは難しいのです。\n現場で噴き出すロジスティクスとガバナンスの問題 社内で多くの人がデータを利用しはじめると細かい運用の面でも課題がでてきます。たとえば、同じ名前の指標でも定義や処理の仕方が異なるという問題はよくあります。売上という言葉1つとってもチームによって計算の定義が異なります。複数の人が似たような計算をする機会が増えますので、正しく効率よく計算できるように必要なデータや処理の方法を共有することも重要になるでしょう。\n運用上の問題に加えて使う人が増えればセキュリティ上のリスクも高まります。分析ツールやデータへのアクセスについて利用者ごとに適切な権限を付与したり管理することが必要になります。データを扱うためのセキュリティについてリテラシーの教育も必要です。ここで挙げたものはデータの民主化について頻出する課題の一例であって、他にもさまざまな障害があるでしょう。\n問題をどう解決していくか それでは、このような問題をどのように解決していけばよいのでしょうか？すべての問題を一息に解決してくれる、いわゆる銀の弾丸は存在しません。1つずつ問題を解決していく必要があります。そして、そのソリューションと優先度は組織の構造やデータ民主化の進め方によるため一概に決めることが困難です。問題と向き合い、地道に取り組むことが必要です。\n先に挙げた課題にはそれぞれ定番の解決策があります。データを安定して分析できるシステムが必要ならば、開発や保守運用を担うデータ分析基盤チームが必要でしょう。指標の定義や処理の仕方に差異が発生するならば、データカタログやデータマートを構築して共有化するのは定番の解決方法です。それらを活用するためにデータスチュワードのようなロールが求められるでしょう。セキュリティリスクへの対策として権限の管理を行うには、ルールの策定とそれを運用する組織を作る必要があります。データが規約や法律に対して問題がないか専門家と議論する枠組みを用意することもよいでしょう。\n解決には全社的・トップダウンの推進が不可欠 これらの問題の解決の障害となるのは組織の壁です。近年ではデータ活用に関する問題に対して解決のプラクティスが共有されつつあり、以前に比べれば効率よく解決へ進むことができるでしょう。しかし、チーム単独で進めることが難しく影響範囲の広い課題です。特に権限の管理や法律や規制への対応はチームを超え全社を巻き込んで解決していく必要があります。このような問題をボトムアップに解決することは困難で、必ずトップダウンに強制力をもって進めなければいけないシーンがでてきます。\nメンバーが幅広くデータを活用することは企業の成長に大きく貢献します。しかしそこに至るにはBIツールの導入のような手段の整備だけでは足りずその土台となるロジスティクスとガバナンスの問題に地道に取り組まなければなりません。そしてその取り組みは現場だけで完結しません。現場の意思決定の速度を速めながらガバナンスやロジスティクスの改善をトップダウンに進める——この両輪を回して全体を最適化することこそがデータの民主化に必要なのです。\n","permalink":"https://kenjiusui.github.io/blog/posts/biz/017_bi%E3%83%84%E3%83%BC%E3%83%AB%E3%82%92%E5%B0%8E%E5%85%A5%E3%81%97%E3%81%9F%E3%81%A0%E3%81%91%E3%81%A7%E3%81%AF%E3%83%87%E3%83%BC%E3%82%BF%E3%81%AE%E6%B0%91%E4%B8%BB%E5%8C%96%E3%81%8C%E9%80%B2%E3%81%BE%E3%81%AA%E3%81%84%E7%90%86%E7%94%B1/","summary":"\u003cblockquote\u003e\n\u003cp\u003e本記事はウェブメディア「Modern Times」へ2023~2024年に寄稿したものを同メディアの閉鎖に伴い加筆・修正のうえ再掲したものです。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"biツールを導入しただけではデータの民主化は進まない\"\u003eBIツールを導入しただけでは「データの民主化」は進まない\u003c/h2\u003e\n\u003cp\u003eDX推進の要素の1つとしてデータの民主化は重要なトピックスです。目まぐるしく変化する現代のマーケットにおいて、意思決定の精度と速度を向上させるために定量的で客観的な評価が必要でしょう。そのためには組織のメンバーが幅広くデータにアクセスし活用できる必要があります。しかし、実際にデータの民主化を進めるにあたってなにから始めればよいのか苦悩している会社も多いのではないでしょうか。\u003c/p\u003e\n\u003cp\u003eデータの民主化を成し遂げるためのアクションとしてBIツールの導入やSQLの教育といったアイディアは非常に頻繁に提案されることの多いテーマです。つまり、多くのメンバーがデータを扱えるような設備や教育を整えようということです。彼らがデータを活用するためにはデータにアクセスする手段が必要であり、BIツールやSQLはその手段として汎用的で定番だと言えるでしょう。しかし、実際のところBIツールを導入しただけではデータの民主化を達成することはできません。BIツールのようなデータを扱うツールというものはデータの民主化に対してほんの一要素でしかないからです。\u003c/p\u003e\n\u003cp\u003eなぜデータを分析する手段ばかりが話題に上がりやすいのでしょうか？これは分析をしたことのないほとんどの人がデータさえ触れれば分析できると勘違いしているからです。分析者であればそれが間違いだと知っているでしょう。調理方法を知っていても材料がなければ料理は作れないのです。\u003c/p\u003e\n\u003cp\u003eそこで本記事が注目するのがデータのロジスティクスとガバナンスです。ここでいうロジスティクスとは分析に使うデータを準備し流通させ使いやすく整備するまでの一連の営みを指します。ガバナンスはそのデータを安全かつ適切に扱うためのルールや管理の仕組みです。データを活用するためには様々な要素が必要ですがこの2つは多くの人に軽視されがちでありながら実際には必要不可欠な論点です。本記事ではその価値について解説します。\u003c/p\u003e\n\u003ch2 id=\"なぜ分析ツールだけでは足りないのか\"\u003eなぜ分析ツールだけでは足りないのか\u003c/h2\u003e\n\u003cp\u003eデータを分析するツールを運用するためには、まず分析できるデータを用意するシステムと分析するインフラが必要になります。社内で利用するならルールの策定が必要ですし個人情報保護や規約違反を犯さないかリーガルチェックをする必要もあるでしょう。\u003c/p\u003e\n\u003cp\u003eロジスティクスやガバナンスの問題はツールの導入では解決することができません。これがデータ分析ツールだけではデータの民主化ができない大きな要因です。ロジスティクスやガバナンスが整ったうえで分析ツールを導入することで初めて多くの人が正しく効率よく分析ができるようになります。\u003c/p\u003e\n\u003cp\u003eデータを分析する技術や設備を導入するだけのアプローチではこうした裏側にあるデータのロジスティクスやガバナンスの問題はほとんど解決できません。それらが不必要なわけではありませんが分析できる手段だけを用意してもほとんどの企業においてデータを十分に活用することは難しいのです。\u003c/p\u003e\n\u003ch2 id=\"現場で噴き出すロジスティクスとガバナンスの問題\"\u003e現場で噴き出すロジスティクスとガバナンスの問題\u003c/h2\u003e\n\u003cp\u003e社内で多くの人がデータを利用しはじめると細かい運用の面でも課題がでてきます。たとえば、同じ名前の指標でも定義や処理の仕方が異なるという問題はよくあります。売上という言葉1つとってもチームによって計算の定義が異なります。複数の人が似たような計算をする機会が増えますので、正しく効率よく計算できるように必要なデータや処理の方法を共有することも重要になるでしょう。\u003c/p\u003e\n\u003cp\u003e運用上の問題に加えて使う人が増えればセキュリティ上のリスクも高まります。分析ツールやデータへのアクセスについて利用者ごとに適切な権限を付与したり管理することが必要になります。データを扱うためのセキュリティについてリテラシーの教育も必要です。ここで挙げたものはデータの民主化について頻出する課題の一例であって、他にもさまざまな障害があるでしょう。\u003c/p\u003e\n\u003ch2 id=\"問題をどう解決していくか\"\u003e問題をどう解決していくか\u003c/h2\u003e\n\u003cp\u003eそれでは、このような問題をどのように解決していけばよいのでしょうか？すべての問題を一息に解決してくれる、いわゆる銀の弾丸は存在しません。1つずつ問題を解決していく必要があります。そして、そのソリューションと優先度は組織の構造やデータ民主化の進め方によるため一概に決めることが困難です。問題と向き合い、地道に取り組むことが必要です。\u003c/p\u003e\n\u003cp\u003e先に挙げた課題にはそれぞれ定番の解決策があります。データを安定して分析できるシステムが必要ならば、開発や保守運用を担うデータ分析基盤チームが必要でしょう。指標の定義や処理の仕方に差異が発生するならば、データカタログやデータマートを構築して共有化するのは定番の解決方法です。それらを活用するためにデータスチュワードのようなロールが求められるでしょう。セキュリティリスクへの対策として権限の管理を行うには、ルールの策定とそれを運用する組織を作る必要があります。データが規約や法律に対して問題がないか専門家と議論する枠組みを用意することもよいでしょう。\u003c/p\u003e\n\u003ch2 id=\"解決には全社的トップダウンの推進が不可欠\"\u003e解決には全社的・トップダウンの推進が不可欠\u003c/h2\u003e\n\u003cp\u003eこれらの問題の解決の障害となるのは組織の壁です。近年ではデータ活用に関する問題に対して解決のプラクティスが共有されつつあり、以前に比べれば効率よく解決へ進むことができるでしょう。しかし、チーム単独で進めることが難しく影響範囲の広い課題です。特に権限の管理や法律や規制への対応はチームを超え全社を巻き込んで解決していく必要があります。このような問題をボトムアップに解決することは困難で、必ずトップダウンに強制力をもって進めなければいけないシーンがでてきます。\u003c/p\u003e\n\u003cp\u003eメンバーが幅広くデータを活用することは企業の成長に大きく貢献します。しかしそこに至るにはBIツールの導入のような手段の整備だけでは足りずその土台となるロジスティクスとガバナンスの問題に地道に取り組まなければなりません。そしてその取り組みは現場だけで完結しません。現場の意思決定の速度を速めながらガバナンスやロジスティクスの改善をトップダウンに進める——この両輪を回して全体を最適化することこそがデータの民主化に必要なのです。\u003c/p\u003e","title":"BIツールを導入しただけではデータの民主化が進まない理由"},{"content":" 本記事はウェブメディア「Modern Times」へ2023~2024年に寄稿したものを同メディアの閉鎖に伴い加筆・修正のうえ再掲したものです。\nデータ活用の誤解 世間では、データの活用について大きな誤解をしている人をよく見かけます。なにかビジネスに関わる大きな問題を解決して自分たちに大きな利益をもたらすとか、未来予知ができてあわよくば自分たちに都合がいい方向へ未来を変えられるような、そんな魔法のような何かだと思われています。当たり前ですが、データを使ってもそんなおとぎ話のようなことは起きません。\nそれでは、データを活用することでどんな利益を得られるのでしょうか？データから得られる利益はもっと地道で現実的です。データを活用するということはシンプルに言ってしまえばゴールへじわじわとにじりよるということです。ビジネスでは達成したい目標に向かって施策を打ち、そこへ少しずつ近づくものですが、データを利用することでその精度を高めることができます。\nデータ活用では情報を収集、解析しそこから得た知見や仮説をとおしてアクションをより良いものにするというOODAループやアジャイル的な運営が前提となります。サイクルを通した改善スパイラルです。このスパイラルにおいて情報を定量的に扱うことができるという点がデータを活用するメリットです。具体的に見ていきましょう。\nサイクルをまわす それでは改善スパイラルとしてデータ分析をどのようなサイクルと考えればよいでしょうか？本記事ではOODAループを参考に、データ分析を「情報の収集・解析・意思決定・実行」の4ステップからなる1つのサイクルとして考えます。必要に応じてステップを戻っても構いません。重要なことは良いアクションを行うために良い意思決定をすることです。逆算して意思決定のクオリティを上げるために必要な情報を集めて解析していきます。\nさて、データの活用ではまず情報を収集し解析することから始まります。やみくもに情報を集めればよいわけではありません。前述したように、データを分析するということはよりよいアクションを起こすためにあり良い意思決定が目標となります。つまり意思決定に役に立たない情報を集めても意味がないのです。\n意思決定に役に立つ情報とはどういうものでしょう？抽象的に言うならば意思決定に影響を及ぼす情報です。その内容によっては意思決定が変化しうるものと言ってもよいでしょう。逆にいえば、その情報があってもなくても何も変化がないのであれば意思決定において価値は高くないということです。\n更に、情報の多くはそのままでは意思決定に役に立たないことがあります。集計や比較、可視化、もしくは統計学的な手法を通して意思決定に役に立つ形へ整形が必要です。\nたとえば商品ごとの売上データや顧客の来訪頻度、購買までの時間などの情報はそれ単体では大きな意味をもちません。地域ごとに比較したり来訪頻度から月の顧客ごとの単価を出したりと紐づけたり比較したりすることで意思決定に使えるような意味のある情報ができます。場合によっては統計的な手法をもちいて数理モデルを構築することで、将来の変化をシミュレーションしたり自分たちにとって重要な変数を探したりすることもあります。\n意思決定を下す前に意思決定を行えるだけの情報が集まっているのか確認することが必要です。不足があれば情報の収集や解析を行います。もちろん無限に時間と金があるわけではありませんので常に必要な情報がすべて揃うわけではありません。しかし、自分たちの意思決定においてクリティカルな情報がなんなのか優先度を考えることはできます。どんな情報があれば自分たちの考えが変わるのか検討しましょう。\n必要な情報がそろったら意思決定を行いそれに伴いアクションを実行します。これでループが1周完了しました。このようなループを必要に応じて何度も実行します。しかし、単純にループを回せばよいというものではありません。ゴールへにじりよるのはここからです。\n改善スパイラルとメリット アクションを実行したら情報の収集や解析がまた始まります。まず、やるべきは施策の効果を確認することです。自分たちの意思決定が正しかったのかどうか検証しましょう。不足があれば自分たちの仮説のどこに誤りがあったのか分析します。施策の効果を経験や勘ではなくデータを分析で定量かつ客観的に評価を行えるという点がデータ分析の強みです。そして同時に次の意思決定に必要な情報を集めます。施策の実行によって状況が変わっているはずです。同じ情報を扱う場合でも再び情報を収集する必要があります。\nアクションの前と後、見積もりと実績の両方を定量かつ客観的に得られるということがデータ活用の強力なポイントです。勘や経験に基づく判断に比べて施策の良し悪しを明確に理解し共有することができます。客観的であることで成功率の高い施策を選べるようになるだけでなく、定量的であることによってどの施策にどの程度投資すれば目的を達成することができるのか量の判断も精緻になります。つまり、予実の精度が向上するのです。\nこのようにしてデータを使うことで意思決定の精度が改善されます。成功率の高い施策を選べる、よりよい施策へ優先的に投資できる、妥当な投資の量を決められる。これこそが、データを活用することで得られる利益なのです。\nもしあなたがデータ活用とは何かを発見することや予知だと思っているならばその考えを捨てましょう。そして目の前の問題を解決するためにデータがあったらもっとよい意思決定ができないか検討すべきです。最初は上手くいかないでしょうし時間がかかるかもしれません。しかし次はきっと今より上手くやれるはずです。\n","permalink":"https://kenjiusui.github.io/blog/posts/biz/016_%E3%83%87%E3%83%BC%E3%82%BF%E3%81%AE%E6%B4%BB%E7%94%A8%E3%81%A8%E3%81%AF%E9%AD%94%E6%B3%95%E3%81%A7%E3%81%AF%E3%81%AA%E3%81%8F%E3%82%B4%E3%83%BC%E3%83%AB%E3%81%B8%E3%81%AB%E3%81%98%E3%82%8A%E3%82%88%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AE%E6%89%8B%E6%AE%B5%E3%81%A7%E3%81%82%E3%82%8B/","summary":"\u003cblockquote\u003e\n\u003cp\u003e本記事はウェブメディア「Modern Times」へ2023~2024年に寄稿したものを同メディアの閉鎖に伴い加筆・修正のうえ再掲したものです。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"データ活用の誤解\"\u003eデータ活用の誤解\u003c/h2\u003e\n\u003cp\u003e世間では、データの活用について大きな誤解をしている人をよく見かけます。なにかビジネスに関わる大きな問題を解決して自分たちに大きな利益をもたらすとか、未来予知ができてあわよくば自分たちに都合がいい方向へ未来を変えられるような、そんな魔法のような何かだと思われています。当たり前ですが、データを使ってもそんなおとぎ話のようなことは起きません。\u003c/p\u003e\n\u003cp\u003eそれでは、データを活用することでどんな利益を得られるのでしょうか？データから得られる利益はもっと地道で現実的です。データを活用するということはシンプルに言ってしまえばゴールへじわじわとにじりよるということです。ビジネスでは達成したい目標に向かって施策を打ち、そこへ少しずつ近づくものですが、データを利用することでその精度を高めることができます。\u003c/p\u003e\n\u003cp\u003eデータ活用では情報を収集、解析しそこから得た知見や仮説をとおしてアクションをより良いものにするというOODAループやアジャイル的な運営が前提となります。サイクルを通した改善スパイラルです。このスパイラルにおいて情報を定量的に扱うことができるという点がデータを活用するメリットです。具体的に見ていきましょう。\u003c/p\u003e\n\u003ch2 id=\"サイクルをまわす\"\u003eサイクルをまわす\u003c/h2\u003e\n\u003cp\u003eそれでは改善スパイラルとしてデータ分析をどのようなサイクルと考えればよいでしょうか？本記事ではOODAループを参考に、データ分析を「情報の収集・解析・意思決定・実行」の4ステップからなる1つのサイクルとして考えます。必要に応じてステップを戻っても構いません。重要なことは良いアクションを行うために良い意思決定をすることです。逆算して意思決定のクオリティを上げるために必要な情報を集めて解析していきます。\u003c/p\u003e\n\u003cp\u003eさて、データの活用ではまず情報を収集し解析することから始まります。やみくもに情報を集めればよいわけではありません。前述したように、データを分析するということはよりよいアクションを起こすためにあり良い意思決定が目標となります。つまり意思決定に役に立たない情報を集めても意味がないのです。\u003c/p\u003e\n\u003cp\u003e意思決定に役に立つ情報とはどういうものでしょう？抽象的に言うならば意思決定に影響を及ぼす情報です。その内容によっては意思決定が変化しうるものと言ってもよいでしょう。逆にいえば、その情報があってもなくても何も変化がないのであれば意思決定において価値は高くないということです。\u003c/p\u003e\n\u003cp\u003e更に、情報の多くはそのままでは意思決定に役に立たないことがあります。集計や比較、可視化、もしくは統計学的な手法を通して意思決定に役に立つ形へ整形が必要です。\u003c/p\u003e\n\u003cp\u003eたとえば商品ごとの売上データや顧客の来訪頻度、購買までの時間などの情報はそれ単体では大きな意味をもちません。地域ごとに比較したり来訪頻度から月の顧客ごとの単価を出したりと紐づけたり比較したりすることで意思決定に使えるような意味のある情報ができます。場合によっては統計的な手法をもちいて数理モデルを構築することで、将来の変化をシミュレーションしたり自分たちにとって重要な変数を探したりすることもあります。\u003c/p\u003e\n\u003cp\u003e意思決定を下す前に意思決定を行えるだけの情報が集まっているのか確認することが必要です。不足があれば情報の収集や解析を行います。もちろん無限に時間と金があるわけではありませんので常に必要な情報がすべて揃うわけではありません。しかし、自分たちの意思決定においてクリティカルな情報がなんなのか優先度を考えることはできます。どんな情報があれば自分たちの考えが変わるのか検討しましょう。\u003c/p\u003e\n\u003cp\u003e必要な情報がそろったら意思決定を行いそれに伴いアクションを実行します。これでループが1周完了しました。このようなループを必要に応じて何度も実行します。しかし、単純にループを回せばよいというものではありません。ゴールへにじりよるのはここからです。\u003c/p\u003e\n\u003ch2 id=\"改善スパイラルとメリット\"\u003e改善スパイラルとメリット\u003c/h2\u003e\n\u003cp\u003eアクションを実行したら情報の収集や解析がまた始まります。まず、やるべきは施策の効果を確認することです。自分たちの意思決定が正しかったのかどうか検証しましょう。不足があれば自分たちの仮説のどこに誤りがあったのか分析します。施策の効果を経験や勘ではなくデータを分析で定量かつ客観的に評価を行えるという点がデータ分析の強みです。そして同時に次の意思決定に必要な情報を集めます。施策の実行によって状況が変わっているはずです。同じ情報を扱う場合でも再び情報を収集する必要があります。\u003c/p\u003e\n\u003cp\u003eアクションの前と後、見積もりと実績の両方を定量かつ客観的に得られるということがデータ活用の強力なポイントです。勘や経験に基づく判断に比べて施策の良し悪しを明確に理解し共有することができます。客観的であることで成功率の高い施策を選べるようになるだけでなく、定量的であることによってどの施策にどの程度投資すれば目的を達成することができるのか量の判断も精緻になります。つまり、予実の精度が向上するのです。\u003c/p\u003e\n\u003cp\u003eこのようにしてデータを使うことで意思決定の精度が改善されます。成功率の高い施策を選べる、よりよい施策へ優先的に投資できる、妥当な投資の量を決められる。これこそが、データを活用することで得られる利益なのです。\u003c/p\u003e\n\u003cp\u003eもしあなたがデータ活用とは何かを発見することや予知だと思っているならばその考えを捨てましょう。そして目の前の問題を解決するためにデータがあったらもっとよい意思決定ができないか検討すべきです。最初は上手くいかないでしょうし時間がかかるかもしれません。しかし次はきっと今より上手くやれるはずです。\u003c/p\u003e","title":"データの活用とは魔法ではなくゴールへにじりよるための手段である"},{"content":" 本記事はウェブメディア「Modern Times」へ2023~2024年に寄稿したものを同メディアの閉鎖に伴い加筆・修正のうえ再掲したものです。\n様々な企業でデータアナリティクスチームが新しく設立されています。データを活用して大きく成長する企業があれば成果が出せずにチームを解散させる企業もあります。両者の違いはなんでしょうか。その答えの1つは組織の関係性です。本記事では事業を成長へ導くためにデータアナリティクスチームを社内で信頼できるパートナーに育てるべきだという話を紹介します。\n失敗するデータアナリティクス部門 データの活用が大きく注目されてから数年が経ち、多くの企業で社内外のデータを分析し自分たちのビジネスに活かすため新たにデータアナリティクスチームが創設されてきました。分析者の採用は活発化し関連する設備への投資は盛り上がりました。一方で、チームを作り人材も設備も用意されたというのに成果が挙げられずデータアナリティクスチームの閉鎖や縮小、企業内での立場が弱くなるという結果になっています。なぜ、このようなことになってしまったのでしょうか。\nデータの活用に実は価値がなかったのでしょうか？いいえ、そんなことはないはずです。実際にいくつかの企業ではデータを活用し大きな成長を遂げています。では、成功した企業と失敗した企業では何が違ったのでしょうか。この質問に対する答えは無数にあります。すでに多くの例がインターネットや書籍に書かれています。良い人材を採用できなかった、解くべき課題が立てられなかった、現場が協力を拒んだ…など様々です。\nこの記事で紹介するデータアナリティクスチームを成功させる秘訣は事業部とのパートナーシップを強化し並走することです。事業部からの依頼をこなすだけの下請け組織からの脱却であり、共に事業を成長させるための頼れる専門家集団への進化です。\n下請け化がもたらす弊害 まずはデータアナリティクスチームの下請け化という現象について解説します。多くの企業では事業部がビジネスを営んでおり支援組織としてあとからデータアナリティクスチームを設立することが多いです。そのため、組織内の力関係として事業部本体のほうが強くデータアナリティクスチームが弱い立場になりやすいです。\nデータアナリティクスチームの立ち上がりの初期は事業部に対するドメイン知識が不足しています。一方で事業部側にはデータアナリティクスの知見が不足しているでしょう。そのためデータアナリティクスチームが事業部が知りたいことをヒアリングして具体的な分析方法はチームに一任されるという依頼ベースの仕事の進め方になっていきます。\nこのようにして事業部が主導権を持っている状態が常態化すると次第にデータアナリティクスチームは事業部の下請け組織となっていきます。事業部に言われるがままにデータ集計や分析を行うだけの状態です。この状態が長く続くといつまで経っても事業部とデータアナリティクスチームの間にシナジーが生まれず生産性は上がらないどころかむしろ下がっていきます。\nなぜ下請け状態になると生産性が下がってしまいやすいのでしょうか。ビジネスでデータを活かすには事業部とデータアナリティクスチームの双方が成長していくことが重要だからです。分析結果を行動に移し行動した結果を分析するというサイクルから学ぶ必要があります。その中でデータの知見がない事業部と事業の知見がないデータアナリティクスチームの間でコミュニケーションが難しくなることは大きな問題になるのです。\n依頼者と下請けという関係性では前提知識や価値観、優先度の違いから課題感の共有が難しく、お互いの立場の強さや信頼関係から積極的な意見や提案、その実行の柔軟さや迅速性に欠けることになります。本来、意思決定者と分析者は対等な立場であり顧客への還元という共通の目的をもっているはずですが、次第に意思決定者が顧客のように振る舞いはじめます。外部ベンダーを通したITシステムの開発が難しいように、このような状態では柔軟かつ迅速なデータ活用は簡単ではありません。\nそれでは、どのようにしてこの問題を解決していけばよいのでしょうか？私の考える解決方法は事業部とデータアナリティクスチームがパートナーとして並走することです。事業部とデータアナリティクスチームが普段から課題感を共有し同じ方向を向いて課題解決に取り組んでいる状態です。\n分析とアクションのサイクルを通して成長していくためにはアクションを起こしやすい分析を行い、分析のしやすいアクションを計画していく必要があります。このためにはお互い密な連携が必須です。依頼者と下請けという立場では実現が難しいですが、お互いに並走することで強力なシナジーを生み出すことが可能です。\nパートナーとして並走する 事業部にデータアナリティクスチームがパートナーとして並走することで上手くいくと述べましたが、実際の問題として「明日からパートナーとしてやっていきましょう」と同じ会議室に詰め込んだところで簡単に成し遂げられるわけではありません。最初はお互いに関係性もなくナレッジの共有もできていませんから、挑戦と実績を積み重ねる必要があります。\n重要なことは小さく挑戦し失敗と成功を積み重ねることです。事業部はデータアナリティクスチームと共にやっていくことにメリットを得られるのか不安を抱えています。データ活用に知見がないのでそこに腹落ちするビジョンを描けていません。一方でデータアナリティクスチームは新しく作られたチームですので早く成果を生み出して信頼を勝ち取る必要があります。このような状況で両チームに必要なのは小さくてもよいので実際に手を動かして実績を積み上げていくことです。良い結果が望ましいですが失敗しても構いません。\nもちろん、挑戦しただけでは意味がありません。その結果を受けて振り返りを行い改善サイクルを回していきます。分析結果を生かしてアクションを起こす、アクションを起こした結果を分析する。このサイクルを回して効率よく効果的なデータアナリティクスの活用を見出します。これは単純に良い結果を出すという意味ではありません。良いやり方を見つけるということです。人材の配置やデータ連携など設備はもちろん、見るべき指標の精査やデータの処理方法、タスクの決め方や管理方法など、データを活用するということは今まで仕事の進め方を変えるということですので考えなければいけないことは多岐にわたります。\nこのようにして深いパートナーシップを結び成果を生み出せるようになるためには経営層からの強いバックアップが必要不可欠です。事業部とデータアナリティクスチームの双方に方向性を示し軌道修正していくということです。事業の成長のためにそしてユーザのために長期的に改革していくのだということを説明しそのように実行できるよう協力することが経営層の仕事です。事業部とデータアナリティクスチームに丸投げしてはうまくいきません。データ活用の成功も失敗も最終的には経営層の責任なのです。\n","permalink":"https://kenjiusui.github.io/blog/posts/biz/015_%E4%BA%8B%E6%A5%AD%E3%82%92%E6%88%90%E9%95%B7%E3%81%AB%E5%B0%8E%E3%81%8F%E3%82%A2%E3%83%8A%E3%83%AA%E3%83%86%E3%82%A3%E3%82%AF%E3%82%B9%E3%83%81%E3%83%BC%E3%83%A0%E3%81%A8%E3%81%AF/","summary":"\u003cblockquote\u003e\n\u003cp\u003e本記事はウェブメディア「Modern Times」へ2023~2024年に寄稿したものを同メディアの閉鎖に伴い加筆・修正のうえ再掲したものです。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e様々な企業でデータアナリティクスチームが新しく設立されています。データを活用して大きく成長する企業があれば成果が出せずにチームを解散させる企業もあります。両者の違いはなんでしょうか。その答えの1つは組織の関係性です。本記事では事業を成長へ導くためにデータアナリティクスチームを社内で信頼できるパートナーに育てるべきだという話を紹介します。\u003c/p\u003e\n\u003ch2 id=\"失敗するデータアナリティクス部門\"\u003e失敗するデータアナリティクス部門\u003c/h2\u003e\n\u003cp\u003eデータの活用が大きく注目されてから数年が経ち、多くの企業で社内外のデータを分析し自分たちのビジネスに活かすため新たにデータアナリティクスチームが創設されてきました。分析者の採用は活発化し関連する設備への投資は盛り上がりました。一方で、チームを作り人材も設備も用意されたというのに成果が挙げられずデータアナリティクスチームの閉鎖や縮小、企業内での立場が弱くなるという結果になっています。なぜ、このようなことになってしまったのでしょうか。\u003c/p\u003e\n\u003cp\u003eデータの活用に実は価値がなかったのでしょうか？いいえ、そんなことはないはずです。実際にいくつかの企業ではデータを活用し大きな成長を遂げています。では、成功した企業と失敗した企業では何が違ったのでしょうか。この質問に対する答えは無数にあります。すでに多くの例がインターネットや書籍に書かれています。良い人材を採用できなかった、解くべき課題が立てられなかった、現場が協力を拒んだ…など様々です。\u003c/p\u003e\n\u003cp\u003eこの記事で紹介するデータアナリティクスチームを成功させる秘訣は事業部とのパートナーシップを強化し並走することです。事業部からの依頼をこなすだけの下請け組織からの脱却であり、共に事業を成長させるための頼れる専門家集団への進化です。\u003c/p\u003e\n\u003ch2 id=\"下請け化がもたらす弊害\"\u003e下請け化がもたらす弊害\u003c/h2\u003e\n\u003cp\u003eまずはデータアナリティクスチームの下請け化という現象について解説します。多くの企業では事業部がビジネスを営んでおり支援組織としてあとからデータアナリティクスチームを設立することが多いです。そのため、組織内の力関係として事業部本体のほうが強くデータアナリティクスチームが弱い立場になりやすいです。\u003c/p\u003e\n\u003cp\u003eデータアナリティクスチームの立ち上がりの初期は事業部に対するドメイン知識が不足しています。一方で事業部側にはデータアナリティクスの知見が不足しているでしょう。そのためデータアナリティクスチームが事業部が知りたいことをヒアリングして具体的な分析方法はチームに一任されるという依頼ベースの仕事の進め方になっていきます。\u003c/p\u003e\n\u003cp\u003eこのようにして事業部が主導権を持っている状態が常態化すると次第にデータアナリティクスチームは事業部の下請け組織となっていきます。事業部に言われるがままにデータ集計や分析を行うだけの状態です。この状態が長く続くといつまで経っても事業部とデータアナリティクスチームの間にシナジーが生まれず生産性は上がらないどころかむしろ下がっていきます。\u003c/p\u003e\n\u003cp\u003eなぜ下請け状態になると生産性が下がってしまいやすいのでしょうか。ビジネスでデータを活かすには事業部とデータアナリティクスチームの双方が成長していくことが重要だからです。分析結果を行動に移し行動した結果を分析するというサイクルから学ぶ必要があります。その中でデータの知見がない事業部と事業の知見がないデータアナリティクスチームの間でコミュニケーションが難しくなることは大きな問題になるのです。\u003c/p\u003e\n\u003cp\u003e依頼者と下請けという関係性では前提知識や価値観、優先度の違いから課題感の共有が難しく、お互いの立場の強さや信頼関係から積極的な意見や提案、その実行の柔軟さや迅速性に欠けることになります。本来、意思決定者と分析者は対等な立場であり顧客への還元という共通の目的をもっているはずですが、次第に意思決定者が顧客のように振る舞いはじめます。外部ベンダーを通したITシステムの開発が難しいように、このような状態では柔軟かつ迅速なデータ活用は簡単ではありません。\u003c/p\u003e\n\u003cp\u003eそれでは、どのようにしてこの問題を解決していけばよいのでしょうか？私の考える解決方法は事業部とデータアナリティクスチームがパートナーとして並走することです。事業部とデータアナリティクスチームが普段から課題感を共有し同じ方向を向いて課題解決に取り組んでいる状態です。\u003c/p\u003e\n\u003cp\u003e分析とアクションのサイクルを通して成長していくためにはアクションを起こしやすい分析を行い、分析のしやすいアクションを計画していく必要があります。このためにはお互い密な連携が必須です。依頼者と下請けという立場では実現が難しいですが、お互いに並走することで強力なシナジーを生み出すことが可能です。\u003c/p\u003e\n\u003ch2 id=\"パートナーとして並走する\"\u003eパートナーとして並走する\u003c/h2\u003e\n\u003cp\u003e事業部にデータアナリティクスチームがパートナーとして並走することで上手くいくと述べましたが、実際の問題として「明日からパートナーとしてやっていきましょう」と同じ会議室に詰め込んだところで簡単に成し遂げられるわけではありません。最初はお互いに関係性もなくナレッジの共有もできていませんから、挑戦と実績を積み重ねる必要があります。\u003c/p\u003e\n\u003cp\u003e重要なことは小さく挑戦し失敗と成功を積み重ねることです。事業部はデータアナリティクスチームと共にやっていくことにメリットを得られるのか不安を抱えています。データ活用に知見がないのでそこに腹落ちするビジョンを描けていません。一方でデータアナリティクスチームは新しく作られたチームですので早く成果を生み出して信頼を勝ち取る必要があります。このような状況で両チームに必要なのは小さくてもよいので実際に手を動かして実績を積み上げていくことです。良い結果が望ましいですが失敗しても構いません。\u003c/p\u003e\n\u003cp\u003eもちろん、挑戦しただけでは意味がありません。その結果を受けて振り返りを行い改善サイクルを回していきます。分析結果を生かしてアクションを起こす、アクションを起こした結果を分析する。このサイクルを回して効率よく効果的なデータアナリティクスの活用を見出します。これは単純に良い結果を出すという意味ではありません。良いやり方を見つけるということです。人材の配置やデータ連携など設備はもちろん、見るべき指標の精査やデータの処理方法、タスクの決め方や管理方法など、データを活用するということは今まで仕事の進め方を変えるということですので考えなければいけないことは多岐にわたります。\u003c/p\u003e\n\u003cp\u003eこのようにして深いパートナーシップを結び成果を生み出せるようになるためには経営層からの強いバックアップが必要不可欠です。事業部とデータアナリティクスチームの双方に方向性を示し軌道修正していくということです。事業の成長のためにそしてユーザのために長期的に改革していくのだということを説明しそのように実行できるよう協力することが経営層の仕事です。事業部とデータアナリティクスチームに丸投げしてはうまくいきません。データ活用の成功も失敗も最終的には経営層の責任なのです。\u003c/p\u003e","title":"事業を成長に導くアナリティクスチームとは？"},{"content":"前回の記事ではデータ分析基盤開発において小さく動くものから作ることの必要性を解説しました。\nでは、データ分析基盤におけるMVPとはなんでしょうか？\n一言でいうならば、意思決定者がデータを取得し意思決定に活かせる最小構成です。\nここでは2つの要素を取り上げます。\n得られるデータがビジネスの意思決定の役に立つ これは言うまでもないことですがビジネスの意思決定の役に立つことが目的です。\nそのため、大なり小なり意思決定へ寄与することが求められます。\nなんの役にも立たないデータしか取得できない分析基盤はMVPになりえないという話です。\nもちろんMVPですからクリティカルで重要な知見を提供する必要はありません。\nイノベーティブな指標を計算しようとすると仕様を決めるのに時間がかかるので数字がある程度わかっているものを選んだほうがよいくらいです。\nスプレッドシートで計算しているものを自動化できるくらいでも良いでしょう。\n自動化されれば手間や品質の改善が起きるのでこれも重要な成果です。\n大事なのは役に立っているということです。\nこの基準はクイックウィン的な発想も入っています。\nなにかしら役に立つことを証明し具体的なイメージをもってもらうことでその後の進行が円滑になりますし課題も見えてきます。\n誰も注目しない数字では次のステップへのブーストになりません。\n「この数字が見られるならこっちも見てみたいな」\nそう思ってもらえるようなものをアウトプットすることで初めて積極的な投資が得られます。\n実はデータ分析基盤のMVPとは利用者側の体勢の検証でもあります。\nデータドリブンな意思決定パイプラインは作れるか？\n自分たちの意思決定に必要なデータはなにか定義できるか？\n現場のデータ入力を掌握できているか？\nこういった問いを自分たちに突きつけるシーンです。\nデータソースからBIまで取得・保存・加工・可視化が一気通貫に動く ビジネスの意思決定に役立つことが重要だと述べましたが、そのためには使う側にデータを届けられるシステムが必要です。\nこれを満たすにはデータ分析にかかる一連の処理が一気通貫に動いていることが求められます。\n重要なのは要件が把握されコントロールできていることです。\nデータ分析基盤を実装するにあたって最大の壁がデータの取り扱いです。\n実際に実装を始めると想定外のデータの仕様にぶつかります。\nデータソースからデータが取得できない 取得したデータのスキーマがおかしい 入っているデータの仕様がわからない \u0026hellip;etcとさまざまな問題が噴出します。\nこれらの問題について必要な項目は仕様を調査したり対応を実装していきます。\nポイントはやりたい分析に必要な仕様がわかっており、必要なデータの取得 ~ 可視化までの処理が可能な限り自動化されていることです。\n仕様を把握する MVPなので入っているデータについてすべて整形し仕様を把握する必要はありません。\nはっきりいってデータの仕様はすべてを理解しようとすると莫大な時間がかかります。\n仕様書に書いてあることと実態がズレていることなんて当然に起きますし仕様書がないことも頻繁です。\n達成したい最低限の問題についてだけ答えられればよいのでそこに絞って調査をおこないます。\n指標の集計に必要な仕様の把握は必須です。\nデータの結合方法や集約キーの仕様、絞り込みに使うパラメータなどがあります。\n使えるとおもっていたデータが実は集計に使えなかったということはよくあります。\nたとえば、顧客の属性情報がCRMに入力されているが自由記述なので内容がバラバラで簡単に集約できないということはありがちです。\n実際のデータを見るまでは油断しないほうがいいでしょう。\nまた、データ自体の仕様の整理も必要です。\n取得するデータがどんな状態なのか実際にやってみるまでわからないことがほとんどです。\n言い換えると仕様と実態がズレていたり仕様が明瞭でないことが頻繁に起きます。\nスキーマの破損やデータの欠損などのデータ品質は前処理や集計に関わってきますし、場合によっては自動化の可・不可にまで影響します。\n人によって入力にばらつきがあるようなデータの不整合は一括で対応できないため自動化ができなくなります。\nこのようなデータの状態は実際のデータを見ないとわかりません。\n実態を見ながら対応を考え、MVPとしてどのように進めるのか？着地をどうするのか考えていきます。\n自動化する データ分析基盤をシステムとして実装している以上は当然自動化が期待されています。\n最初から完全な自動化が必要というわけではありませんが可能な限り手作業は排除すべきでしょう。\n処理をコードとして実装し自動で実行できる環境を構築していきます。\n人がやっているからといって自動化できるとは限りません。\nそれぞれのステップの処理を自動化できるのかどうか、という観点だけでなくステップ同士をスムーズに連携できるかどうかもポイントです。\n定期実行の設定も重要です。\nデータを閲覧したい時間や更新タイミング、処理の時間は重要な課題です。\nあるデータは朝に更新され別のデータは夕方に更新されるので統合した結果がわかるのは次の日になってしまう、なんてケースは珍しくありません。\ncronなどスケジューラーでもよいので自分たちの用途に合わせて自動化が構築され、あわせて今後の拡張の方向性が見えていることが望ましいでしょう。\nとはいえ、自動化が難しいケースは珍しくありません。\n前述したようにデータソースの品質の問題で自動化ができないようなデータはよくあります。\n無理に自動化を目指してスケジュールが遅れるくらいなら手動でも良いとおもいます。\nその場合は手作業を前提に誰がいつどのように行うのか？などを明確に整理し動作を検証する必要があります。\n一方で自動化の仕組みはあるがエラーばかりで全然動かない状態は問題があります。\nMVPとはいえスコープの範囲ではそれなりに想定されたとおりにシステムが動いている必要があります。\nMVPの確認 上記に関する点を踏まえて進捗したあとどのような観点でチェックすべきでしょうか？\n端的にいうなら意思決定者がデータを取得し意思決定に活かせるという実感があるかどうかです。\nまずは意思決定者が自分でデータを取得することができるのか確認しましょう。\n毎回エラーが起きてデータを出すために誰かの手を借りているようでは片手落ちです。\nBIツールを開いたら必要な表やグラフが得られる状態を確認しましょう。\n同時にその数値を意思決定者が活かせることを確認しましょう。\n数値をだしても意思決定者が見ていない、使えてないのでは意味がありません。\nその数値が意思決定に使われていることを確認します。\n以上の要素を確認できたらMVPとして完成したといってもよいでしょう。\nデータドリブンな意思決定を支える重要なシステム開発の偉大な一歩を進めることができました。\nぜひチームでお互いを祝い、称賛しましょう。\nここまで来たら次はなにをするべきでしょうか？\n機能の拡張とMVPの過程で見つかった課題を解決です。\n指標やデータソースの拡張はもちろん、セキュリティや監視の改善、データモデリングによる実装の効率化などやることはたくさんあります。\nメンバーで優先度を決めて対応していきましょう。\nこのステップでの考え方はまた機会があれば記事にしようとおもいます。\n","permalink":"https://kenjiusui.github.io/blog/posts/biz/014_%E3%83%87%E3%83%BC%E3%82%BF%E5%88%86%E6%9E%90%E5%9F%BA%E7%9B%A4%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8Bmvp%E3%81%AE%E8%80%83%E3%81%88%E6%96%B9/","summary":"\u003cp\u003e前回の記事ではデータ分析基盤開発において小さく動くものから作ることの必要性を解説しました。\u003c/p\u003e\n\u003cp\u003eでは、データ分析基盤におけるMVPとはなんでしょうか？\u003cbr\u003e\n一言でいうならば、意思決定者がデータを取得し意思決定に活かせる最小構成です。\u003cbr\u003e\nここでは2つの要素を取り上げます。\u003c/p\u003e\n\u003ch2 id=\"得られるデータがビジネスの意思決定の役に立つ\"\u003e得られるデータがビジネスの意思決定の役に立つ\u003c/h2\u003e\n\u003cp\u003eこれは言うまでもないことですがビジネスの意思決定の役に立つことが目的です。\u003cbr\u003e\nそのため、大なり小なり意思決定へ寄与することが求められます。\u003cbr\u003e\nなんの役にも立たないデータしか取得できない分析基盤はMVPになりえないという話です。\u003c/p\u003e\n\u003cp\u003eもちろんMVPですからクリティカルで重要な知見を提供する必要はありません。\u003cbr\u003e\nイノベーティブな指標を計算しようとすると仕様を決めるのに時間がかかるので数字がある程度わかっているものを選んだほうがよいくらいです。\u003cbr\u003e\nスプレッドシートで計算しているものを自動化できるくらいでも良いでしょう。\u003cbr\u003e\n自動化されれば手間や品質の改善が起きるのでこれも重要な成果です。\u003cbr\u003e\n大事なのは役に立っているということです。\u003c/p\u003e\n\u003cp\u003eこの基準はクイックウィン的な発想も入っています。\u003cbr\u003e\nなにかしら役に立つことを証明し具体的なイメージをもってもらうことでその後の進行が円滑になりますし課題も見えてきます。\u003cbr\u003e\n誰も注目しない数字では次のステップへのブーストになりません。\u003cbr\u003e\n「この数字が見られるならこっちも見てみたいな」\u003cbr\u003e\nそう思ってもらえるようなものをアウトプットすることで初めて積極的な投資が得られます。\u003c/p\u003e\n\u003cp\u003e実はデータ分析基盤のMVPとは利用者側の体勢の検証でもあります。\u003cbr\u003e\nデータドリブンな意思決定パイプラインは作れるか？\u003cbr\u003e\n自分たちの意思決定に必要なデータはなにか定義できるか？\u003cbr\u003e\n現場のデータ入力を掌握できているか？\u003cbr\u003e\nこういった問いを自分たちに突きつけるシーンです。\u003c/p\u003e\n\u003ch2 id=\"データソースからbiまで取得保存加工可視化が一気通貫に動く\"\u003eデータソースからBIまで取得・保存・加工・可視化が一気通貫に動く\u003c/h2\u003e\n\u003cp\u003eビジネスの意思決定に役立つことが重要だと述べましたが、そのためには使う側にデータを届けられるシステムが必要です。\u003cbr\u003e\nこれを満たすにはデータ分析にかかる一連の処理が一気通貫に動いていることが求められます。\u003cbr\u003e\n重要なのは要件が把握されコントロールできていることです。\u003c/p\u003e\n\u003cp\u003eデータ分析基盤を実装するにあたって最大の壁がデータの取り扱いです。\u003cbr\u003e\n実際に実装を始めると想定外のデータの仕様にぶつかります。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eデータソースからデータが取得できない\u003c/li\u003e\n\u003cli\u003e取得したデータのスキーマがおかしい\u003c/li\u003e\n\u003cli\u003e入っているデータの仕様がわからない\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u0026hellip;etcとさまざまな問題が噴出します。\u003cbr\u003e\nこれらの問題について必要な項目は仕様を調査したり対応を実装していきます。\u003c/p\u003e\n\u003cp\u003eポイントはやりたい分析に必要な仕様がわかっており、必要なデータの取得 ~ 可視化までの処理が可能な限り自動化されていることです。\u003c/p\u003e\n\u003ch3 id=\"仕様を把握する\"\u003e仕様を把握する\u003c/h3\u003e\n\u003cp\u003eMVPなので入っているデータについてすべて整形し仕様を把握する必要はありません。\u003cbr\u003e\nはっきりいってデータの仕様はすべてを理解しようとすると莫大な時間がかかります。\u003cbr\u003e\n仕様書に書いてあることと実態がズレていることなんて当然に起きますし仕様書がないことも頻繁です。\u003cbr\u003e\n達成したい最低限の問題についてだけ答えられればよいのでそこに絞って調査をおこないます。\u003c/p\u003e\n\u003cp\u003e指標の集計に必要な仕様の把握は必須です。\u003cbr\u003e\nデータの結合方法や集約キーの仕様、絞り込みに使うパラメータなどがあります。\u003cbr\u003e\n使えるとおもっていたデータが実は集計に使えなかったということはよくあります。\u003cbr\u003e\nたとえば、顧客の属性情報がCRMに入力されているが自由記述なので内容がバラバラで簡単に集約できないということはありがちです。\u003cbr\u003e\n実際のデータを見るまでは油断しないほうがいいでしょう。\u003c/p\u003e\n\u003cp\u003eまた、データ自体の仕様の整理も必要です。\u003cbr\u003e\n取得するデータがどんな状態なのか実際にやってみるまでわからないことがほとんどです。\u003cbr\u003e\n言い換えると仕様と実態がズレていたり仕様が明瞭でないことが頻繁に起きます。\u003cbr\u003e\nスキーマの破損やデータの欠損などのデータ品質は前処理や集計に関わってきますし、場合によっては自動化の可・不可にまで影響します。\u003cbr\u003e\n人によって入力にばらつきがあるようなデータの不整合は一括で対応できないため自動化ができなくなります。\u003c/p\u003e\n\u003cp\u003eこのようなデータの状態は実際のデータを見ないとわかりません。\u003cbr\u003e\n実態を見ながら対応を考え、MVPとしてどのように進めるのか？着地をどうするのか考えていきます。\u003c/p\u003e\n\u003ch3 id=\"自動化する\"\u003e自動化する\u003c/h3\u003e\n\u003cp\u003eデータ分析基盤をシステムとして実装している以上は当然自動化が期待されています。\u003cbr\u003e\n最初から完全な自動化が必要というわけではありませんが可能な限り手作業は排除すべきでしょう。\u003cbr\u003e\n処理をコードとして実装し自動で実行できる環境を構築していきます。\u003cbr\u003e\n人がやっているからといって自動化できるとは限りません。\u003cbr\u003e\nそれぞれのステップの処理を自動化できるのかどうか、という観点だけでなくステップ同士をスムーズに連携できるかどうかもポイントです。\u003c/p\u003e\n\u003cp\u003e定期実行の設定も重要です。\u003cbr\u003e\nデータを閲覧したい時間や更新タイミング、処理の時間は重要な課題です。\u003cbr\u003e\nあるデータは朝に更新され別のデータは夕方に更新されるので統合した結果がわかるのは次の日になってしまう、なんてケースは珍しくありません。\u003cbr\u003e\ncronなどスケジューラーでもよいので自分たちの用途に合わせて自動化が構築され、あわせて今後の拡張の方向性が見えていることが望ましいでしょう。\u003c/p\u003e\n\u003cp\u003eとはいえ、自動化が難しいケースは珍しくありません。\u003cbr\u003e\n前述したようにデータソースの品質の問題で自動化ができないようなデータはよくあります。\u003cbr\u003e\n無理に自動化を目指してスケジュールが遅れるくらいなら手動でも良いとおもいます。\u003cbr\u003e\nその場合は手作業を前提に誰がいつどのように行うのか？などを明確に整理し動作を検証する必要があります。\u003c/p\u003e\n\u003cp\u003e一方で自動化の仕組みはあるがエラーばかりで全然動かない状態は問題があります。\u003cbr\u003e\nMVPとはいえスコープの範囲ではそれなりに想定されたとおりにシステムが動いている必要があります。\u003c/p\u003e","title":"データ分析基盤におけるMVPの考え方"},{"content":"動くものを作らないから失敗する 失敗するデータ分析基盤プロジェクトに共通する重要な特徴の1つは「動くものから作らない」ということです。\n何年もかけて巨大な基盤を構築しすべてが完成してから稼働させるようなやり方は経験上うまくいきません。\n開発の前にすべての要件を定義し仕様を決めようとする。\nデータ分析基盤の実装をレイヤーごとに進めようとする。\nこういった進め方をしようとする人は少なくありませんが実際のところうまくいきません。\nなぜ、このような進め方をするとなぜ失敗するのでしょうか？\n3つの要素にわけて解説します。\n時間をかけると作った頃には役に立たない まず根本的な問題として、データ分析基盤を何年もかけて作ったとしても完成した頃には情勢が変わっており使い物にならない可能性が高いという点があげられます。\nこれはビジネスを取り巻く環境の影響を受けること、そしてデータ分析基盤は社内の様々なシステムの影響を受けることから発生します。\n現代の市場は凄まじい速度で変化しておりビジネスの戦略もそれに合わせて日々変わっていきます。\nビジネス戦略が変われば知りたい情報もどんどん変わっていきます。\n何年も前に決めた指標や分析方法が役に立つでしょうか？\n少なくない割合で変更が求められることは想像に難くないでしょう。\nこのようにして作った瞬間から役に立たないダッシュボードができあがります。\nまた、社内システムが変更されれば取得するデータの性質は変わっていきます。\n1つ1つの変更の周期は短くなくとも様々なシステムによってなりたっている現代では毎年のように何らかのシステムが変更されていきます。\n変更に限らず新たなシステムを導入することも珍しくないでしょう。\nデータ分析基盤は様々なシステムの下流に位置するためそれらの影響を強烈に受けます。\nまた、社内のシステムは変わらずとも法律や規制などによって変更や修正が要求されることもあります。\n分析に必要なデータソースが増えたり減ったり変更されることで、データの取得方法や前処理、集計の定義すら変わるのです。\nフィードバックループを回せ 次に重要な問題の1つとしてフィードバックループが回らないことが挙げられます。\n完成まで誰も触らなければ誰も検証できずフィードバックができません。\n途中で誰かが実際に利用しはじめていれば意思決定に使える分析ができるのか確認できますし問題があれば修正ができます。\n開発の前に完全な要求や仕様を定義することはできません。\n事前の想定が間違っていたという自体は当然のように発生します。\n最初にすべてを定義して設計、実装を行うという方法は絶対に過不足が発生します。\n分析する側も分析基盤を開発する側も両方でこの問題が発生します。\n分析する側は実際に分析して意思決定に活かしてみると最初に想定していた指標では上手くいかない、なんてことはよく起きます。\nこれは「考える人のスキルが足りず想定不足だった」という話ではありません。\n前述したように事業や環境が変わって分析の切り口が変わるケースはその典型例です。\n探索的に分析を行うことで初めて見えてくるものもあります。\nやってみないとわからないことがたくさんあるのです。\n分析基盤を構築する側としては当然上記の分析する側の状況が変化すれば作るものも変わってきます。\n見たい指標が変わればデータマートやダッシュボードの実装は変化するでしょう。\n場合によっては中間テーブルでのデータの持ち方や前処理の方法を変更する必要があるかもしれません。\n想定よりも負荷が高くてうまく運用が回らないというケースもありえます。\nこれらの問題を使う前にすべて洗い出すのはおおよそ不可能であるといってよいでしょう。\n少なくともすべてを洗い出すコストとリスクを考えると作って使ったみたほうが早くて確実です。\n地に足のついた議論をする もう1つ重要な問題として進める優先度や方向性を揃えることが難しいという点があります。\nデータ分析基盤は社内の多くのステークホルダーを巻き込んで開発されるものです。\n意思決定に活かすという性質から上位レイヤーの人間への影響をもちます。\nその中データ分析基盤ではどれをどの順番で作るのか決めていく必要があります。\nこれが実際に動くものと検証ができない状態だと物事を進めるのが簡単ではありません。\nデータ分析基盤の開発に着手するとき、多くのステークホルダーは具体的なイメージを持てていません。\nまして自分たちのチーム以外との連携などほぼ不可能といってよいでしょう。\nしかし実際に開発を進めるには社内のそれぞれのステークホルダーの要望から優先度を決める必要があります。\n具体的なモノがない状態だと各々の認識をぶつけることになり議論が空中戦になりがちです。\n結果として社内の力学がそのまま反映されてしまいあるべき姿から歪んでしまいます。\nしかし、実際に作ったものがあり動かすことができれば多くの人の認識を揃えるやすくなります。\n荒削りでもダッシュボードがあれば間違っている計算や不足している観点を洗い出すことができます。\n自分たちのチームで使うならどんなデータが不足しているのか想像することができるでしょう。\nそのための課題も具体的に見えてきます。\n動くものがあればできることや難しいことのイメージを捉えやすくなるため進める方向性や優先度の認識が揃えやすいでしょう。\nおわりに ここまでに述べたような理由からデータ分析基盤の構築は使う前から最初に時間をかけて大きく作るものではありません。\nまずは小さく作りそれを絶えず修正・改善しながら大きく拡張するものなのです。\nでは、具体的にどのように小さく作ればよいのでしょうか？\n次の記事ではMVPについて考察します。\n","permalink":"https://kenjiusui.github.io/blog/posts/biz/013_%E3%83%87%E3%83%BC%E3%82%BF%E5%88%86%E6%9E%90%E5%9F%BA%E7%9B%A4%E3%81%AF%E3%81%BE%E3%81%9A%E5%8B%95%E3%81%8F%E3%82%82%E3%81%AE%E3%82%92%E4%BD%9C%E3%82%8C/","summary":"\u003ch2 id=\"動くものを作らないから失敗する\"\u003e動くものを作らないから失敗する\u003c/h2\u003e\n\u003cp\u003e失敗するデータ分析基盤プロジェクトに共通する重要な特徴の1つは「動くものから作らない」ということです。\u003cbr\u003e\n何年もかけて巨大な基盤を構築しすべてが完成してから稼働させるようなやり方は経験上うまくいきません。\u003cbr\u003e\n開発の前にすべての要件を定義し仕様を決めようとする。\u003cbr\u003e\nデータ分析基盤の実装をレイヤーごとに進めようとする。\u003cbr\u003e\nこういった進め方をしようとする人は少なくありませんが実際のところうまくいきません。\u003cbr\u003e\nなぜ、このような進め方をするとなぜ失敗するのでしょうか？\u003cbr\u003e\n3つの要素にわけて解説します。\u003c/p\u003e\n\u003ch2 id=\"時間をかけると作った頃には役に立たない\"\u003e時間をかけると作った頃には役に立たない\u003c/h2\u003e\n\u003cp\u003eまず根本的な問題として、データ分析基盤を何年もかけて作ったとしても完成した頃には情勢が変わっており使い物にならない可能性が高いという点があげられます。\u003cbr\u003e\nこれはビジネスを取り巻く環境の影響を受けること、そしてデータ分析基盤は社内の様々なシステムの影響を受けることから発生します。\u003c/p\u003e\n\u003cp\u003e現代の市場は凄まじい速度で変化しておりビジネスの戦略もそれに合わせて日々変わっていきます。\u003cbr\u003e\nビジネス戦略が変われば知りたい情報もどんどん変わっていきます。\u003cbr\u003e\n何年も前に決めた指標や分析方法が役に立つでしょうか？\u003cbr\u003e\n少なくない割合で変更が求められることは想像に難くないでしょう。\u003cbr\u003e\nこのようにして作った瞬間から役に立たないダッシュボードができあがります。\u003c/p\u003e\n\u003cp\u003eまた、社内システムが変更されれば取得するデータの性質は変わっていきます。\u003cbr\u003e\n1つ1つの変更の周期は短くなくとも様々なシステムによってなりたっている現代では毎年のように何らかのシステムが変更されていきます。\u003cbr\u003e\n変更に限らず新たなシステムを導入することも珍しくないでしょう。\u003cbr\u003e\nデータ分析基盤は様々なシステムの下流に位置するためそれらの影響を強烈に受けます。\u003cbr\u003e\nまた、社内のシステムは変わらずとも法律や規制などによって変更や修正が要求されることもあります。\u003cbr\u003e\n分析に必要なデータソースが増えたり減ったり変更されることで、データの取得方法や前処理、集計の定義すら変わるのです。\u003c/p\u003e\n\u003ch2 id=\"フィードバックループを回せ\"\u003eフィードバックループを回せ\u003c/h2\u003e\n\u003cp\u003e次に重要な問題の1つとしてフィードバックループが回らないことが挙げられます。\u003cbr\u003e\n完成まで誰も触らなければ誰も検証できずフィードバックができません。\u003cbr\u003e\n途中で誰かが実際に利用しはじめていれば意思決定に使える分析ができるのか確認できますし問題があれば修正ができます。\u003c/p\u003e\n\u003cp\u003e開発の前に完全な要求や仕様を定義することはできません。\u003cbr\u003e\n事前の想定が間違っていたという自体は当然のように発生します。\u003cbr\u003e\n最初にすべてを定義して設計、実装を行うという方法は絶対に過不足が発生します。\u003c/p\u003e\n\u003cp\u003e分析する側も分析基盤を開発する側も両方でこの問題が発生します。\u003cbr\u003e\n分析する側は実際に分析して意思決定に活かしてみると最初に想定していた指標では上手くいかない、なんてことはよく起きます。\u003cbr\u003e\nこれは「考える人のスキルが足りず想定不足だった」という話ではありません。\u003cbr\u003e\n前述したように事業や環境が変わって分析の切り口が変わるケースはその典型例です。\u003cbr\u003e\n探索的に分析を行うことで初めて見えてくるものもあります。\u003cbr\u003e\nやってみないとわからないことがたくさんあるのです。\u003c/p\u003e\n\u003cp\u003e分析基盤を構築する側としては当然上記の分析する側の状況が変化すれば作るものも変わってきます。\u003cbr\u003e\n見たい指標が変わればデータマートやダッシュボードの実装は変化するでしょう。\u003cbr\u003e\n場合によっては中間テーブルでのデータの持ち方や前処理の方法を変更する必要があるかもしれません。\u003cbr\u003e\n想定よりも負荷が高くてうまく運用が回らないというケースもありえます。\u003c/p\u003e\n\u003cp\u003eこれらの問題を使う前にすべて洗い出すのはおおよそ不可能であるといってよいでしょう。\u003cbr\u003e\n少なくともすべてを洗い出すコストとリスクを考えると作って使ったみたほうが早くて確実です。\u003c/p\u003e\n\u003ch2 id=\"地に足のついた議論をする\"\u003e地に足のついた議論をする\u003c/h2\u003e\n\u003cp\u003eもう1つ重要な問題として進める優先度や方向性を揃えることが難しいという点があります。\u003cbr\u003e\nデータ分析基盤は社内の多くのステークホルダーを巻き込んで開発されるものです。\u003cbr\u003e\n意思決定に活かすという性質から上位レイヤーの人間への影響をもちます。\u003cbr\u003e\nその中データ分析基盤ではどれをどの順番で作るのか決めていく必要があります。\u003cbr\u003e\nこれが実際に動くものと検証ができない状態だと物事を進めるのが簡単ではありません。\u003c/p\u003e\n\u003cp\u003eデータ分析基盤の開発に着手するとき、多くのステークホルダーは具体的なイメージを持てていません。\u003cbr\u003e\nまして自分たちのチーム以外との連携などほぼ不可能といってよいでしょう。\u003cbr\u003e\nしかし実際に開発を進めるには社内のそれぞれのステークホルダーの要望から優先度を決める必要があります。\u003cbr\u003e\n具体的なモノがない状態だと各々の認識をぶつけることになり議論が空中戦になりがちです。\u003cbr\u003e\n結果として社内の力学がそのまま反映されてしまいあるべき姿から歪んでしまいます。\u003c/p\u003e\n\u003cp\u003eしかし、実際に作ったものがあり動かすことができれば多くの人の認識を揃えるやすくなります。\u003cbr\u003e\n荒削りでもダッシュボードがあれば間違っている計算や不足している観点を洗い出すことができます。\u003cbr\u003e\n自分たちのチームで使うならどんなデータが不足しているのか想像することができるでしょう。\u003cbr\u003e\nそのための課題も具体的に見えてきます。\u003cbr\u003e\n動くものがあればできることや難しいことのイメージを捉えやすくなるため進める方向性や優先度の認識が揃えやすいでしょう。\u003c/p\u003e\n\u003ch2 id=\"おわりに\"\u003eおわりに\u003c/h2\u003e\n\u003cp\u003eここまでに述べたような理由からデータ分析基盤の構築は使う前から最初に時間をかけて大きく作るものではありません。\u003cbr\u003e\nまずは小さく作りそれを絶えず修正・改善しながら大きく拡張するものなのです。\u003c/p\u003e\n\u003cp\u003eでは、具体的にどのように小さく作ればよいのでしょうか？\u003cbr\u003e\n次の記事ではMVPについて考察します。\u003c/p\u003e","title":"データ分析基盤はまず動くものを作れ"},{"content":"データ分析基盤を構築するとき避けて通れないのが「どうやってデータを取得するか」という問題です。\nSaaSのETLツールを使うのか、APIを自前で叩くのか、手動でCSVを取り込むのか。\nデータを取得する手法は選択肢が多く状況に応じて最適な手法は変化します。\nまた、技術的な問題だけではなく分析する側であるビジネス上の要求も考える必要があります。\n本記事では技術選定の判断基準を整理し、筆者の経験をもとに実際によくある検討のパターンを解説します。\nデータの鮮度・更新頻度 更新頻度は技術選定に最も直接的な影響を与える要素です。\n一般にデータを更新する頻度が上がるほど自動化の設計は複雑になります。\n日次であれば夜間バッチで全件更新というシンプルな仕組みで済みますが、これが数時間おきとなるとAPIのレートリミットを意識した設計が必要になるかもしれません。\n更にリアルタイムになれば差分検知やリトライの仕組みまで求められます。\nつまり更新頻度は「どの程度の仕組みを作る必要があるか」を決める起点であり実装・運用コストに直結します。\n逆にいえば「どれくらいの頻度でデータを更新する必要があるか」を最初に固めることで選択の幅が大きく絞り込むことができます。\n低頻度 低頻度とは年に数回くらいの想定です。\nこういったデータの場合は手動で全件を更新するというケースが多くなります。\nデータソースと分析上の要求として増分・差分をわざわざ検知する必要がないため全件更新で問題がないこと、そして頻度が低いため自動化のメリットを享受しにくいこと多いためです。\n更新頻度が低いデータの場合はそもそもデータの形式や用途が安定しないこともあり処理の内容を毎回検討する必要が多いことも自動化の優先度が下がる要因の1つです。\n自動化を選ばないケースでいうと、たとえば特定のプロジェクトや顧客で単発で発生するようなケースがあります。\nプロジェクトで単発的にデータが発生したり、顧客ごとにデータの形式にばらつきがあったりという状況です。\nこのような不定期でデータの形式も完全に固まっていない場合は自動化のコストが高くなりがちです。\n担当者がその都度手動で取り込む運用でも十分でしょう。\n逆に頻度が低いとはいえデータの形式が固まっており処理が複雑という場合は自動化のメリットが上回ります。\nエクスポートしたデータをエクセルなどで細々と整理してからアップロードするようなプロセスが必要だとしたら手間もかかりますしミスも起きやすいので自動化が望ましいでしょう。\nたとえば、年に数回しか更新されないマスタデータがありながらインポートにひと手間必要という場合はこのケースに該当します。\n完全に自動化する必要もないので無理にワークフローに載せずにスクリプトとして保存しておくなどの対処もありえます。\n月次・週次 月次・週次で更新する場合は全件更新するケースが多くなります。\nデータソースの特性として月次・週次で更新するデータは何らかの作業がひととおり終わったものを保存するというケースが多く、そのため増分・差分を検知して保存するというよりも全件を保存したいことが多いからです。\nたとえば締め作業が終わって確定した会計データや、週次で棚卸し作業をしている在庫情報などが挙げられます。\n月次・週次くらいの頻度で恒常的に発生するとなると自動化による作業コストが削減できるメリットが大きくなるため多くの場合で自動化を検討します。\n1つ2つくらいのデータソースであればなんとかなりますがデータ分析基盤には多くのデータソースを結合していくことになりますので自動化することを前提に設計するべきでしょう。\nまた、作業ミスによるリスクも考慮に入れるべきです。\nそれなりの頻度で作業することになりますから必然的にミスも発生します。\n作業ミスはそのままデータ品質の問題に、そして誤った意思決定へと繋がります。\nより確かな意思決定という観点からも週次・月次くらいの更新頻度が定常的に発生するようであれば自動化が前提という意識でいるのがよいでしょう。\n日次更新 最も一般的な更新頻度です。\n毎晩にバッチ処理を走らせ朝出社したときには最新のデータが見られるようになっている、というサイクルは多くのビジネスの意思決定に十分なサイクルです。\n日次の更新ではデータ量がよほど大きくない限り全件を取得してそのまま更新するシンプルな設計をベースに検討します。\nこの頻度になると自動化は原則です。\n毎日の作業となると手動では作業の負担が大きくなります。\nあわせて作業頻度が増えることでミスも起きやすくなるため担当者の業務を圧迫します。\nスケジュール実行で毎日自動的に動くように設計しておくことで安定した運用が実現できます。\n基本は全件更新ですがデータ量が多い場合は全件更新が難しくなるため増分・差分更新を検討する必要も出てきます。\nただし増分・差分更新は実装が複雑になるため、まずは全件更新でシンプルに作り必要に応じて改善するアプローチを取るほうが無難です。\n現代ではデータの保存・処理コストは非常に安いので実装が複雑になることのデメリットの回避を優先したほうがよいケースは多いでしょう。\n数時間に一度 日次よりも高い頻度で更新したいがリアルタイムだと工数が高すぎるという場合にとる選択肢です。\nログデータのような量が多く変化を素早く検知したいようなケースです。\nもしくは日次だとデータ量が多くなるため分割したいという場合です。\n数時間おきに更新するときは同時に増分・差分更新が要件となることが増えます。\n差分を検知して変更があった分だけを取得する設計が取れるか検討しましょう。\n増分・差分更新が求められがちな理由はいくつかあります。\n数時間ごとに更新したいデータはログデータのようにデータ量が多く変更よりも追記が多いデータであるため増分・差分更新が要件になりがちです。\nそうでなくとも数時間ごとに実行すると日次の数倍の処理量になるためさすがにコストが無視できない状況になってきます。\n合わせてAPIの実行頻度が増えるため毎回全件更新するとAPIのレートリミットに引っかかるリスクも高まります。\nこのような理由の組み合わせから増分・差分更新になりやすくなります。\nもちろん全件更新で要件として十分なのであればそのほうが望ましいことは言うまでもありません。\n注意点として、増分・差分更新の実装には「どのレコードがいつ変更されたか」を追うことが必須です。\nそのためのタイムスタンプや連番IDがデータソース側に存在することが前提になります。\nこれが整備されていない場合は差分の検知自体が難しくなるためデータソースの特性を事前に確認することが重要です。\n即時〜数分のリアルタイム連携 リアルタイム連携はデータソースの変更が即時もしくは数分程度の遅延で反映されるような設計です。\nユーザーの行動ログデータや広告データなどデータ量が非常に多く、同時に変化を検知したいという場面で求められることが多いです。\nリアルタイム連携は更新頻度としては理想ではありますが一方で他の更新頻度に比べて実装・運用コストが高くなります。\nリアルタイム連携には大きく2つのアプローチがあります。\n一つはデータソース側で変更が発生した時点でイベントとして通知を受け取るイベント駆動型で、もう一つは数分おきに差分だけを取得するミニバッチ形式です。\nどちらも「変更をほぼリアルタイムで検知して取り込む」という点では共通しており日次のバッチ処理とは設計の考え方が大きく異なります。\nどちらのアプローチが現実的かはデータソースの特性やAPIなどのインターフェイスによって変わります。\nリアルタイムにデータを連携しようとすると要求される技術的な難易度が一気に上がります。\n単純なAPI連携で全件更新するバッチ処理に比べると差分の検知に加えてリトライ設計や運用の監視など考えるべき要素が増えるためです。\n障害発生時も全件更新であれば再度実行すれば簡単に復旧することが可能ですがリアルタイム連携の場合はどこまでデータが取れているのか確認する必要があるなど復旧のコストと難易度が高くなります。\n一方で、リアルタイム連携が求められやすいデータソースは公式や外部SaaSにリアルタイム連携のコネクタが用意されていることもあるのでその場合は比較的実現しやすくなります。\n難易度と工数を考えるとリアルタイム連携という選択肢は公式や外部SaaSのコネクタがある場合はともかく自分たちで実装する場合は本当に必要なときだけ選ぶべきです。\n分析する側としては可能な限り遅延の少ないデータの更新を求めてしまいがちですがリアルタイムで連携が必要なケースというのは実のところそこまで多くありません。\n大概の分析は日次更新で問題ないことが多く、更新頻度を高めるにしても数時間ごとの更新で十分なケースがほとんどです。\nまずは日次の全件更新で実装してみて足りなければ数時間ごとに更新頻度を増やし、それでもリアルタイム連携が必要かを検討するのがベターでしょう。\nデータ量 1日あたりに処理するデータ量も技術選定を左右する重要な軸です。\nデータ量が多くなるほど設計上の制約が増えます。\nたとえば、処理時間が長くなれば夜間バッチが翌朝までに終わらないという問題が生じます。\n他にもメモリに乗りきらないデータはそのまま読み込もうとするとエラーになるため分割処理の仕組みが必要になります。\nデータ量が非常に大きくなるとそもそもバッチ処理の枠組みでは対応しきれなくなりスループットを重視した技術の選択が求められるようになります。\nまた現時点のデータ量だけで判断するのは危険です。\n分析のためには過去のデータも蓄積していく必要があるため雪だるま式にデータ量は増えていきます。\n更に事業が成長するにつれて扱うデータ量は加速的に増えていきます。\n今は問題なく動いていても1〜2年後に設計が破綻するということは珍しくないため将来のデータ量を見越した設計が重要です。\n少量（数GB） 数千〜数万件程度のデータで商品などのマスターデータや小規模なプロダクトのデータなどがこれに当たります。\nこの程度のデータ量であれば処理時間も短くデータ全体がメモリに乗りきるためツール側の制約を意識せずに設計できます。\nそのためデータ量が技術選定の制約になることはほとんどありません。\n全件更新が素直に機能するサイズです。\n差分検知などの最適化を行わず毎回全件を取得してそのまま上書きするという設計がそのまま成り立ちます。\nAPIを1回〜数回呼び出すだけで全データを取得でき処理時間も数秒〜数分程度で完了します。\n分割処理を意識する必要も少なく実装がシンプルに保てます。\n差分管理のロジックが不要になることは設計上の大きなメリットです。\n「どのレコードがいつ変更されたか」を追う必要がないため実装コードが少なくなりバグも入りにくくなります。\nデータソース側の仕様が変わったときのスキーマ変更への追従も容易で長期的なメンテナンスコストが低く抑えられます。\nデータ量が許す限り全件更新を選ぶのが最もシンプルで堅牢な設計であり増分・差分更新は本当に必要になったときに初めて検討すれば十分です。\n中程度（数十〜数百GB） それなりの規模のサービスのプロダクトのデータやトランザクションデータ、行動ログなどがこれに当たります。\nこのサイズになるとデータ量が技術選定に影響を与える要因として浮上してきます。\nまず全件取得するたびにメモリに乗りきらないケースが出てきます。\n大きなメモリを持ったインスタンスなどももちろんありますが実行の安定性や時間を考えると現実的な選択肢とは言い難いでしょう。\nその場合はページネーションを使ってAPIを複数回呼び出しながら分割して取得するような設計が必要になります。\nデータ量増加に伴う処理時間の問題も無視できなくなってきます。\n数GBのうちは数分で終わっていた処理が数十から数百GBになると30分〜1時間またはそれ以上かかることもあります。\nこれが1つや2つであれば良いですが実際はこのレベルの大きな処理を組み合わせて実行スケジュールを管理する必要があり、これは簡単ではありません。\n更に処理時間が長くなるとネットワークの寸断や一時的なAPIエラーによる失敗のリスクも高まるためリトライの仕組みも考慮に入れることになります。\nこのサイズになると増分・差分更新を検討する価値も出てきます。\n毎回全件を取得するのではなく前回取得以降に更新されたデータだけを取得する設計にすることで処理時間とAPIへの負荷を大幅に削減できます。\nただし差分更新の実装は複雑になるためまず全件更新で動くものを作ってから処理時間が問題になった段階で差分更新に切り替えるというアプローチが現実的です。\n大量（数TB以上） 大規模なアクセスログ、IoTセンサーのデータ、ソーシャルメディアの投稿データなどがこれに当たります。\nこのサイズになるとデータ量そのものが技術選定の重要な要因になります。\n単純なバッチ処理では処理時間や安定性の面で対応しきれなくなりデータをさばけるかどうかがまず技術選定の基準になります。\n全件更新はほぼ現実的ではありません。\n夜間に処理を回しても翌朝までに終わらない、処理の途中でメモリやディスクが枯渇して失敗するといった問題が起きます。\nこのサイズになると差分更新は必須となりデータを並列処理できるアーキテクチャが求められます。\n処理の負荷を分散するためリアルタイムな連携も視野に入ります。\n障害時の対応設計も重要になります。\n数TBの処理が途中で失敗した場合にどこから再開するかというリカバリー設計がないと最初からやり直すのは現実的ではありません。\n処理をチェックポイントで区切って途中から再開できる仕組みや処理の冪等性を担保した設計が必要になります。\nこのサイズのデータを扱う場合は専門知識が求められることが多くデータエンジニアの関与が不可欠です。\nコスト コストは実装コスト・運用コスト・障害対応コストの3つに分けて考えます。\n技術選定の場面ではツールのライセンス料や計算リソース代といった目に見えやすいコストに注目しがちですが実際にはエンジニアの工数が最も大きなコスト要因になりがちです。\n原則としてシンプルな設計を選ぶほど初期の実装コストは低く抑えられます。\n運用や障害対応のコストはデータソースの数に比例して雪だるま式に増加します。\nそのためデータソースの数が見込まれるときは特にこれらのコストをなるべく下げるように心がける必要があるでしょう。\nそうしなければいつの間にか運用で人手が払底し新たな実装ができなくなるような状況になってしまいます。\n実装コスト データの自動取り込み・更新するシステムを動かし始めるまでに必要なコストです。\n手動で更新すればほぼゼロですが自動化するとなるとエンジニアが必要になり、その工数は求めるものに応じて変化します。\nたとえば全件更新はAPIを呼び出してデータを保存するだけなので実装はシンプルで比較的工数は少なめになります。\n増分更新になると差分を検知するロジックや前回の取得状態を管理する仕組みが必要になりその仕様の整理と実装に工数が増えます。\nリアルタイム連携はさらにその上にリトライや監視の仕組みが加わるため実装コストは段違いに高くなります。\n加えて、データの取り込みについて要件整理に時間がかかることも忘れてはいけません。\nエンジニアが手を動かしてコードを書くことに作業時間がかかることはイメージしやすいですが、実際のところ実装と同じかそれ以上に要件整理に時間がかかります。\nデータソースの仕様の調査だけでなく、どのようにデータが入力されているのか現場のオペレーションを確認したり、分析の用途に不足がないか検討するなどの作業が発生します。\nこれはエンジニアが一人でやれることではなくステークホルダーへ確認・調整する必要があるため思っている以上に時間が必要です。\n運用コスト 自動化されたデータ取り込みの仕組みを動かし続けるためにかかるコストとしてわかりやすいものはまず計算リソース代やツールのライセンス料があります。\nクラウドサービスやSaaSのETLツールは処理するデータ量や実行回数に応じて従量課金されるものが多くデータ量が増えるにつれてコストも増加します。\nBIツールは権限ごとのID単位で課金されるので将来的に利用するユーザーや必要な権限を整理して試算する必要があるでしょう。\n現時点の情報だけで試算すると将来的に予算を大きく超えるということが起きるため設計の段階で将来を見越したコスト試算を行っておくことが大切です。\nさらに、保守・運用のエンジニアコストも忘れずに見ておく必要があります。\nパイプラインを日々監視し問題が起きたときに対応するための工数はデータソースの数と設計の複雑さに比例して大きくなります。\n特に見落とされがちなのがデータソース側の仕様変更への対応コストです。\nほとんどの場合でAPIの仕様やスキーマが変わるたびに改修が必要になります。\nこの改修コストは設計の複雑さによって大きく変わります。\n全件更新に比べると差分更新やリアルタイム連携は対応コストが増えることになります。\nデータを取り込む処理はなるべくシンプルに保つことが仕様変更への追従コストを下げるうえで重要です。\n障害対応コスト パイプラインが止まったときの調査・修復・再実行にかかるコストです。\n全件更新であればやり直しは「再度全件取得して上書き」するだけなので復旧が簡単です。\nワークフローをリトライするだけで復旧することも多いでしょう。\n差分更新やリアルタイム連携は「どこから失敗したか」「欠損データはないか」「重複して取り込んでいないか」を調べる必要があり復旧の難易度が上がります。\n特にリアルタイム連携はトランザクション単位で調査が必要ですし、欠損データを別途保管するような仕組みが必要になることもあり障害対応には手間がかかります。\n設計が複雑になるほど障害時の調査工数は増えるため運用体制と照らし合わせて許容できる複雑さを判断することが重要です。\nセキュリティとプライバシー データを扱うにあたってセキュリティとプライバシーは重要な要件です。\nこれらは会社としてポリシーが決まっていることが一般的でしょう。\n社内のポリシーを調査し自分たちの選択肢が使えるのか事前にすり合わせることが重要です。\n設計と実装が進んでから「使いたいツールが社内ポリシーで使えないので大きな変更が必要になった」といった悲劇を産まないようにしましょう。\nインフラ（データの保管場所とネットワーク） 社外のサービスにデータや認証情報を置くことが許容されるかどうかは最初に確認すべき点です。\n情報セキュリティのポリシーはIT部門や法務・コンプライアンス部門が管轄していることが多くデータエンジニアリングチームの裁量で動かせる話ではないため選択肢の検討を始める前に確認しておく必要があります。\n特に問題になりやすいのはデータの保管場所や分析基盤そのもの、そしてETLツールです。\nまず、データを保管するストレージや分析基盤そのものについての確認が必要です。\nBigQueryのようなパブリッククラウドのサービスは多くの企業で広く使われており適切な設定をすれば高いセキュリティ水準を確保できます。\nしかし、社内規則などでクラウドサービス自体が禁止されている場合はオンプレミスの構成を選ぶことになり、運用コストや実装の工数は大幅に増えることを覚悟する必要があります。\nまた、クラウドの利用自体は問題がなくてもサービスがAWSにある状態でBigQueryを使いたいといったマルチクラウド構成をする場合はクラウドサービスを跨いで利用することの是非について検討する必要があります。\n他にも、SaaS型のETLツールの利用を検討している場合は確認したほうがよいでしょう。\nSaaS型のETLツールはデータをSaaS側の環境を経由して転送・処理する構成が多くあります。\nつまりデータをベンダーのサーバ上で一時的に処理するため「社外にデータが出る」という扱いになります。\n社内ポリシーによってはこのような扱いが禁止されているケースがあります。\nポリシー上これが許容されない場合はこれらのツールは選択肢から外れ自前でETLを実装するか、OSS型のETLツールを構築して社内環境に閉じた構成を取る必要があるでしょう。\n個人情報・機密データの扱い 取り込むデータに個人情報や機密データが含まれる場合は技術選定やアーキテクチャに注意が必要です。\n氏名・メールアドレス・電話番号・住所といった個人を特定できる情報や財務情報や医療情報・営業秘密など機密データは慎重な取り扱いが求められます。\nこれらのデータは個人情報保護法やGDPRといった法規制の対象になるだけでなく漏洩した場合のビジネスリスクも大きいため分析基盤に取り込む場合には適切な対応が必要です。\nSaaS型のETLツールを使う場合はデータが一時的にベンダー側のサーバを経由するためベンダーのサーバ上でログなどに記録する可能性があります。\nたとえばデバッグのためにエラーログに生のデータが書き込まれるケースや一時的なステージング領域に保存されるケースなどがありえます。\nベンダーのインフラ上に個人情報や機密情報が残ることが法規制や社内ポリシー上許容されない場合はSaaSツールの採用は慎重になる必要があるでしょう。\n個人情報や機密情報を含むデータソースだけ自前の実装に切り分けてSaaSツールと組み合わせるという設計を取るケースもありますがパイプラインの構成が複雑になるためトレードオフを考慮する必要があります。\nマスキングや匿名化をどのタイミング・どのツールで行うかという問いも技術選定に影響します。\nデータを取り込む処理の中で個人情報や機密情報をマスキングしてから分析基盤に保存するのか、それとも生データをそのまま取り込んでから分析基盤側で制御するのかによって必要な機能と設計が変わります。\nSaaSのETLツールにマスキング機能が備わっており要件として十分であればそれを活用できますが対応していない場合は変換処理を自前で実装する工数が必要です。\n「そもそも分析に不要なカラムは取り込まない」という判断が最もシンプルなリスク低減策であり最初にデータの範囲を絞っておくことで後続の設計がシンプルになります。\nよくある検討のパターン ここまでさまざまな技術選定をおこなうときのさまざまな観点を紹介しました。\n考えることが多いように思えるかもしれませんが、実際のところすべてを網羅的に検討する必要はありません。\n筆者の経験から、現場でどのように選択肢を絞っていくのかよくある流れを紹介します。\n1. 動かせない前提条件を確認する まず最初に後から覆せない制約を洗い出しておきます。\n技術的な検討を始める前にこのステップを踏まないと、実装が進んだ後で「そのツールはポリシー上使えない」「そのデータは社外に出せない」という事態になりかねません。\nこのような手戻りのコストは大きいため最初に確認する習慣が重要です。\nセキュリティとプライバシーに関する制約が代表的です。\nたとえば社外へのデータ持ち出しが禁止されている場合はSaaS型のETLツールが選択肢から外れます。\n取り込むデータに個人情報や機密情報が含まれている場合はベンダーのサーバ上での処理が許容されるかどうかを確認しなければなりません。\nこれらは情報システム部門や法務・コンプライアンス部門が判断する領域であり技術チームだけで決められる話ではないため早めに関係者を巻き込むことが欠かせません。\nビジネス側の制約としてデータ鮮度の要件も確認しておきます。\n「翌朝9時までに前日のデータが見えれば十分」なのか「数時間以内に反映されていないと困る」なのかによって技術の選択肢が大きく変わります。\n技術的な問題を考えなければ分析側としてはデータの更新頻度は高ければ高いほどよいものです。\n現場の担当者が「リアルタイムな更新が必要」と言っている場合でも実際の意思決定のサイクルを確認するとそこまでの鮮度は不要だったというケースは少なくありません。\nまた「リアルタイム連携が必要なのは一部の分析」で「まずは全件更新があるだけでも大きなメリットがある」という場合は素早く日次更新を実装しあとからリアルタイム連携へと改修するという選択肢もあります。\n実務上どの程度の頻度であれば問題がないのか、そして技術上どの程度までであれば効率よく実装・運用ができるのかすり合わせることが必要です。\n前提条件を固める段階でビジネス上の真の要件を把握しておくことが素早い実装と意思決定の改善に繋がります。\n2. 公式コネクタ・SaaSツールを確認する 前提条件をクリアできたらデータソースの公式コネクタが使えるかを確認します。\nこれが使える場合は技術選定としてほぼ決まりです。\nほかの選択肢と比較検討するまでもなく最優先で採用します。\nコネクタを使う最大のメリットは実装工数の削減です。\nAPIの認証処理やページネーション・スキーマの変換といった定型的な作業がすでに実装されているため自前でゼロから実装する場合に比べて初期の開発工数が大幅に減ります。\n加えてデータソース側でAPIの仕様が変わったときにベンダーがコネクタを更新してくれることが多く長期的な保守コストも低く抑えられます。\n公式のコネクタがなくてもSaaS型のETLツール上にコネクタが用意されているかを確認します。\nツール上のコネクタがあれば利用を検討しましょう。\nコネクタが用意されていてもすべての機能要件を満たすとは限りません。\n対応している更新頻度・データの取得範囲・フィルタリング条件などの要件と合致するか確認しておく必要があります。\nまた、前ステップで確認したセキュリティ要件をここで照らし合わせてSaaS型ツールの利用自体が許容されるかどうかを再確認します。\n3. 日次全件更新を検討する コネクタが使えない場合は自前でAPIを呼び出す実装が必要になります。\nこのとき最初に検討するのが日次の全件更新です。\n1日1回スケジュール実行してデータをすべて取得して上書きするというシンプルな設計を出発点にします。\n全件更新を最初に選ぶ理由は設計のシンプルさです。\n差分更新では「前回の取得以降に何が変わったか」を追跡する仕組みが必要になりますが全件更新にはそれが不要です。\n実装コードが少なくなりバグが入りにくく障害時の復旧も「再実行するだけ」で済みます。\nデータ量が数GB~数十GBの範囲に収まるのであれば全件更新でほぼ問題は起きません。\nまず動くものを作ることを優先して全件更新から始めるのが堅実な進め方です。\n数百GB以上になると全件更新の処理時間が長くなりAPIのレートリミットに引っかかるリスクが出てきます。\nそれでもまずは全件更新で試してみて実際に問題になったときに初めて差分更新を検討するというアプローチが現実的です。\nいきなり差分更新の設計に飛びつくと不要な複雑さを抱えることになりかねません。\n逆に、APIすら用意されていない場合は自動更新が非常に難しくなります。\nその場合は手動で更新するしかないというかもしれません。\nその場合は分析上の更新頻度や優先度などの要求と運用負荷のバランスが必要です。\nなるべくオペレーションが増えないように、ミスが起きないように運用を整理します。\n場合によっては日次ではなく週次や月次へ頻度を落とすことも検討しましょう。\nなお、APIが用意されていないからと言ってスクレイピングでデータを行うのは原則やめたほうがよいでしょう。\nスクレイピングは規約などで禁止されていることが少なくないためです。\nもし規約上問題なかったとしてもサービス側の仕様変更に弱いため運用コストが高くなりがちです。\nスクレイピングの採用は慎重に検討しましょう。\n4. 増分・差分更新やリアルタイム連携を検討する 日次の全件更新では要件が満たせないと判断できた場合に初めてこの選択肢に進みます。\n「満たせない」という判断の根拠は主に2つです。\nデータ量が非常に多く全件取得に現実的でない時間がかかること、もしくはビジネス上の鮮度要件が日次では不足することです。\n増分・差分更新を採用するにはデータソース側の仕様が対応していることが前提になります。\nいつ更新されたデータか判別するためのタイムスタンプやIDがデータソースに存在していなければ差分の検知自体ができません。\n採用前にデータソースの仕様を確認して条件が満たされているかを確かめる必要があります。\nリアルタイム連携は本当に必要な場合に限って選ぶべき選択肢です。\n技術的な難易度が上がり実装・運用コストも高くなります。\n障害時の影響範囲も広くなるため設計の複雑さに見合うだけのビジネス上の価値があるかを慎重に判断することが重要です。\n分析用途ではリアルタイムに連携することのメリットが見えにくいケースも多くあります。\n実際には数時間ごとのバッチ処理で十分というケースも少なくありません。\nリアルタイム連携がどうしても必要なユースケースを確認することが判断の出発点になります。\n増分・差分更新もリアルタイム連携も最初から採用するよりも日次の全件更新で動かし始めてから段階的に高度化するアプローチのほうが多くの場合でうまくいきます。\n実際に運用してみると「日次で十分だった」「思ったほどデータ量が増えなかった」ということも多く、最初から過剰な設計を作り込まずに済みます。\nまとめ データ取得の技術選定について一般化できそうな範囲で判断の基準を整理しました。\nこの領域は選択肢の多さゆえに迷いやすいですが判断の順序を決めておくと道筋が見えやすくなります。\n全体としてシンプルで簡単な実装と設計を心がけることが重要です。\nシンプルな設計から始めることは妥協ではなく合理的な選択だからです。\n複雑な仕組みは必要になったときに追加できますが最初から複雑な設計を作り込むと実装・運用・障害対応のすべてのコストが上がります。\nまず動くものを作り実際の運用を通じて本当に必要かを判断していくサイクルが現実的な改善につながります。\n本記事がデータ分析基盤について技術選定をする方々への助けになれば幸いです。\n","permalink":"https://kenjiusui.github.io/blog/posts/biz/012_%E3%83%87%E3%83%BC%E3%82%BF%E5%88%86%E6%9E%90%E5%9F%BA%E7%9B%A4%E3%82%92%E9%96%8B%E7%99%BA%E3%81%99%E3%82%8B%E3%81%A8%E3%81%8D%E3%83%87%E3%83%BC%E3%82%BF%E3%82%92%E5%8F%96%E5%BE%97%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95%E3%82%92%E3%81%A9%E3%81%86%E3%82%84%E3%81%A3%E3%81%A6%E8%80%83%E3%81%88%E3%82%8C%E3%81%B0%E3%81%84%E3%81%84%E3%81%AE%E3%81%8B/","summary":"\u003cp\u003eデータ分析基盤を構築するとき避けて通れないのが「どうやってデータを取得するか」という問題です。\u003c/p\u003e\n\u003cp\u003eSaaSのETLツールを使うのか、APIを自前で叩くのか、手動でCSVを取り込むのか。\u003cbr\u003e\nデータを取得する手法は選択肢が多く状況に応じて最適な手法は変化します。\u003cbr\u003e\nまた、技術的な問題だけではなく分析する側であるビジネス上の要求も考える必要があります。\u003c/p\u003e\n\u003cp\u003e本記事では技術選定の判断基準を整理し、筆者の経験をもとに実際によくある検討のパターンを解説します。\u003c/p\u003e\n\u003ch2 id=\"データの鮮度更新頻度\"\u003eデータの鮮度・更新頻度\u003c/h2\u003e\n\u003cp\u003e更新頻度は技術選定に最も直接的な影響を与える要素です。\u003c/p\u003e\n\u003cp\u003e一般にデータを更新する頻度が上がるほど自動化の設計は複雑になります。\u003cbr\u003e\n日次であれば夜間バッチで全件更新というシンプルな仕組みで済みますが、これが数時間おきとなるとAPIのレートリミットを意識した設計が必要になるかもしれません。\u003cbr\u003e\n更にリアルタイムになれば差分検知やリトライの仕組みまで求められます。\u003c/p\u003e\n\u003cp\u003eつまり更新頻度は「どの程度の仕組みを作る必要があるか」を決める起点であり実装・運用コストに直結します。\u003cbr\u003e\n逆にいえば「どれくらいの頻度でデータを更新する必要があるか」を最初に固めることで選択の幅が大きく絞り込むことができます。\u003c/p\u003e\n\u003ch3 id=\"低頻度\"\u003e低頻度\u003c/h3\u003e\n\u003cp\u003e低頻度とは年に数回くらいの想定です。\u003cbr\u003e\nこういったデータの場合は手動で全件を更新するというケースが多くなります。\u003cbr\u003e\nデータソースと分析上の要求として増分・差分をわざわざ検知する必要がないため全件更新で問題がないこと、そして頻度が低いため自動化のメリットを享受しにくいこと多いためです。\u003cbr\u003e\n更新頻度が低いデータの場合はそもそもデータの形式や用途が安定しないこともあり処理の内容を毎回検討する必要が多いことも自動化の優先度が下がる要因の1つです。\u003c/p\u003e\n\u003cp\u003e自動化を選ばないケースでいうと、たとえば特定のプロジェクトや顧客で単発で発生するようなケースがあります。\u003cbr\u003e\nプロジェクトで単発的にデータが発生したり、顧客ごとにデータの形式にばらつきがあったりという状況です。\u003cbr\u003e\nこのような不定期でデータの形式も完全に固まっていない場合は自動化のコストが高くなりがちです。\u003cbr\u003e\n担当者がその都度手動で取り込む運用でも十分でしょう。\u003c/p\u003e\n\u003cp\u003e逆に頻度が低いとはいえデータの形式が固まっており処理が複雑という場合は自動化のメリットが上回ります。\u003cbr\u003e\nエクスポートしたデータをエクセルなどで細々と整理してからアップロードするようなプロセスが必要だとしたら手間もかかりますしミスも起きやすいので自動化が望ましいでしょう。\u003cbr\u003e\nたとえば、年に数回しか更新されないマスタデータがありながらインポートにひと手間必要という場合はこのケースに該当します。\u003cbr\u003e\n完全に自動化する必要もないので無理にワークフローに載せずにスクリプトとして保存しておくなどの対処もありえます。\u003c/p\u003e\n\u003ch3 id=\"月次週次\"\u003e月次・週次\u003c/h3\u003e\n\u003cp\u003e月次・週次で更新する場合は全件更新するケースが多くなります。\u003cbr\u003e\nデータソースの特性として月次・週次で更新するデータは何らかの作業がひととおり終わったものを保存するというケースが多く、そのため増分・差分を検知して保存するというよりも全件を保存したいことが多いからです。\u003cbr\u003e\nたとえば締め作業が終わって確定した会計データや、週次で棚卸し作業をしている在庫情報などが挙げられます。\u003c/p\u003e\n\u003cp\u003e月次・週次くらいの頻度で恒常的に発生するとなると自動化による作業コストが削減できるメリットが大きくなるため多くの場合で自動化を検討します。\u003cbr\u003e\n1つ2つくらいのデータソースであればなんとかなりますがデータ分析基盤には多くのデータソースを結合していくことになりますので自動化することを前提に設計するべきでしょう。\u003c/p\u003e\n\u003cp\u003eまた、作業ミスによるリスクも考慮に入れるべきです。\u003cbr\u003e\nそれなりの頻度で作業することになりますから必然的にミスも発生します。\u003cbr\u003e\n作業ミスはそのままデータ品質の問題に、そして誤った意思決定へと繋がります。\u003cbr\u003e\nより確かな意思決定という観点からも週次・月次くらいの更新頻度が定常的に発生するようであれば自動化が前提という意識でいるのがよいでしょう。\u003c/p\u003e\n\u003ch3 id=\"日次更新\"\u003e日次更新\u003c/h3\u003e\n\u003cp\u003e最も一般的な更新頻度です。\u003cbr\u003e\n毎晩にバッチ処理を走らせ朝出社したときには最新のデータが見られるようになっている、というサイクルは多くのビジネスの意思決定に十分なサイクルです。\u003cbr\u003e\n日次の更新ではデータ量がよほど大きくない限り全件を取得してそのまま更新するシンプルな設計をベースに検討します。\u003c/p\u003e\n\u003cp\u003eこの頻度になると自動化は原則です。\u003cbr\u003e\n毎日の作業となると手動では作業の負担が大きくなります。\u003cbr\u003e\nあわせて作業頻度が増えることでミスも起きやすくなるため担当者の業務を圧迫します。\u003cbr\u003e\nスケジュール実行で毎日自動的に動くように設計しておくことで安定した運用が実現できます。\u003c/p\u003e\n\u003cp\u003e基本は全件更新ですがデータ量が多い場合は全件更新が難しくなるため増分・差分更新を検討する必要も出てきます。\u003cbr\u003e\nただし増分・差分更新は実装が複雑になるため、まずは全件更新でシンプルに作り必要に応じて改善するアプローチを取るほうが無難です。\u003cbr\u003e\n現代ではデータの保存・処理コストは非常に安いので実装が複雑になることのデメリットの回避を優先したほうがよいケースは多いでしょう。\u003c/p\u003e\n\u003ch3 id=\"数時間に一度\"\u003e数時間に一度\u003c/h3\u003e\n\u003cp\u003e日次よりも高い頻度で更新したいがリアルタイムだと工数が高すぎるという場合にとる選択肢です。\u003cbr\u003e\nログデータのような量が多く変化を素早く検知したいようなケースです。\u003cbr\u003e\nもしくは日次だとデータ量が多くなるため分割したいという場合です。\u003cbr\u003e\n数時間おきに更新するときは同時に増分・差分更新が要件となることが増えます。\u003cbr\u003e\n差分を検知して変更があった分だけを取得する設計が取れるか検討しましょう。\u003c/p\u003e\n\u003cp\u003e増分・差分更新が求められがちな理由はいくつかあります。\u003cbr\u003e\n数時間ごとに更新したいデータはログデータのようにデータ量が多く変更よりも追記が多いデータであるため増分・差分更新が要件になりがちです。\u003cbr\u003e\nそうでなくとも数時間ごとに実行すると日次の数倍の処理量になるためさすがにコストが無視できない状況になってきます。\u003cbr\u003e\n合わせてAPIの実行頻度が増えるため毎回全件更新するとAPIのレートリミットに引っかかるリスクも高まります。\u003cbr\u003e\nこのような理由の組み合わせから増分・差分更新になりやすくなります。\u003cbr\u003e\nもちろん全件更新で要件として十分なのであればそのほうが望ましいことは言うまでもありません。\u003c/p\u003e\n\u003cp\u003e注意点として、増分・差分更新の実装には「どのレコードがいつ変更されたか」を追うことが必須です。\u003cbr\u003e\nそのためのタイムスタンプや連番IDがデータソース側に存在することが前提になります。\u003cbr\u003e\nこれが整備されていない場合は差分の検知自体が難しくなるためデータソースの特性を事前に確認することが重要です。\u003c/p\u003e\n\u003ch3 id=\"即時数分のリアルタイム連携\"\u003e即時〜数分のリアルタイム連携\u003c/h3\u003e\n\u003cp\u003eリアルタイム連携はデータソースの変更が即時もしくは数分程度の遅延で反映されるような設計です。\u003cbr\u003e\nユーザーの行動ログデータや広告データなどデータ量が非常に多く、同時に変化を検知したいという場面で求められることが多いです。\u003cbr\u003e\nリアルタイム連携は更新頻度としては理想ではありますが一方で他の更新頻度に比べて実装・運用コストが高くなります。\u003c/p\u003e\n\u003cp\u003eリアルタイム連携には大きく2つのアプローチがあります。\u003cbr\u003e\n一つはデータソース側で変更が発生した時点でイベントとして通知を受け取るイベント駆動型で、もう一つは数分おきに差分だけを取得するミニバッチ形式です。\u003cbr\u003e\nどちらも「変更をほぼリアルタイムで検知して取り込む」という点では共通しており日次のバッチ処理とは設計の考え方が大きく異なります。\u003cbr\u003e\nどちらのアプローチが現実的かはデータソースの特性やAPIなどのインターフェイスによって変わります。\u003c/p\u003e\n\u003cp\u003eリアルタイムにデータを連携しようとすると要求される技術的な難易度が一気に上がります。\u003cbr\u003e\n単純なAPI連携で全件更新するバッチ処理に比べると差分の検知に加えてリトライ設計や運用の監視など考えるべき要素が増えるためです。\u003cbr\u003e\n障害発生時も全件更新であれば再度実行すれば簡単に復旧することが可能ですがリアルタイム連携の場合はどこまでデータが取れているのか確認する必要があるなど復旧のコストと難易度が高くなります。\u003cbr\u003e\n一方で、リアルタイム連携が求められやすいデータソースは公式や外部SaaSにリアルタイム連携のコネクタが用意されていることもあるのでその場合は比較的実現しやすくなります。\u003c/p\u003e","title":"データ分析基盤を開発するときデータを取得する方法をどうやって考えればいいのか？"},{"content":"データ分析と戦略と優先度 前々回の記事では経営に近い抽象的な指標をそのまま現場に渡しても「何を変えればいいのか」がわからないという問題を取り上げました。解決策として指標をファネルや要素やセグメントに分解し課題の所在を具体的に特定することの重要性を述べています。\n前回の記事ではその続きとして、分解して見つかった課題に片っ端から対応すればよいわけではないという話をしています。見つかった課題のなかからどこに集中するかを決めること、つまり戦略を立てることが不可欠であり、KPIとはその戦略を定量化した指標だという整理です。\nこの2つの記事を踏まえると「分解して課題を見つけ、戦略的に優先度を決める」という流れが見えてきます。では実際にどうやって優先度を判断すればいいのか。本記事ではその判断軸として「大通り」という考え方を紹介していきます。\n課題を見つけたら次に考えること 指標を分解して分析を進めると課題は次々と出てきます。特定のセグメントでファネルの通過率が低い。ある流入経路だけ転換率が落ちている。こうした発見は分析の成果であり現場への具体的なインプットになり得るものです。\nしかしそこで一度立ち止まってほしいことがあります。「その課題を改善したとして、どれくらいのインパクトがあるのか」という問いです。\nたとえば特定のセグメントのファネル通過率が低いとして、そのセグメントが全体売上に占める割合が1%だったとしましょう。仮にその通過率を2倍に改善できたとしても事業全体への影響は微小です。課題を見つけることと、その課題に取り組む優先度を判断することは別の話です。\n分析で見つかった課題はあくまでも「改善の候補」にすぎません。そのなかからどこに時間とリソースを投じるかを判断するためには自分たちのビジネスのどこが「大通り」なのかを把握しておく必要があります。\n大通りとは何か 大通りとはユーザーがたくさん通りお金が動いているところ、言い換えれば自分たちのビジネスのコアです。\n都市の地図に置き換えると分かりやすいかもしれません。賑わっている大通りに面した店と人通りの少ない小道に面した店では、同じ改装工事でも集客への影響がまったく違います。大通りに面した店の入り口を広げれば多くの人が入りやすくなりますが、小道に面した店をどれだけ改装しても通行人が少なければ効果は限られます。\nビジネスも同じです。大通りを改善すればインパクトが大きく小道を改善してもインパクトは小さい。だからまず自分たちのビジネスの大通りがどこなのかを定量的に把握することが先決になります。\n大通りの2つの考え方 大通りを把握するには2つの視点があります。\nひとつ目は「どの商品が誰に売れているのか」という視点です。売上の大部分を占める商品は何か、それをよく買うのはどんなユーザー層なのか。これを把握することで自分たちのビジネスの主軸が見えてきます。全商品・全顧客を均等に扱うのではなく売上構造を正直に見ることがスタートになります。\nたとえばECサイトで家具・雑貨・インテリア用品を扱っているとしましょう。取扱商品数は雑貨が圧倒的に多いですが売上の大部分はソファやベッドといった大型家具が占めているというケースはよくあります。このとき大通りは大型家具です。商品ページの改善や購買体験の見直しをするなら大型家具を起点に考えることがインパクトの大きい投資になります。\nふたつ目は「商品がどのように購入されているのか」という視点です。同じ商品でも購買に至るまでの経路や行動パターンはユーザーによって異なります。よく使われている経路や購買パターンがある。その「よく通られているルート」こそが大通りであり、そこを改善することがサイト全体の購買体験の底上げにつながります。\n先ほどのECサイトで続けると、ログを分析した結果、大型家具を購入したユーザーの多くがトップページから特集ページを経由して商品ページに到達していたとします。一方で検索機能を使って直接商品ページに来たユーザーの購買率は低い。この場合トップページから特集ページへの導線が大通りです。特集ページのコンテンツを充実させる・季節や用途に合わせた特集を増やすといった施策は多くの購買ユーザーの行動に直接影響しますが、検索機能の改善は通過するユーザーが少ない分インパクトの上限が小さくなります。\nこの2つの視点は排他的ではありません。「大型家具を買うユーザーがよく通る経路」のように掛け合わせることで大通りはより具体的に把握できます。\n通りの大きさがわかれば施策のインパクトが読める 大通りがどこかわかればその通りの規模を使って施策のインパクトをシミュレーションできます。\nたとえばあるセグメントの転換率を5ポイント改善したとして、そのセグメントの流入数と現在の単価から売上への影響を試算できます。大通りであれば多少コストや工数がかかる施策でも投資対効果が見合いやすく腰を据えて取り組む理由になります。逆に小道であれば「インパクトが小さいのでシンプルな施策に絞る」という制約が自然と生まれ、施策の設計も研ぎ澄まされます。\n施策のインパクトを事前に試算する習慣は分析チームと事業側の対話を変えます。「この課題を改善しましょう」ではなく「この改善によってこれくらいのインパクトが見込めます」という会話ができるようになれば優先度の議論はより具体的になります。\n大通りは組織で合意する 大通りを定量的に把握することは分析チームの仕事ですが、それだけでは不十分です。\n分析チームが「ここが大通りだ」と示しても各チームはそれぞれ自分の担当領域を大通りだと思って動きがちです。営業は自分が担当している顧客層を、マーケティングは自分が担当しているチャネルを大通りだと信じている。この状態のまま施策を走らせると前記事で述べたのと同じ問題が繰り返されます。各チームが自分の指標を追っているのに組織として同じ方向に向いていない状態です。\n大通りの定義は分析チームが示して終わりではなく経営や事業責任者、現場を巻き込んで「ここが自分たちのコアだ」と合意するプロセスが必要になります。合意された大通りは組織の共通言語になります。施策のアイデアが出たときに「それは大通りへの投資か」という問いが自然に生まれるようになれば優先度の判断が組織全体でできるようになります。\nまとめ 分析で課題が見つかることは出発点にすぎません。その課題がビジネスのどこにあるのかを大通りという視点から評価することが次のステップです。\n大通りとはユーザーがたくさん通りお金が動いているところ。「どの商品が誰に売れているか」と「商品がどのように購入されているか」という2つの視点で把握します。そして把握するだけでなく組織として合意することが大通りを判断の共通言語にするために欠かせません。\n大通りがわかれば施策のインパクトを読めます。インパクトが読めれば優先度が決められます。優先度が決まれば組織のリソースをコアに集中させることができます。分析から行動への道筋はこの順番で整っていきます。\n","permalink":"https://kenjiusui.github.io/blog/posts/biz/011_%E3%83%87%E3%83%BC%E3%82%BF%E3%81%8B%E3%82%89%E5%A4%A7%E9%80%9A%E3%82%8A%E3%82%92%E6%8E%A2%E3%81%9B/","summary":"\u003ch2 id=\"データ分析と戦略と優先度\"\u003eデータ分析と戦略と優先度\u003c/h2\u003e\n\u003cp\u003e前々回の記事では経営に近い抽象的な指標をそのまま現場に渡しても「何を変えればいいのか」がわからないという問題を取り上げました。解決策として指標をファネルや要素やセグメントに分解し課題の所在を具体的に特定することの重要性を述べています。\u003c/p\u003e\n\u003cp\u003e前回の記事ではその続きとして、分解して見つかった課題に片っ端から対応すればよいわけではないという話をしています。見つかった課題のなかからどこに集中するかを決めること、つまり戦略を立てることが不可欠であり、KPIとはその戦略を定量化した指標だという整理です。\u003c/p\u003e\n\u003cp\u003eこの2つの記事を踏まえると「分解して課題を見つけ、戦略的に優先度を決める」という流れが見えてきます。では実際にどうやって優先度を判断すればいいのか。本記事ではその判断軸として「大通り」という考え方を紹介していきます。\u003c/p\u003e\n\u003ch2 id=\"課題を見つけたら次に考えること\"\u003e課題を見つけたら次に考えること\u003c/h2\u003e\n\u003cp\u003e指標を分解して分析を進めると課題は次々と出てきます。特定のセグメントでファネルの通過率が低い。ある流入経路だけ転換率が落ちている。こうした発見は分析の成果であり現場への具体的なインプットになり得るものです。\u003c/p\u003e\n\u003cp\u003eしかしそこで一度立ち止まってほしいことがあります。「その課題を改善したとして、どれくらいのインパクトがあるのか」という問いです。\u003c/p\u003e\n\u003cp\u003eたとえば特定のセグメントのファネル通過率が低いとして、そのセグメントが全体売上に占める割合が1%だったとしましょう。仮にその通過率を2倍に改善できたとしても事業全体への影響は微小です。課題を見つけることと、その課題に取り組む優先度を判断することは別の話です。\u003c/p\u003e\n\u003cp\u003e分析で見つかった課題はあくまでも「改善の候補」にすぎません。そのなかからどこに時間とリソースを投じるかを判断するためには自分たちのビジネスのどこが「大通り」なのかを把握しておく必要があります。\u003c/p\u003e\n\u003ch2 id=\"大通りとは何か\"\u003e大通りとは何か\u003c/h2\u003e\n\u003cp\u003e大通りとはユーザーがたくさん通りお金が動いているところ、言い換えれば自分たちのビジネスのコアです。\u003c/p\u003e\n\u003cp\u003e都市の地図に置き換えると分かりやすいかもしれません。賑わっている大通りに面した店と人通りの少ない小道に面した店では、同じ改装工事でも集客への影響がまったく違います。大通りに面した店の入り口を広げれば多くの人が入りやすくなりますが、小道に面した店をどれだけ改装しても通行人が少なければ効果は限られます。\u003c/p\u003e\n\u003cp\u003eビジネスも同じです。大通りを改善すればインパクトが大きく小道を改善してもインパクトは小さい。だからまず自分たちのビジネスの大通りがどこなのかを定量的に把握することが先決になります。\u003c/p\u003e\n\u003ch2 id=\"大通りの2つの考え方\"\u003e大通りの2つの考え方\u003c/h2\u003e\n\u003cp\u003e大通りを把握するには2つの視点があります。\u003c/p\u003e\n\u003cp\u003eひとつ目は「どの商品が誰に売れているのか」という視点です。売上の大部分を占める商品は何か、それをよく買うのはどんなユーザー層なのか。これを把握することで自分たちのビジネスの主軸が見えてきます。全商品・全顧客を均等に扱うのではなく売上構造を正直に見ることがスタートになります。\u003c/p\u003e\n\u003cp\u003eたとえばECサイトで家具・雑貨・インテリア用品を扱っているとしましょう。取扱商品数は雑貨が圧倒的に多いですが売上の大部分はソファやベッドといった大型家具が占めているというケースはよくあります。このとき大通りは大型家具です。商品ページの改善や購買体験の見直しをするなら大型家具を起点に考えることがインパクトの大きい投資になります。\u003c/p\u003e\n\u003cp\u003eふたつ目は「商品がどのように購入されているのか」という視点です。同じ商品でも購買に至るまでの経路や行動パターンはユーザーによって異なります。よく使われている経路や購買パターンがある。その「よく通られているルート」こそが大通りであり、そこを改善することがサイト全体の購買体験の底上げにつながります。\u003c/p\u003e\n\u003cp\u003e先ほどのECサイトで続けると、ログを分析した結果、大型家具を購入したユーザーの多くがトップページから特集ページを経由して商品ページに到達していたとします。一方で検索機能を使って直接商品ページに来たユーザーの購買率は低い。この場合トップページから特集ページへの導線が大通りです。特集ページのコンテンツを充実させる・季節や用途に合わせた特集を増やすといった施策は多くの購買ユーザーの行動に直接影響しますが、検索機能の改善は通過するユーザーが少ない分インパクトの上限が小さくなります。\u003c/p\u003e\n\u003cp\u003eこの2つの視点は排他的ではありません。「大型家具を買うユーザーがよく通る経路」のように掛け合わせることで大通りはより具体的に把握できます。\u003c/p\u003e\n\u003ch2 id=\"通りの大きさがわかれば施策のインパクトが読める\"\u003e通りの大きさがわかれば施策のインパクトが読める\u003c/h2\u003e\n\u003cp\u003e大通りがどこかわかればその通りの規模を使って施策のインパクトをシミュレーションできます。\u003c/p\u003e\n\u003cp\u003eたとえばあるセグメントの転換率を5ポイント改善したとして、そのセグメントの流入数と現在の単価から売上への影響を試算できます。大通りであれば多少コストや工数がかかる施策でも投資対効果が見合いやすく腰を据えて取り組む理由になります。逆に小道であれば「インパクトが小さいのでシンプルな施策に絞る」という制約が自然と生まれ、施策の設計も研ぎ澄まされます。\u003c/p\u003e\n\u003cp\u003e施策のインパクトを事前に試算する習慣は分析チームと事業側の対話を変えます。「この課題を改善しましょう」ではなく「この改善によってこれくらいのインパクトが見込めます」という会話ができるようになれば優先度の議論はより具体的になります。\u003c/p\u003e\n\u003ch2 id=\"大通りは組織で合意する\"\u003e大通りは組織で合意する\u003c/h2\u003e\n\u003cp\u003e大通りを定量的に把握することは分析チームの仕事ですが、それだけでは不十分です。\u003c/p\u003e\n\u003cp\u003e分析チームが「ここが大通りだ」と示しても各チームはそれぞれ自分の担当領域を大通りだと思って動きがちです。営業は自分が担当している顧客層を、マーケティングは自分が担当しているチャネルを大通りだと信じている。この状態のまま施策を走らせると前記事で述べたのと同じ問題が繰り返されます。各チームが自分の指標を追っているのに組織として同じ方向に向いていない状態です。\u003c/p\u003e\n\u003cp\u003e大通りの定義は分析チームが示して終わりではなく経営や事業責任者、現場を巻き込んで「ここが自分たちのコアだ」と合意するプロセスが必要になります。合意された大通りは組織の共通言語になります。施策のアイデアが出たときに「それは大通りへの投資か」という問いが自然に生まれるようになれば優先度の判断が組織全体でできるようになります。\u003c/p\u003e\n\u003ch2 id=\"まとめ\"\u003eまとめ\u003c/h2\u003e\n\u003cp\u003e分析で課題が見つかることは出発点にすぎません。その課題がビジネスのどこにあるのかを大通りという視点から評価することが次のステップです。\u003c/p\u003e\n\u003cp\u003e大通りとはユーザーがたくさん通りお金が動いているところ。「どの商品が誰に売れているか」と「商品がどのように購入されているか」という2つの視点で把握します。そして把握するだけでなく組織として合意することが大通りを判断の共通言語にするために欠かせません。\u003c/p\u003e\n\u003cp\u003e大通りがわかれば施策のインパクトを読めます。インパクトが読めれば優先度が決められます。優先度が決まれば組織のリソースをコアに集中させることができます。分析から行動への道筋はこの順番で整っていきます。\u003c/p\u003e","title":"データから大通りを探せ"},{"content":"課題が見えたら次は何をするか 前回の記事では経営に近い抽象的な指標をそのまま現場に渡しても「何を変えればいいのか」がわからないという問題を取り上げました。その解決策として指標をファネルや要素やセグメントに分解し課題の所在を具体的に特定することの重要性を述べました。\nでは分解して課題が見えたとして、見つかった課題に片っ端から対応すればよいのでしょうか？もちろん答えはノーです。課題が見えることと正しく対処できることのあいだにはもうひとつ大事なステップがあります。それが戦略です。\n見つかった課題をそのまま各チームのKPIに据えて改善を任せるというのはよくある流れです。しかし、このように漫然とした進め方では上手くいきません。マーケティングはリード数を追い営業は成約率を追いカスタマーサクセスは解約率を追う。それぞれは正しく見えますが全体としてどこに向かっているのかが定まっておらず組織の成果につながりにくい状況へなりがちです。\n課題の特定と施策の実行のあいだには「どこに集中するか」を決める戦略が欠かせません。本記事ではこの戦略とKPIの関係を整理します。\n全部やろうとすると全部中途半端になる 指標を分解すれば改善すべきポイントはいくつも出てきます。たとえば「リード獲得率が落ちている」「商談からの成約率も低い」「既存顧客の解約率も上がっている」など、どれも放置できない課題です。\nここで「全部やろう」となるのは自然な感覚ですし危機感の表れでもあります。しかし全体の方向性がないまま各チームが自分の担当する課題に個別に取り組み始めるとそれぞれの合理的な判断が噛み合わず組織として逆方向に進んでしまうことがあります。\nたとえばこんなケースを考えてみます。マーケティングはリード数を伸ばすために獲得しやすい中小企業向けの広告に予算を寄せる。営業は成約率を上げるために意思決定の早い小規模案件を優先する。カスタマーサクセスは解約率を下げるために一社一社に手厚いサポートを提供する。どのチームも自分の指標を改善するために合理的な判断をしています。\nしかし結果として起きるのは単価の低い顧客ばかりが増え一人あたりのサポートコストが利益を食いつぶしていくという状態です。仮に本来この事業がエンタープライズ向けに舵を切るべき局面にあったとすれば組織全体が逆方向に進んでいることになります。個々のチームの数字は改善しているのに事業としては悪化している。これは各チームの努力が間違っていたのではなく全体の方向性が定まっていなかったこと、そして事業の方向性と一致していなかったことが原因です。\nどの課題に優先的に取り組むのかを決める。その判断こそが戦略です。\n指標の分解は戦略のために行う ここで前回の記事を振り返ります。指標を分解して課題を特定することは重要です。しかしその目的を改めて整理すると指標の分解とは戦略を考えるための材料を揃える行為だと言えます。\n指標の分解はこのプロセスの起点であり手段です。分解すること自体が目的になってしまうと「課題はたくさん見つかったがどこから手をつければいいかわからない」という状態に陥ります。これは分析が足りないのではなく判断が足りないのです。\n分析チームは指標の分解によって課題の全体像を提示する。意思決定者はそのなかから組織として取り組むべき課題を選ぶ。現場はその判断に基づいて具体的なアクションを設計し実行する。それぞれの役割が噛み合ってはじめて分析から成果につながる流れが生まれます。\n戦略を定量化したものがKPI ここまでの話を踏まえるとKPIの位置づけも明確になります。\n指標を分解すれば改善候補となる指標はいくつも出てきます。しかしそのすべてをKPIにするわけにはいきません。すべてを追えばリソースが分散し結局どれも十分に改善できないという先ほどの問題に戻ってしまいます。\nKPIとは分解によって見えてきた複数の指標のなかから戦略的な判断に基づいて選ばれるものです。「この課題がいま最も重要でありここに集中することが全体の成果につながる」という意思決定の結果として定められる指標がKPIだと言えます。\n「KPIはなぜ\u0026quot;重要\u0026quot;なのか」と聞かれることがありますが、KPIとして選ばれた指標が重要たり得るのはそれが戦略を定量的に表しているからです。KPIの背後には「どの課題を優先するか」「なぜその課題なのか」という戦略的な判断があります。それらの戦略の状態や進捗を定量的に示すから Key-Performance-Indicator なのです。\n言い換えればKPIとは課題がわかるくらいに具体的であり組織としてその改善を優先すると決めた指標のことです。具体性と優先度の両方が揃ってはじめてKPIとして機能します。\n戦略がなければKPIは機能しない ここまでの議論を裏返すと戦略が不在のままKPIを設定することの危うさが見えてきます。\n戦略がない状態で指標を分解しそのまま各チームにKPIとして渡すとどうなるか。各チームは与えられた数字を改善することに集中します。それ自体は真摯な取り組みです。しかし各KPIのあいだに優先順位がなくそれらがどの方向に向かっているのかも示されていなければ個々の改善努力が全体の成果に結びつきません。\n問題はそれだけではありません。一度KPIとして設定された数字は組織のなかで独り歩きしやすくなります。「なぜこの指標を追っているのか」という背景が薄れ「この数字を上げなければいけない」という部分だけが残ってしまい、環境が変わっても市場の優先課題がずれてもKPIだけは据え置かれたまま組織が動き続ける、なんてことが起こります。\nもし戦略に基づいてKPIを設定していれば環境が変わったときにKPIの妥当性を問い直すことができます。「この指標を追う理由は何か」「いまの戦略に照らしてまだ有効か」という判断基準があるからです。しかし戦略がなければその問い直しの根拠がありません。KPIを変えるべきタイミングで変えられず組織が古い指標に縛られ続けるリスクがあります。\nまとめ 指標を分解して課題を見つけることは重要ですがそれだけではアクションにつながりません。見つかった課題のなかからどれに集中するかを決めること、つまり戦略を立てることが不可欠です。\nKPIとは戦略を定量化した指標であり分解から生まれた多くの候補のなかから「いまここに集中する」と組織として判断した結果として定められるものです。戦略的な判断がなければKPIは単なる数字の羅列になりかねません。\n戦略なくしてKPIなし。KPIの設定は分析の延長線上にあるのではなく戦略の延長線上にあるものです。\n","permalink":"https://kenjiusui.github.io/blog/posts/biz/010_%E6%88%A6%E7%95%A5%E3%81%AA%E3%81%8F%E3%81%97%E3%81%A6kpi%E3%81%AA%E3%81%97/","summary":"\u003ch2 id=\"課題が見えたら次は何をするか\"\u003e課題が見えたら次は何をするか\u003c/h2\u003e\n\u003cp\u003e前回の記事では経営に近い抽象的な指標をそのまま現場に渡しても「何を変えればいいのか」がわからないという問題を取り上げました。その解決策として指標をファネルや要素やセグメントに分解し課題の所在を具体的に特定することの重要性を述べました。\u003c/p\u003e\n\u003cp\u003eでは分解して課題が見えたとして、見つかった課題に片っ端から対応すればよいのでしょうか？もちろん答えはノーです。課題が見えることと正しく対処できることのあいだにはもうひとつ大事なステップがあります。それが戦略です。\u003c/p\u003e\n\u003cp\u003e見つかった課題をそのまま各チームのKPIに据えて改善を任せるというのはよくある流れです。しかし、このように漫然とした進め方では上手くいきません。マーケティングはリード数を追い営業は成約率を追いカスタマーサクセスは解約率を追う。それぞれは正しく見えますが全体としてどこに向かっているのかが定まっておらず組織の成果につながりにくい状況へなりがちです。\u003c/p\u003e\n\u003cp\u003e課題の特定と施策の実行のあいだには「どこに集中するか」を決める戦略が欠かせません。本記事ではこの戦略とKPIの関係を整理します。\u003c/p\u003e\n\u003ch2 id=\"全部やろうとすると全部中途半端になる\"\u003e全部やろうとすると全部中途半端になる\u003c/h2\u003e\n\u003cp\u003e指標を分解すれば改善すべきポイントはいくつも出てきます。たとえば「リード獲得率が落ちている」「商談からの成約率も低い」「既存顧客の解約率も上がっている」など、どれも放置できない課題です。\u003c/p\u003e\n\u003cp\u003eここで「全部やろう」となるのは自然な感覚ですし危機感の表れでもあります。しかし全体の方向性がないまま各チームが自分の担当する課題に個別に取り組み始めるとそれぞれの合理的な判断が噛み合わず組織として逆方向に進んでしまうことがあります。\u003c/p\u003e\n\u003cp\u003eたとえばこんなケースを考えてみます。マーケティングはリード数を伸ばすために獲得しやすい中小企業向けの広告に予算を寄せる。営業は成約率を上げるために意思決定の早い小規模案件を優先する。カスタマーサクセスは解約率を下げるために一社一社に手厚いサポートを提供する。どのチームも自分の指標を改善するために合理的な判断をしています。\u003c/p\u003e\n\u003cp\u003eしかし結果として起きるのは単価の低い顧客ばかりが増え一人あたりのサポートコストが利益を食いつぶしていくという状態です。仮に本来この事業がエンタープライズ向けに舵を切るべき局面にあったとすれば組織全体が逆方向に進んでいることになります。個々のチームの数字は改善しているのに事業としては悪化している。これは各チームの努力が間違っていたのではなく全体の方向性が定まっていなかったこと、そして事業の方向性と一致していなかったことが原因です。\u003c/p\u003e\n\u003cp\u003eどの課題に優先的に取り組むのかを決める。その判断こそが戦略です。\u003c/p\u003e\n\u003ch2 id=\"指標の分解は戦略のために行う\"\u003e指標の分解は戦略のために行う\u003c/h2\u003e\n\u003cp\u003eここで前回の記事を振り返ります。指標を分解して課題を特定することは重要です。しかしその目的を改めて整理すると指標の分解とは戦略を考えるための材料を揃える行為だと言えます。\u003c/p\u003e\n\u003cp\u003e指標の分解はこのプロセスの起点であり手段です。分解すること自体が目的になってしまうと「課題はたくさん見つかったがどこから手をつければいいかわからない」という状態に陥ります。これは分析が足りないのではなく判断が足りないのです。\u003c/p\u003e\n\u003cp\u003e分析チームは指標の分解によって課題の全体像を提示する。意思決定者はそのなかから組織として取り組むべき課題を選ぶ。現場はその判断に基づいて具体的なアクションを設計し実行する。それぞれの役割が噛み合ってはじめて分析から成果につながる流れが生まれます。\u003c/p\u003e\n\u003ch2 id=\"戦略を定量化したものがkpi\"\u003e戦略を定量化したものがKPI\u003c/h2\u003e\n\u003cp\u003eここまでの話を踏まえるとKPIの位置づけも明確になります。\u003c/p\u003e\n\u003cp\u003e指標を分解すれば改善候補となる指標はいくつも出てきます。しかしそのすべてをKPIにするわけにはいきません。すべてを追えばリソースが分散し結局どれも十分に改善できないという先ほどの問題に戻ってしまいます。\u003c/p\u003e\n\u003cp\u003eKPIとは分解によって見えてきた複数の指標のなかから戦略的な判断に基づいて選ばれるものです。「この課題がいま最も重要でありここに集中することが全体の成果につながる」という意思決定の結果として定められる指標がKPIだと言えます。\u003c/p\u003e\n\u003cp\u003e「KPIはなぜ\u0026quot;重要\u0026quot;なのか」と聞かれることがありますが、KPIとして選ばれた指標が重要たり得るのはそれが戦略を定量的に表しているからです。KPIの背後には「どの課題を優先するか」「なぜその課題なのか」という戦略的な判断があります。それらの戦略の状態や進捗を定量的に示すから Key-Performance-Indicator なのです。\u003c/p\u003e\n\u003cp\u003e言い換えればKPIとは課題がわかるくらいに具体的であり組織としてその改善を優先すると決めた指標のことです。具体性と優先度の両方が揃ってはじめてKPIとして機能します。\u003c/p\u003e\n\u003ch2 id=\"戦略がなければkpiは機能しない\"\u003e戦略がなければKPIは機能しない\u003c/h2\u003e\n\u003cp\u003eここまでの議論を裏返すと戦略が不在のままKPIを設定することの危うさが見えてきます。\u003c/p\u003e\n\u003cp\u003e戦略がない状態で指標を分解しそのまま各チームにKPIとして渡すとどうなるか。各チームは与えられた数字を改善することに集中します。それ自体は真摯な取り組みです。しかし各KPIのあいだに優先順位がなくそれらがどの方向に向かっているのかも示されていなければ個々の改善努力が全体の成果に結びつきません。\u003c/p\u003e\n\u003cp\u003e問題はそれだけではありません。一度KPIとして設定された数字は組織のなかで独り歩きしやすくなります。「なぜこの指標を追っているのか」という背景が薄れ「この数字を上げなければいけない」という部分だけが残ってしまい、環境が変わっても市場の優先課題がずれてもKPIだけは据え置かれたまま組織が動き続ける、なんてことが起こります。\u003c/p\u003e\n\u003cp\u003eもし戦略に基づいてKPIを設定していれば環境が変わったときにKPIの妥当性を問い直すことができます。「この指標を追う理由は何か」「いまの戦略に照らしてまだ有効か」という判断基準があるからです。しかし戦略がなければその問い直しの根拠がありません。KPIを変えるべきタイミングで変えられず組織が古い指標に縛られ続けるリスクがあります。\u003c/p\u003e\n\u003ch2 id=\"まとめ\"\u003eまとめ\u003c/h2\u003e\n\u003cp\u003e指標を分解して課題を見つけることは重要ですがそれだけではアクションにつながりません。見つかった課題のなかからどれに集中するかを決めること、つまり戦略を立てることが不可欠です。\u003c/p\u003e\n\u003cp\u003eKPIとは戦略を定量化した指標であり分解から生まれた多くの候補のなかから「いまここに集中する」と組織として判断した結果として定められるものです。戦略的な判断がなければKPIは単なる数字の羅列になりかねません。\u003c/p\u003e\n\u003cp\u003e戦略なくしてKPIなし。KPIの設定は分析の延長線上にあるのではなく戦略の延長線上にあるものです。\u003c/p\u003e","title":"戦略なくしてKPIなし"},{"content":"データはあるのに動けない 「データを見ているのに現場が動かない」という話をよく聞きます。ダッシュボードも整備した。数値から課題は見えている。それなのに現場の動きが変わらない。この状況に心当たりがある方は多いのではないでしょうか。\n分析チームからすると「データは出しているのに活用されない」と感じているかもしれませんが、現場からすれば「その数字を見せられても何をすればいいか考えられない」とおもっているかもしれません。これはどちらかが悪いという話ではありません。この噛み合わなさには構造的な原因があるのです。\nこの記事では、この問題が発生する原因として経営に近い指標は抽象度が高く現場では使いにくいという課題を解説しながら、対策として指標を分解することで現場で使いやすくするという考え方を紹介します。\n経営に近い指標は現場では使いにくい 多くの組織でデータ分析の起点になるのは売上や顧客数といった経営において重要視されている指標です。当然ながらこれらは組織にとって重要な数字であり注視すべきものです。\nしかしこうした指標をそのまま現場に渡しても「売上が下がっています」「顧客数が伸びていません」という報告にしかなりません。\nここに問題の本質があります。売上が落ちていること、顧客数が伸びていないことなんて現場の人間だってわかっています。日々の業務を通じて直感的な理解あるいはそのレベルの数値は現場でも持っていることが多いでしょう。\nしかも現場はその課題に対してすでにアクションを取っています。施策を打ち改善の努力を続けている。それでも数字が動かないから困っているのです。\n現場が本当に知りたいのは「売上が落ちている」というレイヤーの事実ではありません。「今やっていることの何をどう変えればいいのか」であり「具体的な問題はどこなのか？」ということです。経営に近い抽象的な指標はこの問いに答えることができません。だからデータを見ても現場のアクションにつながらないのです。\n指標を分解して深堀りする ではどうすればいいのか。答えはシンプルで経営に近い指標をそのまま使うのではなく分解して深堀りすることです。\nここでいう分解とは単に数式的・論理的に要素を分けることだけではありません。ファネルの段階ごとに分けたりセグメントごとに切り分けたりすることも含みます。\n分解の目的は「どこに問題があるのか」を具体的に特定することです。指標が抽象的なままでは打ち手も抽象的になります。分解して問題の所在を絞り込むことで初めて「何を変えるべきか」という現場が求める問いに近づけるのです。\n分解にはいくつかの視点があります。\nファネルでの分解は全体のプロセスをステップごとに分けてどの段階で数字が落ちているかを特定します。これによって「どの工程に問題があるのか」が見えてきます。\n要素への分解はひとつのステップをさらに構成要素に分けることです。量の問題なのか質の問題なのかといった切り口で課題の性質を特定します。\nセグメントでの分解は顧客の属性や行動パターンごとに数字を切り分けることです。全体で見ると問題に見えていたものが特定のセグメントに偏っていると気づければ打ち手はぐっと具体的になります。\nこれらの分解は排他的なものではなく組み合わせて使うものです。ファネルで問題のある段階を特定しそこを要素やセグメントでさらに深堀りするというように段階的に絞り込んでいきます。\n顧客数が伸びないときを例にかんがえてみる ここまでの考え方を顧客数の問題を例に見てみます。\nファネルでチョークポイントを特定する 「顧客数が伸びない」という課題をそのまま扱おうとすると打ち手は漠然としたものになります。まずファネルに分解して問題がどの段階にあるのかを特定します。\nたとえばBtoBのSaaS事業であれば広告表示→サイト訪問→資料請求（リード獲得）→商談→成約というファネルが考えられます。この各ステップの件数と転換率を並べてみると全体のどこで数字が大きく落ちているかが見えてきます。\n仮にサイト訪問数は前年並みなのに資料請求数が大きく減っているとしましょう。この時点で「顧客数が伸びない」という曖昧な課題が「リード獲得の段階に問題がある」という具体的な論点に変わります。\n要素とセグメントでさらに深堀りする ファネルからチョークポイントが特定できたら次はその段階をさらに分解します。\nまず要素への分解です。資料請求が減っているのは量の問題なのか質の問題なのか。サイトへの流入数自体が減っているのかそれとも流入は維持されているのに資料請求への転換率が下がっているのか。量の問題であれば集客施策を見直す必要がありますし転換率の問題であればLPや訴求内容に原因がある可能性が出てきます。これだけでも打ち手の方向性は大きく変わります。\n次にセグメントでの分解です。流入元の媒体ごとに転換率を見たときにリスティング広告は横ばいなのにSNS広告経由だけが大きく落ちているかもしれません。あるいはターゲットセグメントごとに見ると中小企業向けのリードは堅調なのにエンタープライズ向けのリードだけが減っているかもしれません。業種や企業規模といった属性で切り分けることで全体の平均に隠れていた偏りが浮かび上がります。\nこうして段階的に分解していくと「顧客数が伸びない」という漠然とした課題が「SNS広告経由のエンタープライズ層のリード獲得率が落ちている」といった具体的な問題に変わります。ここまで絞り込めれば現場は「何を変えるべきか」を考えられるようになりますし分析チームと現場が同じ問題について具体的に議論できるようになります。\n具体的にすればいいわけでもない ここまで指標を分解して具体化する重要性を述べてきましたが注意点があります。具体化しすぎると今度は別の問題が起きます。\n指標が具体的になるほど現場はその数字を改善することだけに集中しやすくなりますが、これは行動が特定の指標に引っ張られて局所最適に陥りやすくもあります。\n本来であれば現場にはさまざまなアプローチを試す余地があるはずですが具体的すぎる指標はその多様性を奪います。「この数字を上げればいい」という明快さが逆にアクションの幅を狭めてしまうのです。\nたとえば「SNS広告経由のエンタープライズ層のリード獲得率が落ちている」という問題に執着してしまうと「SNSではなくセミナーのほうが効率がよいかもしれない」というソリューションにたどり着きにくくなってしまいます。あくまでも本来の目的はリード獲得率の改善ですから、ほかのアプローチを模索したほうが効率がよい可能性もあります。\n具体的な指標はわかりやすく行動を促す力が強い分だけ視野を狭める力も強くなります。これは分解の粒度を考えるうえで常に意識しておくべきことです。\n分解の目的はあくまで「どこに問題があるのか」を特定して対話の土台をつくることです。分解した結果をそのままKPIとして現場に渡すこととは違います。分析チームと現場が分解の結果を見ながら「ではどうするか」を一緒に考える。そのプロセスがあってこそ分解は意味を持ちます。\nまとめ データ分析からアクションが生まれない原因は分析する側の力不足でも現場の理解不足でもありません。経営に近い抽象的な指標がそのまま現場に渡されることで「何を変えればいいのか」「どこに解くべき課題があるのか」という問いに答えられていないことが根本的な原因です。\nこの問題を解決するには指標をファネルや要素やセグメントに分解して「どこに問題があるのか」を具体的に特定していくことが必要です。分解によって問題の所在が明確になれば分析チームと現場が同じ具体的な課題について対話できるようになります。\nデータ分析の価値は数字を出すことではなく「次に何をすべきか」を一緒に考える土台をつくることにあります。そのためにまずは指標の分解から始めてみましょう。\n","permalink":"https://kenjiusui.github.io/blog/posts/biz/009_%E3%83%87%E3%83%BC%E3%82%BF%E5%88%86%E6%9E%90%E3%81%8B%E3%82%89%E3%82%A2%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%8C%E7%94%9F%E3%81%BE%E3%82%8C%E3%81%AA%E3%81%84%E3%81%AE%E3%81%AF%E3%81%AA%E3%81%9C%E3%81%8B/","summary":"\u003ch2 id=\"データはあるのに動けない\"\u003eデータはあるのに動けない\u003c/h2\u003e\n\u003cp\u003e「データを見ているのに現場が動かない」という話をよく聞きます。ダッシュボードも整備した。数値から課題は見えている。それなのに現場の動きが変わらない。この状況に心当たりがある方は多いのではないでしょうか。\u003c/p\u003e\n\u003cp\u003e分析チームからすると「データは出しているのに活用されない」と感じているかもしれませんが、現場からすれば「その数字を見せられても何をすればいいか考えられない」とおもっているかもしれません。これはどちらかが悪いという話ではありません。この噛み合わなさには構造的な原因があるのです。\u003c/p\u003e\n\u003cp\u003eこの記事では、この問題が発生する原因として経営に近い指標は抽象度が高く現場では使いにくいという課題を解説しながら、対策として指標を分解することで現場で使いやすくするという考え方を紹介します。\u003c/p\u003e\n\u003ch2 id=\"経営に近い指標は現場では使いにくい\"\u003e経営に近い指標は現場では使いにくい\u003c/h2\u003e\n\u003cp\u003e多くの組織でデータ分析の起点になるのは売上や顧客数といった経営において重要視されている指標です。当然ながらこれらは組織にとって重要な数字であり注視すべきものです。\u003c/p\u003e\n\u003cp\u003eしかしこうした指標をそのまま現場に渡しても「売上が下がっています」「顧客数が伸びていません」という報告にしかなりません。\u003c/p\u003e\n\u003cp\u003eここに問題の本質があります。売上が落ちていること、顧客数が伸びていないことなんて現場の人間だってわかっています。日々の業務を通じて直感的な理解あるいはそのレベルの数値は現場でも持っていることが多いでしょう。\u003c/p\u003e\n\u003cp\u003eしかも現場はその課題に対してすでにアクションを取っています。施策を打ち改善の努力を続けている。それでも数字が動かないから困っているのです。\u003c/p\u003e\n\u003cp\u003e現場が本当に知りたいのは「売上が落ちている」というレイヤーの事実ではありません。「今やっていることの何をどう変えればいいのか」であり「具体的な問題はどこなのか？」ということです。経営に近い抽象的な指標はこの問いに答えることができません。だからデータを見ても現場のアクションにつながらないのです。\u003c/p\u003e\n\u003ch2 id=\"指標を分解して深堀りする\"\u003e指標を分解して深堀りする\u003c/h2\u003e\n\u003cp\u003eではどうすればいいのか。答えはシンプルで経営に近い指標をそのまま使うのではなく分解して深堀りすることです。\u003c/p\u003e\n\u003cp\u003eここでいう分解とは単に数式的・論理的に要素を分けることだけではありません。ファネルの段階ごとに分けたりセグメントごとに切り分けたりすることも含みます。\u003c/p\u003e\n\u003cp\u003e分解の目的は「どこに問題があるのか」を具体的に特定することです。指標が抽象的なままでは打ち手も抽象的になります。分解して問題の所在を絞り込むことで初めて「何を変えるべきか」という現場が求める問いに近づけるのです。\u003c/p\u003e\n\u003cp\u003e分解にはいくつかの視点があります。\u003c/p\u003e\n\u003cp\u003eファネルでの分解は全体のプロセスをステップごとに分けてどの段階で数字が落ちているかを特定します。これによって「どの工程に問題があるのか」が見えてきます。\u003c/p\u003e\n\u003cp\u003e要素への分解はひとつのステップをさらに構成要素に分けることです。量の問題なのか質の問題なのかといった切り口で課題の性質を特定します。\u003c/p\u003e\n\u003cp\u003eセグメントでの分解は顧客の属性や行動パターンごとに数字を切り分けることです。全体で見ると問題に見えていたものが特定のセグメントに偏っていると気づければ打ち手はぐっと具体的になります。\u003c/p\u003e\n\u003cp\u003eこれらの分解は排他的なものではなく組み合わせて使うものです。ファネルで問題のある段階を特定しそこを要素やセグメントでさらに深堀りするというように段階的に絞り込んでいきます。\u003c/p\u003e\n\u003ch2 id=\"顧客数が伸びないときを例にかんがえてみる\"\u003e顧客数が伸びないときを例にかんがえてみる\u003c/h2\u003e\n\u003cp\u003eここまでの考え方を顧客数の問題を例に見てみます。\u003c/p\u003e\n\u003ch3 id=\"ファネルでチョークポイントを特定する\"\u003eファネルでチョークポイントを特定する\u003c/h3\u003e\n\u003cp\u003e「顧客数が伸びない」という課題をそのまま扱おうとすると打ち手は漠然としたものになります。まずファネルに分解して問題がどの段階にあるのかを特定します。\u003c/p\u003e\n\u003cp\u003eたとえばBtoBのSaaS事業であれば広告表示→サイト訪問→資料請求（リード獲得）→商談→成約というファネルが考えられます。この各ステップの件数と転換率を並べてみると全体のどこで数字が大きく落ちているかが見えてきます。\u003c/p\u003e\n\u003cp\u003e仮にサイト訪問数は前年並みなのに資料請求数が大きく減っているとしましょう。この時点で「顧客数が伸びない」という曖昧な課題が「リード獲得の段階に問題がある」という具体的な論点に変わります。\u003c/p\u003e\n\u003ch3 id=\"要素とセグメントでさらに深堀りする\"\u003e要素とセグメントでさらに深堀りする\u003c/h3\u003e\n\u003cp\u003eファネルからチョークポイントが特定できたら次はその段階をさらに分解します。\u003c/p\u003e\n\u003cp\u003eまず要素への分解です。資料請求が減っているのは量の問題なのか質の問題なのか。サイトへの流入数自体が減っているのかそれとも流入は維持されているのに資料請求への転換率が下がっているのか。量の問題であれば集客施策を見直す必要がありますし転換率の問題であればLPや訴求内容に原因がある可能性が出てきます。これだけでも打ち手の方向性は大きく変わります。\u003c/p\u003e\n\u003cp\u003e次にセグメントでの分解です。流入元の媒体ごとに転換率を見たときにリスティング広告は横ばいなのにSNS広告経由だけが大きく落ちているかもしれません。あるいはターゲットセグメントごとに見ると中小企業向けのリードは堅調なのにエンタープライズ向けのリードだけが減っているかもしれません。業種や企業規模といった属性で切り分けることで全体の平均に隠れていた偏りが浮かび上がります。\u003c/p\u003e\n\u003cp\u003eこうして段階的に分解していくと「顧客数が伸びない」という漠然とした課題が「SNS広告経由のエンタープライズ層のリード獲得率が落ちている」といった具体的な問題に変わります。ここまで絞り込めれば現場は「何を変えるべきか」を考えられるようになりますし分析チームと現場が同じ問題について具体的に議論できるようになります。\u003c/p\u003e\n\u003ch2 id=\"具体的にすればいいわけでもない\"\u003e具体的にすればいいわけでもない\u003c/h2\u003e\n\u003cp\u003eここまで指標を分解して具体化する重要性を述べてきましたが注意点があります。具体化しすぎると今度は別の問題が起きます。\u003c/p\u003e\n\u003cp\u003e指標が具体的になるほど現場はその数字を改善することだけに集中しやすくなりますが、これは行動が特定の指標に引っ張られて局所最適に陥りやすくもあります。\u003c/p\u003e\n\u003cp\u003e本来であれば現場にはさまざまなアプローチを試す余地があるはずですが具体的すぎる指標はその多様性を奪います。「この数字を上げればいい」という明快さが逆にアクションの幅を狭めてしまうのです。\u003c/p\u003e\n\u003cp\u003eたとえば「SNS広告経由のエンタープライズ層のリード獲得率が落ちている」という問題に執着してしまうと「SNSではなくセミナーのほうが効率がよいかもしれない」というソリューションにたどり着きにくくなってしまいます。あくまでも本来の目的はリード獲得率の改善ですから、ほかのアプローチを模索したほうが効率がよい可能性もあります。\u003c/p\u003e\n\u003cp\u003e具体的な指標はわかりやすく行動を促す力が強い分だけ視野を狭める力も強くなります。これは分解の粒度を考えるうえで常に意識しておくべきことです。\u003c/p\u003e\n\u003cp\u003e分解の目的はあくまで「どこに問題があるのか」を特定して対話の土台をつくることです。分解した結果をそのままKPIとして現場に渡すこととは違います。分析チームと現場が分解の結果を見ながら「ではどうするか」を一緒に考える。そのプロセスがあってこそ分解は意味を持ちます。\u003c/p\u003e\n\u003ch2 id=\"まとめ\"\u003eまとめ\u003c/h2\u003e\n\u003cp\u003eデータ分析からアクションが生まれない原因は分析する側の力不足でも現場の理解不足でもありません。経営に近い抽象的な指標がそのまま現場に渡されることで「何を変えればいいのか」「どこに解くべき課題があるのか」という問いに答えられていないことが根本的な原因です。\u003c/p\u003e\n\u003cp\u003eこの問題を解決するには指標をファネルや要素やセグメントに分解して「どこに問題があるのか」を具体的に特定していくことが必要です。分解によって問題の所在が明確になれば分析チームと現場が同じ具体的な課題について対話できるようになります。\u003c/p\u003e\n\u003cp\u003eデータ分析の価値は数字を出すことではなく「次に何をすべきか」を一緒に考える土台をつくることにあります。そのためにまずは指標の分解から始めてみましょう。\u003c/p\u003e","title":"データ分析からアクションが生まれないのはなぜか？"},{"content":"はじめに この記事ではビジネスにおいてデータを分析した意思決定をおこなう目的やメリットを紹介します。\nさまざまな場所で議論されているテーマですが自分なりの考えをまとめたく記事として残します。\n似たようなテーマで複数の観点から解説していく予定です。\n意思決定における2つのアプローチ ビジネスの現場では複数の選択肢からどれか1つを選ばなければいけないというシーンがよくあります。\nたとえば、マーケティングにおいて「商品のプロモーション用に広告AとBの2つの候補からどちらを選ばなければいけない」なんてシーンは想像に容易いでしょう。\n他にも「どの見込み顧客から営業をするべきか？」とか「このプロダクトのボタンは赤と青どちらの色にしたらいいだろうか？」なんてことを考えている人はきっとこの記事を読んでいる方にもいるのではないでしょうか。\nこれは日常的な風景ですが、しかしこれらの意思決定によって売上が変わる可能性を秘めています。\n下手な広告を選んだら獲得できるリードは減るかもしれませんし、営業の優先順位を間違えば大事な顧客を逃しているかもしれません。\nボタンの色が不評であれば機能を使う人が減ってしまう可能性もあります。\n1つ1つの意思決定の質が企業の売上や成長へ直結する重要な要素です。\nでは、わたしたちはどのように意思決定をしていけばよいのでしょうか？この問題に対するアプローチを大きく2つにわけて考えていきます。\n1つは経験や知識に基づく意思決定、もう1つは客観的なデータに基づく意思決定です。\nどちらも現代のビジネスにおいて重要な役割を果たしていますが有効なシーンに違いがあります。\nこの2つのアプローチを比較することでそれぞれの特徴を理解し上手い使い方を把握していきましょう。\n経験に基づく意思決定の特徴と限界 長年マーケティング業界で活躍してきたベテラン担当者であれば事例や過去の体験から「このターゲット層にはこういったメッセージが響きやすい」とか「今の時期にはこのタイプの広告が効果的だった」のような経験則を蓄積しているものです。\n市場や顧客の心理など数値化が困難な要素を感覚的に捉える能力はベテランの貴重な資産といえるでしょう。\n特に参考となる情報が乏しいまったく新しい市場や商品カテゴリーのような問題ではこのような経験や知識に基づく判断が強力な手法となります。\nしかし、このような経験に基づく意思決定には欠点がいくつか存在します。\nその1つは判断の基準が個人の主観的な観察や経験に依存しているということです。\n例えば、新しい広告を展開した際にたまたま接触した顧客から「この広告は印象的で良かった」という好意的な反応を得たとします。\nこのような直接的なフィードバックは重要ですが担当者に実態以上に強い印象を与えがちで全体の傾向を正確に反映しているとも限りません。\n接触した顧客層が特殊だった可能性、季節や時期による一時的な要因、さらには観察者自身の期待や先入観が判断を歪めている可能性などさまざまなバイアスが混入するリスクがあります。\nたまたまその顧客が気に入っただけで多くの人は別の要因で商品を買っただけかもしれませんし、もしかしたら顧客がお世辞をいっただけという可能性もあります。\n心理学でいう「確証バイアス」により自分の判断を支持する情報ばかりに注目し反対の証拠を無視してしまうこともよく見かけます。\n経験に基づく意思決定がその人に固有の知識や感覚に強く依存するため、品質のコントロールが難しく再現性や客観性に欠けるという点です。\n同じ状況でも担当者が変われば全く異なる判断が下される可能性があり、組織として一貫した品質の意思決定を維持することは簡単ではありません。\nデータに基づく意思決定の特徴と優位性 これに対して十分なデータが蓄積され適切に分析できる環境が整っている場合、意思決定のアプローチは根本的に変化します。\nデータに基づく意思決定では実際に顧客がクリックしたり売上につながった広告やコンバージョンに結びついた施策を客観的な数値として把握することで感情や先入観に左右されない合理的な判断が可能になります。\n具体的な例を見ながら広告AとBのどちらがよいのか考えてみましょう。\n広告A\n表示回数10万回 クリック数2,000回（クリック率2.0%） コンバージョン数80件（コンバージョン率4.0%） 獲得単価5,000円 広告B\n表示回数10万回 クリック数1,500回（クリック率1.5%） コンバージョン数90件（コンバージョン率6.0%） 獲得単価4,500円 このようなデータがあれば、どちらの広告がより効果的かを明確に判断できます。\nこの例では、広告Bの方がコンバージョン率が高く、獲得単価も安いことがわかりました。\nそれぞれの指標について学んだ人であれば、投資対効果の観点から広告Bが優れていることが数値から読み取ることができるでしょう。\nA/Bテストのような事前に準備された実験でデータを収集した場合、データの価値はさらに高まります。\nA/Bテストであれば同じ期間、同じ予算、同じターゲット層に対してランダムに異なる広告を展開し統計的に比較することでどちらがより効果的か高い信頼性をもって客観的に判断できます。\nこのような手法では、季節要因、競合他社の動向、市場環境の変化といった外部要因の影響を最小限に抑えることができ、純粋に広告自体の効果を測定することが可能になります。\nデータに基づく判断のメリットは個人の経験や直感に依存度が低く誰が見ても同じ結論に到達できることです。\nマーケティング部門の新人からベテランまで同じデータを見れば基本的に同じ判断を下すことができます。\nこれは経験に基づく意思決定とは対照的な特徴であり組織全体の意思決定の品質向上に大きく貢献します。\nデータ活用による継続的な学習と改善 データに基づく意思決定のもう一つの重要な利点は、継続的な学習と改善のサイクルを構築できることです。\n広告Aと広告Bの効果を測定した結果、広告Bが優れていることが判明したとします。\nしかし、データ活用の価値はここで終わりません。\n広告がどのようなセグメントに効果的だったのか調査することで次回の広告制作時により効果的な施策を企画するために活かすことができます。\nたとえば「広告Bは都市部のユーザーには効果があったが地方ではいまいちだった」とか「実は広告Aは獲得が難しいセグメントで比較すると優位だった」といったことがわかればターゲットに対して効果的な広告を展開できるようになります。\nこれらの知見は組織の資産として蓄積され強力な武器となるでしょう。\nまた、時系列でのデータ分析により、季節性や市場トレンドの変化も把握できます。\n「夏季は広告Aが効果的だが、冬季は広告Bの方が良い」といったパターンが見えてくれば、時期に応じた最適な施策を事前に計画することも可能になります。\n「広告Bはよかったが市場の変化によって費用対効果が悪くなっている」ということがわかれば新しい広告を検討すべきだとわかります。\nこのような継続的な学習プロセスにより組織のマーケティング能力は段階的に向上していきます。\nデータの蓄積期間が長くなればなるほどデータを通した知見も蓄積され意思決定の品質も高まります。\nこれは個人の能力に依存した意思決定だけではなかなか難しいことです。\n組織全体での意思決定品質の標準化 データに基づく意思決定は組織全体での意思決定品質の標準化にも大きく貢献します。\n経験に基づく判断では意思決定者の能力や経験値によって判断の質に大きな差が生まれます。\n20年の経験を持つベテランマーケターと入社1年目の新人を比べたら判断の精度に差が出るのは自然なことです。\nしかし、データに基づく意思決定の仕組みが整備されていればこの格差を大幅に縮小することができます。\n新人でも適切なデータの読み取り方と分析手法を身につけることでベテランと同等の判断を下すことが可能になります。\nこれは個人のスキルに依存しない組織として安定した品質の意思決定システムを構築できるということです。\n意思決定の標準化によって論点がクリアになり判断の速度も向上します。\n「こっちのほうが好きな人が多そう」とか「前にあった顧客はこの広告を褒めていた」といった主観や経験に基づく議論では簡単に決着がつきません。\n判断軸と評価が曖昧なため最終的に立場や社内政治で物事が決まってしまうこともあるでしょう。\n一方で「データによるとクリック率が1.5倍高い」「コンバージョン率で比較すれば明確に優位性がある」といった客観的な根拠に基づいた議論であれば論点が明確になりスムーズに判断することができます。\nこれは意思決定の高速化を同時にもたらします。\n2つのアプローチの使い分けと組み合わせ方 現代のビジネス環境では経験に基づく意思決定とデータに基づく意思決定を適切に使い分け組み合わせることが重要です。\nすべての状況でデータが利用できるわけではありませんし、すべての要素が数値化できるわけでもありません。\n新市場への参入や全く新しいタイプの商品・サービスの展開など参考となるデータが乏しい場合には経験豊富な担当者の直感が重要な役割を果たします。\nまた、クリエイティブなど感性的で定量化が難しい要素については経験に基づく判断が価値を発揮するでしょう。\n一方で反復性の高いサービスや施策の最適化などではデータに基づく意思決定の威力が遺憾なく発揮されます。\n投資対効果の測定が重要なサービスの改善や広告・プロモーション活動においてはデータ活用は価値が高いと言えるでしょう。\n重要なのはどちらか片方に偏るのではなく両方をバランスよく組み込むことです。\n経験に基づく判断であっても可能な限りデータで検証し学習サイクルに組み込むことです。\n「ベテランの経験から選んだ施策の効果を測定し、その結果を今後の判断基準に反映させる」といったアプローチにより組織全体の意思決定能力を継続的に向上させることができるのです。\nデータに基づく意思決定と経験に基づく意思決定は対立するものではなく相互補完的な関係にあります。\n変化の激しい現代のビジネス環境において成功の確率を上げるためには両者の特性を理解し場面に応じて適切に使い分けることが重要です。\n","permalink":"https://kenjiusui.github.io/blog/posts/biz/008_%E3%83%87%E3%83%BC%E3%82%BF%E3%81%AB%E5%9F%BA%E3%81%A5%E3%81%8F%E6%84%8F%E6%80%9D%E6%B1%BA%E5%AE%9A%E3%81%A8%E7%B5%8C%E9%A8%93%E3%81%AB%E5%9F%BA%E3%81%A5%E3%81%8F%E6%84%8F%E6%80%9D%E6%B1%BA%E5%AE%9A/","summary":"\u003ch1 id=\"はじめに\"\u003eはじめに\u003c/h1\u003e\n\u003cp\u003eこの記事ではビジネスにおいてデータを分析した意思決定をおこなう目的やメリットを紹介します。\u003cbr\u003e\nさまざまな場所で議論されているテーマですが自分なりの考えをまとめたく記事として残します。\u003cbr\u003e\n似たようなテーマで複数の観点から解説していく予定です。\u003c/p\u003e\n\u003ch1 id=\"意思決定における2つのアプローチ\"\u003e意思決定における2つのアプローチ\u003c/h1\u003e\n\u003cp\u003eビジネスの現場では複数の選択肢からどれか1つを選ばなければいけないというシーンがよくあります。\u003cbr\u003e\nたとえば、マーケティングにおいて「商品のプロモーション用に広告AとBの2つの候補からどちらを選ばなければいけない」なんてシーンは想像に容易いでしょう。\u003cbr\u003e\n他にも「どの見込み顧客から営業をするべきか？」とか「このプロダクトのボタンは赤と青どちらの色にしたらいいだろうか？」なんてことを考えている人はきっとこの記事を読んでいる方にもいるのではないでしょうか。\u003c/p\u003e\n\u003cp\u003eこれは日常的な風景ですが、しかしこれらの意思決定によって売上が変わる可能性を秘めています。\u003cbr\u003e\n下手な広告を選んだら獲得できるリードは減るかもしれませんし、営業の優先順位を間違えば大事な顧客を逃しているかもしれません。\u003cbr\u003e\nボタンの色が不評であれば機能を使う人が減ってしまう可能性もあります。\u003cbr\u003e\n1つ1つの意思決定の質が企業の売上や成長へ直結する重要な要素です。\u003c/p\u003e\n\u003cp\u003eでは、わたしたちはどのように意思決定をしていけばよいのでしょうか？この問題に対するアプローチを大きく2つにわけて考えていきます。\u003cbr\u003e\n1つは経験や知識に基づく意思決定、もう1つは客観的なデータに基づく意思決定です。\u003cbr\u003e\nどちらも現代のビジネスにおいて重要な役割を果たしていますが有効なシーンに違いがあります。\u003cbr\u003e\nこの2つのアプローチを比較することでそれぞれの特徴を理解し上手い使い方を把握していきましょう。\u003c/p\u003e\n\u003ch1 id=\"経験に基づく意思決定の特徴と限界\"\u003e経験に基づく意思決定の特徴と限界\u003c/h1\u003e\n\u003cp\u003e長年マーケティング業界で活躍してきたベテラン担当者であれば事例や過去の体験から「このターゲット層にはこういったメッセージが響きやすい」とか「今の時期にはこのタイプの広告が効果的だった」のような経験則を蓄積しているものです。\u003cbr\u003e\n市場や顧客の心理など数値化が困難な要素を感覚的に捉える能力はベテランの貴重な資産といえるでしょう。\u003cbr\u003e\n特に参考となる情報が乏しいまったく新しい市場や商品カテゴリーのような問題ではこのような経験や知識に基づく判断が強力な手法となります。\u003c/p\u003e\n\u003cp\u003eしかし、このような経験に基づく意思決定には欠点がいくつか存在します。\u003cbr\u003e\nその1つは判断の基準が個人の主観的な観察や経験に依存しているということです。\u003cbr\u003e\n例えば、新しい広告を展開した際にたまたま接触した顧客から「この広告は印象的で良かった」という好意的な反応を得たとします。\u003cbr\u003e\nこのような直接的なフィードバックは重要ですが担当者に実態以上に強い印象を与えがちで全体の傾向を正確に反映しているとも限りません。\u003c/p\u003e\n\u003cp\u003e接触した顧客層が特殊だった可能性、季節や時期による一時的な要因、さらには観察者自身の期待や先入観が判断を歪めている可能性などさまざまなバイアスが混入するリスクがあります。\u003cbr\u003e\nたまたまその顧客が気に入っただけで多くの人は別の要因で商品を買っただけかもしれませんし、もしかしたら顧客がお世辞をいっただけという可能性もあります。\u003cbr\u003e\n心理学でいう「確証バイアス」により自分の判断を支持する情報ばかりに注目し反対の証拠を無視してしまうこともよく見かけます。\u003c/p\u003e\n\u003cp\u003e経験に基づく意思決定がその人に固有の知識や感覚に強く依存するため、品質のコントロールが難しく再現性や客観性に欠けるという点です。\u003cbr\u003e\n同じ状況でも担当者が変われば全く異なる判断が下される可能性があり、組織として一貫した品質の意思決定を維持することは簡単ではありません。\u003c/p\u003e\n\u003ch1 id=\"データに基づく意思決定の特徴と優位性\"\u003eデータに基づく意思決定の特徴と優位性\u003c/h1\u003e\n\u003cp\u003eこれに対して十分なデータが蓄積され適切に分析できる環境が整っている場合、意思決定のアプローチは根本的に変化します。\u003cbr\u003e\nデータに基づく意思決定では実際に顧客がクリックしたり売上につながった広告やコンバージョンに結びついた施策を客観的な数値として把握することで感情や先入観に左右されない合理的な判断が可能になります。\u003cbr\u003e\n具体的な例を見ながら広告AとBのどちらがよいのか考えてみましょう。\u003c/p\u003e\n\u003cp\u003e広告A\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e表示回数10万回\u003c/li\u003e\n\u003cli\u003eクリック数2,000回（クリック率2.0%）\u003c/li\u003e\n\u003cli\u003eコンバージョン数80件（コンバージョン率4.0%）\u003c/li\u003e\n\u003cli\u003e獲得単価5,000円\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e広告B\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e表示回数10万回\u003c/li\u003e\n\u003cli\u003eクリック数1,500回（クリック率1.5%）\u003c/li\u003e\n\u003cli\u003eコンバージョン数90件（コンバージョン率6.0%）\u003c/li\u003e\n\u003cli\u003e獲得単価4,500円\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eこのようなデータがあれば、どちらの広告がより効果的かを明確に判断できます。\u003cbr\u003e\nこの例では、広告Bの方がコンバージョン率が高く、獲得単価も安いことがわかりました。\u003cbr\u003e\nそれぞれの指標について学んだ人であれば、投資対効果の観点から広告Bが優れていることが数値から読み取ることができるでしょう。\u003c/p\u003e\n\u003cp\u003eA/Bテストのような事前に準備された実験でデータを収集した場合、データの価値はさらに高まります。\u003cbr\u003e\nA/Bテストであれば同じ期間、同じ予算、同じターゲット層に対してランダムに異なる広告を展開し統計的に比較することでどちらがより効果的か高い信頼性をもって客観的に判断できます。\u003cbr\u003e\nこのような手法では、季節要因、競合他社の動向、市場環境の変化といった外部要因の影響を最小限に抑えることができ、純粋に広告自体の効果を測定することが可能になります。\u003c/p\u003e\n\u003cp\u003eデータに基づく判断のメリットは個人の経験や直感に依存度が低く誰が見ても同じ結論に到達できることです。\u003cbr\u003e\nマーケティング部門の新人からベテランまで同じデータを見れば基本的に同じ判断を下すことができます。\u003cbr\u003e\nこれは経験に基づく意思決定とは対照的な特徴であり組織全体の意思決定の品質向上に大きく貢献します。\u003c/p\u003e\n\u003ch1 id=\"データ活用による継続的な学習と改善\"\u003eデータ活用による継続的な学習と改善\u003c/h1\u003e\n\u003cp\u003eデータに基づく意思決定のもう一つの重要な利点は、継続的な学習と改善のサイクルを構築できることです。\u003cbr\u003e\n広告Aと広告Bの効果を測定した結果、広告Bが優れていることが判明したとします。\u003cbr\u003e\nしかし、データ活用の価値はここで終わりません。\u003c/p\u003e\n\u003cp\u003e広告がどのようなセグメントに効果的だったのか調査することで次回の広告制作時により効果的な施策を企画するために活かすことができます。\u003cbr\u003e\nたとえば「広告Bは都市部のユーザーには効果があったが地方ではいまいちだった」とか「実は広告Aは獲得が難しいセグメントで比較すると優位だった」といったことがわかればターゲットに対して効果的な広告を展開できるようになります。\u003cbr\u003e\nこれらの知見は組織の資産として蓄積され強力な武器となるでしょう。\u003c/p\u003e\n\u003cp\u003eまた、時系列でのデータ分析により、季節性や市場トレンドの変化も把握できます。\u003cbr\u003e\n「夏季は広告Aが効果的だが、冬季は広告Bの方が良い」といったパターンが見えてくれば、時期に応じた最適な施策を事前に計画することも可能になります。\u003cbr\u003e\n「広告Bはよかったが市場の変化によって費用対効果が悪くなっている」ということがわかれば新しい広告を検討すべきだとわかります。\u003c/p\u003e\n\u003cp\u003eこのような継続的な学習プロセスにより組織のマーケティング能力は段階的に向上していきます。\u003cbr\u003e\nデータの蓄積期間が長くなればなるほどデータを通した知見も蓄積され意思決定の品質も高まります。\u003cbr\u003e\nこれは個人の能力に依存した意思決定だけではなかなか難しいことです。\u003c/p\u003e\n\u003ch1 id=\"組織全体での意思決定品質の標準化\"\u003e組織全体での意思決定品質の標準化\u003c/h1\u003e\n\u003cp\u003eデータに基づく意思決定は組織全体での意思決定品質の標準化にも大きく貢献します。\u003cbr\u003e\n経験に基づく判断では意思決定者の能力や経験値によって判断の質に大きな差が生まれます。\u003cbr\u003e\n20年の経験を持つベテランマーケターと入社1年目の新人を比べたら判断の精度に差が出るのは自然なことです。\u003c/p\u003e\n\u003cp\u003eしかし、データに基づく意思決定の仕組みが整備されていればこの格差を大幅に縮小することができます。\u003cbr\u003e\n新人でも適切なデータの読み取り方と分析手法を身につけることでベテランと同等の判断を下すことが可能になります。\u003cbr\u003e\nこれは個人のスキルに依存しない組織として安定した品質の意思決定システムを構築できるということです。\u003c/p\u003e","title":"データに基づく意思決定と経験に基づく意思決定"},{"content":"SQLではよくあるケースだけど案外書くのが難しい書き方。\nこれが一番簡単だと思いますが、もっといい方法があったら教えてください。\nやりたいこと なんらかのカテゴリーごとに順番で並べて一番数値が高い行の他のカラムのデータを取得するクエリです。\nたとえば、下記のitemsというテーブルがあったときcategoryごとにpriceが最も高いnameを取得するという問題です。\nitemsテーブル\ncategory name price belt a 2000 belt b 10000 belt c 4000 wallet d 3000 wallet e 60000 wallet f 15000 wallet g 20000 求める結果\ncategory name price belt b 10000 wallet e 60000 クエリの例 この問題はwindow関数でrow_number関数を使うことで記述する方法がオススメです。\nselect 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() で順番に番号を割り当てています。\nこれによってpriceが最も高いとprice_orderカラムに1が入り降順で番号が割り当てられます。\nこれをサブクエリとして price_order = 1 に絞り込むことで最大の値が手に入るという仕組みです。\n注意点として同じpriceの行が複数存在する場合はどれか1行しか得られません。\nちなみに、最小の値がほしいならorder by で並び変えるところを降順でなく昇順にすればOKです。\nさらに最後に絞り込むところで任意の数値を使うことで好きな順番の行を取得できます。\nので二番目に大きい行がほしいとかも同じ書き方で取得できます。\nBigQueryの便利ワザ BigQueryだとQUALIFY句という便利なものがありサブクエリにしなくても一発で最大の値を取ることができます。\nselect category, name, price, row_number() over (partition by category order by price desc) as price_order from items qualify price_order = 1 qualify句はgroup byにおけるhaving句のwindow関数版です。\nwindow関数が実行されたあとに評価されて絞り込まれます。\nサブクエリを使わずとも1発でほしい結果が得られます。\nたぶんBigQueryにしかないはず。\n余談： 相関サブクエリ 今回はwindow関数を使いましたが同じ結果はサブクエリを使うことでも得られます。\nselect category, name, price_max, from items as items_1 inner join ( select category, max(price) as price_max from items group by category ) as items_2 on items_1.category = items_2.category and items_1.price = items_2.price この書き方はwindow関数よりも読みにくく処理も遅くなるので非推奨です。\nメリットとして同じpriceを持つ行が複数あっても取得することができます。\n","permalink":"https://kenjiusui.github.io/blog/posts/biz/007_sql%E3%81%A7%E3%82%AB%E3%83%86%E3%82%B4%E3%83%AA%E3%81%94%E3%81%A8%E3%81%AB%E6%9C%80%E5%A4%A7%E6%9C%80%E5%B0%8F%E3%81%AE%E5%80%A4%E3%82%92%E6%8C%81%E3%81%A4%E8%A1%8C%E3%82%92%E5%8F%96%E5%BE%97%E3%81%99%E3%82%8B/","summary":"\u003cp\u003eSQLではよくあるケースだけど案外書くのが難しい書き方。\u003cbr\u003e\nこれが一番簡単だと思いますが、もっといい方法があったら教えてください。\u003c/p\u003e\n\u003ch1 id=\"やりたいこと\"\u003eやりたいこと\u003c/h1\u003e\n\u003cp\u003eなんらかのカテゴリーごとに順番で並べて一番数値が高い行の他のカラムのデータを取得するクエリです。\u003cbr\u003e\nたとえば、下記のitemsというテーブルがあったときcategoryごとにpriceが最も高いnameを取得するという問題です。\u003c/p\u003e\n\u003cp\u003eitemsテーブル\u003c/p\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003ecategory\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003ename\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eprice\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003ebelt\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003ea\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e2000\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003ebelt\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eb\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e10000\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003ebelt\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003ec\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e4000\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003ewallet\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003ed\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e3000\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003ewallet\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003ee\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e60000\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003ewallet\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003ef\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e15000\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003ewallet\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eg\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e20000\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e求める結果\u003c/p\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003ecategory\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003ename\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eprice\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003ebelt\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eb\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e10000\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003ewallet\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003ee\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e60000\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003ch1 id=\"クエリの例\"\u003eクエリの例\u003c/h1\u003e\n\u003cp\u003eこの問題はwindow関数でrow_number関数を使うことで記述する方法がオススメです。\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eselect\n    category,\n    name,\n    price\nfrom (\n    select\n        category,\n        name,\n        price,\n        row_number() over (partition by category order by price desc) as price_order\n    from\n        items\n)\nwhere\n    price_order = 1\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eなにをやっているのか簡単に言うと \u003ccode\u003epartition by category\u003c/code\u003e でcategoryごとにわけて \u003ccode\u003eorder by price desc\u003c/code\u003e でprice降順で並びかえたところに \u003ccode\u003erow_number()\u003c/code\u003e で順番に番号を割り当てています。\u003cbr\u003e\nこれによってpriceが最も高いとprice_orderカラムに1が入り降順で番号が割り当てられます。\u003cbr\u003e\nこれをサブクエリとして \u003ccode\u003eprice_order = 1\u003c/code\u003e に絞り込むことで最大の値が手に入るという仕組みです。\u003cbr\u003e\n注意点として同じpriceの行が複数存在する場合はどれか1行しか得られません。\u003c/p\u003e","title":"SQLでカテゴリごとに最大・最小の値を持つ行を取得する"},{"content":"プライベートで使っているPCをApple Silicon M2チップを搭載したMac mini 2023に変えたのでPythonの環境をゼロから構築しました。\nmacOSのバージョンはVentura 13.2.1です\n特に大したことはしていないですが備忘録として。\n環境構築 Homebrew まずはHomebrewから入れます。とにかくこれを入れないと何も進まないので。\n公式のページにインストールするときのコマンドが書かれているのでこれをそのまま実行します。\nインストール自体はこれだけで完了ですが、たぶんインストールの一番最後に「PATHを通せ」みたいなメッセージが表示されているのでそれも実行してください。\n/bin/bash -c \u0026#34;$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)\u0026#34; pyenv Pythonのバージョン管理は定番のpyenvです。\nこれはbrewと使えば簡単にインストールできます。\nbrew install pyenv これだけだとPythonの向き先がシステムのPythonになったままになってしまうのでPATHをとおします。\nコマンドは公式のreadmeに書いてあるのでそれをそのまま実行しましょう。\nhttps://github.com/pyenv/pyenv#set-up-your-shell-environment-for-pyenv\necho \u0026#39;export PYENV_ROOT=\u0026#34;$HOME/.pyenv\u0026#34;\u0026#39; \u0026gt;\u0026gt; ~/.zshrc echo \u0026#39;command -v pyenv \u0026gt;/dev/null || export PATH=\u0026#34;$PYENV_ROOT/bin:$PATH\u0026#34;\u0026#39; \u0026gt;\u0026gt; ~/.zshrc echo \u0026#39;eval \u0026#34;$(pyenv init -)\u0026#34;\u0026#39; \u0026gt;\u0026gt; ~/.zshrc 最新のPython ほしいバージョンのPythonをpyenvをとおしてインストールします。\n今回は何も考えずに一番新しいやつを入れます。\n一点だけ注意ですが、pyenvを経由してPythonをインストールするときxzをインストールしないと ModuleNotFoundError: No module named '_lzma' って怒られるので先んじて対応しておきます。\n（先に pyenv install しちゃった場合はxzを入れただけだと上手く動作しないの一度pyenvのPythonをアンインストールして pyenv uninstall 3.x.x そのあと再度インストール pyenv install 3.x.x してください）\nbrew install xz あとは最新のpythonのバージョンを確認して\npyenv install --list 最新のpythonをインストール\npyenv install 3.x.x pythonのバージョンをインストールしたものにする\npyenv global 3.x.x poetry パッケージ管理はpoetryが好きなのでpoetry入れておく。\npipとかbrewでも入れられるけどとりあえず公式推奨の入れ方でやる。\nたぶん、これもPATHを通せと言われるのでやってください。\nhttps://python-poetry.org/docs/#installing-with-the-official-installer\ncurl -sSL https://install.python-poetry.org | python3 - 以上で最低限のPython環境が構築完了です。\nお疲れ様でした 🙌\nおわり この記事は本当に最低限のものしか入れてないのであとはlinterいれたり好きにしてください。\nそれにしてもM1がでた頃は環境構築が非常に大変で難儀したものですがいつの間にかスマートにできるようになっていました。\n本当に開発者の方々に感謝です。\nRef. Homebrew\nhttps://brew.sh/\npyenv\nhttps://github.com/pyenv/pyenv\npoetry\nhttps://github.com/python-poetry/poetry\nlzmaが入っていないと怒られる問題\nhttps://github.com/pandas-dev/pandas/issues/27532\n","permalink":"https://kenjiusui.github.io/blog/posts/biz/006_%E3%82%BC%E3%83%AD%E3%81%8B%E3%82%89m2-mac%E3%81%ABpython%E7%92%B0%E5%A2%83%E6%A7%8B%E7%AF%89/","summary":"\u003cp\u003eプライベートで使っているPCをApple Silicon M2チップを搭載したMac mini 2023に変えたのでPythonの環境をゼロから構築しました。\u003cbr\u003e\nmacOSのバージョンはVentura 13.2.1です\u003cbr\u003e\n特に大したことはしていないですが備忘録として。\u003c/p\u003e\n\u003ch1 id=\"環境構築\"\u003e環境構築\u003c/h1\u003e\n\u003ch2 id=\"homebrew\"\u003eHomebrew\u003c/h2\u003e\n\u003cp\u003eまずはHomebrewから入れます。とにかくこれを入れないと何も進まないので。\u003cbr\u003e\n公式のページにインストールするときのコマンドが書かれているのでこれをそのまま実行します。\u003cbr\u003e\nインストール自体はこれだけで完了ですが、たぶんインストールの一番最後に「PATHを通せ」みたいなメッセージが表示されているのでそれも実行してください。\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e/bin/bash -c \u0026#34;$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)\u0026#34;\n\u003c/code\u003e\u003c/pre\u003e\u003ch2 id=\"pyenv\"\u003epyenv\u003c/h2\u003e\n\u003cp\u003ePythonのバージョン管理は定番のpyenvです。\u003cbr\u003e\nこれはbrewと使えば簡単にインストールできます。\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003ebrew install pyenv\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eこれだけだとPythonの向き先がシステムのPythonになったままになってしまうのでPATHをとおします。\u003cbr\u003e\nコマンドは公式のreadmeに書いてあるのでそれをそのまま実行しましょう。\u003cbr\u003e\n\u003ca href=\"https://github.com/pyenv/pyenv#set-up-your-shell-environment-for-pyenv\"\u003ehttps://github.com/pyenv/pyenv#set-up-your-shell-environment-for-pyenv\u003c/a\u003e\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eecho \u0026#39;export PYENV_ROOT=\u0026#34;$HOME/.pyenv\u0026#34;\u0026#39; \u0026gt;\u0026gt; ~/.zshrc\necho \u0026#39;command -v pyenv \u0026gt;/dev/null || export PATH=\u0026#34;$PYENV_ROOT/bin:$PATH\u0026#34;\u0026#39; \u0026gt;\u0026gt; ~/.zshrc\necho \u0026#39;eval \u0026#34;$(pyenv init -)\u0026#34;\u0026#39; \u0026gt;\u0026gt; ~/.zshrc\n\u003c/code\u003e\u003c/pre\u003e\u003ch2 id=\"最新のpython\"\u003e最新のPython\u003c/h2\u003e\n\u003cp\u003eほしいバージョンのPythonをpyenvをとおしてインストールします。\u003cbr\u003e\n今回は何も考えずに一番新しいやつを入れます。\u003c/p\u003e\n\u003cp\u003e一点だけ注意ですが、pyenvを経由してPythonをインストールするときxzをインストールしないと \u003ccode\u003eModuleNotFoundError: No module named '_lzma'\u003c/code\u003e って怒られるので先んじて対応しておきます。\u003cbr\u003e\n（先に \u003ccode\u003epyenv install\u003c/code\u003e しちゃった場合はxzを入れただけだと上手く動作しないの一度pyenvのPythonをアンインストールして \u003ccode\u003epyenv uninstall 3.x.x\u003c/code\u003e そのあと再度インストール \u003ccode\u003epyenv install 3.x.x\u003c/code\u003e してください）\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003ebrew install xz\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eあとは最新のpythonのバージョンを確認して\u003c/p\u003e","title":"ゼロからM2 MacにPython環境構築"},{"content":"タイトルどおりメッセージの往復回数をカウントするクエリの書き方です。\n正確には異なるユーザがメッセージを送った回数をカウントする方法なのでチャットルームが1vs1なら往復回数だし3人以上いたら発信者が切り替わった回数と見ることができます。\n最近はチャットサポートが当たり前になってきましたしチャットを提供するサービスも一般化してきたので使う機会は割とあるのではないでしょうか。\n環境はBigQueryを想定しています。\nデータのイメージ こういう感じのデータをイメージしています。\nmassagesというテーブルに下記のようなデータが入っているとします。\nid room_id user_id created_at 1 300 600 2023-01-01 00:00:00 2 300 700 2023-01-01 01:01:01 3 300 600 2023-01-01 08:01:02 4 400 800 2023-02-01 00:10:03 5 400 900 2023-03-01 01:00:04 6 400 900 2023-04-01 0500:05 idはmassageのユニークキーです。\nroom_idはチャットルームごとのユニークキーです。\nroom_idごとに何往復のチャットがやりとりされたのか数え上げることが目的です。\nuser_idはチャットルームに参加しているユーザのidでmassageを誰が送ったのかわかります。\nここではチャットルームに2人のユーザがいることを想定しています。\n例文 with massages_with_lag as ( select id, room_id, user_id, lag(user_id, 1) over (partition by room_id order by created_at) as lag_user_id from massages ) select room_id, ceil(count(case when user_id \u0026lt;\u0026gt; lag_user_id then id end) / 2) as count_round_trips from massages_with_lag group by room_id このクエリは2つにわかれています。\n前半は各メッセージごとに1つ前のメッセージのuser_idを横並びにさせ、後半でuser_idを比較して違ったらカウントが1つ増え、それを半分で割って小数点以下を繰り上げることで往復回数としています。\nさて、前半のmassages_with_lagの内容を解説します。\nこのクエリではlag_user_idにwindow関数を使って対象とするメッセージの1つ前のメッセージのuser_idを横並びにしています。\nlagは指定した数だけ前の行のデータを取ってくる関数で、order by creatd_at でcreated_atの昇順にデータを並び替えlag関数で1つ前のデータをもってくるということです。\npartition by room_id をつけることでこれがroom_idごとに計算されるということです。\nちなみに一番最初のメッセージは前のメッセージがないのでlag_user_idはnullになります。\n後半は前半の結果を利用して実際にcountで数え上げます。\ncount(case when user_id \u0026lt;\u0026gt; lag_user_id then id end) はcase式を使ってuser_idとlag_user_idを比較して不一致であればidを返しそれをcountします。\nつまり今の行と前の行でuser_idが違うならば1増えるので、これが2増えるごとに往復回数が1増えることになります。\nなので2で割って往復回数にしています。\nしかし、割った結果が小数点だと往復回数が0.5回というのは使いにくいですね。\n往復回数が知りたいだけなので一方的にメッセージを送ったままのときは往復回数にカウントしないようにしたいです。\nceilという関数で小数点以下を切り上げる関数を使うことでうまく結果を整数にし直感的な往復回数としています。\n以上で往復回数を集計することができます。\nもし、間違いやもっと良い方法があれば教えてください。\n参考 window関数\nhttps://cloud.google.com/bigquery/docs/reference/standard-sql/window-function-calls?hl=ja\nlag関数\nhttps://cloud.google.com/bigquery/docs/reference/standard-sql/navigation_functions?hl=ja#lag\n","permalink":"https://kenjiusui.github.io/blog/posts/biz/005_%E3%83%A1%E3%83%83%E3%82%BB%E3%83%BC%E3%82%B8%E3%81%AE%E5%BE%80%E5%BE%A9%E5%9B%9E%E6%95%B0%E3%82%92%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88%E3%81%99%E3%82%8Bsql%E3%82%AF%E3%82%A8%E3%83%AA%E3%81%AE%E6%9B%B8%E3%81%8D%E6%96%B9/","summary":"\u003cp\u003eタイトルどおりメッセージの往復回数をカウントするクエリの書き方です。\u003cbr\u003e\n正確には異なるユーザがメッセージを送った回数をカウントする方法なのでチャットルームが1vs1なら往復回数だし3人以上いたら発信者が切り替わった回数と見ることができます。\u003cbr\u003e\n最近はチャットサポートが当たり前になってきましたしチャットを提供するサービスも一般化してきたので使う機会は割とあるのではないでしょうか。\u003cbr\u003e\n環境はBigQueryを想定しています。\u003c/p\u003e\n\u003ch1 id=\"データのイメージ\"\u003eデータのイメージ\u003c/h1\u003e\n\u003cp\u003eこういう感じのデータをイメージしています。\u003cbr\u003e\nmassagesというテーブルに下記のようなデータが入っているとします。\u003c/p\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003eid\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eroom_id\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003euser_id\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003ecreated_at\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e1\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e300\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e600\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e2023-01-01 00:00:00\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e2\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e300\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e700\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e2023-01-01 01:01:01\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e3\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e300\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e600\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e2023-01-01 08:01:02\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e4\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e400\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e800\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e2023-02-01 00:10:03\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e5\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e400\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e900\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e2023-03-01 01:00:04\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e6\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e400\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e900\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e2023-04-01 0500:05\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003eidはmassageのユニークキーです。\u003cbr\u003e\nroom_idはチャットルームごとのユニークキーです。\u003cbr\u003e\nroom_idごとに何往復のチャットがやりとりされたのか数え上げることが目的です。\u003cbr\u003e\nuser_idはチャットルームに参加しているユーザのidでmassageを誰が送ったのかわかります。\u003cbr\u003e\nここではチャットルームに2人のユーザがいることを想定しています。\u003c/p\u003e\n\u003ch1 id=\"例文\"\u003e例文\u003c/h1\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003ewith massages_with_lag as (\n    select\n        id,\n        room_id,\n        user_id,\n        lag(user_id, 1) over (partition by room_id order by created_at) as lag_user_id\n    from\n        massages\n)\n\nselect\n    room_id,\n    ceil(count(case when user_id \u0026lt;\u0026gt; lag_user_id then id end) / 2) as count_round_trips\nfrom\n    massages_with_lag\ngroup by\n    room_id\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eこのクエリは2つにわかれています。\u003cbr\u003e\n前半は各メッセージごとに1つ前のメッセージのuser_idを横並びにさせ、後半でuser_idを比較して違ったらカウントが1つ増え、それを半分で割って小数点以下を繰り上げることで往復回数としています。\u003c/p\u003e","title":"メッセージの往復回数をカウントするSQLクエリの書き方"},{"content":"valueに配列を含むJSONから配列を抽出し行へ変換するクエリの書き方\n前提 下記のようなJSONが \u0026ldquo;テーブル名：table_1\u0026rdquo; の \u0026ldquo;列名：item_logs\u0026rdquo; に格納されいてるとき\n{ \u0026#34;user_id\u0026#34;: 1111, \u0026#34;item_names\u0026#34;: [ \u0026#34;foo\u0026#34;, \u0026#34;bar\u0026#34;, \u0026#34;hoge\u0026#34; ] } このようなテーブルに変換するためのクエリ\nuser_id item 1111 foo 1111 bar 1111 hoge 環境はBigQuery\n書き方 json_query_arrayでほしい配列が格納されているペアのkey \u0026ldquo;$.item_names\u0026rdquo; を指定し目的の配列をとってくる unnestで配列を行に変換する（配列の順序が保証されないらしいので必要ならoffsetを使う） 上記で行に変換したものと元のテーブルをcross joinして目的のテーブルが完成 select user_id, json_value(items) as item, from table_1 as t_1 cross join unnest(json_query_array(t_1.item_logs, \u0026#34;$.item_names\u0026#34;)) as items これを使ってJSONから item = \u0026quot;foo\u0026quot; のときだけフラグを建てる処理も簡単に書ける。\nJSON値は比較とかできないのでjson_valueで変換する。\nselect id, json_value(items) = \u0026#34;foo\u0026#34; as is_foo, from table_1 as t_1 cross join unnest(json_query_array(t_1.item_logs, \u0026#34;$.item_names\u0026#34;)) as items 変更があったり間違っていたらコメントください。\nRef. JSONの取り扱い\nhttps://cloud.google.com/bigquery/docs/reference/standard-sql/json-data#query_json_data\njson_query_array\nhttps://cloud.google.com/bigquery/docs/reference/standard-sql/json_functions#json_query_array\njson_value\nhttps://cloud.google.com/bigquery/docs/reference/standard-sql/json_functions#json_value\n","permalink":"https://kenjiusui.github.io/blog/posts/biz/004_bigquery%E3%81%A7json%E3%81%AE%E9%85%8D%E5%88%97%E3%81%8B%E3%82%89%E8%A1%8C%E3%81%AB%E5%A4%89%E6%8F%9B%E3%81%99%E3%82%8B/","summary":"\u003cp\u003evalueに配列を含むJSONから配列を抽出し行へ変換するクエリの書き方\u003c/p\u003e\n\u003ch1 id=\"前提\"\u003e前提\u003c/h1\u003e\n\u003cp\u003e下記のようなJSONが \u0026ldquo;テーブル名：table_1\u0026rdquo; の \u0026ldquo;列名：item_logs\u0026rdquo; に格納されいてるとき\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e{\n    \u0026#34;user_id\u0026#34;: 1111,\n    \u0026#34;item_names\u0026#34;: [\n        \u0026#34;foo\u0026#34;,\n        \u0026#34;bar\u0026#34;,\n        \u0026#34;hoge\u0026#34;\n    ]\n}\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eこのようなテーブルに変換するためのクエリ\u003c/p\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003euser_id\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eitem\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e1111\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003efoo\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e1111\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003ebar\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e1111\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003ehoge\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e環境はBigQuery\u003c/p\u003e\n\u003ch1 id=\"書き方\"\u003e書き方\u003c/h1\u003e\n\u003col\u003e\n\u003cli\u003ejson_query_arrayでほしい配列が格納されているペアのkey \u0026ldquo;$.item_names\u0026rdquo; を指定し目的の配列をとってくる\u003c/li\u003e\n\u003cli\u003eunnestで配列を行に変換する（配列の順序が保証されないらしいので必要ならoffsetを使う）\u003c/li\u003e\n\u003cli\u003e上記で行に変換したものと元のテーブルをcross joinして目的のテーブルが完成\u003c/li\u003e\n\u003c/ol\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eselect\n    user_id,\n    json_value(items) as item,\nfrom\n    table_1 as t_1\ncross join\n    unnest(json_query_array(t_1.item_logs, \u0026#34;$.item_names\u0026#34;)) as items\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eこれを使ってJSONから \u003ccode\u003eitem = \u0026quot;foo\u0026quot;\u003c/code\u003e のときだけフラグを建てる処理も簡単に書ける。\u003cbr\u003e\nJSON値は比較とかできないのでjson_valueで変換する。\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eselect\n    id,\n    json_value(items) = \u0026#34;foo\u0026#34; as is_foo,\nfrom\n    table_1 as t_1\ncross join\n    unnest(json_query_array(t_1.item_logs, \u0026#34;$.item_names\u0026#34;)) as items\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e変更があったり間違っていたらコメントください。\u003c/p\u003e","title":"BigQueryでJSONの配列から行に変換する"},{"content":"Cloud ComposerからCloud Functionsにある関数を認証有りのHTTPトリガーで軌道する方法です。\n公式のドキュメントに書いてありますが備忘録として書きます。\nたぶん、これが一番簡単だと思いますが他に良い方法があったら教えてください。\n環境 Airflow: 2.1.4\nやりかた やることはわかってしまえば簡単です。\n関数の実行権限をCloud Composerに付与する IDトークンを発行する HTTPリクエストのheaderにトークンを含めて送る これだけです。\n詳しいやり方 関数の実行権限をCloud Composerに付与する GCPのコンソールからポチポチやるのが簡単だと思います。\n具体的な手順はドキュメントを参照してください。\nhttps://cloud.google.com/functions/docs/securing/authenticating#authenticating_function_to_function_calls\nポイントは受信する側の関数ごとにroles/cloudfunctions.invokerを設定するということです。\nやっていないのでわかりませんがComposerのサービスアカウントにroles/cloudfunctions.invokerを付与するのではなく関数側から設定する必要がありそうです。\n一括で付与とかはできないのかな？できそうな気もするのでわかる人いたら教えてください。\nIDトークンを発行する ここからはComposerのDAGのコードになります。\nDAGでHTTPリクエストを送るまえに認証に使用するIDトークンを発行します。\nimport google.auth.transport.requests import google.oauth2.id_token auth_req = google.auth.transport.requests.Request() # endpoint はCloud Functionsにある関数のエンドポイントのURL id_token = google.oauth2.id_token.fetch_id_token(auth_req, endpoint) これで得られたid_tokenが目的のものになります。\nendpoint はCloud Functionsにある関数のエンドポイントのURLです。\nこのトークンの発行に使っているGoogleのライブラリはComposerであればインストールされているはずなので簡単に利用できます。\nHTTPリクエストを送る 最後はComposerからHTTPリクエストを送って関数を実行するだけです。\n単純に関数を実行するだけであればエンドポイントをPOSTするだけで良いのですが認証情報をheaderに入れて送ります。\nfrom airflow.providers.http.operators.http import SimpleHttpOperator end_point = \u0026#34;cloud functionsの関数のエンドポイント\u0026#34; invoke_task = SimpleHttpOperator( task_id = \u0026#34;invoke_function\u0026#34;, endpoint=end_point, headers={\u0026#34;Content-Type\u0026#34;: \u0026#34;application/json\u0026#34;, \u0026#34;Authorization\u0026#34;: f\u0026#34;Bearer {id_token}\u0026#34;}, dag=dag ) はい、これだけでOKです。\nあとはよしなにDAGのなかにこのタスクを組み込んでください。\nこういう単純なHTTPリクエストを送るのはAirflowの1系だと面倒だったのですが2系ではSimpleHttpOperatorという便利なものがあるのでこれを使えばOKです。\nCloud Functionsを使うのが初めてだったのでこんな単純なことをやるのに結構苦労してしまったので、もし同じようなことをする人の役に立てば嬉しいです。\nもし間違っていたり、より良い方法がありましたらコメントで教えてください。\n","permalink":"https://kenjiusui.github.io/blog/posts/biz/003_cloud-function%E3%82%92cloud-composer%E3%81%8B%E3%82%89%E8%AA%8D%E8%A8%BC%E6%9C%89%E3%82%8A%E3%81%A7http%E8%B5%B7%E5%8B%95%E3%81%99%E3%82%8B/","summary":"\u003cp\u003eCloud ComposerからCloud Functionsにある関数を認証有りのHTTPトリガーで軌道する方法です。\u003cbr\u003e\n公式のドキュメントに書いてありますが備忘録として書きます。\u003cbr\u003e\nたぶん、これが一番簡単だと思いますが他に良い方法があったら教えてください。\u003c/p\u003e\n\u003ch1 id=\"環境\"\u003e環境\u003c/h1\u003e\n\u003cp\u003eAirflow: 2.1.4\u003c/p\u003e\n\u003ch1 id=\"やりかた\"\u003eやりかた\u003c/h1\u003e\n\u003cp\u003eやることはわかってしまえば簡単です。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e関数の実行権限をCloud Composerに付与する\u003c/li\u003e\n\u003cli\u003eIDトークンを発行する\u003c/li\u003e\n\u003cli\u003eHTTPリクエストのheaderにトークンを含めて送る\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eこれだけです。\u003c/p\u003e\n\u003ch1 id=\"詳しいやり方\"\u003e詳しいやり方\u003c/h1\u003e\n\u003ch2 id=\"関数の実行権限をcloud-composerに付与する\"\u003e関数の実行権限をCloud Composerに付与する\u003c/h2\u003e\n\u003cp\u003eGCPのコンソールからポチポチやるのが簡単だと思います。\u003cbr\u003e\n具体的な手順はドキュメントを参照してください。\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://cloud.google.com/functions/docs/securing/authenticating#authenticating_function_to_function_calls\"\u003ehttps://cloud.google.com/functions/docs/securing/authenticating#authenticating_function_to_function_calls\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eポイントは受信する側の関数ごとにroles/cloudfunctions.invokerを設定するということです。\u003cbr\u003e\nやっていないのでわかりませんがComposerのサービスアカウントにroles/cloudfunctions.invokerを付与するのではなく関数側から設定する必要がありそうです。\u003cbr\u003e\n一括で付与とかはできないのかな？できそうな気もするのでわかる人いたら教えてください。\u003c/p\u003e\n\u003ch2 id=\"idトークンを発行する\"\u003eIDトークンを発行する\u003c/h2\u003e\n\u003cp\u003eここからはComposerのDAGのコードになります。\u003cbr\u003e\nDAGでHTTPリクエストを送るまえに認証に使用するIDトークンを発行します。\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eimport google.auth.transport.requests\nimport google.oauth2.id_token\n\nauth_req = google.auth.transport.requests.Request()\n# endpoint はCloud Functionsにある関数のエンドポイントのURL\nid_token = google.oauth2.id_token.fetch_id_token(auth_req, endpoint)\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eこれで得られたid_tokenが目的のものになります。\u003cbr\u003e\n\u003ccode\u003eendpoint\u003c/code\u003e はCloud Functionsにある関数のエンドポイントのURLです。\u003cbr\u003e\nこのトークンの発行に使っているGoogleのライブラリはComposerであればインストールされているはずなので簡単に利用できます。\u003c/p\u003e\n\u003ch2 id=\"httpリクエストを送る\"\u003eHTTPリクエストを送る\u003c/h2\u003e\n\u003cp\u003e最後はComposerからHTTPリクエストを送って関数を実行するだけです。\u003cbr\u003e\n単純に関数を実行するだけであればエンドポイントをPOSTするだけで良いのですが認証情報をheaderに入れて送ります。\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003efrom airflow.providers.http.operators.http import SimpleHttpOperator\n\nend_point = \u0026#34;cloud functionsの関数のエンドポイント\u0026#34;\ninvoke_task = SimpleHttpOperator(\n        task_id = \u0026#34;invoke_function\u0026#34;,\n        endpoint=end_point,\n        headers={\u0026#34;Content-Type\u0026#34;: \u0026#34;application/json\u0026#34;, \u0026#34;Authorization\u0026#34;: f\u0026#34;Bearer {id_token}\u0026#34;},\n        dag=dag\n    )\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eはい、これだけでOKです。\u003cbr\u003e\nあとはよしなにDAGのなかにこのタスクを組み込んでください。\u003cbr\u003e\nこういう単純なHTTPリクエストを送るのはAirflowの1系だと面倒だったのですが2系ではSimpleHttpOperatorという便利なものがあるのでこれを使えばOKです。\u003c/p\u003e","title":"Cloud FunctionをCloud Composerから認証有りでHTTP起動する"},{"content":"pandasを使っていたら下記のwarningがでていたのを解決したので備忘録。\nUserWarning: Could not import the lzma module. Your installed Python is incomplete. Attempting to use lzma compression will result in a RuntimeError. 環境 OS: macOS Catalina 10.15.7 Python: 3.8.1 pandas: 1.3.1 pyenv: 2.0.1 解決方法 どうやらpyenvを通してPythonをインストールしていると発生するようです。\nhttps://github.com/pandas-dev/pandas/issues/27532\n対処法は xz をインストールしてから改めてPythonをインストールします。\nxzはbrewにあるので簡単です。\nbrew install xz これでxzが入るのでPythonをインストールしなおせばOK。\npyenv uninstall 3.8.1 pyenv install 3.8.1 これでwarningが消えました 🙌\n","permalink":"https://kenjiusui.github.io/blog/posts/biz/002_lzma%E3%81%8C%E5%85%A5%E3%81%A3%E3%81%A6%E3%81%84%E3%81%AA%E3%81%84%E3%81%A3%E3%81%A6%E6%80%92%E3%82%89%E3%82%8C%E3%82%8Bwarning%E3%82%92%E8%A7%A3%E6%B6%88%E3%81%99%E3%82%8B/","summary":"\u003cp\u003epandasを使っていたら下記のwarningがでていたのを解決したので備忘録。\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eUserWarning: Could not import the lzma module. Your installed Python is incomplete. Attempting to use lzma compression will result in a RuntimeError.\n\u003c/code\u003e\u003c/pre\u003e\u003ch1 id=\"環境\"\u003e環境\u003c/h1\u003e\n\u003cul\u003e\n\u003cli\u003eOS: macOS Catalina 10.15.7\u003c/li\u003e\n\u003cli\u003ePython: 3.8.1\u003c/li\u003e\n\u003cli\u003epandas: 1.3.1\u003c/li\u003e\n\u003cli\u003epyenv: 2.0.1\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch1 id=\"解決方法\"\u003e解決方法\u003c/h1\u003e\n\u003cp\u003eどうやらpyenvを通してPythonをインストールしていると発生するようです。\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://github.com/pandas-dev/pandas/issues/27532\"\u003ehttps://github.com/pandas-dev/pandas/issues/27532\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e対処法は \u003ccode\u003exz\u003c/code\u003e をインストールしてから改めてPythonをインストールします。\u003cbr\u003e\nxzはbrewにあるので簡単です。\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003ebrew install xz\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eこれでxzが入るのでPythonをインストールしなおせばOK。\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003epyenv uninstall 3.8.1\npyenv install 3.8.1\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eこれでwarningが消えました 🙌\u003c/p\u003e","title":"lzmaが入っていないって怒られるwarningを解消する"},{"content":"この記事はビジネスにおいてデータ分析のレポートを作成する際に気をつけたほうがよいことを自分なりにまとめたものです。間違いやすい点なんかを集めたTIPSみたいな記事になっています。\nレポートの書き方そのものについては良い書籍や記事がたくさんありますのでそちらを参照することをオススメします。\n前提 データ分析のレポートでは基本構成としてIMRAD形式に則るのが良いです。IMRADとはIntroduction, Methods, Results And Discussionの頭文字を取ったもので、特に論文でよく使われる構成です。シンプルですが科学的検証に向いた形式でありデータ分析もデータを元に客観的に検証するという観点からIMRAD形式に合わせると適切に記述・検証することが可能になるので強く推奨です。逆に言えば、ビジネスのプレゼンテーションにありがちなインパクトを優先する恣意的な印象を与える方法は基本的にはNGです。\n一方で、ビジネスの現場では重要な点をすぐに把握できる形が好まれます。そのため記述する形式はIMRADに限る必要はありません。私がよくやる方法は抄録を冒頭に置いてそれだけで要点をすぐに把握できるようにし、詳しく読みたい人向けに後ろにIMRAD形式で記述する方法です。要約には基本として議論を理解できる最低限の前提と手法そして重要な結果と考察を技術します。要約を書くことはとてもむずかしいです。ぜひ訓練を積みましょう。\nIntroduction この章では分析の目的・背景を記述します。あなたが何を目的にこの分析を行い、何を得たいのか明確にわかるように書きましょう。目的や背景を書くときに重要なことは、データ分析では分析の結果からどんな結果を得たいのか記述することです。これがなければ分析の意味がないので当然ながら重要な事柄になります。データ分析の目的は抽象化すると下記の3パターンにわけられます。\n仮説をデータから検証する\n変化を検知するために定常的なデータを取得する\n数字感覚を知るために探索的分析をする\n手元の分析が上記のどれに当てはまるのか分類し、それを踏まえて記述するとよいでしょう。たとえば、あなたが1番の仮説検証を行いたいのであれば、どんな仮説があり・どんな検証が必要で・その結果としてどんな判断をとることができるのか書くことになります。\n背景を記述する際に気をつける点として、その分析が妥当であることを明記することが挙げられます。分析を行うまでには様々な背景や先行調査などがあるかと思います。それらを記載することで分析が妥当であることを説明します。1つの課題に対して手段は複数ありますが、なぜあなたはその手法を行ったのでしょうか？この問に対して十分な回答をここに記載する必要があります。もし、背景を省略した場合はあなたの分析が必要であることが伝わらず価値を理解してもらえないかもしれません。そのような状態を避けるために背景を記載することが重要です。そして、その背景は事前に関係者と共有し理解を得ていることが望ましいです。\nMethod この章では分析の対象や手法をすべて記載します。あなたがどこからデータを取得してきてどのように分析したのかわかり、再現できるようにしましょう。\n基本として書くべきことは母集団の説明、データの取得方法（クエリやアンケート方法）、分析方法（特に統計的手法）です。ありがちなのが母集団に関する説明の不足です。データをどのような母集団から得たのか明記しましょう。データは取得した母集団によってバイアスを受けるため、バイアスに留意した記述が必要になります。\n手法を記述する基本は5W1Hを用いた方法です。ビジネスの現場では特定の属性を対象にデータを集めることが多いと思うので、そのような事前に決めていた属性は網羅的に記述します。データの取得方法はアクティビティなどをデータベースから取得した場合は意図的に絞り込んだ条件の記載とクエリ、可能であれば生データを共有しておくと一番よいです。アンケートなど能動的にデータを取りに行った場合はいつ、どこで、どのようにして実施したのかなど可能な限り詳細にアンケート方法を記載しておくとよいでしょう。アンケートは様々な理由からバイアスが発生しうるので、なるべく詳細に実施内容を書いておくと良いです。どちらの手法にせよ、他の人が同じようにデータを取得できるレベルに記載しておくことが望ましいです。\n分析方法は集計以上に統計的手法を用いた場合は明記しておくとよいです。統計的手法はいくらでも嘘の結論を導くことができるのでどんな手法を選んだのか明確に記述するべきです。とはいえ、そもそもレポートの書き方がままならないレベルの人は統計的手法を使わないほうが望ましいです。理解していない技術を使うことは思わぬ失敗を招きます。必要ならば専門家と共同して行うべきでしょう。\nResults and Discussion この章では分析から得られた結果とその考察を記載します。あなたが分析から得られたデータや統計的解析結果とそれに対する考察を書きます。\n結果と考察の項を書くときに最も重要なことは客観的事実と自分の考えを明確にわけて書くことです。データ分析はデータという客観的な情報を元に意思決定することを目的としています。にもかかわらず、あなたの主観と客観的情報を混ぜて書いてしまってはその価値は失われてしまうでしょう。\n特にグラフの書き方はルールや作法がありますので留意すべき点でしょう。グラフを記載する際のルールはそれを守ることによってグラフを見た人が誤解をせず適切にグラフから情報を読み取れるようにするためのものです。軸の単位やラベルを書いたり説明を記述することは最低限であり、これが不足しているグラフを描くことは避けましょう。もし図や表の書き方を詳細に知りたい方は科学コミュニティにおける書き方を参考にすると良いでしょう。\n統計学的手法を用いている場合はその結論を導いて良いのか適切に検討しましょう。例えば、相関関係と因果関係を見誤ることはとても多い問題です。他にも検定の結果の受け方は一癖あるので手法を理解し記述するよう気をつけるべきでしょう。これを間違うと一気にレポートの信頼性が落ちてしまいます。\nまた、バイアスの存在は重要です。データは常に何かしらのバイアスの影響を受けています。結論に影響がなくても影響が無いことを明記すべきです。バイアスについて留意した考察を行うことを行ったということが重要になります。\n留意点 ここまでIMRAD形式をベースにレポーティングの留意点を記述しました。ここまで読んだ人の中にはこんなにたくさんの文字を書くことは非常に労力がかかり、まるで冗長な作業のように感じる方もいるでしょう。私も以前はそう思っていました。\nもちろん、このような内容を網羅的に記述することは労力がかかります。実際に、ベテランは意図的にこれらのいくつかを書かないことがあります。しかし、それはケースごとの\u0026quot;重点\u0026quot;を理解した手抜きです。レポートを見る人の関係性や分析の重要度、実験の難易度などを加味した上で省略をします。\nしかし、少なくとも初心者のうちはこのような省略をおこなわず、すべてを明確に書くべきだと考えます。なぜなら、このように網羅的な記述を行うことは物事を整理し言語化する力を強くしてくれるからです。大変ですが、それでも時間と労力をかけて明確に記述することを推奨します。\n初めてこのようにレポートを書いたとき、とても大変で投げたくなるでしょう。大丈夫です、私もそうでした。もしよければ3ヶ月だけ我慢してみてください。きっとあなたのスキルが進化していることを体感できるでしょう。\nあとがき この記事ではデータ分析を行ったときのレポーティングについて簡単に重要な点を述べさせていただきました。\nこの記事をとおして、あなたのレポートが良いものになれば嬉しい限りです。\n","permalink":"https://kenjiusui.github.io/blog/posts/biz/001_%E3%83%87%E3%83%BC%E3%82%BF%E5%88%86%E6%9E%90%E3%83%AC%E3%83%9D%E3%83%BC%E3%83%88%E3%81%A7%E6%B0%97%E3%82%92%E3%81%A4%E3%81%91%E3%81%9F%E3%81%84%E5%9F%BA%E6%9C%AC%E7%9A%84%E3%81%AA%E3%81%93%E3%81%A8/","summary":"\u003cp\u003eこの記事はビジネスにおいてデータ分析のレポートを作成する際に気をつけたほうがよいことを自分なりにまとめたものです。間違いやすい点なんかを集めたTIPSみたいな記事になっています。\u003cbr\u003e\nレポートの書き方そのものについては良い書籍や記事がたくさんありますのでそちらを参照することをオススメします。\u003c/p\u003e\n\u003ch1 id=\"前提\"\u003e前提\u003c/h1\u003e\n\u003cp\u003eデータ分析のレポートでは基本構成として\u003cstrong\u003eIMRAD形式\u003c/strong\u003eに則るのが良いです。IMRADとは\u003cstrong\u003eI\u003c/strong\u003entroduction, \u003cstrong\u003eM\u003c/strong\u003eethods, \u003cstrong\u003eR\u003c/strong\u003eesults \u003cstrong\u003eA\u003c/strong\u003end \u003cstrong\u003eD\u003c/strong\u003eiscussionの頭文字を取ったもので、特に論文でよく使われる構成です。シンプルですが科学的検証に向いた形式でありデータ分析もデータを元に\u003cstrong\u003e客観的に検証する\u003c/strong\u003eという観点からIMRAD形式に合わせると適切に記述・検証することが可能になるので強く推奨です。逆に言えば、ビジネスのプレゼンテーションにありがちなインパクトを優先する\u003cstrong\u003e恣意的な印象を与える方法は基本的にはNG\u003c/strong\u003eです。\u003c/p\u003e\n\u003cp\u003e一方で、ビジネスの現場では重要な点をすぐに把握できる形が好まれます。そのため記述する形式はIMRADに限る必要はありません。私がよくやる方法は抄録を冒頭に置いてそれだけで要点をすぐに把握できるようにし、詳しく読みたい人向けに後ろにIMRAD形式で記述する方法です。要約には基本として議論を理解できる最低限の前提と手法そして重要な結果と考察を技術します。要約を書くことはとてもむずかしいです。ぜひ訓練を積みましょう。\u003c/p\u003e\n\u003ch1 id=\"introduction\"\u003eIntroduction\u003c/h1\u003e\n\u003cp\u003eこの章では分析の目的・背景を記述します。\u003cstrong\u003eあなたが何を目的にこの分析を行い、何を得たいのか明確にわかるように書きましょう\u003c/strong\u003e。目的や背景を書くときに重要なことは、データ分析では\u003cstrong\u003e分析の結果からどんな結果を得たいのか記述する\u003c/strong\u003eことです。これがなければ分析の意味がないので当然ながら重要な事柄になります。データ分析の目的は抽象化すると下記の3パターンにわけられます。\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003e仮説をデータから検証する\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e変化を検知するために定常的なデータを取得する\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e数字感覚を知るために探索的分析をする\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e手元の分析が上記のどれに当てはまるのか分類し、それを踏まえて記述するとよいでしょう。たとえば、あなたが1番の仮説検証を行いたいのであれば、どんな仮説があり・どんな検証が必要で・その結果としてどんな判断をとることができるのか書くことになります。\u003c/p\u003e\n\u003cp\u003e背景を記述する際に気をつける点として、\u003cstrong\u003eその分析が妥当であることを明記する\u003c/strong\u003eことが挙げられます。分析を行うまでには様々な背景や先行調査などがあるかと思います。それらを記載することで分析が妥当であることを説明します。1つの課題に対して手段は複数ありますが、なぜあなたはその手法を行ったのでしょうか？この問に対して十分な回答をここに記載する必要があります。もし、背景を省略した場合はあなたの分析が必要であることが伝わらず価値を理解してもらえないかもしれません。そのような状態を避けるために背景を記載することが重要です。そして、その背景は事前に関係者と共有し理解を得ていることが望ましいです。\u003c/p\u003e\n\u003ch1 id=\"method\"\u003eMethod\u003c/h1\u003e\n\u003cp\u003eこの章では分析の対象や手法をすべて記載します。\u003cstrong\u003eあなたがどこからデータを取得してきてどのように分析したのかわかり、再現できるよう\u003c/strong\u003eにしましょう。\u003c/p\u003e\n\u003cp\u003e基本として書くべきことは母集団の説明、データの取得方法（クエリやアンケート方法）、分析方法（特に統計的手法）です。\u003cstrong\u003eありがちなのが母集団に関する説明の不足\u003c/strong\u003eです。データをどのような母集団から得たのか明記しましょう。データは取得した母集団によってバイアスを受けるため、バイアスに留意した記述が必要になります。\u003c/p\u003e\n\u003cp\u003e手法を記述する基本は5W1Hを用いた方法です。ビジネスの現場では特定の属性を対象にデータを集めることが多いと思うので、そのような事前に決めていた属性は網羅的に記述します。データの取得方法はアクティビティなどをデータベースから取得した場合は意図的に絞り込んだ条件の記載とクエリ、可能であれば生データを共有しておくと一番よいです。アンケートなど能動的にデータを取りに行った場合はいつ、どこで、どのようにして実施したのかなど可能な限り詳細にアンケート方法を記載しておくとよいでしょう。アンケートは様々な理由からバイアスが発生しうるので、なるべく詳細に実施内容を書いておくと良いです。どちらの手法にせよ、\u003cstrong\u003e他の人が同じようにデータを取得できるレベルに記載しておく\u003c/strong\u003eことが望ましいです。\u003c/p\u003e\n\u003cp\u003e分析方法は集計以上に統計的手法を用いた場合は明記しておくとよいです。統計的手法はいくらでも嘘の結論を導くことができるのでどんな手法を選んだのか明確に記述するべきです。とはいえ、そもそもレポートの書き方がままならないレベルの人は統計的手法を使わないほうが望ましいです。\u003cstrong\u003e理解していない技術を使うことは思わぬ失敗を招きます\u003c/strong\u003e。必要ならば専門家と共同して行うべきでしょう。\u003c/p\u003e\n\u003ch1 id=\"results-and-discussion\"\u003eResults and Discussion\u003c/h1\u003e\n\u003cp\u003eこの章では分析から得られた結果とその考察を記載します。\u003cstrong\u003eあなたが分析から得られたデータや統計的解析結果とそれに対する考察\u003c/strong\u003eを書きます。\u003c/p\u003e\n\u003cp\u003e結果と考察の項を書くときに最も重要なことは\u003cstrong\u003e客観的事実と自分の考えを明確にわけて書く\u003c/strong\u003eことです。データ分析はデータという客観的な情報を元に意思決定することを目的としています。にもかかわらず、あなたの主観と客観的情報を混ぜて書いてしまってはその価値は失われてしまうでしょう。\u003c/p\u003e\n\u003cp\u003e特にグラフの書き方はルールや作法がありますので留意すべき点でしょう。グラフを記載する際のルールはそれを守ることによってグラフを見た人が誤解をせず適切にグラフから情報を読み取れるようにするためのものです。軸の単位やラベルを書いたり説明を記述することは最低限であり、これが不足しているグラフを描くことは避けましょう。もし図や表の書き方を詳細に知りたい方は科学コミュニティにおける書き方を参考にすると良いでしょう。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e統計学的手法を用いている場合はその結論を導いて良いのか適切に検討しましょう\u003c/strong\u003e。例えば、相関関係と因果関係を見誤ることはとても多い問題です。他にも検定の結果の受け方は一癖あるので手法を理解し記述するよう気をつけるべきでしょう。これを間違うと一気にレポートの信頼性が落ちてしまいます。\u003c/p\u003e\n\u003cp\u003eまた、\u003cstrong\u003eバイアスの存在は重要です\u003c/strong\u003e。データは常に何かしらのバイアスの影響を受けています。結論に影響がなくても影響が無いことを明記すべきです。バイアスについて留意した考察を行うことを行ったということが重要になります。\u003c/p\u003e\n\u003ch1 id=\"留意点\"\u003e留意点\u003c/h1\u003e\n\u003cp\u003eここまでIMRAD形式をベースにレポーティングの留意点を記述しました。ここまで読んだ人の中にはこんなにたくさんの文字を書くことは非常に労力がかかり、まるで冗長な作業のように感じる方もいるでしょう。私も以前はそう思っていました。\u003c/p\u003e\n\u003cp\u003eもちろん、このような内容を網羅的に記述することは労力がかかります。実際に、ベテランは意図的にこれらのいくつかを書かないことがあります。しかし、それはケースごとの\u0026quot;重点\u0026quot;を理解した手抜きです。レポートを見る人の関係性や分析の重要度、実験の難易度などを加味した上で省略をします。\u003c/p\u003e\n\u003cp\u003eしかし、少なくとも初心者のうちはこのような省略をおこなわず、すべてを明確に書くべきだと考えます。なぜなら、このように網羅的な記述を行うことは物事を整理し言語化する力を強くしてくれるからです。大変ですが、それでも時間と労力をかけて明確に記述することを推奨します。\u003c/p\u003e\n\u003cp\u003e初めてこのようにレポートを書いたとき、とても大変で投げたくなるでしょう。大丈夫です、私もそうでした。もしよければ3ヶ月だけ我慢してみてください。きっとあなたのスキルが進化していることを体感できるでしょう。\u003c/p\u003e\n\u003ch1 id=\"あとがき\"\u003eあとがき\u003c/h1\u003e\n\u003cp\u003eこの記事ではデータ分析を行ったときのレポーティングについて簡単に重要な点を述べさせていただきました。\u003c/p\u003e\n\u003cp\u003eこの記事をとおして、あなたのレポートが良いものになれば嬉しい限りです。\u003c/p\u003e","title":"データ分析レポートで気をつけたい基本的なこと"},{"content":"昨今では少なくない企業のテックブログにおいてLLMで生成したままのような低品質な記事をよく見かけるようになりました。\n独特の単語と文章構造、読みにくい日本語、文章量だけはやたら多いがうすっぺらい冗長な記事。\n低品質化がひどすぎて少なくないテックブログを見ることをやめることが増えました。\nテックブログのメタクソ化です。\n私はこのような振る舞いはテックブログの本来の目的と逆の効果を生むので避けるべきだとおもっています。\n多くの企業はテックブログを気軽なアウトプットの場所にとらえていますが、あくまでも企業の名前を看板として背負っていることを忘れてはいけません。\n気軽さは大事ですが企業の活動としておこなう以上は最低限のクオリティが必要だと考えています。\n企業の名前で低品質な記事を書くということは「手を抜いた低品質なものをアウトプットとして恥ずかしげもなくだせる企業」に見えているということです。\nあなたの会社は「アウトプットにこだわりがない」「テクニカルライティングもまともにできない」「技術にこだわりがない」「社内のコミュニケーションはもっと酷いのだろう」なんて思われています。\nそれってテックブログとして正しい姿ですか？\nたとえば、イベントに登壇した人が生成したスライドで練習した様子もなくたどたどしく発表したらどう見えるでしょうか？\n社内で資料の確認や練習をしなかったのかとおもわれるでしょう。\nポジティブな印象をもたれるとは言い難いです。\nLLMを使うことでたくさんの記事を書けるからPVは上がっている、と言う人もいます。\nしかし忘れてほしくないのがテックブログの本来の目的はPVを集めることではないということです。\nテックブログの本来の目的は優秀な人材を採用することにあります。\n果たして、貴社の求める人材はLLMで書かれた低品質な記事を有難がって読むような人でしょうか？\n勘違いされたくないので明記しておきますがLLMで書いたからダメというわけではありません。\nLLMとアイディアを考えたり、LLMで草案を作って人間が手直しをするというのはむしろ上手いやり方でしょう。\nまた、記事は高品質なものでないといけないという話でもありません。\n慣れてない人が記事を書くということもとても大事なことです。\nテクニカルライティングの練習にもちょうどよい機会ですから。\n周りの人がサポートして最低限のクオリティまでもっていけばよいだけです。\nいずれにせよ大事なのは他人に見られているのだということを決して忘れてはいけないというところにあります。\nあなたの会社はAIで効率化する会社ですか？それともAIで手抜きする会社ですか？\n","permalink":"https://kenjiusui.github.io/blog/posts/essay/016_%E3%83%86%E3%83%83%E3%82%AF%E3%83%96%E3%83%AD%E3%82%B0%E3%81%AE%E3%83%A1%E3%82%BF%E3%82%AF%E3%82%BD%E5%8C%96/","summary":"\u003cp\u003e昨今では少なくない企業のテックブログにおいてLLMで生成したままのような低品質な記事をよく見かけるようになりました。\u003cbr\u003e\n独特の単語と文章構造、読みにくい日本語、文章量だけはやたら多いがうすっぺらい冗長な記事。\u003cbr\u003e\n低品質化がひどすぎて少なくないテックブログを見ることをやめることが増えました。\u003cbr\u003e\nテックブログのメタクソ化です。\u003c/p\u003e\n\u003cp\u003e私はこのような振る舞いはテックブログの本来の目的と逆の効果を生むので避けるべきだとおもっています。\u003cbr\u003e\n多くの企業はテックブログを気軽なアウトプットの場所にとらえていますが、あくまでも企業の名前を看板として背負っていることを忘れてはいけません。\u003cbr\u003e\n気軽さは大事ですが企業の活動としておこなう以上は最低限のクオリティが必要だと考えています。\u003c/p\u003e\n\u003cp\u003e企業の名前で低品質な記事を書くということは「手を抜いた低品質なものをアウトプットとして恥ずかしげもなくだせる企業」に見えているということです。\u003cbr\u003e\nあなたの会社は「アウトプットにこだわりがない」「テクニカルライティングもまともにできない」「技術にこだわりがない」「社内のコミュニケーションはもっと酷いのだろう」なんて思われています。\u003cbr\u003e\nそれってテックブログとして正しい姿ですか？\u003c/p\u003e\n\u003cp\u003eたとえば、イベントに登壇した人が生成したスライドで練習した様子もなくたどたどしく発表したらどう見えるでしょうか？\u003cbr\u003e\n社内で資料の確認や練習をしなかったのかとおもわれるでしょう。\u003cbr\u003e\nポジティブな印象をもたれるとは言い難いです。\u003c/p\u003e\n\u003cp\u003eLLMを使うことでたくさんの記事を書けるからPVは上がっている、と言う人もいます。\u003cbr\u003e\nしかし忘れてほしくないのがテックブログの本来の目的はPVを集めることではないということです。\u003cbr\u003e\nテックブログの本来の目的は優秀な人材を採用することにあります。\u003cbr\u003e\n果たして、貴社の求める人材はLLMで書かれた低品質な記事を有難がって読むような人でしょうか？\u003c/p\u003e\n\u003cp\u003e勘違いされたくないので明記しておきますがLLMで書いたからダメというわけではありません。\u003cbr\u003e\nLLMとアイディアを考えたり、LLMで草案を作って人間が手直しをするというのはむしろ上手いやり方でしょう。\u003c/p\u003e\n\u003cp\u003eまた、記事は高品質なものでないといけないという話でもありません。\u003cbr\u003e\n慣れてない人が記事を書くということもとても大事なことです。\u003cbr\u003e\nテクニカルライティングの練習にもちょうどよい機会ですから。\u003cbr\u003e\n周りの人がサポートして最低限のクオリティまでもっていけばよいだけです。\u003c/p\u003e\n\u003cp\u003eいずれにせよ大事なのは他人に見られているのだということを決して忘れてはいけないというところにあります。\u003cbr\u003e\nあなたの会社はAIで効率化する会社ですか？それともAIで手抜きする会社ですか？\u003c/p\u003e","title":"テックブログのメタクソ化"},{"content":"2.1 データ分析基盤の定義と目的 まずはデータ分析基盤が企業にもたらす本質的な価値について整理していきましょう。\nデータ分析基盤とは企業内の様々なシステムやサービスから生成されるデータを統合・管理・分析するためのITシステム全体を指します。単なるデータベースではなくデータの収集から保存・加工・分析・可視化まで一連のデータ活用プロセスを支える包括的なプラットフォームです。\nこの基盤の最大の目的は組織内に散在するデータと加工のプロセスを一元化し迅速かつ正確な意思決定を支援することです。従来であれば、各部署が個別にExcelでデータを管理し月末になると手作業で集計作業を行っていたような状況を脱却します。専門的なITスキルを持たないビジネス担当者でも必要な時に必要なデータにアクセスし自分で分析できる環境を用意することでデータドリブンな意思決定が促進されます。\n現代のビジネスにおいてデータに基づいた意思決定（データドリブン経営）は競争優位性の源泉となっています。データ分析基盤はこの変革を技術面から支える重要なインフラなのです。\n2.2 従来のシステムとの違い 従来のシステムが抱える根本的な課題を理解することで、なぜ専用の分析基盤が必要なのかが見えてきます。\nまず業務システムでデータを分析する場合の限界をみてみましょう。販売管理システムや在庫管理システムといった業務システムは少量のデータを高速に処理することに特化しています。一方で、大量のデータを処理するには向いていないため大量のデータを集計・分析することは現実的ではありません。また従来は週次や月次の売上集計程度でしたが現代では毎日生成される大量のWebアクセスログ・IoTセンサーデータ・ソーシャルメディアデータなど多様なデータを多角的に高い頻度で分析をおこなう必要があります。\n従来のレポートシステムでは管理者が事前に定義した固定のレポートしか作成できませんでした。新しい観点での分析や想定外の質問が生まれるたびにIT部門への依頼が発生し分析結果を得るまでに少なくない時間を要していました。つまり意思決定において分析結果を得るプロセスがボトルネックという状況です。\n加えて、このような複雑な環境では異なるデータソースを統合し一貫性のあるルールで管理するガバナンス体制が必要不可欠です。しかし、レポーティングのために部門間の連携を取ることは簡単ではありません。そのため、複数の部門が異なる定義で同じ指標を計算し、全社で一貫した数値を共有することがむずかしいという状態は珍しくありませんでした。\n2.3 なぜ専用の基盤が必要なのか データ分析基盤は前述した従来システムの課題を根本的に解決することを目的としています。\nまず大量データの高速処理という課題に対しては分析専用に最適化されたアーキテクチャを採用しています。列指向データベースやメモリ内処理などの技術により数十億件のデータでも数秒で集計・分析が可能です。また業務システムとは物理的に分離されているため本来の業務処理に影響を与えることもありません。\n統合分析の困難さに対しては異なるデータソースを統一的に管理する仕組みを提供します。売上データ・在庫データ・顧客データ・Webアクセスログなどを一元化することで部門を跨いだ横断的な分析が可能です。さらにデータの形式を標準化することで分析を効率化します。\nまた、全社統一のデータ定義や品質管理を一元的に管理できます。「売上」「顧客数」といった指標の定義を全社で統一し誰が見ても同じ数値になるようにします。同じデータ、共通の集計済みテーブルとダッシュボード、標準化された指標の定義によって同じ目線でデータを用いた議論が可能です。\nデータ分析基盤は単なるITシステムではありません。組織の意思決定プロセスを根本的に変革するインフラです。従来は「勘と経験」に頼っていた意思決定を「データに基づいた客観的な判断」に変えることで企業の競争力を大幅に向上させます。\nデータ分析基盤がもたらすこの変革の核心はデータの活用の拡大にあります。データ分析を一部のデータアナリストだけが扱える特別なモノではなく、現場の営業担当者から経営幹部まで誰でも必要な時に必要なデータを活用できる環境へ変えます。日常的なデータ活用により組織全体の判断精度とスピードが向上します。\nもう一つの本質的価値は「組織の学習能力向上」です。データ分析基盤により過去の成功・失敗事例が蓄積され次の戦略立案に活用できます。どの商品がなぜ売れたのか どのマーケティング施策が効果的だったのか どの時期にどんな問題が発生しやすいのか。これらの定量的な知見が組織の財産として蓄積され継続的な改善を支援します。\nこの章ではデータ分析基盤を開発する目的やメリットを紹介しました。次の章ではデータ分析基盤のもつ機能について概要を解説していきます。\n","permalink":"https://kenjiusui.github.io/blog/books/data-platform-intro/02_what_is_data_platform/","summary":"\u003ch2 id=\"21-データ分析基盤の定義と目的\"\u003e2.1 データ分析基盤の定義と目的\u003c/h2\u003e\n\u003cp\u003eまずはデータ分析基盤が企業にもたらす本質的な価値について整理していきましょう。\u003c/p\u003e\n\u003cp\u003eデータ分析基盤とは企業内の様々なシステムやサービスから生成されるデータを統合・管理・分析するためのITシステム全体を指します。単なるデータベースではなくデータの収集から保存・加工・分析・可視化まで一連のデータ活用プロセスを支える包括的なプラットフォームです。\u003c/p\u003e\n\u003cp\u003eこの基盤の最大の目的は組織内に散在するデータと加工のプロセスを一元化し迅速かつ正確な意思決定を支援することです。従来であれば、各部署が個別にExcelでデータを管理し月末になると手作業で集計作業を行っていたような状況を脱却します。専門的なITスキルを持たないビジネス担当者でも必要な時に必要なデータにアクセスし自分で分析できる環境を用意することでデータドリブンな意思決定が促進されます。\u003c/p\u003e\n\u003cp\u003e現代のビジネスにおいてデータに基づいた意思決定（データドリブン経営）は競争優位性の源泉となっています。データ分析基盤はこの変革を技術面から支える重要なインフラなのです。\u003c/p\u003e\n\u003ch2 id=\"22-従来のシステムとの違い\"\u003e2.2 従来のシステムとの違い\u003c/h2\u003e\n\u003cp\u003e従来のシステムが抱える根本的な課題を理解することで、なぜ専用の分析基盤が必要なのかが見えてきます。\u003c/p\u003e\n\u003cp\u003eまず業務システムでデータを分析する場合の限界をみてみましょう。販売管理システムや在庫管理システムといった業務システムは少量のデータを高速に処理することに特化しています。一方で、大量のデータを処理するには向いていないため大量のデータを集計・分析することは現実的ではありません。また従来は週次や月次の売上集計程度でしたが現代では毎日生成される大量のWebアクセスログ・IoTセンサーデータ・ソーシャルメディアデータなど多様なデータを多角的に高い頻度で分析をおこなう必要があります。\u003c/p\u003e\n\u003cp\u003e従来のレポートシステムでは管理者が事前に定義した固定のレポートしか作成できませんでした。新しい観点での分析や想定外の質問が生まれるたびにIT部門への依頼が発生し分析結果を得るまでに少なくない時間を要していました。つまり意思決定において分析結果を得るプロセスがボトルネックという状況です。\u003c/p\u003e\n\u003cp\u003e加えて、このような複雑な環境では異なるデータソースを統合し一貫性のあるルールで管理するガバナンス体制が必要不可欠です。しかし、レポーティングのために部門間の連携を取ることは簡単ではありません。そのため、複数の部門が異なる定義で同じ指標を計算し、全社で一貫した数値を共有することがむずかしいという状態は珍しくありませんでした。\u003c/p\u003e\n\u003ch2 id=\"23-なぜ専用の基盤が必要なのか\"\u003e2.3 なぜ専用の基盤が必要なのか\u003c/h2\u003e\n\u003cp\u003eデータ分析基盤は前述した従来システムの課題を根本的に解決することを目的としています。\u003c/p\u003e\n\u003cp\u003eまず大量データの高速処理という課題に対しては分析専用に最適化されたアーキテクチャを採用しています。列指向データベースやメモリ内処理などの技術により数十億件のデータでも数秒で集計・分析が可能です。また業務システムとは物理的に分離されているため本来の業務処理に影響を与えることもありません。\u003c/p\u003e\n\u003cp\u003e統合分析の困難さに対しては異なるデータソースを統一的に管理する仕組みを提供します。売上データ・在庫データ・顧客データ・Webアクセスログなどを一元化することで部門を跨いだ横断的な分析が可能です。さらにデータの形式を標準化することで分析を効率化します。\u003c/p\u003e\n\u003cp\u003eまた、全社統一のデータ定義や品質管理を一元的に管理できます。「売上」「顧客数」といった指標の定義を全社で統一し誰が見ても同じ数値になるようにします。同じデータ、共通の集計済みテーブルとダッシュボード、標準化された指標の定義によって同じ目線でデータを用いた議論が可能です。\u003c/p\u003e\n\u003cp\u003eデータ分析基盤は単なるITシステムではありません。組織の意思決定プロセスを根本的に変革するインフラです。従来は「勘と経験」に頼っていた意思決定を「データに基づいた客観的な判断」に変えることで企業の競争力を大幅に向上させます。\u003c/p\u003e\n\u003cp\u003eデータ分析基盤がもたらすこの変革の核心はデータの活用の拡大にあります。データ分析を一部のデータアナリストだけが扱える特別なモノではなく、現場の営業担当者から経営幹部まで誰でも必要な時に必要なデータを活用できる環境へ変えます。日常的なデータ活用により組織全体の判断精度とスピードが向上します。\u003c/p\u003e\n\u003cp\u003eもう一つの本質的価値は「組織の学習能力向上」です。データ分析基盤により過去の成功・失敗事例が蓄積され次の戦略立案に活用できます。どの商品がなぜ売れたのか どのマーケティング施策が効果的だったのか どの時期にどんな問題が発生しやすいのか。これらの定量的な知見が組織の財産として蓄積され継続的な改善を支援します。\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003eこの章ではデータ分析基盤を開発する目的やメリットを紹介しました。次の章ではデータ分析基盤のもつ機能について概要を解説していきます。\u003c/p\u003e","title":"データ分析基盤とは何か"},{"content":"会社で働いていると作業を頼んだりとか期限を確認したりするような場面ってありますよね。ときには指摘や注意することもあります。ですが、こういうのを苦手に感じる人はけっこう多いんじゃないでしょうか。催促のメッセージを書いては消して結局送らずに閉じた、なんて経験は誰にでもありますよね。\nその気持ちの正体は「図々しいヤツだと思われたくない」みたいなとこにあるんじゃないかなあとおもいます。相手も忙しいのに自分の都合で時間を使わせてしまう、そう考えると声をかけること自体がわがままのように思えてきてしまうのです。実際、こういう振る舞いを「図々しさ」と表現する人をよく見かけます。\nでも僕はこれを図々しさとは呼びたくないんですよね。むしろ依頼も催促も指摘も相手を対等な大人だと思っているからできることなんじゃないかと思っています。\n言わないでおく判断の裏には相手への一方的な思い込みが隠れています。頼んだら負担になるだろう、催促したら気を悪くするだろう、指摘したら傷つくだろう…みたいな。優しさのように見えますがこれは相手を守ってあげないといけない子供として扱う発想でもあります。\n対等な大人だと思っているならそうはならないはずなんです。相手は自分の仕事量を把握しているので無理なら断れるはずです。指摘を受け取ったうえで自分で判断もできます。つまりこちらが勝手に相手の許容量を決めて手加減する理由がないわけです。断る力があると信じているからこそ頼めるんです。\nそもそも組織は各々で役割を持つ人が集まった場所です。その役割がお互いに噛み合うことで全体が前に進みます。誰かの遅れは誰かの手待ちになりますし間違ったまま進んだものは後から全員に返ってきます。\nこの構造で考えると依頼や催促は相手の人格に向けたものではなく役割に向けたものだとわかります。「あなたが悪い」ではなく「あなたの役割ならこれをしてくれないと次に進まない」という感じですね。役割の話として扱えるなら言う側の後ろめたさもだいぶ軽くなるはずです。\n反対に、言わずに済ませればその場は穏やかに終わります。ただ問題そのものが消えたわけではありません。期限は静かに過ぎていきますし、ズレたまま進んだら問題はいつか大きくなって戻ってきます。困るのは黙っていた本人だけではなく多くの場合は相手も一緒です。早い段階なら一言で済んだものが遅れるほど収拾のつかない話になっていきます。\nこの問題はどんどん深みにハマる可能性も高いです。お互いになあなあでいると自然と受け身になります。そして察してほしいとか気づいてほしいという気持ちばかりが強くなり、相手の気配りに依存し始め、最後には誰が何を持っているのかも曖昧になっていきます。やるべきことを言葉にしないまま空気で回そうとするやり方は、大人同士の仕事としてはかなり心もとないと思うんですよね。\nもちろん何を言ってもいいという話ではありません。言い方や中身はちゃんと気をつける必要があります。\n相手の役割の外にある仕事を投げる、丸投げして判断材料を渡さない、期限だけ伝えて背景を説明しない、うまくいかなかったときに感情で詰める\u0026hellip;など。この辺はたしかに対等な扱いから外れています。逆に目的・期限・前提をそろえて渡す、まず事実の確認から入る、指摘は行動の範囲にとどめる、断る余地を残しておく。こういうやり方は図々しさではなく普通の仕事の進め方だと思います。\nそう考えるとお願いしたり指摘したりすること自体は失礼ではありません。むしろ言えるというのは相手を信用しているという合図でもあります。この人なら受け止めて自分で判断してくれると思っているから口に出せるわけですから。\n","permalink":"https://kenjiusui.github.io/blog/posts/essay/015_%E5%AF%BE%E7%AD%89%E3%81%AA%E5%A4%A7%E4%BA%BA%E3%81%A0%E3%81%A8%E6%80%9D%E3%81%86%E3%81%8B%E3%82%89%E5%82%AC%E4%BF%83%E3%82%82%E6%B3%A8%E6%84%8F%E3%82%82%E3%81%A7%E3%81%8D%E3%82%8B/","summary":"\u003cp\u003e会社で働いていると作業を頼んだりとか期限を確認したりするような場面ってありますよね。ときには指摘や注意することもあります。ですが、こういうのを苦手に感じる人はけっこう多いんじゃないでしょうか。催促のメッセージを書いては消して結局送らずに閉じた、なんて経験は誰にでもありますよね。\u003c/p\u003e\n\u003cp\u003eその気持ちの正体は「図々しいヤツだと思われたくない」みたいなとこにあるんじゃないかなあとおもいます。相手も忙しいのに自分の都合で時間を使わせてしまう、そう考えると声をかけること自体がわがままのように思えてきてしまうのです。実際、こういう振る舞いを「図々しさ」と表現する人をよく見かけます。\u003c/p\u003e\n\u003cp\u003eでも僕はこれを図々しさとは呼びたくないんですよね。むしろ依頼も催促も指摘も相手を対等な大人だと思っているからできることなんじゃないかと思っています。\u003c/p\u003e\n\u003cp\u003e言わないでおく判断の裏には相手への一方的な思い込みが隠れています。頼んだら負担になるだろう、催促したら気を悪くするだろう、指摘したら傷つくだろう…みたいな。優しさのように見えますがこれは相手を守ってあげないといけない子供として扱う発想でもあります。\u003c/p\u003e\n\u003cp\u003e対等な大人だと思っているならそうはならないはずなんです。相手は自分の仕事量を把握しているので無理なら断れるはずです。指摘を受け取ったうえで自分で判断もできます。つまりこちらが勝手に相手の許容量を決めて手加減する理由がないわけです。断る力があると信じているからこそ頼めるんです。\u003c/p\u003e\n\u003cp\u003eそもそも組織は各々で役割を持つ人が集まった場所です。その役割がお互いに噛み合うことで全体が前に進みます。誰かの遅れは誰かの手待ちになりますし間違ったまま進んだものは後から全員に返ってきます。\u003c/p\u003e\n\u003cp\u003eこの構造で考えると依頼や催促は相手の人格に向けたものではなく役割に向けたものだとわかります。「あなたが悪い」ではなく「あなたの役割ならこれをしてくれないと次に進まない」という感じですね。役割の話として扱えるなら言う側の後ろめたさもだいぶ軽くなるはずです。\u003c/p\u003e\n\u003cp\u003e反対に、言わずに済ませればその場は穏やかに終わります。ただ問題そのものが消えたわけではありません。期限は静かに過ぎていきますし、ズレたまま進んだら問題はいつか大きくなって戻ってきます。困るのは黙っていた本人だけではなく多くの場合は相手も一緒です。早い段階なら一言で済んだものが遅れるほど収拾のつかない話になっていきます。\u003c/p\u003e\n\u003cp\u003eこの問題はどんどん深みにハマる可能性も高いです。お互いになあなあでいると自然と受け身になります。そして察してほしいとか気づいてほしいという気持ちばかりが強くなり、相手の気配りに依存し始め、最後には誰が何を持っているのかも曖昧になっていきます。やるべきことを言葉にしないまま空気で回そうとするやり方は、大人同士の仕事としてはかなり心もとないと思うんですよね。\u003c/p\u003e\n\u003cp\u003eもちろん何を言ってもいいという話ではありません。言い方や中身はちゃんと気をつける必要があります。\u003c/p\u003e\n\u003cp\u003e相手の役割の外にある仕事を投げる、丸投げして判断材料を渡さない、期限だけ伝えて背景を説明しない、うまくいかなかったときに感情で詰める\u0026hellip;など。この辺はたしかに対等な扱いから外れています。逆に目的・期限・前提をそろえて渡す、まず事実の確認から入る、指摘は行動の範囲にとどめる、断る余地を残しておく。こういうやり方は図々しさではなく普通の仕事の進め方だと思います。\u003c/p\u003e\n\u003cp\u003eそう考えるとお願いしたり指摘したりすること自体は失礼ではありません。むしろ言えるというのは相手を信用しているという合図でもあります。この人なら受け止めて自分で判断してくれると思っているから口に出せるわけですから。\u003c/p\u003e","title":"対等な大人だと思うから催促も注意もできる"},{"content":"先日SNSでこんな投稿を見ました。「AIでアプリが作れたからもうエンジニアいらないな」みたいなやつ。非エンジニアの人がAIを使って自分でツールを組んでそれが動いたということ自体は素直にすごいことだと思います。でも、そのあとに続く「エンジニアいらない」のひと言だけはどうにも引っかかったんですよね。\n先に言っておくと非エンジニアがAIでいろんなものを手軽に作るのは最高にいいことだと思っています。今までお金や技術の壁で諦めていたものが自分の手で形になる。これはもう純粋に世界が良くなっている話です。なのでぼくは作ること自体を否定したいわけじゃまったくありません。\n引っかかるのは「動くものが作れた」を根拠に「エンジニアをいらない」と言い切ってしまうところです。あれ正直めちゃくちゃダサいと思うんですよね。\nなぜダサいかというと動くだけのアプリケーションと仕事で使う商用アプリケーションのあいだには見えていない論点とクオリティの差が横たわっているからです。動いた時点で見えているのは氷山の一角で、プロが金をもらって作っているのはその下に沈んでいる部分のほうです。\nたとえば自分1人が触るぶんには動くやつも、同時に1万人がアクセスしたら耐えられるのか、変な入力を投げられたときに落ちないか、個人情報を扱うならそれをどう守るのか、誰かがデータを盗もうとしてきたときに防げるのか、半年後に仕様変更が来たとき直せる作りになっているのか、障害が起きた夜中にちゃんと復旧できるのか\u0026hellip;etc。この辺は全部「動く」の外側にある話で、しかも商用だと1つも落とせません。\n要するに動かすのは入り口で、仕事で作るというのは落ちない・壊れない・守れる・直せるをぜんぶ同時に成立させることです。デモで動くものと、他人の金や生活を預かって動き続けるものは求められるクオリティの桁が違います。\nこう書くと「でもその見えてない部分もいずれAIが全部埋めるでしょ」と言われそうです。わかります。というか正直それはかなりあると思っています。負荷対策もセキュリティも保守も、いつかAIがまとめて面倒を見る未来は普通に来ると思います。だからここで「AIには無理」みたいな話をするつもりはありません。\n引っかかっているのはそこじゃなくて、そもそも見えてない部分が存在するという事実に気づけていないというところです。1万人がアクセスしたら落ちるかもしれない、変な入力で壊れるかもしれない、その論点がまず頭に浮かぶ人だけが「じゃあそこAIに埋めさせよう」と指示を出せます。**埋める手段がAIになっても「何を埋める必要があるか」を判断する部分は残ります。**むしろそこがプロの中身なんですよね。\n「動いたからエンジニアいらない」と言い切れてしまうのは、その埋めるべき穴が見えていないからこそなんです。見えていないから穴がないように思えてしまいます。逆にいえば技術がAIに肩代わりされるほど、穴の在りかを知っている人の価値はむしろ上がるんじゃないかと僕は思っています。\nAIで動くものを作れた人は堂々とそれを喜んでいいと思います。ほんとにすごいので。ただそれと「プロがいらない」はつなげないほうがいい。むしろ自分で少し作ってみたからこそ、その先の見えない部分の深さに気づける立場になったはずなんです。作れるようになった人ほどプロの凄みがわかるようになる。そっちのほうがずっとかっこいいと思いますね。\n","permalink":"https://kenjiusui.github.io/blog/posts/essay/013_ai%E3%81%A7%E4%BD%9C%E3%82%8C%E3%82%8B%E3%82%88%E3%81%86%E3%81%AB%E3%81%AA%E3%81%A3%E3%81%9F%E4%BA%BA%E3%81%BB%E3%81%A9%E3%83%97%E3%83%AD%E3%81%AE%E5%87%84%E3%81%BF%E3%81%8C%E3%82%8F%E3%81%8B%E3%82%8B%E3%81%A8%E6%80%9D%E3%81%86/","summary":"\u003cp\u003e先日SNSでこんな投稿を見ました。「AIでアプリが作れたからもうエンジニアいらないな」みたいなやつ。非エンジニアの人がAIを使って自分でツールを組んでそれが動いたということ自体は素直にすごいことだと思います。でも、そのあとに続く「エンジニアいらない」のひと言だけはどうにも引っかかったんですよね。\u003c/p\u003e\n\u003cp\u003e先に言っておくと非エンジニアがAIでいろんなものを手軽に作るのは最高にいいことだと思っています。今までお金や技術の壁で諦めていたものが自分の手で形になる。これはもう純粋に世界が良くなっている話です。なのでぼくは作ること自体を否定したいわけじゃまったくありません。\u003c/p\u003e\n\u003cp\u003e引っかかるのは「動くものが作れた」を根拠に「エンジニアをいらない」と言い切ってしまうところです。あれ正直めちゃくちゃダサいと思うんですよね。\u003c/p\u003e\n\u003cp\u003eなぜダサいかというと動くだけのアプリケーションと仕事で使う商用アプリケーションのあいだには見えていない論点とクオリティの差が横たわっているからです。動いた時点で見えているのは氷山の一角で、プロが金をもらって作っているのはその下に沈んでいる部分のほうです。\u003c/p\u003e\n\u003cp\u003eたとえば自分1人が触るぶんには動くやつも、同時に1万人がアクセスしたら耐えられるのか、変な入力を投げられたときに落ちないか、個人情報を扱うならそれをどう守るのか、誰かがデータを盗もうとしてきたときに防げるのか、半年後に仕様変更が来たとき直せる作りになっているのか、障害が起きた夜中にちゃんと復旧できるのか\u0026hellip;etc。この辺は全部「動く」の外側にある話で、しかも商用だと1つも落とせません。\u003c/p\u003e\n\u003cp\u003e要するに\u003cstrong\u003e動かすのは入り口で、仕事で作るというのは落ちない・壊れない・守れる・直せるをぜんぶ同時に成立させること\u003c/strong\u003eです。デモで動くものと、他人の金や生活を預かって動き続けるものは求められるクオリティの桁が違います。\u003c/p\u003e\n\u003cp\u003eこう書くと「でもその見えてない部分もいずれAIが全部埋めるでしょ」と言われそうです。わかります。というか正直それはかなりあると思っています。負荷対策もセキュリティも保守も、いつかAIがまとめて面倒を見る未来は普通に来ると思います。だからここで「AIには無理」みたいな話をするつもりはありません。\u003c/p\u003e\n\u003cp\u003e引っかかっているのはそこじゃなくて、\u003cstrong\u003eそもそも見えてない部分が存在するという事実に気づけていない\u003c/strong\u003eというところです。1万人がアクセスしたら落ちるかもしれない、変な入力で壊れるかもしれない、その論点がまず頭に浮かぶ人だけが「じゃあそこAIに埋めさせよう」と指示を出せます。**埋める手段がAIになっても「何を埋める必要があるか」を判断する部分は残ります。**むしろそこがプロの中身なんですよね。\u003c/p\u003e\n\u003cp\u003e「動いたからエンジニアいらない」と言い切れてしまうのは、その埋めるべき穴が見えていないからこそなんです。見えていないから穴がないように思えてしまいます。逆にいえば\u003cstrong\u003e技術がAIに肩代わりされるほど、穴の在りかを知っている人の価値はむしろ上がる\u003c/strong\u003eんじゃないかと僕は思っています。\u003c/p\u003e\n\u003cp\u003eAIで動くものを作れた人は堂々とそれを喜んでいいと思います。ほんとにすごいので。ただそれと「プロがいらない」はつなげないほうがいい。むしろ自分で少し作ってみたからこそ、その先の見えない部分の深さに気づける立場になったはずなんです。作れるようになった人ほどプロの凄みがわかるようになる。そっちのほうがずっとかっこいいと思いますね。\u003c/p\u003e","title":"AIで作れるようになった人ほど、プロの凄みがわかると思う"},{"content":"朝ベッドから出るのに時間がかかったり、日曜の夜になると胃が重くなったり、通勤電車でこのままどっか遠くに連れて行かれないかなとぼんやり考えてしまったり。仕事がそこまで辛くなってくるといっそFIREして働くこと自体から降りたくなる気持ちはよくわかります。あと何年でいくら貯めれば会社を辞められるのか電卓を叩きたくなる人もいるでしょう。\nでも僕は仕事が辛い人がまず目指すべきなのはFIREじゃなくて転職なんじゃないかと思っています。\nFIREって要するに今の仕事が嫌すぎて働くことそのものから降りたい気持ちの表れですよね。でもよく考えると嫌なのは働くこと全般じゃなくて「その職場で働くこと」のほうだったりします。上司が理不尽とか残業が終わらないとかやってる仕事に意味を感じられないとか。これらは働くこと全体の問題じゃなくて今いる場所の問題なんですよ。それなのに解決策として仕事を丸ごと手放そうとするのは正直ちょっと大げさじゃないでしょうか。まだ試せることがいくらでも残っているのにそれを飛ばしてしまっている気がします。\nしかもFIREって金額のハードルがえげつなく高いんですよね。生活費を全部運用益でまかなうとなると数千万とか億とかの単位になってきます。辛い仕事に耐えながらそこまで貯めるのに10年20年かかるとしたら、その間はずっとすり減りっぱなしになります。ゴールに着く前に心か体のほうが先に折れてしまってもおかしくありません。\nその点で転職はずっと早く状況を変えてくれます。職場が変わるだけで人間関係も仕事内容も労働時間も一気に入れ替わるので、うまくいけば数ヶ月で朝のあの憂鬱が消えることもあるでしょう。FIREが人生をかけた長期プロジェクトだとしたら転職は今月からでも動き出せます。つらさが軽くなるまでの時間がまるで違うんですよ。\nそれに実際に移ってみて「なんだ、働くこと自体は別に嫌じゃなかったんだ」と気づく場合もあります。前の職場がしんどかっただけで環境さえ変われば仕事から得られるものもちゃんとあったりするんですよね。そうなればもうFIREを急ぐ理由自体が消えてしまいます。辛さの原因が仕事じゃなくて場所だったのなら場所を変えれば済むだけの話ですから。\nもちろんFIREを目指すこと自体を否定したいわけじゃありません。それはそれで立派な目標だと思います。ただ今の辛さから抜け出したいだけならちょっと遠回りが過ぎる気もします。まずは近いところから試してみて、それでもやっぱり働くのが嫌だったらそのときFIREを考えたって遅くないはずです。\n","permalink":"https://kenjiusui.github.io/blog/posts/essay/014_%E4%BB%95%E4%BA%8B%E3%81%8C%E8%BE%9B%E3%81%84%E4%BA%BA%E3%81%8C%E7%8B%99%E3%81%86%E3%81%AA%E3%82%89fire%E3%81%98%E3%82%83%E3%81%AA%E3%81%8F%E3%81%A6%E3%81%BE%E3%81%9A%E8%BB%A2%E8%81%B7%E3%81%98%E3%82%83%E3%81%AA%E3%81%84/","summary":"\u003cp\u003e朝ベッドから出るのに時間がかかったり、日曜の夜になると胃が重くなったり、通勤電車でこのままどっか遠くに連れて行かれないかなとぼんやり考えてしまったり。仕事がそこまで辛くなってくるといっそFIREして働くこと自体から降りたくなる気持ちはよくわかります。あと何年でいくら貯めれば会社を辞められるのか電卓を叩きたくなる人もいるでしょう。\u003c/p\u003e\n\u003cp\u003eでも僕は\u003cstrong\u003e仕事が辛い人がまず目指すべきなのはFIREじゃなくて転職\u003c/strong\u003eなんじゃないかと思っています。\u003c/p\u003e\n\u003cp\u003eFIREって要するに今の仕事が嫌すぎて働くことそのものから降りたい気持ちの表れですよね。でもよく考えると\u003cstrong\u003e嫌なのは働くこと全般じゃなくて「その職場で働くこと」のほう\u003c/strong\u003eだったりします。上司が理不尽とか残業が終わらないとかやってる仕事に意味を感じられないとか。これらは働くこと全体の問題じゃなくて今いる場所の問題なんですよ。それなのに解決策として仕事を丸ごと手放そうとするのは正直ちょっと大げさじゃないでしょうか。まだ試せることがいくらでも残っているのにそれを飛ばしてしまっている気がします。\u003c/p\u003e\n\u003cp\u003eしかも\u003cstrong\u003eFIREって金額のハードルがえげつなく高い\u003c/strong\u003eんですよね。生活費を全部運用益でまかなうとなると数千万とか億とかの単位になってきます。辛い仕事に耐えながらそこまで貯めるのに10年20年かかるとしたら、その間はずっとすり減りっぱなしになります。ゴールに着く前に心か体のほうが先に折れてしまってもおかしくありません。\u003c/p\u003e\n\u003cp\u003eその点で\u003cstrong\u003e転職はずっと早く状況を変えてくれます\u003c/strong\u003e。職場が変わるだけで人間関係も仕事内容も労働時間も一気に入れ替わるので、うまくいけば数ヶ月で朝のあの憂鬱が消えることもあるでしょう。FIREが人生をかけた長期プロジェクトだとしたら転職は今月からでも動き出せます。つらさが軽くなるまでの時間がまるで違うんですよ。\u003c/p\u003e\n\u003cp\u003eそれに実際に移ってみて「なんだ、働くこと自体は別に嫌じゃなかったんだ」と気づく場合もあります。前の職場がしんどかっただけで環境さえ変われば仕事から得られるものもちゃんとあったりするんですよね。そうなればもうFIREを急ぐ理由自体が消えてしまいます。辛さの原因が仕事じゃなくて場所だったのなら場所を変えれば済むだけの話ですから。\u003c/p\u003e\n\u003cp\u003eもちろんFIREを目指すこと自体を否定したいわけじゃありません。それはそれで立派な目標だと思います。ただ今の辛さから抜け出したいだけならちょっと遠回りが過ぎる気もします。まずは近いところから試してみて、それでもやっぱり働くのが嫌だったらそのときFIREを考えたって遅くないはずです。\u003c/p\u003e","title":"仕事が辛い人が狙うならFIREじゃなくてまず転職じゃない？"},{"content":"給湯室とか飲みの席で「もうこんな会社やめてやる」「まじで転職するわ」って毎回言ってる人いるじゃないですか。上司がどうとか給料がどうとか人事評価がどうとかとにかく口を開けば会社の不満が出てくる。でもそう言い続けて半年経っても1年経ってもその人はまだ同じ席で同じ愚痴をこぼしてるんですよね。\nこういう「転職したい」が口癖になってる人ほど経験上ほんとに転職しないんですよ。\n最初のうちはまわりもちゃんと愚痴を聞いてくれるんですよ。大変だねって同調してくれるし親身になって求人サイトや転職先を教えてくれる人もいる。でも同じ愚痴を3回4回と聞かされるうちにまわりの反応はどんどん薄くなっていく。言うだけで何も動かない人に本気で付き合ってあげるのって、聞いてる側もさすがにだんだん疲れてくるんですよね。\n聞き流されるようになると本人のやる気も落ちていくし、まわりも「どうせこの人は変わらない」と思って手をかけなくなります。難しい仕事を任せてみようとかこいつを伸ばしてやろうという気持ちも自然と失せていく。本人は会社が嫌で言ってるだけなのにいつのまにか\u0026quot;関わりたくないヤツ\u0026quot;になっちゃうんですよね。\nこれがいちばん怖いところなんですけど、そうやって放っておかれていくと肝心のスキルも人脈も止まっちゃうんです。転職市場で見られるのは結局この数年で何をやってきたかなので、愚痴りながら足踏みしてた時間は外から見るとほとんど空白なんです。文句を言い続けてるあいだにいざ動こうとしたときの手札がどんどん減っていく。転職したいと言い続けた結果として転職できない体になっていくわけです。なかなかの皮肉ですよね。\nたぶん愚痴ること自体が行動の代わりになっちゃってるんだと思います。「転職したい」と口に出すとそれだけでなんか一歩前に進んだ気になれてその場はスッキリするんですよね。でもそのスッキリで満足しちゃうから、求人を見るとか職務経歴書を書くとかいう面倒な行動には手が伸びないんですよね。ガス抜きが上手すぎて逆にいつまでも爆発しないみたいな感じです。\nだから転職したいって気持ちが出てきたら、それを言葉にして消費してしまう前にちょっとだけ手を動かしておくのがいいです。とりあえず求人眺めてみるとか、なんだったら面接受けてみるとか。愚痴に使う時間のほんの一部をそっちに回すだけで将来は結構変わってくるんじゃないかなあとおもいます。\nほんとに転職する人ってだいたい静かにさっさと動くんですよね。逆に転職したいと言い続けるほど実際に転職できる可能性は下がっていく。みなさんは愚痴を言うのもほどほどにして思い立ったら早いうちに動きましょう。\n","permalink":"https://kenjiusui.github.io/blog/posts/essay/013_%E4%BC%9A%E7%A4%BE%E3%81%AE%E6%84%9A%E7%97%B4%E3%81%8C%E5%A4%9A%E3%81%84%E4%BA%BA%E3%81%BB%E3%81%A9%E8%BB%A2%E8%81%B7%E3%81%97%E3%81%AA%E3%81%84/","summary":"\u003cp\u003e給湯室とか飲みの席で「もうこんな会社やめてやる」「まじで転職するわ」って毎回言ってる人いるじゃないですか。上司がどうとか給料がどうとか人事評価がどうとかとにかく口を開けば会社の不満が出てくる。でもそう言い続けて半年経っても1年経ってもその人はまだ同じ席で同じ愚痴をこぼしてるんですよね。\u003c/p\u003e\n\u003cp\u003eこういう「転職したい」が口癖になってる人ほど経験上ほんとに転職しないんですよ。\u003c/p\u003e\n\u003cp\u003e最初のうちはまわりもちゃんと愚痴を聞いてくれるんですよ。大変だねって同調してくれるし親身になって求人サイトや転職先を教えてくれる人もいる。でも同じ愚痴を3回4回と聞かされるうちにまわりの反応はどんどん薄くなっていく。言うだけで何も動かない人に本気で付き合ってあげるのって、聞いてる側もさすがにだんだん疲れてくるんですよね。\u003c/p\u003e\n\u003cp\u003e聞き流されるようになると本人のやる気も落ちていくし、まわりも「どうせこの人は変わらない」と思って手をかけなくなります。難しい仕事を任せてみようとかこいつを伸ばしてやろうという気持ちも自然と失せていく。本人は会社が嫌で言ってるだけなのにいつのまにか\u0026quot;関わりたくないヤツ\u0026quot;になっちゃうんですよね。\u003c/p\u003e\n\u003cp\u003eこれがいちばん怖いところなんですけど、そうやって放っておかれていくと肝心のスキルも人脈も止まっちゃうんです。転職市場で見られるのは結局この数年で何をやってきたかなので、愚痴りながら足踏みしてた時間は外から見るとほとんど空白なんです。文句を言い続けてるあいだにいざ動こうとしたときの手札がどんどん減っていく。転職したいと言い続けた結果として転職できない体になっていくわけです。なかなかの皮肉ですよね。\u003c/p\u003e\n\u003cp\u003eたぶん愚痴ること自体が行動の代わりになっちゃってるんだと思います。「転職したい」と口に出すとそれだけでなんか一歩前に進んだ気になれてその場はスッキリするんですよね。でもそのスッキリで満足しちゃうから、求人を見るとか職務経歴書を書くとかいう面倒な行動には手が伸びないんですよね。ガス抜きが上手すぎて逆にいつまでも爆発しないみたいな感じです。\u003c/p\u003e\n\u003cp\u003eだから転職したいって気持ちが出てきたら、それを言葉にして消費してしまう前にちょっとだけ手を動かしておくのがいいです。とりあえず求人眺めてみるとか、なんだったら面接受けてみるとか。愚痴に使う時間のほんの一部をそっちに回すだけで将来は結構変わってくるんじゃないかなあとおもいます。\u003c/p\u003e\n\u003cp\u003eほんとに転職する人ってだいたい静かにさっさと動くんですよね。逆に転職したいと言い続けるほど実際に転職できる可能性は下がっていく。みなさんは愚痴を言うのもほどほどにして思い立ったら早いうちに動きましょう。\u003c/p\u003e","title":"会社の愚痴が多い人ほど転職しない"},{"content":"あんなにいい人なのになんで報われないんだろうみたいなこと言われてる人ってときどきいるじゃないですか。言われた仕事はきっちり片づけてまわりの評判も悪くない。それなのに給料は上がらないし昇進もしない。世の中は不公平だと。まあそう言いたくなる気持ちもわかるんですよ。\nただその人がなんでいい人扱いされてるのかをよく見るとですね、だいたい「言われたことを素直にやるだけ」なんですよね。上から降ってきた作業を断らずにこなす。頼まれごとにイヤな顔をしない。たしかに一緒に働くぶんには気持ちいいんですよ。でもこの仕事って何のためにあるんだっけとか、もっといいやり方あるんじゃないのとか、そういうのを自分の頭で考えた形跡はびっくりするほどないんです。\nこういう言われたことを何も考えずにこなすのっていい人というよりただ従順なだけなんですよね。そしてこの従順さっていうのが実は給料の伸びない大きな理由だったりするんです。\nむしろ言われたとおりにやるのって実はいちばん楽な道なんですよ。黙って従っておけば何かコケても「指示どおりやっただけ」で逃げ切れる。自分の頭で考えはじめると判断の責任がのしかかってくるし、ときには「それ違いますよね」と波風を立てないといけない。だから従順って真面目の顔をした思考停止になりがちなんです。しかも本人はそれが正しいとおもって頑張ってるぶん余計にタチが悪いんです。\n言われたことをこなせる能力って正直なところ最低限の話であって代わりがいくらでもいるぶん高い給料は出にくいですよね。言い方悪いですが言われたことをこなすのって組織の一番下なんですよ。新卒とかならそれでもいいですけど、そこから先で市場がお金を払うのは良いやり方を自分で模索できるとか何をやるべきかを自分で決められる力とかそういう方向のスキルになります。従順さって周りからは喜ばれても外に持ち出せる価値とは言い難いんですよね。\nなので言われたことだけを10年やってきた人って市場から見ると「10年ぶんの経験」というより**「1年くらいで身につく経験を10回くり返しただけ」**みたいに評価されがちです。\u0026ldquo;いい人\u0026quot;として働いてきたはずなのに転職市場でぜんぜん値がつかないっていうのはこういうその場で足踏みしてるような頑張ってるけど全然進んでない的な状態の人が多いんじゃないかなあとおもいます。\nいい人なのに給料が伸びないなあと感じてるなら、1回自分を雇う側の目で眺めてみるといいと思います。「自分のことお金を払うとして言われたとおり動く以外に何ができるんだっけ？」ってかんがえてみる。そこでパッと答えが出てこないなら自分の行動を見直すといいかもしれません。\nいい人でいるのは悪いことじゃないですけど、どうでもいい人にはならないように気をつけましょう。\n","permalink":"https://kenjiusui.github.io/blog/posts/essay/012_%E3%81%84%E3%81%84%E4%BA%BA%E3%81%AE%E7%B5%A6%E6%96%99%E3%81%8C%E4%BC%B8%E3%81%B3%E3%81%AA%E3%81%84%E7%90%86%E7%94%B1/","summary":"\u003cp\u003eあんなにいい人なのになんで報われないんだろうみたいなこと言われてる人ってときどきいるじゃないですか。言われた仕事はきっちり片づけてまわりの評判も悪くない。それなのに給料は上がらないし昇進もしない。世の中は不公平だと。まあそう言いたくなる気持ちもわかるんですよ。\u003c/p\u003e\n\u003cp\u003eただその人がなんでいい人扱いされてるのかをよく見るとですね、だいたい「言われたことを素直にやるだけ」なんですよね。上から降ってきた作業を断らずにこなす。頼まれごとにイヤな顔をしない。たしかに一緒に働くぶんには気持ちいいんですよ。でもこの仕事って何のためにあるんだっけとか、もっといいやり方あるんじゃないのとか、そういうのを自分の頭で考えた形跡はびっくりするほどないんです。\u003c/p\u003e\n\u003cp\u003eこういう言われたことを何も考えずにこなすのって\u003cstrong\u003eいい人というよりただ従順なだけ\u003c/strong\u003eなんですよね。そして\u003cstrong\u003eこの従順さっていうのが実は給料の伸びない大きな理由\u003c/strong\u003eだったりするんです。\u003c/p\u003e\n\u003cp\u003eむしろ言われたとおりにやるのって実はいちばん楽な道なんですよ。黙って従っておけば何かコケても「指示どおりやっただけ」で逃げ切れる。自分の頭で考えはじめると判断の責任がのしかかってくるし、ときには「それ違いますよね」と波風を立てないといけない。だから\u003cstrong\u003e従順って真面目の顔をした思考停止\u003c/strong\u003eになりがちなんです。しかも本人はそれが正しいとおもって頑張ってるぶん余計にタチが悪いんです。\u003c/p\u003e\n\u003cp\u003e言われたことをこなせる能力って正直なところ最低限の話であって代わりがいくらでもいるぶん高い給料は出にくいですよね。言い方悪いですが言われたことをこなすのって組織の一番下なんですよ。新卒とかならそれでもいいですけど、そこから先で市場がお金を払うのは良いやり方を自分で模索できるとか何をやるべきかを自分で決められる力とかそういう方向のスキルになります。従順さって周りからは喜ばれても外に持ち出せる価値とは言い難いんですよね。\u003c/p\u003e\n\u003cp\u003eなので言われたことだけを10年やってきた人って市場から見ると「10年ぶんの経験」というより**「1年くらいで身につく経験を10回くり返しただけ」**みたいに評価されがちです。\u0026ldquo;いい人\u0026quot;として働いてきたはずなのに転職市場でぜんぜん値がつかないっていうのはこういうその場で足踏みしてるような頑張ってるけど全然進んでない的な状態の人が多いんじゃないかなあとおもいます。\u003c/p\u003e\n\u003cp\u003eいい人なのに給料が伸びないなあと感じてるなら、1回自分を雇う側の目で眺めてみるといいと思います。「自分のことお金を払うとして言われたとおり動く以外に何ができるんだっけ？」ってかんがえてみる。そこでパッと答えが出てこないなら自分の行動を見直すといいかもしれません。\u003c/p\u003e\n\u003cp\u003eいい人でいるのは悪いことじゃないですけど、\u003cstrong\u003eどうでもいい人にはならないように気をつけましょう\u003c/strong\u003e。\u003c/p\u003e","title":"「いい人」の給料が伸びない理由"},{"content":"前の職場に会議のたびに「それってそもそも何のためにやるんでしたっけ」みたいな基本的なことを聞く同僚がいました。みんなが当然の前提でどんどん話を進めているなかで1人だけ話を止めるので、正直「今さらそれ聞く?」と内心思っていました。わかってないのかなと。\nでもあるときその質問のおかげでプロジェクトが救われたんですよ。全員がなんとなく同じ方向で合っていると思い込んでいた前提が実はバラバラで、その人が止めてくれなければ見当違いのものを作って数週間まるごと無駄にするところだった。一見、要領が悪いと思っていた質問こそいちばん的を射た確認だったわけです。\nこのとき愚かだったのは質問した同僚じゃなくてわかったつもりでいた僕のほうでした。自分が理解できないからといって相手が愚かとは限らないということです。\n理解できないのはたいてい相手がおかしいからじゃなくて自分の知らない情報や理由があるからなんですよね。さっきの質問も意図を知るまではただの見当違いにしか見えなかった。こっちは事情の半分も知らないのに見えている部分だけで「無駄」と判定していたわけです。当てずっぽうで出した結論が当たるほうが珍しい。\n人は自分の理解の枠からはみ出すものを見ると相手のほうが変だと処理したくなります。そのほうが楽だからです。自分が何か見落としているかもと考えるよりあいつはズレていると切り捨てるほうが頭を使わなくて済む。でもそれをやった瞬間に理解のチャンスを自分から捨てているんです。\nそもそも他人と自分は考えが違うんですよ。こんなの当たり前なんですがわかっていない人が驚くほど多い。自分の前提は相手にも共有されているはずだと無意識に信じていて、そこからズレた行動を全部「間違い」の箱に放り込んでしまう。前提が違えば正解も変わるのに同じ景色を見ているつもりだから話が噛み合わないだけなんですよね。\nこれは仕事にかぎった話じゃないです。ニュースのコメント欄でもSNSでも自分と違う選択をした人にすぐ馬鹿だ愚かだとラベルを貼る光景があふれている。でもその人にはその人の事情があってこっちが知らないだけかもしれない。少なくともその可能性を消さずに持っておくだけで世界の見え方はだいぶ変わるはずです。\nだから理解できない人に出会ったら馬鹿にするのは事情を聞いてからでも遅くない。たいていは理由が出てきて愚かなのは決めつけた自分のほうだったと気づきます。理解できないというのは相手の頭の出来ではなく自分の足りなさを映す鏡なのかもしれません。\n","permalink":"https://kenjiusui.github.io/blog/posts/essay/011_%E7%90%86%E8%A7%A3%E3%81%A7%E3%81%8D%E3%81%AA%E3%81%84%E3%81%93%E3%81%A8%E3%82%92%E3%81%99%E3%82%8B%E4%BA%BA%E3%82%92%E6%84%9A%E3%81%8B%E3%81%A0%E3%81%A8%E6%B1%BA%E3%82%81%E3%81%A4%E3%81%91%E3%81%AA%E3%81%84%E3%81%BB%E3%81%86%E3%81%8C%E3%81%84%E3%81%84/","summary":"\u003cp\u003e前の職場に会議のたびに「それってそもそも何のためにやるんでしたっけ」みたいな基本的なことを聞く同僚がいました。みんなが当然の前提でどんどん話を進めているなかで1人だけ話を止めるので、正直「今さらそれ聞く?」と内心思っていました。わかってないのかなと。\u003c/p\u003e\n\u003cp\u003eでもあるときその質問のおかげでプロジェクトが救われたんですよ。全員がなんとなく同じ方向で合っていると思い込んでいた前提が実はバラバラで、その人が止めてくれなければ見当違いのものを作って数週間まるごと無駄にするところだった。一見、要領が悪いと思っていた質問こそいちばん的を射た確認だったわけです。\u003c/p\u003e\n\u003cp\u003eこのとき愚かだったのは質問した同僚じゃなくてわかったつもりでいた僕のほうでした。自分が理解できないからといって相手が愚かとは限らないということです。\u003c/p\u003e\n\u003cp\u003e理解できないのはたいてい相手がおかしいからじゃなくて自分の知らない情報や理由があるからなんですよね。さっきの質問も意図を知るまではただの見当違いにしか見えなかった。こっちは事情の半分も知らないのに見えている部分だけで「無駄」と判定していたわけです。当てずっぽうで出した結論が当たるほうが珍しい。\u003c/p\u003e\n\u003cp\u003e人は自分の理解の枠からはみ出すものを見ると相手のほうが変だと処理したくなります。そのほうが楽だからです。自分が何か見落としているかもと考えるよりあいつはズレていると切り捨てるほうが頭を使わなくて済む。でもそれをやった瞬間に理解のチャンスを自分から捨てているんです。\u003c/p\u003e\n\u003cp\u003eそもそも他人と自分は考えが違うんですよ。こんなの当たり前なんですがわかっていない人が驚くほど多い。自分の前提は相手にも共有されているはずだと無意識に信じていて、そこからズレた行動を全部「間違い」の箱に放り込んでしまう。前提が違えば正解も変わるのに同じ景色を見ているつもりだから話が噛み合わないだけなんですよね。\u003c/p\u003e\n\u003cp\u003eこれは仕事にかぎった話じゃないです。ニュースのコメント欄でもSNSでも自分と違う選択をした人にすぐ馬鹿だ愚かだとラベルを貼る光景があふれている。でもその人にはその人の事情があってこっちが知らないだけかもしれない。少なくともその可能性を消さずに持っておくだけで世界の見え方はだいぶ変わるはずです。\u003c/p\u003e\n\u003cp\u003eだから理解できない人に出会ったら馬鹿にするのは事情を聞いてからでも遅くない。たいていは理由が出てきて愚かなのは決めつけた自分のほうだったと気づきます。理解できないというのは相手の頭の出来ではなく自分の足りなさを映す鏡なのかもしれません。\u003c/p\u003e","title":"理解できないことをする人を愚かだと決めつけないほうがいい"},{"content":"「同じ会社に5年もいるの？」みたいな反応をされたことがある人いるんじゃないでしょうか。最近は2、3年で転職を重ねるのが当たり前みたいな空気があって、1つの会社に長くいると成長が止まるとか市場価値が下がるとか言う人がよくいます。なんなら長居そのものがリスクみたいな扱いをされることもある。で、それを真に受けて焦って動く人を何人も見てきました。\n僕が言いたいのは1つの会社に長くいることで得られるものもちゃんとあるということです。\n過去の記事で給料に不満があるなら転職したほうが早いと書いたので矛盾してると思われるかもしれません。でもあれは待遇が動かないなら場所を変えろという話で、長くいること自体を否定したわけじゃないんですよね。場所が合っているなら長くいるメリットはむしろデカい。\n一番大きいのは信頼です。これは時間をかけないと積み上がらない。同じ会社で結果を出し続けると「こいつに任せておけば大丈夫」という評価がたまっていって、ある日それが大きなチャレンジの許可証になるんですよね。新しいことをやらせてもらえるかどうかって能力よりも信頼で決まる場面が多くて、入ったばかりの人がいきなり大きなプロジェクトを任されることはまずないです。逆にいえば時間をかけて積んだ信頼があれば新しい挑戦がしやすくなるってことですね。\n**もう1つは人脈です。**社内で長くやっていると誰が何を握っているかが見えてきて、何か動かしたいときに「あの人に聞けば早い」が増えていく。他部署のキーマンとはなしにいける関係ができてると本来なら何週間もかかる調整が一本の連絡で片付いたりする。これ転職するとほぼリセットされる資産で外から来た人がゼロから築くにはやっぱり時間がかかるんですよ。同じ会社に長くいる人だけが使えるショートカットなんです。\n転職には転職の良さがあるし合わない場所に留まり続けるのはたしかにリスクです。ただ「長くいる＝停滞」という決めつけもまた雑な話で信頼や人脈という時間でしか買えないものを捨てて毎回ゼロからやり直すのが常に正解とは限らないんですね。腰を据えたからこそできる大きな仕事もあるんです。動くのが偉いわけでも残るのが偉いわけでもなくて自分がいま積み上げの途中なのか頭打ちなのか、そこを見極めるのが大事なのかなあとおもいます。\n","permalink":"https://kenjiusui.github.io/blog/posts/essay/010_1%E3%81%A4%E3%81%AE%E4%BC%9A%E7%A4%BE%E3%81%AB%E9%95%B7%E3%81%8F%E3%81%84%E3%82%8B%E3%81%AE%E3%81%AF%E6%A1%88%E5%A4%96%E3%82%8F%E3%82%8B%E3%81%8F%E3%81%AA%E3%81%84/","summary":"\u003cp\u003e「同じ会社に5年もいるの？」みたいな反応をされたことがある人いるんじゃないでしょうか。最近は2、3年で転職を重ねるのが当たり前みたいな空気があって、1つの会社に長くいると成長が止まるとか市場価値が下がるとか言う人がよくいます。なんなら長居そのものがリスクみたいな扱いをされることもある。で、それを真に受けて焦って動く人を何人も見てきました。\u003c/p\u003e\n\u003cp\u003e僕が言いたいのは\u003cstrong\u003e1つの会社に長くいることで得られるものもちゃんとある\u003c/strong\u003eということです。\u003c/p\u003e\n\u003cp\u003e過去の記事で給料に不満があるなら転職したほうが早いと書いたので矛盾してると思われるかもしれません。でもあれは待遇が動かないなら場所を変えろという話で、長くいること自体を否定したわけじゃないんですよね。場所が合っているなら長くいるメリットはむしろデカい。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e一番大きいのは信頼です。\u003cstrong\u003eこれは時間をかけないと積み上がらない。同じ会社で結果を出し続けると「こいつに任せておけば大丈夫」という評価がたまっていって、ある日それが大きなチャレンジの許可証になるんですよね。新しいことをやらせてもらえるかどうかって能力よりも信頼で決まる場面が多くて、入ったばかりの人がいきなり大きなプロジェクトを任されることはまずないです。逆にいえば\u003c/strong\u003e時間をかけて積んだ信頼があれば新しい挑戦がしやすくなる\u003c/strong\u003eってことですね。\u003c/p\u003e\n\u003cp\u003e**もう1つは人脈です。**社内で長くやっていると誰が何を握っているかが見えてきて、何か動かしたいときに「あの人に聞けば早い」が増えていく。他部署のキーマンとはなしにいける関係ができてると本来なら何週間もかかる調整が一本の連絡で片付いたりする。これ転職するとほぼリセットされる資産で外から来た人がゼロから築くにはやっぱり時間がかかるんですよ。同じ会社に長くいる人だけが使えるショートカットなんです。\u003c/p\u003e\n\u003cp\u003e転職には転職の良さがあるし合わない場所に留まり続けるのはたしかにリスクです。ただ「長くいる＝停滞」という決めつけもまた雑な話で\u003cstrong\u003e信頼や人脈という時間でしか買えないものを捨てて毎回ゼロからやり直すのが常に正解とは限らない\u003c/strong\u003eんですね。腰を据えたからこそできる大きな仕事もあるんです。動くのが偉いわけでも残るのが偉いわけでもなくて自分がいま積み上げの途中なのか頭打ちなのか、そこを見極めるのが大事なのかなあとおもいます。\u003c/p\u003e","title":"1つの会社に長くいるのは案外わるくない"},{"content":"フリーランスをやっていると副業を始めようとしている友人から相談を受けることがたまにあります。エンジニアの彼は「スキルを活かして案件を受ければ月10万くらいいけるかも」と言ってたんですが話を聞いていてちょっと待てと思ったんですよね。それ副業じゃなくてただの残業じゃないかと。\n今日は副業はよほどの理由がない限りやらないほうがいいという話をします。 noteでこういうこというと怒る人が多そうだけどね。\nエンジニアなど専門職がスキルを活かして案件をこなす副業は実質残業です。というか本業と同じことをやりながら営業や確定申告や契約管理という余計な仕事が増えるので残業未満です。それなら最初から残業を選んだほうがリスクがなく手っ取り早い。会社員として働く時間を伸ばすほうがよっぽどシンプルです。副業という形を取ることで増えるのは収入より手間のほうが多い場合がほとんどです。確定申告は面倒ですよ。\nSNS運用みたいなやつはもっとわかりやすくて、あれで稼げているのは「副業のやり方を教える人たち」がほとんどです。 情報商材屋が儲かる構造がうまくできていて実際に運用してみると収益は微々たるものになりやすい。\nYouTuberやライターも同じで労力を正直に時給換算すると最低賃金すら割ることが多い。これを副業と呼ぶのはちょっと違うなと思います。好きな人が好きなことしてついでにお金をもらうくらいのスタンスがいいとおもってます。\n本業以外で純粋に収入を増やしたいだけならバイトするのが一番確実です。 働いた分だけきちんとお金がもらえる。当たり前のことですが副業の情報に囲まれているとこの当たり前を見失いがちになります。最近は残業できない会社も少なくありませんが、残業以外で収入を増やすなら変な副業じゃなくてバイトしたほうが早いです。\nただ例外があって、起業や独立を本気で考えているなら副業という形で小さく試すのは意味があります。 僕がいまフリーランスでやっていけているのも会社員時代に副業で小さく試して感触を確かめていたからで、そうやって学んだことは今に繋がっています。失敗のリスクを抑えながら将来の足がかりをつくるという目的があるなら多少非効率でもやる価値はあります。\nそもそも収入を上げたいなら本業に集中するのが一番効いてくることが多いです。 副業に使う時間とエネルギーを本業のスキルアップに回しましょう。今の会社で上がらないなら転職を検討したほうがいいですね。転職市場では年収の上がり幅が副業で稼げる額とは桁が違うことも珍しくないです。副業で月5万稼ぐために週末を削るより転職で年収を50万上げるほうがずっと現実的だし体も楽です。なによりも王道なので上手くいきやすい。\n副業ブームで「副業＝収入を増やす手段」というイメージが定着しています。でも「稼ぎたいだけ」と「将来に向けて試したい」はかなり性質が違います。前者が目的なら副業は回り道になりやすい。副業なんかに浮気せず素直に本業に集中する方が正解です。\n","permalink":"https://kenjiusui.github.io/blog/posts/essay/009_%E3%83%95%E3%83%AA%E3%83%BC%E3%83%A9%E3%83%B3%E3%82%B9%E3%81%AE%E5%83%95%E3%81%8C%E5%89%AF%E6%A5%AD%E3%82%92%E3%81%99%E3%81%99%E3%82%81%E3%81%AA%E3%81%84%E7%90%86%E7%94%B1/","summary":"\u003cp\u003eフリーランスをやっていると副業を始めようとしている友人から相談を受けることがたまにあります。エンジニアの彼は「スキルを活かして案件を受ければ月10万くらいいけるかも」と言ってたんですが話を聞いていてちょっと待てと思ったんですよね。それ副業じゃなくてただの残業じゃないかと。\u003c/p\u003e\n\u003cp\u003e今日は副業はよほどの理由がない限りやらないほうがいいという話をします。 noteでこういうこというと怒る人が多そうだけどね。\u003c/p\u003e\n\u003cp\u003eエンジニアなど専門職がスキルを活かして案件をこなす副業は実質残業です。というか本業と同じことをやりながら営業や確定申告や契約管理という余計な仕事が増えるので残業未満です。それなら最初から残業を選んだほうがリスクがなく手っ取り早い。会社員として働く時間を伸ばすほうがよっぽどシンプルです。副業という形を取ることで増えるのは収入より手間のほうが多い場合がほとんどです。確定申告は面倒ですよ。\u003c/p\u003e\n\u003cp\u003eSNS運用みたいなやつはもっとわかりやすくて、あれで稼げているのは「副業のやり方を教える人たち」がほとんどです。 情報商材屋が儲かる構造がうまくできていて実際に運用してみると収益は微々たるものになりやすい。\u003c/p\u003e\n\u003cp\u003eYouTuberやライターも同じで労力を正直に時給換算すると最低賃金すら割ることが多い。これを副業と呼ぶのはちょっと違うなと思います。好きな人が好きなことしてついでにお金をもらうくらいのスタンスがいいとおもってます。\u003c/p\u003e\n\u003cp\u003e本業以外で純粋に収入を増やしたいだけならバイトするのが一番確実です。 働いた分だけきちんとお金がもらえる。当たり前のことですが副業の情報に囲まれているとこの当たり前を見失いがちになります。最近は残業できない会社も少なくありませんが、残業以外で収入を増やすなら変な副業じゃなくてバイトしたほうが早いです。\u003c/p\u003e\n\u003cp\u003eただ例外があって、起業や独立を本気で考えているなら副業という形で小さく試すのは意味があります。 僕がいまフリーランスでやっていけているのも会社員時代に副業で小さく試して感触を確かめていたからで、そうやって学んだことは今に繋がっています。失敗のリスクを抑えながら将来の足がかりをつくるという目的があるなら多少非効率でもやる価値はあります。\u003c/p\u003e\n\u003cp\u003eそもそも収入を上げたいなら本業に集中するのが一番効いてくることが多いです。 副業に使う時間とエネルギーを本業のスキルアップに回しましょう。今の会社で上がらないなら転職を検討したほうがいいですね。転職市場では年収の上がり幅が副業で稼げる額とは桁が違うことも珍しくないです。副業で月5万稼ぐために週末を削るより転職で年収を50万上げるほうがずっと現実的だし体も楽です。なによりも王道なので上手くいきやすい。\u003c/p\u003e\n\u003cp\u003e副業ブームで「副業＝収入を増やす手段」というイメージが定着しています。でも「稼ぎたいだけ」と「将来に向けて試したい」はかなり性質が違います。前者が目的なら副業は回り道になりやすい。副業なんかに浮気せず素直に本業に集中する方が正解です。\u003c/p\u003e","title":"フリーランスの僕が副業をすすめない理由"},{"content":"最近よく見るんですよね。「アウトプットが大事だからAIで記事を書いて毎日投稿してます」みたいな人。学んだことをAIにまとめさせて公開する。たしかに量は出るし見た目もちゃんとしている。でも僕はこれを見るたびに思うんですよね。それ本当に \u0026ldquo;アウトプット\u0026rdquo; になってます？\n先に言っておくと僕自身も仕事でAIはがっつり使っています。だからAIを使うな、みたいな話をしたいわけじゃないです。引っかかっているのはもっと別のところにあります。\nネットに記事を書くのってざっくり2つの目的があって1つは世の中への情報提供でもう1つは自分の理解の検証です。で、AIが効くのは前者の方なんですよね。\n情報提供のほうはむしろAIのほうが速いし上手いことも多い。これはもう認めるしかない。でも自分の理解が試されるという後者の機能、こっちはAIにはどうやっても代われないんです。\n問題はAIが情報の提供をきれいに肩代わりしてくれるせいで、自分の理解の検証まで一緒に済ませた気になってしまうことなんです。\n理解の穴って「自分の言葉で書こうとして書けない瞬間」に初めて露出するんですよ。分かったつもりで書き始めたら例が思いつかない、ロジックが飛ぶ、結論が宙に浮く。あの詰まる瞬間こそが「お前ここ分かってないぞ」のサインでそれを潰しながら書き上げるから理解が固まるんです。AIに任せるとこの詰まりがまるごと消えて穴があったことにすら気づけない。\nしかもタチが悪いのは、出来上がった記事を読むと自分まで分かった気になることです。すらすら読めるから理解した感覚だけはしっかり残る。でも人に説明してみろと言われると詰まる。読んで分かるのとゼロから組み立てられるのは完全に別の能力で後者だけが本当に使える理解なんですよね。\n「叩き台をAIに作らせて自分で直せばいいのでは？」とか「AIと相談しながら書くのはダメなん？」みたいなこと言われそうですが、それは全然いいと思います。論点は思考の丸投げと壁打ちの線引きなんです。思考を肩代わりさせるのか、思考の相手をさせるのかという違いです。思考を丸投げすると自分の理解の検証が消えるけど壁打ちなら自分の頭が動くぶんちゃんと検証は回る。同じ「AIを使う」でも主従が逆なんです。\n要するに「書けた」と「分かった」は別物でAIは前者を肩代わりしてくれるけど後者は肩代わりできない。なのに前者が手に入ると後者までやった気になる。アウトプットの達成感だけ残って本当にやりたかったはずの復習の機会をむしろ失っている。\nだから価値提供がしたいならAIをどんどん使えばいい。でも「学んだことを定着させたい」が目的なら、そこだけは面倒でも自分の手で書いたほうがいい。目的が違うものを同じ「アウトプット」という言葉でくくるからやった気だけが量産されるんです。\nその記事、AIなしで自分の言葉でもう一度書けそうですか。書けなさそうなら、まだ自分のものにはなってないのかもしれませんね。\n","permalink":"https://kenjiusui.github.io/blog/posts/essay/007_ai%E3%81%A7%E8%A8%98%E4%BA%8B%E3%82%92%E6%9B%B8%E3%81%84%E3%81%9F%E3%81%AF%E3%82%A2%E3%82%A6%E3%83%88%E3%83%97%E3%83%83%E3%83%88%E3%81%A8%E8%A8%80%E3%81%88%E3%82%8B%E3%82%93%E3%81%A0%E3%82%8D%E3%81%86%E3%81%8B/","summary":"\u003cp\u003e最近よく見るんですよね。「アウトプットが大事だからAIで記事を書いて毎日投稿してます」みたいな人。学んだことをAIにまとめさせて公開する。たしかに量は出るし見た目もちゃんとしている。でも僕はこれを見るたびに思うんですよね。それ本当に \u0026ldquo;アウトプット\u0026rdquo; になってます？\u003c/p\u003e\n\u003cp\u003e先に言っておくと僕自身も仕事でAIはがっつり使っています。だからAIを使うな、みたいな話をしたいわけじゃないです。引っかかっているのはもっと別のところにあります。\u003c/p\u003e\n\u003cp\u003eネットに記事を書くのってざっくり2つの目的があって1つは世の中への情報提供でもう1つは自分の理解の検証です。で、AIが効くのは前者の方なんですよね。\u003c/p\u003e\n\u003cp\u003e情報提供のほうはむしろAIのほうが速いし上手いことも多い。これはもう認めるしかない。でも自分の理解が試されるという後者の機能、こっちはAIにはどうやっても代われないんです。\u003c/p\u003e\n\u003cp\u003e問題はAIが情報の提供をきれいに肩代わりしてくれるせいで、自分の理解の検証まで一緒に済ませた気になってしまうことなんです。\u003c/p\u003e\n\u003cp\u003e理解の穴って「自分の言葉で書こうとして書けない瞬間」に初めて露出するんですよ。分かったつもりで書き始めたら例が思いつかない、ロジックが飛ぶ、結論が宙に浮く。あの詰まる瞬間こそが「お前ここ分かってないぞ」のサインでそれを潰しながら書き上げるから理解が固まるんです。AIに任せるとこの詰まりがまるごと消えて穴があったことにすら気づけない。\u003c/p\u003e\n\u003cp\u003eしかもタチが悪いのは、出来上がった記事を読むと自分まで分かった気になることです。すらすら読めるから理解した感覚だけはしっかり残る。でも人に説明してみろと言われると詰まる。読んで分かるのとゼロから組み立てられるのは完全に別の能力で後者だけが本当に使える理解なんですよね。\u003c/p\u003e\n\u003cp\u003e「叩き台をAIに作らせて自分で直せばいいのでは？」とか「AIと相談しながら書くのはダメなん？」みたいなこと言われそうですが、それは全然いいと思います。論点は思考の丸投げと壁打ちの線引きなんです。思考を肩代わりさせるのか、思考の相手をさせるのかという違いです。思考を丸投げすると自分の理解の検証が消えるけど壁打ちなら自分の頭が動くぶんちゃんと検証は回る。同じ「AIを使う」でも主従が逆なんです。\u003c/p\u003e\n\u003cp\u003e要するに「書けた」と「分かった」は別物でAIは前者を肩代わりしてくれるけど後者は肩代わりできない。なのに前者が手に入ると後者までやった気になる。アウトプットの達成感だけ残って本当にやりたかったはずの復習の機会をむしろ失っている。\u003c/p\u003e\n\u003cp\u003eだから価値提供がしたいならAIをどんどん使えばいい。でも「学んだことを定着させたい」が目的なら、そこだけは面倒でも自分の手で書いたほうがいい。目的が違うものを同じ「アウトプット」という言葉でくくるからやった気だけが量産されるんです。\u003c/p\u003e\n\u003cp\u003eその記事、AIなしで自分の言葉でもう一度書けそうですか。書けなさそうなら、まだ自分のものにはなってないのかもしれませんね。\u003c/p\u003e","title":"「AIで記事を書いた」はアウトプットと言えるんだろうか"},{"content":"評価面談で「いやー今期もよく頑張ってくれたね」と言われて昇給額を聞いたら月5000円だった、みたいな話あるじゃないですか。こっちは去年より明らかにできることが増えて任される範囲も広がっているのに上がるのはその程度かよ、みっていう。で、来年も再来年もこのペースなのかと薄々気づいてしまう。\n僕がこういう人に言いたいのは、給料に不満があるならスキルを上げながらさっさと転職を考えたほうがいいということです。\n多くの人が給料を上げるには社内で昇進すればいいと考えてるんですけど社内昇進にははっきり天井があります。わかりやすく言うと、あなたの会社の課長が年収400万円ならあなたが課長になったときの年収も400万円なんですよ。どれだけ頑張って1段上がっても、行き着く先の金額はもう先に座っている人を見れば見えている。会社の給与テーブルって基本的にレンジが決まっていて、どれだけ評価されてもその枠を超えては払われないんです。\nしかも昇進はポストの空き次第で上が詰まっていればどれだけ実力があっても順番待ちです。さらに今の会社が決めた等級の中での評価なので「この会社の中でどう見えるか」しか反映されない。市場全体で自分にいくらの値がつくかとは別物なんですよね。\nつまり精神論じゃなくて構造の話なんです。スキルが上がると転職市場での価値が上がるとはいえ、その能力にお金を払える会社は限られているわけなので。だから同じスキルの人でも所属する会社が変わるだけで年収が普通に100万200万変わるんですよね。社内で評価を1段階上げてもらうより別の会社の給与テーブルに乗っかるほうが上げ幅がデカいことが珍しくないのはそういう理由です。\nだからスキルが上がっているのに給料が動かないなら、それは実力不足じゃなくて単に場所が合っていないだけのことが多いです。会社の中で必死に1段上を目指すのは天井の低い部屋で背伸びしているようなものです。背は伸びているのに頭をぶつけて止まる。\nとはいえ年収の数字だけ見て飛びつくのも危ないです。社内で積んだ信頼やドメイン知識みたいに転職でリセットされる資産もちゃんとあります。そこは天秤にかけたほうがいいです。ただそれを差し引いても、いまの待遇に納得できていないなら動く準備だけは始めておく価値があります。今はリモートで面接してくれるとこも多いので小さく転職活動しやすいです。\n結局のところ会社は給与テーブル以上のお金は払えないし、そのテーブルを自分の頑張りで書き換えることはできません。変えられるのはどのテーブルに座るかだけです。今のテーブルに納得できないならスキルを上げながら別のテーブルに移ればいい。給料を上げる方法って案外それくらいシンプルな話なんだと思います。\n","permalink":"https://kenjiusui.github.io/blog/posts/essay/008_%E7%B5%A6%E6%96%99%E3%81%AB%E4%B8%8D%E6%BA%80%E3%81%8C%E3%81%82%E3%82%8B%E3%81%AA%E3%82%89%E6%98%87%E9%80%B2%E3%82%92%E5%BE%85%E3%81%A4%E3%82%88%E3%82%8A%E8%BB%A2%E8%81%B7%E3%81%97%E3%81%9F%E3%81%BB%E3%81%86%E3%81%8C%E6%97%A9%E3%81%84/","summary":"\u003cp\u003e評価面談で「いやー今期もよく頑張ってくれたね」と言われて昇給額を聞いたら月5000円だった、みたいな話あるじゃないですか。こっちは去年より明らかにできることが増えて任される範囲も広がっているのに上がるのはその程度かよ、みっていう。で、来年も再来年もこのペースなのかと薄々気づいてしまう。\u003c/p\u003e\n\u003cp\u003e僕がこういう人に言いたいのは、給料に不満があるならスキルを上げながらさっさと転職を考えたほうがいいということです。\u003c/p\u003e\n\u003cp\u003e多くの人が給料を上げるには社内で昇進すればいいと考えてるんですけど社内昇進にははっきり天井があります。わかりやすく言うと、あなたの会社の課長が年収400万円ならあなたが課長になったときの年収も400万円なんですよ。どれだけ頑張って1段上がっても、行き着く先の金額はもう先に座っている人を見れば見えている。会社の給与テーブルって基本的にレンジが決まっていて、どれだけ評価されてもその枠を超えては払われないんです。\u003c/p\u003e\n\u003cp\u003eしかも昇進はポストの空き次第で上が詰まっていればどれだけ実力があっても順番待ちです。さらに今の会社が決めた等級の中での評価なので「この会社の中でどう見えるか」しか反映されない。市場全体で自分にいくらの値がつくかとは別物なんですよね。\u003c/p\u003e\n\u003cp\u003eつまり精神論じゃなくて構造の話なんです。スキルが上がると転職市場での価値が上がるとはいえ、その能力にお金を払える会社は限られているわけなので。だから同じスキルの人でも所属する会社が変わるだけで年収が普通に100万200万変わるんですよね。社内で評価を1段階上げてもらうより別の会社の給与テーブルに乗っかるほうが上げ幅がデカいことが珍しくないのはそういう理由です。\u003c/p\u003e\n\u003cp\u003eだからスキルが上がっているのに給料が動かないなら、それは実力不足じゃなくて単に場所が合っていないだけのことが多いです。会社の中で必死に1段上を目指すのは天井の低い部屋で背伸びしているようなものです。背は伸びているのに頭をぶつけて止まる。\u003c/p\u003e\n\u003cp\u003eとはいえ年収の数字だけ見て飛びつくのも危ないです。社内で積んだ信頼やドメイン知識みたいに転職でリセットされる資産もちゃんとあります。そこは天秤にかけたほうがいいです。ただそれを差し引いても、いまの待遇に納得できていないなら動く準備だけは始めておく価値があります。今はリモートで面接してくれるとこも多いので小さく転職活動しやすいです。\u003c/p\u003e\n\u003cp\u003e結局のところ会社は給与テーブル以上のお金は払えないし、そのテーブルを自分の頑張りで書き換えることはできません。変えられるのはどのテーブルに座るかだけです。今のテーブルに納得できないならスキルを上げながら別のテーブルに移ればいい。給料を上げる方法って案外それくらいシンプルな話なんだと思います。\u003c/p\u003e","title":"給料に不満があるなら昇進を待つより転職したほうが早い"},{"content":"仕事をしているとよく言われますよね。「相手の立場に立って考えろ」って。お客さんが何を求めているか想像しろとか上司がどう受け取るか先回りしろとか。まあ正論だし、面と向かって反論しづらい。でも僕はこれ言うほど役に立たないというか事故のもとだと思っているんですよ。\nなぜかというと「相手の立場で考える」って実際にやってみると相手の頭の中を読む作業じゃなくて自分の願望を相手に投影する作業になりがちだからです。\nたとえば提案資料を作るときに「お客さんの立場で考えるとこの機能が一番刺さるはず」と何時間も練り込んで持っていったら先方が欲しかったのは全然別のところだった、みたいな経験ないですか。あれは相手の気持ちを当てたんじゃなくて自分が推したい案を「相手もきっとこう思っているはず」という形で正当化していただけなんですよね。\n人は相手を思いやっているつもりでたいてい自分が見たいものを相手に押し付けています。「あの人は急かされるのを嫌うはず」と思って連絡を控えたら本当はさっさと答えがほしかった。「上司は細かい報告を面倒がるはず」と要約して伝えたら肝心なところを省くなと怒られた。全部こっちの想像で相手は一言もそうとは言っていないんだからまあ100%自分が悪いです。\nで、これを一発で解決する方法があるんですよ。素直に聞けばいいんです。\n「どういう形だと一番助かりますか」「これとこれだとどっちがいいですか」って直接本人に確認する。たったこれだけで想像の精度がどうとか悩む必要が消える。立場を推し量るより本人に聞くほうが速いし正確に決まっているんです。答えを持っている人が目の前にいるんだから。\n想像はタダで何時間でもできるけど当たっている保証はゼロです。質問は一瞬で正解が返ってくる。なのにみんな聞くより想像するほうを選ぶ。聞くと無能に見えるとか相手に手間をかけて悪いとか察するのが気遣いだとか、そういう刷り込みがあるからなんですよね。\nでも本当の気遣いは思いやりを押しつけることじゃなくて相手が望むものをちゃんと渡すことです。そのためには想像で埋めず聞いて確かめるのが一番手っ取り早い。\n「相手の立場で考える」のは聞けないときの最終手段でいい。相手に聞けるなら考える前に口を開きましょう。\n","permalink":"https://kenjiusui.github.io/blog/posts/essay/006_%E7%9B%B8%E6%89%8B%E3%81%AE%E7%AB%8B%E5%A0%B4%E3%81%A7%E8%80%83%E3%81%88%E3%82%8D%E3%81%AF%E3%81%A0%E3%81%84%E3%81%9F%E3%81%84%E4%BA%8B%E6%95%85%E3%82%8B/","summary":"\u003cp\u003e仕事をしているとよく言われますよね。「相手の立場に立って考えろ」って。お客さんが何を求めているか想像しろとか上司がどう受け取るか先回りしろとか。まあ正論だし、面と向かって反論しづらい。でも僕はこれ言うほど役に立たないというか事故のもとだと思っているんですよ。\u003c/p\u003e\n\u003cp\u003eなぜかというと「相手の立場で考える」って実際にやってみると相手の頭の中を読む作業じゃなくて自分の願望を相手に投影する作業になりがちだからです。\u003c/p\u003e\n\u003cp\u003eたとえば提案資料を作るときに「お客さんの立場で考えるとこの機能が一番刺さるはず」と何時間も練り込んで持っていったら先方が欲しかったのは全然別のところだった、みたいな経験ないですか。あれは相手の気持ちを当てたんじゃなくて自分が推したい案を「相手もきっとこう思っているはず」という形で正当化していただけなんですよね。\u003c/p\u003e\n\u003cp\u003e人は相手を思いやっているつもりでたいてい自分が見たいものを相手に押し付けています。「あの人は急かされるのを嫌うはず」と思って連絡を控えたら本当はさっさと答えがほしかった。「上司は細かい報告を面倒がるはず」と要約して伝えたら肝心なところを省くなと怒られた。全部こっちの想像で相手は一言もそうとは言っていないんだからまあ100%自分が悪いです。\u003c/p\u003e\n\u003cp\u003eで、これを一発で解決する方法があるんですよ。素直に聞けばいいんです。\u003c/p\u003e\n\u003cp\u003e「どういう形だと一番助かりますか」「これとこれだとどっちがいいですか」って直接本人に確認する。たったこれだけで想像の精度がどうとか悩む必要が消える。立場を推し量るより本人に聞くほうが速いし正確に決まっているんです。答えを持っている人が目の前にいるんだから。\u003c/p\u003e\n\u003cp\u003e想像はタダで何時間でもできるけど当たっている保証はゼロです。質問は一瞬で正解が返ってくる。なのにみんな聞くより想像するほうを選ぶ。聞くと無能に見えるとか相手に手間をかけて悪いとか察するのが気遣いだとか、そういう刷り込みがあるからなんですよね。\u003c/p\u003e\n\u003cp\u003eでも本当の気遣いは思いやりを押しつけることじゃなくて相手が望むものをちゃんと渡すことです。そのためには想像で埋めず聞いて確かめるのが一番手っ取り早い。\u003c/p\u003e\n\u003cp\u003e「相手の立場で考える」のは聞けないときの最終手段でいい。相手に聞けるなら考える前に口を開きましょう。\u003c/p\u003e","title":"「相手の立場で考えろ」はだいたい事故る"},{"content":"やりたい仕事を探すっていうのを一旦やめて、それよりも先に心底やりたくない仕事から逃げてみたらいいんじゃないかっていう話をします。\n世間はだいたい逆を言いますよね。「本当にやりたいことを見つけよう」とか「天職を探せ」とか「好きを仕事にしろ」みたいな。でも僕はこの順番がそもそも間違っていると思っていて、やりたいことを足す前にやりたくないことから離れるほうがずっと大事だと思っています。特にやりたくないことまみれの仕事をしている人は。\nたとえば理不尽に怒鳴る客の電話を一日中受けるとか、誰も読まない資料を体裁だけ整えて延々と作るとか、心の底からどうでもいいと思っている数字のために自分をすり減らすとか。ああいう仕事を月曜から金曜まで続けていると休日に何をしてもいまいち回復しなくて、気づくと頭の中がずっとどんよりしたままになる。まずはここから抜けるのが先なんですよ。\nそもそもやりたい仕事なんてそうそうあるものではないんですから。\n心からやりたいと思える仕事に出会えるのはかなり運がいい人の話で、ほとんどの人は一生かけても巡り合えなかったりします。確率の低いものを引き当てようと頑張るのはしんどいし空振りも多い。なんなら僕も別にソフトウェア開発という仕事は天職だなんて全然思ってないです。\n一方でやりたくない仕事のほうは驚くほどはっきりわかります。やってみて吐き気がするとか日曜の夜に憂鬱になるとか。体が先に答えを出してくれるので判定が簡単なんですよね。\nだったら当てるのが難しい正解を探すより、はっきりわかる不正解を一個ずつ消していくほうが現実的です。やりたいことを見つけるんじゃなくてやりたくないことを引き算で減らしていく。こっちのほうがよっぽど打率が高い。\nそれにやりたくない仕事って人生の地力みたいなものをじわじわ削ってくるんですよ。\n毎日嫌なことに耐えていると気力も体力も自尊心も少しずつ目減りしていって、いざ面白そうな話が来てもそれに飛びつくエネルギーが残っていない。あのときこうしてたらなーみたいな後悔ばっかり積もって人生つまんなくないですか？\n逆に「最悪これだけは嫌だ」というものから距離を取れているだけで日々の消耗がぜんぜん違う。土台が削られていない状態をキープできていればチャンスが来たときにちゃんと動ける。やりたいことに出会えるかどうかも結局はこの余力次第なんです。なにより挑戦ができると人生が楽しくなる。\nだからキャリアの話をするときも僕は「何がやりたいか」より先に「何だけは絶対やりたくないか」を決めたほうがいいと思っています。やりたいことは曖昧でも構わない。でもやりたくないことだけははっきりさせて、そこからは全力で逃げる。逃げるというと聞こえは悪いけどこれは立派な戦略です。\nやりたい仕事を探すのは一生かけてゆっくりやればいいので、やりたくない仕事から逃げるのは今日から始めましょう。\n","permalink":"https://kenjiusui.github.io/blog/posts/essay/004_%E3%82%84%E3%82%8A%E3%81%9F%E3%81%84%E4%BB%95%E4%BA%8B%E3%82%88%E3%82%8A%E5%85%88%E3%81%AB%E3%82%84%E3%82%8A%E3%81%9F%E3%81%8F%E3%81%AA%E3%81%84%E4%BB%95%E4%BA%8B%E3%81%8B%E3%82%89%E9%80%83%E3%81%92%E3%82%8B/","summary":"\u003cp\u003eやりたい仕事を探すっていうのを一旦やめて、それよりも先に心底やりたくない仕事から逃げてみたらいいんじゃないかっていう話をします。\u003c/p\u003e\n\u003cp\u003e世間はだいたい逆を言いますよね。「本当にやりたいことを見つけよう」とか「天職を探せ」とか「好きを仕事にしろ」みたいな。でも僕はこの順番がそもそも間違っていると思っていて、やりたいことを足す前にやりたくないことから離れるほうがずっと大事だと思っています。特にやりたくないことまみれの仕事をしている人は。\u003c/p\u003e\n\u003cp\u003eたとえば理不尽に怒鳴る客の電話を一日中受けるとか、誰も読まない資料を体裁だけ整えて延々と作るとか、心の底からどうでもいいと思っている数字のために自分をすり減らすとか。ああいう仕事を月曜から金曜まで続けていると休日に何をしてもいまいち回復しなくて、気づくと頭の中がずっとどんよりしたままになる。まずはここから抜けるのが先なんですよ。\u003c/p\u003e\n\u003cp\u003eそもそもやりたい仕事なんてそうそうあるものではないんですから。\u003c/p\u003e\n\u003cp\u003e心からやりたいと思える仕事に出会えるのはかなり運がいい人の話で、ほとんどの人は一生かけても巡り合えなかったりします。確率の低いものを引き当てようと頑張るのはしんどいし空振りも多い。なんなら僕も別にソフトウェア開発という仕事は天職だなんて全然思ってないです。\u003c/p\u003e\n\u003cp\u003e一方でやりたくない仕事のほうは驚くほどはっきりわかります。やってみて吐き気がするとか日曜の夜に憂鬱になるとか。体が先に答えを出してくれるので判定が簡単なんですよね。\u003c/p\u003e\n\u003cp\u003eだったら当てるのが難しい正解を探すより、はっきりわかる不正解を一個ずつ消していくほうが現実的です。やりたいことを見つけるんじゃなくてやりたくないことを引き算で減らしていく。こっちのほうがよっぽど打率が高い。\u003c/p\u003e\n\u003cp\u003eそれにやりたくない仕事って人生の地力みたいなものをじわじわ削ってくるんですよ。\u003c/p\u003e\n\u003cp\u003e毎日嫌なことに耐えていると気力も体力も自尊心も少しずつ目減りしていって、いざ面白そうな話が来てもそれに飛びつくエネルギーが残っていない。あのときこうしてたらなーみたいな後悔ばっかり積もって人生つまんなくないですか？\u003c/p\u003e\n\u003cp\u003e逆に「最悪これだけは嫌だ」というものから距離を取れているだけで日々の消耗がぜんぜん違う。土台が削られていない状態をキープできていればチャンスが来たときにちゃんと動ける。やりたいことに出会えるかどうかも結局はこの余力次第なんです。なにより挑戦ができると人生が楽しくなる。\u003c/p\u003e\n\u003cp\u003eだからキャリアの話をするときも僕は「何がやりたいか」より先に「何だけは絶対やりたくないか」を決めたほうがいいと思っています。やりたいことは曖昧でも構わない。でもやりたくないことだけははっきりさせて、そこからは全力で逃げる。逃げるというと聞こえは悪いけどこれは立派な戦略です。\u003c/p\u003e\n\u003cp\u003eやりたい仕事を探すのは一生かけてゆっくりやればいいので、やりたくない仕事から逃げるのは今日から始めましょう。\u003c/p\u003e","title":"やりたい仕事より先に、やりたくない仕事から逃げる"},{"content":"ここ最近どうにも仕事がうまくいかない。出した企画は通らないし担当した案件は数字が伸びないし頑張っているはずなのに評価される気配もない。やることなすこと空振りで自分はもうダメになったんじゃないかと夜中に天井を見つめる。そういう時期って誰にでもあると思うんですよね。\nで、そういうスランプのときに僕が自分に言い聞かせているのは成果なんて割と運で決まるんだから真に受けすぎるなということです。\n身も蓋もない話なんですけど出した成果がよかったか悪かったかって自分の実力だけで決まってるわけじゃないんですよ。たまたまタイミングがよかった、たまたま上司の機嫌がよかった、たまたま競合がコケた、たまたま景気がよかった。逆に全部が裏目に出ることもある。同じことをやっても当たる年と当たらない年があってその差の結構な部分は自分にはどうしようもない外側の要因だったりします。\nRPGで考えるとゲームの中で敵に攻撃するときどれだけ攻撃力を上げてもたまに「ミス」って出るじゃないですか。命中率が100%じゃないから強いキャラでもサイコロの目が悪ければ普通に外す。逆にへなちょこな攻撃がクリティカルでたまたま大ダメージを出すこともある。1回1回の結果はあくまで確率の上に乗っかっているだけなんです。\n成果ってまさにこれで1発の当たり外れに一喜一憂してもしょうがない。敵に負けたのは攻撃力が足りなかったからとは限らなくて単にサイコロの出目が悪かっただけかもしれない。なのにミスが3回続いただけで「自分は弱い」と決めつけてセーブデータを消そうとする。これがスランプのときの人間なんですよ。\nじゃあ何を見ればいいかというと成果じゃなくて自分の能力です。\n能力が上がっていれば命中率は確実に上がります。1発1発を見てると相変わらず外すんだけど長い目で見たときの成功率は明確に違ってくるし当たったときのダメージもデカくなる。それがわかるとちょっと外したくらいどうでもいいんだってわかります。本当に追うべきは「今回当たったか」ではなくて「自分のステータスが先月より上がっているか」なんですよね。\nここを取り違えると成果が出ない時期にひたすら自分を責めて消耗するだけで終わる。逆に能力さえ積み上がっているなら今は運の目が悪いだけだから焦る必要はまったくない。ステータス上げてればそのうち命中する回が来るし来たときのダメージもでかくなっている。\n成果はサイコロの出目次第で決まるのに対して能力は手元に積み上がっていく資産です。スランプのときに削れるのはたいてい前者で後者は黙々とやっていれば裏切らない。だからへこんだ夜は今日いくつ外したかじゃなくて今月どれだけ能力が上がったかを数えればいい。当たるのはそのあとで勝手についてきます。\n","permalink":"https://kenjiusui.github.io/blog/posts/essay/005_%E4%BB%95%E4%BA%8B%E3%81%8C%E3%81%86%E3%81%BE%E3%81%8F%E3%81%84%E3%81%8B%E3%81%AA%E3%81%84%E3%81%A8%E3%81%8D%E3%81%AF%E6%88%90%E6%9E%9C%E3%81%98%E3%82%83%E3%81%AA%E3%81%8F%E3%82%B9%E3%83%86%E3%83%BC%E3%82%BF%E3%82%B9%E3%82%92%E3%81%BF%E3%82%88%E3%81%86/","summary":"\u003cp\u003eここ最近どうにも仕事がうまくいかない。出した企画は通らないし担当した案件は数字が伸びないし頑張っているはずなのに評価される気配もない。やることなすこと空振りで自分はもうダメになったんじゃないかと夜中に天井を見つめる。そういう時期って誰にでもあると思うんですよね。\u003c/p\u003e\n\u003cp\u003eで、そういうスランプのときに僕が自分に言い聞かせているのは成果なんて割と運で決まるんだから真に受けすぎるなということです。\u003c/p\u003e\n\u003cp\u003e身も蓋もない話なんですけど出した成果がよかったか悪かったかって自分の実力だけで決まってるわけじゃないんですよ。たまたまタイミングがよかった、たまたま上司の機嫌がよかった、たまたま競合がコケた、たまたま景気がよかった。逆に全部が裏目に出ることもある。同じことをやっても当たる年と当たらない年があってその差の結構な部分は自分にはどうしようもない外側の要因だったりします。\u003c/p\u003e\n\u003cp\u003eRPGで考えるとゲームの中で敵に攻撃するときどれだけ攻撃力を上げてもたまに「ミス」って出るじゃないですか。命中率が100%じゃないから強いキャラでもサイコロの目が悪ければ普通に外す。逆にへなちょこな攻撃がクリティカルでたまたま大ダメージを出すこともある。1回1回の結果はあくまで確率の上に乗っかっているだけなんです。\u003c/p\u003e\n\u003cp\u003e成果ってまさにこれで1発の当たり外れに一喜一憂してもしょうがない。敵に負けたのは攻撃力が足りなかったからとは限らなくて単にサイコロの出目が悪かっただけかもしれない。なのにミスが3回続いただけで「自分は弱い」と決めつけてセーブデータを消そうとする。これがスランプのときの人間なんですよ。\u003c/p\u003e\n\u003cp\u003eじゃあ何を見ればいいかというと成果じゃなくて自分の能力です。\u003c/p\u003e\n\u003cp\u003e能力が上がっていれば命中率は確実に上がります。1発1発を見てると相変わらず外すんだけど長い目で見たときの成功率は明確に違ってくるし当たったときのダメージもデカくなる。それがわかるとちょっと外したくらいどうでもいいんだってわかります。本当に追うべきは「今回当たったか」ではなくて「自分のステータスが先月より上がっているか」なんですよね。\u003c/p\u003e\n\u003cp\u003eここを取り違えると成果が出ない時期にひたすら自分を責めて消耗するだけで終わる。逆に能力さえ積み上がっているなら今は運の目が悪いだけだから焦る必要はまったくない。ステータス上げてればそのうち命中する回が来るし来たときのダメージもでかくなっている。\u003c/p\u003e\n\u003cp\u003e成果はサイコロの出目次第で決まるのに対して能力は手元に積み上がっていく資産です。スランプのときに削れるのはたいてい前者で後者は黙々とやっていれば裏切らない。だからへこんだ夜は今日いくつ外したかじゃなくて今月どれだけ能力が上がったかを数えればいい。当たるのはそのあとで勝手についてきます。\u003c/p\u003e","title":"仕事がうまくいかないときは成果じゃなくステータスをみよう"},{"content":"最近つくづく思うのですが、なにか問題が起きたときに「人」に焦点を当てて話しても、ほとんど何も解決しないんですよね。\nたとえば仕事でトラブルが起きたとします。データが壊れた、リリースが遅れた、顧客が怒っている。そういうとき最初に始まるのが「誰がやったんだ」という犯人探しです。で、犯人っぽい人が見つかるとみんなでその人の落ち度を指摘して本人が謝ってなんとなく場が収まる。\nこれ、解決した気になっているだけで何も解決していないんですよね。\n正確に言うと一部の人が一瞬気持ちよくなる効果はあります。責める側は「自分はちゃんとやっている側」だと確認できて安心しますし正義を執行した満足感も得られる。でもそれだけで問題そのものは何ひとつ変わっていません。\nなぜかというとその人を責めて反省させたところで同じ構造の中に別の人を置けばだいたい同じことが起きるからです。人間の注意力とか善意とかって思っているよりずっと当てにならないし「気をつけます」「次から確認を徹底します」みたいな再発防止策が何の役にも立たないことはみんな本当は知っているはずです。\nだから議論すべきは制度とか仕組みのほうなんですよね。\nなぜそのミスが起きうる状態だったのか？チェックが人間の目視に依存していたんじゃないか？そもそも一人でやるには多すぎる作業量だったんじゃないか？間違えたらすぐ気づける仕組みがなかったんじゃないか？\nそういうシステムを直せば誰がその席に座っても同じ失敗は起きにくくなります。人を入れ替えるより仕組みを入れ替えるほうがずっと再現性があるはずなんですよね。\nこれは仕事に限った話ではなくて世の中のニュースでも同じです。不祥事のたびに特定の個人を吊るし上げて辞任なり謝罪なりで一件落着という流れをよく見かけます。あれも叩いている側がスッキリするだけで次の不祥事を防ぐ力はほぼゼロ。本当に必要なのは「なぜそれが可能だったのか」「どういうインセンティブ構造がそれを生んだのか」の検証なのですが地味で時間がかかるのであまり人気がありません。\n人を責めるのは簡単で即効性のある娯楽みたいなものです。仕組みを直すのは面倒で地味で誰の溜飲も下がらない。でも有益なのは圧倒的に後者だと思うんです。\n問題が起きたとき「誰が悪い」の話を始めそうになったら一度立ち止まって「どの仕組みが悪い」に言い換えてみる。それだけで議論の生産性はだいぶ変わるんじゃないでしょうか。\n","permalink":"https://kenjiusui.github.io/blog/posts/essay/001_%E8%AA%B0%E3%81%8C%E6%82%AA%E3%81%84%E3%81%8B%E3%81%AE%E8%A9%B1%E3%82%82%E3%81%86%E3%82%84%E3%82%81%E3%81%BE%E3%81%9B%E3%82%93%E3%81%8B/","summary":"\u003cp\u003e最近つくづく思うのですが、なにか問題が起きたときに「人」に焦点を当てて話しても、ほとんど何も解決しないんですよね。\u003c/p\u003e\n\u003cp\u003eたとえば仕事でトラブルが起きたとします。データが壊れた、リリースが遅れた、顧客が怒っている。そういうとき最初に始まるのが「誰がやったんだ」という犯人探しです。で、犯人っぽい人が見つかるとみんなでその人の落ち度を指摘して本人が謝ってなんとなく場が収まる。\u003c/p\u003e\n\u003cp\u003eこれ、解決した気になっているだけで何も解決していないんですよね。\u003c/p\u003e\n\u003cp\u003e正確に言うと一部の人が一瞬気持ちよくなる効果はあります。責める側は「自分はちゃんとやっている側」だと確認できて安心しますし正義を執行した満足感も得られる。でもそれだけで問題そのものは何ひとつ変わっていません。\u003c/p\u003e\n\u003cp\u003eなぜかというとその人を責めて反省させたところで同じ構造の中に別の人を置けばだいたい同じことが起きるからです。人間の注意力とか善意とかって思っているよりずっと当てにならないし「気をつけます」「次から確認を徹底します」みたいな再発防止策が何の役にも立たないことはみんな本当は知っているはずです。\u003c/p\u003e\n\u003cp\u003eだから議論すべきは制度とか仕組みのほうなんですよね。\u003c/p\u003e\n\u003cp\u003eなぜそのミスが起きうる状態だったのか？チェックが人間の目視に依存していたんじゃないか？そもそも一人でやるには多すぎる作業量だったんじゃないか？間違えたらすぐ気づける仕組みがなかったんじゃないか？\u003c/p\u003e\n\u003cp\u003eそういうシステムを直せば誰がその席に座っても同じ失敗は起きにくくなります。人を入れ替えるより仕組みを入れ替えるほうがずっと再現性があるはずなんですよね。\u003c/p\u003e\n\u003cp\u003eこれは仕事に限った話ではなくて世の中のニュースでも同じです。不祥事のたびに特定の個人を吊るし上げて辞任なり謝罪なりで一件落着という流れをよく見かけます。あれも叩いている側がスッキリするだけで次の不祥事を防ぐ力はほぼゼロ。本当に必要なのは「なぜそれが可能だったのか」「どういうインセンティブ構造がそれを生んだのか」の検証なのですが地味で時間がかかるのであまり人気がありません。\u003c/p\u003e\n\u003cp\u003e人を責めるのは簡単で即効性のある娯楽みたいなものです。仕組みを直すのは面倒で地味で誰の溜飲も下がらない。でも有益なのは圧倒的に後者だと思うんです。\u003c/p\u003e\n\u003cp\u003e問題が起きたとき「誰が悪い」の話を始めそうになったら一度立ち止まって「どの仕組みが悪い」に言い換えてみる。それだけで議論の生産性はだいぶ変わるんじゃないでしょうか。\u003c/p\u003e","title":"「誰が悪いか」の話、もうやめませんか"},{"content":"よくある話なんですけど、人間って大事なことを放ったらかしにして、どうでもいいところにやたらこだわるという謎の行動を取りがちなんですよね。\nたとえば仕事の場面を思い浮かべてほしんですけど、要件定義が曖昧なままなのにどのツールを使うのか何週間も議論していたり、テストもドキュメントもほったらかしにしてコードのフォーマット論争だけは異様に盛り上がったり。健康でいえば睡眠も運動もボロボロなのにサプリの銘柄だけは異様に詳しい人とか。投資ならコアの資産運用すらしていないのに個別株の短期売買の手法ばかり研究している人とか。\nこれ、別に特定の誰かが愚かとかそういう話ではなくて人間がだいたいそういうふうにできているという話です。大事なことは地味で退屈で効果が見えるまで時間がかかる。どうでもいいことは目先で楽しくて選んでいる感覚が得られる。だからみんな自然と「どうでもいいこと」に吸い寄せられるんですよね。\nで、ここからが本題なのですが、みんながそういう生き物だということは裏を返せば教科書どおりをやり抜くだけで勝ち越せるということなんですよ。\n教科書に書いてあることっていうのは、たとえば「基礎を固めてから応用に手をだす」とか「記録を取って振り返りをする」とか「スケジュールを決めて優先順位の高いものからやる」みたいなヤツ。基本的に検証済みの王道です。かっこよく言うなら再現性のある手法。\n誰でも知っているし誰でもできそうに見える。でも実際にやり抜いている人は驚くほど少ない。みんな途中で飽きて「もっといい方法があるんじゃないか」と寄り道を始めるからです。つまり競争相手のほとんどが勝手に脱落していく。王道を淡々と続けるだけで相対的に上位に入れてしまう。\nだから私は「何事も教科書どおりにやれ。教科書どおりにやれないことは教科書どおりにやれるようにしろ」という考え方が大事だと思っています。\n後半が特に重要で、教科書どおりにできないとき人は「うちは特殊だから」「自分には合わないから」と自分を例外扱いして独自路線に走りがちです。よく聞くのが「世の中は教科書どおりなんかにはならない」というセリフ。一見もっともらしいのですがあれの正体はだいたいやらない理由づくりです。\n「教科書どおりにいかないのが現実だ」と言えば、やめることを賢い判断っぽく見せられる。でも実際は教科書が間違っているのではなく続けるのに飽きてきた、地味な作業がしんどくなってきた、みたいな怠けなんですよ。\nそれに教科書どおりじゃなくても教科書どおりになるような状態を自分から作らないといけないんですよね。だって教科書的じゃない方法って上手くいくかどうかわかんないんだから。そのリスクを負うほど特殊な状況なんてほとんどないんです。時間がなくてできないなら時間を確保する仕組みを作る。スキルが足りないなら基礎から埋める。アレンジは王道を一通りやり切ってから、それでもどうにかしないといけないときの一手なんです。\nオリジナリティとか独自の工夫って聞こえはいいのですが大半は基本から逃げるための言い訳だったりします。まずは教科書どおり。地味ですがそれだけで勝てる世界が案外たくさんあるんです。\nあなたの「教科書どおりにはいかない」ってそれは本当ですか？それともやらない言い訳ですか？\n","permalink":"https://kenjiusui.github.io/blog/posts/essay/002_%E6%95%99%E7%A7%91%E6%9B%B8%E3%81%A9%E3%81%8A%E3%82%8A%E3%81%AB%E3%82%84%E3%82%8B%E3%81%A0%E3%81%91%E3%81%A7%E5%8B%9D%E3%81%A1%E8%B6%8A%E3%81%9B%E3%82%8B/","summary":"\u003cp\u003eよくある話なんですけど、人間って大事なことを放ったらかしにして、どうでもいいところにやたらこだわるという謎の行動を取りがちなんですよね。\u003c/p\u003e\n\u003cp\u003eたとえば仕事の場面を思い浮かべてほしんですけど、要件定義が曖昧なままなのにどのツールを使うのか何週間も議論していたり、テストもドキュメントもほったらかしにしてコードのフォーマット論争だけは異様に盛り上がったり。健康でいえば睡眠も運動もボロボロなのにサプリの銘柄だけは異様に詳しい人とか。投資ならコアの資産運用すらしていないのに個別株の短期売買の手法ばかり研究している人とか。\u003c/p\u003e\n\u003cp\u003eこれ、別に特定の誰かが愚かとかそういう話ではなくて人間がだいたいそういうふうにできているという話です。大事なことは地味で退屈で効果が見えるまで時間がかかる。どうでもいいことは目先で楽しくて選んでいる感覚が得られる。だからみんな自然と「どうでもいいこと」に吸い寄せられるんですよね。\u003c/p\u003e\n\u003cp\u003eで、ここからが本題なのですが、みんながそういう生き物だということは裏を返せば教科書どおりをやり抜くだけで勝ち越せるということなんですよ。\u003c/p\u003e\n\u003cp\u003e教科書に書いてあることっていうのは、たとえば「基礎を固めてから応用に手をだす」とか「記録を取って振り返りをする」とか「スケジュールを決めて優先順位の高いものからやる」みたいなヤツ。基本的に検証済みの王道です。かっこよく言うなら再現性のある手法。\u003c/p\u003e\n\u003cp\u003e誰でも知っているし誰でもできそうに見える。でも実際にやり抜いている人は驚くほど少ない。みんな途中で飽きて「もっといい方法があるんじゃないか」と寄り道を始めるからです。つまり競争相手のほとんどが勝手に脱落していく。王道を淡々と続けるだけで相対的に上位に入れてしまう。\u003c/p\u003e\n\u003cp\u003eだから私は「何事も教科書どおりにやれ。教科書どおりにやれないことは教科書どおりにやれるようにしろ」という考え方が大事だと思っています。\u003c/p\u003e\n\u003cp\u003e後半が特に重要で、教科書どおりにできないとき人は「うちは特殊だから」「自分には合わないから」と自分を例外扱いして独自路線に走りがちです。よく聞くのが「世の中は教科書どおりなんかにはならない」というセリフ。一見もっともらしいのですがあれの正体はだいたいやらない理由づくりです。\u003c/p\u003e\n\u003cp\u003e「教科書どおりにいかないのが現実だ」と言えば、やめることを賢い判断っぽく見せられる。でも実際は教科書が間違っているのではなく続けるのに飽きてきた、地味な作業がしんどくなってきた、みたいな怠けなんですよ。\u003c/p\u003e\n\u003cp\u003eそれに教科書どおりじゃなくても教科書どおりになるような状態を自分から作らないといけないんですよね。だって教科書的じゃない方法って上手くいくかどうかわかんないんだから。そのリスクを負うほど特殊な状況なんてほとんどないんです。時間がなくてできないなら時間を確保する仕組みを作る。スキルが足りないなら基礎から埋める。アレンジは王道を一通りやり切ってから、それでもどうにかしないといけないときの一手なんです。\u003c/p\u003e\n\u003cp\u003eオリジナリティとか独自の工夫って聞こえはいいのですが大半は基本から逃げるための言い訳だったりします。まずは教科書どおり。地味ですがそれだけで勝てる世界が案外たくさんあるんです。\u003c/p\u003e\n\u003cp\u003eあなたの「教科書どおりにはいかない」ってそれは本当ですか？それともやらない言い訳ですか？\u003c/p\u003e","title":"教科書どおりにやるだけで勝ち越せる"},{"content":"会議で議論がやたら噛み合わないときありますよね。お互い真剣に喋っているのにいつまでも平行線で結論が出ない。声の大きい人が押し切るかなんとなく時間切れで「じゃあ一旦持ち帰りで」みたいに終わるやつ。\nああいうとき何が起きているかというとだいたい目標・評価方法・背景のどれかが共有できていないんですよね。\n目標っていうのは「そもそも何を達成したいのか」、評価方法は「何をもって良し悪しを決めるのか」、背景は「どういう制約や前提のもとで話しているのか」という感じ。議論が詰まったときはこの3つのどれかがズレていないか確認するといいです。これ本当に驚くほど効きます。\nたとえばツールが2つあってどっちを使うかで延々と揉めているとします。よく聞いてみると片方は「開発スピードを上げたい」と思っていて、もう片方は「運用コストを下げたい」と思っている。目標が違うんだからそりゃ結論なんて出るわけがない。ここで「で、今いちばん優先したいのはどっちでしたっけ」と目標を揃えるだけで議論が一気に進んだりします。\n評価方法のズレもよくあります。同じ目標に同意していても片方は短期の数字で測ろうとしていてもう片方は長期の安定性で測ろうとしている。何を物差しにするかが違うと同じデータを見ても結論が逆になる。背景も同じで相手が知らない制約を自分だけが前提にして話しているといつまでたっても話が通じません。\nだから議論に詰まったらいったん中身の応酬をやめて「自分たちは今この3つを共有できているか」を確認したほうが早いです。中身で殴り合うより土台を揃えるほうがよっぽど生産的なんですよね。\n逆にこの3つを曖昧なまま議論を進めようとする人には気をつけたほうがいいです。\n目標も評価方法も背景もはっきりさせないまま話を進めると何が正解かが決まらないわけですね。決まらないということは声が大きい人や立場が上の人の「なんとなく」で結論を寄せられるということです。つまり土台を曖昧にしておくのは論理ではなく力で勝つための準備なんですよ。そういう人は往々にしてこちらが目標や評価方法をはっきりさせようとすると話をはぐらかしたり急に抽象的なことを言い出したりします。\n議論が進まないなーと感じたらまず3つのどれがズレているかを探す。たいていはそれだけで動き出します。それでも揃えるのを露骨に嫌がる人がいたらこれもう政治なんで議論することは諦めましょう。\n","permalink":"https://kenjiusui.github.io/blog/posts/essay/003_%E7%B5%90%E8%AB%96%E3%81%8C%E5%87%BA%E3%81%AA%E3%81%84%E4%BC%9A%E8%AD%B0%E3%81%AF%E7%9B%AE%E6%A8%99%E8%A9%95%E4%BE%A1%E8%83%8C%E6%99%AF%E3%81%AE%E3%81%A9%E3%82%8C%E3%81%8B%E3%81%8C%E3%82%BA%E3%83%AC%E3%81%A6%E3%82%8B/","summary":"\u003cp\u003e会議で議論がやたら噛み合わないときありますよね。お互い真剣に喋っているのにいつまでも平行線で結論が出ない。声の大きい人が押し切るかなんとなく時間切れで「じゃあ一旦持ち帰りで」みたいに終わるやつ。\u003c/p\u003e\n\u003cp\u003eああいうとき何が起きているかというとだいたい目標・評価方法・背景のどれかが共有できていないんですよね。\u003c/p\u003e\n\u003cp\u003e目標っていうのは「そもそも何を達成したいのか」、評価方法は「何をもって良し悪しを決めるのか」、背景は「どういう制約や前提のもとで話しているのか」という感じ。議論が詰まったときはこの3つのどれかがズレていないか確認するといいです。これ本当に驚くほど効きます。\u003c/p\u003e\n\u003cp\u003eたとえばツールが2つあってどっちを使うかで延々と揉めているとします。よく聞いてみると片方は「開発スピードを上げたい」と思っていて、もう片方は「運用コストを下げたい」と思っている。目標が違うんだからそりゃ結論なんて出るわけがない。ここで「で、今いちばん優先したいのはどっちでしたっけ」と目標を揃えるだけで議論が一気に進んだりします。\u003c/p\u003e\n\u003cp\u003e評価方法のズレもよくあります。同じ目標に同意していても片方は短期の数字で測ろうとしていてもう片方は長期の安定性で測ろうとしている。何を物差しにするかが違うと同じデータを見ても結論が逆になる。背景も同じで相手が知らない制約を自分だけが前提にして話しているといつまでたっても話が通じません。\u003c/p\u003e\n\u003cp\u003eだから議論に詰まったらいったん中身の応酬をやめて「自分たちは今この3つを共有できているか」を確認したほうが早いです。中身で殴り合うより土台を揃えるほうがよっぽど生産的なんですよね。\u003c/p\u003e\n\u003cp\u003e逆にこの3つを曖昧なまま議論を進めようとする人には気をつけたほうがいいです。\u003c/p\u003e\n\u003cp\u003e目標も評価方法も背景もはっきりさせないまま話を進めると何が正解かが決まらないわけですね。決まらないということは声が大きい人や立場が上の人の「なんとなく」で結論を寄せられるということです。つまり土台を曖昧にしておくのは論理ではなく力で勝つための準備なんですよ。そういう人は往々にしてこちらが目標や評価方法をはっきりさせようとすると話をはぐらかしたり急に抽象的なことを言い出したりします。\u003c/p\u003e\n\u003cp\u003e議論が進まないなーと感じたらまず3つのどれがズレているかを探す。たいていはそれだけで動き出します。それでも揃えるのを露骨に嫌がる人がいたらこれもう政治なんで議論することは諦めましょう。\u003c/p\u003e","title":"結論が出ない会議は目標・評価・背景のどれかがズレてる"},{"content":"3.1 データ分析基盤の核心 データ分析基盤が従来システムと根本的に異なるのは「一元化」と「自動化」という2つの核心的な特徴にあります。\n一元化による統合的なデータ管理 従来は各部門で個別にデータが管理されていましたが、データ分析基盤では全社のデータを一箇所に統合します。この一元化により、これまで不可能だった部門を横断した分析が日常的に実行できるようになります。\n一元化の価値は単にデータを集めるということだけではありません。データのフォーマットを標準化し、マスターデータを整備することも重要です。例えば日付の形式やタイムゾーン、通貨などシステムによる細かな差異は分析の効率を下げ、ときには間違った分析の原因となります。\nさまざまな指標の集計定義を統一することも一元化の要素の1つです。「売上」という指標について経営と営業と開発が異なる計算方法を使っているような状況はよくあることです。データ分析基盤をとおして集計の定義を統一することで誰が見ても同じ数値になります。これにより意思決定時のコミュニケーションがスムーズになると同時に意思決定の精度が改善されます。\n自動化による継続的な処理 データ分析基盤のもう一つの核心は処理の自動化です。従来であれば一部のレポートが自動化されている程度に限られており少なくない月次集計や週次レポート作成が手動である状況は珍しくありません。データ分析基盤を活用することで自動化し人的ミスの排除と処理時間の大幅短縮を実現できます。\n自動化は単に作業効率を向上させるだけでなくデータの鮮度を大きく改善します。手動で更新している場合だと毎日作業するのは簡単ではありませんがシステムで自動化していれば高い頻度で更新可能です。日次でデータを更新すれば業務の改善サイクルを高速に回すことが可能になります。リアルタイムなデータ連携によって広告や商品をリリースした数刻後には定量的な効果を検証することも可能でしょう。\nまた自動化により処理の一貫性も確保します。各々が手作業で処理していると意図しないミスや認識のズレが起きるものです。データ分析基盤をとおして自動化することで担当者による処理方法の違いや手作業による計算ミスといった問題が解決されます。\n3.2 一元化と自動化を実現する4つの要素 一元化と自動化は、以下の4つの要素が連携することで実現されます。この4つの要素を通ることで生データのデータから前処理されたキレイなデータとなり分析結果へ加工されます。そして最終的に意思決定に役立つ情報として提供されるのです。\n収集 データを分析するためには当然ですがデータ分析基盤へデータを流し込む必要があります。このプロセスでは社内の各業務システムや外部サービスからデータを取得しデータ分析基盤へ保存します。\n販売管理システムのCSVファイル、Webサイトのアクセスログ、SaaSのAPIから取得するJSONなど内容も形式も取得方法も異なる多様なデータを収集します。データを分析基盤へ一元化するために重要なプロセスです。\n蓄積 収集したデータを効率的に保管します。全社のデータを共通のルールで保存し、後の処理で高速にアクセスできるよう最適化された形で蓄積します。\nデータの蓄積と管理はデータの品質や処理の速度に直結します。適切な方法でデータを貯めていくためにも、どのようにデータを利用するのか想定し戦略的に進めることが必要です。\n処理 保存されたデータを分析に適した形に変換します。生のデータからきれいなデータ、そして分析へと加工していきます。データ分析基盤で加工プロセスを自動化することによって効率よく一貫した品質のデータを継続的に生成させることができます。\n大量のデータを処理するという計算量の多さはもちろん問題になりますが、それ以上に計算ロジックや依存関係を実装していく難しさがあります。用途に応じて多様な処理を実装が求められますしビジネスの変化によって柔軟な対応も必要となります。一方で間違った分析をしないように堅実な構築であることも重要です。また、データを加工するだけでなくデータの不整合の修正や異なるシステムの間での標準化などもすべき要素です。\n提供 処理済みのデータを分析者が利用できる形で提供します。ダッシュボード、レポート、分析ツールなど、利用者のニーズに応じた様々な形でデータが自動的に出力されます。\nデータの活用が進めば進むほど多様なメンバーがデータを活用するようになります。利用者が円滑にデータを利用できるようツールの導入や権限の管理、利用方法の教育などの利用する環境を構築していくことが必要です。\n3.3 構築から運用への道のり データ分析基盤の構築は一朝一夕では完成しません。段階的なアプローチにより確実に価値を積み重ねていくことが重要です。\n第1段階：基礎固め（最初の3-6ヶ月）\nまず既存の重要なデータソースを特定し基本的な3層アーキテクチャを構築します。すべてのデータを一度に取り込もうとせず売上データと顧客データなど最も価値の高い2-3個のデータソースから開始します。完璧を目指さず「動くもの」を早期に構築し実際にデータを流して分析してみることで成果を生み出しながら課題を発見します。\n第2段階：拡張（6ヶ月-1年）\n基本機能が安定稼働した後は対象データソースを段階的に拡大します。データソースを増やすことで分析できるチームが増えるほか、横断的な分析がおこなえるようになります。\nあわせて、データの活用を広げることを視野に入れて多くの人が自力で分析できるような環境の構築にも力を入れます。BIツールの導入・データカタログの整備・トレーニングの実施により、いわゆる「データの民主化」を目指します。\n第3段階：最適化と管理（1年以降）\nシステムが安定し利用者が増加した段階でシステムの最適化をおこないます。処理性能の改善やコスト最適化、効率的な分析をおこなえるようにデータマートなどの構築をしていきます。\nまた利用者の増加にあわせてデータガバナンス体制を強化します。多くの人が安全に分析できるような環境を構築することで長期的な運用に備えます。\n成功の鍵：小さく始めて大きく育てる\n多くの企業がデータ分析基盤の構築で失敗する理由は「完璧なシステムを一度に作ろうとする」ことです。最初から全部門・全データを対象とした大規模システムを構築しようとすると要件が複雑になりプロジェクトが破綻するリスクが高まります。\n成功するプロジェクトは「小さく始めて大きく育てる」アプローチを採用します。限定的な範囲で確実に価値を実証し段階的に拡大していく方法により失敗リスクを最小限に抑えながら着実に成果を積み重ねられます。\n成功の鍵：継続的な改善\nデータ分析基盤は一度構築して終わりではありません。ビジネス環境の変化・新しい分析ニーズ・技術の進歩に応じて継続的に改善していく必要があります。定期的なシステム見直し・フィードバックの収集・新技術の検証を通じて常に最適な状態を維持しましょう。また組織の成長に合わせてシステムもスケールアップしていくことが重要です。\nこの章ではデータ分析基盤がどのような要素から成り立っているのか解説しました。次の章から具体的にデータ分析基盤を解説していきます。まずはデータの保存・管理の基本的な考え方と定番の3層構造について紹介しましょう。\n","permalink":"https://kenjiusui.github.io/blog/books/data-platform-intro/03_overview_architecture/","summary":"\u003ch2 id=\"31-データ分析基盤の核心\"\u003e3.1 データ分析基盤の核心\u003c/h2\u003e\n\u003cp\u003eデータ分析基盤が従来システムと根本的に異なるのは「一元化」と「自動化」という2つの核心的な特徴にあります。\u003c/p\u003e\n\u003ch3 id=\"一元化による統合的なデータ管理\"\u003e一元化による統合的なデータ管理\u003c/h3\u003e\n\u003cp\u003e従来は各部門で個別にデータが管理されていましたが、データ分析基盤では全社のデータを一箇所に統合します。この一元化により、これまで不可能だった部門を横断した分析が日常的に実行できるようになります。\u003c/p\u003e\n\u003cp\u003e一元化の価値は単にデータを集めるということだけではありません。データのフォーマットを標準化し、マスターデータを整備することも重要です。例えば日付の形式やタイムゾーン、通貨などシステムによる細かな差異は分析の効率を下げ、ときには間違った分析の原因となります。\u003c/p\u003e\n\u003cp\u003eさまざまな指標の集計定義を統一することも一元化の要素の1つです。「売上」という指標について経営と営業と開発が異なる計算方法を使っているような状況はよくあることです。データ分析基盤をとおして集計の定義を統一することで誰が見ても同じ数値になります。これにより意思決定時のコミュニケーションがスムーズになると同時に意思決定の精度が改善されます。\u003c/p\u003e\n\u003ch3 id=\"自動化による継続的な処理\"\u003e自動化による継続的な処理\u003c/h3\u003e\n\u003cp\u003eデータ分析基盤のもう一つの核心は処理の自動化です。従来であれば一部のレポートが自動化されている程度に限られており少なくない月次集計や週次レポート作成が手動である状況は珍しくありません。データ分析基盤を活用することで自動化し人的ミスの排除と処理時間の大幅短縮を実現できます。\u003c/p\u003e\n\u003cp\u003e自動化は単に作業効率を向上させるだけでなくデータの鮮度を大きく改善します。手動で更新している場合だと毎日作業するのは簡単ではありませんがシステムで自動化していれば高い頻度で更新可能です。日次でデータを更新すれば業務の改善サイクルを高速に回すことが可能になります。リアルタイムなデータ連携によって広告や商品をリリースした数刻後には定量的な効果を検証することも可能でしょう。\u003c/p\u003e\n\u003cp\u003eまた自動化により処理の一貫性も確保します。各々が手作業で処理していると意図しないミスや認識のズレが起きるものです。データ分析基盤をとおして自動化することで担当者による処理方法の違いや手作業による計算ミスといった問題が解決されます。\u003c/p\u003e\n\u003ch2 id=\"32-一元化と自動化を実現する4つの要素\"\u003e3.2 一元化と自動化を実現する4つの要素\u003c/h2\u003e\n\u003cp\u003e一元化と自動化は、以下の4つの要素が連携することで実現されます。この4つの要素を通ることで生データのデータから前処理されたキレイなデータとなり分析結果へ加工されます。そして最終的に意思決定に役立つ情報として提供されるのです。\u003c/p\u003e\n\u003ch3 id=\"収集\"\u003e収集\u003c/h3\u003e\n\u003cp\u003eデータを分析するためには当然ですがデータ分析基盤へデータを流し込む必要があります。このプロセスでは社内の各業務システムや外部サービスからデータを取得しデータ分析基盤へ保存します。\u003c/p\u003e\n\u003cp\u003e販売管理システムのCSVファイル、Webサイトのアクセスログ、SaaSのAPIから取得するJSONなど内容も形式も取得方法も異なる多様なデータを収集します。データを分析基盤へ一元化するために重要なプロセスです。\u003c/p\u003e\n\u003ch3 id=\"蓄積\"\u003e蓄積\u003c/h3\u003e\n\u003cp\u003e収集したデータを効率的に保管します。全社のデータを共通のルールで保存し、後の処理で高速にアクセスできるよう最適化された形で蓄積します。\u003c/p\u003e\n\u003cp\u003eデータの蓄積と管理はデータの品質や処理の速度に直結します。適切な方法でデータを貯めていくためにも、どのようにデータを利用するのか想定し戦略的に進めることが必要です。\u003c/p\u003e\n\u003ch3 id=\"処理\"\u003e処理\u003c/h3\u003e\n\u003cp\u003e保存されたデータを分析に適した形に変換します。生のデータからきれいなデータ、そして分析へと加工していきます。データ分析基盤で加工プロセスを自動化することによって効率よく一貫した品質のデータを継続的に生成させることができます。\u003c/p\u003e\n\u003cp\u003e大量のデータを処理するという計算量の多さはもちろん問題になりますが、それ以上に計算ロジックや依存関係を実装していく難しさがあります。用途に応じて多様な処理を実装が求められますしビジネスの変化によって柔軟な対応も必要となります。一方で間違った分析をしないように堅実な構築であることも重要です。また、データを加工するだけでなくデータの不整合の修正や異なるシステムの間での標準化などもすべき要素です。\u003c/p\u003e\n\u003ch3 id=\"提供\"\u003e提供\u003c/h3\u003e\n\u003cp\u003e処理済みのデータを分析者が利用できる形で提供します。ダッシュボード、レポート、分析ツールなど、利用者のニーズに応じた様々な形でデータが自動的に出力されます。\u003c/p\u003e\n\u003cp\u003eデータの活用が進めば進むほど多様なメンバーがデータを活用するようになります。利用者が円滑にデータを利用できるようツールの導入や権限の管理、利用方法の教育などの利用する環境を構築していくことが必要です。\u003c/p\u003e\n\u003ch2 id=\"33-構築から運用への道のり\"\u003e3.3 構築から運用への道のり\u003c/h2\u003e\n\u003cp\u003eデータ分析基盤の構築は一朝一夕では完成しません。段階的なアプローチにより確実に価値を積み重ねていくことが重要です。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第1段階：基礎固め（最初の3-6ヶ月）\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eまず既存の重要なデータソースを特定し基本的な3層アーキテクチャを構築します。すべてのデータを一度に取り込もうとせず売上データと顧客データなど最も価値の高い2-3個のデータソースから開始します。完璧を目指さず「動くもの」を早期に構築し実際にデータを流して分析してみることで成果を生み出しながら課題を発見します。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第2段階：拡張（6ヶ月-1年）\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e基本機能が安定稼働した後は対象データソースを段階的に拡大します。データソースを増やすことで分析できるチームが増えるほか、横断的な分析がおこなえるようになります。\u003c/p\u003e\n\u003cp\u003eあわせて、データの活用を広げることを視野に入れて多くの人が自力で分析できるような環境の構築にも力を入れます。BIツールの導入・データカタログの整備・トレーニングの実施により、いわゆる「データの民主化」を目指します。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第3段階：最適化と管理（1年以降）\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eシステムが安定し利用者が増加した段階でシステムの最適化をおこないます。処理性能の改善やコスト最適化、効率的な分析をおこなえるようにデータマートなどの構築をしていきます。\u003c/p\u003e\n\u003cp\u003eまた利用者の増加にあわせてデータガバナンス体制を強化します。多くの人が安全に分析できるような環境を構築することで長期的な運用に備えます。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e成功の鍵：小さく始めて大きく育てる\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e多くの企業がデータ分析基盤の構築で失敗する理由は「完璧なシステムを一度に作ろうとする」ことです。最初から全部門・全データを対象とした大規模システムを構築しようとすると要件が複雑になりプロジェクトが破綻するリスクが高まります。\u003c/p\u003e\n\u003cp\u003e成功するプロジェクトは「小さく始めて大きく育てる」アプローチを採用します。限定的な範囲で確実に価値を実証し段階的に拡大していく方法により失敗リスクを最小限に抑えながら着実に成果を積み重ねられます。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e成功の鍵：継続的な改善\u003c/strong\u003e\u003cbr\u003e\nデータ分析基盤は一度構築して終わりではありません。ビジネス環境の変化・新しい分析ニーズ・技術の進歩に応じて継続的に改善していく必要があります。定期的なシステム見直し・フィードバックの収集・新技術の検証を通じて常に最適な状態を維持しましょう。また組織の成長に合わせてシステムもスケールアップしていくことが重要です。\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003eこの章ではデータ分析基盤がどのような要素から成り立っているのか解説しました。次の章から具体的にデータ分析基盤を解説していきます。まずはデータの保存・管理の基本的な考え方と定番の3層構造について紹介しましょう。\u003c/p\u003e","title":"データ分析基盤の全体像"},{"content":"前回はNISAとiDeCoという制度をどう活用するかという話をしました。\nここからは「投資を始めたあと」の話に入ります。\n資産運用をするとき資産を投資する割合を決めてその割合で買うのが一般的です。\nしかし、買った資産のバランスは市場の変化にともなって時間とともに自然にズレていきます。\nこのズレを元に戻す作業が「リバランス」です。\n今回はリバランスの目的と実践的な進め方について整理します。\n配分は放っておくと崩れる 株式と債券は値動きが異なるため同じ配分で投資を始めても時間が経つにつれて比率は変わっていきます。\n市場が成長していれば株式の方がリターンは大きいので株式の割合が自然と高まります。\nたとえば株式70%・債券30%で始めたとしても、数年後には株式80%・債券20%といった配分になっていることがあります。\nもちろん逆のケースもあります。\n暴落後は株式の比率が下がりすぎて株式60%・債券40%となっているかもしれません。\nバランスがズレているということは当初の試算に対してリターンとリスクが崩れているということになります。\n株式の比率が高まっていればリスクを取りすぎている状態に無自覚のままなっているということです。\n逆に暴落して債券比率が高いままでは本来取れるはずのリターンを取り損ねる配分になっているといえます。\nリバランスはこのズレた比率を元の配分に戻す作業のことです。\n増えすぎた株式を売却して債券を買い増す、逆に債券を売って減った株式を買うということですね。\n比率を正してリターンとリスクを正常化します。\nこれは結果として「値上がりした資産を売り、値下がりした資産を買う」ことになります。\nつまり機械的に高値売り・安値買いを実行しているわけですね。\nここで重要なのはリバランスは別に相場を見て判断しているわけではないという点です。\nあらかじめ決めた資産の比率というルールに従って淡々と動くだけです。\n感情に左右されずに済むことがリバランスの最大のメリットになります。\n「相場ではなくシンプルなルールに従って取引できる」というのは投資を続けるにあたって非常に重要です。\n暴落時に相場を見て狼狽してしまうという状態を避けることにつながるためです。\n人は相場が上がれば「もっと伸びるのではないか？」と欲がでる生き物です。\n一方で下がれば「まだ下がるのではないか？」と不安になります。\nその場の判断に任せているとこの心理に流されてしまい利益を逃したり損失を拡大してしまいます。\nあらかじめ決めたルールに従って機械的に取引することで判断のブレを排除できます。\nルールを決めて淡々と守り続けることが長期的な利益に結びつくのです。\nリバランスの手法：売買と新規資金 さて、実際にリバランスのやり方について見ていきましょう。\nリバランスには大きく2つの方法があります。\n方法1: 増えすぎた資産を売って減った資産を買う\nバランスが崩れたうち多い方を売って少ない方を買うということですね。\n一般にリバランスというとこちらを指すことが多いでしょう。\n直感的にも理解しやすいのではないかとおもいます。\nこの方法は王道であり基本的にはリバランスこの方法で行うと考えてよいでしょう。\n課税口座の場合は売却益に課税されるという点は注意が必要です。\nNISA枠でも一度売却すると枠の再利用には年間・生涯それぞれに制限があるため単純にやり直せるわけではありません。\n（NISAは購入時の金額なので利益がでてから再購入するともったいないのです）\nそのため、可能であれば方法2を使うとよいでしょう。\n税金が勿体ないからリバランスしないという人をたまに見かけますが、それはリスクとリターンのバランスを崩して資産を危険な状態にしておくほどの価値があるのでしょうか？\n利益に冷静さを失って間違った判断をしていないか落ち着いて考え直すべきです。\n方法2: 新規の入金・積立分を比率が減っている資産に多めに振り分ける\n手持ちの新規の資金や待機資金で購入する際にバランスを整えるように購入するという方向です。\n株価が上がっていれば債券を多めに買い、株価が下がっていたら株式を多めに買うという感じですね。\nこの方法は売却を伴わないため含み益への課税を避けることができます。\n投資していない資金が必要なため誰でもできる方法ではありませんが税金がかからないというのは大きなメリットです。\nボーナスや積立などの新規資金があるならばこの方法を検討するのがよいでしょう。\nとはいえ、新規の資金には限界があります。\n資産全体が少額であったり、ちょっとしたバランスのズレには便利ですが大きなズレには向きません。\n大きく配分がズレたときは売買による調整を検討しましょう。\nタイミングの目安 リバランスの方法がわかったところで、次はいつ行うべきか考えてみましょう。\nリバランスを行うタイミングには大きく2つの考え方があります。\n頻度による方法: 年1回など期間を決めて見直す 乖離率による方法: 比率から一定割合ズレたら調整する この点についてVanguardが1926年から2014年までのデータを用いた検証があります。\n頻度と乖離率のさまざまな組み合わせでのリターンとリスクについてシミュレーションしており、頻度や乖離率の基準を変えても大きな差がないという結果でした。\nVanguardは多くの分散されたポートフォリオにおいて「年1回または半年に1回のモニタリングと5%の乖離閾値」の組み合わせがリスク管理とコストのバランスとして妥当である、と結論づけています。\n出典: Vanguard \u0026ldquo;Best practices for portfolio rebalancing\u0026rdquo;\n筆者自身の体感としても違和感ないので、このルールを採用しています。\nリバランスは重要とはいえやはり面倒ですから頻繁にやらなくていいのは楽で良いですね。\nまとめ 投資した資産の配分は放置すれば自然にズレていきます。\nリバランスはそのズレを戻して当初のリスク水準を保つための作業です。\n大事なのはとにかく定期的にリバランスすることです。\nあらかじめルールを決めて感情に左右されず淡々と続けることが重要です。\nリバランスで健全な資産運用を心がけましょう！\n","permalink":"https://kenjiusui.github.io/blog/posts/finance/006_%E8%B3%87%E7%94%A3%E9%81%8B%E7%94%A8%E3%81%A8%E3%83%AA%E3%83%90%E3%83%A9%E3%83%B3%E3%82%B9/","summary":"\u003cp\u003e前回はNISAとiDeCoという制度をどう活用するかという話をしました。\u003c/p\u003e\n\u003cp\u003eここからは「投資を始めたあと」の話に入ります。\u003c/p\u003e\n\u003cp\u003e資産運用をするとき資産を投資する割合を決めてその割合で買うのが一般的です。\u003cbr\u003e\nしかし、買った資産のバランスは市場の変化にともなって時間とともに自然にズレていきます。\u003cbr\u003e\nこのズレを元に戻す作業が「リバランス」です。\u003cbr\u003e\n今回はリバランスの目的と実践的な進め方について整理します。\u003c/p\u003e\n\u003ch2 id=\"配分は放っておくと崩れる\"\u003e配分は放っておくと崩れる\u003c/h2\u003e\n\u003cp\u003e株式と債券は値動きが異なるため同じ配分で投資を始めても時間が経つにつれて比率は変わっていきます。\u003cbr\u003e\n市場が成長していれば株式の方がリターンは大きいので株式の割合が自然と高まります。\u003cbr\u003e\nたとえば株式70%・債券30%で始めたとしても、数年後には株式80%・債券20%といった配分になっていることがあります。\u003c/p\u003e\n\u003cp\u003eもちろん逆のケースもあります。\u003cbr\u003e\n暴落後は株式の比率が下がりすぎて株式60%・債券40%となっているかもしれません。\u003c/p\u003e\n\u003cp\u003eバランスがズレているということは当初の試算に対してリターンとリスクが崩れているということになります。\u003cbr\u003e\n株式の比率が高まっていればリスクを取りすぎている状態に無自覚のままなっているということです。\u003cbr\u003e\n逆に暴落して債券比率が高いままでは本来取れるはずのリターンを取り損ねる配分になっているといえます。\u003c/p\u003e\n\u003cp\u003eリバランスはこのズレた比率を元の配分に戻す作業のことです。\u003cbr\u003e\n増えすぎた株式を売却して債券を買い増す、逆に債券を売って減った株式を買うということですね。\u003cbr\u003e\n比率を正してリターンとリスクを正常化します。\u003c/p\u003e\n\u003cp\u003eこれは結果として「値上がりした資産を売り、値下がりした資産を買う」ことになります。\u003cbr\u003e\nつまり機械的に高値売り・安値買いを実行しているわけですね。\u003c/p\u003e\n\u003cp\u003eここで重要なのはリバランスは別に相場を見て判断しているわけではないという点です。\u003cbr\u003e\nあらかじめ決めた資産の比率というルールに従って淡々と動くだけです。\u003cbr\u003e\n感情に左右されずに済むことがリバランスの最大のメリットになります。\u003c/p\u003e\n\u003cp\u003e「相場ではなくシンプルなルールに従って取引できる」というのは投資を続けるにあたって非常に重要です。\u003cbr\u003e\n暴落時に相場を見て狼狽してしまうという状態を避けることにつながるためです。\u003cbr\u003e\n人は相場が上がれば「もっと伸びるのではないか？」と欲がでる生き物です。\u003cbr\u003e\n一方で下がれば「まだ下がるのではないか？」と不安になります。\u003cbr\u003e\nその場の判断に任せているとこの心理に流されてしまい利益を逃したり損失を拡大してしまいます。\u003cbr\u003e\nあらかじめ決めたルールに従って機械的に取引することで判断のブレを排除できます。\u003cbr\u003e\nルールを決めて淡々と守り続けることが長期的な利益に結びつくのです。\u003c/p\u003e\n\u003ch2 id=\"リバランスの手法売買と新規資金\"\u003eリバランスの手法：売買と新規資金\u003c/h2\u003e\n\u003cp\u003eさて、実際にリバランスのやり方について見ていきましょう。\u003cbr\u003e\nリバランスには大きく2つの方法があります。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e方法1: 増えすぎた資産を売って減った資産を買う\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eバランスが崩れたうち多い方を売って少ない方を買うということですね。\u003cbr\u003e\n一般にリバランスというとこちらを指すことが多いでしょう。\u003cbr\u003e\n直感的にも理解しやすいのではないかとおもいます。\u003cbr\u003e\nこの方法は王道であり基本的にはリバランスこの方法で行うと考えてよいでしょう。\u003c/p\u003e\n\u003cp\u003e課税口座の場合は売却益に課税されるという点は注意が必要です。\u003cbr\u003e\nNISA枠でも一度売却すると枠の再利用には年間・生涯それぞれに制限があるため単純にやり直せるわけではありません。\u003cbr\u003e\n（NISAは\u003cstrong\u003e購入時\u003c/strong\u003eの金額なので利益がでてから再購入するともったいないのです）\u003cbr\u003e\nそのため、可能であれば方法2を使うとよいでしょう。\u003c/p\u003e\n\u003cp\u003e税金が勿体ないからリバランスしないという人をたまに見かけますが、それはリスクとリターンのバランスを崩して資産を危険な状態にしておくほどの価値があるのでしょうか？\u003cbr\u003e\n利益に冷静さを失って間違った判断をしていないか落ち着いて考え直すべきです。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e方法2: 新規の入金・積立分を比率が減っている資産に多めに振り分ける\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e手持ちの新規の資金や待機資金で購入する際にバランスを整えるように購入するという方向です。\u003cbr\u003e\n株価が上がっていれば債券を多めに買い、株価が下がっていたら株式を多めに買うという感じですね。\u003cbr\u003e\nこの方法は売却を伴わないため含み益への課税を避けることができます。\u003c/p\u003e\n\u003cp\u003e投資していない資金が必要なため誰でもできる方法ではありませんが税金がかからないというのは大きなメリットです。\u003cbr\u003e\nボーナスや積立などの新規資金があるならばこの方法を検討するのがよいでしょう。\u003c/p\u003e\n\u003cp\u003eとはいえ、新規の資金には限界があります。\u003cbr\u003e\n資産全体が少額であったり、ちょっとしたバランスのズレには便利ですが大きなズレには向きません。\u003cbr\u003e\n大きく配分がズレたときは売買による調整を検討しましょう。\u003c/p\u003e\n\u003ch2 id=\"タイミングの目安\"\u003eタイミングの目安\u003c/h2\u003e\n\u003cp\u003eリバランスの方法がわかったところで、次はいつ行うべきか考えてみましょう。\u003cbr\u003e\nリバランスを行うタイミングには大きく2つの考え方があります。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e頻度による方法\u003c/strong\u003e: 年1回など期間を決めて見直す\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e乖離率による方法\u003c/strong\u003e: 比率から一定割合ズレたら調整する\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eこの点についてVanguardが1926年から2014年までのデータを用いた検証があります。\u003cbr\u003e\n頻度と乖離率のさまざまな組み合わせでのリターンとリスクについてシミュレーションしており、頻度や乖離率の基準を変えても大きな差がないという結果でした。\u003cbr\u003e\nVanguardは多くの分散されたポートフォリオにおいて「年1回または半年に1回のモニタリングと5%の乖離閾値」の組み合わせがリスク管理とコストのバランスとして妥当である、と結論づけています。\u003c/p\u003e\n\u003cp\u003e出典: \u003ca href=\"https://www.financieelonafhankelijkblog.nl/wp-content/uploads/2021/11/Vanguard-ISGPORE.pdf\"\u003eVanguard \u0026ldquo;Best practices for portfolio rebalancing\u0026rdquo;\u003c/a\u003e\u003c/p\u003e","title":"資産運用とリバランス"},{"content":"前回は投資する資金をどうやって投じるかという話を書きました。\n投資額と投資方法が決まったら次に考えるのがその資金をどの制度に入れるかという問題です。\nNISAとiDeCoという2つの非課税制度がありますがどちらを優先すればいいのか迷う人は多いはずです。\n今回はこの2つの違いを整理したうえで優先順位の考え方を書いていきます。\n注意\n今回はわかりやすさを重視して一般的な会社員を想定して細かい説明を省いて書いています。\nあくまでイメージですので気になる人はちゃんと調べたり計算してくださいね。\n違いは「自由度」と「節税の強さ」のトレードオフ NISAとiDeCoの違いは一言でいえば自由度と節税の強さのトレードオフです。\nNISA\n引き出しはいつでも可能（老後・住宅・教育など自由に使える） 非課税になるのは運用益のみ iDeCo\n引き出しは原則60歳まで不可（実質老後資金に限られる） 非課税になるのは拠出時・運用益・受け取り時の3つ NISAはいつでも引き出せる代わりに非課税になるのは運用益のみです。\niDeCoは60歳まで引き出せない代わりに非課税になるタイミングが拠出時・運用益・受け取り時の3つあります。\n自由度を取るか節税の強さを取るか、というのがこの2つの制度の本質的な違いです。\n節税の強さだけならiDeCoが勝つ 税制優遇とそこから得られるリターンの大きさを比べるとiDeCoのほうが強力です。\n拠出時は掛金が全額所得控除の対象になり拠出した時点でその年の所得税と住民税が下がります。\n下がった税金の分だけ確定したリターン（単利）が返ってくるともいえるでしょう。\n戻ってきた税金分はNISAなどで再投資に回せるので実質的に元本が増えることになります。\n資産運用は長期投資なので元本の違いは長期的なリターンに大きな違いを産みます。\nまた、受け取り時は退職所得控除の対象になり加入期間に応じた一定額まで非課税になります。\n超過分には課税されますがそれでも退職所得は優遇の大きい仕組みなので税額はかなり抑えられます。\n節税効果とリターンという観点ではiDeCoが使えるなら使わない理由はないというのが結論です。\nそれくらいiDeCoは強力な制度なのです。\nただし60歳まで引き出せない とはいえiDeCoには大きな制約があります。\n一度拠出したお金は原則60歳まで引き出せないということです。\nこれは生活防衛資金や近い将来使う予定のあるお金の話と直結します。\n急な出費が必要になったときにiDeCoに入れた資金は使うことができません。\nどれだけ節税効果が大きくても目の前の生活が苦しくなってしまっては本末転倒です。\nNISAであれば必要なときにいつでも引き出せるためこうした心配がありません。\nまた、iDeCoは一度に入金できる金額に厳しい制限があります。\n1ヶ月に数万円程度しか入金できないのでまとまった金額を即座に運用できません。\nそのため、歳を取ってから一気に拠出するという使い方ができず若いうちから継続的に拠出する必要があります。\n一方、NISAは1年に360万円、5年で1800万円まで入金できますので個人の資産運用としては十分な金額を短い期間で投資することができます。\nNISAとiDeCoは節税効果の大きさと資金の自由度の低さにおいて表裏一体の関係にあるということです。\n優先順位は入金力で決める ではNISAとiDeCoどちらから始めればいいのでしょうか。\n考え方としては自分の資産や収入、つまり拠出できる金額によって決めるのがよいでしょう。\n資産に余裕があるならばiDeCoに入れる金額をシミュレーションして計算して拠出し、それ以外をNISAに入れるというのが理想です。\n老後に必要な金額をまず見積もってから逆算して毎月の拠出金額を決めるとよいでしょう。\n老後まで使わないと決められる資金があるならば資金拘束はデメリットになりません。\niDeCoの節税効果は優秀なので老後の資産形成としてはなるべくiDeCoを活用したいです。\n一方で、投資に回せる資金に余裕がない段階であればまずはNISAから始めるのがよいとおもいます。\n不測の事態や60歳までのイベントに対応できなくなるリスクを回避するほうが重要だからです。\n節税効果が高いからといっても受け取れるのは老後ですので偏ってしまっては意味がありません。\nまずはNISAで投資をして資産を増やしながら余裕ができたらiDeCoを使い始めて資産運用を加速させるのがよいでしょう。\n重要なポイントとして、iDeCoの節税できる機会は後から取り戻すことができません。\n年金のように後から追納するようなことができないからです。\n入金力があるのに後回しにすればするほど本来受け取れたはずの控除を逃し続けることになります。\n可能ならばiDeCoの利用を早めに検討しましょう。\nまとめ NISAとiDeCoの違いは自由度と節税の強さのトレードオフになっています。\niDeCoの節税効果は強力なので使えるならなるべく使うべきです。\nただし資金拘束があるため老後資金として切り離せるだけの余力が必要になります。\nそのため、まだ入金力に余裕がなければ自由度の高いNISAから始めるという選択肢もでてきます。\nNISAもiDeCoも強力な制度です。\n自分が今どのように利用すると効果的なのか検討して制度を活用しましょう！\n次回は投資したあとの話、運用中の心構えとリバランスについて解説します。\n","permalink":"https://kenjiusui.github.io/blog/posts/finance/005_nisa%E3%81%A8ideco%E3%81%A9%E3%81%A1%E3%82%89%E3%82%92%E5%84%AA%E5%85%88%E3%81%99%E3%81%B9%E3%81%8D%E3%81%8B/","summary":"\u003cp\u003e前回は投資する資金をどうやって投じるかという話を書きました。\u003cbr\u003e\n投資額と投資方法が決まったら次に考えるのがその資金をどの制度に入れるかという問題です。\u003cbr\u003e\nNISAとiDeCoという2つの非課税制度がありますがどちらを優先すればいいのか迷う人は多いはずです。\u003cbr\u003e\n今回はこの2つの違いを整理したうえで優先順位の考え方を書いていきます。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e注意\u003c/strong\u003e\u003cbr\u003e\n今回はわかりやすさを重視して一般的な会社員を想定して細かい説明を省いて書いています。\u003cbr\u003e\nあくまでイメージですので気になる人はちゃんと調べたり計算してくださいね。\u003c/p\u003e\n\u003ch2 id=\"違いは自由度と節税の強さのトレードオフ\"\u003e違いは「自由度」と「節税の強さ」のトレードオフ\u003c/h2\u003e\n\u003cp\u003eNISAとiDeCoの違いは一言でいえば自由度と節税の強さのトレードオフです。\u003c/p\u003e\n\u003cp\u003eNISA\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e引き出しはいつでも可能（老後・住宅・教育など自由に使える）\u003c/li\u003e\n\u003cli\u003e非課税になるのは運用益のみ\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eiDeCo\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e引き出しは原則60歳まで不可（実質老後資金に限られる）\u003c/li\u003e\n\u003cli\u003e非課税になるのは拠出時・運用益・受け取り時の3つ\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eNISAはいつでも引き出せる代わりに非課税になるのは運用益のみです。\u003cbr\u003e\niDeCoは60歳まで引き出せない代わりに非課税になるタイミングが拠出時・運用益・受け取り時の3つあります。\u003cbr\u003e\n自由度を取るか節税の強さを取るか、というのがこの2つの制度の本質的な違いです。\u003c/p\u003e\n\u003ch2 id=\"節税の強さだけならidecoが勝つ\"\u003e節税の強さだけならiDeCoが勝つ\u003c/h2\u003e\n\u003cp\u003e税制優遇とそこから得られるリターンの大きさを比べるとiDeCoのほうが強力です。\u003c/p\u003e\n\u003cp\u003e拠出時は掛金が全額所得控除の対象になり拠出した時点でその年の所得税と住民税が下がります。\u003cbr\u003e\n下がった税金の分だけ確定したリターン（単利）が返ってくるともいえるでしょう。\u003cbr\u003e\n戻ってきた税金分はNISAなどで再投資に回せるので実質的に元本が増えることになります。\u003cbr\u003e\n資産運用は長期投資なので元本の違いは長期的なリターンに大きな違いを産みます。\u003c/p\u003e\n\u003cp\u003eまた、受け取り時は退職所得控除の対象になり加入期間に応じた一定額まで非課税になります。\u003cbr\u003e\n超過分には課税されますがそれでも退職所得は優遇の大きい仕組みなので税額はかなり抑えられます。\u003c/p\u003e\n\u003cp\u003e節税効果とリターンという観点ではiDeCoが使えるなら使わない理由はないというのが結論です。\u003cbr\u003e\nそれくらいiDeCoは強力な制度なのです。\u003c/p\u003e\n\u003ch2 id=\"ただし60歳まで引き出せない\"\u003eただし60歳まで引き出せない\u003c/h2\u003e\n\u003cp\u003eとはいえiDeCoには大きな制約があります。\u003cbr\u003e\n一度拠出したお金は原則60歳まで引き出せないということです。\u003c/p\u003e\n\u003cp\u003eこれは生活防衛資金や近い将来使う予定のあるお金の話と直結します。\u003cbr\u003e\n急な出費が必要になったときにiDeCoに入れた資金は使うことができません。\u003cbr\u003e\nどれだけ節税効果が大きくても目の前の生活が苦しくなってしまっては本末転倒です。\u003cbr\u003e\nNISAであれば必要なときにいつでも引き出せるためこうした心配がありません。\u003c/p\u003e\n\u003cp\u003eまた、iDeCoは一度に入金できる金額に厳しい制限があります。\u003cbr\u003e\n1ヶ月に数万円程度しか入金できないのでまとまった金額を即座に運用できません。\u003cbr\u003e\nそのため、歳を取ってから一気に拠出するという使い方ができず若いうちから継続的に拠出する必要があります。\u003cbr\u003e\n一方、NISAは1年に360万円、5年で1800万円まで入金できますので個人の資産運用としては十分な金額を短い期間で投資することができます。\u003c/p\u003e\n\u003cp\u003eNISAとiDeCoは節税効果の大きさと資金の自由度の低さにおいて表裏一体の関係にあるということです。\u003c/p\u003e\n\u003ch2 id=\"優先順位は入金力で決める\"\u003e優先順位は入金力で決める\u003c/h2\u003e\n\u003cp\u003eではNISAとiDeCoどちらから始めればいいのでしょうか。\u003cbr\u003e\n考え方としては自分の資産や収入、つまり拠出できる金額によって決めるのがよいでしょう。\u003c/p\u003e\n\u003cp\u003e資産に余裕があるならばiDeCoに入れる金額をシミュレーションして計算して拠出し、それ以外をNISAに入れるというのが理想です。\u003cbr\u003e\n老後に必要な金額をまず見積もってから逆算して毎月の拠出金額を決めるとよいでしょう。\u003cbr\u003e\n老後まで使わないと決められる資金があるならば資金拘束はデメリットになりません。\u003cbr\u003e\niDeCoの節税効果は優秀なので老後の資産形成としてはなるべくiDeCoを活用したいです。\u003c/p\u003e\n\u003cp\u003e一方で、投資に回せる資金に余裕がない段階であればまずはNISAから始めるのがよいとおもいます。\u003cbr\u003e\n不測の事態や60歳までのイベントに対応できなくなるリスクを回避するほうが重要だからです。\u003cbr\u003e\n節税効果が高いからといっても受け取れるのは老後ですので偏ってしまっては意味がありません。\u003cbr\u003e\nまずはNISAで投資をして資産を増やしながら余裕ができたらiDeCoを使い始めて資産運用を加速させるのがよいでしょう。\u003c/p\u003e\n\u003cp\u003e重要なポイントとして、iDeCoの節税できる機会は後から取り戻すことができません。\u003cbr\u003e\n年金のように後から追納するようなことができないからです。\u003cbr\u003e\n入金力があるのに後回しにすればするほど本来受け取れたはずの控除を逃し続けることになります。\u003cbr\u003e\n可能ならばiDeCoの利用を早めに検討しましょう。\u003c/p\u003e\n\u003ch2 id=\"まとめ\"\u003eまとめ\u003c/h2\u003e\n\u003cp\u003eNISAとiDeCoの違いは自由度と節税の強さのトレードオフになっています。\u003cbr\u003e\niDeCoの節税効果は強力なので使えるならなるべく使うべきです。\u003cbr\u003e\nただし資金拘束があるため老後資金として切り離せるだけの余力が必要になります。\u003cbr\u003e\nそのため、まだ入金力に余裕がなければ自由度の高いNISAから始めるという選択肢もでてきます。\u003c/p\u003e\n\u003cp\u003eNISAもiDeCoも強力な制度です。\u003cbr\u003e\n自分が今どのように利用すると効果的なのか検討して制度を活用しましょう！\u003c/p\u003e\n\u003cp\u003e次回は投資したあとの話、運用中の心構えとリバランスについて解説します。\u003c/p\u003e","title":"NISAとiDeCo どちらを優先すべきか"},{"content":"前回は総資産のうちいくらを投資に回せばよいのかという話を書きました。\n投資に回す金額が決まったら次に悩むのがその資金をどう投資すればよいのかという問題です。\n手元のお金を一度にまとめて投資するのか、時間をかけて少しずつ投資するのかで結果も心理的な負担も変わってきます。\n今回はこの資金の投資方法について一括投資と積立投資そしてドルコスト平均法を整理しながら考えていきます。\n基本は決めたポートフォリオに従って投資する 投資の方法を考える前に大前提を確認します。\n投資は事前に決めたポートフォリオに従って行うのが基本です。\n株式と債券をどう組み合わせるかという資産配分を先に決めておきその配分どおりにお金を投資していきます。\nたとえば株式70%・債券30%という配分を決めたとしたら、100万円を投資するとき内訳は株式に70万円と債券に30万円になります。\nそのうえで、手元の資金状況によってどのように買っていくのか決まります。\nすでにまとまった資金があるならその全額を一括投資が理想です。\n反対にこれから始める人は毎月の収入から積み立てていくことになります。\nここで押さえておきたいのが一括投資と積立投資は本質的に同じだという点です。\n積立投資だとしても投資に回せるお金をすべて決めた資産配分に投資しているという意味では一括投資と変わりません。\n違いは今まとまった資産を持っているかどうかだけです。\nまとまった資金がある人はそれを一度に投資して、持っていない人は稼いだそばから投資していくというだけの差にすぎません。\nこの記事を読んでいる人の多くはこれから資産を作りたいと考えている側でしょう。\nその場合はすでにある貯金をまとめて投資してそこから先は毎月積み立てて増やしていくやり方がほとんどになります。\nドルコスト平均法はリターンが下がる ここでよく名前があがるのがドルコスト平均法です。\nドルコスト平均法とは一定の金額で定期的に買い続けて購入時期を分散する手法を指します。\n価格が高いときは少なく安いときは多く買えるため、取得単価を均す点がメリットとしてよく説明されます。\nただし、この手法には見落とされがちな問題点があります。\n資金を分けて投資するため、投資されない資金が生まれてしまうことです。\nこのように投資予定だが投資されていない資金を待機資金と呼びます。\nあたりまえですが、待機資金はなんのリターンも生みません。\nそのため期待できるリターンは下がってしまいます。\nドルコスト平均法はリスクを下げる手段だからリターンが下がるのはしょうがない、という意見もあるかとおもます。\nですが、そもそも時間分散でリスクを下げる必要があるのかというと基本的には不要だといえるでしょう。\nリスクはそもそも先に決めたアセットアロケーションで管理されるべきだからです。\n自分が受け入れられる水準に資産配分を合わせてあれば値動きの幅はその時点でコントロールされています。\nそのため、ドルコスト平均法で時間分散する必要がありません。\n理論だけを見ればまとまった資金は一括投資で問題ないということになります。\nとはいえ、理屈のうえで正しくても実際に行動できるかは別の問題です。\nまとまった資金をいきなり全額投資するのは多くの人にとってかなり怖いとおもいます。\nその不安を和らげる意味ではドルコスト平均法で分けて投資するのも初心者には悪くない選択です（ちなみに筆者の初めての投資額は1000円でした）\nリターンは重要ですが長期投資は続けられることが最も重要です。\n積立投資とドルコスト平均法を混同しない 最後に混同されやすい積立投資とドルコスト平均法の違いを丁寧に説明しておきます。\nどちらも毎月一定額を投資する形になるため同じものだと思われがちです。\nしかし両者は投資に回せるお金が手元にあるかどうか？という点でまったく違います。\nまず積立投資の例を見てみましょう。\n待機資金がない状態から毎月の給料から5万円を投資に回すとしましょう。\nこの人はその月に投資できる5万円をそのつど全額を投資しています。\nまだ投資していないのに寝かせているお金は手元にありません。\nこれが積立投資であり実質的に一括投資と同じ状況になっています。\n一方で、手元に待機資金300万円をもっている人がいるとします。\nこの300万円は今すぐ全額投資できるお金です。\nそれをあえて毎月10万円ずつ30ヶ月に分けて投資しているのがドルコスト平均法です。\nこの場合はまだ投資していない残りのお金が投資されずに待機資金として残り続けます。\nつまり、この待機資金を抱えるかどうかという点で大きな違いがあります。\n前述したように、積立投資は投資に回せるお金をそのつど全額投資しているため一括投資と本質的に同じです。\n反対にドルコスト平均法はまとまった資金の一部を待機させてしまうためリターンが落ちてしまいます。\nまとめ 資金の投資の仕方はまず決めた資産配分に従うのが基本です。\nそのうえでまとまった資金があれば一括投資、ゼロから始めるなら積立投資になります。\n両者は本質的に同じものですのでもっている資産状況からどちらで投資すればよいのか明確に決まるでしょう。\n一方で名前のよくあがるのがドルコスト平均法です。\nこれは待機資金が生まれるぶんリターンが下がってしまいますし、リスクはアセットアロケーションで管理できるため理論的には必要ありません。\nしかし、一度に投資する不安が大きいならドルコスト平均法で分散するのは初心者には悪くない選択です。\n自分がどこまで値動きに耐えられるか考えたうえで選んでみてください。\n次回はNISAとiDeCoの使い分けについて解説します。\n","permalink":"https://kenjiusui.github.io/blog/posts/finance/004_%E8%B3%87%E9%87%91%E3%82%92%E3%81%A9%E3%81%86%E3%82%84%E3%81%A3%E3%81%A6%E6%8A%95%E8%B3%87%E3%81%99%E3%82%8B%E3%81%AE%E3%81%8B/","summary":"\u003cp\u003e前回は総資産のうちいくらを投資に回せばよいのかという話を書きました。\u003c/p\u003e\n\u003cp\u003e投資に回す金額が決まったら次に悩むのがその資金をどう投資すればよいのかという問題です。\u003cbr\u003e\n手元のお金を一度にまとめて投資するのか、時間をかけて少しずつ投資するのかで結果も心理的な負担も変わってきます。\u003cbr\u003e\n今回はこの資金の投資方法について一括投資と積立投資そしてドルコスト平均法を整理しながら考えていきます。\u003c/p\u003e\n\u003ch2 id=\"基本は決めたポートフォリオに従って投資する\"\u003e基本は決めたポートフォリオに従って投資する\u003c/h2\u003e\n\u003cp\u003e投資の方法を考える前に大前提を確認します。\u003cbr\u003e\n投資は事前に決めたポートフォリオに従って行うのが基本です。\u003cbr\u003e\n株式と債券をどう組み合わせるかという資産配分を先に決めておきその配分どおりにお金を投資していきます。\u003cbr\u003e\nたとえば株式70%・債券30%という配分を決めたとしたら、100万円を投資するとき内訳は株式に70万円と債券に30万円になります。\u003c/p\u003e\n\u003cp\u003eそのうえで、手元の資金状況によってどのように買っていくのか決まります。\u003cbr\u003e\nすでにまとまった資金があるならその全額を一括投資が理想です。\u003cbr\u003e\n反対にこれから始める人は毎月の収入から積み立てていくことになります。\u003c/p\u003e\n\u003cp\u003eここで押さえておきたいのが一括投資と積立投資は本質的に同じだという点です。\u003cbr\u003e\n積立投資だとしても投資に回せるお金をすべて決めた資産配分に投資しているという意味では一括投資と変わりません。\u003cbr\u003e\n違いは今まとまった資産を持っているかどうかだけです。\u003cbr\u003e\nまとまった資金がある人はそれを一度に投資して、持っていない人は稼いだそばから投資していくというだけの差にすぎません。\u003c/p\u003e\n\u003cp\u003eこの記事を読んでいる人の多くはこれから資産を作りたいと考えている側でしょう。\u003cbr\u003e\nその場合はすでにある貯金をまとめて投資してそこから先は毎月積み立てて増やしていくやり方がほとんどになります。\u003c/p\u003e\n\u003ch2 id=\"ドルコスト平均法はリターンが下がる\"\u003eドルコスト平均法はリターンが下がる\u003c/h2\u003e\n\u003cp\u003eここでよく名前があがるのがドルコスト平均法です。\u003cbr\u003e\nドルコスト平均法とは一定の金額で定期的に買い続けて購入時期を分散する手法を指します。\u003cbr\u003e\n価格が高いときは少なく安いときは多く買えるため、取得単価を均す点がメリットとしてよく説明されます。\u003c/p\u003e\n\u003cp\u003eただし、この手法には見落とされがちな問題点があります。\u003cbr\u003e\n資金を分けて投資するため、投資されない資金が生まれてしまうことです。\u003cbr\u003e\nこのように投資予定だが投資されていない資金を待機資金と呼びます。\u003cbr\u003e\nあたりまえですが、待機資金はなんのリターンも生みません。\u003cbr\u003e\nそのため期待できるリターンは下がってしまいます。\u003c/p\u003e\n\u003cp\u003eドルコスト平均法はリスクを下げる手段だからリターンが下がるのはしょうがない、という意見もあるかとおもます。\u003cbr\u003e\nですが、そもそも時間分散でリスクを下げる必要があるのかというと基本的には不要だといえるでしょう。\u003cbr\u003e\nリスクはそもそも先に決めたアセットアロケーションで管理されるべきだからです。\u003cbr\u003e\n自分が受け入れられる水準に資産配分を合わせてあれば値動きの幅はその時点でコントロールされています。\u003cbr\u003e\nそのため、ドルコスト平均法で時間分散する必要がありません。\u003cbr\u003e\n理論だけを見ればまとまった資金は一括投資で問題ないということになります。\u003c/p\u003e\n\u003cp\u003eとはいえ、理屈のうえで正しくても実際に行動できるかは別の問題です。\u003cbr\u003e\nまとまった資金をいきなり全額投資するのは多くの人にとってかなり怖いとおもいます。\u003cbr\u003e\nその不安を和らげる意味ではドルコスト平均法で分けて投資するのも初心者には悪くない選択です（ちなみに筆者の初めての投資額は1000円でした）\u003cbr\u003e\nリターンは重要ですが長期投資は続けられることが最も重要です。\u003c/p\u003e\n\u003ch2 id=\"積立投資とドルコスト平均法を混同しない\"\u003e積立投資とドルコスト平均法を混同しない\u003c/h2\u003e\n\u003cp\u003e最後に混同されやすい積立投資とドルコスト平均法の違いを丁寧に説明しておきます。\u003cbr\u003e\nどちらも毎月一定額を投資する形になるため同じものだと思われがちです。\u003cbr\u003e\nしかし両者は投資に回せるお金が手元にあるかどうか？という点でまったく違います。\u003c/p\u003e\n\u003cp\u003eまず積立投資の例を見てみましょう。\u003cbr\u003e\n待機資金がない状態から毎月の給料から5万円を投資に回すとしましょう。\u003cbr\u003e\nこの人はその月に投資できる5万円をそのつど全額を投資しています。\u003cbr\u003e\nまだ投資していないのに寝かせているお金は手元にありません。\u003cbr\u003e\nこれが積立投資であり実質的に一括投資と同じ状況になっています。\u003c/p\u003e\n\u003cp\u003e一方で、手元に待機資金300万円をもっている人がいるとします。\u003cbr\u003e\nこの300万円は今すぐ全額投資できるお金です。\u003cbr\u003e\nそれをあえて毎月10万円ずつ30ヶ月に分けて投資しているのがドルコスト平均法です。\u003cbr\u003e\nこの場合はまだ投資していない残りのお金が投資されずに待機資金として残り続けます。\u003c/p\u003e\n\u003cp\u003eつまり、この待機資金を抱えるかどうかという点で大きな違いがあります。\u003cbr\u003e\n前述したように、積立投資は投資に回せるお金をそのつど全額投資しているため一括投資と本質的に同じです。\u003cbr\u003e\n反対にドルコスト平均法はまとまった資金の一部を待機させてしまうためリターンが落ちてしまいます。\u003c/p\u003e\n\u003ch2 id=\"まとめ\"\u003eまとめ\u003c/h2\u003e\n\u003cp\u003e資金の投資の仕方はまず決めた資産配分に従うのが基本です。\u003cbr\u003e\nそのうえでまとまった資金があれば一括投資、ゼロから始めるなら積立投資になります。\u003cbr\u003e\n両者は本質的に同じものですのでもっている資産状況からどちらで投資すればよいのか明確に決まるでしょう。\u003c/p\u003e\n\u003cp\u003e一方で名前のよくあがるのがドルコスト平均法です。\u003cbr\u003e\nこれは待機資金が生まれるぶんリターンが下がってしまいますし、リスクはアセットアロケーションで管理できるため理論的には必要ありません。\u003cbr\u003e\nしかし、一度に投資する不安が大きいならドルコスト平均法で分散するのは初心者には悪くない選択です。\u003cbr\u003e\n自分がどこまで値動きに耐えられるか考えたうえで選んでみてください。\u003c/p\u003e\n\u003cp\u003e次回はNISAとiDeCoの使い分けについて解説します。\u003c/p\u003e","title":"資金をどうやって投資するのか？一括・積立・ドルコスト平均法"},{"content":"前回は株式だけでなく債券を加えてリスクを管理しようという話を書きました。\n今回は「どれくらい投資すればよいのか？」という問題についてかんがえていきます。\nリスクを抑える組み合わせ方がわかっても次に気になるのは金額です。\n手元の資産のうちどこまでを投資に回していいのか迷う人は多いはずでしょう。\n考えるポイントは生活防衛資産と近い将来に使う予定のあるお金にあります。\nこの2つを整理したうえで投資する金額を検証できるようになりましょう。\n生活防衛資産を確保する 投資する前にまず最初に確保しておきたいのが生活防衛資産です。\n生活防衛資産はその名の通り生活を守るためのお金です。\nたとえば病気やケガで失業して収入が途絶えてしまったり、予期せぬ冠婚葬祭や車の故障といった急な出費に備えるためのお金を指します。\n生活防衛資産を用意せずにすべて投資してしまうのは危険です。\nこれには2つの理由があげられます。\n1つ目はリスク資産を強制的に売却しなければいけない事態を避けるためです。\n突発的な出費と市場の下落が同時に起きてしまうとあなたは損失を回避することができません。\n場合によっては、下落によって出費に耐えられるだけの資産がない状態になる可能性すらあります。\n2つ目は心理的な負担の解消です。\n生活防衛資産があることでなにか起きても生活を立て直せるという安心感が得られます。\nこれによって市場と生活の安定性を切り離せるため、安心して投資を続けることができます。\nでは、どれくらいの金額を生活防衛資産として用意すればよいのでしょうか？\n目安として会社員であれば生活費の半年分という基準が広く利用されています。\n金額としては一人暮らしであれば100万円、4人家族であれば200~300万円ほどになります。\nこのくらい用意していれば大概のアクシデントに耐えることができます。\n注意点として、フリーランスなどの場合は傷病手当といった失業時の保証が弱いため多めに用意することが推奨されています。\n具体的には生活費の1年分程度が望ましいでしょう。\n使う予定のあるお金も低リスク資産に置く 生活防衛資産は病気や失業といった予測できない出費に備えるためのお金でした。\n一方で教育費や車、住宅のようにあらかじめ使う時期が決まっている大きな出費もあります。\nこれらも計画的に準備する必要のあるお金です。\n大きな出費が予定されているのにすべてを投資資産に置いてしまうと生活防衛資産と同じ問題が起こり得ます。\nたとえば使う時期になった時にたまたま値下がりしていれば大きく価値が毀損した状態で売る必要がでてきます。\nこういった出費は金額が大きいだけに値下がりによって必要な金額を用意できない問題が容易に発生します。\n使う予定があるお金は定期預金や債券などリスクの低い資産に置いておくと安心です。\n目安として景気の循環サイクルから3~5年以内に使う予定がある分は安全な資産に移しておくとよいとされています。\n生活防衛資産と合わせてこの資金も投資とは切り離して考えておきたいところです。\n残りを投資資産に回す ここまでで確保しておくお金について解説してきました。\nこれらを用意した残りが投資に回せるお金になります。\nつまり、投資に回せる金額は総資産から「生活防衛資産」と「使う予定のあるお金」を差し引いた残りです。\n総資産 - 生活防衛資産 - 使う予定のあるお金 = 投資できるお金\nこの考え方のポイントは生活を安定して営むためのお金は絶対にわけて確保しておくということです。\n必要なお金を用意しておくからこそ安心して長期投資できるようになります。\n逆に、投資する金額を先に決めて無理をするのは絶対にやめましょう。\nNISA貧乏という言葉もありますが、投資とは生活もままならない状態でおこなうものではなく安定した生活の先にあるものです。\n将来の出費に安心できない状態では適切な投資判断をおこなうことはできません。\nまずは生活防衛資産と使う予定のあるお金を切り分けるところからやってみましょう。\n投資に回す金額が決まったら次に悩むのが実際にお金を投資する際の進め方です。\n一括で投資するか時間をかけて積み立てるか、やり方によって結果も心理的な負担も変わります。\n次回はこの一括投資と積立投資の違い、そしてドルコスト平均法について考えていきます。\n","permalink":"https://kenjiusui.github.io/blog/posts/finance/003_%E7%B7%8F%E8%B3%87%E7%94%A3%E3%81%AE%E3%81%86%E3%81%A1%E3%81%84%E3%81%8F%E3%82%89%E6%8A%95%E8%B3%87%E3%81%AB%E5%9B%9E%E3%81%9B%E3%81%B0%E3%81%84%E3%81%84%E3%81%AE%E3%81%8B/","summary":"\u003cp\u003e前回は株式だけでなく債券を加えてリスクを管理しようという話を書きました。\u003c/p\u003e\n\u003cp\u003e今回は「どれくらい投資すればよいのか？」という問題についてかんがえていきます。\u003cbr\u003e\nリスクを抑える組み合わせ方がわかっても次に気になるのは金額です。\u003cbr\u003e\n手元の資産のうちどこまでを投資に回していいのか迷う人は多いはずでしょう。\u003cbr\u003e\n考えるポイントは生活防衛資産と近い将来に使う予定のあるお金にあります。\u003cbr\u003e\nこの2つを整理したうえで投資する金額を検証できるようになりましょう。\u003c/p\u003e\n\u003ch2 id=\"生活防衛資産を確保する\"\u003e生活防衛資産を確保する\u003c/h2\u003e\n\u003cp\u003e投資する前にまず最初に確保しておきたいのが生活防衛資産です。\u003cbr\u003e\n生活防衛資産はその名の通り生活を守るためのお金です。\u003cbr\u003e\nたとえば病気やケガで失業して収入が途絶えてしまったり、予期せぬ冠婚葬祭や車の故障といった急な出費に備えるためのお金を指します。\u003c/p\u003e\n\u003cp\u003e生活防衛資産を用意せずにすべて投資してしまうのは危険です。\u003cbr\u003e\nこれには2つの理由があげられます。\u003c/p\u003e\n\u003cp\u003e1つ目はリスク資産を強制的に売却しなければいけない事態を避けるためです。\u003cbr\u003e\n突発的な出費と市場の下落が同時に起きてしまうとあなたは損失を回避することができません。\u003cbr\u003e\n場合によっては、下落によって出費に耐えられるだけの資産がない状態になる可能性すらあります。\u003c/p\u003e\n\u003cp\u003e2つ目は心理的な負担の解消です。\u003cbr\u003e\n生活防衛資産があることでなにか起きても生活を立て直せるという安心感が得られます。\u003cbr\u003e\nこれによって市場と生活の安定性を切り離せるため、安心して投資を続けることができます。\u003c/p\u003e\n\u003cp\u003eでは、どれくらいの金額を生活防衛資産として用意すればよいのでしょうか？\u003cbr\u003e\n目安として会社員であれば生活費の半年分という基準が広く利用されています。\u003cbr\u003e\n金額としては一人暮らしであれば100万円、4人家族であれば200~300万円ほどになります。\u003cbr\u003e\nこのくらい用意していれば大概のアクシデントに耐えることができます。\u003c/p\u003e\n\u003cp\u003e注意点として、フリーランスなどの場合は傷病手当といった失業時の保証が弱いため多めに用意することが推奨されています。\u003cbr\u003e\n具体的には生活費の1年分程度が望ましいでしょう。\u003c/p\u003e\n\u003ch2 id=\"使う予定のあるお金も低リスク資産に置く\"\u003e使う予定のあるお金も低リスク資産に置く\u003c/h2\u003e\n\u003cp\u003e生活防衛資産は病気や失業といった予測できない出費に備えるためのお金でした。\u003cbr\u003e\n一方で教育費や車、住宅のようにあらかじめ使う時期が決まっている大きな出費もあります。\u003cbr\u003e\nこれらも計画的に準備する必要のあるお金です。\u003c/p\u003e\n\u003cp\u003e大きな出費が予定されているのにすべてを投資資産に置いてしまうと生活防衛資産と同じ問題が起こり得ます。\u003cbr\u003e\nたとえば使う時期になった時にたまたま値下がりしていれば大きく価値が毀損した状態で売る必要がでてきます。\u003cbr\u003e\nこういった出費は金額が大きいだけに値下がりによって必要な金額を用意できない問題が容易に発生します。\u003c/p\u003e\n\u003cp\u003e使う予定があるお金は定期預金や債券などリスクの低い資産に置いておくと安心です。\u003cbr\u003e\n目安として景気の循環サイクルから3~5年以内に使う予定がある分は安全な資産に移しておくとよいとされています。\u003cbr\u003e\n生活防衛資産と合わせてこの資金も投資とは切り離して考えておきたいところです。\u003c/p\u003e\n\u003ch2 id=\"残りを投資資産に回す\"\u003e残りを投資資産に回す\u003c/h2\u003e\n\u003cp\u003eここまでで確保しておくお金について解説してきました。\u003cbr\u003e\nこれらを用意した残りが投資に回せるお金になります。\u003cbr\u003e\nつまり、投資に回せる金額は総資産から「生活防衛資産」と「使う予定のあるお金」を差し引いた残りです。\u003c/p\u003e\n\u003cp\u003e総資産 - 生活防衛資産 - 使う予定のあるお金 = 投資できるお金\u003c/p\u003e\n\u003cp\u003eこの考え方のポイントは生活を安定して営むためのお金は絶対にわけて確保しておくということです。\u003cbr\u003e\n必要なお金を用意しておくからこそ安心して長期投資できるようになります。\u003c/p\u003e\n\u003cp\u003e逆に、投資する金額を先に決めて無理をするのは絶対にやめましょう。\u003cbr\u003e\nNISA貧乏という言葉もありますが、投資とは生活もままならない状態でおこなうものではなく安定した生活の先にあるものです。\u003cbr\u003e\n将来の出費に安心できない状態では適切な投資判断をおこなうことはできません。\u003cbr\u003e\nまずは生活防衛資産と使う予定のあるお金を切り分けるところからやってみましょう。\u003c/p\u003e\n\u003cp\u003e投資に回す金額が決まったら次に悩むのが実際にお金を投資する際の進め方です。\u003cbr\u003e\n一括で投資するか時間をかけて積み立てるか、やり方によって結果も心理的な負担も変わります。\u003cbr\u003e\n次回はこの一括投資と積立投資の違い、そしてドルコスト平均法について考えていきます。\u003c/p\u003e","title":"総資産のうちいくら投資に回せばいいのか"},{"content":"前回は資産運用のベースにオルカンが選ばれる理由を書きました。\n世界中の株式を時価総額の比率どおりに持てる商品なので株式の部分はこれ1本でも問題ありません。\n何を買えばいいのか迷ったときの答えとしてよくできています。\nただ資産運用そのものをオルカンだけで済ませてよいのかどうか、となると話が変わってきます。\nオルカンしか持たない状態は資産のすべてを株式に置くことになるからです。\nこれはリスクが高く資産運用の基本から見ると良いやり方とはいえません。\nなぜリスク管理が必要なのか概観を掴みましょう。\n株式100%はリターンしか見ていない 株式100%という配分は期待リターンがもっとも大きくなる形です。\nそれだけ聞くと良いことのよう見えますが、その代わり値下がりも丸ごと引き受けることになります。\nつまり長期的には値上がりするが一時的に強烈な値下げが起きうるということです。\nこれが自分にとって問題がないのかどうか考える必要があります。\n2008年リーマン・ショックでは全世界株式でも高値から5割を超えて下がりました。\n最終的には元の値段を超えて成長していますが元の値段に戻るまで何年もかかりました。\n将来的に戻るという経験則は当時も今と同じくわかっていましたが、多くの人は耐えきれず資産を手放してしまいました。\n誰もが暴落が起きても自分なら耐えられると考えています。\n長期的に伸びるのだから値下がりで手放すなんて愚かだ、と。\nところが実際に下落が始まってみると1割減るような変化ですら狼狽して売ってしまう人は少なくありません。\nSNSを眺めていればそういう人をたくさん見かけることができます。\n想像している以上に目の前で資産が減っていくストレスは耐え難いものです。\nそして、気持ちの面で耐えられたとしてももうひとつ問題が残ります。\n下落の時期と資産を使う時期が重なる可能性です。\n出費の予定というのは相場の都合に合わせて動いてくれません。\n相場が悪いから大学の進学を1年待ってほしいとは言えないわけです。\nもしリーマン・ショックと出費が重なればあなたは半分になった資産をそのまま取り崩すことになります。\n自分に合ったリスクに収める そこで必要になるのが自分に合った水準までリスクを抑える管理です。\nやり方そのものは難しくありません。\n定番といえるのが債券を組み合わせるやり方です。\n債券は株式に比べて値動きが小さいため株式と一緒に持っておけば全体の下がり方は株式だけの場合より穏やかになります。\nまた、株式と債券は異なる値動きをするためお互いに打ち消し合ってリスクを減らします。\n単純に株式と債券のリスクの平均以上にリスクを減らす効果があるのです。\nでは、株式と債券はどれくらいの割合でもてばよいのでしょうか？\n自分が受け入れられるリスクのほうから考えるとよいでしょう。\n債券の比率が2割から5割のどこかに落ち着くことが多いです。\n古典的に株式と債券の割合として上げられるものは50:50や60:40があります。後者は株式が60％です。\nこれは割合のシンプルさ、歴史的に多くの商品で使われてきたという背景があります。\n他にも年齢の数だけ債券の割合にするというものもあります。\n引退が近づくにつれて債券比率を高めリスクを逓減するということですね。\nいずれにせよ、重要なのは心と支出の両面からみた自分が受け入れられるリスクです。\n資産が減っても気にならず当面は使う予定もないなら債券を2~3割ほどにしてリターンを狙ってもよいでしょう。\n一方で値下がりがどうしても怖い人もいます。\n子どもの教育費が控えていたり住宅の購入や引退が近かったりする場合もありますね。\nその場合は債券を4割から5割まで増やしておくほうが落ち着いて続けられるでしょう。\nオルカン1本で終わらせないために オルカンが良い商品であることは変わりません。\n株式の部分をこれ1本で済ませる判断にも十分な合理性があります。\nただ資産運用の全体をオルカンだけで終わらせてしまうのはリスクの管理ができていないかもしれません。\n将来の出費の予定と自分がどこまで下落に耐えられるかを見たうえで債券を組み入れておきたいところです。\nこの一手間が資産運用を長く続けるための土台になるのだと思います。\n","permalink":"https://kenjiusui.github.io/blog/posts/finance/002_%E3%82%AA%E3%83%AB%E3%82%AB%E3%83%B3100%E3%81%A7%E3%81%AF%E3%81%AA%E3%81%8F%E5%82%B5%E5%88%B8%E3%82%92%E7%B5%84%E3%81%BF%E5%85%A5%E3%82%8C%E3%82%88%E3%81%86/","summary":"\u003cp\u003e前回は資産運用のベースにオルカンが選ばれる理由を書きました。\u003cbr\u003e\n世界中の株式を時価総額の比率どおりに持てる商品なので株式の部分はこれ1本でも問題ありません。\u003cbr\u003e\n何を買えばいいのか迷ったときの答えとしてよくできています。\u003cbr\u003e\nただ資産運用そのものをオルカンだけで済ませてよいのかどうか、となると話が変わってきます。\u003cbr\u003e\nオルカンしか持たない状態は資産のすべてを株式に置くことになるからです。\u003cbr\u003e\nこれはリスクが高く資産運用の基本から見ると良いやり方とはいえません。\u003cbr\u003e\nなぜリスク管理が必要なのか概観を掴みましょう。\u003c/p\u003e\n\u003ch2 id=\"株式100はリターンしか見ていない\"\u003e株式100%はリターンしか見ていない\u003c/h2\u003e\n\u003cp\u003e株式100%という配分は期待リターンがもっとも大きくなる形です。\u003cbr\u003e\nそれだけ聞くと良いことのよう見えますが、その代わり値下がりも丸ごと引き受けることになります。\u003cbr\u003e\nつまり長期的には値上がりするが一時的に強烈な値下げが起きうるということです。\u003cbr\u003e\nこれが自分にとって問題がないのかどうか考える必要があります。\u003c/p\u003e\n\u003cp\u003e2008年リーマン・ショックでは全世界株式でも高値から5割を超えて下がりました。\u003cbr\u003e\n最終的には元の値段を超えて成長していますが元の値段に戻るまで何年もかかりました。\u003cbr\u003e\n将来的に戻るという経験則は当時も今と同じくわかっていましたが、多くの人は耐えきれず資産を手放してしまいました。\u003c/p\u003e\n\u003cp\u003e誰もが暴落が起きても自分なら耐えられると考えています。\u003cbr\u003e\n長期的に伸びるのだから値下がりで手放すなんて愚かだ、と。\u003cbr\u003e\nところが実際に下落が始まってみると1割減るような変化ですら狼狽して売ってしまう人は少なくありません。\u003cbr\u003e\nSNSを眺めていればそういう人をたくさん見かけることができます。\u003cbr\u003e\n想像している以上に目の前で資産が減っていくストレスは耐え難いものです。\u003c/p\u003e\n\u003cp\u003eそして、気持ちの面で耐えられたとしてももうひとつ問題が残ります。\u003cbr\u003e\n下落の時期と資産を使う時期が重なる可能性です。\u003cbr\u003e\n出費の予定というのは相場の都合に合わせて動いてくれません。\u003cbr\u003e\n相場が悪いから大学の進学を1年待ってほしいとは言えないわけです。\u003cbr\u003e\nもしリーマン・ショックと出費が重なればあなたは半分になった資産をそのまま取り崩すことになります。\u003c/p\u003e\n\u003ch2 id=\"自分に合ったリスクに収める\"\u003e自分に合ったリスクに収める\u003c/h2\u003e\n\u003cp\u003eそこで必要になるのが自分に合った水準までリスクを抑える管理です。\u003cbr\u003e\nやり方そのものは難しくありません。\u003cbr\u003e\n定番といえるのが債券を組み合わせるやり方です。\u003cbr\u003e\n債券は株式に比べて値動きが小さいため株式と一緒に持っておけば全体の下がり方は株式だけの場合より穏やかになります。\u003cbr\u003e\nまた、株式と債券は異なる値動きをするためお互いに打ち消し合ってリスクを減らします。\u003cbr\u003e\n単純に株式と債券のリスクの平均以上にリスクを減らす効果があるのです。\u003c/p\u003e\n\u003cp\u003eでは、株式と債券はどれくらいの割合でもてばよいのでしょうか？\u003cbr\u003e\n自分が受け入れられるリスクのほうから考えるとよいでしょう。\u003cbr\u003e\n債券の比率が2割から5割のどこかに落ち着くことが多いです。\u003c/p\u003e\n\u003cp\u003e古典的に株式と債券の割合として上げられるものは50:50や60:40があります。後者は株式が60％です。\u003cbr\u003e\nこれは割合のシンプルさ、歴史的に多くの商品で使われてきたという背景があります。\u003cbr\u003e\n他にも年齢の数だけ債券の割合にするというものもあります。\u003cbr\u003e\n引退が近づくにつれて債券比率を高めリスクを逓減するということですね。\u003c/p\u003e\n\u003cp\u003eいずれにせよ、重要なのは心と支出の両面からみた自分が受け入れられるリスクです。\u003cbr\u003e\n資産が減っても気にならず当面は使う予定もないなら債券を2~3割ほどにしてリターンを狙ってもよいでしょう。\u003cbr\u003e\n一方で値下がりがどうしても怖い人もいます。\u003cbr\u003e\n子どもの教育費が控えていたり住宅の購入や引退が近かったりする場合もありますね。\u003cbr\u003e\nその場合は債券を4割から5割まで増やしておくほうが落ち着いて続けられるでしょう。\u003c/p\u003e\n\u003ch2 id=\"オルカン1本で終わらせないために\"\u003eオルカン1本で終わらせないために\u003c/h2\u003e\n\u003cp\u003eオルカンが良い商品であることは変わりません。\u003cbr\u003e\n株式の部分をこれ1本で済ませる判断にも十分な合理性があります。\u003cbr\u003e\nただ資産運用の全体をオルカンだけで終わらせてしまうのはリスクの管理ができていないかもしれません。\u003cbr\u003e\n将来の出費の予定と自分がどこまで下落に耐えられるかを見たうえで債券を組み入れておきたいところです。\u003cbr\u003e\nこの一手間が資産運用を長く続けるための土台になるのだと思います。\u003c/p\u003e","title":"オルカン100%ではなく債券を組み入れよう"},{"content":"資産運用でまず何を買うか考えたとき多くの人がオルカンを選んでいますね。\nオルカンとはeMAXIS Slim全世界株式（オール・カントリー）の愛称で、世界中の株式を時価総額の比率どおりに保有できる投資信託です。\nこの時価総額の比率どおりという部分が実は資産運用の原則に照らしてもっともニュートラルな配分にあたります。\nなぜ全世界株式の時価総額加重平均がベースに選ばれるのか整理してみます。\n時価総額加重平均がニュートラルな理由 オルカンは世界中の株式に時価総額加重平均という方式で投資する商品です。\n時価総額とは株価に発行済み株式数をかけたもので企業や市場全体の規模を示す指標にあたります。\nオルカンはこの時価総額の比率をそのまま反映する形で世界中の株式を組み合わせています。\n一般的な資産運用の考え方として市場全体の構成比率どおりに保有することがベースとなっています。\nこの理由は単純で、この割合が世界中の投資家が売買した結果そのものだからです。\n時価総額比率は世界中の投資家の判断が集積した結果です。\nこの比率どおりに保有することは特定の見方を主張せず市場全体の判断をそのまま受け入れる立場と言えます。\nオルカンはこの時価総額加重平均をほぼそのまま再現した商品なのでベースとなる商品としてよく買われているということですね。\nオルカンは賭けをしないニュートラルな選択肢だといえます。\n時価総額加重平均が基準になるということ言い換えるならば、時価総額加重平均から外れた配分は市場平均に対して意図的に賭けをしているともいえるでしょう。\n市場全体の判断とは違う判断をするということですから、これは裁量をもったトレードに近づくわけです。\nその賭けが報われるかどうかは事前にはわかりません。\nS\u0026amp;P500や日経平均などを買って時価総額の加重平均から離れるということは、まさしくこのニュートラルな状態からあえて外れるという選択です。\nもちろん、バランスが外れること自体が悪いわけではありません。\nしかし、その判断は慎重に行う必要があります。\n下手にバランスを崩すのは単にリスクだけを増やしていることになりかねません。\n根拠なく「アメリカがいいと聞いたからS\u0026amp;P500を増やす」のような判断をする人は多く見かけますが、これは投資ではなく何も考えずアメリカに賭けるギャンブルだということを理解しておく必要があります。\nまとめ オルカンのように世界の時価総額平均が絶対の正解というわけではありません。\nアメリカ株や日本株に多めに配分したり個別株を一部組み込んだりする戦略もあります。\nただ、それは時価総額加重平均がニュートラルな基準であるということを理解したうえでの応用の話です。\n土台となる資産をどこに置くか迷ったときにオルカンが選ばれやすいのはこうした理由があるからです。\n","permalink":"https://kenjiusui.github.io/blog/posts/finance/001_%E8%B3%87%E7%94%A3%E9%81%8B%E7%94%A8%E3%81%AE%E3%83%99%E3%83%BC%E3%82%B9%E3%81%AB%E3%82%AA%E3%83%AB%E3%82%AB%E3%83%B3%E3%81%8C%E9%81%B8%E3%81%B0%E3%82%8C%E3%82%8B%E7%90%86%E7%94%B1/","summary":"\u003cp\u003e資産運用でまず何を買うか考えたとき多くの人がオルカンを選んでいますね。\u003cbr\u003e\nオルカンとはeMAXIS Slim全世界株式（オール・カントリー）の愛称で、世界中の株式を時価総額の比率どおりに保有できる投資信託です。\u003cbr\u003e\nこの時価総額の比率どおりという部分が実は資産運用の原則に照らしてもっともニュートラルな配分にあたります。\u003cbr\u003e\nなぜ全世界株式の時価総額加重平均がベースに選ばれるのか整理してみます。\u003c/p\u003e\n\u003ch2 id=\"時価総額加重平均がニュートラルな理由\"\u003e時価総額加重平均がニュートラルな理由\u003c/h2\u003e\n\u003cp\u003eオルカンは世界中の株式に時価総額加重平均という方式で投資する商品です。\u003cbr\u003e\n時価総額とは株価に発行済み株式数をかけたもので企業や市場全体の規模を示す指標にあたります。\u003cbr\u003e\nオルカンはこの時価総額の比率をそのまま反映する形で世界中の株式を組み合わせています。\u003c/p\u003e\n\u003cp\u003e一般的な資産運用の考え方として市場全体の構成比率どおりに保有することがベースとなっています。\u003cbr\u003e\nこの理由は単純で、この割合が世界中の投資家が売買した結果そのものだからです。\u003cbr\u003e\n時価総額比率は世界中の投資家の判断が集積した結果です。\u003cbr\u003e\nこの比率どおりに保有することは特定の見方を主張せず市場全体の判断をそのまま受け入れる立場と言えます。\u003cbr\u003e\nオルカンはこの時価総額加重平均をほぼそのまま再現した商品なのでベースとなる商品としてよく買われているということですね。\u003cbr\u003e\nオルカンは賭けをしないニュートラルな選択肢だといえます。\u003c/p\u003e\n\u003cp\u003e時価総額加重平均が基準になるということ言い換えるならば、時価総額加重平均から外れた配分は市場平均に対して意図的に賭けをしているともいえるでしょう。\u003cbr\u003e\n市場全体の判断とは違う判断をするということですから、これは裁量をもったトレードに近づくわけです。\u003cbr\u003e\nその賭けが報われるかどうかは事前にはわかりません。\u003c/p\u003e\n\u003cp\u003eS\u0026amp;P500や日経平均などを買って時価総額の加重平均から離れるということは、まさしくこのニュートラルな状態からあえて外れるという選択です。\u003cbr\u003e\nもちろん、バランスが外れること自体が悪いわけではありません。\u003cbr\u003e\nしかし、その判断は慎重に行う必要があります。\u003cbr\u003e\n下手にバランスを崩すのは単にリスクだけを増やしていることになりかねません。\u003cbr\u003e\n根拠なく「アメリカがいいと聞いたからS\u0026amp;P500を増やす」のような判断をする人は多く見かけますが、これは投資ではなく何も考えずアメリカに賭けるギャンブルだということを理解しておく必要があります。\u003c/p\u003e\n\u003ch2 id=\"まとめ\"\u003eまとめ\u003c/h2\u003e\n\u003cp\u003eオルカンのように世界の時価総額平均が絶対の正解というわけではありません。\u003cbr\u003e\nアメリカ株や日本株に多めに配分したり個別株を一部組み込んだりする戦略もあります。\u003cbr\u003e\nただ、それは時価総額加重平均がニュートラルな基準であるということを理解したうえでの応用の話です。\u003cbr\u003e\n土台となる資産をどこに置くか迷ったときにオルカンが選ばれやすいのはこうした理由があるからです。\u003c/p\u003e","title":"資産運用のベースにオルカンが選ばれる理由"},{"content":"4.1 データを保存・管理するための3層アーキテクチャ データ分析基盤では収集したデータや加工したデータを保存するときデータの状態ごと3つの層に分けて管理する方法が広く使われています。この3つの層はデータレイク、データウェアハウス、データマートと呼ばれています。\nデータがデータレイクからデータウェアハウス、そしてデータマートへと1方向に流れていくという構造になっています。データレイクは加工されていない生データが保存され、データウェアハウスはひととおりの加工によって標準化されたデータが保存されています。最後のデータマートでは何らかの用途や目的に応じて最適化されたデータを保存します。\nなぜ3層に分けるのでしょうか。主なメリットはデータの品質の向上と管理のしやすさにあります。1つのレイヤーにまとめた場合だと生のデータと分析用データが混在し管理が複雑でしたが3層にわけることで各層の責任範囲が明確になります。各層ごとに改善をおこないやすくなるのでデータの品質が向上し使いやすい分析基盤を作ることができるのです。\nまた、セキュリティやガバナンスといった観点でも有用です。個人情報などセンシティブなデータはデータレイクにとどめておき、なるべくデータウェアハウス以降は安全なデータのみとすることで安全に分析できる環境を構築することができます。\n4.2 データレイク：生データの保存 データレイクは収集したデータをそのまま保存する領域です。データソースから収集したデータを保存する最初のレイヤーとなります。\nデータレイクの最重要ポイントは、なるべく元のデータのまま加工せずに保存するということです。元データをそのまま保存する理由は後から「元データを確認したい」「別の分析方法を試したい」という要求が発生した時に必ず元に戻れる状態を維持することにあります。また変換処理でミスが発生しても元データから再処理できる可逆性も重要です。\nデータレイクはCSV、JSON、XML、ログファイル、画像など様々な形式のデータを統一的に保存します。業務システムから出力されるCSVファイル、Webサーバーのアクセスログ、外部APIから取得したJSON形式の顧客データなどが保存されます。\n保存時には圧縮によるストレージ容量の最適化も検討されます。圧縮効率だけでなく解凍にかかる時間や付随できるメタデータの有用性なども重要な観点です。たとえば、データベースのような構造化データを扱うときはParquetのようにあとの工程で扱いやすい形式がよく使われています。\nまた、保存するときは乱雑に保存するのではなく日付やデータソース別にパーティション分割することが一般的です。これは多くの分析基盤や関連サービスにおいてパーティションを利用することで効率的な検索と管理ができるようになっているためです。データレイクは大量データの長期保存となるためコスト効率と検索性の両立が不可欠です。\n4.3 データウェアハウス：データクレンジングと前処理・セキュリティ対応 データウェアハウスではデータレイクの生データに対してクレンジングや前処理を実行し品質の高い標準化されたデータを保存します。\nなぜデータウェアハウスが必要なのでしょうか？データレイクは生のデータを網羅的に保存する場所であり、分析するにはひと手間かかってしまうという問題があります。データのフォーマットの違いや欠損、個人情報の対応などが必要です。それらの処理を施したうえで保存されているのがデータウェアハウスです。データウェアハウスは分析するために必要な処理をおこなったデータを保存する場所であり、データウェアハウスのデータならばすぐに分析に使うことができます。\nデータの前処理としてよくあるのはまずデータのフォーマットの標準化です。たとえば日付を「2024/1/15」と「2024-01-15」のように形に統一して扱いやすくします。JSONやXMLなどさまざまな形式のデータを扱いやすい形式に変換したりもします。\n個人情報の対応も前処理として重要です。個人情報などセンシティブな情報はデータを削除したりマスキングすることで安全に扱えるようにします。データウェアハウス以降のデータは個人情報への対応が完了しているものだけ保存する、というルールを設定すればデータウェアハウス以降は安全な領域となるため安心して多くの人が利用できるようになります。このような運用はガバナンスの観点でも好まれます。\n4.4 データマート：分析用データとビジネス特化環境 データマートでは特定のビジネス要件に特化したデータを保存・提供します。\nデータウェアハウスは前処理されたデータを幅広く保存している場所でしたがデータマートは部門別や目的別に特化した分析用データセットです。各データマートは分析者の分析パターンに合わせて設計されます。たとえば、営業部門が「先月の売上トップ10商品を地域別に知りたい」という分析を頻繁に実行する場合、時系列で地域別・商品別の売上を事前計算しておいてデータマートに保存します。これによりレポートを開いた瞬間に結果が表示されますし、必要に応じてちょっとした分析をBIツールですぐにおこなうこともできます。\nデータマートは素早く分析できることだけでなく一貫した分析結果が得られることも大きなメリットです。データマートを用意しなければ各々が分析処理を実装する必要がありますが、そうすると細かな仕様や実装の差によって集計値がズレがちです。データマートとして事前に仕様と実装の認識を揃えておくことでこのような値のズレによる意思決定の間違いや遅延を回避することができます。\n一方でデータマートを乱立させてしまうとこれらの目的を達成することができなくなります。それぞれの目的やチームごとにどんなデータマートが必要なのか整理しながら適切にデータマートを用意する必要があります。用途を満たしながら変化に対応できる柔軟性をもたせたデータマートの設計が重要です。\n4.5 データ変換処理とワークフロー管理 3層アーキテクチャを実現するためには各層の特性に応じたデータ処理システムの構築が重要です。データレイクからデータウェアハウス、そしてデータマートへデータが段階的に変換される過程で品質向上と利用価値の最大化させていきます。\nデータ処理システムを構築するうえで最も重要なポイントは自動化と信頼性です。手作業による処理は人的ミスやスケール性の限界があるため全ての変換処理を自動化し障害時でも容易に復旧できる仕組みを構築します。また処理の透明性も重要でありデータがどの段階でどのように変換されたか追跡を可能にします。\nデータの処理は一方向になるよう意識しましょう。データの処理はデータレイクからデータウェアハウス、そしてデータマートへという流れに統一し、逆方向への処理は避けます。これにより「データマートの特定用途の集計済みデータがデータウェアハウスに入る」といった管理コストが高くなるような状況を回避することができます。あわせて、処理の順序が明確になりシステムの複雑性を軽減できます。\n大量のデータを処理するための処理時間の最適化と並列化、そして依存関係管理のバランスも重要です。処理時間短縮のため可能な限り並列実行を行いますが依存関係のある処理ならば順序を守る必要があります。そのため、データ分析基盤を開発するときにはワークフローを管理するためにワークフローエンジンなど専用のサービスを導入して複雑な依存関係を管理することが一般的です。同時に、各データソースの更新パターンに合わせた最適なスケジューリングも求められます。\nここにあげた以外にもデータの変換処理をうまくおこなうためのプラクティスはたくさんあります。データ分析基盤は他のITサービスや社内システムとも違う独特のシステムです。実際にデータ分析基盤を開発・実装する段階なのであれば、より詳しい知見を事前に調べてから取り掛かることをオススメします。\n","permalink":"https://kenjiusui.github.io/blog/books/data-platform-intro/04_data_storage/","summary":"\u003ch2 id=\"41-データを保存管理するための3層アーキテクチャ\"\u003e4.1 データを保存・管理するための3層アーキテクチャ\u003c/h2\u003e\n\u003cp\u003eデータ分析基盤では収集したデータや加工したデータを保存するときデータの状態ごと3つの層に分けて管理する方法が広く使われています。この3つの層はデータレイク、データウェアハウス、データマートと呼ばれています。\u003c/p\u003e\n\u003cp\u003eデータがデータレイクからデータウェアハウス、そしてデータマートへと1方向に流れていくという構造になっています。データレイクは加工されていない生データが保存され、データウェアハウスはひととおりの加工によって標準化されたデータが保存されています。最後のデータマートでは何らかの用途や目的に応じて最適化されたデータを保存します。\u003c/p\u003e\n\u003cp\u003eなぜ3層に分けるのでしょうか。主なメリットはデータの品質の向上と管理のしやすさにあります。1つのレイヤーにまとめた場合だと生のデータと分析用データが混在し管理が複雑でしたが3層にわけることで各層の責任範囲が明確になります。各層ごとに改善をおこないやすくなるのでデータの品質が向上し使いやすい分析基盤を作ることができるのです。\u003c/p\u003e\n\u003cp\u003eまた、セキュリティやガバナンスといった観点でも有用です。個人情報などセンシティブなデータはデータレイクにとどめておき、なるべくデータウェアハウス以降は安全なデータのみとすることで安全に分析できる環境を構築することができます。\u003c/p\u003e\n\u003ch2 id=\"42-データレイク生データの保存\"\u003e4.2 データレイク：生データの保存\u003c/h2\u003e\n\u003cp\u003eデータレイクは収集したデータをそのまま保存する領域です。データソースから収集したデータを保存する最初のレイヤーとなります。\u003c/p\u003e\n\u003cp\u003eデータレイクの最重要ポイントは、なるべく元のデータのまま加工せずに保存するということです。元データをそのまま保存する理由は後から「元データを確認したい」「別の分析方法を試したい」という要求が発生した時に必ず元に戻れる状態を維持することにあります。また変換処理でミスが発生しても元データから再処理できる可逆性も重要です。\u003c/p\u003e\n\u003cp\u003eデータレイクはCSV、JSON、XML、ログファイル、画像など様々な形式のデータを統一的に保存します。業務システムから出力されるCSVファイル、Webサーバーのアクセスログ、外部APIから取得したJSON形式の顧客データなどが保存されます。\u003c/p\u003e\n\u003cp\u003e保存時には圧縮によるストレージ容量の最適化も検討されます。圧縮効率だけでなく解凍にかかる時間や付随できるメタデータの有用性なども重要な観点です。たとえば、データベースのような構造化データを扱うときはParquetのようにあとの工程で扱いやすい形式がよく使われています。\u003c/p\u003e\n\u003cp\u003eまた、保存するときは乱雑に保存するのではなく日付やデータソース別にパーティション分割することが一般的です。これは多くの分析基盤や関連サービスにおいてパーティションを利用することで効率的な検索と管理ができるようになっているためです。データレイクは大量データの長期保存となるためコスト効率と検索性の両立が不可欠です。\u003c/p\u003e\n\u003ch2 id=\"43-データウェアハウスデータクレンジングと前処理セキュリティ対応\"\u003e4.3 データウェアハウス：データクレンジングと前処理・セキュリティ対応\u003c/h2\u003e\n\u003cp\u003eデータウェアハウスではデータレイクの生データに対してクレンジングや前処理を実行し品質の高い標準化されたデータを保存します。\u003c/p\u003e\n\u003cp\u003eなぜデータウェアハウスが必要なのでしょうか？データレイクは生のデータを網羅的に保存する場所であり、分析するにはひと手間かかってしまうという問題があります。データのフォーマットの違いや欠損、個人情報の対応などが必要です。それらの処理を施したうえで保存されているのがデータウェアハウスです。データウェアハウスは分析するために必要な処理をおこなったデータを保存する場所であり、データウェアハウスのデータならばすぐに分析に使うことができます。\u003c/p\u003e\n\u003cp\u003eデータの前処理としてよくあるのはまずデータのフォーマットの標準化です。たとえば日付を「2024/1/15」と「2024-01-15」のように形に統一して扱いやすくします。JSONやXMLなどさまざまな形式のデータを扱いやすい形式に変換したりもします。\u003c/p\u003e\n\u003cp\u003e個人情報の対応も前処理として重要です。個人情報などセンシティブな情報はデータを削除したりマスキングすることで安全に扱えるようにします。データウェアハウス以降のデータは個人情報への対応が完了しているものだけ保存する、というルールを設定すればデータウェアハウス以降は安全な領域となるため安心して多くの人が利用できるようになります。このような運用はガバナンスの観点でも好まれます。\u003c/p\u003e\n\u003ch2 id=\"44-データマート分析用データとビジネス特化環境\"\u003e4.4 データマート：分析用データとビジネス特化環境\u003c/h2\u003e\n\u003cp\u003eデータマートでは特定のビジネス要件に特化したデータを保存・提供します。\u003c/p\u003e\n\u003cp\u003eデータウェアハウスは前処理されたデータを幅広く保存している場所でしたがデータマートは部門別や目的別に特化した分析用データセットです。各データマートは分析者の分析パターンに合わせて設計されます。たとえば、営業部門が「先月の売上トップ10商品を地域別に知りたい」という分析を頻繁に実行する場合、時系列で地域別・商品別の売上を事前計算しておいてデータマートに保存します。これによりレポートを開いた瞬間に結果が表示されますし、必要に応じてちょっとした分析をBIツールですぐにおこなうこともできます。\u003c/p\u003e\n\u003cp\u003eデータマートは素早く分析できることだけでなく一貫した分析結果が得られることも大きなメリットです。データマートを用意しなければ各々が分析処理を実装する必要がありますが、そうすると細かな仕様や実装の差によって集計値がズレがちです。データマートとして事前に仕様と実装の認識を揃えておくことでこのような値のズレによる意思決定の間違いや遅延を回避することができます。\u003c/p\u003e\n\u003cp\u003e一方でデータマートを乱立させてしまうとこれらの目的を達成することができなくなります。それぞれの目的やチームごとにどんなデータマートが必要なのか整理しながら適切にデータマートを用意する必要があります。用途を満たしながら変化に対応できる柔軟性をもたせたデータマートの設計が重要です。\u003c/p\u003e\n\u003ch2 id=\"45-データ変換処理とワークフロー管理\"\u003e4.5 データ変換処理とワークフロー管理\u003c/h2\u003e\n\u003cp\u003e3層アーキテクチャを実現するためには各層の特性に応じたデータ処理システムの構築が重要です。データレイクからデータウェアハウス、そしてデータマートへデータが段階的に変換される過程で品質向上と利用価値の最大化させていきます。\u003c/p\u003e\n\u003cp\u003eデータ処理システムを構築するうえで最も重要なポイントは自動化と信頼性です。手作業による処理は人的ミスやスケール性の限界があるため全ての変換処理を自動化し障害時でも容易に復旧できる仕組みを構築します。また処理の透明性も重要でありデータがどの段階でどのように変換されたか追跡を可能にします。\u003c/p\u003e\n\u003cp\u003eデータの処理は一方向になるよう意識しましょう。データの処理はデータレイクからデータウェアハウス、そしてデータマートへという流れに統一し、逆方向への処理は避けます。これにより「データマートの特定用途の集計済みデータがデータウェアハウスに入る」といった管理コストが高くなるような状況を回避することができます。あわせて、処理の順序が明確になりシステムの複雑性を軽減できます。\u003c/p\u003e\n\u003cp\u003e大量のデータを処理するための処理時間の最適化と並列化、そして依存関係管理のバランスも重要です。処理時間短縮のため可能な限り並列実行を行いますが依存関係のある処理ならば順序を守る必要があります。そのため、データ分析基盤を開発するときにはワークフローを管理するためにワークフローエンジンなど専用のサービスを導入して複雑な依存関係を管理することが一般的です。同時に、各データソースの更新パターンに合わせた最適なスケジューリングも求められます。\u003c/p\u003e\n\u003cp\u003eここにあげた以外にもデータの変換処理をうまくおこなうためのプラクティスはたくさんあります。データ分析基盤は他のITサービスや社内システムとも違う独特のシステムです。実際にデータ分析基盤を開発・実装する段階なのであれば、より詳しい知見を事前に調べてから取り掛かることをオススメします。\u003c/p\u003e","title":"データ保存・管理"},{"content":"5.1 データ収集の複雑さと課題 データ分析基盤の構築において最も困難な工程がデータ収集です。前章で説明したデータレイクに生のデータを保存する前段階として様々なシステムからデータを取り込むのがこの工程です。\n現代の企業では様々なシステムが連携して稼働しています。顧客管理システム、マーケティングツール、在庫管理システム、受発注管理システム、アクセス解析…などです。これらのシステムはそれぞれ異なる技術で構築されておりデータの形式・更新頻度・アクセス方法など全く違うことがほとんどでしょう。\nデータを取り込む工程が複雑な理由は大きく4つあります。\nデータ形式の多様性：CSV・JSON・XML・固定長テキスト・バイナリファイルなど様々な形式が混在 アクセス方法の違い：データベース直接接続・REST API・FTPサーバー・メール添付など多様な取得経路 更新スケジュールの違い：リアルタイム更新から月次更新まで時間軸が大きく異なる データ量の違い：数MBの小規模なファイルから数TBまでデータ量が段違い 従来は各システムの担当者が個別にデータを抽出し手動でやり取りしていました。しかしこの方法では人為的なミス・作業の遅延・データの不整合が頻発します。データ分析基盤では全てのデータソースを自動的かつ確実に取り込むための仕組みが必要不可欠です。\n5.2 データソースの種類と特徴 データを取り込むという観点から、企業内で扱うデータソースは大きく4つのカテゴリに分類して紹介します。それぞれ異なる取り込み方法と注意点があります。\n社内業務システム 社内の基幹システムは最も重要なデータソースです。販売管理、在庫管理、会計、人事そして自社ITサービスのデータベースなどが該当します。\nこれらのシステムの特徴は高い信頼性と一定の更新パターンです。たとえば在庫データであれば出荷処理後に比較的リアルタイムに更新されることが多いでしょう。一方で営業のデータは営業時間中リアルタイムに更新されるよりも営業時間終了後にまとめて確定・更新されることは珍しくありません。さらに会計データであれば月末月初に処理が集中しやくすく締め処理もこのタイミングです。このような更新タイミングを理解してデータ取り込みスケジュールを設計することが重要です。\n取り込み方法はシステムによって異なります。データベースへの直接接続できたり専用のAPIが用意されていればやりやすいケースです。データベースからCSVファイルを出力して転送するというケースも珍しくありません。業務システムは古いことも多く、現代ではあまり使われないファイル形式や文字コードを扱う必要や互換性の確保が課題となります。\n外部Webサービス・API SaaSや広告配信プラットフォームなど外部のサービスから提供されるデータです。現代の企業運営では多くの外部サービスを連携して使うことも多いため、小さい企業でも複数の外部サービスを利用することは珍しくありません。\n外部サービスからデータを取得するには方法や形式、制限を調査する必要があります。最近のサービスであればREST API形式でアクセスできることが多いですが、GUI上からしかアクセスできない場合は自動化が難しいケースもあるでしょう。そもそもまとめてデータの取得ができないということもあります。\nまたAPIだとしてもほとんどの場合で制約事項が存在します。APIの呼び出し回数の上限や、データ取得量の制限、認証トークンの更新、サービス停止時の対応などを考慮する必要があります。また外部サービスの仕様変更により突然データ取得ができなくなるリスクもあります。\nこのような多様な接続形式や仕様の変更に対応できるような柔軟な仕組みと体制が必要になります。自分たちで接続するシステムを開発するだけでなく、データ分析基盤が用意しているコネクターを利用したり外部サービスと連携するサービスの利用を検討してもよいでしょう。\nファイルデータ PDFや画像、動画などのファイル形式で提供されるデータです。請求書など外部から送られてきたPDFファイル、経費の精算に使うレシートの画像データ、議事録の録画ファイルなどがさまざまなものがあります。\nファイルのデータはさまざまな経路から発生するうえデータの性質に応じて個別の対応が求められます。特に保存する場所や形式には注意が必要です。動画などデータのサイズが大きい場合はストレージがすぐに満杯になってしまったり、従量課金制の場合は気がついたらストレージだけで予算を使い切ってしまいます。\nファイル形式の場合はデータベースのように構造化されたデータをもっていないため、何らかの処理を通して構造化されたデータをデータウェアハウスに保存することが多くあります。たとえば、音声から文字起こししたり画像からOCRするようなパターンです。この場合は処理の内容があとから変更されることも少なくないのでなるべく元データを保存することが望ましいでしょう。\nリアルタイムストリームデータ IoTセンサー・Webサイトのログデータ・金融取引データなど連続的に生成されるデータです。\nストリームデータの特徴は高頻度・小容量・時系列性です。常にデータが連続的に流れ込みます。データの順序や時刻情報が重要でありネットワーク遅延や重複配信への対応が必要です。\nストリームデータの取り扱いは他のケースに比べて技術的に難易度が高くなります。取り込みには専用のメッセージングシステムが使用されることが一般的です。AWSのKinesisやGoogle CloudのPub/Subなどが挙げられます。\n他のデータの形式と違ってリアルタイムに取得されたデータが常に網羅的であるとは限らないという点が厄介です。例えば、スマホアプリのログデータであれば端末がネットワークにつながっていないときはログが送信されてこないため後からログが到着するという事象が起きます。データの取得に遅延がなくとも、分析にすぐさま使えるかどうかは別の問題となります。\n5.3 バッチ処理とストリーミング処理 データの収集にあたってどのようなデータがあるのか俯瞰したところで、次はどのようにしてデータを取り込むのか？という観点からいくつか重要なポイントを紹介します。\nデータ取り込み方式には大きく分けてバッチ処理とストリーミング処理があります。どちらを選択するかはデータの性質と業務要件によって決まります。\nバッチ処理 バッチ処理は決められた時間にまとまったデータを一括で処理する方式です。「毎日午前3時に前日分の売上データを取り込む」とか「月末に1ヶ月分の会計データを取得する」といったように決まった時間や間隔で定期に処理をおこないます\nバッチ処理の利点はシンプルな設計と処理効率の高さです。まとまった処理ロジックを構築できるため比較的実装をシンプルにしやすく運用管理も容易になります。エラーが発生した場合の再実行やリトライも簡単に実装できます。また、大量のデータを一度に処理するため処理の効率も向上します。\n一方でバッチ処理の欠点はリアルタイム性です。決まった時間に実行されるため、その時間までは最新のデータが反映されません。更新頻度を高めることでこの問題はある程度解決することはできますが高いリアルタイム性が求められる場合はバッチ処理だと限界があるでしょう。\nまた、データ量が非常に大きい場合もバッチ処理が難しい場合があります。バッチ処理のためには一度にデータを取り込む必要があるためメモリに乗らないデータ量となると途端に処理が難しくなります。スケールできるシステムであればある程度は解決しますが実装が複雑になるためストリーミング処理をおこなったほうが便利な場面もでてきます。\nストリーミング処理 ストリーミング処理はデータの追加や変更をリアルタイムかつ連続的に処理する方式です。WebサイトのアクセスログやIoTセンサーデータなど刻一刻と変化するデータに適しています。\nストリーミング処理の一番のメリットはリアルタイム性です。発生したデータをリアルタイムに分析結果へと反映させることができます。広告やリリースの効果検証のように施策を実行したあと素早くデータを取得して分析したいときに有用です。\n加えて、継続的に処理するという点もメリットがあります。小さなデータを連続処理するためシステム負荷が平準化されます。バッチ処理でデータが大きすぎて処理が詰まるような事態を解消することができます。\n一方でストリーミング処理の欠点は設計・運用の複雑さです。データの順序や重複処理の回避、障害時の復旧など考慮すべき点が多数あります。処理中断によるデータ欠損のリスクもあります。\nまた、リアルタイムといっても完全にデータの発生から瞬時にデータが得られるわけではありません。システムの構成にもよりますが数秒から数分の遅延があることが一般的です。\n適切な選択基準 どちらを選択するかは以下の観点で判断します。\n1つはデータの鮮度です。リアルタイムな分析が必要ならストリーミングが必要になりますが、日次や週次レポートで十分ならバッチを選択します。\n2つ目はシステムの運用のしやすさです。処理のわかりやすさや障害発生時の対応のしやすさを重視するならバッチが適しています。\n3つ目はデータの量です。センサーやアクセスログのようにデータ量が非常に大きく継続的に更新されている場合はバッチよりもストリーミング処理したほうが効率がよいでしょう。\n実際の運用では両方を組み合わせることが一般的です。顧客データなど日次で十分なデータはバッチで処理し、日次よりもリアルタイム性が求められるデータや連続的かつ大量に発生するログデータはストリーミング処理にするといったハイブリッド構成になります。\n5.4 データ取り込みパターン（全件 vs 増分・CDC） 効率的なデータ取り込みのために適切な取り込みパターンを選択することが重要です。主要なパターンを3つ紹介します。\n全件取り込み 毎回データソースから全てのデータを取り込む最もシンプルな方式です。「毎日商品マスタの全件を取り込む」「毎月CRMの全データをコピーする」といった処理が該当します。\n全件取り込みの利点は実装の簡単さと確実性です。すべてのデータを丸ごと取得して保存するだけなので複雑な差分処理が不要で過去データの修正や削除も確実に反映されます。また障害からの復旧時も最新の全件データを取り込むだけで完全に復元できます。\n一方で欠点は処理時間と負荷の大きさです。データ量が増加すると1回あたりの処理に必要な計算資源や処理時間が増えますしネットワーク帯域なども大量に消費します。また、毎回同じデータを転送するため効率は悪くなります。\n増分・差分取り込み 新しく追加されたり更新されたデータのみを取り込む方式です。「前回取り込みをおこなった昨日の17時以降に追加・更新された注文データのみ取得する」といった処理が該当します。\n増分取り込みの利点は処理効率とリソース節約です。前に取得したときとの差分しか処理しないので転送するデータ量と処理時間を大幅に削減できます。そのため頻繁な取り込み処理も可能になりデータの鮮度を向上させやすくなります。\nしかし、増分・差分取り込みは管理が複雑になりがちです。どのデータが更新されたかを判定する仕組み・処理済みデータの管理・取り込み失敗時の差分データの処理などを考慮する必要があります。要件が複雑になるためデータ更新の定義の誤りで過去データの修正や削除を見落とすというケースは珍しくありません。\nCDC + ストリーミング CDCとはChange Data Captureの略でデータベースの変更をリアルタイムで検知する技術です。CDCで検知した変更内容をそのままストリーミングで取り込むのがこの方式です。データベースのトランザクションログを監視して挿入・更新・削除の操作を即座に反映します。\nCDCの利点はリアルタイム性と完全性です。データ変更から素早く分析基盤に反映でき、変更・削除も含めて完全に同期されます。差分更新とは異なりトランザクションを監視しているためデータの修正や削除を見落とす可能性が低くなります。\n一方で、CDCの欠点は技術的複雑さと運用の難易度です。データベース固有の仕組みを理解する必要があり全件更新などに比べると実装が複雑ですしシステム障害時の原因や影響範囲の特定が難しくなります。また、全てのデータベースがCDCに対応しているわけではありません。\n適切なパターンの選択 パターン選択はデータの特性と要件によって決まります。マスタデータのような更新頻度が低いデータは全件取り込み、トランザクションデータのような大容量データを増分取り込み、リアルタイムな分析が必要なデータはCDCと使い分けることが必要です。実際の運用では複数パターンを組み合わせて各データソースと利用目的に応じて適した方式を適用します。\n5.5 データ収集アーキテクチャの設計指針 データ収集システムを効率的かつ安定的に運用するためにアーキテクチャの設計についていくつかの指針を紹介します。\nシンプルな取得方法の優先 データ収集システムでは複雑な処理を避けシンプルな取得方法を優先することが重要です。技術的に高度な仕組みよりも理解しやすく保守しやすいアプローチを選択することで長期的な運用コストを削減できます。\n例えばリアルタイム性が必須でない場合はストリーミング処理ではなくバッチ処理を選択します。データ量などに問題がなければCDCや増分・差分更新よりも全件取得のほうがロジックがシンプルで楽になります。\nまた、データソースからデータを取得する手法はAPIが用意されているならばAPIを利用することが望ましいでしょう。RPAツールやクローリングなどは動作も安定しないためなるべく避けるべきです。外部サービスの場合は用意された方法以外だと規約違反になる可能性もあります。\nスケーラビリティへの対応 基本的に取得するデータは増えていくという前提のもと設計する必要があります。増加速度は場合によりますが減ることはふつうありません。データが増えたときにスケールできる設計になっていることが重要です。\nまた、データ量の増加だけでなく接続するデータソースの数と多様性の拡大にも柔軟に対応できる設計が必要です。水平スケーリングにより処理サーバー数を増やすことでデータソースの増加に対応できるアーキテクチャを採用します。\nデータソースの多様性に対しては機能を追加しやすいアーキテクチャが有効です。新しいデータソースが追加されても既存システムに影響を与えることなくコネクタやアダプターを追加できる仕組みを構築します。APIの変更や新しいファイル形式にも迅速に対応できる拡張性を確保することが重要です。\n監視と運用性の考慮 データ収集の成功・失敗・処理時間・データ品質を常時監視する仕組みが不可欠です。各処理段階でメトリクスを収集しダッシュボードでリアルタイム監視できる環境を構築します。\n異常検知の自動化により処理失敗やデータ品質悪化を即座に検出しアラート通知を行います。また処理ログの詳細記録により問題発生時の原因調査を迅速に実行できるようにします。運用手順書とトラブルシューティングガイドも整備し属人化を防ぎます。\nセキュリティとコンプライアンス データ収集過程で個人情報や機密情報を適切に保護する仕組みが必要です。データ転送時の暗号化・アクセス権限管理・監査ログ取得を徹底し情報漏洩リスクを最小化します。\nまた法的要件への対応も重要です。GDPR・個人情報保護法などの規制に応じてデータ保持期間・削除手順・同意管理を適切に実装します。定期的なセキュリティ監査により継続的な改善を図ることも必要です。\n","permalink":"https://kenjiusui.github.io/blog/books/data-platform-intro/05_data_ingestion/","summary":"\u003ch2 id=\"51-データ収集の複雑さと課題\"\u003e5.1 データ収集の複雑さと課題\u003c/h2\u003e\n\u003cp\u003eデータ分析基盤の構築において最も困難な工程がデータ収集です。前章で説明したデータレイクに生のデータを保存する前段階として様々なシステムからデータを取り込むのがこの工程です。\u003c/p\u003e\n\u003cp\u003e現代の企業では様々なシステムが連携して稼働しています。顧客管理システム、マーケティングツール、在庫管理システム、受発注管理システム、アクセス解析…などです。これらのシステムはそれぞれ異なる技術で構築されておりデータの形式・更新頻度・アクセス方法など全く違うことがほとんどでしょう。\u003c/p\u003e\n\u003cp\u003eデータを取り込む工程が複雑な理由は大きく4つあります。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eデータ形式の多様性\u003c/strong\u003e：CSV・JSON・XML・固定長テキスト・バイナリファイルなど様々な形式が混在\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eアクセス方法の違い\u003c/strong\u003e：データベース直接接続・REST API・FTPサーバー・メール添付など多様な取得経路\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e更新スケジュールの違い\u003c/strong\u003e：リアルタイム更新から月次更新まで時間軸が大きく異なる\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eデータ量の違い\u003c/strong\u003e：数MBの小規模なファイルから数TBまでデータ量が段違い\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e従来は各システムの担当者が個別にデータを抽出し手動でやり取りしていました。しかしこの方法では人為的なミス・作業の遅延・データの不整合が頻発します。データ分析基盤では全てのデータソースを自動的かつ確実に取り込むための仕組みが必要不可欠です。\u003c/p\u003e\n\u003ch2 id=\"52-データソースの種類と特徴\"\u003e5.2 データソースの種類と特徴\u003c/h2\u003e\n\u003cp\u003eデータを取り込むという観点から、企業内で扱うデータソースは大きく4つのカテゴリに分類して紹介します。それぞれ異なる取り込み方法と注意点があります。\u003c/p\u003e\n\u003ch3 id=\"社内業務システム\"\u003e社内業務システム\u003c/h3\u003e\n\u003cp\u003e社内の基幹システムは最も重要なデータソースです。販売管理、在庫管理、会計、人事そして自社ITサービスのデータベースなどが該当します。\u003c/p\u003e\n\u003cp\u003eこれらのシステムの特徴は高い信頼性と一定の更新パターンです。たとえば在庫データであれば出荷処理後に比較的リアルタイムに更新されることが多いでしょう。一方で営業のデータは営業時間中リアルタイムに更新されるよりも営業時間終了後にまとめて確定・更新されることは珍しくありません。さらに会計データであれば月末月初に処理が集中しやくすく締め処理もこのタイミングです。このような更新タイミングを理解してデータ取り込みスケジュールを設計することが重要です。\u003c/p\u003e\n\u003cp\u003e取り込み方法はシステムによって異なります。データベースへの直接接続できたり専用のAPIが用意されていればやりやすいケースです。データベースからCSVファイルを出力して転送するというケースも珍しくありません。業務システムは古いことも多く、現代ではあまり使われないファイル形式や文字コードを扱う必要や互換性の確保が課題となります。\u003c/p\u003e\n\u003ch3 id=\"外部webサービスapi\"\u003e外部Webサービス・API\u003c/h3\u003e\n\u003cp\u003eSaaSや広告配信プラットフォームなど外部のサービスから提供されるデータです。現代の企業運営では多くの外部サービスを連携して使うことも多いため、小さい企業でも複数の外部サービスを利用することは珍しくありません。\u003c/p\u003e\n\u003cp\u003e外部サービスからデータを取得するには方法や形式、制限を調査する必要があります。最近のサービスであればREST API形式でアクセスできることが多いですが、GUI上からしかアクセスできない場合は自動化が難しいケースもあるでしょう。そもそもまとめてデータの取得ができないということもあります。\u003c/p\u003e\n\u003cp\u003eまたAPIだとしてもほとんどの場合で制約事項が存在します。APIの呼び出し回数の上限や、データ取得量の制限、認証トークンの更新、サービス停止時の対応などを考慮する必要があります。また外部サービスの仕様変更により突然データ取得ができなくなるリスクもあります。\u003c/p\u003e\n\u003cp\u003eこのような多様な接続形式や仕様の変更に対応できるような柔軟な仕組みと体制が必要になります。自分たちで接続するシステムを開発するだけでなく、データ分析基盤が用意しているコネクターを利用したり外部サービスと連携するサービスの利用を検討してもよいでしょう。\u003c/p\u003e\n\u003ch3 id=\"ファイルデータ\"\u003eファイルデータ\u003c/h3\u003e\n\u003cp\u003ePDFや画像、動画などのファイル形式で提供されるデータです。請求書など外部から送られてきたPDFファイル、経費の精算に使うレシートの画像データ、議事録の録画ファイルなどがさまざまなものがあります。\u003c/p\u003e\n\u003cp\u003eファイルのデータはさまざまな経路から発生するうえデータの性質に応じて個別の対応が求められます。特に保存する場所や形式には注意が必要です。動画などデータのサイズが大きい場合はストレージがすぐに満杯になってしまったり、従量課金制の場合は気がついたらストレージだけで予算を使い切ってしまいます。\u003c/p\u003e\n\u003cp\u003eファイル形式の場合はデータベースのように構造化されたデータをもっていないため、何らかの処理を通して構造化されたデータをデータウェアハウスに保存することが多くあります。たとえば、音声から文字起こししたり画像からOCRするようなパターンです。この場合は処理の内容があとから変更されることも少なくないのでなるべく元データを保存することが望ましいでしょう。\u003c/p\u003e\n\u003ch3 id=\"リアルタイムストリームデータ\"\u003eリアルタイムストリームデータ\u003c/h3\u003e\n\u003cp\u003eIoTセンサー・Webサイトのログデータ・金融取引データなど連続的に生成されるデータです。\u003c/p\u003e\n\u003cp\u003eストリームデータの特徴は高頻度・小容量・時系列性です。常にデータが連続的に流れ込みます。データの順序や時刻情報が重要でありネットワーク遅延や重複配信への対応が必要です。\u003c/p\u003e\n\u003cp\u003eストリームデータの取り扱いは他のケースに比べて技術的に難易度が高くなります。取り込みには専用のメッセージングシステムが使用されることが一般的です。AWSのKinesisやGoogle CloudのPub/Subなどが挙げられます。\u003c/p\u003e\n\u003cp\u003e他のデータの形式と違ってリアルタイムに取得されたデータが常に網羅的であるとは限らないという点が厄介です。例えば、スマホアプリのログデータであれば端末がネットワークにつながっていないときはログが送信されてこないため後からログが到着するという事象が起きます。データの取得に遅延がなくとも、分析にすぐさま使えるかどうかは別の問題となります。\u003c/p\u003e\n\u003ch2 id=\"53-バッチ処理とストリーミング処理\"\u003e5.3 バッチ処理とストリーミング処理\u003c/h2\u003e\n\u003cp\u003eデータの収集にあたってどのようなデータがあるのか俯瞰したところで、次はどのようにしてデータを取り込むのか？という観点からいくつか重要なポイントを紹介します。\u003c/p\u003e\n\u003cp\u003eデータ取り込み方式には大きく分けてバッチ処理とストリーミング処理があります。どちらを選択するかはデータの性質と業務要件によって決まります。\u003c/p\u003e\n\u003ch3 id=\"バッチ処理\"\u003eバッチ処理\u003c/h3\u003e\n\u003cp\u003eバッチ処理は決められた時間にまとまったデータを一括で処理する方式です。「毎日午前3時に前日分の売上データを取り込む」とか「月末に1ヶ月分の会計データを取得する」といったように決まった時間や間隔で定期に処理をおこないます\u003c/p\u003e\n\u003cp\u003eバッチ処理の利点はシンプルな設計と処理効率の高さです。まとまった処理ロジックを構築できるため比較的実装をシンプルにしやすく運用管理も容易になります。エラーが発生した場合の再実行やリトライも簡単に実装できます。また、大量のデータを一度に処理するため処理の効率も向上します。\u003c/p\u003e\n\u003cp\u003e一方でバッチ処理の欠点はリアルタイム性です。決まった時間に実行されるため、その時間までは最新のデータが反映されません。更新頻度を高めることでこの問題はある程度解決することはできますが高いリアルタイム性が求められる場合はバッチ処理だと限界があるでしょう。\u003c/p\u003e\n\u003cp\u003eまた、データ量が非常に大きい場合もバッチ処理が難しい場合があります。バッチ処理のためには一度にデータを取り込む必要があるためメモリに乗らないデータ量となると途端に処理が難しくなります。スケールできるシステムであればある程度は解決しますが実装が複雑になるためストリーミング処理をおこなったほうが便利な場面もでてきます。\u003c/p\u003e\n\u003ch3 id=\"ストリーミング処理\"\u003eストリーミング処理\u003c/h3\u003e\n\u003cp\u003eストリーミング処理はデータの追加や変更をリアルタイムかつ連続的に処理する方式です。WebサイトのアクセスログやIoTセンサーデータなど刻一刻と変化するデータに適しています。\u003c/p\u003e\n\u003cp\u003eストリーミング処理の一番のメリットはリアルタイム性です。発生したデータをリアルタイムに分析結果へと反映させることができます。広告やリリースの効果検証のように施策を実行したあと素早くデータを取得して分析したいときに有用です。\u003c/p\u003e\n\u003cp\u003e加えて、継続的に処理するという点もメリットがあります。小さなデータを連続処理するためシステム負荷が平準化されます。バッチ処理でデータが大きすぎて処理が詰まるような事態を解消することができます。\u003c/p\u003e\n\u003cp\u003e一方でストリーミング処理の欠点は設計・運用の複雑さです。データの順序や重複処理の回避、障害時の復旧など考慮すべき点が多数あります。処理中断によるデータ欠損のリスクもあります。\u003c/p\u003e\n\u003cp\u003eまた、リアルタイムといっても完全にデータの発生から瞬時にデータが得られるわけではありません。システムの構成にもよりますが数秒から数分の遅延があることが一般的です。\u003c/p\u003e\n\u003ch3 id=\"適切な選択基準\"\u003e適切な選択基準\u003c/h3\u003e\n\u003cp\u003eどちらを選択するかは以下の観点で判断します。\u003c/p\u003e\n\u003cp\u003e1つはデータの鮮度です。リアルタイムな分析が必要ならストリーミングが必要になりますが、日次や週次レポートで十分ならバッチを選択します。\u003c/p\u003e\n\u003cp\u003e2つ目はシステムの運用のしやすさです。処理のわかりやすさや障害発生時の対応のしやすさを重視するならバッチが適しています。\u003c/p\u003e\n\u003cp\u003e3つ目はデータの量です。センサーやアクセスログのようにデータ量が非常に大きく継続的に更新されている場合はバッチよりもストリーミング処理したほうが効率がよいでしょう。\u003c/p\u003e\n\u003cp\u003e実際の運用では両方を組み合わせることが一般的です。顧客データなど日次で十分なデータはバッチで処理し、日次よりもリアルタイム性が求められるデータや連続的かつ大量に発生するログデータはストリーミング処理にするといったハイブリッド構成になります。\u003c/p\u003e\n\u003ch2 id=\"54-データ取り込みパターン全件-vs-増分cdc\"\u003e5.4 データ取り込みパターン（全件 vs 増分・CDC）\u003c/h2\u003e\n\u003cp\u003e効率的なデータ取り込みのために適切な取り込みパターンを選択することが重要です。主要なパターンを3つ紹介します。\u003c/p\u003e\n\u003ch3 id=\"全件取り込み\"\u003e全件取り込み\u003c/h3\u003e\n\u003cp\u003e毎回データソースから全てのデータを取り込む最もシンプルな方式です。「毎日商品マスタの全件を取り込む」「毎月CRMの全データをコピーする」といった処理が該当します。\u003c/p\u003e\n\u003cp\u003e全件取り込みの利点は実装の簡単さと確実性です。すべてのデータを丸ごと取得して保存するだけなので複雑な差分処理が不要で過去データの修正や削除も確実に反映されます。また障害からの復旧時も最新の全件データを取り込むだけで完全に復元できます。\u003c/p\u003e\n\u003cp\u003e一方で欠点は処理時間と負荷の大きさです。データ量が増加すると1回あたりの処理に必要な計算資源や処理時間が増えますしネットワーク帯域なども大量に消費します。また、毎回同じデータを転送するため効率は悪くなります。\u003c/p\u003e\n\u003ch3 id=\"増分差分取り込み\"\u003e増分・差分取り込み\u003c/h3\u003e\n\u003cp\u003e新しく追加されたり更新されたデータのみを取り込む方式です。「前回取り込みをおこなった昨日の17時以降に追加・更新された注文データのみ取得する」といった処理が該当します。\u003c/p\u003e\n\u003cp\u003e増分取り込みの利点は処理効率とリソース節約です。前に取得したときとの差分しか処理しないので転送するデータ量と処理時間を大幅に削減できます。そのため頻繁な取り込み処理も可能になりデータの鮮度を向上させやすくなります。\u003c/p\u003e\n\u003cp\u003eしかし、増分・差分取り込みは管理が複雑になりがちです。どのデータが更新されたかを判定する仕組み・処理済みデータの管理・取り込み失敗時の差分データの処理などを考慮する必要があります。要件が複雑になるためデータ更新の定義の誤りで過去データの修正や削除を見落とすというケースは珍しくありません。\u003c/p\u003e\n\u003ch3 id=\"cdc--ストリーミング\"\u003eCDC + ストリーミング\u003c/h3\u003e\n\u003cp\u003eCDCとはChange Data Captureの略でデータベースの変更をリアルタイムで検知する技術です。CDCで検知した変更内容をそのままストリーミングで取り込むのがこの方式です。データベースのトランザクションログを監視して挿入・更新・削除の操作を即座に反映します。\u003c/p\u003e","title":"データ収集・取り込み"},{"content":"6.1 なぜデータ品質管理が重要なのか データ分析基盤がどれほど高度な技術で構築されていても中に格納されているデータの品質が低ければその分析結果は信頼できません。「Garbage In, Garbage Out」という言葉があるように質の悪いデータからは質の悪い結果しか得られません。\n企業の意思決定においてデータの信頼性は死活問題です。売上予測が不正確なデータに基づいていれば在庫の過剰発注や機会損失を招きます。顧客分析のデータに重複や欠損があれば間違ったターゲティングによりマーケティング投資が無駄になります。\n従来の部門別システムでは各担当者が個別に品質管理を行っていました。しかし全社統一のデータ分析基盤では複数の部門の多数のデータソースから収集したデータが混在するため従来の手法では限界があります。システム的な品質管理の仕組みがなければデータの信頼性を担保できません。\nデータ品質の問題は発見が遅れるほど影響範囲が拡大します。元データの段階で発見できれば修正は比較的簡単ですが分析結果として経営層に報告された後に問題が発覚すれば信頼回復には長期間を要します。そのため予防的な品質管理体制の構築が不可欠です。\n加えて、現代ではデータの取り扱いに関する法的規制も厳しくなっています。個人情報保護法やGDPRなどの法的要件を満たすためにも適切なデータ管理が求められています。\n6.2 品質管理で実現したいこと データ品質管理の最終目標は組織全体がデータを安心して使える環境を構築することです。どの部門の誰がデータを見ても同じ理解ができ迅速で正確な意思決定を支援する状態を目指します。重要なのは信頼性と一貫性です。\n信頼性の確保 信頼性とはデータが正確で完全であり間違いがない状態です。売上のデータであれば金額の計算ミスがなく取引先名の表記に誤りがなく必要な注文の項目がすべて記録されているような状態を目指します。\n信頼性を実現するためによく使われる手段の1つは自動的なデータ検証の仕組みです。数値データが妥当な範囲にあることをチェックしたり、必須項目が空欄でないことを確認したり、入力された項目のフォーマットの妥当性検証などを実行します。異常値が検出された場合は記録しておきダッシュボードで確認したりアラートを発信します。同時に障害やミスが発生した場合でも迅速に復旧できる体制を整備します。バックアップからの復元手順・データ修正のワークフロー・影響範囲の調査方法などを標準化し属人化を防ぎます。\n重要なのはそもそも間違ったデータが生まれにくくする仕組みづくりです。間違って入力されたデータを後から修正するのは簡単ではありません。データ入力時に制約を設定したり自動計算による手計算の排除、システム間連携の自動化、標準化されたデータ変換処理などにより人為的なエラーの発生機会を根本的に減らします。予防的なアプローチにより問題の発生そのものを抑制することが最も効果的な信頼性の向上策です。\n一貫性の維持 一貫性とは「同じ概念や指標が組織全体で統一されている状態」を指します。「売上」という指標を営業部・マーケティング部・経営企画部が見た時に全く同じ定義と計算方法で算出され全く同じ数値を認識している状態です。\n一貫性を実現するためには全社で統一されたデータベースが必要です。営業部とマーケティング部が同じ顧客について分析する際にそれぞれ異なるデータベースを使用していては分析結果に矛盾が生じてしまいます。特に顧客や商品などのマスターデータは社内で散逸しやすいため一元管理することで計算の根拠となるデータを明確にし一貫したデータ分析の結果が得られます。計算の基礎となる情報ほど一元管理し各システムで共通利用することで情報の不整合が防げます。\nまた、指標の定義と計算式の明文化も同様に重要です。「売上」「利益」「顧客数」といった基本指標について全社統一の定義書を作成し関係者全員が同じ理解を共有します。データの変換・集計ロジックも統一化し売上の集計方法・顧客分類のルール・在庫評価の基準などを標準化することで誰が処理しても同じ結果になるようにします。\n6.3 基本的なデータ品質の観点 データ品質を体系的に管理するための評価軸はさまざまな考え方がありますが、ここでは基本となる6つの観点を紹介します。\n完全性（Completeness）\n必要なデータがすべて存在し欠損がない状態です。顧客マスタで会社名・担当者名・連絡先がすべて記録されている状態が完全性を満たしています。改善施策として入力必須項目の設定・デフォルト値の自動設定・欠損率の監視などがあります。\n正確性（Accuracy）\nデータが現実の状況を正しく反映している状態です。顧客の住所が実際の所在地と一致している・商品の価格が最新の定価と同じという状態が正確性を満たしています。改善施策として元データとの照合・外部データソースとの突合・異常値検出などがあります。\n一意性（Uniqueness）\n重複データが存在せず各レコードが唯一である状態です。顧客マスタで同じ会社が複数のIDで登録されていない状態が一意性を満たしています。改善施策として重複検出アルゴリズム・一意制約の設定・データ統合時の重複排除などがあります。\n整合性（Consistency）\n関連するデータ間で矛盾がない状態です。注文データと出荷データで数量が一致している・複数システム間で同じ情報が同じ値になっている状態が整合性を満たしています。改善施策として関連データの照合チェック・システム間同期の強化・データ変換ロジックの標準化などがあります。\n適時性（Timeliness）\nデータが適切なタイミングで更新され最新の情報を反映している状態です。在庫データが出荷と同時に更新される・売上データが翌日には確認できる状態が適時性を満たしています。改善施策としてリアルタイム更新の仕組み・バッチ処理の高速化・処理遅延の監視などがあります。\n妥当性（Validity）\nデータが定義されたルールや制約に従っている状態です。郵便番号が正しい形式・年齢が妥当な範囲・ステータスが定義済みの値という状態が妥当性を満たしています。改善施策として入力値の検証・マスタデータとの照合・業務ルールに基づく妥当性判定などがあります。\n6つの観点の活用方法\nこれら6つの観点は常にすべてを同じように扱う必要はありません。必要に応じて組み合わせることで効果的なデータ品質管理を実現できます。まず自社のデータ活用目的に応じて重要度の優先順位を決定します。日常的な業務においてリアルタイム分析が必要なデータでは適時性を最重視し、経営判断のような影響が大きい意思決定に使う場合では正確性と完全性を優先する、といった使い分けが重要です。また、各データソースの特性に合わせて重点的にチェックする観点を選択し効率的な品質管理体制を構築します。\n6.4 メタデータの管理 メタデータとは「データについてのデータ」を指します。メタデータとはデータについてのデータのことを指し、データがどのようなものなのか説明しているものです。テーブル名や列の名前・説明文、更新日次、更新頻度、計算ロジックなどがあります。\nメタデータが適切に管理されていないとデータの扱い方がわからない状況が発生します。データ分析基盤を管理する側もそれぞれのデータが何者かわかりやすくなっていることは運用の効率を向上させます。メタデータはデータの品質そのものではありませんが品質管理に直結する重要な存在です。\nデータの意味と定義の明確化 テーブルや列の名前および説明は重要なメタデータです。わかりやすいテーブルや列の名前をつけたり、それぞれがどのようなデータなのか素性や計算ロジックを明文化します。\n例えば、データをソースが何で前処理はどんなことをしているのかなどを記載すると便利でしょう。データマートならば用途や目的があるので、それらを踏まえてどのような集計や結合がされているのかロジックがわかるものが望ましいです。\n計算の定義をドキュメント化し共有することで社内の認識を統一することができるというメリットもあります。同じ項目名でも部門によって異なる意味で使われることがあります。「売上」という項目が営業部では受注金額を指し経営企画部では入金金額を指すといったすれ違いは珍しくありません。\nメタデータ管理では各データ項目の正確な定義を言語化します。売上データであれば「税抜き受注金額で返品・キャンセルを除く」といった具体的な定義を記録します。また計算方法・集計ルール・除外条件なども明記します。定義の共有により全社で統一された理解を実現します。新しい担当者がデータを利用する際も定義を確認することで正しい使い方を理解できます。\nデータリネージュ（Data Lineage）の追跡 データリネージュとは元データから現在の形に至るまでの処理の過程を可視化しデータの背景と文脈を把握しやすくするものです。売上分析レポートの数値が元々どのシステムのどのテーブルから生成され途中でどのような計算が行われたかを視覚的にわかりやすくなります。\nデータリネージュが管理されていると問題発生時の影響範囲調査が迅速に行えます。元データに問題が発見された場合そのデータを使用している全ての分析結果を特定し修正の必要性を判断できます。データリネージュがない場合は処理に使われているコードから読み解いて影響範囲を追跡する必要があり、依存関係が複雑になりやすいデータ分析基盤では調査コストが跳ね上がります。\nまた規制対応という観点でも重要な役割を果たします。個人情報に対応する必要がある場合、その情報がどのテーブルで参照されているのかリネージュから特定することができるため素早く適切に対応することが可能です。\n使いやすさの向上 メタデータの適切な管理はデータ分析基盤の使いやすさを改善するにあたって非常に重要な存在です。使いやすさとは「必要な時に必要なデータを簡単に見つけて理解して信頼して利用できる状態」を指します。営業部が自分たちの地域の売上データをみたいと考えたときに素早く目的のデータを見つけ出し、どのようなロジックで集計されたものなのか把握して、その値が間違っていないだろうと判断できることです。\nメタデータを利用したデータカタログによる検索・参照機能はデータの見つけやすさを改善します。業務領域や利用用途を用いた絞り込み機能により目的に応じたデータを素早く見つけられるようにします。また、キーワード検索やタグ機能により目的のデータを効率的に発見できる環境を構築します。\nデータの理解しやすさを改善するためにもメタデータは重要です。各集計値の正確な定義・計算方法・集計ルールを明確に文書化しておけば「このデータは何を意味するのか」「どのような処理で生成されたのか」を即座に理解できるようにしますし、データリネージュがあればデータの背景と文脈を視覚的に把握できます。\nまた、データの更新頻度や最終更新日時、作成者などの情報はデータの信頼度につながります。誰がいつ作ったのかわからないデータでは気軽に使うことはできません。責任者が明確になっており最新のデータであることが明確にわかって初めて安心して使うことができます。\nしかし、メタデータの管理は言うは易く行うは難し。日々変わり続けるビジネスとデータ構造に追随し続けるのは容易ではありません。掛けられるコストや利用状況に応じて効率化を図ることが重要でしょう。\n6.5 品質チェックと監視の仕組み データ品質を継続的に維持するためには自動化された監視の仕組みが不可欠です。人手による品質チェックでは限界があるため技術的な支援が必要です。\n品質チェックと監視の仕組み構築では「予防・検出・改善」の3つのステップを意識するとよいでしょう。まず予防的な観点からデータ入力時の制約設定や自動計算によりそもそも問題が発生しにくい仕組みを構築します。次に検出の観点から自動品質チェックとダッシュボード監視により問題を早期発見します。最後に改善の観点から発見された問題を優先度に基づいて計画的に解決し再発防止策を講じます。この3段階を連携させることで持続可能な品質管理体制を実現できます。\n自動品質チェックの実装 データが分析基盤に取り込まれる際に自動的に品質チェックを実行します。チェックする処理を行い結果を記録、必要に応じてアラートをだします。\n分析基盤全体でまずチェックするべき項目として処理の成否・実行時間や遅延の確認があります。バッチ処理であれば実行が予定通りの実行時間で開始され遅延なく終わっているか確認します。成功していても何度もリトライしているならばメモリ不足やネットワークの不調が考えられますし、いつもより実行時間が長ければ把握していない問題が起きているかもしれません。ストリーミングは配信のレイテンシが適正な範囲か確認します。データ配信の遅延がいつ発生したのかわかれば対策も立てやすくなりますので時系列で把握できるようにしておくとよいでしょう。\n個別のデータに応じてチェック項目を設けることもあります。具体的なチェック項目として、数値データの範囲チェック（年齢が0-200の範囲内）やフォーマット検証（メールアドレスが正しい形式）などが挙げられます。さらに集計処理の結果に対する妥当性チェックも重要です。集計後のデータ件数やNULL値の出現チェックなどを自動で実行し集計処理の正確性を保証します。チェック処理が完了したら問題があるデータの件数などを保存しておくことで後から追跡できるようにしておきます。\nチェック結果はログに保存し問題が検出された場合は担当者にアラート通知を送信します。メールやチャットサービスと連携させることで素早くチームメンバーが気がつける状態にしておくとよいでしょう。品質チェックの結果はダッシュボードで可視化することで各データソースの品質状況をリアルタイムで監視できるようにします。また、問題が検出されてなくとも定期的に振り返るようにしましょう。そうすることでアラートが出るほどではない緩やかな処理時間や配信遅延の悪化に気がついて予防的に対策できるかもしれません。\nここでは分析基盤側としてのチェック機能を解説しましたが、もちろん可能であればデータソース側で入力された時点でチェックする機能があるのが最も望ましいことはいうまでもありません。\n利用状況の把握 利用状況の把握は優先度決定に不可欠な情報です。どのデータが誰によってどの程度の頻度で利用されているか把握することで限られたリソースを効果的に配分できます。また、利用状況から実際に求められているデータ品質の課題や改善すべきポイントが見えてきます。\n頻繁にアクセスされるデータの品質改善は優先度が高くなります。利用頻度の高いデータで品質問題が発見された場合は迅速に修正作業を行い、元データからの再処理やデータクレンジングの強化などの改善施策を積極的に適用します。一方で、利用頻度が低いデータは改善の優先度を下げつつコストと効果のバランスを考慮して対応を判断します。実際のところ、利用者数だけでなく利用している部門や用途の重要度、影響範囲などを考慮して優先度を決めることになるでしょう。\n分析で利用されているパターンを理解することでテーブル構造や設定を最適化していきます。データマートを中心に分析用のテーブルは利用部門などの意見をもとに作成しますが、事前に決めた仕様と実際の利用状況が異なるのはよくあることです。そこで、実際の分析のログを解析することで頻繁に参照されているテーブルや列、テーブルの結合、集計方法などを検証します。よく一緒に参照される項目であれば同じテーブルにまとめたものを作成して処理にかかる計算リソースを削減しつつ標準化をおこないます。逆に、ほとんど使われない項目は別テーブルに分離してメインテーブルのパフォーマンスを最適化することを検討します。\n","permalink":"https://kenjiusui.github.io/blog/books/data-platform-intro/06_data_quality_metadata/","summary":"\u003ch2 id=\"61-なぜデータ品質管理が重要なのか\"\u003e6.1 なぜデータ品質管理が重要なのか\u003c/h2\u003e\n\u003cp\u003eデータ分析基盤がどれほど高度な技術で構築されていても中に格納されているデータの品質が低ければその分析結果は信頼できません。「Garbage In, Garbage Out」という言葉があるように質の悪いデータからは質の悪い結果しか得られません。\u003c/p\u003e\n\u003cp\u003e企業の意思決定においてデータの信頼性は死活問題です。売上予測が不正確なデータに基づいていれば在庫の過剰発注や機会損失を招きます。顧客分析のデータに重複や欠損があれば間違ったターゲティングによりマーケティング投資が無駄になります。\u003c/p\u003e\n\u003cp\u003e従来の部門別システムでは各担当者が個別に品質管理を行っていました。しかし全社統一のデータ分析基盤では複数の部門の多数のデータソースから収集したデータが混在するため従来の手法では限界があります。システム的な品質管理の仕組みがなければデータの信頼性を担保できません。\u003c/p\u003e\n\u003cp\u003eデータ品質の問題は発見が遅れるほど影響範囲が拡大します。元データの段階で発見できれば修正は比較的簡単ですが分析結果として経営層に報告された後に問題が発覚すれば信頼回復には長期間を要します。そのため予防的な品質管理体制の構築が不可欠です。\u003c/p\u003e\n\u003cp\u003e加えて、現代ではデータの取り扱いに関する法的規制も厳しくなっています。個人情報保護法やGDPRなどの法的要件を満たすためにも適切なデータ管理が求められています。\u003c/p\u003e\n\u003ch2 id=\"62-品質管理で実現したいこと\"\u003e6.2 品質管理で実現したいこと\u003c/h2\u003e\n\u003cp\u003eデータ品質管理の最終目標は組織全体がデータを安心して使える環境を構築することです。どの部門の誰がデータを見ても同じ理解ができ迅速で正確な意思決定を支援する状態を目指します。重要なのは信頼性と一貫性です。\u003c/p\u003e\n\u003ch3 id=\"信頼性の確保\"\u003e信頼性の確保\u003c/h3\u003e\n\u003cp\u003e信頼性とはデータが正確で完全であり間違いがない状態です。売上のデータであれば金額の計算ミスがなく取引先名の表記に誤りがなく必要な注文の項目がすべて記録されているような状態を目指します。\u003c/p\u003e\n\u003cp\u003e信頼性を実現するためによく使われる手段の1つは自動的なデータ検証の仕組みです。数値データが妥当な範囲にあることをチェックしたり、必須項目が空欄でないことを確認したり、入力された項目のフォーマットの妥当性検証などを実行します。異常値が検出された場合は記録しておきダッシュボードで確認したりアラートを発信します。同時に障害やミスが発生した場合でも迅速に復旧できる体制を整備します。バックアップからの復元手順・データ修正のワークフロー・影響範囲の調査方法などを標準化し属人化を防ぎます。\u003c/p\u003e\n\u003cp\u003e重要なのはそもそも間違ったデータが生まれにくくする仕組みづくりです。間違って入力されたデータを後から修正するのは簡単ではありません。データ入力時に制約を設定したり自動計算による手計算の排除、システム間連携の自動化、標準化されたデータ変換処理などにより人為的なエラーの発生機会を根本的に減らします。予防的なアプローチにより問題の発生そのものを抑制することが最も効果的な信頼性の向上策です。\u003c/p\u003e\n\u003ch3 id=\"一貫性の維持\"\u003e一貫性の維持\u003c/h3\u003e\n\u003cp\u003e一貫性とは「同じ概念や指標が組織全体で統一されている状態」を指します。「売上」という指標を営業部・マーケティング部・経営企画部が見た時に全く同じ定義と計算方法で算出され全く同じ数値を認識している状態です。\u003c/p\u003e\n\u003cp\u003e一貫性を実現するためには全社で統一されたデータベースが必要です。営業部とマーケティング部が同じ顧客について分析する際にそれぞれ異なるデータベースを使用していては分析結果に矛盾が生じてしまいます。特に顧客や商品などのマスターデータは社内で散逸しやすいため一元管理することで計算の根拠となるデータを明確にし一貫したデータ分析の結果が得られます。計算の基礎となる情報ほど一元管理し各システムで共通利用することで情報の不整合が防げます。\u003c/p\u003e\n\u003cp\u003eまた、指標の定義と計算式の明文化も同様に重要です。「売上」「利益」「顧客数」といった基本指標について全社統一の定義書を作成し関係者全員が同じ理解を共有します。データの変換・集計ロジックも統一化し売上の集計方法・顧客分類のルール・在庫評価の基準などを標準化することで誰が処理しても同じ結果になるようにします。\u003c/p\u003e\n\u003ch2 id=\"63-基本的なデータ品質の観点\"\u003e6.3 基本的なデータ品質の観点\u003c/h2\u003e\n\u003cp\u003eデータ品質を体系的に管理するための評価軸はさまざまな考え方がありますが、ここでは基本となる6つの観点を紹介します。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e完全性（Completeness）\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e必要なデータがすべて存在し欠損がない状態です。顧客マスタで会社名・担当者名・連絡先がすべて記録されている状態が完全性を満たしています。改善施策として入力必須項目の設定・デフォルト値の自動設定・欠損率の監視などがあります。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e正確性（Accuracy）\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eデータが現実の状況を正しく反映している状態です。顧客の住所が実際の所在地と一致している・商品の価格が最新の定価と同じという状態が正確性を満たしています。改善施策として元データとの照合・外部データソースとの突合・異常値検出などがあります。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e一意性（Uniqueness）\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e重複データが存在せず各レコードが唯一である状態です。顧客マスタで同じ会社が複数のIDで登録されていない状態が一意性を満たしています。改善施策として重複検出アルゴリズム・一意制約の設定・データ統合時の重複排除などがあります。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e整合性（Consistency）\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e関連するデータ間で矛盾がない状態です。注文データと出荷データで数量が一致している・複数システム間で同じ情報が同じ値になっている状態が整合性を満たしています。改善施策として関連データの照合チェック・システム間同期の強化・データ変換ロジックの標準化などがあります。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e適時性（Timeliness）\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eデータが適切なタイミングで更新され最新の情報を反映している状態です。在庫データが出荷と同時に更新される・売上データが翌日には確認できる状態が適時性を満たしています。改善施策としてリアルタイム更新の仕組み・バッチ処理の高速化・処理遅延の監視などがあります。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e妥当性（Validity）\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eデータが定義されたルールや制約に従っている状態です。郵便番号が正しい形式・年齢が妥当な範囲・ステータスが定義済みの値という状態が妥当性を満たしています。改善施策として入力値の検証・マスタデータとの照合・業務ルールに基づく妥当性判定などがあります。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e6つの観点の活用方法\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eこれら6つの観点は常にすべてを同じように扱う必要はありません。必要に応じて組み合わせることで効果的なデータ品質管理を実現できます。まず自社のデータ活用目的に応じて重要度の優先順位を決定します。日常的な業務においてリアルタイム分析が必要なデータでは適時性を最重視し、経営判断のような影響が大きい意思決定に使う場合では正確性と完全性を優先する、といった使い分けが重要です。また、各データソースの特性に合わせて重点的にチェックする観点を選択し効率的な品質管理体制を構築します。\u003c/p\u003e\n\u003ch2 id=\"64-メタデータの管理\"\u003e6.4 メタデータの管理\u003c/h2\u003e\n\u003cp\u003eメタデータとは「データについてのデータ」を指します。メタデータとはデータについてのデータのことを指し、データがどのようなものなのか説明しているものです。テーブル名や列の名前・説明文、更新日次、更新頻度、計算ロジックなどがあります。\u003c/p\u003e\n\u003cp\u003eメタデータが適切に管理されていないとデータの扱い方がわからない状況が発生します。データ分析基盤を管理する側もそれぞれのデータが何者かわかりやすくなっていることは運用の効率を向上させます。メタデータはデータの品質そのものではありませんが品質管理に直結する重要な存在です。\u003c/p\u003e\n\u003ch3 id=\"データの意味と定義の明確化\"\u003eデータの意味と定義の明確化\u003c/h3\u003e\n\u003cp\u003eテーブルや列の名前および説明は重要なメタデータです。わかりやすいテーブルや列の名前をつけたり、それぞれがどのようなデータなのか素性や計算ロジックを明文化します。\u003c/p\u003e\n\u003cp\u003e例えば、データをソースが何で前処理はどんなことをしているのかなどを記載すると便利でしょう。データマートならば用途や目的があるので、それらを踏まえてどのような集計や結合がされているのかロジックがわかるものが望ましいです。\u003c/p\u003e\n\u003cp\u003e計算の定義をドキュメント化し共有することで社内の認識を統一することができるというメリットもあります。同じ項目名でも部門によって異なる意味で使われることがあります。「売上」という項目が営業部では受注金額を指し経営企画部では入金金額を指すといったすれ違いは珍しくありません。\u003c/p\u003e\n\u003cp\u003eメタデータ管理では各データ項目の正確な定義を言語化します。売上データであれば「税抜き受注金額で返品・キャンセルを除く」といった具体的な定義を記録します。また計算方法・集計ルール・除外条件なども明記します。定義の共有により全社で統一された理解を実現します。新しい担当者がデータを利用する際も定義を確認することで正しい使い方を理解できます。\u003c/p\u003e\n\u003ch3 id=\"データリネージュdata-lineageの追跡\"\u003eデータリネージュ（Data Lineage）の追跡\u003c/h3\u003e\n\u003cp\u003eデータリネージュとは元データから現在の形に至るまでの処理の過程を可視化しデータの背景と文脈を把握しやすくするものです。売上分析レポートの数値が元々どのシステムのどのテーブルから生成され途中でどのような計算が行われたかを視覚的にわかりやすくなります。\u003c/p\u003e\n\u003cp\u003eデータリネージュが管理されていると問題発生時の影響範囲調査が迅速に行えます。元データに問題が発見された場合そのデータを使用している全ての分析結果を特定し修正の必要性を判断できます。データリネージュがない場合は処理に使われているコードから読み解いて影響範囲を追跡する必要があり、依存関係が複雑になりやすいデータ分析基盤では調査コストが跳ね上がります。\u003c/p\u003e\n\u003cp\u003eまた規制対応という観点でも重要な役割を果たします。個人情報に対応する必要がある場合、その情報がどのテーブルで参照されているのかリネージュから特定することができるため素早く適切に対応することが可能です。\u003c/p\u003e\n\u003ch3 id=\"使いやすさの向上\"\u003e使いやすさの向上\u003c/h3\u003e\n\u003cp\u003eメタデータの適切な管理はデータ分析基盤の使いやすさを改善するにあたって非常に重要な存在です。使いやすさとは「必要な時に必要なデータを簡単に見つけて理解して信頼して利用できる状態」を指します。営業部が自分たちの地域の売上データをみたいと考えたときに素早く目的のデータを見つけ出し、どのようなロジックで集計されたものなのか把握して、その値が間違っていないだろうと判断できることです。\u003c/p\u003e\n\u003cp\u003eメタデータを利用したデータカタログによる検索・参照機能はデータの見つけやすさを改善します。業務領域や利用用途を用いた絞り込み機能により目的に応じたデータを素早く見つけられるようにします。また、キーワード検索やタグ機能により目的のデータを効率的に発見できる環境を構築します。\u003c/p\u003e\n\u003cp\u003eデータの理解しやすさを改善するためにもメタデータは重要です。各集計値の正確な定義・計算方法・集計ルールを明確に文書化しておけば「このデータは何を意味するのか」「どのような処理で生成されたのか」を即座に理解できるようにしますし、データリネージュがあればデータの背景と文脈を視覚的に把握できます。\u003c/p\u003e\n\u003cp\u003eまた、データの更新頻度や最終更新日時、作成者などの情報はデータの信頼度につながります。誰がいつ作ったのかわからないデータでは気軽に使うことはできません。責任者が明確になっており最新のデータであることが明確にわかって初めて安心して使うことができます。\u003c/p\u003e\n\u003cp\u003eしかし、メタデータの管理は言うは易く行うは難し。日々変わり続けるビジネスとデータ構造に追随し続けるのは容易ではありません。掛けられるコストや利用状況に応じて効率化を図ることが重要でしょう。\u003c/p\u003e\n\u003ch2 id=\"65-品質チェックと監視の仕組み\"\u003e6.5 品質チェックと監視の仕組み\u003c/h2\u003e\n\u003cp\u003eデータ品質を継続的に維持するためには自動化された監視の仕組みが不可欠です。人手による品質チェックでは限界があるため技術的な支援が必要です。\u003c/p\u003e\n\u003cp\u003e品質チェックと監視の仕組み構築では「予防・検出・改善」の3つのステップを意識するとよいでしょう。まず予防的な観点からデータ入力時の制約設定や自動計算によりそもそも問題が発生しにくい仕組みを構築します。次に検出の観点から自動品質チェックとダッシュボード監視により問題を早期発見します。最後に改善の観点から発見された問題を優先度に基づいて計画的に解決し再発防止策を講じます。この3段階を連携させることで持続可能な品質管理体制を実現できます。\u003c/p\u003e\n\u003ch3 id=\"自動品質チェックの実装\"\u003e自動品質チェックの実装\u003c/h3\u003e\n\u003cp\u003eデータが分析基盤に取り込まれる際に自動的に品質チェックを実行します。チェックする処理を行い結果を記録、必要に応じてアラートをだします。\u003c/p\u003e\n\u003cp\u003e分析基盤全体でまずチェックするべき項目として処理の成否・実行時間や遅延の確認があります。バッチ処理であれば実行が予定通りの実行時間で開始され遅延なく終わっているか確認します。成功していても何度もリトライしているならばメモリ不足やネットワークの不調が考えられますし、いつもより実行時間が長ければ把握していない問題が起きているかもしれません。ストリーミングは配信のレイテンシが適正な範囲か確認します。データ配信の遅延がいつ発生したのかわかれば対策も立てやすくなりますので時系列で把握できるようにしておくとよいでしょう。\u003c/p\u003e\n\u003cp\u003e個別のデータに応じてチェック項目を設けることもあります。具体的なチェック項目として、数値データの範囲チェック（年齢が0-200の範囲内）やフォーマット検証（メールアドレスが正しい形式）などが挙げられます。さらに集計処理の結果に対する妥当性チェックも重要です。集計後のデータ件数やNULL値の出現チェックなどを自動で実行し集計処理の正確性を保証します。チェック処理が完了したら問題があるデータの件数などを保存しておくことで後から追跡できるようにしておきます。\u003c/p\u003e\n\u003cp\u003eチェック結果はログに保存し問題が検出された場合は担当者にアラート通知を送信します。メールやチャットサービスと連携させることで素早くチームメンバーが気がつける状態にしておくとよいでしょう。品質チェックの結果はダッシュボードで可視化することで各データソースの品質状況をリアルタイムで監視できるようにします。また、問題が検出されてなくとも定期的に振り返るようにしましょう。そうすることでアラートが出るほどではない緩やかな処理時間や配信遅延の悪化に気がついて予防的に対策できるかもしれません。\u003c/p\u003e\n\u003cp\u003eここでは分析基盤側としてのチェック機能を解説しましたが、もちろん可能であればデータソース側で入力された時点でチェックする機能があるのが最も望ましいことはいうまでもありません。\u003c/p\u003e\n\u003ch3 id=\"利用状況の把握\"\u003e利用状況の把握\u003c/h3\u003e\n\u003cp\u003e利用状況の把握は優先度決定に不可欠な情報です。どのデータが誰によってどの程度の頻度で利用されているか把握することで限られたリソースを効果的に配分できます。また、利用状況から実際に求められているデータ品質の課題や改善すべきポイントが見えてきます。\u003c/p\u003e","title":"データ品質・メタデータ管理"},{"content":"7.1 データ活用とセルフサービス環境 ここまでにデータを収集し保存、加工する技術とデータの品質について紹介してきました。しかし単にデータを保存しただけでは価値を生み出せません。分析する人が簡単にデータにアクセスし自分で分析できる環境が必要です。\nデータの活用が広まれば広まるほどデータの専門家以外でも自力でデータを分析できる環境が求められます。専門家だけであれば自分でデータベースやコードを読み解きPythonやSQLを書いて処理を行うことができますが非専門家の場合はそうもいきません。\n専門的な知識を持たないビジネス担当者でも必要な時に必要な分析を自分で実行できる環境の構築を目指します。\nBIツールによる分析環境の向上 BIツール（Business Intelligence Tool）はセルフサービスで分析できるようにするための環境作りに重要なシステムです。グラフィカルなインターフェースにより一定範囲の分析作業を効率化できます。\nBIツールのメリットはGUIベースで専門的な知識がなくてもとっつきやすいことです。画面上で分析したいデータをGUI上で選択し基本的な集計やグラフ作成を実行できます。たとえば売上データから「商品カテゴリ」を行に「販売月」を列に「売上金額」を値とすることで売上推移のクロス集計表が生成されます。\nまた、多くのデータを分析するため必要な情報を集約することで分析の効率が上げやすくなります。ダッシュボードを通じて分析結果や分析の処理を共有できたり、データカタログを通して必要なデータを素早く検索・利用できたりするため、分析に必要な情報が集約されることで分析・アクションが実行しやすくなります。また、データ分析基盤へのインターフェイスが統一されることで権限管理もしやすくなります。\nしかし複雑な分析や柔軟な条件設定が必要な場合はGUIだけでは限界があります。条件での絞り込みや複数テーブルの複雑な結合、計算式を用いた指標などは複雑になればなるほどGUIベースのBIツールだけでは実装が難しく、SQLによる直接的なデータ操作が必要になります。そのため、実際はBIツールと併せてデータ分析基盤へSQLを実行できる環境も提供し、利用者のスキルレベルに応じた分析手段を用意することが一般的です。\nデータカタログによる情報発見 大規模なデータ分析基盤では数百から数千のテーブルやレポートが存在します。分析する人が必要なデータを発見するためのデータカタログ機能が重要になります。\nデータカタログはメタデータ管理の成果を活用します。第6章で説明したようにメタデータはデータ分析を効率化させる重要な要素です。各データの定義・更新頻度・データリネージュ・利用状況といった情報が整理することで「売上」「顧客」「在庫」といったキーワード検索により関連するテーブルやレポートを素早く発見できます。\n必要なデータを自分たちで素早く探せる環境は分析する人が増えれば増えるほど有用になります。なにかのデータを探すたびに問い合わせていたら分析が進みませんしデータ分析基盤チームも問い合わせ対応ばかりで手いっぱいになってしまいます。これはデータ活用を広める段階においてボトルネックになりがちで忘れてはいけない観点です。\nさらに重要なのは見つけたデータが自分の求めているものかどうかを確認できることです。データの詳細な定義・計算方法・サンプル値が表示されるため「このテーブルの売上は税込みなのか税抜きなのか」「このテーブルの在庫データはいつ更新された値なのか」といった疑問を事前に解決できます。またデータの品質状況や信頼性レベルも併せて確認できるため分析に適したデータソースかどうか判断できるようになり分析の効率化と精度を向上します。\n協調的な分析環境 作成したレポートやダッシュボード、その処理方法を組織内で共有することで分析の効率性と正確性を大幅に向上し意思決定の質と速度を改善することができます。\n過去に他のメンバーが作成した分析手法を参考にすることでゼロから分析処理の実装を考える必要がなくなり効率的に作業を進められます。類似のビジネス課題に対する分析アプローチが蓄積されることで組織全体の分析スキルが向上され、また優秀な分析者が作成したテンプレートやベストプラクティスを活用することで分析経験の浅いメンバーでも高品質な分析を実行できるようになります。\n共有という観点でBIツールは非常に便利です。ほとんどのBIツールにはレポートやダッシュボードの共有機能がついており、これを使うことで組織内で共有することができます。特にWebサービスとして提供されているBIツールはURLだけで簡単に共有できるので手間がかかりません。\n同じダッシュボードやレポートを共有することで全員が同じ数値を参照しながら議論でき認識のズレを根本的に回避できます。この結果として現状把握から行動までのスピードと精度が飛躍的に向上します。共有されたダッシュボードを通して即座に状況を把握し緊急性の判断や初動対応を開始できますし、素早く複数の視点から検討が可能になります。組織全体でデータに基づいた迅速な意思決定が日常的に行われる環境を構築するにあたって分析を共有できる環境が重要なのです。\n","permalink":"https://kenjiusui.github.io/blog/books/data-platform-intro/07_data_visualization/","summary":"\u003ch2 id=\"71-データ活用とセルフサービス環境\"\u003e7.1 データ活用とセルフサービス環境\u003c/h2\u003e\n\u003cp\u003eここまでにデータを収集し保存、加工する技術とデータの品質について紹介してきました。しかし単にデータを保存しただけでは価値を生み出せません。分析する人が簡単にデータにアクセスし自分で分析できる環境が必要です。\u003c/p\u003e\n\u003cp\u003eデータの活用が広まれば広まるほどデータの専門家以外でも自力でデータを分析できる環境が求められます。専門家だけであれば自分でデータベースやコードを読み解きPythonやSQLを書いて処理を行うことができますが非専門家の場合はそうもいきません。\u003c/p\u003e\n\u003cp\u003e専門的な知識を持たないビジネス担当者でも必要な時に必要な分析を自分で実行できる環境の構築を目指します。\u003c/p\u003e\n\u003ch3 id=\"biツールによる分析環境の向上\"\u003eBIツールによる分析環境の向上\u003c/h3\u003e\n\u003cp\u003eBIツール（Business Intelligence Tool）はセルフサービスで分析できるようにするための環境作りに重要なシステムです。グラフィカルなインターフェースにより一定範囲の分析作業を効率化できます。\u003c/p\u003e\n\u003cp\u003eBIツールのメリットはGUIベースで専門的な知識がなくてもとっつきやすいことです。画面上で分析したいデータをGUI上で選択し基本的な集計やグラフ作成を実行できます。たとえば売上データから「商品カテゴリ」を行に「販売月」を列に「売上金額」を値とすることで売上推移のクロス集計表が生成されます。\u003c/p\u003e\n\u003cp\u003eまた、多くのデータを分析するため必要な情報を集約することで分析の効率が上げやすくなります。ダッシュボードを通じて分析結果や分析の処理を共有できたり、データカタログを通して必要なデータを素早く検索・利用できたりするため、分析に必要な情報が集約されることで分析・アクションが実行しやすくなります。また、データ分析基盤へのインターフェイスが統一されることで権限管理もしやすくなります。\u003c/p\u003e\n\u003cp\u003eしかし複雑な分析や柔軟な条件設定が必要な場合はGUIだけでは限界があります。条件での絞り込みや複数テーブルの複雑な結合、計算式を用いた指標などは複雑になればなるほどGUIベースのBIツールだけでは実装が難しく、SQLによる直接的なデータ操作が必要になります。そのため、実際はBIツールと併せてデータ分析基盤へSQLを実行できる環境も提供し、利用者のスキルレベルに応じた分析手段を用意することが一般的です。\u003c/p\u003e\n\u003ch3 id=\"データカタログによる情報発見\"\u003eデータカタログによる情報発見\u003c/h3\u003e\n\u003cp\u003e大規模なデータ分析基盤では数百から数千のテーブルやレポートが存在します。分析する人が必要なデータを発見するためのデータカタログ機能が重要になります。\u003c/p\u003e\n\u003cp\u003eデータカタログはメタデータ管理の成果を活用します。第6章で説明したようにメタデータはデータ分析を効率化させる重要な要素です。各データの定義・更新頻度・データリネージュ・利用状況といった情報が整理することで「売上」「顧客」「在庫」といったキーワード検索により関連するテーブルやレポートを素早く発見できます。\u003c/p\u003e\n\u003cp\u003e必要なデータを自分たちで素早く探せる環境は分析する人が増えれば増えるほど有用になります。なにかのデータを探すたびに問い合わせていたら分析が進みませんしデータ分析基盤チームも問い合わせ対応ばかりで手いっぱいになってしまいます。これはデータ活用を広める段階においてボトルネックになりがちで忘れてはいけない観点です。\u003c/p\u003e\n\u003cp\u003eさらに重要なのは見つけたデータが自分の求めているものかどうかを確認できることです。データの詳細な定義・計算方法・サンプル値が表示されるため「このテーブルの売上は税込みなのか税抜きなのか」「このテーブルの在庫データはいつ更新された値なのか」といった疑問を事前に解決できます。またデータの品質状況や信頼性レベルも併せて確認できるため分析に適したデータソースかどうか判断できるようになり分析の効率化と精度を向上します。\u003c/p\u003e\n\u003ch3 id=\"協調的な分析環境\"\u003e協調的な分析環境\u003c/h3\u003e\n\u003cp\u003e作成したレポートやダッシュボード、その処理方法を組織内で共有することで分析の効率性と正確性を大幅に向上し意思決定の質と速度を改善することができます。\u003c/p\u003e\n\u003cp\u003e過去に他のメンバーが作成した分析手法を参考にすることでゼロから分析処理の実装を考える必要がなくなり効率的に作業を進められます。類似のビジネス課題に対する分析アプローチが蓄積されることで組織全体の分析スキルが向上され、また優秀な分析者が作成したテンプレートやベストプラクティスを活用することで分析経験の浅いメンバーでも高品質な分析を実行できるようになります。\u003c/p\u003e\n\u003cp\u003e共有という観点でBIツールは非常に便利です。ほとんどのBIツールにはレポートやダッシュボードの共有機能がついており、これを使うことで組織内で共有することができます。特にWebサービスとして提供されているBIツールはURLだけで簡単に共有できるので手間がかかりません。\u003c/p\u003e\n\u003cp\u003e同じダッシュボードやレポートを共有することで全員が同じ数値を参照しながら議論でき認識のズレを根本的に回避できます。この結果として現状把握から行動までのスピードと精度が飛躍的に向上します。共有されたダッシュボードを通して即座に状況を把握し緊急性の判断や初動対応を開始できますし、素早く複数の視点から検討が可能になります。組織全体でデータに基づいた迅速な意思決定が日常的に行われる環境を構築するにあたって分析を共有できる環境が重要なのです。\u003c/p\u003e","title":"データ可視化"},{"content":"8.1 データガバナンス データの活用が拡大するに伴いデータと分析基盤への適切な管理と統制がより重要になります。分析する人が安全かつ安心してデータにアクセスし分析できる環境を整えましょう。\nアクセス権限管理 データには機密度の異なる情報が含まれているため適切なアクセス制御が必要です。多くの場合で部門や役職、プロジェクトごとにアクセス可能なデータ範囲を設定します。\n最も気をつけるべきポイントは個人情報を含むデータです。基本的には個人情報を削除したりマスキングすることで安全性を確保します。このとき3層アーキテクチャで明確にわける設計にすると便利です。データレイクには生の個人情報があり、データウェアハウス段階で匿名化処理を行いデータマートでは個人を特定できない形式でデータを提供します。こうすることで多くの分析者はデータマートで安全に分析をおこない、必要に応じて権限を付与することでデータレイクから個人情報を含めた分析をおこなうことも可能になります。この段階的な匿名化により分析する際に安全にデータ分析を実行できる環境を構築します。\n他にも役職や部門でわける考え方として、本部のメンバーはデータ全体が見られるようにしておきながら各店舗のマネージャーは自分の店舗のデータだけ見られるようにするというものがあります。この切り分け方は各社の考え方によって大きく異なる部分なので一概には決められませんが誰がどのデータを見てよいのか、見てはいけないのか明確に決めておくことが必要です。\n詳細なアクセス制御としてテーブル・列・行といった複数レベルでの権限管理も可能です。テーブル単位では部門別に参照可能なデータを制限し行単位では営業担当者が自分の担当顧客のみ参照できるようにも制御できます。しかしこれらの詳細な制御は管理コストの増大と操作ミスによる事故が起きるリスクがあります。データの権限制御は3層アーキテクチャの単位やプロジェクト、ワークスペースなどなるべくわかりやすく大きな括りでわけることが望ましいでしょう。可能な限りシンプルな管理設計を心がけることが重要です。\n利用ルールとガバナンス体制 データ利用に関する社内ルールを明文化しデータ分析基盤を利用するすべての人に周知することが重要です。個人情報の取り扱い方法やデータの取り扱い、特に社外への持ち出しなどの具体的なルールを策定します。また部門別のデータアクセス範囲や分析結果の共有範囲についても明文化し組織全体で一貫したデータ利用基準を構築します。\nこれらのルールはドキュメントの配布だけでなく研修や説明会を通じて分析をする人に教育し適切なデータ利用を浸透させます。特にセキュリティや個人情報の利用については定期的な理解度チェックによる継続的にルールの定着を図ることが必要です。新しいメンバーの入社時やシステムの機能追加・変更時には周知を徹底し常に最新のルールが共有されるよう体制を整えます。\nルールの策定と周知だけでなく監視も重要です。データへアクセスする全ての操作はログとして記録し継続的に監視します。誰がいつどのデータにアクセスし何を分析したかを追跡可能な状態に保ちます。ログには単なるアクセス履歴だけでなく実行されたクエリ内容や出力状況も含めることで詳細な利用実態を把握できます。\nこれらの利用状況はダッシュボードで可視化しておき、必要ならばアラートの設定をしましょう。ログの分析により利用傾向を把握し適切なアクセス権限の見直しやセキュリティ強化の判断材料としても活用できます。また定期的に利用状況をレビューすることで潜在的なリスクを早期発見し予防的な対策を講じることも重要です。\n継続的な改善 データ分析基盤の利用者からのフィードバックを収集し分析基盤の継続的な改善を図ります。「このデータが見つけにくい」「処理が遅い」「新しい分析軸を追加してほしい」といった要望を定期的に収集し優先度をつけて対応します。\n利用状況に応じたパフォーマンスの最適化は地道ですが重要な改善活動です。利用者数やデータ量、計算量、処理の応答時間などをダッシュボードで監視することで計算リソースの設定が適切か判断することができます。必要に応じてリソースを追加したり削減するとよいでしょう。\n社内で似たような処理が高頻度におこなわれているならば事前処理されたテーブルを用意することで処理速度と計算負荷が改善できます。一方で、あまり使われない中間テーブルや参照されていないのに自動更新されているダッシュボードはリソース削減の対象として整理します。このような最適化により全体的なシステムパフォーマンスが向上し新たなビジネス価値の発見にもつながります。\nデータマートの管理においては似たようなデータマートの乱立を防ぐことが重要です。複数の部門が独自に類似の集計テーブルを作成することで重複したデータ処理による計算負荷とストレージ使用量の増大を招かないよう定期的にデータマートを見直し統合可能なものは一本化します。一方で、ビジネスの変化に応じて新たな分析ニーズが発生した場合は迅速に適切なデータマートを用意し組織の意思決定スピードを支援します。\nデータガバナンスは規制や制約ではなく「安心してデータを活用するための仕組み」として位置づけることが重要です。適切なガバナンスがあることで分析者は迷うことなくデータ分析に集中することが可能になり組織全体のデータ活用レベルを向上させることができます。\n","permalink":"https://kenjiusui.github.io/blog/books/data-platform-intro/08_data_access_governance/","summary":"\u003ch2 id=\"81-データガバナンス\"\u003e8.1 データガバナンス\u003c/h2\u003e\n\u003cp\u003eデータの活用が拡大するに伴いデータと分析基盤への適切な管理と統制がより重要になります。分析する人が安全かつ安心してデータにアクセスし分析できる環境を整えましょう。\u003c/p\u003e\n\u003ch3 id=\"アクセス権限管理\"\u003eアクセス権限管理\u003c/h3\u003e\n\u003cp\u003eデータには機密度の異なる情報が含まれているため適切なアクセス制御が必要です。多くの場合で部門や役職、プロジェクトごとにアクセス可能なデータ範囲を設定します。\u003c/p\u003e\n\u003cp\u003e最も気をつけるべきポイントは個人情報を含むデータです。基本的には個人情報を削除したりマスキングすることで安全性を確保します。このとき3層アーキテクチャで明確にわける設計にすると便利です。データレイクには生の個人情報があり、データウェアハウス段階で匿名化処理を行いデータマートでは個人を特定できない形式でデータを提供します。こうすることで多くの分析者はデータマートで安全に分析をおこない、必要に応じて権限を付与することでデータレイクから個人情報を含めた分析をおこなうことも可能になります。この段階的な匿名化により分析する際に安全にデータ分析を実行できる環境を構築します。\u003c/p\u003e\n\u003cp\u003e他にも役職や部門でわける考え方として、本部のメンバーはデータ全体が見られるようにしておきながら各店舗のマネージャーは自分の店舗のデータだけ見られるようにするというものがあります。この切り分け方は各社の考え方によって大きく異なる部分なので一概には決められませんが誰がどのデータを見てよいのか、見てはいけないのか明確に決めておくことが必要です。\u003c/p\u003e\n\u003cp\u003e詳細なアクセス制御としてテーブル・列・行といった複数レベルでの権限管理も可能です。テーブル単位では部門別に参照可能なデータを制限し行単位では営業担当者が自分の担当顧客のみ参照できるようにも制御できます。しかしこれらの詳細な制御は管理コストの増大と操作ミスによる事故が起きるリスクがあります。データの権限制御は3層アーキテクチャの単位やプロジェクト、ワークスペースなどなるべくわかりやすく大きな括りでわけることが望ましいでしょう。可能な限りシンプルな管理設計を心がけることが重要です。\u003c/p\u003e\n\u003ch3 id=\"利用ルールとガバナンス体制\"\u003e利用ルールとガバナンス体制\u003c/h3\u003e\n\u003cp\u003eデータ利用に関する社内ルールを明文化しデータ分析基盤を利用するすべての人に周知することが重要です。個人情報の取り扱い方法やデータの取り扱い、特に社外への持ち出しなどの具体的なルールを策定します。また部門別のデータアクセス範囲や分析結果の共有範囲についても明文化し組織全体で一貫したデータ利用基準を構築します。\u003c/p\u003e\n\u003cp\u003eこれらのルールはドキュメントの配布だけでなく研修や説明会を通じて分析をする人に教育し適切なデータ利用を浸透させます。特にセキュリティや個人情報の利用については定期的な理解度チェックによる継続的にルールの定着を図ることが必要です。新しいメンバーの入社時やシステムの機能追加・変更時には周知を徹底し常に最新のルールが共有されるよう体制を整えます。\u003c/p\u003e\n\u003cp\u003eルールの策定と周知だけでなく監視も重要です。データへアクセスする全ての操作はログとして記録し継続的に監視します。誰がいつどのデータにアクセスし何を分析したかを追跡可能な状態に保ちます。ログには単なるアクセス履歴だけでなく実行されたクエリ内容や出力状況も含めることで詳細な利用実態を把握できます。\u003c/p\u003e\n\u003cp\u003eこれらの利用状況はダッシュボードで可視化しておき、必要ならばアラートの設定をしましょう。ログの分析により利用傾向を把握し適切なアクセス権限の見直しやセキュリティ強化の判断材料としても活用できます。また定期的に利用状況をレビューすることで潜在的なリスクを早期発見し予防的な対策を講じることも重要です。\u003c/p\u003e\n\u003ch3 id=\"継続的な改善\"\u003e継続的な改善\u003c/h3\u003e\n\u003cp\u003eデータ分析基盤の利用者からのフィードバックを収集し分析基盤の継続的な改善を図ります。「このデータが見つけにくい」「処理が遅い」「新しい分析軸を追加してほしい」といった要望を定期的に収集し優先度をつけて対応します。\u003c/p\u003e\n\u003cp\u003e利用状況に応じたパフォーマンスの最適化は地道ですが重要な改善活動です。利用者数やデータ量、計算量、処理の応答時間などをダッシュボードで監視することで計算リソースの設定が適切か判断することができます。必要に応じてリソースを追加したり削減するとよいでしょう。\u003c/p\u003e\n\u003cp\u003e社内で似たような処理が高頻度におこなわれているならば事前処理されたテーブルを用意することで処理速度と計算負荷が改善できます。一方で、あまり使われない中間テーブルや参照されていないのに自動更新されているダッシュボードはリソース削減の対象として整理します。このような最適化により全体的なシステムパフォーマンスが向上し新たなビジネス価値の発見にもつながります。\u003c/p\u003e\n\u003cp\u003eデータマートの管理においては似たようなデータマートの乱立を防ぐことが重要です。複数の部門が独自に類似の集計テーブルを作成することで重複したデータ処理による計算負荷とストレージ使用量の増大を招かないよう定期的にデータマートを見直し統合可能なものは一本化します。一方で、ビジネスの変化に応じて新たな分析ニーズが発生した場合は迅速に適切なデータマートを用意し組織の意思決定スピードを支援します。\u003c/p\u003e\n\u003cp\u003eデータガバナンスは規制や制約ではなく「安心してデータを活用するための仕組み」として位置づけることが重要です。適切なガバナンスがあることで分析者は迷うことなくデータ分析に集中することが可能になり組織全体のデータ活用レベルを向上させることができます。\u003c/p\u003e","title":"データアクセス・ガバナンス"},{"content":"データ分析基盤の構築は技術的な挑戦であると同時に組織変革のプロジェクトでもあります。システムを作ることは手段であり最終目的は「データに基づいた優れた意思決定により企業価値を向上させる」ことです。\nデータ分析基盤の構築ではビジネス価値の実現を考えることが重要です。データ分析の先にはビジネス上の意思決定が存在します。どんなデータがあれば意思決定の質を向上させることができますか？どんなシステムがあれば素早く意思決定に必要な情報を集められますか？データを分析した結果を利用する人たちの抱えている課題がなにか常に問い続けることがデータ分析基盤の価値を向上させます。\n同時にデータ分析基盤の開発者と利用者はお互いに仲間であるという認識を忘れてはいけません。社内システムを構築すると「開発者vs利用者」という構図になりがちですがお互いに会社を良くするために仕事をしているのです。データドリブンカンパニーになるためには相手をリスペクトし、理解し、融和を図ることが重要です。\nデータは21世紀の石油と言われますが原油のまま放置していても価値を生みません。適切な精製・加工・流通の仕組みがあって初めて価値を発揮します。データ分析基盤はまさにその精製プラントであり、ぜひ本書で解説した技術と知識を活用して皆さんの組織でも価値あるデータ活用を実現してください。\nデータに基づいた意思決定により皆さんの組織がさらなる成長を遂げることを心から期待しています。\n","permalink":"https://kenjiusui.github.io/blog/books/data-platform-intro/09_conclusion/","summary":"\u003cp\u003eデータ分析基盤の構築は技術的な挑戦であると同時に組織変革のプロジェクトでもあります。システムを作ることは手段であり最終目的は「データに基づいた優れた意思決定により企業価値を向上させる」ことです。\u003c/p\u003e\n\u003cp\u003eデータ分析基盤の構築ではビジネス価値の実現を考えることが重要です。データ分析の先にはビジネス上の意思決定が存在します。どんなデータがあれば意思決定の質を向上させることができますか？どんなシステムがあれば素早く意思決定に必要な情報を集められますか？データを分析した結果を利用する人たちの抱えている課題がなにか常に問い続けることがデータ分析基盤の価値を向上させます。\u003c/p\u003e\n\u003cp\u003e同時にデータ分析基盤の開発者と利用者はお互いに仲間であるという認識を忘れてはいけません。社内システムを構築すると「開発者vs利用者」という構図になりがちですがお互いに会社を良くするために仕事をしているのです。データドリブンカンパニーになるためには相手をリスペクトし、理解し、融和を図ることが重要です。\u003c/p\u003e\n\u003cp\u003eデータは21世紀の石油と言われますが原油のまま放置していても価値を生みません。適切な精製・加工・流通の仕組みがあって初めて価値を発揮します。データ分析基盤はまさにその精製プラントであり、ぜひ本書で解説した技術と知識を活用して皆さんの組織でも価値あるデータ活用を実現してください。\u003c/p\u003e\n\u003cp\u003eデータに基づいた意思決定により皆さんの組織がさらなる成長を遂げることを心から期待しています。\u003c/p\u003e","title":"おわりに"},{"content":"自己紹介 薄井研二 / USUI Kenji\nフリーランスのデータアナリスト・データエンジニアです。\nデータの活用を中心に分析・基盤構築・AI活用の支援をおこなっています。\nご興味のある方はリンクよりご相談ください。\n当サイトについて 当サイトは薄井の執筆した記事などのアウトプットを掲載しています。\n告知なくコンテンツの修正・削除する可能性があります。\n意見・要望はSNSへご連絡ください。\nPosts: 書いた記事です Books: Web書籍含む書いた本です リンク Bluesky LinkedIn GitHub ","permalink":"https://kenjiusui.github.io/blog/about/","summary":"about","title":"About"}]