(13ページ目)

部門

に関する学び

---

なぜP/Lを理解する必要があるのか？ ビジネスのコンセプトやビジネスモデルを理解した上でP/Lを読むことが重要です。ビジネスモデルが分からないままP/Lだけを見ても、数字の示す意味が理解できなくなります。ビジネスモデルが分かると、数字、特に費用の内訳が想定しやすくなります。特にマーケティング費用は時折忘れがちになるので注意が必要です。これは、エンジニア出身者の弱点としてより意識して取り組むべき点です。 ビジネスモデルごとのP/L比較 現在、部門内のいくつかのプロジェクトのビジネスケースを見直す時期です。各プロジェクトのP/Lを確認し、特にサービス、ハードウェア＋サービス、ハードウェアBtBなどのビジネスモデルごとにP/Lを比較しています。これにより、各プロジェクトの個別のP/Lが確認できる状態になり、横並びで比較することで違いが見え始めています。 効果的なP/L確認の方法とは？ まずは、各プロジェクトから提出されるP/Lを来週1日1件ずつ確認していきます。確認すべきプロジェクト数は5つあり、1日1件確認する予定です。分からない項目については、各プロジェクトチームに確認して理解を深めることが重要です。一件ずつ質問を通じて理解を深めていくつもりです。 来週の目標とアクション宣言 グループワーク後の宣言として、米国時間の木曜日までにGlobisの課題を終わらせる予定です。また、プロジェクトのP/Lを見ての気付きも発表する予定です。

住民サービス改善とは？ 私の職場である自治体において、住民への行政サービス提供の改善を実践しています。一例として、市役所の窓口での手続き改善点を見出すため、職員がロールプレイング形式で体験しながら意見を出し合ったり、電子化された行政手続きを自ら試用してみたりする取り組みがあります。 試用体験の効果は？ 電子化された行政手続きは、リリース前に何度も動作チェックを兼ねた体験が行われるため、自然と試用される流れになっています。私自身は行政手続きの担当部門ではなく、システム開発側にいるため、制度の細かな点についてはあまり把握していません。そのため、住民に近い立場から、専門用語を極力排除し、質問項目も必要最低限に工夫して使うよう努めました。この経験から、行政特有の硬直した手続きや、利用者側のストレスを実感し、ユーザー視点に立ったサービス開発が可能であったと考えています。 ユーザー共感どう生む？ 利用者はあくまでサービスのユーザーであるため、ユーザー視点で製品やサービスを開発するのは当たり前のことです。しかし実際には、業務の多忙さや手間を理由に、この基本的なステップが省かれている場合が多く見受けられます。組織全体の取り組みとしてユーザー共感のプロセスを重視することで、より良い環境づくりが実現できるのではないでしょうか。共感と共創が伴わない製品やサービスは淘汰されるという認識のもと、今後もユーザー体験の改善に努めていく必要があると感じています。

何が問題と捉える？ 問題解決のプロセスには、まず「何が問題か（WHAT）」を明確にすることが基本であり、その後に課題の位置（WHERE）や発生原因（WHY）、そして具体的な対策（HOW）を検討する流れがあると学びました。 本質はどう捉える？ 普段、私は問題が起こるとすぐに「どのように対応するか（HOW）」を考えてしまいがちです。しかし、本質的な解決策を導くためには、まず問題自体を正確に捉えることが重要だと実感しました。その際、基本となる「比較」を行うことで、どの部分に大きなギャップがあるかを見極めやすくなります。 経営結果の謎は？ また、年次の経営結果を分析する際も、まず何が問題なのかを探ることが肝心です。例えば、利益が上がらない原因が売上の減少にあるのか、費用の増加によるものなのかを明確にし、どのカテゴリー、どの購買層、またはどの部門に起因しているのかを整理することが求められます。そして、その整理された課題に対してどのような対策を講じるかを段階的に考えていくことが大切です。 問いの作り方は？ 最も難しいと感じたのは、問題そのものを見つけ出すための適切な問いを立てることです。正確な問いがあれば、フレームワークに沿って段階的に解決策を導き出すイメージが湧きます。しかし、感度の高い問いが立てられなければ、効果的なロジックツリーを作成することも困難になります。今後は、この問いを立てるコツをより一層習得していきたいと感じました。

