作成 ✕ 言語

に関する学び

---

提言の進め方は？ 普段は、自部門における業務改善提言をまとめる際、現状分析から課題の洗い出し、解決策の検討、そしてプロトタイプ作成にあたる「改善施策案」の作成まで、一連のステップを踏んでいます。その後、実際の現場にパイロット運用してもらい、評価結果を反映させたうえで全社展開するという流れで進めています。しかし、これらは経験則に基づいて実施しているため、精度については疑問を抱くことも多く、「本当にこれで良いのか」「もっと深く検討すべき点はなかったか」「チームにしっかり伝わっているか」といった不安がつきまといます。 情報設計はどう活かす？ 今回学んだ「情報設計」では、ユーザーストーリーマップやカスタマージャーニーマップを用いて、一連の行動を可視化する手法が印象に残りました。仮説に基づいてコンテンツを洗い出し、ワイヤーフレームとして可視化することで、「誰に・何を・どのように」という視点を意識しながら情報の構成を検討する重要性を実感しました。また、モックアップ作成時にもアクセシビリティやユーザビリティを意識しつつ、現場の実情に合わせた設計が求められると感じました。 モックアップは要注意？ 私の場合、業務改善提言に基づく施策案をプロトタイプとして捉えると、どうしても現場では具体的な作業方法や運用フローが前面に出やすくなり、結果としてモックアップになってしまうことが多いです。確かに、モックアップは現場の方々にとって分かりやすく、何をすべきかを直感的に提示できます。しかし、それが本当に効果的な施策であるかどうかは、ワイヤーフレームで情報の骨組みをしっかり設計し、基盤となるユーザーストーリーを正確に捉えることが必要だと改めて感じました。こうした視点を深く分析し、可視化することで、チーム内で課題を共有し、伝えることができると感じています。 共感で見える課題？ また、プロジェクトの初期段階においては「共感」が非常に重要であると実感しました。先週、現場のエンジニアから「資料に説明が見当たらず、作業ミスが発生してしまう」との意見が出た際、彼らの状況や日々の業務背景を考えると、確かに説明不足は理解しやすい問題だと共感しました。一方で、別のメンバーが資料の他の部分で情報が補完されていると指摘するなど、一見対立する意見もあり、現場で働く人々の視点や状況に寄り添わなければ本質的な課題を把握し、改善策を導き出すことは難しいと痛感しました。 アイデアは整理できた？ 今回のプロトタイピングでは、具体的なアイデア検討と自身の業務との関連付けを行いながら、意識すべきポイントを学ぶことができました。前回学んだ「言語化する」という手法と今回の「可視化する」という手法は、どちらも抽象的ながらも常に意識すべき要素だと感じています。情報設計、コンテンツ設計、そしてUI設計という一連の流れを通じて、体系的な実践方法を整理できたことは大きな収穫です。特に、ユーザーストーリーマップやカスタマージャーニーマップを用いてユーザーストーリーを正確に捉える点については、これまで疎かにしていた部分を改め、しっかりと実践していく必要があると強く意識しました。 目的を見失って？ 一方で、どうしてもモックアップ作成に偏ってしまいがちな点、つまり自部署や自分の目的を優先してしまう傾向があることにも改めて気づかされました。あるメンバーが自作の資料に固執し、必要な対策が偏る事例を目の当たりにした経験から、業務改善その本来の目的である「ユーザーの目的」を見失わないためにも、情報設計を通じた体系的なアプローチの重要性を痛感しています。今後は、この学びをチームメンバーと共有し、偏った施策にならないように取り組んでいきたいと思います。

