カスタマージャーニーは、顧客が商品やサービスを知り、情報を集め、比較し、購入し、利用し、再購入や推奨に至るまでの一連の体験を表します。EC事業では、広告、商品ページ、決済、配送、問い合わせ、メールなど、複数の接点を横断して顧客体験を理解するために使われます。

しかし、社内の想像だけでカスタマージャーニーを作成すると、実際の顧客行動とは異なる理想的な流れになりやすくなります。企業が想定する順序どおりに顧客が行動するとは限らず、SNSを見た後に実店舗で確認し、数週間後に検索広告からECへ戻って購入することもあります。

正確なカスタマージャーニーを作るには、アクセス解析、購入履歴、広告接触、問い合わせ、口コミ、インタビュー、操作観察などを組み合わせる必要があります。本記事では、各段階で収集すべきデータと、そのデータから何を判断できるかを詳しく解説します。

1. カスタマージャーニーとは

カスタマージャーニーとは、顧客が課題や欲求を認識してから、商品との関係を終了するまでに経験する行動、思考、感情、接点を時系列で表したものです。企業側の販売手順ではなく、顧客側の経験を中心に記述します。

Webサイトやアプリケーションでは、操作結果や現在の状態を利用者へ伝えるために、成功、警告、エラー、情報という四つのステータスがよく使われます。保存が完了したときは成功、入力内容に問題があるときはエラー、注意が必要な操作には警告、補足説明には情報というように、状態ごとに役割が異なります。

ステータスカラーは、成功なら緑、警告なら黄、エラーなら赤、情報なら青を選べば完成するものではありません。背景色、文字色、枠線、アイコン、操作要素、ライトモード、ダークモードまで含めて設計しなければ、文字が読めない、状態を区別できない、ブランドカラーと混同するといった問題が発生します。

さらに、色だけで状態を伝える設計は避ける必要があります。WCAG 2.2では、色の違いだけに依存せず、文字、形状、アイコンなど別の視覚的な手掛かりも提供することが求められています。また、通常サイズの文字には背景とのコントラスト比4.5対1以上、状態の識別に必要な非テキスト要素には隣接色とのコントラスト比3対1以上が基準になります。

本記事では、四つのステータスの意味から、カラーパレット、コンポーネント、アクセシビリティ、デザイントークン、Figma、CSSへの実装まで、実務で使える設計手順を解説します。

UIでは、色を使うことで状態や優先順位を素早く伝えられます。成功を緑、警告を黄色、エラーを赤、情報を青で表示すれば、多くの利用者は画面を見ただけでおおよその意味を判断できます。色は、情報を短時間で理解するための有効な視覚要素です。

しかし、色だけを唯一の手掛かりにすると、色覚特性、弱視、低品質な画面、強い日光、モノクロ印刷、ハイコントラストモードなどの条件によって情報が失われる可能性があります。赤い枠線だけで入力エラーを示したり、緑と赤だけでグラフの良し悪しを区別したりすると、状態を正しく判断できない利用者が生まれます。

WCAG 2.2の達成基準1.4.1「色の使用」では、色を情報、操作、応答、識別の唯一の視覚的手段にしないことが求められています。色を廃止する必要はなく、文字、形状、アイコン、線種、パターン、位置など、色以外の手掛かりを追加することが基本です。

1. 色だけに依存しないUIとは

色だけに依存しないUIとは、色を認識できない状態でも、情報、状態、操作方法を理解できるUIです。色を使わないデザインではなく、色に加えて別の手掛かりを用意する設計を意味します。

Pythonで同じ処理を何度も実行したいとき、一行ずつ同じコードを書く必要はありません。繰り返し処理を使えば、リストに入っている全商品を表示する、1から100までの数値を合計する、利用者が正しい値を入力するまで質問を続ける、といった処理を簡潔に記述できます。

Pythonの代表的な繰り返し構文はfor文とwhile文です。for文はリストや文字列などから要素を順番に取り出す処理に向き、while文は条件が成立している間、処理を繰り返す場合に利用します。Pythonのfor文は、数値カウンターだけを操作するのではなく、イテラブルから要素を順番に取り出す構文として設計されています。

JSONは、Web API、設定ファイル、システム間のデータ交換などで広く使われるテキスト形式です。正式名称はJavaScript Object Notationですが、JavaScript専用ではなく、Python、Java、C#、PHPなど多くの言語で利用できます。RFC 8259では、JSONは軽量でテキストベースの言語非依存なデータ交換形式として定義されています。

Pythonでは、標準ライブラリのjsonモジュールを使って、JSON文字列を辞書やリストへ変換したり、PythonのデータをJSON文字列やファイルへ書き出したりできます。外部パッケージを追加しなくても基本的なJSON処理を実装できます。

本記事では、loads、dumps、load、dumpの基本から、日本語、ファイル操作、Web API、独自クラス、数値精度、エラー処理、大容量データまで順番に解説します。

1. JSONの基本構造を理解する

JSONをPythonで扱う前に、JSONが表現できる値と記述規則を理解する必要があります。Pythonの辞書に似ていますが、同じものではありません。

