(4ページ目)

営業 ✕ 実際

に関する学び

---

どんなデータで戦略化？ 私の顧客は主に社内の営業担当で、取得できるかどうかに関わらず、どのようなデータがあればより戦略的な活動が実現できるかというアイデアを集めるブレーンストーミングが面白いと感じています。現状、データ提供側は、こうしたデータをもとに顧客の考えや行動を理解し、営業がその仮説に基づいた行動に移ることを前提としているため、実際のデータ活用にはつながっていないと考えています。そのため、単に可視化しているデータに対する意見収集にとどまらず、営業として必要なデータについても積極的に意見を集めたいと思っています。 伝え方はどう変える？ 既存のデータの可視化においては、私自身が顧客（営業）視点で開発を進めています。しかし、システムベンダーとの要件定義の際、どうしても自分が実現可能だと感じているアイデアしか伝えがちでした。そこで、直近のシステム改修にあたっては、実現が難しいかもしれないアイデアも含め、幅広い提案をもとに話し合いを行いました。 代案提示の意味は？ その結果、実現不可能に見えるアイデアに対しても、ベンダー側からは「こういった形なら実現可能」という代案を提示していただくことができました。これにより、自己完結する前にアイデアを言語化し、関係者に発散することの重要性を学びました。 参加者選定どうする？ また、ブレーンストーミングの手法についても新たな学びがありました。これまでは、同じグループや部内で取り組むレクリエーション的なブレーンストーミングにおいて、出されたアイデアがどこか似通っており革新的なものを得られなかった印象がありました。今回、出したい成果に合わせて参加者を選び、初めからブレーンストーミングの設計を行うことで、以前感じていたもやもやの原因がわかり、スッキリとした気持ちになりました。

P/Lの基礎はどう見る？ 先週、P/L（損益計算書）の基本的な理解が大切であると学びました。特に経常利益について、これは持続的に利益が出るかどうかを測る指標であり、本業の儲けに加えて財務活動での収益や費用が常に発生するという基本的な認識を持てたことが、私にとって大きなプラスとなりました。 原価率はどう変化？ 次に、売上原価率について、「原材料費が高くなっているのか、それとも原価率が高い商品が売れているのか」といった視点が学びとなりました。売上高が伸びた際には、原価率の変動原因を細かく見て、売上を形成する製品に基づいた戦略を立てることが重要だと感じました。また、当たり前のことではありますが、販売価格が低ければ原価率が上がる（クーポンによる安売りなどが原因）という点にも気付かされました。事業計画を達成するためには、利益を確保しつつ売上を伸ばすことが重要であると再確認しました。 取引先のP/Lって？ そして、実際に取引先や競合他社のP/Lを読み解くことに挑戦したいと考えています。具体的には、営業外収益や費用がどの程度あるのか、売上原価率が企業や年度ごとにどのように変化し、何がその原因であるのかを理解し、それが戦略にどのように結びついているのかを把握したいです。また、新聞で最終利益が報じられた際に、売上総利益、営業利益、経常利益の中でどこが影響してその結果が生まれたのかを確かめたいです。 IR活用は確実？ これを実践するために、11月に決算が発表された取引先企業のIR（インベスター・リレーションズ）を確認し、売上総利益、営業利益、経常利益の各利益率を同業界の平均や他社と比較することを毎週行いたいと考えています。この取組は、異なる業界である建設、エネルギー、人材業界から各1社ずつ選び、競合他社も含めた計6社を対象としています。

ユーザーの反応はどう？ ユーザーからのフィードバックをもとに改良を重ねることが、成果向上の鍵だと実感しました。そこで、ユーザーの反応をスピーディーに得る手法を検討する必要性を感じています。具体的には、デザイン画や模型など、素早く形にできるプロトタイプの作り方が効果的です。フィードバックは、見た目、機能、使用感という３つの観点で捉えることができ、何を試したいのか、何を確かめたいのかを明確にして適切な手法を選ぶことが重要と感じました。 生成AIの可能性は？ また、多くの受講生が生成AIを活用していることにも驚きました。ビジュアル化の面で、今後は私自身もこの技術を積極的に活用していきたいと思っています。 プロトタイプの意義は？ 私自身の業務に当てはめると、扱う教材をどのように現場で使っていただくかを検討する役割があります。例えば、現場の指導提案を行う際、いきなり詳細な資料を持ち込むのではなく、まずはプロトタイプとして提案内容を形にし、意見を求めたり実際に使用してもらったりすることで、改善の余地を探ろうとしています。 プロトタイプの罠は？ ただし、プロトタイプにこだわりすぎるとスピード感を失い、作成したものに固執してしまうリスクもあります。私自身は、商品開発の立場ではないからこそ、営業、マーケティング、開発といった異なる部門と連携し、情報を共有することが、よりよい企画へとつながると考えています。 十分な準備はどう？ 今回の課題に取り組む中で、これまでの積み重ねがプロトタイプの精度を大きく左右することを痛感しました。自分なりに検討はしたものの、他の受講生に比べると十分な準備ができておらず、反省すべき結果となりました。

