(9ページ目)

システム

に関する学び

---

プレッシャーにはどう対処する？ 経営者としての視点に立つと、プレッシャーが非常に大きいことを実感しました。ここで、よりクリティカルな思考が必要だと感じました。 「イシュー」とは何を意味する？ 今週、主に学んだのは「イシュー」についてです。イシューとは、今ここで答えを出すべき問いのことを指し、ブレずに意識し続けるために疑問文の形を取ります。長期間の目標とは異なり、「今」答えを出さなければならない問いを具体的に考える必要があります。 どう具体策を決める？ この考え方は、特定の業務だけでなく、さまざまな意思決定の場面で活用できると感じました。特に私は業務運用の監督をしているため、システムや社内ルールの変更に対応する際、具体的な案を短期間で決定する必要があります。その際、短期的に素早く回答を見出し、周囲を巻き込むためにも、疑問文の形で一つ一つのイシューに向き合いたいと思います。 どのように行動計画を描く？ 学んだことを実際に活かしていくために、まず「イシュー」を意識的に捉え、それを継続的に意識し、関係者と共有しながら全体の方向性を考えたいと思います。周囲をうまく巻き込むためには、関連動画で学んだことが非常に役立ちました。身近な例に置き換えることで関係者も納得し、共に同じ目標に向かえるよう促したいです。

問いをどう理解する？ 「問いを立てる」という言葉について、普段の言い回しとは異なり、初めはピンと来なかったものの、ライブ授業の具体例を通じて理解が深まりました。YESかNOで答えられる問いを設定することで、その答えに対する論拠や分析が求められ、論理的な説明が自然と身につくと実感しています。これまでの日々の業務にも通じる部分があり、改めてその意義を認識することができました。 フレームワークの再確認は？ また、これまでシステム開発の現場で漠然と使っていた思考のフレームワークが、今回の学習を通じて再確認できた点も大きな収穫です。部署内で複数のシステム開発案件のレビューを行った際に、報告内容が論理的でない場面に直面することがあり、状況を整理するためにこのフレームワークを意識的に活用できそうだと感じました。さらに、事業計画の立案や部下のサポートにも、今までの経験にとらわれない新たな視点を加える上で大いに役立ちそうです。 イシューリストをどう見る？ ライブ講義で紹介されたイシューリストの作成方法も非常に印象的でした。日常業務では緊急度の高いものが優先され、本来注目すべき課題が見落とされがちですが、イシューリストを作成し定期的に見直すことで、重要な問題点を把握し、対処策を検討する体制を整えられると感じました。

本質は何だろう？ 問題解決を行う際には、まず何が問題なのかをしっかりと定義することが重要です。問題が本当にその部分にあるのか、あるいは「そもそも」といった観点で見直してみることも大切です。その後の分析やアクションを行う際にも、常に問いを意識することで、本質から逸れることなく、もしズレが生じた場合には適切に軌道修正することができます。 対策はどう考える？ たとえば、チームに人手不足という問題がある場合には、人員を増やすという対応だけでなく、同時に生産性の向上や仕組みの効率化を図ることが求められます。また、システム操作が煩雑で非効率だと感じた場合には、システムの改修を行うだけでなく、補助的なツールや直感的に理解しやすいマニュアルの整備を通じて生産性の向上を目指します。こうした問題を複数の視点から捉え、それぞれに合ったアプローチを実施することが重要です。 気づきはどう引き出す？ また、メンバーに対して問いの重要性を示すことで、彼らから新たな気づきを得ることができるかもしれません。定期的に自分の活動を見直し、無意識のうちにバイアスがかかっていないかを確認することも重要です。他の人から異なる視点や意見を求め、自身にはなかった新たな問いを取り入れることで、自分自身の視野を広げることができます。

物事を客観視するには？ 講座全体を通じて得た学びを振り返ると、まず客観的に物事を見る力が重要性を増していると感じました。また、視点や視座、視野の持ち方、そして問題を分解する方法についても多くを学ぶことができました。問題に直面した際は、適切な問いを立てることから始め、データの加工・可視化を行って分析し、解決策を見出しスライドを作成するというステップが有効であると理解しました。 運用変更の必要性は？ さらに、変化に伴うアクションを決定する際には、システムや社内ルールの変更に応じた運用変更が不可欠です。その際には、なぜその運用変更が必要なのかを関係者に分かりやすく説明することが大切です。同時に、変化に応じたアクションが本当に必要かを問い、様々な角度から分析することが必要です。このプロセスを通じて、回答を常に疑いながら最善の解決策を見出したいと考えています。 効果的なプレゼンは？ また、上層部へのプレゼンテーションでも得た知識を役立てたいと思います。今年度のKPI達成や課題の共有に際しては、受け手にとって効果的なプレゼンとなるよう、視野・視座・視点を意識した分析と資料作りを心掛けます。これにより、より理解しやすく、見やすい資料を作成し、効果的な情報の伝達を実現したいです。