共感体験で何が分かる？ まず、デザイン思考を通じて印象的だったのは、ユーザーになりきった体験を重ねる「共感」の力です。実際に現場で体験することで、教える側では気づかない学ぶ側の困難や新たな気づきが得られました。たとえば、プログラミング指導において、教員自身が初学者として言語の習得につまずく経験をすることで、より効果的な指導方法を模索できると感じました。 問題整理の意義は？ また、問題を「誰が・どんな状況で・何に困っているか」と具体的に整理することの重要性について学びました。漠然とした課題意識を再定義し、本質的な問題へと落とし込むことで、解決策の方向性が明確になるという気づきがありました。加えて、SCAMPER法など多角的な発想法を用いると、従来の固定概念を超えた新たなアプローチが生まれ、実際にバックパックの軽量化などの具体例でも確認できました。 早期試作ってどう？ さらに、早い段階で試作を行い、フィードバックを得るサイクルの大切さも実感しました。完成度を完璧に求めるのではなく、手早く形にして検証することで、目的に合った試作方法（デザイン画や実物試作、説明動画など）を効果的に活用できると感じています。そして、机上の理論だけでなく、実際の環境でテストを重ね、逐次改善していくことが、真の成果につながると理解しました。 学びの応用はどう？ こうした学びを高専教育にどう応用するかというと、まずは学生の立場で課題を体験し、そのプロセスや困難を共感的に捉えることが第一歩となります。たとえば、電子工学実験では、学生が回路設計や測定機器の使い方でつまずく場面を自ら体験し、具体的な改善策を模索することが挙げられます。また、プログラミング授業では、エラーの解決に向けた視覚的な解説や、ペアプログラミングを取り入れることで、初学者が段階的に成功体験を積む環境を構築しようとしています。 行動計画は大丈夫？ 具体的な行動計画として、プログラミング演習では、授業ごとに学生のつまずきポイントを記録する「学生目線観察ノート」を活用し、エラーメッセージや解決策を図解したガイドの試作を進めます。次学期には教員間でワークショップを開催し、学生の課題を洗い出すとともに、実践的な演習課題セットの開発を行います。さらに、半年以内には地域の技術者を招いたワークショップで新教材の効果検証とフィードバックの収集を予定しています。 実験の壁は何？ 電子工学実験に関しては、実験前後で自ら学生視点で取り組むことで、操作の不明点や手順上の課題を記録し、「つまずきマップ」を作成します。次学期には、視覚化された新たな実験ガイドや補助教材の試作を進め、実際の授業で試用して理解度の向上を測定します。半年以内には、これまでの成果をもとに他の実験テーマへも応用可能なガイドラインをまとめ、学内で展開する方針です。 運営改善は可能？ また、研究室運営の革新に向けても、週ごとのミーティングで「プロトタイピング報告」の時間を設け、進捗や課題の可視化に努めます。新入生への研究テーマ設定ワークショップや、知識共有のためのデジタルナレッジベースの構築、さらに企業や地域との連携を通じたフィードバックの仕組みを取り入れることで、研究活動全体の改善を図ります。 未来の育成はどう？ これら一連の取り組みは、学生の学びの質の向上と、高専教育そのものの革新に寄与するためのものです。教える側が学生視点で実際に体験し、試作・検証を重ねながら、理論と実践のバランスを保った教授法を確立することで、将来社会に貢献できる技術者育成を目指していきたいと考えています。