データは何を伝える？ 表やグラフを用いてデータを可視化すると、数字そのものだけでは見えなかった切り口が浮かび上がり、新たな示唆を得ることができると感じました。単なる数値比較だけでなく、比率の違いを明確に示すことで、より深い理解につながります。 年齢の背景はどう？ また、年齢などの属性を分解する際は、機械的な年代区分に頼らず、その背景や特性を考慮することが重要だと改めて実感しました。単一の切り口に固執せず、同じ年齢層内でも別の観点から分析する工夫が求められると感じます。 切り口の秘訣は？ 切り口を設定する際は、When/Where/Howといった観点を取り入れることで、網羅的かつ多角的な分析が可能になります。たとえ一つの切り口で顕著な特徴が見えたとしても、それだけに満足せず、さらなる検証を重ねることが大切です。 提供方法は適切？ 実際に、生命保険のある支払事由発生状況の数値データを、年代別や発生時期といった切り口で分解し、営業現場に提示した経験があります。しかし、この講義を聞いて、その提供方法が目的に十分沿っていたのか、またはもっと細かく分解する余地があったのかと自問する機会となりました。今後は、まず自分なりに目的を明確にした上で、When/Where/Howの観点から再度切り口を検討したいと考えています。 新たな切り口は？ せっかく取得したQ2のデータを活用し、まずはどのような切り口が設定できるのか、単純な年代別ではなく異なる観点からの分解が可能かどうかを試してみようと思います。そして、ある程度データを分解した後は、とにかく可視化に努め、動きながら検証を進めることの重要性を再認識しました。

どうして分解が必要？ 問題が起きたとき、まずは「どうすれば」という視点から考えるのではなく、問題を細かく分解して捉えることが重要です。具体的には、まず現状を把握し（What）、その問題がどこで発生しているかを認識し（Where）、なぜ起こったのかを明らかにし（Why）、その上でどのように解決すべきか（How）を検討する流れが求められます。 どのパターンが有効？ また、問題解決のパターンは大きく2つに分けられます。一つは、あるべき姿に対して過去の実績が届いていなかった場合、もう一つは、未来の理想と現状との間にギャップがある場合です。これらの状況を整理するためには、ロジックツリーを活用し、「What」「Where」「Why」「How」の観点から一つひとつ問題を解明していくことが効果的です。さらに、情報を漏れなくダブりなく整理するMECEの視点も大切です。 何が運用の障害？ 今、営業から導入プロセスに至るまでのオペレーション検討を進めていますが、まだ実際には運用が始まっていないため、各段階で運用面の不備が見えてきています。そこで、まずは現状のフローにおいて何が問題なのか、理想の状態はどのようなものかを洗い出します。その上で、問題箇所を特定し、最適な解決策を考案していく必要があります。 どうやって整理する？ 各検討箇所ではロジックツリーを用い、「What」「Where」「Why」「How」の視点で分析を繰り返していくことで、問題を一つずつ確実に解決していく姿勢が大切です。頭の中で漠然と把握しているだけでなく、明確に言語化して整理することで、問題解決への道筋がはっきりと見えてきます。

インタビューの目的は？ 現在、製薬会社でデジタル関連のプロジェクトを担当しています。直近ではリリースしたWebサイトについて、一般ユーザーや医療関係者へのインタビューを実施し、そのフィードバックを改善のためのインプットとして活用しようとしています。ユーザーグループごとに利用方法が異なるため、グループに合わせた質問を準備する必要があります。具体的なプロセスとしては、①ユーザーインタビューの企画、②マーケティングチームへの情報共有、③プロダクトチーム内での対応優先順位の決定、④実装、⑤サイトのPVや滞在時間による成果計測、⑥さらなる対応の実施が考えられます。しかし、これらは予算の確保やインタビュー会社との契約など大掛かりな準備が必要なため、現段階では実践には至っていません。 CRM経験の教訓は？ 以前の実践例として、営業で利用されるCRMシステムを担当していた際、現場での実体験がありました。実際に営業の1日を同行し、営業車内でCRMシステムについてのインタビューを行うことで、改善すべきポイントを見いだすことができました。その後、実際の改善対応を進めた結果、別の営業担当者からも好評のフィードバックを得ることができました。 本当に必要なものは？ これらの経験から、作りたいものではなく、使う人にとって必要なものを作ることの重要性を実感しました。単に想像するだけではなく、現場を体験することで、何が必要であればより良いかを具体的に理解できるのです。また、体験をしていない人々に共感してもらうためには、インタビュー内容やプロダクト開発に至った背景を分かりやすくまとめることが今後の課題であると考えています。