問題解決の基本ステップをどう活用する？ 問題解決について、「What・Where・Why・How」の段階があることを学びました。これらの段階は場合によっては行き来しながら課題の特定を進めるために用いられます。 定量的なギャップ分析を習慣化すべき？ 問題解決において、定量的なギャップを要素分解し、影響度の高い変数を特定する手法は、どのような案件にも通じるため、ぜひ習慣化していきたいと感じました。また、MECE（Mutually Exclusive, Collectively Exhaustive）に分解するためのフレームワークについても、既存のものを学ぶ必要があると考えています。 部門間の合意形成はどう進める？ 様々な部門の相談案件に対応する際には、まずどこにギャップがあるのかを明確にし、相手の合意を得たうえで進めることが重要です。そして、目の前の依頼内容の解決にとどまらず、その依頼が本質的な事業課題を要素分解した際にどれほどの影響度を持つのかを冷静に判断し、本当に解くべき課題の探索にも応用することが必要です。 「What」から考え始める理由とは？ 現状対応中の案件や新規案件に取り組む際には、「How」から入らず、まず立ち止まって「What」からステップを踏んで考えることが求められます。また、あるべき姿と現状とのギャップについては、依頼元としっかりとすり合わせ、共通認識のもとで仕事を進めることが大切だと感じました。

なぜグループにまとめ？ 仕事でお客様の会社において、事業部、部門、部署、チーム、そして個人といった多様な単位でヒアリングを実施しています。各単位で個別に課題を抽出し解決策を検討するというよりも、各々の課題をコーディングし、小グループとしてまとめる手法に取り組みました。その結果、企業全体のインサイトがより明確になったと感じています。同じ課題であっても、観る角度や背景が異なるため、捉え方に違いが生じることを実感しました。 どう問いを工夫する？ また、ヒアリングやアンケートで得られたキーワードや文章をコーディングする際には、自身の考えや先入観を持ち込まないよう注意しています。適切な問いの立て方が非常に重要で、オープンクエッションを用い「WHY」を投げかけることで、目先の要求だけでなく、根底にある不自由さや真の要求を引き出すことが可能となります。問いを設定する前に、事前調査や自身の体験を通じた共感を得ることで、相手の立場に立った一歩踏み込んだ質問ができると感じました。 なぜ共感が大切？ 事前調査や経験による共感、そしてその共感に基づく一歩踏み込んだ問い、さらにヒアリングやアンケート調査で得た定性的な結果のコーディングを通して、課題とインサイトを明確化するプロセスは、相互に連携して作用しています。深い共感があれば、より深い問いが実現し、結果としてユーザーや生活者の深層心理を引き出し、課題とインサイトの発見へと結び付くと実感しています。

Week1からの学びを総括 今週は振り返りの週ということで、改めてWeek1からの学びを総括しました。 まず、「データを理解し、深く分解すること」や、「相手に正確に伝えるアウトプットの重要性」、「イシューを特定し、それに対する適切な打ち手を考えること」を学びました。 トラブル解決で何を思い出す？ 私の業務は製薬会社の生産部門におけるトラブル解決を担当しています。そこで思い出すのは、以下の内容です。 まず、年間目標や業務ごとの課題解決についてです。これには、生産部門でのトラブルの原因究明とその解決策の立案が含まれます。目標の達成に向けてマイルストーンを設定し、各段階でイシューを特定し、対応策を考えることが重要です。 データ分析はどう生かす？ 次に、与えられるデータに対する考察についてです。多角的にデータを分析し、イシューを浮き彫りにする能力が求められます。この分析の過程で得られた洞察が、課題解決の手がかりとなります。 メンバー育成の視点で何が重要？ 最後に、部門のメンバーのキャリア開発と育成です。これも同様に、個々の成長を見据えたマイルストーン設定とイシューの特定が重要であり、その都度適切な指導やサポートを行うことが求められます。 今回の学びが示す未来 今回の学びを通じて、日々の業務においても適用できるアプローチが増え、より効果的なトラブル解決とチーム育成の実現が期待できると感じています。

