(38ページ目)

実施

に関する学び

---

何故課題意識は必要？ 分析の目的や課題意識を明確にすることで、日常の業務だけでなく、普段目にする分析データについても「なぜ？」と考える習慣が身につきました。例えば、ニュース記事で医師不足が取り上げられる場合、その背後にある分析の意図や解決すべき課題を自分なりに考察するきっかけとなりました。 施策評価はどう？ また、業務で複数の施策を企画・実行する中で、効果を評価するための分析が重要だと感じています。中長期的な戦略の実行に際し、連続性のある施策を実施するためにも、小さな施策のブラッシュアップを繰り返す必要があると考えています。たとえば、アプリへのログインプロセスを細かく分解し、特に初回ログイン率の向上に向けた分析を進めています。 情報取得は万全？ さらに、戦略立案の段階から必要な情報やデータが適切に取得できているかを精査し、取得できていないデータにはタグ付けなどの対応を実施して、常に分析が可能な状態を作り上げています。同じ条件で定期的にログの確認やレポート作成を行う仕組みを整備することで、継続的な定点観測が可能になりました。

切り口の偏りは？ せっかくデータを作成しても、切り口が偏ると適切な分析ができない場合があります。そのため、まずは多くの切り口で検証し、仮に失敗しても恐れずに試みることが重要です。 視覚資料の活用は？ また、グラフなどの視覚資料を効果的に活用するとともに、全体の区切りや範囲に注意を払い、ダブりや漏れがないように全体像を俯瞰しながら、目的に沿って細かく分解する工夫が求められます。 目的と創意工夫は？ 目的を見失わずに、データを創意工夫して見せる姿勢も大切です。MECE（漏れなく、ダブりなく）を意識し、複数の切り口から分析を行い、その結果を分かりやすく伝えることを心掛けましょう。職場の意見を反映する際も、偏った分析にならないよう真の原因を追求することが必要です。 アンケートの目的は？ 今後、職場環境の改善を進めるためにアンケートを実施する際は、まず目的を明確にし、事務局の方向性と従業員の意見のギャップを把握することが基本となります。さまざまな視点から課題を検証し、その分析結果を分かりやすく報告する工夫を重ねていきたいと考えています。

データ検証の意味は？ データを検証し、仮説を立てた上で再びデータを確認する―リスクを抑えながら新たな可能性を模索する問題解決のプロセスについて学びました。その中で、A/Bテストの活用についても知ることができました。 実践規模の見極めは？ 仕事に活かす方法として、プロセスをどの規模で実施するかが、データ抽出の視点や意思決定の重要度によって左右される点に気付かされました。企業の規模によっては、実行が難しい場合も出てくると感じました。 チームでの一歩は？ そこでまずは、自分のチーム内で進められる範囲から取り組んでみようと思いました。 チーム育成のポイントは？ チーム内での人材育成プロセスに、データの検証と仮説の立案を取り入れ、今後の計画に反映させたいと考えています。近年、チームメンバーとなる人の出身部署が多様化しているため、前提となる知識やその特性にも違いが出ていると感じます。これにより、それぞれの出身部署や知識の有無を的確に把握し、最終的には一人前のチームメンバーとして成長するプロセスを、より効率的に進めたいと思います。

原因分析はどう進める？ 原因の分析にあたっては、まずプロセスごとに分解し、確認することが大切だと感じました。特に「what／where／why／how」を意識し、まず「where」から入念に分析することで、その後の「why」や「how」の解像度が高まると理解しています。 A/Bテストってどうやる？ また、A/Bテストが有効な手法であることを学びました。その際、検証する「要素」は極力少なくし、その他の条件は共通とすることで、スコープを狭めることが重要だと感じました。実際にアプリ上でプッシュ通知とバナーを用いたA/Bテストを実施した経験から、振り返ると「キーメッセージ」に差が生じてしまった点が課題として残りました。 ログイン改善は何が？ さらに、アプリのログイン率向上を図るため、ログインに至るフローを細かく分解し、原因の追究を行いたいと考えています。特に、パスワード設定の箇所で離脱するユーザーが多いという仮説に基づき、検証からスタートする予定です。その後の改善策として、ユーザーインタビューやUIテストの実施を検討しています。