仮説の意味は？ 今週の学習では、「仮説」とは、不確かな状況下で行動するために立てる仮の答えであるという理解を改めました。特に、「結論の仮説」と「問題解決の仮説」という2つの分類が印象に残りました。 検証のプロセスは？ 結論の仮説は、戦略や提案を行う際に、まず仮の答えを設定することで議論の出発点を作り、その後の検証と修正を通じて精度を高めるアプローチです。一方、問題解決の仮説では「What→Where→Why→How」といった段階的な掘り下げにより、原因と対策を導き出すプロセスが紹介され、思考の整理に非常に効果的だと感じました。 現場で有効か？ これらのフレームワークは、限られた情報の中で迅速な意思決定が求められるビジネス現場において、強力なツールとなると実感しています。私は、AIやデータ分析関連のソリューションを扱う営業を担当しており、顧客の課題特定や提案内容の作成において、不確実な情報を扱う機会が多い中、学んだ「仮説思考」が非常に有効だと感じました。 仮説検証のコツは？ 例えば、初回訪問時に顧客がまだ課題を明確に言語化していない場合でも、「業務プロセスの非効率があるのではないか」「蓄積されたデータがうまく活用されていないのではないか」といった仮説を立てることで、仮説検証型のヒアリングが可能となります。これにより、単なる情報収集に留まらず、仮説に基づいた深掘り型の対話で本質的な課題に近づけると感じました。 提案の説得力は？ また、提案の段階においては、「ある部署では意思決定が属人的で、データドリブンな仕組みの導入により業務効率を向上できるのでは」という結論の仮説を基に提案を設計することで、ストーリー性のある説得力の高い提案が可能になります。商談時間が限られている中で、このような仮説をもとにしたアプローチは非常に重要と感じました。 失注の理由は？ さらに、失注や案件停滞の原因を検証する際にも、「なぜ受注に至らなかったのか」という問題解決の仮説を設定することで、次回以降の提案の質を高めるフィードバックループを構築できると感じました。 商談前の工夫は？ 具体的な取り組みとしては、まず初回商談前に「業界特性・顧客規模・職種」などの観点から、課題仮説とニーズ仮説を2～3パターン想定し、ヒアリング項目に落とし込むテンプレートを自作しています。たとえば、製造業では「設備点検や不良検知にAI活用のニーズがあるのでは」といった仮説を用意し、仮説検証型の商談を組み立てることで、短期間で核心的な課題に迫るという方法です。 案件停滞の原因は？ また、受注が見込まれていたものの急に停滞した案件については、どのステークホルダーが懸念しているのか、どの提案要素に説得力が不足していたのかといったWhy型の仮説を設定し、上司やチームとの定例レビューで検証しています。これにより、再提案やフォローアクションの精度を高め、案件化率の向上を目指しています。 アウトプット文化は？ さらに、営業週報や朝会において、「この案件は〇〇という仮説でアプローチします」といった発言を推奨し、仮説をしっかり言語化してアウトプットする文化を醸成しています。こうした取り組みは、個々の思考の質の向上やナレッジの蓄積につながると実感しています。

調査ログの見直しは？ 今週、育児期間中の30～40代を対象に実施した過去のインタビュー調査ログを見直す作業を行いました。コーディングを意識しながら作業する中で、改めて一次データの重要性を実感しました。 抽出視点の違いは？ ログから課題やニーズにつながる事象や行動を抽出する作業は、人の目に依存するため、抽出の視点が人によって異なりやすいと感じました。動画内でも経験が強調されていましたが、バイアスが働くと必要な情報に気付かなくなる可能性があるため、情報を絞りすぎると大切な観点を見落としてしまいそうだと危惧しました。 共感の重要性は？ デザイン思考の最初のステップである「共感」では、ユーザーの見えない課題やニーズを発見するために、観察、体験、インタビューを繰り返すことが重要です。インタビューでは、観察で気になった行動の背景を心理面から深掘りし、共感を得られるように課題やニーズを言語化します。こうして得た情報をテキスト化し、コーディング分析を行うことで、単なる観察だけでは浮かび上がらない本質的な課題や行動を明らかにすることができます。 行動の理由を探る？ 実際、観察や体験で注目した行動をインタビューで詳しく聞くことで、ユーザーが無意識に行っている当たり前の行動の理由を解明するプロセスの重要性を実感しました。課題を抽出する際は、互いの思い込みや認識の差が生じやすいため、情報共有を通じて共通認識を合わせることが求められます。しかし、立場や利害関係が異なる中で何を重視すべきかを調整するのは容易ではなく、うまく進む場合とそうでない場合があると感じました。 定性調査の有用性は？ WEEK-3で学んだ定性調査は、新しい領域や馴染みのない状況で仮説を構築する際に有効な手法だと感じています。定量データだけでは掴めないユーザーの姿勢や心理を探るのに、インタビュー、フィールドリサーチ、ログ（日記）などの手法が効果的です。実際、観察を通じてユーザーが意識していない行動や癖から気付かないニーズや課題にアプローチできることもあります。 仮説構築の進め方は？ 定性調査では、まずインタビューやフィールド調査で得た情報を整理し、要点となる事象や課題を抽出します。その後、抽出した要素をカテゴリー分けして情報を圧縮し、最小限の要素にまとめた上で、フレームワークやプロセスの形に図式化・構造化することで仮説モデルを作成します。 ヒアリングの工夫ポイントは？ また、インタビューの際にヒアリング項目を整理したシートを事前に作成し、記入してもらってから話を聞く方法も有効だと感じました。ただし、記入式では重要な点が十分に言語化されない場合があるため、まずは日常の業務や業務フローなど現状を把握することから始める工夫が必要です。ヒアリングが雑談になり、課題に焦点が定まらなくなる場合は、ジョブ理論を参考にするのも一案です。実際、グループワークでフォームの改善に取り組んだ参加者の話では、ユーザーが入力の手間を感じないようにするため、従来の枠にとらわれない解決策が模索され、その柔軟な発想が印象的でした。

