(19ページ目)

職種が「技術職（IT・通信）」

の受講生の学び

---

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

戦略的な問いは？ 講義中、「戦略的な人とはどのような人物か」「戦略的とは何か」という問いに触れ、誰もが大小さまざまな戦略的行動を取っていると実感しました。しかし、自分自身が十分に戦略的に動けていないと感じる背景について考えた結果、主に二点あると気付きました。 戦略が足りない理由は？ まず、不確定な事柄を明確にするための思考が十分に身についておらず、「自分には難しい」と考えたり、俯瞰的に全体を捉える時間が足りなかったりすることが挙げられます。次に、独自性を意識して行動するという観点が不足していると感じました。これらの点を研修期間中に克服し、意識して身につけていきたいと思います。 活かし方を考える？ この学びは、今後以下の二つの場面で活かしたいと考えています。 数値目標はどうする？ 一つ目は、組織の数値目標や状態目標達成に向けたアクションプラン作成です。目標は設定しているものの、さまざまな角度からのアプローチがある一方で、具体的な行動計画に落とし込めていません。直近の経験と直感に頼ったアクション決定の癖を是正し、より精緻なプランを構築していきたいです。 提案はどのように？ 二つ目は、顧客への案件提案の際です。自社ならではの独自性を真剣に追求し、提案内容に反映させることが今後の課題です。

比較ってどう見る？ 分析とは比較することであり、これまであまり意識してこなかった点でしたが、意識することで適切な図表や色の検討が可能になります。根底にあるのは目的であり、目的を意識することで、比較して何を伝えたいのかが明確になります。 自分化の意味は？ 学びのプロセスにおいて、「言語化」「教訓化」「自分化」は非常に重要な考え方です。特に、教訓化と自分化が自分自身の成長に大きく寄与すると実感しています。 施策にどう活かす？ 業務を分析し、施策を練る際には、根拠となる情報を集めて問題点を特定することが有効です。また、「言語化」と「教訓化」を意識することで、会議などで他人の進捗状況を聞いた際に、自分の考えの幅や経験値を広げる一助となっています。 仮説はどう考える？ 分析に取り組む際は、目的を常に意識することが大切です。まずは「現状を可視化する」ために図表化を実施し、その結果を踏まえて仮説を立案します。そこから、より限定的な部分の分析を進めることで、精度の高い課題の解決へと結び付けています。 会議はどう捉える？ 内部の会議においては、ただ受け身で情報を聞くのではなく、他人の発言をそのまま鵜呑みにせず、原理原則を抽出して自分自身の状況にどう反映できるかを検討することが重要であると感じました。

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

対概念で何が変わる？ 「手順を踏んで書く」というポイントで、対になる概念を下層に進める方法について学びました。これまでは、主題に対して思いつくまま事象を書き連ねたり、相手に刺さりそうな内容を並べたりしていました。しかし、対になる概念を並べることにより、より網羅的に整理することができると感じました。また、具体性を持たせるため、さらに一層具体的に記述するなど、どの程度具体に落とし込めば分かりやすくなるのか、ロジックツリーの構築で多くを学びました。 連絡時は何に注意？ 社外の人と連絡を取る際、基本的な要素として、主語が抜けていないか、主語と述語が対応しているかを確認することが重要です。これは、相手が話すことを理解する際にも、頭の中でピラミッドストラクチャーを描くことで役立ちます。理解が追いつかない場合には、その場でメモを取ることを心がけています。 AIでどう確認する？ また、手元の文章を他人に見せる前に、生成AIを利用して確認するようにしています。AIが提示する誤りについても解説を求めることで、自分の書いた文章の改善につなげます。一通りの話を聞いた後には、頭の中で描いたピラミッドを基に「この理解で正しいか？」と確認を入れるようにしています。これにより、意思疎通の精度が上がることを実感しています。

