(129ページ目)

考え ✕ 本

に関する学び

---

文章の組み立てはどう？ ピラミッドストラクチャーを意識して話を組み立てたり資料を作成したりしているつもりでしたが、日常のメールでは相手への配慮が欠けた文章を書いていたと感じました。特に、「日本語を正しく使うこと」や「自身の文章を評価すること」を怠っていました。 伝わる文章はどう？ 上司や部下に対する説明や説得、PLやBSの評価作成、プロジェクトの起案、そして日々のメールでのコミュニケーションが必要です。文章にするのが苦手だとわかったので、口頭や資料に頼らず、積極的に文章を書く習慣を身につけていきたいと考えています。 図解で伝えるのは？ ピラミッドストラクチャーで考えることを意識し、頭の中で組み立てるだけでなく、時には図解して頭の整理や説明に役立てたいと思います。また、メールの文面については「文章を評価する」ことを怠らず、相手の立場を考えてしっかりとチェックする習慣をつけたいと心がけています。

「MECE」で効率的に分析する方法とは？ 目で捉えた情報は、直感的に判断するのではなく、まず分解して考えることが重要です。分解の手法としては、まず全体を定義し、MECE（もれなくダブりなく）を意識して複数の切り口から分析を行います。MECEを適用することで、効率的な分析が可能となります。たとえ思い通りの結果が出なかった場合でも、それ自体が貴重な分析結果と捉えることが大切です。 WBS作成で精度を上げるには？ たとえば、プロジェクトのWBSを作成するときには、全体を定義した後、いくつかのカテゴリに分解して、重複がないかチェックすることで、効率化と精度向上を図ることができます。また、システムの基本設計を行う際には、MECEを応用し、実装時に条件の重複を減らすことでエンジニアの工数を削減します。さらに、製品のUI/UXを検討する際も、仮説や切り口を複数持って分析することで、ユーザの満足度を高めることができます。

相手視点はどうなる？ 無意識に自分の感情や考えで文章を作ってしまい、理由付けが自分本位になってしまうことに気づきました。しかし、相手目線に立って文章を構成することが非常に重要であると学びました。まずは文章の軸をしっかりと定め、その軸に基づいて内容を深堀することで、納得感と深みのある文章が作れると実感しています。 メール内容は伝わる？ また、お客様へ送るメールにおいては、長文になってしまい伝えたい内容が不明瞭になるケースがありました。そこで、相手の立場になって「何を伝えたいのか」とその理由を明確に整理し、筋が通った根拠とともに伝えることを意識したいと思います。 提案書の説得力は？ さらに、提案書作成の際にもピラミッドストラクチャーを活用しているため、この学びを復習と実践に活かして、今後も意識的に文章作成を改善していくつもりです。まずはQ2で記載したメール作成から、この考え方を実践していく予定です。

P/Lの構造を理解するには？ P/Lの構造を理解できたと思います。会社が利益を出すためには、ターゲットとする顧客や提供価値をブレずに一貫性を持って進めることが重要だということがよくわかりました。P/Lの数字の意味を考えながら、今後も学習を続けていきたいです。 利益の源泉をどう捉える？ 自社のP/Lを詳細に読み込み、利益の源泉や問題点を現時点よりさらに深く理解したいと思います。そして、その問題点に対して、売上増や変動費の削減といった具体的な解決策を考え、自分がまず何をすべきかをアイデアとして出したいです。 自部門の数字をどう理解する？ まず、自部門の数字の意味を深く理解する必要があります。そのため、腑に落ちるまでP/Lをしっかりと読み込み、分からないことがあれば書籍や人に聞くなどして解決します。本講義が終了するまでに、自部門の問題点に対する解決案を最低3つは会社に提案して実行したいと思っています。

比較で見える本質は？ 「データ分析の本質とは何か」という視点から、『比較』の重要性に気付かされました。目的達成のために、どの要素を比較すべきかを考える際、目先のことにとらわれず、本質に目を向ける必要があると実感しました。特にクイズ形式の事例は、この点を分かりやすく示してくれました。 経営とデータ活用は？ また、経営においては経験や勘も重要ですが、成長とリスクテイクのバランスをとるためにはデータ分析が欠かせないと感じています。現状、社内に十分なデータ活用の文化が根付いていないため、まずは意思決定に役立つデータを整備し、データ活用への理解を深める啓発活動に注力したいと思います。 信頼をどう築く？ さらに、データ分析結果の有効性を社内で理解してもらうためには、まず信頼できるデータを整えることが重要です。必要なデータの所在すら不明な状態からのスタートとなるため、地道な取り組みを積み重ねていく覚悟です。

部下への伝え方はどう？ 部下や後輩に組織の方針を伝える際は、伝える内容を大きく二つに分けています。一つは守ってほしい基本方針を明確に示えること、もう一つはプレッシャーをかけずに自ら答えを導けるような具体的な質問を投げかけることです。部下や後輩自身が答えを見つけ出すプロセスを促すため、なるべく自分で考えさせる工夫が大切だと考えています。 調査業務はどうする？ また、社内の調査業務においては、直属の部下や後輩だけでなく、他の部署や関連会社の年齢が離れた若いメンバーにも指示を行うことがあります。その際、細かい指示は避け、大枠の目的や流れを示すことを心掛けています。限られた時間の中で、資料や言葉にまとめた基本方針を分かりやすく伝え、誰にでも理解しやすいよう努めています。そして、上司や先輩という立場でありながらも、決して偉そうな態度をとらず、すべては部下や後輩の成長を支援するためであるという姿勢を貫いています。

