(12ページ目)

計画 ✕ 方法

に関する学び

---

問題解決の秘訣は？ 問題解決の手順として、「What（問題は何か）」「Where（問題はどこにあるか）」「Why（問題はなぜ起きたか）」「How（問題はどう解決するか）」の４ステップを学びました。これまでなんとなく行っていたことやできていたことも、言語化することで抜け漏れなく整理でき、仮説や結論に対する自信が深まりました。 仮説思考はどうする？ また、仮説思考については、問題解決の仮説と結論の仮説があり、それぞれに過去・現在・未来の視点が存在するという考え方を知り、とてもすっきりしました。これまで様々な場面で仮説を立ててきましたが、今回の整理方法を取り入れることで、何を考えればよいかがすぐに浮かぶようになりました。 計画立案を学ぶ？ 事業計画の立案のプロセスにおいては、これまでなんとなく進めてきた作業を、今回学んだ解決のステップとフレームワークを意識して取り組んでいきたいと思います。自分で考えるだけでなく、他者に説明する際にも納得してもらえるよう、言葉にして伝えられる方法として活用していきます。 課題整理は進んでる？ さらに、事業計画の立案にあたって複数の課題と対策が存在する中で、重要度の高い順に今回のステップやフレームワークを適用し、ゼロから考え直すことで、問題を正しく捉え、解決策が十分かどうかを抜け漏れなく検討していきたいと考えています。

目標設定はどう？ 「分析は比較なり」「何を明らかにしたいのか」という考えを軸に、データから得られる情報を見失わないため、まず明確な目標を設定しています。その目標に向かい、必要なデータやストーリーともいえる仮説を構築し、試行と検証を繰り返すことで、求める結果に近づけています。 データ表現はどう？ また、取り扱うデータの種類に応じた加工方法やグラフの見せ方が重要であると感じています。そのため、状況に合わせて最適な表現方法を選ぶことに努め、いかなる場合も「とりあえず」での加工を避け、ビジネスにおける分析では、データに入る前に「目的」や「仮説」がしっかり整っていることを確認しています。 ランニング費用はどう？ これまで部門費管理を想定していた中で、担当しているITツールのランニングコストについても、使用金額や実際の作業時間など、これまで取得してこなかった新たなデータ要素を活用していく計画です。これにより、必要なツールや今後の投資対象となるソフトウエアの分析に役立てようとしています。 データ収集の工夫はどう？ さらに、データが不足している点を解消するため、まずは必要なデータの収集に力を入れると同時に、作業の効率化や一部自動化の導入も視野に入れています。今回の講座を通じて、時間の有限性を改めて認識し、これからはより計画的に活動していく所存です。

ゴールはどう決める？ ゴール設定が重要だと改めて感じています。部下には「何がしたいんだ」「どうしたいんだ」と問いかけ、明確な目標の言語化を促す機会が多々あります。しかし、私自身も経験則でやっているため、実はちゃんとゴールを設定できていなかったことに気づきました。 部下の根回しはどう？ また、業務がスムーズに進むために取り組んでほしい「根回し」ができない部下がいるのは、単にコミュニケーション能力の不足だと思っていました。しかし、実際は戦略的な思考力が欠けていることが原因であると理解し、納得しました。 戦略立案はどうする？ さらに、私の上司は自組織の戦略立案を担っており、意見を求められることが多いです。私自身はまだそのポジションに就いて間もなく、現時点では一から戦略を策定する機会はありませんが、遠い将来、特定領域の戦略立案を任される可能性が高いと感じています。そのため、上司に指摘される前に自分なりの戦略を構想し、上司と意見をすり合わせながら準備を進めようと考えています。 具体策はどう進める？ 具体的には、上司が設定したゴールとその達成までの道筋を明確に言語化し、他の方法や計画と比較検討する予定です。２週間に一度の１on１のミーティングの際に、今回の講座で学んだ内容も踏まえた私の考えを説明し、フィードバックをいただこうと思います。

顧客価値の定義とは？ ビジネスにおいて顧客に対してどのような価値を提供するかを明確にするためには、対象となる顧客（ペルソナ）をしっかりと定義することが重要だと学びました。顧客ペルソナが不明確だと、ビジネスを構築するのに必要な要素や資金の計画が立てられません。また、ビジネスの成果は損益計算書（P/L）で大まかに計算できますが、利益が出ていない場合の修正プランも検討する必要があります。この際、ビジネスが提供する基本的な価値は不変とすべきで、そこがぶれると「なぜこのビジネスを始めたのか？」という根本的な問題に直面する恐れがあります。そのため、修正プランについても価値への影響を考慮しながら検討することが不可欠です。 自社サービスの価値を再確認するには？ 現在の業務においても、自社のサービスや自分の組織・チームがどのような価値を提供しているのかを再確認します。その価値が実際に提供できているかどうかを測定する基準としてKPI（重要業績評価指標）が定義されているので、その関係を正しく理解することが必要です。 まずは社内情報を含めて、自社製品が提供する価値や関連サービスの価値の認識が、自分の理解と合致しているかを確認します。もし差異がある場合は、その部分を修正します。また、KPIについてもその設定背景を正しく理解し、同様に確認を進めていきます。