導入の不安は何？ AIなどの新しい技術を自社の業務に導入する際、最適な方法が明確でないことが多く、適当な仮説に頼るだけではユーザーのニーズを十分に捉えられず、導入がうまくいかない事例があると感じました。観察やインタビューを行い、ユーザーが直面している本当の課題を定義することが、根拠に基づいた施策の展開につながるのではないでしょうか。 事前準備は十分？ ただし、観察やインタビューを最初に実施する際、聞く内容があらかじめ決まっていないと十分な情報が得られないのではないか、という懸念もあります。一方で、こちらが求める回答にユーザーを誘導してしまう危険性もあるため、フラットな立場でユーザーの本音を引き出し、客観的に分析するプロセスが不可欠だと考えます。 ユーザー視点は大事？ 特に、共感を基盤とした課題定義の段階では、ユーザー中心の視点が非常に重要です。業務においては、新しい技術やソリューション自体に焦点が当たり、答えあたりの議論に陥りがちですが、常に解決すべきはユーザーの本質的な課題であることを念頭に置き、施策の検討を進めたいと思います。

キャリア分類ってどうする？ 「キャリア・アンカー」という考え方があります。これは、キャリアを8つのタイプに分類する手法で、私も実際に試してみたところ「専門家・職人タイプ」に分類されました。私が自己満足を重視しがちなため、納得のいく結果でした。この手法は手軽に実施できるため、他の方にもぜひ勧めたいです。 ギャップはどう縮める？ キャリア・アンカーを通じて、「やりたいこと」と「実際にやっていること」、そして「仕事の進め方」の間に違いがあると、モチベーションが低下し、成果も上がりにくくなります。このギャップを埋めることができれば理想的です。また、ゲイルの仕事観や価値観についても見直す機会になるので、学んだ内容をメンバーと共有したいと考えました。 メンバー理解はどう？ まずは、キャリア・アンカーをメンバーにも勧めてみる予定です。メンバーのキャリア志向が明らかになることで、それぞれのモチベーションが高まり、仕事の割り振りにも役立ち、成果にも影響すると考えています。最終的には、相手を理解するためには対話が欠かせないと感じています。

進行中の問題は何？ プロジェクトの進行において問題が発生した場合、まずはプロセスをできるだけ詳細に分解し、ボトルネックを見つけ出すことで原因を明確にし、解決策の糸口を探していきたいと考えています。 複数原因はどう整理？ 一方で、原因が複数存在する場合には、さまざまな対策案を検討する必要があります。実際の業務ではA/Bテストの実施が少ないかもしれませんが、実施する際には1要素ずつ、できる限り条件を揃えて行うことを心掛けたいと思います。 全体像はどう掴む？ また、問題の原因を探索する際には、プロセスを細かく分けることでボトルネックに注目し、問題の全体像を把握するよう努めます。 評価基準は納得？ さらに、解決策を検討する場合は、適切な判断基準を設定した上で各案の評価を行います。その際、判断基準の重要性や重み付けについても十分に考慮しながら進めることが重要だと考えています。 A/Bテストはどう実施？ A/Bテストについては、条件を一致させた上で1要素ずつ実施するようにし、比較が効果的に行えるよう留意していきたいと思います。

今の問いの意味は？ イシューとは、今ここで答えを出すべき問いのことであり、問いが何であるかを常に意識し、組織全体でその方向性を共有できるよう努める必要があります。 具体化はどう行う？ イシューの特定は、問いを具体的な形に落とし込み、一貫して保持することが基本です。また、ピラミッド・ストラクチャーを用いる場合、まずイシューを明確にしてから、論理の枠組みを考え、主張を適切な根拠で支えるというステップが不可欠です。 問題と対応策は？ 担当プロジェクトで問題が発生した際には、まずイシューを特定し、その問題に対してぶれず対応策を検討したいと考えています。同様に、事業計画の立案時にも、目標実現に向けた問題点を洗い出し、解決策を提示する上で非常に効果的だと思います。 納得できる資料は？ さらに、問題点を徹底的に洗い出し、要素分解や数値分析を実施することで、相手が納得しやすい見やすい資料を作成することが重要です。また、部下や上司、顧客との打ち合わせの際には、目的である問いを明確にし、議論がぶれないよう意識することが大切だと感じています。

