(12ページ目)

システム

に関する学び

---

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

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

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

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

戦略的イメージの気づきは？ 「戦略的なイメージ」に関する回答からは、これまで自分にはなかった視点を得ることができました。手をかけなくても安定するシステムを構築するという考え方が、新たな気づきとなりました。 相手ごとに違う道は？ また、普段行っている業務に関して振り返っている際、講師から「人に関わる点では、現在地からゴールまでの道のりは相手ごとに異なる」とのご指摘をいただきました。同じゴールであっても、そこでのプロセスが異なる場合や、目標自体が異なる場合もあり、それぞれに見合った難しさや検討すべき点があると実感しました。自分の日常業務が整理され、言語化できた瞬間でもありました。 効率実現の秘訣は？ さらに、「できるだけ早く、できるだけ手間をかけずに目的・目標・自分の想いを実現する」という考え方が印象に残りました。計画を立てたり、頭の中を整理する際に、まず自分がすべきこととそうでないことを明確にすることで、より効率よく前進できると学びました。今後はこの考え方をすぐに実践していくつもりです。 参加者の取り組みは？ さまざまな立場や経験を持つ参加者の具体的な取り組みを知ることで、思考の幅が広がると感じ、大変意義深い学びの機会であったと実感しています。

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

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

生成AIだけで大丈夫？ 現時点での生成AIは、予測に基づいた文章生成しかできないため、期待した成果を得るためには必ず人間の介入が必要です。具体的には、適切な情報提供と最終確認の２点に留意することが求められます。生成AIの出力をそのまま信頼して他人に伝えると、自身の能力すら疑われる可能性があるため、慎重な対応が不可欠です。 苦手部分はどう克服？ また、生成AIが苦手な部分を補うためには、編集者自身のスキル向上が必要です。AIが生成した文章の誤りや改善点を言語化できる能力がないと、成果の質が向上せず、活用の幅も狭まってしまいます。そのため、基本的なスキルの向上にも力を入れることが重要です。 企画書の信頼は確か？ さらに、イベント企画においては、事前にシステムユーザーを対象としたアンケートを実施し、そのフィードバックをもとに企画書を作成する手法が有効です。アンケート作成の際には、誰に向けたものか、目的や求めるニュアンスなどの情報をプロンプトに盛り込み、質の高いアンケート骨子を作成することが求められます。そして、どの情報を基に項目を作成したのか、参考とした出典のURLや抜粋文言を示すことで、データの信頼性を確認することも大切です。

イシューはなぜ重要？ 問題が発生した際には、まず「イシューは何か？」という問いを忘れずに持ち続けることが大切だと感じました。関係者全員がそのイシューを共通認識として共有することからスタートすることで、論点がぶれず、解決策の議論にしっかりと集中できます。 どうして急いで解決策？ 一方で、いきなり「How（解決策）」に話を持っていくのは注意が必要です。後になって「なんでこの話をしているんだろう？」「そもそも何が問題だったんだろう？」「これって有効な施策なのだろうか？」といった疑問が生じ、議論が後戻りしたりぶれてしまうリスクがあります。 信頼関係はどう築く？ よくある例として、営業売上目標の未達が挙げられます。一般的には、顧客の業績悪化により無駄な経費や固定費を削減する動きが理由だと言われます。しかし、注意すべきは、それだけが原因で問題が起こっているとは限らない点です。実際には、既存顧客が自社システムの活用不足により解約が相次いでいたり、顧客の予算縮小とともに自社製品への信頼が低下している可能性も考えられます。そのため、本質的な課題は、営業施策の活動量や上位接触の不足ではなく、顧客との信頼関係にあるのではないかと捉えることが必要です。

顧客と競合はどう見る？ 差別化について学んだ内容では、まずどの業界で事業を展開し、ターゲットとなる顧客が誰であるかを明確にすることが重要だと実感しました。その上で、顧客が求めるものが何か、どのような価値を提供すれば意味があるのかを深く考える必要があります。また、競合他社についても、単に同じビジネスモデルを真似るのではなく、顧客視点でその存在を捉えることが求められると学びました。特に、VRIOの模倣困難性に関しては、独自の歴史的条件や因果関係の不明性、さらには社会的複雑性といった要因が働くため、他社には真似できない価値を生み出す可能性がある点が非常に興味深いと感じました。今後は、自社にもこうした独自要素がないか、改めて考察してみたいと思います。 自社戦略を再検討する？ また、今後の自社戦略を検討するにあたり、VRIOの観点から差別化の施策を実践してみたいと考えています。現在の受託開発業務では、場合によっては他社と同じシステムやテーマで開発が進むこともあり、身近な競合との違いを明確にすることが課題となっています。まずは、身近な顧客や競合を軸に設定し、実際に差別化を図る方法を試すことで、より具体的な戦略の構築に繋げていきたいと思います。

ビジネス違いはなぜ？ 今回の学びで最も印象に残ったのは、各社のビジネスの違いがP/LやB/Sにそのまま反映される点です。たとえば、ZoomやNetflixはシステム開発やコンテンツなど、目に見えない価値に多くの投資をしている一方、ANAは航空機など大きな設備に、またZOZOは在庫を持たない軽い資産構成になっていることが分かりました。数字だけでは把握しにくい面もありますが、事業内容と合わせて見ることで「その会社が何に力を入れているのか」が明確に感じられるようになりました。 数字に潜む意味は？ また、今後は財務諸表を単なる数字の羅列としてではなく、企業の考え方を読み解く大切なヒントとして活用していきたいと考えています。数字を一面的に判断するのではなく、事業内容との関連性を意識して、「この数値であれば問題ないのでは」といった視点で検証し、議論に役立てる姿勢が求められると感じました。 価値の軸はどこ？ さらに、気になる他業界の企業についても、P/L・B/Sと事業内容をセットで分析し、「この会社は何に価値を置いているのか」を言葉にしてみる習慣をつけたいと思います。これにより、決算資料からより具体的な企業戦略が見えてくるはずです。

規模経済の効果は？ 規模の経済性（スケールメリット）では、生産量を増やすことで生産コストが下がり、発注量が多いほど交渉力を高める効果があります。習熟効果に関しては、効率化の進展で1個あたりのコストが低減できる一方、ナレッジの蓄積状況によりその効果に差が生じることも見受けられます。 範囲経済の利益と危険は？ また、範囲の経済性は既存の資源を他の事業に展開することでコスト削減を図る手法です。しかし、多角化によって非効率が生じ、逆に追加コストが発生する場合も完全には排除できません。ネットワーク経済性の場合、ネットワーク参加者の増加により利便性が急速に向上し、優れたサービスが市場でのデファクトスタンダードとなる機会もありますが、より魅力的な代替サービスの出現により容易に置き換えられるリスクも存在します。 システム開発の可能性は？ 自社のシステム開発業務においては、習熟効果と範囲の経済性の両面が活かせると感じています。パッケージ開発を通じた開発ナレッジの蓄積で生産性の向上や教育の効率化が期待でき、加えて開発に携わる中で得た業務スキルをほかの顧客にも展開することで、競合との差別化や市場での優位性が実現できると考えています。