分かりやすい伝達方法とは？ 物事は「分けて」考えることが重要です。思考すること、文章を書くこと、相手に伝える時の言語化、これら全てに手間をかけることが求められます。自分の思考の癖に気付き、常に自分自身に問いかけ、問いに対して懐疑的になることも忘れてはいけません。そして、伝える「相手」が存在することを意識する必要があります。学びを仲間にアウトプットすることも大切です。 認識齟齬を防ぐには？ プロジェクトマネジメントにおいて、ステークホルダーに言葉を伝える際、相手の理解度は十人十色です。同じKPIを掲げていても、実際には人によって目的が異なることがよくあります。ミスの要因の一つは認識齟齬であり、全員が同じ思考回路を持っているわけではありません。だからこそ、リスク対策をしっかりと行いたいです。 会議の効果を最大化するには？ 会議の目的を明確にし、参加者全員が同じ認識を持つプロセスを忘れないことが重要です。また、認識齟齬を防ぐため、資料の準備には力を入れ、図解を用いることも大切です。伝え方が杜撰であれば相手の理解度は下がるため、何事にもプロセスに手間をかける必要があります。また、プロジェクトのリスク分析を行う際は、相手のポジションや役割に応じて切り口を変え、複数のケースを想定しておくことが望まれます。

思考のクセ気付いてる？ 人にはそれぞれ独自の「思考のクセ」があると言われます。私自身も、会社でその点を指摘されたことがあり、非常に印象に残っています。この経験を通じて、誰しもが持つ思考のクセを意識しながら、他者に分かりやすく伝える必要があると改めて感じました。特に考え続けることの重要性が指摘され、私は早く仕事を進めることを優先するあまり、考えることを疎かにしていたのではないかと反省しました。 企画説明どう進める？ 私の役割は、企画を検討し、上司に説明して納得を得た上で承認を得るということです。その際、自分の思考のクセに基づいたアイデアだけでなく、他の視点も包含して練り上げた結果を論理的に説明することで、企画から承認までのプロセスを迅速化できると信じています。 企画の目的は明確？ まず、進める企画の目的を徹底的に考え、明確化します。そして、すぐにアイデアを深掘りしてしまう自分の癖を意識します。その後、MECE（Mutually Exclusive, Collectively Exhaustive）などのフレームワークを活用し、問題の所在や可能な対策を短時間で探る作業を繰り返します。このようにして企画の内容や資料を固め、論理的に説明して納得を得て承認されるというプロセスを実行します。

比較と目的はどう考える？ 分析において、「比較」と「目的への立ち返り」の大切さを改めて感じました。何かしらの数値をグラフ化して報告するだけでは、かえって分析した気分になってしまい、実際は単なる数字の結果報告に過ぎなかったと認識しています。今後は、目の前の数字だけではなく、適切な比較対象を設定し、分析結果としてしっかり報告できるよう努めたいと考えています。 上司の反応はなぜ？ 直近の業務では、状況報告を上司に行った際、好意的な反応を得られず、簡単に取得できる情報だけに依存し、見栄えの良いグラフや表を作成するだけの報告になっていたことを痛感しました。単に数値を並べるだけでなく、それぞれの情報をきちんと比較し、その内容から次の対応や施策を検討できるような報告に改善する必要性を感じています。 次の一手はどうする？ そのため、今後の取り組みとして以下の点を意識していきます。 まず、分析の目的を再度明確にすること。 次に、比較する項目や内容について、上司の意見や生成AIのサポートを活用しながら見直しを行うこと。 さらに、定量的な分析だけでなく、定性的な分析も取り入れられるよう検討を進めること。 そして、最終的には目的に沿った次の対応策が検討できるような報告をまとめることを目標とします。

表現方法の重要性に気付く スライドや資料を作成する際、これまではコンテンツ（メッセージ）の内容に意識を集中していました。しかし、メッセージの表現方法やグラフなど補助情報の見せ方には注意を払っていませんでした。今回の講義で紹介された修正前後の例を通じて、メッセージの表現方法やちょっとしたイラストの追加が、自分の言いたいことを論理的にも視覚的にも分かりやすくする効果があると理解できました。これが最も大きな学びとなりました。 文書作成にも応用可能か？ 現在の所属部署では、スライドを作る文化がなく、主にワードやExcelで文書を作成しています。しかし、メッセージの表現方法や文書に添えるグラフなどの補足情報の重要性は同じです。このため、文書作成においても、今回の講義で学んだことを応用していきたいと考えています。 報告資料作成での新たな工夫 特に、プロジェクトの立ち上げ時や各工程終了時に必要となる報告資料作成において、今回学んだスキルを活かしたいです。振り返ってみると、これまでの報告では言いたいことをダラダラと書いてしまい、その結果、一度の報告で済むはずの内容も質問によって再確認を求められることが多々ありました。今後は、文章や図を使って言いたいことをシャープに伝えるよう工夫していきたいと思います。

