(4ページ目)

本 ✕ システム

に関する学び

---

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

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

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

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

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

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

デザイン思考はどう変わる？ デザイン思考は、当初は外見や部分的な要素に焦点が当てられていましたが、徐々に全体設計へのアプローチへと発展してきました。お客様への共感を軸とすることで、顧客にとって本質的な課題解決を目指す姿勢は、単に技術的に高度であるだけではなく、実際に役立つ製品やサービスへと結実するために不可欠です。 技術進歩と課題は何？ また、AIの進化により、ITシステムの試作が容易になったため、全体プロセスの回しやすさは向上しています。しかしながら、細部の制御が難しい現状では、あと一歩の実現に大きな工数と時間が必要となるケースも見受けられます。加えて、顧客と製品やサービスの提供者はそれぞれ別の利害を持つため、どうしても緊張関係が生じるという課題があり、こうした点を含めた総合的な方法論の整備が望まれます。 試作と提案はどう進む？ 今後は、ChatGPTなどを活用して顧客の発言から課題やソリューションを分析し、その結果を基にReplitで試作案を作成、実際に顧客に提示するという流れが実現できるのではないかと考えています。授業を通して、こうしたプロンプトの設計など、具体的な手法を確立していくことが目標です。

問いの立て方はどう？ 問題が発生した際、問いの立て方によって真に解決すべき課題が異なり、解決策の方向性が決まってくることがよく理解できました。イシューとは何か、またイシューを設定して考えるとはどういうことかを知っていないと、問題の本質にたどり着けないということも実感しました。 問いが変える提案は？ このアプローチは、私自身の業務における顧客の課題解決にも活用できると感じています。これまでユーザーの課題を聞き取りシステムを提案してきましたが、結局は活用されない機能が存在したこともありました。今後は、常に「問い」を立て、問題の本質を追求した上で提案していく必要があると考えています。 組織課題の見極めは？ また、社内では組織の抱える課題を正確に見極め、その解決策を事業計画に反映させたいと思っています。まずは、自身の業務において、ユーザーの課題に対してすぐに解答を提示するのではなく、問いを設定してその内容が本質的なものかどうかを繰り返し吟味しながら、適切な提案を行うことが重要です。そして、そのプロセスをチームで共有し、全員が同じ方向に向かって取り組めるようチームビルディングに努めていきたいです。

制約が生む思考の深さとは？ 私は、思考において制約があるほうが解答を導きやすく、制約がない場合の方がかえって困難な思考になりがちであることに気づきました。人間は、簡単に考えたことよりも、少し深く考え、もうワンステップ努力することで、より良い答えを得られると感じました。 顧客の本質をどう捉える？ IT業界で営業職をしている私は、顧客の問題や課題を聞き出し、システム化のニーズや条件を理解した上で、顧客要件に合ったシステムを提案する機会が多くあります。この際に、顧客が何を求めているのかを正確に聞き取り、それに対する提案を行う場面で今回学んだ考え方を活用できればと思っています。また、社内での受注審議における説明など、多くの人に物事を説明する場面での事前準備にも応用できそうです。 効果的な提案の準備法 具体的には、顧客要件をなるべくシンプルに書き出し、提案ポイントを整理してそれがマッチしているのかを検討します。さらに、自作の説明資料に対して他者から質問を想定し（自分ならどこを質問するか）、その想定問答を資料のブラッシュアップ時に活用していきたいと思います。

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

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

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