(13ページ目)

システム

に関する学び

---

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

ライブ授業をどう捉える？ ライブ授業を通して、分析においては「比較」が非常に重要であると改めて実感しました。限られた情報の中で考察を進めると、様々な視点が生まれる一方で、正確な回答を導き出せない場合もあることが認識できました。 データ準備の確認は？ データ分析を実施する際には、まず必要なデータをしっかりと揃えることが不可欠だと学びました。新しいシステムの導入を検討する場合、価格、使用頻度、使用者の経歴、最も利用される時間帯など、複数のデータを準備し、事前に確認すべきポイントを絞り込む必要があります。 集計と比較はどうする？ その上で、まずは確実にデータを集め、その後に集めたデータを比較しながら、必要な情報や懸念点を検討していくことが大切です。さらに、足りない情報がないかを意識しながら、新しいシステムに求められる要素を見極めるプロセスの重要性を再認識しました。

多角視点で深く見る？ 目の前で起きている事象については、安易に結論を出さずに、多角的な視点で深く理解を進めることが重要です。機械的にただ分類するのではなく、分類を行う際には仮説を持って切り分けることが必要です。 異常値の謎は何？ 私はクライアントワークで製造業の在庫管理を担当しています。その中で、異常値が見られた場合には、なぜその異常が発生しているのかという仮説を立て、原因を特定するよう努めています。その特定方法には、グラフ化や分類を活用し、他者に分かりやすく、簡潔にまとめることを心掛けています。 現場の声、どう活かす？ また、在庫管理システムにダッシュボード機能を追加する予定です。このダッシュボードには、様々な切り口での指標を記載する計画です。その際、自分の視点だけでなく、現場の意見も取り入れ、多角的な視点で実装を行うようにしています。

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

戦略って何だろう？ 戦略とは、まず孫氏が説いた「戦を略すこと」、そしてマイケル・ポーターが提案する「何をやり、何をやらないかを選択すること」を指し、さらにグロービスが定義するように、企業や事業の目的達成のために持続的な競争優位を確立する具体的なアクション・プランでもあります。 学び方のコツは？ また、学び方のコツとしては、①言語化＝考えを言葉にする、②教訓化＝教訓を引き出し原理原則化する、③自分事化＝学んだことを自分に引き寄せる、という三点が挙げられます。 実行はどうする？ 現在、システム開発において機能要件の精査だけでは対応が難しい要望を受けている状況です。そこで、今週は、次週以降に顧客への提案フェーズに臨むため、社内で戦略としてどのように進めるかを言語化し、共有し、さらにブラッシュアップする取り組みを進めています。

どう原因を見極める？ 課題解決においては、まず対象の業務プロセスを細分化し、どの段階が問題の原因となっているかを明確にすることが重要です。自分の感覚だけで原因を決定するのではなく、有識者へのヒアリングなどを通じてプロセス全体を整理し、どの部分に注力するかを正しく見極める必要があります。どのプロセスを改善すれば、課題解決に大きな効果が期待できるかをしっかり検討することが求められます。 何をテストするの？ また、改善案の効果を正確に判断するためには、A/Bテストの導入が有効です。改善前後の両方のパターンを同じ条件下でランダムにテストすることで、施策の効果を客観的に評価できます。さらに、システム導入のトライアルにおいては、現行システムと新システムを同時に使用することで、正確な効果測定が可能となるよう進めることが望まれます。

経済性と習熟効果はどう？ 規模の経済性について学びました。固定費と変動費の違いを正確に分析することの重要性を再認識し、分析を誤ると規模の不経済に陥る可能性がある点が印象に残りました。また、習熟効果についても一定程度理解していたものの、製造現場では人が入れ替わるのは仕方のない事実であるため、個々の熟練度に過度に依存しない設計やマネジメントが求められると感じました。 自動化の影響はどう考える？ 製造現場では、自動化やAIの導入により、人が関わる部分が次第に置き換えられています。こうした変化を進めつつも、システムの導入によって新たな不具合が生じる可能性や、重要な業務においては依然として人の習熟度が影響を与える点に注目しています。そのため、こういった課題についても分析し、適宜改善策を講じていく必要があると考えています。