捨てる判断が重要な理由は？ 自身の職場では「捨てる」判断が関係者から賛成を得やすいパターンがあり、それは大半が「自分も面倒臭い、無駄だと思っていたことがなくなる時」です。反対に反発を受けやすいのは、新しいことを始めるために古いことを捨てる時で、「新しいことの方が工数が多く面倒そうだ」と感じる場合が多いです。これはどこの職場でもある程度パターン化されており、傾向が見えやすいと思います。 お試し期間の意義とは？ 現在の職場では、新規プランを継続するかを検討するために「お試し期間」を設け、関係者からヒアリングを行いつつ、時にはあっさりと「捨てる」決断もしています。これは十分なリソースがあるからこそ実現できることですが、リソースの有無に関わらず、「捨てる」際の指標を明確にすることが重要だと感じました。 整理整頓で気づいた問題点は？ 日常的に「整理（整頓）」することは習慣化できていますが、整理整頓の選択肢として「捨てる」ということは無意識的に除外していることに気付きました。それは、ブランドの事例のように中途半端な状態に陥らないかという点を危惧しているからです。トレードオフ関係の有無といった要素の洗い出しが十分に行えていないことや、自分の判断に自信がないことが根底にあるのではないかと考えています。難しい判断であるからこそ、関係者の納得感を得るために「捨てた場合」だけでなく、「捨てなかった場合」も含め、あらゆる方向から検討が必要です。それに加え、スピード感を意識しながら実行できるようになりたいと感じています。 技術伝承の課題はどう克服する？ サービス技術の伝承は大別して、①ある程度マニュアル化されているもの、②経験者から教わるものの2種類があります。後者が圧倒的に多く、昔からの慣例に縛られることが多いため、「捨てる」判断が特に難しいです。そんな時に力を発揮するのは「時間」です。特に私たちの現場では「残された時間」や「安全の観点」は絶対に他のものとトレードオフの関係にならないということも今回、言語化・明確化できたことは収穫です。 過去の業務態度に学びはある？ 過去の業務態度を思い返すと多数のプロジェクトが動いていた際には、目まぐるしい日々の中でROI（費用対効果）検討の「時間配分1％あたりの利益率の算出」といった表作成に時間を割くことは難しく、余裕も感じていませんでした。振り返ると、工数管理は実施していたものの、ざっくりしたプランニングであったため無駄な工数が発生していたり、リードタイムをさらに短く設定することが可能な部分も多かったと反省しています。