根本原因はどう探る？ 問題や課題に直面した際、それらの背景や根本のイシューを特定することが最初に、そして非常に重要であるということを学びました。イシューの特定や設定には、立場や部門の違いから様々なアプローチが考えられ、必ずしもイシューが一つではなく、複数存在することもあるという理解が深まりました。 品質不具合の真実は？ 多く発生するのは品質の問題であると考えられます。社内での問題であれば、「なぜこの不具合が発生するのか」という視点でのイシュー特定が一般的ですが、逆の視点、「なぜこの不具合が顧客から受け入れられないのか」という視点でのイシュー設定も可能であるという新しい学びを活かしたいと考えています。具体的には、この不具合が直接取引の顧客でどのような問題となるのか、さらには最終ユーザーではどのような問題となるのかという視点を取り入れれば、品質責任の負担を平準化したり、過剰スペックを是正したりすることに繋がる可能性があると感じました。 会議で何を疑問視？ 週次で開催される品質会議では、不具合に関する品質部門からの分析内容やその是正に向けた対策について、自分自身が何か疑問を持つように意識することが重要です。「何が問題か」「どこで発生するのか」「なぜ発生するのか」といった基本的な把握に加え、問題や品質がなぜ顧客に受け入れられないのか、顧客でどのような問題に繋がるのかという視点を持つことから始めていきたいと考えています。

フレームワークを再考する？ 3C分析、SWOT分析、バリューチェーン分析という戦略の基本フレームワークについて、改めて学び直しました。もともと基礎知識はありましたが、それぞれの利用方法も含めてクリアな理解を得ることができました。 価値向上のポイントは？ 特にバリューチェーン分析では、これまでのビジネス経験から各局面で発揮される強みや価値、そして消費者に十分に伝わっていない部分に着目し、どのように価値を高めるか、あるいはコスト削減を進めるべきかを考える良いきっかけとなりました。 全社戦略の切り口は？ 全社のビジネス戦略立案においては、これまでも3C分析やSWOT分析が頻繁に使われてきましたが、バリューチェーン分析はあまり活用されていなかったため、今後はこれを起点として戦略立案を進めることを提案しようと考えています。 バックオフィスの挑戦は？ また、自部門の戦略立案では、バックオフィス部門という性質上、これらのフレームワークの利用が少ないものの、今年の夏から始まる来年度の戦略立案においては、3C分析とSWOT分析を活用していく予定です。 議論を深める方法は？ このように、3C分析、SWOT分析、バリューチェーン分析の3つのフレームワークは、今後の戦略立案やそれに関する議論において積極的に取り入れていき、実践を通して議論の焦点を明確にし、戦略的な視点でのディスカッションをリードできるよう努めます。

分析の意味は何？ 「分析は比較なり」という言葉は、普段何気なく耳にするものですが、今回改めてその意味を強く感じました。データ分析において、必要な情報を集めることに注力し過ぎるあまり、単にデータを並べただけで満足してしまい、見る人によっては分析結果の捉え方に差が生じる場面があったと実感しています。動画学習では、適切な比較対象を選ぶことの重要性にも触れ、データを揃える行為は無駄ではないものの、分析の目的や見せ方を意識しなければ本来の意味での分析にならないということを認識しました。 物流の選定はどう見直す？ この考え方は、物流部門における利用業者の選定や見直しにも応用できると感じます。たとえば、ある条件がある場合とない場合で、一律運賃が設定される荷主とそうでない荷主の運賃総額を比較する手法が考えられます。 大手と中小の差は？ また、単純に大手業者と中小業者を料金面で比較するのではなく、企業の規模や対応する配送範囲が同様である業者同士で運賃を比較することが、より適切な分析につながると理解しました。 比較対象の妥当性は？ さらに、自分が揃えたデータが本当に比較に適したものかどうか、常に振り返りを行うことが大切です。普段利用している輸送業者に注目し、過去の実績が明確な業者だけを比較対象にしている現状を見直し、新たな業者や新しい地区の業者も検討することで、より多角的な視点を持つことができると感じました。

