(34ページ目)

開発

に関する学び

---

3CやSWOTをどう活かす？ 3C、SWOT、バリューチェーンの3つの方法について学びました。各用語の意味は理解できたものの、実際の業務への適用となると難しさを感じました。特に3Cでは、自分自身と相手をしっかり把握し、そこからゴールへの最速・最短の道筋を導き出すことが重要だと感じました。また、SWOTとバリューチェーンを組み合わせることで、より広い視野で現状を考察する意識が芽生えました。 競合対策はどう進める？ 対競合の観点からは、製品の作り方や工程を見直し、自社の強みと弱みを徹底的に分析する必要性を実感しました。さらに、試作や開発の段階から製造の視点を取り入れ、開発部署と密に連携することで、量産開始後のトラブルを減らせる体制づくりが不可欠だと考えます。こうした取り組みによって、プロジェクトの最速・最短なゴール達成を実現していきたいと思います。

定石をどう捉える？ ビジネスの定石を正しく理解し活用することの大切さが印象に残りました。漠然とした知識だけで判断してしまわず、本質をしっかりと捉える姿勢が必要だと感じています。 適切な打ち手は？ また、単に総生産数を増やすだけでは規模の経済が働くかどうかは不明であり、自社の状況に合わせた適切な打ち手を検討する必要があるという点も重要だと思いました。 大数字の罠は？ 技術開発提案書を作成する際、年間や生涯の生産数といった大きな数字を用いていましたが、規模の不経済が生じていないか、また工場の生産状況を踏まえた上で、より効果的な施策を考える必要性を強く感じます。 情報の真偽は？ さらに、範囲の経済性などの要素も十分に考慮し、単なる定石に頼るのではなく、部分的な情報だけに流されずに事実の本質を見極めることが求められていると実感しました。

既存製品はどう変わる？ デジタル社会でビジネスを考える際、既存の製品にセンサーやネットワークなどの要素を加えることで、新たな価値や体験が生み出されることが分かりました。しかし、「＋何か」を検討するアイデアには限界があり、生成AIは膨大なデータから多様なアイデアを提示してくれます。人が考える方向性と生成AIが出す提案を上手く組み合わせることが、成功のポイントと感じています。 生成AIとの相性は？ 私はソフトウエア開発に従事しており、プログラミングは文章のような性質があるため、生成AIとの相性は非常に良いと考えています。これまでは手作業でコードを入力してプログラムを作成してきましたが、今後は生成AIによるコード作成やリファクタリング、テストコードの生成といった手間のかかる作業を取り入れることで、生産性向上や品質改善に挑戦していきたいと思います。

A/Bテストはどう活かす？ A/Bテストの手法を学ぶ中で、基準を揃えた上で複数のパターンを試し、比較検証することの重要性を実感しました。また、A/Bテストに限らず、比較を行う際には条件を同一にすることが必要であると感じています。 仮説検証はどう進める？ 仮説検証については、小さなサイクルを繰り返すことが効果的だと考えています。月次実績を追いながら、仮説検証を実施し、特に割合の比較を日々の業務に取り入れることで、より正確な分析が可能になると認識しています。 UI/UXはどう評価する？ さらに、アプリケーション開発に携わる立場から、UI/UXの検討においてもA/Bテストの手法を積極的に活用していきたいと思います。現業務で実際に数値をもとに比較を行っている経験を踏まえ、今後も引き続きこのアプローチを継続し、業務改善に生かしていく所存です。

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

体験価値はどう評価？ 製品そのものだけでなく、その製品に至るプロセス全体を体験として提供することにより、新たな価値を生み出す可能性があると感じました。自社製品を購入してもらうためには、通常、より優れた品質や他社より低価格という点が重視されがちです。しかし、これまでにない体験という付加価値を提供することで、価格競争に陥ることなく、独自の魅力を持たせることができると思います。 オンリーワンってどう捉える？ また、値上げの方法として「オンリーワン」であるという考え方の重要性も強く印象に残りました。製品開発の段階で、たとえ一つの特徴でも他社にはない独自の魅力があれば、比較対象になった際に価格競争を避けることが可能です。そのため、企画の初期段階からどの部分を強みとするのかを十分に検討しながら開発を進めることが必要だと感じました。

