(8ページ目)

システム

に関する学び

---

問題抽出はどうする？ 問題や課題の抽出は、文章だけでなく事象にも適用できるという点を実感しました。文章としてまとめる場合は、誰が見ても具体的かつわかりやすく、明確に「問題・課題」と認識できる情報を提示することが求められます。また、業務や事象が発生した際には、問題や課題とその原因、対策を即座に考え出す発想力が必要だと感じています。 時間ロスはどう解消？ システム障害やプロジェクト遂行時における問題や課題に対して、考える時間がロスになることがあります。そこで、このロス時間をどのようになくし、万人に伝わる内容や表現、魅力的な見せ方を実現できるかを、一つひとつの仕事に取り組む中で追求していきたいと思います。 スキル向上はどう進める？ また、時間のロスを削減するためには、引き続き多くの文献や資料に目を通したり、人との会話を重ねたりすることが重要です。自分の発想力や判断力、瞬発力を鍛えるとともに、学んだ見せ方や伝え方を活用した資料作成や発言ができるよう、イメージトレーニングを繰り返していこうと考えています。

顧客ニーズをどう解釈するか？ 顧客のニーズを的確に把握することは、すべての始まりであると考えています。そのニーズをどのように解釈し、自身または自社の行動に結びつけるかが重要です。しかし、ニーズの正確性は非常に重要であり、顧客のニーズをどれだけ深く掘り下げて引き出すことができるかが鍵となります。 購買業務で求められるものは？ 購買業務に携わっていると、まずはコストダウンを求められることが多いです。要求される仕様に逸脱しない範囲での代替品の発見など、ニーズを的確に捉え、調査に役立てることが求められます。単に右から左へ流すだけでなく、選択と集中を念頭において業務を進めるべきです。 社内ニーズを吸い上げるには？ まず初めに、社内にどのようなニーズがあるのかを吸い上げる仕組みを作ることが重要です。そして、それを自身の部署で協議し、活動につなげるルーティンを構築することが求められます。システムはできる限り個人に負担をかけないものであるべきだと考えるため、慎重にシステム構築を進めていきます。

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

目的を考える重要性とは？ 今までグラフを用いた文章を作る経験が少なかったので、今回の学びはとても有益でした。「目的」を考えることが重要であり、目的に沿ったメッセージを表現するための最適な方法を検討する必要があると感じました。特に伝えたいメッセージは、フォントを変えたり色をつけたりするなどの工夫が必要です。 図解の新たな活用法とは？ このスキルは、可視化のシステムを作るときにも活用できると思います。また、経営に予算を取得する際や、今までの仕事の効果を示す場面でも役立つと感じました。これまではほとんど数字や表ばかりで説明していましたが、図を使う場面をもっと考えてみようと思います。 効果的な資料作成の構想 伝えるべき相手の目的を考え、正しく伝えるための資料の作り方の構想をまず描くことが大切だと思います。部下に仕事を説明する際には、イメージしやすいようにグラフやチャートを使うことを試してみようと考えています。どのような場面でこれを活用できるかをまずは考えてみます。

決算報告書をどう捉える？ 現在、システバックスの決算報告書を実際に確認する機会がありました。以前はただの数字の羅列に過ぎなかったP/Lですが、コンセプトや事業活動のイメージとリンクさせることで、数値の背景が見えてきたと感じます。システムエンジニアから税理士法人に転職し、少しずつ担当のお客様を持つ中で、今後はお客様へP/LやB/Sを説明する機会が増えていくと予想しています。そのため、今回の学びは非常に有意義で、企業についてさらに調べるなどして内省できる良い機会となりました。 説明方法はどう考える？ ご担当のお客様には、数値を根拠にP/Lの結果や今後の動向を自信を持ってご説明しています。また、事業活動をヒアリングした内容を図などに落とし込み、お客様とのイメージを合わせる取り組みも行っています。今回の決算報告書の学びを活かし、先輩社員の説明面談にも同席し、学んだ視点でレポートを読み、フィードバックをいただくことでさらにスキルアップを目指していきたいと考えています。

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

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

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

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

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

読み手へどう配慮？ 読み手への配慮について学びました。文章を書く際、誰に向けて何を伝えるのかを明確にし、タイトルや見出しを工夫して関心を引くことが重要です。また、色や余計な装飾を避け、読み手に負担をかけないよう心がけます。 知識はどう活かす？ この知識は、マニュアルや会議のアジェンダを作成するときに役立つと感じました。特に、初めて使用するシステムの説明などでは、大きな言葉を避け、伝えたいポイントを事前に整理することが重要です。さらに、読み手の視点やフォントの細部にまで配慮し、最低限のすり合わせで理解してもらえるよう準備します。 資料準備の進め方は？ 具体的には、まず誰向けの資料なのか、何を伝えたいのか、会議終了時のゴールなどを大枠で紙に書き出します。その後、逆の立場に立って、説明の順番が適切かどうかを確認します。最後に、時間を決めて、集中的にまとめ上げる時間を作ることが大切です。

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