提供価値はどう評価？ ビジネスの提供価値を評価する際は、まずその価値自体を見直し、次に利益やコストなどの数字を確認します。単に数値が高いか低いかだけで判断するのではなく、目指す価値に対してそれらの数字が妥当かどうか、どのような理由や根拠でその評価に至ったのかを、類似するビジネスと比較しながら検証することが大切です。また、目の前の結果だけでなく、将来的な展望も考慮し、日々の業務や行動の中でその視点を意識する必要があります。 ビジネス見直しの視点は？ 自分のビジネスや他部門、他社のビジネスを見直す際には、提供価値が何であるか、その価値が他に比べて優れているのか、またお客様に喜んでもらえるのかを常に考える癖をつけることが求められます。グループ内でディスカッションする際には、その価値がどのような点で優れているか、または改善すべき点がどこにあるのかを話し合います。 新商品検証はどう進む？ 新しい商品開発においては、初期段階だけでなく各段階でその提供価値を振り返り、再検証することが重要です。コスト資料を確認する際も、他の資料と比較しながら、なぜ費用が高いのか低いのか自分なりの考えを持ち、それをメンバーに説明して納得を得る力を養います。報告や説明を行うときは、できるだけ数値を用いて具体的かつわかりやすい表現を心がけるとともに、商品コンセプトや提供価値に立ち戻って考える姿勢を保ち続けるようにしています。

グラフで何が見える？ 数字や表をそのまま眺めるのではなく、グラフ化することで「目に仕事をさせる」という考え方が印象的でした。数字を様々な角度から検証し、視覚的に捉えることで、普段は気づきにくい点が浮かび上がると感じました。また、MECEという概念についても、モレなくダブりなく分析するための具体的な手法（層別分解、変数分解、事象のプロセスでの分解）があることを学び、今後の分析において意識して活用していきたいと思いました。 現状把握のコツは？ 私は全社の事務部門において、業務プロセス上の課題を明確にし、改善策を提言・実行する役割を担っています。各種データから課題や問題点を抽出する際、今回学んだ分析手法を取り入れることで、より正確な状況把握ができると期待しています。また、メンバーからの意見をそのまま受け入れるのではなく、他の視点も取り入れながらクリティカル・シンキングを活かして問題点を見極める重要性を再認識しました。 多角的な視点は？ 日々の報告や相談を受ける際は、数字については多角的な分析ができているか、課題の洗い出しについてはMECEの観点で漏れがないかをひとつひとつ意識しています。必要に応じて分析の切り口を増やし、グラフ化するなど、手を動かしながら客観的に情報を整理しています。説明を行う際にも、これらの視点が十分に盛り込まれているかを確認し、分かりやすい内容を提供できるよう努めています。

ライブ授業から得た教訓は？ ライブ授業で取り上げられた「売上昨対2割減」に向き合う例題についての感想です。このようなオーソドックスな例題に対して、何を知りたいか、どのように仮説を立てるかを考える際、必要な情報を十分に洗い出すことができませんでした。また、適切なグラフを思い浮かべることもできず、ビジュアル化に苦慮しました。しかし、「やみくもに分析しない」「ストーリーを大事にする」という前提は常に意識しています。こうした困難に直面しないよう、フレームワークや論理的思考、分析のための関連情報について日々インプットを続け、実践に活かせるようにしておかなければなりません。 赤字解消に向けた第一歩は？ 現在、自部門が赤字という現実に直面しています。まずは実績を集計し、現場のメンバーにもヒアリングしながら情報を集め、自分なりの仮説を明確化することから始めます。そして、4つのステップで分析し、解決に向けて取り組んでいきます。フレームワークを活用し、経験や勘に頼らない形で、フラットに考えながら取り組むつもりです。 チームの協力で問題を解決？ 早急に解決が求められる問題のため、迅速に対策を講じます。データ集計の際は、自身の目で確認するだけでなく、メンバーの協力を得ながら多角的にデータを収集します。講座で学んだ内容をチーム内で共有し、部門の問題について関係者とともに仮説を立て、解決策を見つける努力を続けます。