なぜ分解して考える？ プロセスを分解して問題の本質に迫る手法について、非常に分かりやすい事例から学ぶことができました。特に、採用プロセスの一部である中途採用面談や、顧客への提案における在庫差異の問題解決に、このアプローチを活用できると感じています。また、ABテストにおいては、条件をできる限り同一とし、検証範囲を絞るための仮説設定が重要である点も再認識しました。 採用面談、何が問題？ まず、中途採用面談に関しては、自身が関与する採用活動において、プロセスのどの部分で問題が発生しているのかを明確にするため、面談調整に要する日数と採用結果の情報を人事部から収集することを検討しています。この情報をもとに、面談調整に時間がかかる原因を特定し、改善策を提言することで、採用率の向上を図ることができると考えています。 在庫の差異、どう解決？ 次に、顧客への提案、特にシステム間の在庫差異に関する課題解決では、既に現状の業務プロセス分析は実施していますが、課題が発生しているプロセスの粒度が細かすぎるため、より単純化した形で説明する必要性を感じました。問題となりうる箇所を明示した上で、システム改善または運用プロセスの変更のいずれかを提案し、顧客にとって最適な解決策を提示していく考えです。

最初のLIVE講座の印象は？ クリティカルシンキングの総まとめの週では、最初のLIVE講座で「自分の思考の癖を知る」というテーマが特に印象に残りました。その後のLIVE講座では、week1～5で学んだ知識を活かしながら、２つの問題に取り組み、その中で数字の並びを見ると細部に過度に意識が向いてしまう自分の癖に気づかされました。そこで、まず問題全体を把握し、数値を見える化する、軸を変えて視点を変えるといった手法を段階的に取り入れることの大切さを実感させられました。 数字分析はどう進む？ さらに、数字の羅列や傾向を分析する際、現実の業務の中でも工数の見直しやシステムの性能分析などが必要になる状況を思い起こしました。今回学んだデータ分析のツールを活用すれば、初めに考えすぎず、さまざまな角度からデータの整理と視覚化を行い、その上で仮説を立て補足説明を探すという実践的なアプローチが可能だと感じました。 どのデータ視覚化？ 今後は、単に収集したデータに基づいて行動するのではなく、まずはデータを多角的に分類し、視覚化する作業を徹底して行います。そして、その中から得られる示唆をたくさん書き出し、グループ化や抽象化を通じて整理し、自分の視点をさらに深める検討を進めていきたいと思います。

簿記学習のポイントを振り返る 今回の内容は、以前から簿記で学習していたことと重なっていたため、理解するのは比較的容易でした。固定負債と流動負債の違いを理解するのには最初苦労しましたが、学んでおいて良かったと思います。また、1年以上の負債でも通常の営業サイクルに含まれるのであれば流動負債とするという例外ケースは見分けるのが難しいかもしれません。ただし、今のところはそのようなケースにはまだ出会ったことがありません。 自店舗の資産を深く考えてみる 自分の店舗の資産と負債について考えてみました。これまで店舗の資産について深く考えたことがなかったので、良い機会になりました。私の店舗は賃借であり、大部分のPCやシステムもリースや利用料を払って使用しています。顧客データや人材などのソフトな部分は資産と言えますが、基本的にはBSには表記しません。具体的に考えると、資産の特定は難しいものです。 おおよそのBSを作成してみる 次に、自店舗のBSをざっくり作ってみました。正確なものではなく、おおよその仮定で考えられる項目に置き換えてみました。さらに、自社全店舗を合わせたものが会社全体のおおよそのBSになると考えると、若干大雑把な数字になりますが、それでも考えてみる価値はあると思います。