設備投資の意義は？ 固定資産や固定負債が少ない状態は、資金の柔軟性やリスク低減の面で理想的ですが、事業継続のためには設備やシステムなどへの投資が不可欠です。そのため、自己資金だけでまかなうのは困難であり、銀行借入などの固定負債を利用する場合も多いと感じています。 資産負債のバランスは？ 過剰な負債による返済リスクや、資産不足による競争力の低下を避けるためには、事業の特性に応じた最適な資産・負債バランスを設計する工夫が必要です。 成果に見合っている？ また、各社が展開するサービスや事業を前提に、実現に必要な資産やその用途を明確にすることが重要です。PLやBSを読み解きながら、現在の自分の仕事が会社の提供価値に見合っているか、投資した金額に対して十分な成果が得られているのかを理解する意識が求められています。

感情価値を追求する理由は？ 昨今の市場環境では、単に機能的価値を提供するだけでは顧客を満足させることが難しくなっています。顧客満足を実現し、真の差別化を図るためには、「体験」という情緒的価値の追求が欠かせません。 業務効率と情緒的価値は？ 私の業務は、効率化や業務圧縮を目的としたツールやシステムの提供が中心ですが、その先のクライアントに対して情緒的価値を届ける意識を持つことが重要です。 多様なニーズに応えるには？ また、社内の複数のステークホルダーを顧客として捉え、日々の業務依頼を通してそれぞれのニーズや課題に応えることを心がけています。 体験で業務改革は？ BPOやBPR業務においては、顧客に「楽になった」という体験を提供することが本来の目的であることを忘れず、今後も業務に取り組んでいきます。

なぜ現状分析が必要？ 講義を通じて、ただ単に顧客目線で考えるのではなく、差別化に向けては競合を意識し、実現可能性と持続可能性を検証することが重要であると改めて学びました。まずは、自社の現状を正確に把握するためにVRIO分析を実施し、その結果をもとにポーターの基本戦略を用いてターゲット顧客を絞り込む方法が効果的だと感じました。 どう優位性を確認？ また、自社の優位性を明確にするためには、3C分析やSWOT分析と併せてVRIO分析を進めるのが有用であると思います。システム開発が本格化すると、柔軟に対応できる部分が限られてしまうため、提案活動の段階で自社の強みを十分に活かした提案を行うための準備が必要だと考えています。

フレームワークで全体把握？ 3C分析、SWOT分析、PESTなど、さまざまなフレームワークについて学ぶことができました。個人で課題を考えるだけでは局所的になりがちな点を、これらのフレームワークを用いて全体の取り巻く環境を整理することが大切だと実感しました。また、テンプレートを活用して大局観を持つことは、チーム全体で同じ視点を共有する上でも役立つと感じました。 フレームワークの限界を感じる？ システム開発に実際に取り組むと、フレームワークを活用する場面が限定的に感じられることもありました。しかし、顧客への提案の際には、顧客の外部要因や内部要因を分析して、より的確なシステム提案ができるのではないかと考えています。

固定概念に縛られる？ ドラッグストアにあるもの、ないものの演習を通して、あるものは具体的なイメージを持ちやすい反面、ないものは視野を広げることで無限に考えられる点がとても印象深かったです。この経験から、固定概念に縛られると考えが偏り、狭い視野に陥ってしまう恐れがあると実感しました。 システム全体を見渡す？ また、システムにバグが発生した際、一部の機能だけに着目して解決策を模索することが多いですが、それだけでは済まない場合も多いと感じました。バグの修正にあたっては、システム全体やユーザーの操作まで影響を及ぼすことを踏まえ、全体の視点から影響度と対策を考えることが改めて重要だと学びました。