経営視点の重要性は？ 大局的な視点で物事を見ること、そして経営者の視点で考えることが非常に重要であると学びました。どうしても自部署の視点に偏りがちですが、最終的な決裁は上長から経営者に至るため、彼らに納得してもらえる結論を導くことが必要です。そのため、短期的なゴールにとどまらず、それが会社全体にどのように貢献するのかを明確に文字にしたいと思います。 意見をどう取り入れる？ また、他人の意見を積極的に取り入れることを意識しています。個人での業務が多いのですが、全社に影響を及ぼす可能性が高いため、計画段階から自分以外の視点を追加するよう努めたいと思います。特に競合分析については現場のメンバーがより詳しく見えている場合が多いため、一緒に計画を立てる方法で進めていきたいと考えています。 計画はどう整える？ 実際の教育計画において、情報や意見を集める機会を設けたいと思います。さらに、社長や経営層からも意見を聞く場を作り、計画におけるずれがないか確認することで、計画の完成度を高め、実施の際には協力を得られるようにしたいと考えています。

財務諸表の役割はどうなってる？ 財務諸表は、事業の状況を定量的に把握するための重要な資料です。基本的な３種類には、P/L（ある期間の収益や利益の状況を表す）、B/S（事業運営に必要な資金の調達方法と使用用途を示す）、C/S（一定期間におけるキャッシュの増減を明らかにする）があり、それぞれ異なる視点から事業の健全性を測ることができます。 プロジェクトの試算はどうする？ 現在取り組んでいるプロジェクトにおいては、これらの財務諸表を分析し、将来のシミュレーションを実施できるようになりたいと考えています。現状では上司が試算を行ってくださっているため、今後は自分自身で実施できるようになることを目標としています。 競合比較で見えてくるのは？ また、競合との比較を通して自社の資金運用や収益の仕組みを明らかにすることも大切だと感じています。担当プロジェクトでは、競合や自社の状況を分析する際に、グループメンバーに任せるのではなく、自ら積極的に手を挙げる姿勢を持ち、業務時間の確保のためにその他の業務も先回りして段取りを整えるよう努めています。

今のプロセスは最適？ 現状への最適解を追求することの重要性を再認識しました。現在の業務は多くがプロセス化され、一定の手順に従って進められていますが、その一方でプロセス化によるオーバーヘッドが生じていることも改めて感じています。常に「今の対応が本当に最適なのか」という疑問を持ち、業務の見直しを図ることが大切だと考えています。 手順は見直す？ これまでの問題への対応として、手順を確立し日常のオペレーションに組み込んでいます。しかし、定期的なプロセスの見直しやメンバーからのフィードバックを受け、各プロセスの必要性や効率を再評価するよう意識を変える必要があると感じています。 自問自答してる？ まずは以下の点について自問自答してみたいと思います。 ・そもそもなぜそのプロセスが必要になったのか、当時の背景を十分に理解する ・現在の状況が当時とは異なる場合、対応すべき最適解が変わる可能性があるため、現状の必要性を検討する ・プロセスで実施している作業を、他のツールやソフトウェアなどの手段で代替できないかを検討する

問いとは何だろう？ 今週は「問い・イシュー」を学び、これまで学んだことの総合演習を実施しました。イシューとは、今ここで答えを出すべき問いであり、長期的な課題解決のためには用いません。また、イシューを設定しないと論点がずれやすくなるため、常に意識し一貫して押さえ続けることが大切だと実感しました。 会議は何を促す？ 会議では「今日のゴール」を設定し、議事録の一番上に書いて全員で共有しました。その結果、イシューや目的が何であったかを改めて意識でき、各参加者のイシューがずれることなく進められたと感じました。今後もこの方法を継続していきたいと思います。 メモはどう活かす？ また、会議の議事録だけでなく、誰かに見せるためではなく自分用のメモにもこの考え方を応用したいと考えています。過去には、目的と手段が入れ替わっていると言われることがありましたが、イシューを明確に設定していなかったため、そうした指摘にピンとこなかった経験があります。今後はまず問いを立て、何がイシューなのかを念頭に置いた一貫性のある思考を心がけたいです。