ブレインで発想はどう？ 私は、ブレインストーミングを主にアイデア出しの手法として活用しています。たとえば、顧客課題の把握や、販売戦略の検討など、さまざまなテーマに対して意見を出しています。リモートでのミーティングが中心なため、付箋よりもエクセルやテキストを用いて情報をまとめることが多いです。また、SCAMPERについてはこれまで意識して取り組んでこなかったものの、今後は意見を出す一手法として実践してみたいと考えています。 少人数で意見はどう出る？ ブレインストーミングでは「否定しない」や「何でも言っていい」という基本ルールをみんなが理解して取り組んでいるものの、参加人数が多いと、どうしてもある一定レベル以上の意見でなければ雰囲気が微妙になってしまうことがあります。さまざまな意見を出し合うことは大切ですが、私は3～4人といった少人数で行うほうが、気軽に意見が言えてまとめやすいと感じています。 アイデア整理の秘訣は？ まずは、アイデアをたくさん出すことが重要です。その際、ひとつのアイデアに変更を加えたり、具体的なペルソナやシチュエーションを想定して出してみると効果的です。そして、出されたアイデアを最終的に整理し、言語化して説明できる状態にまとめることが大切だと考えています。

顧客定義はどうする？ 差別化や集中などいろいろな施策がある中で、最も重要なのは「顧客」を誰と定義するか、そしてその定義を厳密に行うことだと理解しました。顧客像を明確にすることで、施策の効果が格段に向上すると思います。 環境と戦略はどう？ 差別化施策を検討する際には、VRIOをはじめとする各種フレームワークを活用し、自社および周囲の環境を正確に分析することが必要です。そのうえで、リスクを踏まえながらも、複数の戦略を同時に実行できる組織の柔軟さが大切であると感じました。 顧客定義の共有は？ 自分の所属するサポートチームにおいても、まず「顧客」が誰であるかを再確認し、その定義から導かれる優位性や差別化要因を自分なりに分析し、同僚と共有するよう努めています。現在のチーム体制も、顧客の定義に基づいて構築されているため、外部環境の変化や何がトリガーになるかについても常に注意を払っています。 多様な意見はどう？ また、限られた情報だけに頼らず、少なくとも複数の視点や意見を取り入れることが重要だと実感しています。否定的な意見を受け入れ、フィードバックを正しく取り入れるために、自分自身の感情コントロールを心がけることが、結果としてより良い判断につながると感じました。

なぜ分解して考える？ プロセスを分解して問題の本質に迫る手法について、非常に分かりやすい事例から学ぶことができました。特に、採用プロセスの一部である中途採用面談や、顧客への提案における在庫差異の問題解決に、このアプローチを活用できると感じています。また、ABテストにおいては、条件をできる限り同一とし、検証範囲を絞るための仮説設定が重要である点も再認識しました。 採用面談、何が問題？ まず、中途採用面談に関しては、自身が関与する採用活動において、プロセスのどの部分で問題が発生しているのかを明確にするため、面談調整に要する日数と採用結果の情報を人事部から収集することを検討しています。この情報をもとに、面談調整に時間がかかる原因を特定し、改善策を提言することで、採用率の向上を図ることができると考えています。 在庫の差異、どう解決？ 次に、顧客への提案、特にシステム間の在庫差異に関する課題解決では、既に現状の業務プロセス分析は実施していますが、課題が発生しているプロセスの粒度が細かすぎるため、より単純化した形で説明する必要性を感じました。問題となりうる箇所を明示した上で、システム改善または運用プロセスの変更のいずれかを提案し、顧客にとって最適な解決策を提示していく考えです。