エンパワメントは何が肝心？ ■エンパワメント・マネジメントについて エンパワメント・マネジメントは、リーダーシップの技法のひとつです。目標は明示しながらも、実行方法はメンバー自身の判断に任せることで自律性を促進します。また、メンバーが活動しやすい環境を整える支援が重要となります。実行プロセスにおいては権限と責任を譲渡し、育成に努めるエンパワメント型と、すべての命令を管理する命令管理型とがあります。 どう実践すべきか？ ■エンパワメントの実践ステップ エンパワメントの実践には、以下のステップがあります。すべてのプロセスでは、双方のコミュニケーションを重ねることが自立を促すために必要です。 ① 目的やビジョンの共有 ② 対象者の把握 ③ 適切な仕事の割り当て ④ コーチングによる動機付け ⑤ 実行支援 注意すべき点は？ ■実践時の留意点 ・各メンバーに適した仕事、あるいは不向きな仕事を見極めること ・部下の持つ権限が十分に機能していない状況を避けること ・リスクを想定し、対策を事前に準備しておくこと 現状の課題は？ ■直近の業務と発生している課題 私が直近で担当しているシステム開発におけるテストでは、複数のシステム連携テストを実施するため、以下の作業を行っています。 ① システムテストの計画作成 ② テストシナリオの作成 ③ システムテストの実行および推進 しかし、現状ではテスト対象や関係するシステムの内容が十分に共有されていない課題が発生しています。直接の原因として、以下の3点が挙げられます。 ・ドキュメントによる情報共有がなされていない ・情報が日本語で記述されていない ・イメージ図が用いられていない どのように対応？ ■対応策と運用方法 対象は課題が発生している各担当者です。これまでは目標は明示し、遂行方法はメンバーの自主判断に任せるエンパワメント・マネジメントで進めていましたが、現状を改善するため命令型に一部切り替え、フォローアップを強化する方針です。 具体的には、発生している各課題に対して、私自身が実際に動いて一つ一つ内容を整理していきます。また、ゴール達成のために必要なタスクをより細かい粒度で言語化し、メンバーとともにタスクを解消していく形で進めます。再度、以下の課題点について検討・改善していきます。 ・ドキュメントでの情報共有の不備 ・日本語での記述不足 ・イメージ図の欠如

分析を成功させるためには？ ライブ授業を通して、次の3点を改めて整理できました。 まず、分析は比較によって成り立つということです。目的とアウトプットを明確にしてから分析に取り組むことで、闇雲な作業を避けることができます。 問題解決のステップをどう活用する？ 次に、問題解決のステップ（What-Where-Why-How）の重要性についてです。当日の演習を通じて、これを実際に活用するイメージがつかめました。各ステップでは、目的を明確にし、ロジックツリーの活用や仮説設定、データ収集方法、データの見せ方などのポイントを整理しました。 データ分析から得た新たな発見とは？ 最後に、分析のステップとして、検証したいことを具体的にし、仮説を立て、何と比較するかを意識しながらデータを集め、加工してビジュアル化することで、新たな発見が得られることを再確認しました。 また、データ分析の活用については以下の3点が挙げられます。 1. 企画立案時のマーケティングプロセスにおけるデータ活用 現状では、企画立案が現場の勘や経験に偏りがちですが、データを用いることで、より良い意思決定や施策運営につなげたいと考えています。さらに、他の施策との比較や過去のデータ分析を通じて課題点を洗い出し、マーケティングプロセスを改善していきます。 2. 施策振り返り時の検証 施策を振り返る際には、実績に対する問題や課題を明確にし、次の意思決定のために仮説を立てて検証することが重要です。 3. 課題解決に向けた活用 具体的な課題が提示されたときは、問題解決のステップと仮説検証の考え方を用いて取り組んでいきます。 学習方法の見直しがもたらした効果 これらの活用方法を通じて、アウトプットを進めていきたいと考えています。 さらに、本講座の復習をしっかり行い、学んだことを言語化しアウトプットできるようにし、問題解決ステップや仮説思考、フレームワークを実務に取り入れて練習します。自然に使いこなせるようになることを目指します。また、周辺知識の学習も継続的に進めていきます。データ活用にはクリティカルシンキングや伝える力、マーケティングに関する知識が必要で、今回自分に合った学習方法が見えたのも大きな収穫です。 今年度の目標達成に向けた取り組み 今年度は、施策の乱立を防ぎ、効率的な施策運営のために可視化データを作成し、リソースを他の業務に割けるようにしていきたいと思います。そして、掲げた目標に向けて努力を続けます。

