(3ページ目)

作成 ✕ システム

に関する学び

---

データ分析の手法とは？ データを見る際には、単に与えられた数字を眺めるだけでなく、自らデータに触れて比率などの必要な情報を引き出し、グラフ化することで、複数の視点から分析することが重要です。こうしたアプローチにより、データを多角的に捉えることができます。 MECEで現状を把握するには？ データを分解する際は、MECE（Mutually Exclusive and Collectively Exhaustive）を意識することが大切です。同じ内容を繰り返すことなく、全体を漏れなくカバーすることで、現状を正確に把握できます。 具体的な分析の例は？ システムや業務の分析では、具体的な例として航空券の購入フローや空港での搭乗フロー、整備フローなどを分解して考えることが挙げられます。また、売り上げ分析では、路線別や年齢別、搭乗回数別に分解してみることも効果的です。 業務に応用できるか？ これらの手法は日常業務でも活用可能です。例えば、システム障害発生時の対応やアクセス数のデータ分析、WEBサイトへの攻撃分析といった場面でも役立ちます。 テンプレート活用の効果は？ さらに、切り口のテンプレートを作成すると便利です。例としては、航空券購入から搭乗後までのプロセスを旅客の視点や業務の視点で分類することが考えられます。また、研修アンケートの分析にもこの方法を応用できます。受講前には思いもよらなかった角度からデータを切り分け、Tableauといったツールの活用も視野に入れると良いでしょう。 新たな視点が発見を生む？ 日常業務においては、失敗を恐れずにデータを分解し、新たな視点で見ることがスタート地点です。こうした姿勢が新たな発見につながります。

問いの大切さは？ 「問いから始める」という考え方が非常に印象に残りました。問いが何なのかを常に意識し、具体的な問いにまで落とし込むことが重要だと感じました。また、「問いを残す」ということは、問いを持ち続けることや自分が何を考えているのかを絶えず問いかけることであり、それにより、立てた問いが正しいのか、その問いに答えることで目標が達成できるのかを確認し続けたいと思います。さらに、問いを立てた後は「問いを共有する」ことが不可欠です。組織全体で方向性を共有しなければ、自分が解決しようとしている問題に取り組むことは困難になるため、問いの共有を常に心がけたいです。 工場問題の原因は？ 現在、私たちの会社は世界各国に5つの工場を持っており、お客様が希望するタイミングでの供給が困難になるケースが頻繁に発生しています。この問題の原因を詳しく分析する必要があります。考えられる切り口としては、工場のオペレーションに課題があるのか、あるいはシステムの受発注の仕組みに問題があるのかなどが考えられます。この分析を通じて、現状の問題点を明確にし、対策を検討していきたいと思います。 目標達成の方法は？ そのために目指すべきゴールと具体的方法、そしてその手段を実行することによって得られる価値についてしっかりと考えたいと考えています。検討した結果に基づいて資料を作成し、仮説を証明するための理由については、視覚的に分かりやすく示すように工夫したいです。この目的を達成するために必要なデータは何か、どのように分析すべきかを考慮しながら、自分の考えや実施したい施策について毎週の部内会議でチームメンバーと共有していきます。

カフェで価値守れてる？ アカウンティング研修の第1週目では、P/L（損益計算書）を題材に、カフェ経営のケーススタディを通して「利益を生み出すためには、店としてどのような価値を提供するか」が重要であると学びました。特に、高級志向のカフェが原価低減を図るために安価な豆を使用しようとしたが、結果的に店のコンセプトが損なわれ、顧客に支持されなくなる可能性があるという事例が印象に残りました。単に売上から原価を引いた数値だけで判断するのではなく、「価値を守ることが利益に直結する」という視点の重要性を実感しました。 IT提案で本当に伝わる？ この学びは、私が関わるITシステムの提案やプロジェクト企画にも活かせると感じています。たとえば、顧客に単にコスト削減を訴えるのではなく、その企業のビジョンや利用者のニーズに合致した価値を明示し、費用対効果の高い提案を行うことが大切です。そのため、今後は提案書の作成時に「この機能は誰のためで、どのような価値を提供するのか」を意識し、価格や納期だけでなく、価値提供を軸にした提案を心がけていきます。 価値、どう数量化する？ 一方で、「価値を守ることが利益につながる」とはいえ、その“価値”をいかに定量的に測定するかについて疑問も感じました。ITプロジェクトでは、顧客の要求に応えるために機能の取捨選択が求められ、何を守るべき価値とするかの判断が難しいと感じています。他の受講生にも「価値」と「利益」のバランスについて、実際の経験をもとに意見を交換し、定量評価が難しい価値をどのようにマネジメントに反映するかを議論してみたいと考えています。