データ分析の意義とは？ データ分析をビジネスに活用することの本質を理解し、考え方や手法を再設計して、自分のものにしたいと感じました。データ分析で課題を解決するとは、「勘と経験に頼る意思決定の方法を、データ分析を用いた合理的な意思決定へと改めること」を指しています。そのために必要なことを次のように整理しました。 シナリオ設計のコツは？ まず、ビジネスに貢献するシナリオを描くことが重要です。そして、データを基にした意思決定プロセスを設計し、解消したい問題と解決する課題を言語化します。さらには、意思決定のプロセスを形式知として明文化することが必要です。 問題点は何か？ 具体的な問題としては目標未達があり、その課題として購入増加、キャンセル回避、Webサイト離脱の回避、および集客増加といった点が挙げられます。これらの課題を「意思決定プロセス」に深く掘り下げていくことが今後の大きな課題と考えています。 今後の展望は？ 今後の6週間では、問題と課題のさらなる言語化を進めていきたいと思っています。また、意思決定プロセスの6種類のうち、特にマーケティング型の「仮説試行型」と、経営者の思考バイアスを低減させるための経営者判断型について、さらに学びたいと考えています。そして、意思決定プロセスの形式知化を設計していく計画です。

全体像はどう見る？ 視野を広げて全体を俯瞰し、物事の本質やメカニズムを捉えることが重要です。このプロセスでは、現在の状況を正確に把握し、ゴールに向けての差別化と選択を慎重に検討しながら道筋を描いていきます。特に現在地の設定が重要で、これが不正確だと計画がうまくいかず、成果に繋がりません。したがって、一つ一つをしっかりと考えることが必要です。 学びはどんな工夫？ 学習を進める際には学習のピラミッドが示すように、他者に教えたり、実践したり、グループで議論することが定着率を高める秘訣です。このような学びの方法を意識することが大切です。 フレームはどう使う？ また、さまざまなフレームワークやアウトプットを業務で活用していくことを考えています。ただし、フレームワークには適切な使用場所や方法がありますので、それをしっかりと選択することが求められます。この考えを実践し、他者に教えることを意識して業務に取り入れていきたいと思います。 資料作成でどう活かす？ 具体的には、資料作成の場面での活用を試みたいです。例えば、新しい部署の提案や営業先の提案資料作成の機会を活かし、フレームワークの一覧をシーンごとに検討して使用することを考えています。今後も一つでも使用することを意識し、その継続を通じて全体的な活用を目指します。

数字をどう分解する？ 数字はグラフ化することで、視覚的かつ直感的に捉えやすくなり、説得力が増します。そのため、数字から情報を得る際は、ひと手間加えて分解することが重要です。ただし、単に区切るのではなく、仮定を立てた上でMICEを意識した切り口で分解する必要があります。分析を進めて結論にたどり着く過程では、短絡的な判断を避け、「本当にそうか？」と立ち止まって丁寧に確認する姿勢が求められます。 システムプロジェクトで何が大事？ システムの導入や改修、さらには現行システムの廃止などのプロジェクトを進める際には、現状の課題と期待される改善点を明確に提示するために、数字を用いたデータ分析が役立ちます。システム関連のプロジェクトは多額の費用が動くため、慎重な判断が必要です。そのため、さまざまな切り口からデータを分解し、要件と費用の比較検討に活かすことが大切です。また、社員向け研修の終了後には、受講者アンケートの結果を分析し、そのフィードバックを次の計画に反映させる方法も有効です。 苦手意識はどう克服？ 一方で、数字に対して苦手意識を持つ人もいます。私自身、業務で直接データを扱う機会はあまりありませんが、定期的に報告される各種レポートを基に、MICEを意識した分解の手法やデータの取り扱いに徐々に慣れていきたいと考えています。

正しい文章の秘訣は？ 文章作成においては、正しい日本語の使用が重要です。省略されがちな主語も明示することで、読み手にとって理解しやすい文章となります。また、一文は60字以内にまとめることで、読み手の負担を減らす工夫が必要だと感じました。さらに、主張に対する理由付けと根拠を視覚化することで、自身や他者の理解促進につながると学びました。 相手に伝える方法は？ 業務面では、まず他部署間のコミュニケーションにおいて、メールやプレゼンテーションなどで伝わりやすい文章を書く際にこのスキルが役立っています。次に、意思決定の場面では、方針を示す理由とその根拠を視覚化することで、チーム内外の理解度が向上し、説得力のある実行が可能になりました。さらに、トラブルシューティングにおいても、論理的な対処法を用いることで、上司への報告がスムーズに進み、理解を得やすくなります。 実践計画はどうする？ 今後の行動計画としては、まず実践段階で、上記の3点において積極的に取り組んでいきます。特に、これまで細かく実行できなかった視覚化手法の活用について、ピラミッドツリーの作成を含めて徹底して進めます。また、業務外でもこのスキルは有用であることから、日常の買い物やあらゆる意思決定の際に意識して活用し、自然に身につけられるよう習慣化を目指します。