分析とは何を理解するべき？ 分析とは何かについて理解しているつもりではあったが、それを言語化することが出来ていないことに気づかされた。また、ライブ授業や動画学習で言及される内容は日常的に行っていることでも、その目的や意図を明確にすることの重要性を改めて認識した。 ライブ授業での学びとは？ 【ライブ授業】 分析の基本的な考え方として、「具体的に」かつ「はっきり」とさせることで意思決定に役立てることが非常に印象的だった。これは当たり前のことながら、この理解により方向性や手法を誤らないための指針として機能することがわかった。さらに、棒グラフについては、縦よりも横の方が差を認識しやすいというテクニックが参考になった。分析が第三者に理解され、納得してもらうことが目的であるため、このようなテクニックは非常に有意義であると感じた。 動画学習で気づいたことは？ 【動画学習】 「Apple to Apple」のように、分析には条件が等しいものを比較することが重要である一方、世間には意図的に「Apple to Orange」を行っている情報も存在する。この講義では、提示された資料の分析目的や意図を意識することの重要性について学んだ。また、生存者バイアスの考え方も参考になった。目に見えるデータに偏りがちだが、隠れたデータが示す意味について仮説を立てて考えることが重要であると学び、業務に生かしたいと思った。 後輩指導にどう活かす？ 後輩の指導や同僚の資料作成の際には、この講義で学んだ考えを意識して取り組みたい。その分析の目的は何なのか、比較対象は正しいのか、隠れたデータが何を意味しているのか。与えられた情報だけでなく、背景を含めて俯瞰する視点を持ちたい。また、自分の行う分析や提案に際しても同様に、目的を持ち、仮説を立て、対象を選定し、隠れた情報に注意を向けることを意識する。 高精度な需要予測を目指すには？ 私の担当する製品はSKUが非常に多く、その需要は季節や景気、エンドユーザーの意向によって大きく左右される。また、競合他社の動向にも影響を受け、需要予測が難しい。これまでは自部署の過去データのみを参考に需要予測と予算を立案していたが、これは客観性に欠けていた。今後は業界実績やその時のトピックスも取り入れることで、生存者バイアスを避け、より精度の高い分析を行いたいと考えている。

