(52ページ目)

課題

に関する学び

---

論理的思考の理解を深めるには？ WEEK1での学習を通じて、ビジネスで求められる「論理的思考」について理解が深まりました。特に「自分の考えは偏ること」を理解したうえで、「他にないか？」を考えることが重要であると学びました。この学びにより、視点・視座・視野の3つの視を意識することの重要性を理解しました。今週の学習では、自分の癖や弱点ではなく、仕組みとして理解できたことが大変有意義でした。 クリティカルシンキングで会議をリードする方法 私は仕事でクリティカルシンキングを活用し、特に社内外の会議で意見を述べる際に論理的な説明をするスキルを向上させたいと考えています。特に目上の方や経験豊富な相手に対しても、納得感を持って自身が導きたいゴールに着地できるようになりたいです。また、困難な課題に直面したときに適切な解決策を見つけ、チームを導けるようにもなりたいと思っています。 常識に囚われず新たな視野を持つ方法とは？ 特に強化すべきだと感じたのは、「自分の考えは偏るもの」であることを常に意識する点です。これまで経験や勘で業務をこなしてきたため、偏りが大きいと感じています。また、常識に囚われすぎる傾向もあるため、視野についても自分の物差しで物事を瞬間的に判断せず、非常識な可能性についても常に問い続ける癖をつけることが必要です。ビジネスにおいて論理的思考を使いこなせるよう、業務中に物事を判断する時や意見を求められる時、メールを作成する際には、一度立ち止まって考え直すことを心がけ、定着させたいと思います。

発注とユーザーの違いは？ ITシステムの外部委託先の立場から考えると、システム開発を進める際、お客様はエンドユーザーというよりも、顧客企業の担当部門として対応することが多いです。担当部門はユーザーと異なる視点を持つため、今回学んだエンドユーザーの立場よりも、発注者の意向に注力せざるを得ません。しかし、発注者との共感、課題の理解、試作品の作成といったプロセスは十分に実現可能です。真にエンドユーザーに役立つものを提供するのは難しいものの、発注者の満足を追求する姿勢が重要だと感じています。 満足の不一致はどう？ 一方で、発注者の満足を追求できたとしても、発注者がエンドユーザーに目を向けなければ、エンドユーザーの満足と発注者の満足は一致しなくなります。このような複雑な階層構造を持つ大規模な組織では、デザイン思考を一部の人だけが理解していても、途中のプロセスでその意義が薄れてしまうため、広く多くの人に理解してもらうことが必要だと考えました。 試作品の使い分けは？ また、プロトタイプの作成方法によって検証できる項目は異なるため、一つのプロトタイプが最適かどうかを問うよりも、各プロトタイプの特性を活かして使い分け、互いに補完していくことが重要です。さらに、組織階層が深い大規模な組織では、開発過程に関わるすべての人がデザイン思考の考え方を身につける必要があると感じました。加えて、生成AIを発注者役として活用し、想定問答を行う手法も有用であると実感したため、今後も積極的に取り入れていきたいと思います。

価値はどう伝わる？ サービスが提供する価値は、モノとそれにまつわる体験がしっかりとお客さまに届くことで実現されます。お客さまが「また買いたい」「また行きたい」と感じ、ファンになっていただければ、そのサービスは他と差別化できる大きな強みとなります。しかし、同じ体験が続くと魅力は次第に薄れてしまうため、常に新しい体験の提供が求められます。また、企業のブランディングやその打ち出し方も、こうした体験の一部としてお客さまに伝わっています。 営業から体験へは？ カンファレンスやイベントを通じたリード獲得から、実際の営業での商談、さらにはサービス導入前後のお客さまの体験まで、一連の流れがどのように評価されているかは、今後のサービス向上にとって非常に重要です。現在、ハイタッチとテックタッチの使い分けは進められているものの、お客さま向けのコミュニケーションプランの整備にはまだ改善の余地があると感じます。 現場の知見はどう？ さらに、実際にお客さまのもとへ出向き、現場の洞察を得ることは、サービス改善のために必須です。どのような前提知識で自社サービスが利用され、また課題や十分に活用されていないサービスが何かを深掘りすることで、お客さまのニーズにより的確に応えることが可能になります。加えて、社内ではヒアリングの様子をSlack huddleなどで共有し、従来のお客さまターゲットと今回のニーズとの違いや、求められているワンアクションの軽減点について、開発メンバーと共に検討することが大切だと実感しました。