思考の偏りにどう向き合うか？ この講座を通じて、物事の分解方法や見せ方の基本を学ぶことができました。その中で、自分の考え方には思考の偏りがあることも改めて認識し、常にそれを前提として振り返ることが重要だと感じました。 データに基づく「イシュー」とは？ また、問題解決においては、本当に必要なデータとそれに基づく「イシュー」を抑え続けることが求められると実感しました。チームメンバーが同様に問題解決に取り組む際、その課題を特定し、解決策の立案までの流れを明確に説明できるようになることで、自分自身の理解も深まるように努めました。 業務要件定義の重要性 業務要件定義の際には、業務ユーザーが具体的にどのような問題に直面しているのかを分解し、それを言葉にする重要性を学びました。意識的に、このアプローチを用いることで、意思決定を行う際にどこまで網羅的に分解できているか、その対策が本当に有効であるかを十分に議論する必要性を感じました。 課題分解で認識の齟齬を防ぐ方法 特に、業務ユーザーの課題をシステムで解決する場合、課題の分解を丁寧に行い、認識の齟齬がないよう努めることが不可欠であると痛感しました。これらの学びを通じて、問題解決能力の向上に繋がることを期待しています。

データ分析の基礎を理解するには？ データ分析を始めるにあたり、まずはデータの形式を理解し、その違いを把握することが重要だと感じました。分析に必要なデータを集め、形式に合わせた加工を施し、さらに可視化することで示唆を得る流れを認識しました。特に、データの性質をしっかり理解しないままでは、可視化しても意味がないことを学びました。 どう業務課題を探索する？ 例えば、各店舗での様々な商品の契約状況から、それぞれの商品の契約者に共通する特徴を可視化したり、取引履歴と商品の契約状況の関連性を探るといった作業は、まずデータの性質を把握することから始まります。データを比較し、その特徴を掴むことで、業務課題に関連するデータが何であるかを見極めることができます。 他社事例をどう活かす？ また、他社のデータ活用事例を知ることで、自社の業務に置き換えて考え、業務上の課題を発見する手がかりとすることができました。社内においても、各種システムで収集・蓄積されているデータの内容を把握し、それを整理して業務課題を解決するための手法を模索することが大切です。こうしたプロセスを経て、データの性質を十分に理解し、適切に可視化し比較することで、より良い業務改善に繋げることができると感じました。

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

説明の根拠はどう確認する？ ピラミッドストラクチャーを用いることで、説明の際にその根拠に共通する要素を確認し、文章の構造を理解する学びを得ました。共通要素を言葉で表現するのは難しく、また、説明の正しさは相手によって変える必要があると感じました。例えば、勉強会を実施する際、上司を説得する場合は、勉強会によって社員の負荷が増えないことを強調することが重要です。一方で、同僚を説得する際には、スキルアップなどのメリットを提示することが効果的です。これは、相手の課題を解決する要素を説得に使用する例です。 会話でどう説明すべき？ 日々のミーティングでは、相手の前提を理解し、どのようなアプローチで説明すれば納得感を得られるかを考えながら会話を進めたいと思います。また、上司への提案時には、ピラミッドストラクチャーを使って根拠を明確に伝えることが重要です。 変革の価値は何？ 他部署への方針変更の説明においては、変更の理由をしっかり伝え、どのような価値が相手に提供されるか、またどのようなメリットがあるかを示すことが大切です。新たなシステム導入時には、必ずオペレーションの変更が伴うため、その際の相手へのメリットを具体的な根拠を示して理解してもらうことが必要です。

ロジックツリーって何？ ロジックツリーとは、ある問題や課題に対して、その構成要素を分解し整理するためのワークフレームです。複雑な要素を明確にし、原因や解決策を見つけ出すためには、MECE（もれなくダブりなく）を意識することが重要です。 なぜ手順が必要？ システム導入のプロジェクト進行で発生する問題に対して、ロジックツリーを活用する具体的な手順は以下の通りです。まず、タスクが遅延している原因という起点となる要素を設定します。次に、その要素を「スケジュールに対する意識不足」「リソース不足」「スケジュール自体に問題がある」などといった具体的な要因に分解します。 どう深掘りするの？ さらに、各要素について深掘りし、たとえばリソースが不足している場合には、タスクに必要な要員を明確に割り出していなかったことが原因として考えられます。その上で、各原因に対して解決策を検討します。具体的には、必要な要員の割り出しを行い、タスクを完了するためにどの要員がどれだけ必要かを明確にし、要員の調整を試みるという方法です。 実行計画はどうなる？ 最後に、検討した解決策に優先順位を付け、実行計画を立てることが、問題解決のために有効であると考えられます。