誰に向ける思いは？ 「誰に何を」の「誰に」の部分の重要性を学びました。特に、現在取り扱っているSaaSサービスでは、開発側の「誰に」の思いが先行しがちだと感じています。もちろん、思いは大切ですが、想定している市場に十分なポジショニングがあるか、自社製品が届けることができる価値が十分に感じられる対象であるかを客観的に分析したいと思います。また、複数の価値を組み合わせて提供することで、価値を最大化する意識を持ち続けたいです。 魅力伝達はどうする？ プロダクトの強みやアピールポイントを考える際、アピールポイントとそのターゲットを一対一で考えがちでした。今後は、複数のアピールポイントを組み合わせて、より魅力的な形で伝える視点を重視していきたいです。 訴求対象は何処？ ①プロダクトを訴求するターゲット検討の場面では、クラウド型サービスの特性上、ターゲットを見直し、開発のロードマップを検討する必要があります。現状、開発側の「誰に」の思いが先行しがちな状況なので、今回学んだ「想定したターゲットに関する市場規模の確認」や「バックオフィス向けサービスの概念の見直し」を行いたいです。 認知施策は何が鍵？ ②ターゲットへの認知獲得からコンバージョン（CV）の施策やメディア内容の検討では、開発したプロダクトのメリットを洗い出し、ポジショニングマップを作成したいと考えています。このポジショニングマップを共通言語とすることで、チーム内でも一致した訴求ポイントや施策検討が行えるようにしたいです。 市場規模は再確認？ まず、現在のターゲット市場規模を確認し、売上見込みの再評価から始めたいと思います。そして、バックオフィス向けのプロダクトが経理部向けという状況を見直し、本当にメインターゲットが経理部でいいのか再確認します。そのためには、考えうるターゲットを再度洗い出し、各市場規模を整理し、6Rのフレームワークで判断を確かなものにしたいです。 差別化の強みは？ プロダクトのメリットを洗い出す際には、「クラウド」「AIの活用」「多言語対応」「UIの良さ」などを挙げ、それらを組み合わせることで、他社との差別化を図ることを目指します。このプロセスは一人で行うだけでなく、チームで行い、新たな強みやポジショニングを発見するとともに、チームで一貫したポジショニングイメージを共有したいと考えています。

振り返りから何を学ぶ？ Week1の学習を振り返り、断片的に記憶しているワードはあるものの、まだ自分の中で十分に消化できていないことを感じました。人に伝えるには、より深く学び直す必要があります。この体験を通じて、忘却曲線の存在を実感し、学び続けることの重要性と反復トレーニングの必要性を改めて認識しました。 目標設定での課題は？ 今後の目標を言語化する際、どうしても視野が狭くなり、普段の考えから広がりません。そこで思考が止まってしまうことがあります。「なぜ」を掘り下げることが足りないと感じており、これもトレーニングの一環だと理解しました。 書く力をどう伸ばす？ 日々の業務ではスピード重視で、メールを書く際も思いつきで始めがちです。しかし、わかりづらい文章は相手に負担をかけるため、書き始める前に少し考えて思考を整理することを意識する必要があります。時間はかかりますが、このトレーニングを通じて思考の癖をつけたいと考えています。 効果的な会議の進め方は？ チームミーティングでは、「issue」の設定がないまま議論が始まることが多く、脱線して時間が過ぎることがあります。そこで、「問を設定する」「問を確認し続ける」「問を共有する」ことを意識してファシリテートしていきます。また、チームメンバーにも「issue」の重要性を具体例を通じて共有したいと考えています。 課題解決に必要なアプローチは？ 「組織の業務分担をどのように変更するのか」という現在の課題について、現時点ではチーム内で暗黙の了解があるような状態です。しかし、これでは説得力が欠けます。そこで、クリティカルシンキングで学んだ分解・ロジックツリー・視覚化を用いて、上司にも納得してもらえるようなプレゼンを作成したいと考えています。 今後の学びをどう深める？ まずは本講座を再度振り返り、知識のインプット、それを自分の頭で整理し、実業務で活用するというサイクルを回すことが重要です。クリティカルシンキングを習得するために、他者とのディスカッションの機会を意識的に作り、思考の癖についてフィードバックをもらったり、他者の視点から気づきを得ることが効果的であると実感しました。反復トレーニングで土台を作った後も、他の単科受講など、学びを止めず、自身を高め続けることでチームを牽引していきたいと思います。