顧客のニーズをどう捉える？ 顧客志向に基づき、長く愛される商品やサービスを生み出すためには、顧客のニーズの核心を捉えることが重要です。同時に、自社の強みを的確に理解し、それを活かす可能性を模索することも欠かせません。具体的な方法としては、行動観察やデプスインタビューなどがありますが、あらゆる事象を顧客視点で捉える姿勢が求められます。顧客ニーズを曖昧に捉えると、他社に追随されたり新商品に脅かされる恐れがあります。顧客が自らの費用ででも解決したい問題、「ペインポイント」を見つけ出し、それを「ゲインポイント」に昇華させることを目指します。 業務改善に必要な視点は？ 新しい業務で業務フロー図を作成する機会においても、実務者の視点から「ペインポイント」を特定し、それを解決することで業務改善へと繋げることができます。また、顧客視点をより強く意識することで、ヒアリングや課題の抽出・解決策の精度が高まると感じました。カスタマージャーニーという概念も学び、業務移管の場面ではより当事者意識を持って取り組むことが大切だと理解しました。 業務移管で心掛けるべきことは？ さまざまな業務移管や委託を受ける立場にあるため、移管元の人々の立場や業務工程を意識しつつ、ヒアリング、業務代行、業務フロー図の作成、改善提案を進めていきます。そのための準備として、ヒアリングの場面では、より詳しい状況や体験、関心事を引き出すことを重視しています。具体的な事象だけでなく、その背景にある体験や印象を言語化することも心掛けています。

学びで何が変わった？ 今週は、規模の経済性、習熟効果、範囲の経済性について学びました。これらはコスト削減に役立つという認識は以前からありましたが、具体的に言葉にして整理されることで、より実感できるようになりました。また、効果が見られない場合もあるという説明を受け、自分自身がその点に気づいていなかったことを再認識しました。 ネット効果をどう見る？ また、過去にゲーム業界、現在はIT業界にいるため、ネットワーク経済性に関しては日常的に意識する場面が多いですが、今回の学びにより、普段はあまり意識していなかった部分も含めて、再確認することができました。 固定費削減の秘訣は？ 私の所属する会社はデータ分析をビジネスの柱としており、これまで競合が比較的少なく、専門職であったため高コストでも許容されていました。しかし、最近ではLLMやAIエージェントの登場で、専門職に限定されない業務も増えているため、差別化戦略を検討する一方で、コスト削減が重要な課題となっています。いかに固定費を下げ、売上や利益を向上させるかが喫緊のテーマとなっており、今回の学びは具体的な施策を検討する際の重要な軸として活用していこうと考えています。 可視化で議論進む？ 今後は、各施策にフレームワークを適用して抜け漏れがないか、また見落としているメリットやデメリットがないかを整理し、可視化していく予定です。上司とのディスカッションは口頭で進むことが多いため、こうした可視化を通じて議論をより明確に進めていきたいと思います。

原因特定で悩む？ 問題解決のためには、「WHAT」「WHERE」「WHY」「HOW」の４つのステップで整理すると良いと感じました。私は特に「WHERE」の段階、つまり「原因の特定」に偏りがあったように感じますが、今後は「状況把握」や「解決策」に関しても仮説を立て、ロジックツリーを使って可視化するようにしたいと思います。一度有効だと考えた仮説に固執せず、全体を整理し直す柔軟な姿勢を大切にしていきたいです。 人事課題に挑む？ 人事課題では、正解がない問題が多く、一般論や他社の傾向と自社の実情が必ずしも一致しない場合があります。そんな中で自分が立てた仮説やその結論を明確にするため、ロジックツリーを作成しながら取り組んでいくことが重要だと感じました。また、これまで属性ごとに人事データを層別分解してきたものの、変数ごとの解釈が不足していたため、状況に応じてさまざまな角度から仮説の検証を行えるように努めたいと思います。 本当の問題は？ まずは、目の前のデータに頼るのではなく、何が本当の問題なのかを明確にするための仮説を立て、その仮説をロジックツリーのような形で整理していきます。現状のデータだけでなく、どんなデータがあればより適切な比較ができるかを考え、必要であればデータを収集できる体制を整えることにも注力していきたいです。 検証の進め方は？ 最後に、実際にデータを使って仮説を検証する際には、ログを残すことや、時間や状況の違いを比較することを意識しながら、着実に分析を進めていく所存です。