数字分析の本質は？ 数字を分析するとき、一つの要素だけでなく、複数の要素を組み合わせて分解することで、新たな視点が得られることがわかりました。分解することで初めて見えるものがあり、実際にデータを操作してみることの重要性を感じました。エクセルで表をダウンロードし、関数や条件付き書式を使って分析することで、数字に隠れた情報も明らかになりました。また、どの要素をどのように分解すればどんな結果が出るのかを予測しながら作業することが、分析の精度向上に繋がると実感しました。 工数分析の効果は？ 具体的には、コールセンターの効率化にこの分析手法を活用したいと思います。応答時間、後処理時間、入電内容、お客様の待ち時間などの観点から、それぞれの業務にかかる工数を数値化できます。これにより、どの業務に多くの工数を費やしているのかを可視化し、効率化の余地がある業務を特定することが可能です。 多角度分析のヒントは？ さらに、コールセンターでは顧客から情報を得るだけでなく、それを様々な角度で分析して新たな顧客獲得のヒントを見つけることができると感じました。こうした情報は営業やマーケティング部門でも必要とされるでしょう。どんな情報が役立つかを部署間で話し合い、共有することが重要です。 新たな要素を探す？ 今後、毎月集計しているお問い合わせ内容や顧客情報を新しい要素で分析してみたいと考えています。これまではカスタマーセンターの視点で集計を行っていましたが、マーケティング部門の視点でどのように数字を分解できるかを検討し、目的に応じた分析を進めていきたいと思います。

どうして金融調査？ 金融関連の業務を担当するにあたり、まずは競合調査の一環として、顧客満足度上位の企業のwebページを確認しました。調査項目は、サービス内容、金利、セキュリティ対策の三点です。 なぜ実際に試す？ 担当クライアントは、顧客満足度においてサポート部門がトップである一方、web・アプリ部門では3位という評価でした。UIおよびUXの強化を目指すため、実際に口座を開設し、サービスを体験することにしました。 体験中の違和感は？ 口座開設のプロセスでは、窓口での対応とweb上でのマイナンバーカードによる審査を利用し、手続きは2日ほどで完了しました。全体的にスムーズでストレスを感じることはほとんどなく、スマートフォンを使った顔認識に関しては、背景に余計なものが映らないようにするためか、認識に少し時間がかかりました。 営業メールの謎は？ 一方、口座開設後は、毎週のようにメールでの営業連絡が送られてきました。そのため、金利に基づく金額の通知が他の営業メールに埋もれてしまい、見逃されることがあるという印象を持ちました。 改善要求の真意は？ クライアントからはUIおよびUXの改善依頼があり、提供された情報だけで対策を検討していた状況に不安も感じました。実際にサービスを利用しなければ気づけなかった問題点について、担当者間で共有しています。たとえば、営業メールの配信頻度を隔週に変更することや、メールタイトルに【レポート】やサービス名を含めることで、ユーザーが利用状況を一目で把握できるようにする提案を考えています。

営業観察のポイントは？ 私は営業経験がなかったため、営業の日常や業務、そして顧客の様子を観察することで、潜在的に満たされていないニーズや抱える問題に気付けると感じました。また、顧客向けのサービス改善については、普段から顧客と接点を持っている営業メンバーを初期段階から巻き込んでデザインすることで、自分だけでは実現が難しい新しい発想を生み出せると考えています。 体験と意見はどう違う？ 自身の体験に基づく感覚や気づきは大切である一方で、異なる視点を持つメンバーや顧客の多様な意見を収集することも重要です。特に担当する事業の規模が大きい場合は、万人受けを狙う必要があるため、幅広い意見を取り入れることが求められます。ただし、個性的な商品を開発する際は、強く実感した体験を基に判断することも必要だと考え、両者のバランスを意識して使い分けたいと思います。 調査手法の有効性は？ また、調査手法は複数存在しますが、一人で考えると非効率だったり視点が不足してしまうため、参加型デザインと調査を組み合わせることで、より有効なニーズ把握と具体的な打ち手の作成につながると感じました。客観的な観察とともに、実際に体験する参与観察の手法も非常に有効だと思います。 背負い具の課題は？ たとえば、バックパックに関しては、いくつかの課題を思いついたものの、どの課題が最もクリティカルな問題なのかは実際に体験してみないと判断が難しいと実感しました。体験を通じて、さまざまな課題が浮かび上がる中で、登山体験において特に重要な問題がどれであるかを見極める必要があると感じています。