CSVは、表計算ソフト、データベース、業務システムなどの間で、表形式データを交換するためによく使われるテキスト形式です。一般的には項目をカンマで区切りますが、タブやセミコロンを区切り文字にする形式もあり、引用符や改行の扱いにもシステムごとの差があります。Pythonの公式ドキュメントも、CSVには提供元ごとの細かな形式差が存在すると説明しています。

Pythonでは、標準ライブラリのcsvモジュールを使ってCSVを読み書きできます。行をリストとして扱うreaderとwriterに加え、列名をキーとする辞書として扱えるDictReaderとDictWriterが用意されています。

2026年7月時点の最新安定版はPython 3.14.6です。本記事の基本コードはPython 3.10以降を想定していますが、csv.readerやcsv.writerなどの中心的な機能は、より古いPython 3でも利用できます。

Pythonの書籍を選ぶときは、知名度やページ数だけでなく、現在の学習レベルとPythonを使う目的を確認する必要があります。プログラミング未経験者向けの本と、実務経験者が型ヒントや内部機構を学ぶ本では、必要な前提知識が大きく異なるからです。

2026年7月時点の最新安定版はPython 3.14.6で、Python 3.15は2026年10月の正式公開に向けた開発段階です。ただし、書籍はPython 3.13以前を対象としていても、変数、関数、クラス、例外、標準ライブラリなどの学習には十分活用できます。環境構築や新機能については、書籍の対応版と現在のPythonとの差分を確認しましょう。

本記事では、最初の一冊として読みやすい入門書から、実務、自動化、データ分析、機械学習、Web開発へ進むための専門書までを紹介します。一度に複数冊を購入するのではなく、主教材、演習・実践書、専門分野の順番で選ぶことが重要です。

1. Pythonおすすめ書籍の選び方

Pythonの書籍は、対象読者、対応版、サンプルの量、扱う分野によって内容が大きく異なります。学習目的に合わない本を選ぶと、必要のない数学やフレームワークの説明で止まり、Pythonの基礎まで到達できない場合があります。

Dynamics 365とERPは、同じ種類の製品を表す言葉ではありません。ERPは、会計、販売、購買、在庫、生産などの経営資源を統合的に管理するシステムの分類です。一方のDynamics 365は、マイクロソフトが提供するCRMおよびERPの業務アプリケーション群を指します。

そのため、「Dynamics 365とERPのどちらを選ぶべきか」という質問は、厳密には比較の前提が異なります。自動車という製品分類と、特定メーカーが提供する車種群を比較するような関係に近いと考えると分かりやすいでしょう。

Dynamics 365の中には、Dynamics 365 Finance、Dynamics 365 Supply Chain Management、Dynamics 365 Business Centralなど、ERPに分類される製品があります。同時に、Dynamics 365 SalesやDynamics 365 Customer Serviceなど、顧客管理を中心とするCRM製品も含まれています。MicrosoftもDynamics 365を、営業、サービス、財務、サプライチェーン業務を支援するERPおよびCRMアプリケーション群として説明しています。

Dynamics 365とCRMは、同じ種類の名称ではありません。CRMは、顧客との関係を管理し、営業、マーケティング、カスタマーサービスなどの活動を改善する考え方、業務手法、システム分類を指します。一方、Dynamics 365はMicrosoftが提供する具体的な業務アプリケーション群です。

Dynamics 365には、Dynamics 365 SalesやDynamics 365 Customer ServiceなどのCRM関連製品が含まれています。同時に、Dynamics 365 FinanceやDynamics 365 Supply Chain ManagementなどのERP関連製品も含まれます。MicrosoftもDynamics 365を、CRMとERPの業務アプリケーション群として位置付けています。

したがって、「Dynamics 365とCRMのどちらを選ぶか」という比較は、厳密には適切ではありません。正しくは、「CRMを導入する際に、Dynamics 365のCRM関連製品を選ぶか」「Dynamics 365と他社CRMを比較するか」と考える必要があります。

CRMを導入しても、顧客情報が十分に入力されない、営業担当者が日報代わりにしか使わない、蓄積したデータから施策を作れないといった問題が起こることがあります。高機能なCRMを導入していても、利用目的、入力基準、業務手順、評価指標が曖昧であれば、現場にとっては作業負担の大きい管理システムになってしまいます。

CRM改善では、入力率だけを確認してはいけません。登録された情報が正しいか、その情報を誰が何の判断に使うか、営業やマーケティングの行動が変わったか、顧客体験や収益が改善したかまで確認する必要があります。入力件数が増えても、担当者が判断に使えない情報ばかりであれば、CRMの価値は高まりません。

本記事では、CRMの目的、顧客データ、営業活動、マーケティング、顧客維持、操作性、社内定着、分析、安全管理を見直すためのチェックリストを紹介します。各項目は、確認するだけでなく、問題が見つかった後に何を変更すべきかまで判断できる構成です。

1. CRM改善チェックリストとは

CRM改善チェックリストは、CRMの設定、データ、利用状況、業務成果を複数の観点から確認し、改善すべき場所を見つけるための診断項目です。システム担当者だけでなく、営業、マーケティング、顧客支援、経営の担当者が共同で利用します。