(17ページ目)

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

の受講生の学び

---

広い視点を持つ重要性とは？ 目の前の意見や状況だけで判断するのではなく、広い視点から考えることの重要性がとても印象に残りました。また、多くの人の意見を聞くことの大切さも心に残ります。この点については、上司からも同様の指摘を受けています。いくら俯瞰的に考えようとしても個人には限界があるため、組織で働く以上、他の人の助力が必要だと痛感しています。 事業計画に役立つ視点は？ 現在進行中の事業計画や施策について今週一時判断が求められており、その過程で非常に役立ちました。特に「この施策自体が事業にどのような貢献ができるのか？」という問いを最初に考えることで、これまで気づかなかった新たな視点や気付きを得ることができました。他部門のメンバーの協力を得ることももちろん大事ですが、自部門内でも意見を集め、新しい観点を生み出すことができました。この取り組みがまだ不足していることを組織内で議論し、実際に内部でも定期的なディスカッションの場を設けることができました。 意見を整理するには？ 今後は他部門のメンバーの意見を積極的に取り入れることを予定しています。そして、ここまで集めた情報を整理する作業を来週実施します。その際には、3Cなどのフレームワークを活用し、本質を見失わないように常に「目標は何か」を意識しながら情報を整理していきます。

効果的な文章の組み立て方とは？ 「相手に伝わる文章を書くポイントを身につける」について、大きなポイントになる部分は以下の順序で理解しました。自身の解釈に基づいて再編していますので、他に気になる点があればご指摘ください。 1. 文章を書き始める前に全体像を想像する。 2. ピラミッドストラクチャー（メモ："主張⇒根拠"の論理の組み立て）を活用する。 3. 主語述語を意識する。 4. 長文になっていないか意識する。 5. 自分の文章を俯瞰し精読する。 コミュニケーションツールの使い分け方は？ 業務で利用しているコミュニケーションツールには、チャット、メール、Office製品、課題管理ツールなどがあります。 これらのツールは、以下のような場面で活用できます。 ●提案フェーズでの資料作成 主張したいことを一点に絞り、複数の概念を用意します。既存顧客の場合は、顧客カラーに応じた選択を行いますが、分からない場合は複数の選択肢をそのまま準備しておきます。ただし、根拠はすべて明確にしておくことが重要です。 ●エンジニアとのやり取り 主張に対しての根拠を複数用意し、文章の精度を高めます。しかし、コミュニケーションには必ずラリー（やりとり）が存在するため、一回で全てを伝えようとせず、逐次的なやり取りを心がけることも大切です。

定性分析の意義は何？ 定性分析という言葉は以前から耳にしていましたが、具体的な内容についてはあまり理解していなかったため、普段使っている手法ということもあり、大まかなイメージは持っていました。日常的に顧客と会話する中で、提供しているサービスに対する意見や不満を雑談の中からヒアリングし、複数の顧客の声を集めることで共通の改善ポイントを見つけ出してきました。フレームワーク化はしていなかったため、これを機に試してみることにしました。 顧客の反応はどう？ また、ある顧客で認識した課題を、別の顧客にも「こういった課題はありませんか」と確認することがあります。その結果、多くの方から「あ、そうだね」と言われ、潜在的な問題を掘り起こせたような気がする反面、半ば無理やりに認識させたのではないかと感じることもあり、共感フェーズの難しさを改めて実感しました。 対応策は進むか？ さらに、特定の条件下にある利用者の特定シチュエーションでの課題に焦点を当てる重要性は理解しているものの、実際にその課題に対して具体的な対応策を講じるまでには至っていません。対象となるケースが想定以上に少ないため、コストメリット的にも実施判断にまで至らないのが現状です。今後は、次のフェーズで小規模なテストなどを通じ、解決策を模索していければと考えています。

仮説と枠組みはどうなる？ 仮説の立て方や具体的なフレームワークについての説明があり、現在取り組んでいる業務とも密接に関係していたため、大変参考になった週でした。 知識はどう耕す？ 備忘の意味も含め、仮説構築のためのメモとして、まずは「知識を耕す」ことの重要性が挙げられます。なぜを繰り返し問うこと、別の観点や視点で事象を捉えること、時系列や将来予測を意識すること、そして類似や反対の事象をセットで考えることが効果的だと感じました。 創造的な仮説は？ また、ラフな仮説を立てる段階では、常識にとらわれず新しい情報と組み合わせることで、発想を絶やさず創造的な仮説を生み出す姿勢が大切であると理解しました。 仮説の検証はどう？ さらに、仮説の検証については、必要な検証の程度を見極め、情報収集と分析を通して仮説に具体性を加え、再構築していくプロセスが重要であると認識しました。 今後の見直しは？ 現在、事業計画の策定や顧客に対するプラン作成に活かすため、仮説構築を意識して取り組んでいます。しかし、現状では仮説の立て方が自己流であり、検証も十分ではないと感じています。今後は、前述した「知識を耕す」という視点を基に、数字的根拠をうまく活用した報告や、仮説の肉付け・再構築にも注力していく必要があると実感しています。

なぜ手法を再確認？ 今回の学習では、問題解決のステップ（What/Where/Why/How）に沿って、各段階でどのようなアクションを取るべきかを再確認することができました。普段の業務でも同様の手法を取り入れていますが、今回の具体例を通じて現状の見直しに役立つと感じました。 適切な分解は何故？ また、ロジックツリーに取り組む際、すべての要素を漏れなくダブりなく洗い出そうとするあまり、時間をかけすぎてしまう傾向があることを改めて実感しました。特に末端の階層にこだわりすぎず、適切なレベルで分解するというアドバイスは大きな気づきとなりました。 現業務の解析はどう？ 現在の業務では、顧客へのサービス提供に際してコスト試算や自部署の予算計画、実績の分析を行っています。例えば、コスト試算においては提供価格、原価、販管費といった大枠から、さらに細かい費目に分解して検証していますが、構成要素をツリー状に分解するという手法は初めての体験でした。今回の学びを現業務にも活かせると考えています。 次の改善策は何？ 今後は、自部署における予算計画、実績把握、コスト試算のプロセスに、ツリー状の分析手法を取り入れてみます。一度試してみて、試算の妥当性や課題の特定にどのような効果があるかを検証していきたいと思います。

学びの意義は？ WEEK1からの学びを通じて、自分にとって何が重要なのかを再確認できました。特に、思考の抽象度を操作することや、イシューの再検証に関しては、苦手としていた部分を具体的なアクションプランに落とし込むことができたのが良かったです。 リーダーで何する？ 現在、チームのリーダーを務めていることから、チームのメンバーや組織の課題に取り組む際にこの学びを活用したいと考えています。特に来年度のチーム戦略や目標を立てる際には、現状の組織課題をきちんとイシューとして認識し、その上で解決策を策定していくことが必要です。 抽象思考はどう？ 抽象度を上げる思考がしにくい点は、日常的な課題にも当てはまります。例えば、組織の課題に向き合う際には、周囲からのチームに対するイメージや現在の業務内容に引っ張られ、思考の抽象度が上がりにくいこともあります。これを改善するために、紙に書き出して思考の抽象度を上げる訓練をしてみようと思います。 イシュー評価はどう？ イシューの設定に関しては、実務において分かりやすいイシューが見つかると、それに集中して他の可能性を排除しがちです。これを改善するためには、思考のプロセスを意識し、発見したイシューが最適かどうかを何度か他の分解方法を試してみる習慣をつけたいと考えています。

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

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

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

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

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

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