選択と集中の意義は？ 選択と集中はよく耳にする言葉ですが、実際に実践するとなると難しさを感じます。自身の生活においても、本や衣類、思い出の品を手放すことが容易ではないように、会社ではプロジェクトや事業において同じ課題があると考えています。 捨てる条件は？ 捨てる際に最も困難なのは、その条件を明確にすることだと感じます。例えば、本であれば、どの段階でその役割を終え、手放すかという目標設定が必要です。同様に、衣類ではいつ再度着用するかなど、明確な基準が求められます。 撤退判断は？ また、事業に関しては、撤退の判断基準が不透明な場合が多いと感じます。たとえば、全体の売上に対して事業部の売上がどの程度後退したら撤退するべきか、また累積赤字がどこまでなら許容され、どの段階で撤退するかといった具体的な観点や条件について、社内で議論できればと思います。 投資効果の見極めは？ 製品企画や技術開発、販売営業といった分野においては、どのプロジェクトが投資効果を生むのかを見極める必要があります。そして、事業全体としては、どの段階で撤退や新規実施を行うのか、明確な判断基準を持つことが大切だと感じました。これらの基準を明確にすることが、今後の業務において判断や行動に大いに役立つと学びました。 指標の重要性は？ 一般的に重視される品質、コスト、納期といった指標がいかに重要かを再確認しました。タスク、プロジェクト、事業ごとに判断基準を設定し、それに基づいて進めるとともに、自分が取り組む業務には必ず情報発信を織り交ぜるよう努めたいと強く感じています。

どう学びを業務へ活かす？ 今週の学習を通じて、順序立てて俯瞰的に考えることの重要性を再認識しました。3C、SWOT、バリューチェーンといったフレームワークについては知識としては持っているものの、実際の戦略立案の場面では、これらを反射的に反応するだけで、十分に活用できていないと感じています。例えば、3C分析においては顧客と自社の要素しか分析できておらず、その他の要素についてどのように分析すべきか答えられない状態にあることに気づきました。これを受け、学習を通じて各フレームワークがどのような場面でどのように活用できるのかを理解し、今後の業務に活かしていこうと考えています。 チームの展望はどう見る？ 社内では次期の予算が固まりつつあり、私のチームのアクションプランを考える時期に来ています。しかし、これまでの視点は自チームの課題解決に偏りがちだったと反省しています。そこで、3CやSWOTを用いて、現在のチームの状況をより俯瞰的に把握していく方針に転換しました。 計画の具体策はどうする？ アクションプランの策定に際しては、まず現状の順序立てた分析を行います。具体的には、3C分析を通じて、顧客、市場、業界、競合を明確に分けて分析します。現在、社内のコールセンターで働いていますが、顧客設定についてしっかりと考えきれていませんでした。そこで、顧客を営業社員全員と捉え、それに対する期待されるサービスを明確に定義することにしました。また、同業他社だけに囚われず、目指すゴールに向けて不可欠な競合企業を設定することとしました。

クリティカルシンキングの活用場面は？ クリティカルシンキングは、課題解決や上司への提案、説得など多くの場面で活用できる思考法であることを理解しました。特に課題解決の場面では、自分の経験や勘に頼らず、関係する様々な人の立場から課題を見ることで、その本質を探り、より良い解決策を提案できると感じました。ライブ授業の「病院」をテーマにした課題では、病院に関わる人々の視点を変えることで、病院の役割について多様な考え方ができることに気づきました。また、他の受講生から自分にはない視点を学ぶことで、クリティカルシンキングの重要性を再認識しました。 システム要件定義への応用法は？ 現在、私は生命保険契約の電子手続き化に関するシステム要件定義作成に関わっており、部下が提案するシステム機能が本当に必要かどうか、管理職として判断を迫られることがあります。今回学んだことを活かし、視点や視座を広げ、顧客・営業・開発者・経営者の目線で機能のメリットとデメリットを考慮することが、より良い判断に繋がると実感しています。 どのように優先順位を考える？ 具体的には、部下から提案されたシステム機能の開発要否について、多角的にメリット・デメリットを洗い出し、優先順位を決めていきたいと思います。例えば、顧客目線では便利でも、実際の利用者が少なく費用がかさむ場合は、費用対効果を考慮して開発を見送るといった判断を意識して行っていきます。最終的に、部下や上司に対してなぜその判断をしたのかを説明する際、説得力のある説明ができると考えています。