(16ページ目)

システム

に関する学び

---

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

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

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

自分の考え方はどう？ クリティカルシンキングの講座では、「もう一人の自分を育てる」という考え方がとても印象に残りました。これまでの私は、自分一人で考える傾向が強く、そのために思考が限定的で柔軟性に欠けていました。課題に対しても、なんとなく取り組み、経験値に頼ってスピードを重視していたと感じます。しかし、本講座やグループワークを通じてさまざまな問いを投げかけられた結果、自分の考えに強いバイアスがかかっていたことに気づくことができました。今後は、本講座で習得したMECEやピラミッドストラクチャーといったテクニックを活かし、自己に問いかける「もう一人の自分」を育てていきたいと思います。 業務の対応策はどう？ 業務においては、システム周りのテクニカルな課題に対応する機会が多くあります。単に顧客の要望を言葉通りに実現するのではなく、広い視野を持ってその背景や目的を十分に分析し、顧客にとって長期的に最も適した対応策を導き出すことを目指しています。

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

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

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

仮説とは何だろう？ ビジネスにおける仮説とは、ある論点に対する仮の答えのことを指します。仮説には「結果の仮説」と「問題解決の仮説」があり、その内容は過去、現在、未来の時間軸に沿って変わっていきます。 データ収集はどうする？ 仮説を立てる際は、偏りなくデータを集めることが重要です。反論が予想される項目についても、対応できるデータを用意することで、仮説全体の説得力が向上します。 仮説展開の鍵は？ 業務においては、まず結果の仮説を立て、その後で問題解決の仮説へと展開するケースが多いと感じます。普段は課題に対して直接問題解決の仮説を検討しがちですが、結果の仮説をしっかりと行うことで、問題解決の仮説を立てる際に抜け落ちがない視点で検証できることに気づきました。 収集可能性を確認？ また、どのようなデータが収集可能かという点は、今後のシステム更新においても重要な視点として意識していきたいと考えています。

体験に何を感じる？ ビジネスの在り方が「体験」から「モノ」へと変わる中で、どのような体験に価値があるのかを意識することの重要性を学びました。同時に、AIはあくまでツールであり、操作や評価は人間が担うべきであると再認識しました。AIに任せすぎると、ユーザーに十分な価値を提供できない可能性があるため、自身もAIを右腕として上手く活用し、適切な役割を果たしていこうと感じました。 AIの役割は何？ 講義に参加した目的は、業務におけるAI活用法を学ぶことでしたが、実際には人間が果たすべき役割と、AIに任せるべき業務の見極めを学ぶ良い機会となりました。具体的には、議事録の作成や企画書の生成、スケジュール管理といったタスクはAIに任せ、コミュニケーションや共感を必要とする部分に注力する体制づくりを進めたいと考えています。また、工数管理システムに「AIを活用した業務」や「AIを用いた時間」を項目として追加し、効果的な管理を検討中です。

ターゲット再検証は？ 商品のターゲットを見直すことで、新たな価値が生まれる可能性を学びました。特に、心理的変数は時代とともに変化するため、価値を再評価する上で有効な切り口であると実感しました。 マップの違いは？ また、ポジショニングマップとパーセプションマップの違いについて理解を深め、顧客目線がいかに大切かを再認識することができました。 事業見直しはどう？ 自社の事業を振り返る際は、まず特徴を洗い出して訴求ポイントを整理することから始めました。その上で、どこにポジショニングを置くべきか検討し、注力している事業に問題がないかを確認しています。さらに、顧客へのヒアリングを通じて、自社の伝えたいポジションがしっかり伝わっているかどうかをチェックしていきます。 システムに期待は？ また、時間に余裕があれば、システム会社に対してどのような期待を持っているのか、直接伺ってみたいと考えています。

目的整理はどう進む？ ライブ授業では、シナリオ実習を通じて目的の明確化、優先順位の決定、リソースの最適な活用、そして情報収集の大切さを学びました。一方、動画学習では戦略と戦術の違いに着目し、物事全体を俯瞰して捉える重要性を実感しました。これにより、まずは達成すべき目標の整理と明確化、そしてその目標に向けた無駄のない計画作成の必要性を体得することができました。 開発進捗はどう見極める？ また、システム開発の初期段階においては、顧客の要望整理と目的の明確化、優先順位の確定、さらには予算や人員配置、期限設定といったリソースの最適化が欠かせません。開発段階では、全体の状況を把握しながら効率的な進捗管理を行うことで、無理なくプロジェクトを進めることが可能となります。発生する課題に関しても、すべてに対応するのではなく、優先順位に基づいて取り組むことで、リソースを集中させながら最適な解決策を見出すことが大切だと感じました。

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