(6ページ目)

本 ✕ システム

に関する学び

---

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

満足システムの意義は？ 自分もユーザも満足できるシステムを開発・提供する重要性に、改めて気付かされました。現在目指しているキャリアは一般的には成長と捉えられていますが、自分自身にとって本当に成長なのか、真剣に考える必要があると感じます。どんな自分になりたいのか、日々の業務に追われて見落としがちですが、意識的に時間を取って考えることは大切です。 自己評価の方法は？ 今回、ナノ単科の学習を通して、今一度自身の在り方を見直す機会を得ました。これを機に、今後も定期的に自己評価を行うための仕掛けが必要だと考えています。例えば、毎月リマインダーを設定し、なりたい自分像や現在の進捗状況を文字にして記録する方法を始めようと思います。 なりたい自分って何？ 「なりたい自分はどんな人物か」「なぜそのように思うのか」「これまでの変化の中で、どのような出来事があったのか」「なりたい自分に近づくために今日から何をするのか」―こうした問いを自分自身に投げかけ、小さなことでも具体的に書き出していくことが、今後の成長に繋がると信じています。

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

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

誰にアピールすべき？ 「誰に売るか」という視点の重要性を実感しました。最初は具体的に何をどう考えればよいのか分からなかったものの、実践演習の設問に沿って一つひとつ整理していくうちに、その考え方の本質が理解できるようになりました。ほかの事例についても同様に検討してみたいと思います。 システムの見直しは？ また、以前作成したものの、全く成果を上げられていないシステムについて悩んでいました。ターゲット層には既に優れた競合が存在しており、現状のシステムを一新するのは現実的でないという認識から、まずはターゲット層を切り替えることに着目することにしました。 伝え方はどうすべき？ その上で、営業チームや開発の主担当と協力し、既存システムのどの機能を誰に届けるべきかを話し合いました。システム導入を決定する意思決定者が何を基準として判断しているのか、また担当者にどのような価値を訴求すれば導入の後押しとなるのか、といった点について深く検討する良い機会となりました。

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

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

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

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

イシューの意味は？ 「イシュー」とは「いまここで答えを出すべき問い」であり、その重要性を実感しました。問いが誤ると論点がずれ、共通認識が形成されなくなるため、イシューを共有し本質を意識することが、具体的な課題解決や施策につながると考えています。 課題共有はどう進む？ IT業界においては、顧客からの課題相談が頻繁に寄せられるため、まずはイシューを明確にして共有することから取り組みたいと思います。共有をせずに解決策だけを模索すると、後に認識の齟齬が生じ、根本的な課題解決につながらない恐れがあります。 本質解決は可能か？ 業務では、本質的な課題が誤ると顧客が期待する解決が果たせず、結果として不適切なITシステムが提供される恐れがあります。そのため、単に解決策のみを提案するのではなく、イシューを踏まえた本質的な課題解決を追求することで、真に必要なITシステムの提供が可能になると考えています。

なぜ売れたのか？ 実例に沿って、なぜある商品が売れたのかを考えることは今まで経験していなかったため、とても印象に残りました。自分がよく知る商品についても同様に、なぜ売れたのか具体的な理由を探っていきたいと思います。また、行動観察を行ったことがなかったため、まずは身近なところから実践してみる意欲が湧いてきました。 実際の行動はどう？ 新規システムを開発する際には、これまで社長からの指示に従ってシステムを作ってきましたが、その結果、真のニーズが捉えられておらず、売れない原因になっていたと感じます。今後は、社長が想定する利用者像に留まらず、実際に利用者の行動を観察し、深いインタビューを行った上でシステムのコンセプトを策定していくことが重要だと実感しました。この点を踏まえ、予算申請にも利用者観察やインタビューのプロセスを組み込み、本当に解決すべき課題を明確にしていきたいと考えています。

問いと答えで学ぶ理由は？ 今週はクリティカルシンキングの振り返りを行い、WEEK1の自分の回答を再確認しました。問いと答え、すなわち主張と根拠のシンプルな構成が印象的で、問いを明確に設定し、その問いだけに集中して回答するという行為の難しさを実感しました。 お客様の課題は核心？ また、商談時にはお客様からシステム構築による課題解決のご相談をいただくことが多い中で、お客様の課題が何か、本当にその課題が核心なのか、そしてその解決策が改善につながるのかを、主張と根拠をセットで検討する必要があると感じました。講義で「早く答えを導き出すには常に考え続けることが大切」という話が印象深く、思考の切り替えを意識して反復することで、そのスピード感を自分のものにしたいと思います。今後は、何かを考える際に必ず主張と根拠を意識する行動を心がけていきます。