(7ページ目)

システム

に関する学び

---

説明の根拠はどう確認する？ ピラミッドストラクチャーを用いることで、説明の際にその根拠に共通する要素を確認し、文章の構造を理解する学びを得ました。共通要素を言葉で表現するのは難しく、また、説明の正しさは相手によって変える必要があると感じました。例えば、勉強会を実施する際、上司を説得する場合は、勉強会によって社員の負荷が増えないことを強調することが重要です。一方で、同僚を説得する際には、スキルアップなどのメリットを提示することが効果的です。これは、相手の課題を解決する要素を説得に使用する例です。 会話でどう説明すべき？ 日々のミーティングでは、相手の前提を理解し、どのようなアプローチで説明すれば納得感を得られるかを考えながら会話を進めたいと思います。また、上司への提案時には、ピラミッドストラクチャーを使って根拠を明確に伝えることが重要です。 変革の価値は何？ 他部署への方針変更の説明においては、変更の理由をしっかり伝え、どのような価値が相手に提供されるか、またどのようなメリットがあるかを示すことが大切です。新たなシステム導入時には、必ずオペレーションの変更が伴うため、その際の相手へのメリットを具体的な根拠を示して理解してもらうことが必要です。

デザイン思考はどう変わる？ デザイン思考は、当初は外見や部分的な要素に焦点が当てられていましたが、徐々に全体設計へのアプローチへと発展してきました。お客様への共感を軸とすることで、顧客にとって本質的な課題解決を目指す姿勢は、単に技術的に高度であるだけではなく、実際に役立つ製品やサービスへと結実するために不可欠です。 技術進歩と課題は何？ また、AIの進化により、ITシステムの試作が容易になったため、全体プロセスの回しやすさは向上しています。しかしながら、細部の制御が難しい現状では、あと一歩の実現に大きな工数と時間が必要となるケースも見受けられます。加えて、顧客と製品やサービスの提供者はそれぞれ別の利害を持つため、どうしても緊張関係が生じるという課題があり、こうした点を含めた総合的な方法論の整備が望まれます。 試作と提案はどう進む？ 今後は、ChatGPTなどを活用して顧客の発言から課題やソリューションを分析し、その結果を基にReplitで試作案を作成、実際に顧客に提示するという流れが実現できるのではないかと考えています。授業を通して、こうしたプロンプトの設計など、具体的な手法を確立していくことが目標です。

分析はどのプロセスから始める？ ＜印象に残った内容＞ ・プロセスに分解し、各プロセス毎に数値を見る ・A/Bテストの前に目的と仮説を明確にする ・データ分析はまず身近な課題から着手する A/Bテストの代替案は？ ＜感想＞ A/Bテストはオンラインサービスとの相性が非常に良いが、対面サービスやコストの問題で簡単に実施できない場合の代替案が気になりました。 残業時間削減へのアプローチ ①社内で使用しているSFA（営業支援システム）の切り替えに伴い、入力画面のインターフェース検討においてFigma等のツールを使ってA/Bテストを実施し、手戻りが無いようにする。 ②今後の人員削減に伴い、業務の棚卸しを行う。 この切り替えは少し先になるため、思考訓練として自分の残業時間を減らすための施策を考えました。 まず、業務の洗い出しと各業務のプロセスの分析を行います。そして、以下の代案を検討します。 外注や自動化は可能？ ・外注の可能性を探る 　・無料の外注が可能か 　・有料の外注が利用できるか ・自動化を進める ・不要なプロセスを廃止する 以上のステップを踏み、効率的かつ効果的な業務運営を目指したいと考えています。

フレームワークはどう？ 3C、SWOT、VCフレームワークについて深く理解しました。これらのフレームワークはどの業界にも適用可能であり、分析に非常に役立ちます。しかし、実際にしっかりと分析を進めようとすると、情報が十分でない場合や分析力の不足が課題となることもあると感じました。 競合戦略は何？ そこで、競合分析に挑戦してみることにしました。具体的には、ウェブ上での調査やIR資料の確認、および転職者からのヒアリングを通して、競合他社が実現を目指していることや、そのための戦略を探りました。その中で学んだことは自社に取り入れ、どのような影響があるのかを理解することを心がけました。 自組織の分析は？ さらに、3C、SWOT、VCフレームワークを用いて自組織を一度分析してみることを考えました。外部環境の理解にはPEST分析を用い、得られた内容を3Cの外部環境部分や競合分析、SWOT分析の強みと弱みの項目に活用しました。SWOT分析では、PEST分析から得た機会と脅威に焦点を当て、VCフレームワークでは営業活動から最終顧客へのシステムリリースに至るまでのプロセスを機能分割し、その中での強みを詳細に分析することを目指しました。