分解で見える変化は？ 物事の解像度を上げるためには、対象を細かく分解することが有効です。分解した結果をグラフにすると、視覚的に変化が把握しやすくなります。 単純合算は危険？ たとえば、①の切り口と②の切り口でそれぞれの結果を導き出した後、単に合算して「～の傾向がある」と判断してしまう自分の傾向に気づくことがありました。しかし、このような安易な判断では、実際の状況を正確に捉えられない可能性があります。 早期結論で誤解？ また、すぐに結論に至ると間違った傾向を導き出すリスクがあるため、複数の切り口で分解し、得られた結果を合わせて検討することが重要です。仮説を立てた場合は「本当にそうであるか」を疑い、さらに検証する姿勢が求められます。 MECEの使い方は？ MECE―もれなく、ダブりなく分解するという考え方―は、タスクごとにどれだけの工数がかかっているかを把握する作業に役立ちます。グラフ化により、全体の中で平均以上の工数がかかっているタスクを見直すことで、必要なリソースや業務の調整が行いやすくなります。 実例で確認する？ プロジェクトにおいては、MECEの手法を用いて、チームメンバーがどのプロセスで課題を抱えているのかを分析しています。ただし、「もれなく」を意識しすぎることで、カテゴリが過剰に分割され、現実の問題に完全にフィットしない場合もあります。実務上、これらの点をどのようにコントロールして使用しているのか、具体的な実例を示していただけるとありがたいと感じています。

プロトタイプの効果は？ 新規事業開発の現場では、従来、テキストや紙芝居を用いてコンセプトや提供価値を磨く方法を意識していました。しかし、議論をより活性化させるために、あえてプロトタイプを作成する有用性を学びました。また、毎週のグループワークでのディスカッションを通じて得られる新たな気づきも非常に意義深いと感じています。 感情と真因の探究は？ 今後は、自身が関わるサービス開発で次の2点を実践したいと考えています。まず、ユーザーとしての体験から得られる心理的変化に注目し、表面的なニーズだけでなく、感情面に踏み込むことで利用者の情動を捉えること。次に、顧客の悩みの奥に潜む思考や本能、その背景の制約条件を探ることで、根本的な課題や真因を見極めることです。デザイン思考においては、この2つのプロセスを徹底することが、結果的に発想や試作品作成の近道になると考えています。ただし、議論を進めるためのツールとしてプロトタイプは有効なケースもあるため、状況に応じて活用することが重要です。 アイデアはどう生む？ また、アイデア発想のプロセスについても挑戦してみたいと思います。アイデアは、具体と抽象の深さ、多角的な視点、そして顧客視点の掛け合わせによって生まれるものです。基本的な流れとしては、現状の課題を洗い出し、KJ法で構造化し、課題を絞り込んだ上で、SCAMPER法などを用いてアイデアを発散。さらに抽象度を上げて再度発散させ、最終的に収束させるというプロセスを磨いていきたいと考えています。

プロトタイピングの留意点は？ システム開発では、定められた手法に沿った実践が成果の成否を分けるとよく言われます。その一環として、プロトタイピングが推奨される場合もあり、顧客に実際の成果物に近い形を見せることで、齟齬がないかを確認することが目的です。しかしながら、プロトタイピングはコストがかかる点や、成果物に近いがゆえに本来の目的と異なる変更が行われるリスクがあると感じています。そのため、KT法など他の手法も併用すべきではないかと考え、今回の学びを改めて実務に活かす必要性を再認識しました。 初期案件で試す価値は？ 開発初期の案件でこれを試みるのが最もやりやすいと感じています。初期段階であれば、手法や認識に囚われ過ぎず、目的を確実に反映させることが可能だからです。現在、ヒアリングの初期段階にある案件もあるため、その案件で実践してみたいと思っています。目的の決定においてはMUSTとWANTの両面が存在することから、これらを明確にし、常に共感を得続ける姿勢が大切だと考えています。 非線形プロセスの注意点は？ また、WEB制作も手がけている中で、ビデオ内の説明は非常に分かりやすかったと感じました。実際に手を動かしていない方にはイメージしにくい部分もあるかもしれませんが、実務では線形的なプロセス進行が理想とされる一方、現実には非線形となる場面が多いことが大きな課題となっています。手戻りは望ましくないものの、「手戻り禁止」ではなく、最低限に留めるという意識が必要であることを改めて認識しました。