戦略の本当の意味は？ 「戦略」という言葉について考えを深める中で、自分がそれを曖昧に捉えていたことに気づきました。難しく考えすぎると頭に入りにくいので、戦略とは「目的・目標をラクに達成するためのもの」や「やること・やらないことを選ぶこと」と解釈しました。この考えに基づくと、目的・目標の設定が今まで以上に重要であることがわかりました。 IT部門の悩みは？ 当社のIT部門も他社と同様に、計画済みの重要テーマに加えて経営や事業からの緊急案件が絶えず降りかかり、質・量の両面でメンバーへの負担が大きくなっています。そこで、社会や当社事業の状況を前提条件として受け入れつつ、メンバーが心身ともに健康で持続的に働ける組織を作るための運営戦略を確立したいと考えています。 研修後の見直しは？ 研修を終えた後には、まず以下のことに取り組みたいと思います： - 当社のIT部門の当面の役割・目的・目標を再評価し、明文化する。 - ミッションを効率的に達成する方法や、やらなくても良いことを構造的に考え、書き出す。 毎日の行動の意義は？ さらに、日々の行動としては次のことを徹底していきたいです： - 「やらない」という選択肢を常に意識する。 - これまで以上に目的・目標の設定を重要視する。

問題解決はどう進む？ 問題解決の4ステップとして、まず「what」（問題の明確化）、次に「where」（問題個所の特定）、その後「why」（原因の分析）、そして「how」（解決策の立案）という流れで整理する方法が紹介されています。各ステップが順序立てて説明されているため、全体像を把握しやすく、実際の問題へのアプローチがより明確になります。 仮説検証はどうする？ 仮説を立てる際には、複数の仮説を同時に検討し、それぞれに網羅性を持たせることがポイントとして挙げられています。また、仮説を検証するために、どの比較指標を選ぶのかを意識してデータの評価を行う大切さも感じました。 データ収集はどう考える？ データを収集する際の注意点として、まず「誰に聞くか」と「どのように聞くか」を慎重に考え、比較可能なデータの収集を怠らないことが重要です。さらに、反論を排除するためにも、対立意見をも十分に考慮した情報収集が求められています。 分析計画はなぜ大切？ 最後に、分析に取りかかる前に、設定した仮説を反映した分析計画表を作成する意義が強調されています。特に、経験の浅いメンバーと共に仮説の設定プロセスや必要なデータ収集、効果的な分析方法について議論することで、より深く問題解決に臨む体制を整えることが可能になります。

どの分析方法が有効？ 問題を特定する際のアプローチについて、分類や分解の手法、考え方の基本を身につけることで、さまざまな課題に対してゼロから悩むことなく、正しい分析を進められると実感しました。学習の中ではプロセスの分解に重点を置いていましたが、他の方法についても幅広く覚えておきたいと考えています。 提案の見直しは必要？ 実業務においては、顧客への提案で解決策ありきで進めてしまうケースがあり、都合の良い分析になってしまうことがあります。こうした提案は初めは良い印象を与えるかもしれませんが、本質的な課題解決にはつながらず、長期的には評価を下げるリスクがあるため、業務の進め方を見直す必要があると感じました。まずは、これまで学んだ分析のステップに基づき、客観的かつ正確な分析を実行した上で、最適な解決策を提案することが重要だと思います。 行動計画はどう決める？ 具体的な行動としては、実業務で特定のサービスに依存せず、客観的で正確なデータ分析を徹底し、複数の選択肢を比較検討することが求められます。そして、適切な判断基準を設定して最適な解決策を提案することを意識します。加えて、提案後の振り返りを行い、実施した解決策の効果をデータで検証する仕組みを整えることで、継続的に提案の機会を創出できると考えています。

問いをどう理解する？ 「問いを立てる」という言葉について、普段の言い回しとは異なり、初めはピンと来なかったものの、ライブ授業の具体例を通じて理解が深まりました。YESかNOで答えられる問いを設定することで、その答えに対する論拠や分析が求められ、論理的な説明が自然と身につくと実感しています。これまでの日々の業務にも通じる部分があり、改めてその意義を認識することができました。 フレームワークの再確認は？ また、これまでシステム開発の現場で漠然と使っていた思考のフレームワークが、今回の学習を通じて再確認できた点も大きな収穫です。部署内で複数のシステム開発案件のレビューを行った際に、報告内容が論理的でない場面に直面することがあり、状況を整理するためにこのフレームワークを意識的に活用できそうだと感じました。さらに、事業計画の立案や部下のサポートにも、今までの経験にとらわれない新たな視点を加える上で大いに役立ちそうです。 イシューリストをどう見る？ ライブ講義で紹介されたイシューリストの作成方法も非常に印象的でした。日常業務では緊急度の高いものが優先され、本来注目すべき課題が見落とされがちですが、イシューリストを作成し定期的に見直すことで、重要な問題点を把握し、対処策を検討する体制を整えられると感じました。