何故問いが大切なの？ 起こった問題に直面した際、まずはどのような「問い」を立てるかが非常に重要です。この問いの立て方によって、今後の課題解決の方向性が大きく変わっていくと感じました。 どう柔軟に考える？ また、自分の過去の経験だけに頼って「考えたい」「考えやすい」方法で解決策を導き出すのではなく、より本質を見極めるための柔軟な視点が求められると思います。特に、お客さまからの悩みや課題に対しても、安易なアプローチに流れることなく、核心を捉える問いを設定することが大切です。 相談はどう進める？ さらに、問いを導き出した際には、その目的を明確にするために上司に相談し、意見を仰ぐことが効果的です。解決策を提示する場合は、相手の立場に立ち、数値や見やすい資料を使って分かりやすく説明することを意識しています。そして、相談の際には、設定した問いから離れた議論を避け、常に本質に焦点を合わせるよう努めています。

分析ってどう理解？ 分析とは、ものごとを分け、比べることだと改めて理解しました。具体的かつ明確に整理することで、より良い意思決定に役立てる手法であるという基本的な定義を再確認できたと感じています。分析を進める上では、目的設定と仮説設定がいかに重要かという点が特に印象に残りました。 目的設定は何が必要？ まずは、分析の目的を明確にして、どの意思決定に結びつけたいのかを整理することが大切だと考えています。その上で、目的に合わせた仮説を立て、膨大なデータの中から役立つ情報を見極める方法を実践していきたいと思います。 振り返りの進め方は？ また、自身の業務を振り返り、データを活用して改善したい点を整理し、どのようなデータを収集しているのかを把握することから取り組みたいと考えています。一つのテーマに絞り、目的設定、仮説設定、そして分析の順で自分なりに実践を進めることで、より良い結果を得たいと思います。

Aの有無はどう影響？ 分析の本質は、効果があるかどうかを明確にするために、Aがある場合とない場合を直接比較する点にあります。Aの有無で起こる違いを比較することにより、効果の有無がはっきりと浮かび上がります。 比較対象は何を基準に？ また、適切な比較対象の選定も重要です。分析したい要素以外の条件を揃える「Apple to Apple」の視点を持つと同時に、成功事例だけでなく失敗したケースも考慮する「生存バイアス」に注意する必要があります。成功だけに目を向けると、誤った判断につながる恐れがあるためです。 学びを活かすには？ 今回の学習で特に印象に残ったのは、「分析は比較なり」という考え方です。仕事の場面、たとえば事業計画で事業の方向性を示す根拠や理由を説明する際、比較の手法が非常に役立つと感じました。今後も自分の意見や判断の根拠を示す際に、この考え方を意識して分析に取り組んでいきたいと思います。

正しい問いは何？ 「問い」を誤ると、その後の努力が無駄になる可能性があると感じました。そこで、常に「問い」から始め、本当に正しい問いであるかを考えることの重要性を学びました。また、そのプロセスを共有し、確認し続けることも大切だと認識しています。 会議で問いは必要？ IT業界においても、そもそもの「問い」が誤っていたり、思い込みにより不要な作業が生じている場合があります。したがって、会議や議論の場で「問い」を意識的に共有することで、無駄を省き生産性を向上させられるのではないかと考えています。 導く問いは何？ 今後も常に「問い」から出発し、その正しさを確認・共有する姿勢を業務に取り入れていきたいと思います。また、クリティカルシンキング研修で学んだ自分の思考の偏りに気づいた経験を踏まえ、学んだ手法や考え方を活用しながら論理的な分析やグラフ作成など、客観的な判断ができるよう努めたいと考えています。

イシューの意味は？ 「イシュー」とは「いまここで答えを出すべき問い」であり、その重要性を実感しました。問いが誤ると論点がずれ、共通認識が形成されなくなるため、イシューを共有し本質を意識することが、具体的な課題解決や施策につながると考えています。 課題共有はどう進む？ IT業界においては、顧客からの課題相談が頻繁に寄せられるため、まずはイシューを明確にして共有することから取り組みたいと思います。共有をせずに解決策だけを模索すると、後に認識の齟齬が生じ、根本的な課題解決につながらない恐れがあります。 本質解決は可能か？ 業務では、本質的な課題が誤ると顧客が期待する解決が果たせず、結果として不適切なITシステムが提供される恐れがあります。そのため、単に解決策のみを提案するのではなく、イシューを踏まえた本質的な課題解決を追求することで、真に必要なITシステムの提供が可能になると考えています。

分解から何が見える？ データを分解して傾向がはっきり見えなくても、それを失敗と捉える必要はないと感じました。たとえば、「傾向が無いことが分かった」や「別の切り口があることが分かった」という結果も、データの捉え方の違いを示しており、有用な示唆と言えます。 正しい表記はどう守る？ また、「分かる」は必ず「分かる」と表記するようにし、データの分解を丁寧に行うことの大切さを改めて実感しました。実際にデータを細かく分ける際は、手を動かすこと、機械的にただ分けるだけでなく、複数の切り口で考えることが重要だと考えています。 売上の分解方法は？ さらに、メンバーの売上を整理し、今後の対応を検討する際には、合計の売上だけでなく、関連する項目ごとに分解することが必要です。その際、本当にこれだけで良いのか自問し、他のメンバーと相談することで、より具体的な分解と傾向の提示ができるよう努めたいと思いました。