(5ページ目)

分析 ✕ システム

に関する学び

---

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

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

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

業績分析の意義は？ オリエンタルランドに関する演習を通じて、エンターテインメント業界においてもアカウンティングの視点が不可欠であるという大きな気づきを得ました。これまで、テーマパークのような非日常体験を提供する業態は、感性やブランド力が中心であり、数字とはあまり結びつかないと考えていました。しかし、今回の分析で、顧客の特性から提供価値、業務活動や経営資源、そして売上や原価、資産といった財務情報に至るまで、すべてが論理的に整理され戦略的に設計されていることを実感しました。 経営全体を見る理由は？ また、今回学んだアカウンティングの視点やフレームワークは、今後の業務でクライアントの課題を整理する場面で活かせると考えています。たとえば、新規システム導入の相談を受けた際には、単に技術的な要件や予算を確認するに留まらず、「そのシステムがどのような価値を提供するのか」「どの業務活動と関係しているのか」「導入によりどのコストが削減され、どの資産が活用されるのか」といった経営全体を俯瞰する視点で問いを立てることで、より本質的な提案が可能になると感じています。

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

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

分析の目的はどう設定する？ 数字整理の段階で、分析の目的や仮説を設定して作業を進めることの重要性を学びました。この方法により、さまざまな観点から結果を導き出せることがわかりました。また、分析前にMECEやロジックツリーを活用して要素を整理することで、抜け漏れのない分析が可能であることも学習しました。 多様な切り口で何を掘り下げる？ この手法は、社内システムに対するユーザー満足度調査の分析に役立つと感じています。以前は、部署毎や勤続年数などの一般的な数値のみでの分析にとどまっていましたが、より多様な切り口で分析を進めることで、真のニーズを掘り下げることができるのではないかと考えています。 ロジックツリーの作成はどうする？ まず、ロジックツリーを手書きで作成し、可視化します。そして、それを基にしてExcelのピボットテーブルを活用し、他にどのような切り口があるかを常に自問しながら分析を進めます。あわせて、MECEによるモレやダブりがないかにも注意を払っています。

なぜ系統分解する？ 問題解決にあたっては、主観的な判断を極力排除し、各要素を系統的に分解する手法が重要であると学びました。MECEの考え方を参考に、まずはトレーニングを重ねながら、必要な要素を網羅的に整理する力を身につけたいと考えています。 どの角度で検証する？ また、IT分野でのシステム設計や事後分析においては、目的や問題点を明確にし、多角的に分析する姿勢が求められると感じました。どの角度から、どのレベルまで検討するかを意識することで、より高い品質のアウトプットを実現できると実感しています。さらに、クリティカルシンキングの向上には継続的なトレーニングが不可欠であり、ビジネスシーンにおいても振り返りの時間を大切にすべきだと思いました。 自己評価はどう？ 今後は、本コースで学んだ思考方法を活かし、過去の問題分析を振り返る中で、自分のアプローチが主観的になっていないか、また適切なレベルまで検証できたかを再評価し、次回以降のタスクに役立てていきたいと考えています。

新たな視点の重要性は？ 一度一見納得のいく答えにたどり着いた後でも、その答えが本当に正しいのかを疑う視点を持つことが重要だと思います。ほかの視点から再度考えることで、これまで気づかなかった事実に気付く可能性が高まります。また、要素を分解する際には、MECEの考え方に基づいてデータを重複なく漏れなく整理することが大切だと感じました。 どうすればリソース確保できる？ また、サーバ保守業務に従事している私にとって、ユーザから届くリクエストの分析は日常的な作業です。一定時間ごとのリクエスト数を見ることで、日中と夜間で訪問者数の違いを把握でき、サーバの応答時間の計測を通じてシステムへの負荷状況を確認することが可能です。リクエストのトレンド分析により、将来的に必要となるサーバ台数の予測が行え、適切なリソース確保につながります。また、応答速度の追跡を通じて、サーバが限界を超えるリスクを事前に察知し、システムダウンを防止するための対応策を講じることができると感じました。

問題の特定方法には何がある？ 問題の特定方法について、さまざまな考え方があることを学びました。特に、5W1Hを駆使して繰り返し考察を行うことで、より意義のある分析にたどり着けることがわかりました。また、MECE（Mutually Exclusive, Collectively Exhaustive）を意識することで、分析の精度が高まると理解しました。 定量的でない問題にどう対応する？ この方法は、特に定量的でない問題やトラブルの対応に役立ちそうです。さまざまなシステムを活用しているため、どこに問題があるかを素早く把握するために、MECEやロジックツリーを活用して解決を図りたいと考えています。 ロジックツリーの活用方法を説明 具体的には、ロジックツリーをWordやExcelなどで作成し、問題を視覚的に整理することを目指しています。この方法により、直感的には気づかなかった問題や課題の本質を見つけやすくなると期待しています。

数値分解はどうする？ ITの現場では原因分析のシーンが何度もあり、今回の学習は具体的な分析手法を再確認する良い機会となりました。特に、数値をどの要素で分解するかが重要で、正確に分けないと誤解を招く恐れがあるという点は、日常的に直面している課題でした。そのため、今後は多角的な視点で分解することを意識したいと考えています。 印象改善はどう実現？ また、プレゼンテーションなど、相手に良い印象を与えたいシーンにおいても、事実と異ならない範囲で資料を工夫する手法として、この学びを活用できると感じました。 不具合原因の見直しは？ システム構築における不具合の数や原因分析の場面でも有用であるため、既存の分析フォーマットの中から今回の学びで得た要素を見直すことにします。さらに、部下と行う1on1でのヒアリングシーンにおいて、メンバーが抱える不安や不満などのメンタル的な問題に対しても、役立てられないか検討したいと思います。

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