講義から何を学んだ？ 本講義は、あらゆる業務に共通する重要なワークが凝縮されており、準備万端な状態を目指すために必ず押さえておくべき内容だと実感しました。特に、「トップダウンによる理由付け」「共通言語の活用」、そして「客観性を担保する支える柱の存在」が大きな学びとなりました。論理的思考のプロセスを理解し、これらの支える柱がどのような視点で存在しているのかを意識する習慣を身につけていきたいと考えています。 情報整理はどう進む？ 社内ではセールスフォースを導入していますが、情報が各所に散在しているため、管理者がそれらを整理し、発信者と同じ立場で情報共有するのに多くのリソースが必要となっています。また、営業現場で発生するリアルタイムの問題（顕在化）や、問題に発展するリスク（潜在化）が十分に把握できていないため、対応が後手に回るケースが見受けられます。こうした現状に対しては、システムツールの有効活用を通じて、業務改善を図ることが求められると考えています。そのため、主語と述語の明確化、適切な言語選択、そしてピラミッド構造を用いた概念整理や根拠付けを意識しながら、情報発信に努めています。 AI依存は安心か？ また、全社への情報発信や取引先向けのメール作成に際しては、自身で作成した文章を一度AIに添削してもらうようにしています。これは、自分一人では見落としがある場合や、時間短縮を図るためです。しかし、最新技術に依存している現状については、今後業務のクオリティが維持できなくなるのではないかという不安も感じています。

クリティカルシンキングの活用場面は？ クリティカルシンキングは、課題解決や上司への提案、説得など多くの場面で活用できる思考法であることを理解しました。特に課題解決の場面では、自分の経験や勘に頼らず、関係する様々な人の立場から課題を見ることで、その本質を探り、より良い解決策を提案できると感じました。ライブ授業の「病院」をテーマにした課題では、病院に関わる人々の視点を変えることで、病院の役割について多様な考え方ができることに気づきました。また、他の受講生から自分にはない視点を学ぶことで、クリティカルシンキングの重要性を再認識しました。 システム要件定義への応用法は？ 現在、私は生命保険契約の電子手続き化に関するシステム要件定義作成に関わっており、部下が提案するシステム機能が本当に必要かどうか、管理職として判断を迫られることがあります。今回学んだことを活かし、視点や視座を広げ、顧客・営業・開発者・経営者の目線で機能のメリットとデメリットを考慮することが、より良い判断に繋がると実感しています。 どのように優先順位を考える？ 具体的には、部下から提案されたシステム機能の開発要否について、多角的にメリット・デメリットを洗い出し、優先順位を決めていきたいと思います。例えば、顧客目線では便利でも、実際の利用者が少なく費用がかさむ場合は、費用対効果を考慮して開発を見送るといった判断を意識して行っていきます。最終的に、部下や上司に対してなぜその判断をしたのかを説明する際、説得力のある説明ができると考えています。

発注とユーザーの違いは？ ITシステムの外部委託先の立場から考えると、システム開発を進める際、お客様はエンドユーザーというよりも、顧客企業の担当部門として対応することが多いです。担当部門はユーザーと異なる視点を持つため、今回学んだエンドユーザーの立場よりも、発注者の意向に注力せざるを得ません。しかし、発注者との共感、課題の理解、試作品の作成といったプロセスは十分に実現可能です。真にエンドユーザーに役立つものを提供するのは難しいものの、発注者の満足を追求する姿勢が重要だと感じています。 満足の不一致はどう？ 一方で、発注者の満足を追求できたとしても、発注者がエンドユーザーに目を向けなければ、エンドユーザーの満足と発注者の満足は一致しなくなります。このような複雑な階層構造を持つ大規模な組織では、デザイン思考を一部の人だけが理解していても、途中のプロセスでその意義が薄れてしまうため、広く多くの人に理解してもらうことが必要だと考えました。 試作品の使い分けは？ また、プロトタイプの作成方法によって検証できる項目は異なるため、一つのプロトタイプが最適かどうかを問うよりも、各プロトタイプの特性を活かして使い分け、互いに補完していくことが重要です。さらに、組織階層が深い大規模な組織では、開発過程に関わるすべての人がデザイン思考の考え方を身につける必要があると感じました。加えて、生成AIを発注者役として活用し、想定問答を行う手法も有用であると実感したため、今後も積極的に取り入れていきたいと思います。