明確なメッセージの設定 スライド作成において重要なポイントは、以下の通りです。 まず、伝えたいことを明確にすることが最も重要です。誰に何を伝えたいのかをしっかりと定め、それを基にスライドを構成します。また、フォントや色、アイコンは効果的に使用し、視覚的な印象を強化します。 誰にでも伝わる視覚表現 さらに、グラフはデータや表現内容に応じて適切なものを選び、一目でわかるように作成します。相手に考えさせるスライドではなく、誰もが読んですぐに理解できるものを目指します。 課題解決のためのステップ 営業で抱えている課題を解決するためのプレゼン資料を作成する場合、まず現状の課題を明確にし、将来的なゴールを設定します。その上で、ゴールを達成するための施策やツール導入を順序立ててスライドにまとめます。こうすることで、抽象的な内容を避け、具体的な数値を用いたグラフも織り交ぜることが求められます。 データ収集と構成の順序づけ 最初に現状把握を行い、課題認識をすることが必要です。これには、課題に関連するデータの収集が含まれます。スライドの組み立てにあたっては、まずこの提案で何を伝えたいのかを明確にし、それを基に順序立てて構成します。伝えたい内容が明瞭に伝わるよう、グラフやアイコンを適宜活用しながら作成を進めます。 フィードバックを活かすには？ 最後に、完成したスライドを評価してもらう機会を設けます。部内などのフィードバックを受けることで、より洗練された資料を完成させることができます。

現状は何を示す？ 問題解決のプロセスでは、まず「What：問題の明確化」から始め、現状とあるべき姿のギャップを把握します。現状を定量的な数値で示し、関係者間で共通認識を持つことが重要です。取り組むべき問題は、単なる異常事態の解消だけでなく、目指すべき姿へ到達するためにも活用できます。 どこに問題が潜む？ 次に「Where：問題個所の特定」に進みます。ここでは、Whatの段階で整理した構造を基に、具体的な問題箇所を抽出します。たとえば、売上の構造を「客数×客単価」といった形で分解することで、問題所在を明確にすることができます。 なぜ原因を探る？ 「Why：原因の分析」では、特定した問題箇所をさらに下位概念に分解し、具体的な原因に迫ります。詳細な原因把握は、問題解決のための重要なステップとなります。 どう取り組む解決策？ 最後に「How：解決策の立案」を行い、制約や条件を踏まえた上で効果的な対策を導き出します。各ステップを順に辿ることで、全体像を把握しながら解決策を組み立てることが可能となります。 どうしてツリーを活用？ また、クライアントから抽象的な課題が事前に提示されることが多いため、ロジックツリーを作成して情報を整理することが効果的です。全体の流れや解像度を上げることで、関係者間の認識合わせがスムーズになり、感度の良い切り口を見つけやすい環境が整います。案件のキックオフ時には、まず自分なりにロジックツリーを構築し、可視化することでその効果を実感できるでしょう。

課題の本質は？ 課題を明確にすることの重要性について学びました。大まかに課題を把握するだけでは、その根本原因を解決するには至りません。具体化することで、本質的な課題を捉えることが可能になります。イシューに対する方策や判断は、経験に依存する部分もあるため、知見や経験、俯瞰的に捉える力が必要だと感じました。課題や問いに対するイシューの捉え方は、考え方次第で大きく変わるため、間違いに気づくことが難しい場合もあります。 どう活用される？ このような学びは、日々の業務、例えば社内外の会議、製品の不具合対応や要因究明、現行業務の方針決定、将来の業務の企画戦略など、さまざまな面で活用できます。特に会議など、口頭でのやり取りでは、イシューや課題から逸脱しないようにする意識を持ち、全体への共有を意識しています。また、資料作成の際には、最初にイシューや課題を意識し、フレームを構築することを重視しています。 会議で意識は？ 打ち合わせの際には、まずイシューや課題の共有を行い、全体の方向性を合わせるよう努めます。会議に参加する場合には、認識のズレが発生しないように課題を確認し、内容が逸れたりしないように軌道修正を行います。資料作成時には、イシューや課題から外れていないかを意識し、作成に取り組みます。資料を書く前に、イシューの特定と枠組みを考え、相手に理解してもらえるように図などで可視化することが大切です。このプロセスでは、他の人に確認してもらい、フィードバックを受けることも心がけています。