データ分解で何がわかる？ 整理されていないデータに少しずつ情報が追加されるワークを通じ、さまざまな観点からデータを分解する方法を学びました。特に、物事をMECEの考え方に基づいて漏れなく分解することで、より正確な結論に近づける点が印象的でした。手を動かしながら作業を進めることで、仮説に固執せず、たとえすぐに明確な傾向が見えてこなくても有用な情報が得られると実感しました。 業務での応用はどう？ 通常の業務では、同じような分析方法を経験や勘で対応していましたが、新しいジャンルのデータではアプローチが難しく感じることもありました。直近では事業開発のテーマに対して、今回学んだMECEに基づく分解の考え方を応用し、印象や感覚に頼らず複数の切り口から要素を漏れなく分解できているかを意識しながら業務に取り入れていきたいと考えています。

他者意見の学びは？ これまでのグループワークを通して、さまざまな方の意見に触れる機会がありました。今回のテストでは、また違った視点からのフィードバックを得ることができ、他者の視点がとても貴重であると実感しました。 サービス企画の一歩は？ 普段の業務では、新しいサービスを企画する際に、プレマーケティングとして信頼関係のあるお客様に紹介し、フィードバックを収集する機会を設けています。このプロセスは、まさにデザイン思考のテストフェーズそのものだと感じました。 デザイン思考の活用は？ また、これまで深く意識していなかったデザイン思考が、実際には日々の業務に広く活用されていることに気づかされました。今後は、サービス開発だけでなく、社内での合意形成やプロジェクト推進など、その他の業務にも積極的に応用していきたいと思います。

ユーザー体験はどう感じる？ 金融機関で個人株主向けのサービス開発に携わる中、金融機関であるがゆえに自分自身で個別銘柄の株を購入できず、ユーザーとしての体験がなかなか得られない状況です。一方、投資信託は購入可能ですが、商品が多岐にわたるため、ある程度ユーザーターゲットを絞る必要があると感じました。 夢中になる理由は？ また、業務から離れて、自分が真に夢中になれることを事業化するシナリオを考えると、デザイン思考の本質により迫れるように思います。現在の業務ではユーザー体験を得にくいため、一言で言えば「とことんユーザーになる」ことが大切です。そして、チームは多様な専門性を持つ少人数体制が理想的だと考えます。こうした視点は、現職での取り組みとは対極に位置しており、職場でのデザイン思考活用には伸び代が限られていると感じました。

なぜ目標の方向が変わった？ WEEK1の時点では、「担当事業の成功のための顧客理解に役立てたい」といったありたい姿を記していました。しかし、実際には講座が進むにつれ、より抽象的にサービス全体での展開を考えるようになり、顧客そのものの理解よりも商品を起点とした話が多くなったと感じます。 どんな成果が得られた？ また、事業部長への「2030年までのサービス展開計画」の場で、今回学んだ内容がすぐに活かされました。上長からは「技術面で2年分の機能開発計画が出ているので、その先の3年間分のアイデアを出してほしい」という指示を受け、当初は自分自身でも3年間延長する機能のロードマップを考えていました。最終的には、講座での学びを活かして3年分の新機能を提案し、サービスの構造化と別領域への展開案として報告することができました。

名称変更が与える影響は？ 今回の学習では、新商品の普及に寄与する5つの要素―比較優位、適合性、わかりやすさ、試用可能性、可視性―に焦点を当てました。特に、商品の名称変更が消費者の連想や期待にどのような影響を及ぼすかを事例を通して学びました。同じ商品でも、ネーミング次第で消費者が抱くイメージが変わり、結果として売上に差が生じる可能性がある点が示され、顧客ニーズやターゲットセグメントの分析の重要性を実感しました。 顧客ニーズの真実は？ 自社製品においても、現在顧客ニーズの調査を開始した段階です。自分たちが想定している商品仕様が実際の需要とどの程度合致しているのか、また顧客が期待する機能と価格のバランスについて検証中です。今後は、顧客訪問やヒアリングを通じて、より具体的な情報を収集し、製品開発に反映させていく予定です。

他者視点で見直す？ 自分で導き出した結論や回答について、常に他者や別の立場からの視点で再検討することで、これまで気づかなかった発見や新たな答えを得られると感じました。また、その回答に至る重要なポイントを、漏れなくかつ重複なく整理することで、根拠や納得感をしっかりと説明できるようになりました。 両面の視点はどう考える？ 今回学んだ点としては、部下との目標管理面談や評価面談において、一方的な上司の視点ではなく、部下の立場に立った思考で臨むことで、円滑なコミュニケーションが築けると実感しています。さらに、システム開発においては、お客様との要件定義や調整の場で、開発側だけの視点に偏らず、システムを利用する側の視点に立ってコミュニケーションを行うことで、より使いやすく、質の高いシステムの開発につなげられると考えています。