今回の学習で、私は以下の2点を学びました。 具体内容の合意は？ まず1点目は、イシューの留意点についてです。合意形成の際には抽象的な表現ではなく、具体的な内容に落とし込むことの重要性を改めて認識しました。例えば、上司や関係者との目標設定の際に、単に「売上げUP」といった漠然とした表現ではなく、「○〇分野での機器販売について、売上げUP」のように具体的に提示することで、プロジェクトやサービス導入の計画・遂行における合意形成をより確実なものにできると感じました。これに基づき、今後は行動計画として、イシューを十分に具体化してからプラン策定に入るよう努めていきます。 スライドはどう伝える？ 2点目は、スライド作成時の効果的な方法についてです。プロジェクトやサービス導入の説明において、よりわかりやすい資料作りが求められる中、グラフの活用やアイコンの設置、タイトルの工夫、レイアウトの見直しなど、実践的なポイントを学びました。直近の部門内でのシステム改修に関する説明では、これらの学びを実際に取り入れ、より伝わりやすいスライド作成に取り組む計画です。今まで以上に分かりやすい資料となるか、レビューを通して改善していきたいと考えています。

ワークショップでの学びは？ 問題解決のステップについては以前聞いたことがありましたが、今回のワークショップではすぐに思いつかず、アイデアが発散してしまいました。学んだフレームワークを活用して思考する習慣をつけていきたいと思います。また、MECE（Mutually Exclusive, Collectively Exhaustive）を行う際、層別分解は比較的考えやすいものの、変数分解は思いつきにくく、これについても日々練習が必要です。 コミュニケーションで注意することは？ 打ち合わせでは、意見が対立したり、言いたいことがうまく伝わらず、お互いのイメージが合わないことがあります。このような場面では、MECEを用いてブレスト（ブレインストーミング）すると、目線を揃えやすくなります。したがって、コミュニケーションツールとしても積極的に活用していきたいです。 お客様との認識をどう一致させる？ お客様にシステム開発の見積を提示する際、その作業内容や作業量を説明する必要があります。単なる金額の羅列ではイメージしにくいため、プロセスを分解したり、変数分解して説明することで、お客様との認識を一致させたいと思います。

問いの立て方はどう？ 問題が発生した際、問いの立て方によって真に解決すべき課題が異なり、解決策の方向性が決まってくることがよく理解できました。イシューとは何か、またイシューを設定して考えるとはどういうことかを知っていないと、問題の本質にたどり着けないということも実感しました。 問いが変える提案は？ このアプローチは、私自身の業務における顧客の課題解決にも活用できると感じています。これまでユーザーの課題を聞き取りシステムを提案してきましたが、結局は活用されない機能が存在したこともありました。今後は、常に「問い」を立て、問題の本質を追求した上で提案していく必要があると考えています。 組織課題の見極めは？ また、社内では組織の抱える課題を正確に見極め、その解決策を事業計画に反映させたいと思っています。まずは、自身の業務において、ユーザーの課題に対してすぐに解答を提示するのではなく、問いを設定してその内容が本質的なものかどうかを繰り返し吟味しながら、適切な提案を行うことが重要です。そして、そのプロセスをチームで共有し、全員が同じ方向に向かって取り組めるようチームビルディングに努めていきたいです。

ビジネスモデルをどう理解する？ P/Lだけでは、その会社のやりたいことや強みは明確になりません。ビジネスモデルを理解し、意図を汲み取る必要があります。単純な数字の遊びではなく、想像力が非常に重要だと感じました。ただし、ビジネスを考える上での基礎はB/SやP/Lの知識であり、それを抜きにしてビジネスは成り立たないと理解しました。 事業ごとの強みとは？ まず、自社のB/SやP/Lを理解し、自社の強み、特に事業部別の強みや弱みを把握することが重要です。次に、人事的な側面から数字を理解し、事業部別の特性にあった施策を組み立てる必要があります。例えば、システムとアウトソーシングではビジネスモデルが異なり、同じ制度では限界があるため、事業会社設立も視野に入れて施策を検討するべきです。 予実管理の重要性とは？ また、毎月の予実を確認し、昨年度の実績から傾向を把握することも大切です。特に、原価（人件費）を理解し、売上総利益の何％が営業利益になるかを正確に知る必要があります。この流れで、人件費を増やせるかを検討し、難しい場合は全社としての施策で従業員に貢献できないかを考えましょう。

