(5ページ目)

データ ✕ システム

に関する学び

---

弾痕が少ない理由は？ 今回の研修で最も印象に残ったのは、戦闘機の補強に関する話でした。弾痕が多く残っている部分ではなく、むしろ弾痕が少ない部分を補強すべきという考え方に驚かされました。この事例は「生存者バイアス」と呼ばれ、帰還できなかった機体の状況を無視すると正しい判断ができないという重要な教訓を示していました。 比較対象の選び方は？ また、分析の基本は「比較」というシンプルな考え方に基づいているものの、適切な比較対象を選ぶことや、見えにくいデータに注目することの難しさと大切さを改めて実感しました。 データ比較で改善策は？ 私が担当しているシステム開発プロジェクトにおいては、テスト工程でのバグ検出率向上が課題です。そこで、研修で学んだ比較の考え方を活用し、成功事例と失敗事例のデータ、たとえばテスト時間やレビュー時間を比較することで、より効果的な改善策を見出していきたいと考えています。 比較難点をどう乗り越える？ ただし、比較対象の条件が必ずしも揃っていないケースや、対照となる対象そのものが存在しない場合など、現実のデータ分析では困難な点もあります。こうした状況では、新しいデータの収集や、比較方法の検討をさらに深掘りしていく必要があると感じました。

生成AIだけで大丈夫？ 現時点での生成AIは、予測に基づいた文章生成しかできないため、期待した成果を得るためには必ず人間の介入が必要です。具体的には、適切な情報提供と最終確認の２点に留意することが求められます。生成AIの出力をそのまま信頼して他人に伝えると、自身の能力すら疑われる可能性があるため、慎重な対応が不可欠です。 苦手部分はどう克服？ また、生成AIが苦手な部分を補うためには、編集者自身のスキル向上が必要です。AIが生成した文章の誤りや改善点を言語化できる能力がないと、成果の質が向上せず、活用の幅も狭まってしまいます。そのため、基本的なスキルの向上にも力を入れることが重要です。 企画書の信頼は確か？ さらに、イベント企画においては、事前にシステムユーザーを対象としたアンケートを実施し、そのフィードバックをもとに企画書を作成する手法が有効です。アンケート作成の際には、誰に向けたものか、目的や求めるニュアンスなどの情報をプロンプトに盛り込み、質の高いアンケート骨子を作成することが求められます。そして、どの情報を基に項目を作成したのか、参考とした出典のURLや抜粋文言を示すことで、データの信頼性を確認することも大切です。

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

何を伝えるべき？ 文章を書く際には、まず「何を伝えたいか」という目的を明確にし、読み手が知りたい情報に焦点を当てることが大切だと学びました。読んでもらうためには、最初につかみを工夫し、目的を簡潔に示すとともに、段落ごとに整理して読みやすい文章構造を作ることが効果的です。 図表の役割は何？ また、図表を使用する場合は、内容に適したものを選び、文章とのつながりをわかりやすく示すことで、より伝わりやすい文章を作成できると実感しました。 システム開発はどうする？ この文章作成のアプローチは、システム開発にも大いに活かせると考えています。開発目的や要件を明確にし、常にユーザーや関係者のニーズに注意を払いながら、資料作成や説明時には結論や狙いを示し、構成を整理して伝わりやすくすることが重要です。さらに、画面遷移図やデータフローなどの図表は、内容にふさわしい形式で提示し、理解しやすくする工夫が求められます。 コミュニケーションは改善する？ これらを実践することで、全体のコミュニケーション品質を高め、より効果的な開発プロセスを実現できると確信しています。

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

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

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

問題をどう分解する？ 問題をプロセスに分解して捉えることの重要性を改めて実感しました。問題を細分化することで、どの部分に原因が潜んでいるかを具体的に探ることができ、解決策を検討する際にも複数の方策から根拠をもって判断する必要性を感じました。特に、A/Bテストを用いることで、実データに基づいてどの方策が効果的かを検証できる点が有用だと感じました。各方策の比較では、実施条件を統一し、シンプルで運用判断がしやすい、低コストかつ少工数で取り組める点を重視することが大切です。 社内SEの対策は？ また、社内SEとして課題に対してシステム方策や製品の導入を行う中で、現実には1つの方策案を提示し、その効果を検証してから本番環境に導入するケースが多いことに気付きました。その理由は、方策の準備コストや期間、さらにユーザの教育コストが影響していると考えられるからです。そこで、まずは日常的に感じる課題に対し、すぐに立てやすい方策の検証手法から取り入れていくことが望ましいと考えています。

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

生成AIはどう役立つ？ 生成AIを業務効率化の手段として活用しようと考えていた私ですが、当初は「人間が介在しなくても」業務が進むのではという思いもありました。しかし、講義を受ける中で、生成AIは人間がしっかりとした役割を与え、明確な指示を出すことで初めてその価値を発揮できるということに気づかされました。 体験価値の進化はどう？ また、提供する価値が単なる「モノ」から「コト」へとシフトしている現在、単純なデータの組み合わせや決まりきった製品ではなく、生成AIを活用してより深い体験価値を顧客に提供できるサービスを展開したいという思いが湧いてきました。 システムの未来はどうなる？ 現在、数万人規模の業務を生成AIが自律的に理解し遂行するシステムを開発中ですが、現段階では主に業務効率化やコスト削減を目的としています。今後は、この生成AIにより、既に提供しているサービスにさらなる付加価値を加え、顧客の体験価値を一層向上させることを目指したいと考えています。

各平均値はどう選ぶ？ 加重平均は以前から活用していましたが、その際は重み付けの解釈に重点を置いていました。改めて考えると、単純平均、加重平均、幾何平均、中央値といった各種の平均値は目的に応じて使い分けるべきですが、実際の業務では加重平均に偏りがちです。また、見える化の手法としても円グラフやヒストグラムが多用され、ばらつきは主に標準偏差の数値で把握しています。 業務量の重みをどう見る？ 業務量の重み付けについては、データから抽出することで一層理解が深まり、数値化により説得力のある説明へとつながると感じています。今後も業務要件を数値から読み解く手法を積極的に採用していきたいです。 数値が語る本質は？ さらに、業務量のヒアリング調査結果やシステム利用率など、数値のインパクトは重要な判断材料となります。これらを自分の業務タスクに組み込み、インプットデータのマネジメントを計画の初期段階から取り入れていくことが今後の課題だと考えています。

フレームワークの意義は？ 仮説の基本的な理解を改めて振り返ることができました。これまで、どちらかというと自分のバイアスに左右されることが多かったですが、3Cや4Pといったフレームワークに沿って物事を進める習慣が必要だと実感しました。もちろん、データの活用において都合の良い点に気付いてしまう傾向もあり、そこは今後の課題です。 チーム作業に注意すべき？ また、実際の業務においては、ある程度の人数で構成されるチームで作業を進める場合、フレームワークを用いる際に工夫が求められることを改めて認識しました。それでも、基本に則って作業を進めることが、合意形成を図る上で重要であると感じました。 合意形成、どう進める？ 変革やシステムの刷新・改善といった業務では、関連部門との合意形成が不可欠です。こうした基本的なプロセスをフレームワークに落とし込むことで、問題の根本をより深く理解し、具体的なアクションプランを立てることができると考えています。