営業実績の見える化の秘訣は？ 部内で営業実績を可視化するシステムを構築する際、ビジネス側がシステム設計を確認する中で、ベンダーさんがしっかりと手順を踏んで進めていたことを改めて知りました。システム構築は何となく進めていたものですが、今回の経験で、体系的に学ぶことの大切さを実感しました。 コンテンツ設計の極意は？ また、社内で公開するSharePointのページを作る際に、いきなり制作に取り掛かるのではなく、無意識のうちに行っていたコンテンツ設計の重要性に気づきました。当時は自分一人で資料上で並び替えなどを試行錯誤して使いやすい表示方法を模索していましたが、次回はチームメンバーやユーザーに評価を仰いだうえで、実際の作成に移ろうと考えています。 ユーザー受入の意義は？ システム構築の過程で、ユーザー受入テスト（UAT）も単なる操作性の確認に留めず、実際のユーザーが何を実現したいのかを意識し、情報の配置や表現方法をしっかりと検証することの大切さを改めて感じました。 試作品作りの秘訣は？ 普段は試作品を依頼する立場ですが、試作品を作る前の要件定義を十分に行うことで、より精度の高い試作品が生み出され、そこからさらにアイデアを加えてブラッシュアップできると実感しています。情報設計、UI設計、ユーザビリティ設計、アクセシビリティ設計を進めるにあたっては、ターゲットを明確に設定することが非常に重要だと感じました。

ライブ授業で得た気づきとは？ ライブ授業の実習を通じて、自分の思考にバイアスがかかっていることを実感したため、物事を深掘りすることの重要性を改めて感じました。MECE（Mutually Exclusive, Collectively Exhaustive）やロジックツリーといった手法を学び、それを自分のものとして使いこなせるようになることで、より深く物事を考え振り返る行動につなげることができると考えています。 提案資料にどう活用する？ 社内システムの担当として、ITを駆使し事業課題を解決するシステムの企画や立案を行う際には、一度自分の考えを止めて客観的な視点を取り入れ、提案資料にその考えを反映させるよう努めています。そうすることで、より説得力のある資料を作成できるのではないかと考えています。また、部下との評価面談では、クリティカルシンキングを活用して部下の考えを引き出し、自分の意見も効果的に伝えることができると思っています。 判断を支える習慣とは？ 自身で何らかの判断を行う際には、なぜその判断に至ったのか自問する習慣を身につけることが重要です。その問いかけをロジックツリーなどに書き起こして思考を整理します。これを実践するために、PCの付箋アプリにこれらの行動を記載して常に視界に入れるようにし、ロジックツリーなどで思考を整理するためのメモ用紙を常に手元に置いて実践していきたいと考えています。

資料の本質は？ これまでのスライド作りを振り返ると、見た目のインパクトを重視するあまり、内容が堅実に伝わらないことがあったと感じています。今回の学びを通じて、まず「この資料で何を伝えたいのか」という本質を整理し、そのメッセージを明確にすることが大切だと再認識しました。グラフやその他の視覚要素は、伝えたい内容を補完するツールとして活用すべきだと考えています。 機能の必要性は？ システムの新機能開発に関する資料作成の場合も、いきなり詳細な仕様に入るのではなく、まずこの機能がなぜ必要なのか、顧客が何を求めているのかを整理するところから始めるべきだと感じました。例えば、現在手作業で工数がかかっていることを視覚的に示すことで、メンバー全員が共通の課題とゴールを認識でき、アイディア出しや改善に繋がる良いスタートになると思います。 管理方法はどうする？ また、資料作成だけでなく、作成した資料をどのように管理するかにも悩みを抱えています。プレゼンテーション資料に限らず、全てのドキュメントについて、修正履歴が重なったり、最新版がどれなのか、誰がどこに保管しているのかが明確でない場合が多いです。アップロード先で検索しても、タイトルに【改定版】や【最新版】といった統一性がなく、どの資料を参照すればよいのか判断しにくい状況にあります。管理方法について、どなたか工夫されている点があれば知りたいです。