どう進める？ 問題解決のプロセスでは、ステップごとに考慮し、解決の基準を言語化し、数値化して、関係者内で合意を得ることが重要です。具体的には、問題の明確化（What）、問題箇所の特定（Where）、原因の分析（Why）、施策の立案（How）という流れで進める必要があります。あるべき姿と現状のギャップを定量化することも求められます。このギャップには、正しい状態に戻すための問題解決と、ありたい姿に到達するための問題解決の2種類があります。 どう区別する？ また、MECE（もれなくダブりなく）に基づいた分け方での問題の区別が重要です。施策の検討においては、ロジックツリーを用い、施策案を作成し、ファクトに基づく評価基準で絞り込むことが必要です。さらに、複数の切り口を検討する準備をすることが大切です。 分析はどう？ 定量分析には5つの視点があります。具体的には「インパクト（全体への影響度合い）」、「ギャップ（目標との比較）」、「トレンド（時間軸での把握）」、「ばらつき（集中、均一）」、「パターン（外れ値や変曲点の活用）」があります。特に外れ値については、積極的にビジネスに活用する視点が新しい考え方です。 数値はどう見る？ 案①「正しい状態に戻すための問題解決」では、年度目標未達が具体的な問題であり、KGI（人数・収入・営業利益）やKPI（Web流入数、CVR、CTR）が定量化されています。やるべきことは、販売チャネル別の数値把握、変数分解の可視化、定量分析の5つの視点で再検証を行うことです。具体的には、販売チャネル別の人数・収入・利益を再検証し、優先順位を設計し、施策を可視化します。 組織はどう整える？ 案②「ありたい姿に到達するための問題解決」では、来年度の組織編制が具体的な問題として挙げられています。計画人員やグループ数が具体的に定量化されており、現状の可視化、中長期的なトレンド把握、目標設定が必要です。具体的には、各課の強みや啓発点の洗い出しを行い、組織の現状の業務が将来の目標に向けて十分であるかを評価し、不足もしくは不要な業務を見定めます。 まとめはどうする？ このように、問題解決のステップとMECEなどの手法を用いて、具体的な解決策を導き出すためには、論理的で整理されたアプローチが不可欠です。

言葉遣いの改善点は？ これまでの自分の伝え方に改めて目を向け、正しい日本語と手順で相手に分かりやすく伝えることの重要性を理解しました。具体的には、以下の点を意識する必要があると感じました。 まず、主語（隠れた主語）と述語が繋がっているか、主語のすり替えが起きていないかを確認すること。一文を長文にしない（60文字以内）ことも大切です。 思考を整理する方法は？ 自分の理由付けを考える際には、どのような視点で理由付けをしているかを意識する重要性も理解しました。しかし、自分の書いた文章を客観的にチェックすることは難しく、これを怠ると受け取り手に迷惑がかかるという解説が特に心に響きました。 複数の理由付けを考えることで、言いたいことの厚みが増します。伝える相手や状況によっても、より良い理由付けは変わることを学びました。伝える内容を精査する上で重要なポイントとして、以下を挙げます。 - 言語選択（言葉のチョイス） - 概念整理（抽象度を揃える） - 順序を考える（伝える順番） - 根拠づけ ピラミッドストラクチャーの効果 また、ピラミッドストラクチャーという方法を学び、それを使うことで自分の主張とその根拠が視覚的に明確になることも理解しました。伝える行為は、状況や思考を的確に言語化していく能力が必要で、これらのポイントを意識することで思考力も磨かれると感じました。 相手に伝える行為は、全ての業務に関わる部分です。普段の会話から、社内業務の引継ぎ、他部署とのやり取り、会議や説明会の進行、資料作成など、伝えるシーンは常に溢れています。今回学んだ知識を全ての場面で活かすのは難しいですが、業務内容や状況に応じて使用していきます。特に会議や説明会の進行、資料作成、他者からの問答の際にはピラミッドストラクチャーを使用して、内容や自分の考えを整理したうえで発信します。 緊急度が高い案件の対処 特定の業務に絞らず、重要度や緊急度の高い案件に関してピラミッドストラクチャーを積極的に活用します。使用回数が増えて上達する過程を経て、重要度や緊急度がそれほど高くない案件にも活用できるように挑戦します。特に緊急度が高い案件では時間的猶予が少なく、心理的にも焦ってしまい内容確認がおろそかになりやすいので、意識を高めて取り組みます。