制約が生む思考の深さとは？ 私は、思考において制約があるほうが解答を導きやすく、制約がない場合の方がかえって困難な思考になりがちであることに気づきました。人間は、簡単に考えたことよりも、少し深く考え、もうワンステップ努力することで、より良い答えを得られると感じました。 顧客の本質をどう捉える？ IT業界で営業職をしている私は、顧客の問題や課題を聞き出し、システム化のニーズや条件を理解した上で、顧客要件に合ったシステムを提案する機会が多くあります。この際に、顧客が何を求めているのかを正確に聞き取り、それに対する提案を行う場面で今回学んだ考え方を活用できればと思っています。また、社内での受注審議における説明など、多くの人に物事を説明する場面での事前準備にも応用できそうです。 効果的な提案の準備法 具体的には、顧客要件をなるべくシンプルに書き出し、提案ポイントを整理してそれがマッチしているのかを検討します。さらに、自作の説明資料に対して他者から質問を想定し（自分ならどこを質問するか）、その想定問答を資料のブラッシュアップ時に活用していきたいと思います。

データ分析で重要なのは？ 現在、実務の初歩的なデータ分析に触れる機会はあるものの、改めて分析手法を体系的に理解することができました。特に、データ分析においては課題設定と仮説が極めて重要です。ただ単に分析手法の知識を持つだけでなく、領域知識も必要となるため、日常業務では特に業務理解を深めることを意識していきたいと思います。 業務改革で何が求められる？ 業務改革の根拠としてデータ分析を利用することが多いですが、第1週の学習を通じて、私が現在取り組んでいるのは、分析というよりもむしろ集計や可視化に近いことを理解しました。したがって、まず課題の設定や仮説に基づいてどのようなデータで比較するかを慎重に検討し、情報を収集することから始めるべきだと考えています。 領域知識を高めるには？ また、課題設定や仮説を立てるための領域知識が不足しています。そこで、領域知識の向上を目指しながらも、分析を進めるためには周囲の協力を仰ぐことも重要だと感じています。データが複数のシステムにまたがって保存されているため、一度どのようなデータが存在するのかを整理することが重要です。

問題点は何でしょう？ 何が問題かを明確にし、結論のイメージを持ちながら取り組むことが大切だと感じました。何を解決したいのかを考えることで、目的に立ち返ることができるため、数字をどのようなグラフで表現するか悩む場面でも、考え方の整理が進みました。データ分析においては、仮説思考が基本であるとも実感しています。 プロジェクトの目的は？ 業務改善プロジェクトに取り組む際には、まず目的の設定が不可欠です。進める中で何を解決したいのか、そして最終的な結論のイメージを持ちながら作業を進めたいと考えています。現状では、システムや運用の活用率といったデータが中心ですが、活用と非活用という単純な区分のみで目的に沿った分析が可能かどうか、再度検討する必要があるように思います。 誰にでも分かる目的は？ 目的設定については、誰にでもすぐにイメージできるような分かりやすいものにすることが重要です。現在取り扱っているデータから新たな気づきが得られないか、また、ほかのデータを追加することで見えてくる可能性があるかどうかにも注目していきたいと思います。

データ分析で新視点を得るには？ データ分析とは、比較を行うことで新たな視点やアイデアを引き出すことが可能であると学びました。同じ基準や条件を用いることで効果的に分析ができ、新しい発見に繋がることが特に印象的です。 効率化への第一歩は？ これまでの仕事では、何となくデータを用いながらプロジェクトの進捗を管理していましたが、新しい職場では積極的にデータの可視化を取り入れ、業務の効率化を図りたいと考えています。以前は過去のデータより直近のプロジェクトの状況にのみ焦点を当てていました。 なぜデータ可視化が重要？ 日常業務の中で、業務上必要がない場面でもデータを可視化することは重要だと考えていましたが、既存のシステムやBIツールに頼りがちでした。しかし、自ら業務プロセスをデータ化することが、業務のパフォーマンス向上に繋がるのではないかと考えています。 ダッシュボード作成スキルをどう磨く？ 現在は過去のプロジェクトマネジメントの経験を活かし、会社の既存のダッシュボードを一から作成するスキルを身につけるために勉強を続けています。