不確実性はどこに？ 試作の方法によって得られるフィードバックの性質が異なる点は非常に重要だと感じました。どの試作を採用するかという議論に陥りがちですが、その前にまず、どの部分に不確実性があるのかを明確にし、その不確実性を早期に確認するために、どの試作をどの順序で使うべきかを検討する必要があると思います。 AI導入は効果的？ また、AIを活用してWebアプリのプロトタイプを作成したところ、パワーポイントの説明資料以上に多くの反応をもらうことができました。以前は、静的HTMLのプロトタイプを作るだけでも1ヶ月程度かかり、動的に変化するシステムではさらに長い期間が必要でした。しかし、AIの導入により、1日から数日でプロトタイプを完成させることが可能となりました。得られるフィードバックの質や量の面からも、AIを活用したシステムのプロトタイプ作成は不可欠だと実感しました。 次回の方向性は？ 現在進行中のプロジェクトでは、人力でプロトタイプを作成していますが、個人的にもAIを活用してプロトタイプを作る検討を進めています。まだ途中段階ではありますが、現状のAI技術でどこまで要件を反映したプロトタイプが作成できるのかを確認し、十分な要件が盛り込めることが確認できれば、次回以降のプロジェクトではAIを前提としたアプローチを採用したいと考えています。

緻密な準備が成功を導く？ 慎重になり過ぎず、頭でっかちになり過ぎないことが大切です。手を動かす前に仮説を立て、何を比較するかの指標を決める必要があります。ただし、やってみないと分からないこともあり、その際には柔軟に変更しても問題ありません。 有効な切り口を探る方法は？ 引き出しの多さと選球眼が求められます。専門知識が少ない領域では、まずはフレームワークに頼るとよいでしょう。専門知識がある領域にフレームワークを掛け合わせることで、発見が生まれます。筋のよい切り口を選択するためには、現場の肌感覚としてのドメイン知識が重要です。 例えば、webサイトからの問い合わせを増やすための分析が必要な場合、データはすべて手元にあるので実践可能です。流入経路、案件種別、問合せ企業の業種、企業の所在地、案件規模、実施月、実施までの期間など、指標となり得る項目が多数あります。これらの指標を基に、問い合わせ数との相関関係を探ることで、有効な分析が可能となります。 仮説とフレームワークの活用 システムの切り替えに伴うベンダー選定や資料作成、現場からの業務要件整理とRFP作成などの業務においても、フレームワークや仮説の立て方が活用できることを実感しています。これらの方法は、実務において有用であり、実際に業務を進める上での基盤となります。

数年後の実装はどう？ 私が想像していた「数年後の使い方」がすでに実装段階にあると実感しました。一方、社内情報を取り扱える生成AIはセキュリティの関係から、資料作成レベルのアウトプットには至らない状況です。そのため、どこまでAIと協力して業務を進められるのかを考える必要性を感じました。 需給と包装の課題は？ 動画内で紹介されていた需給予測の活用は、使用期限が短い食品業界にとって非常に意義深いと思います。また、包装という業務に絞った場合、配送効率の向上など、AIの効果的な利用が期待できると感じました。運送の効率化は国家レベルで急務となっており、一定規模以上のメーカーにとって、パレットやコンテナ単位での積載効率を上げる取り組みは喫緊の課題です。商品のサイズや荷姿の制約を考慮して最適な製品形状を導き出す機能は、AIによる簡略化が可能であり、社内システムに組み込むことで非常に有用になると考えています。 生成AIの導入は？ また、業務に活用しやすい生成AIについても興味を持っています。現状は社内情報に対応できるソフトが限られていますが、情報システム部門からは順次拡充される予定とのことです。具体的にどのような生成AIが導入されれば業務効率化に寄与するのか、実務で利用されている方々の意見をお伺いしたいです。