(12ページ目)

自分 ✕ 開発

に関する学び

---

イシューはどう捉える？ 今週は、「今答えを出すべき問い＝イシュー」の特定がいかに重要かという点について学びました。実際の事例をもとに、「なぜ？」「どうすれば？」と経営者の視点でロールプレイを行いながら検討することで、実際に取られた施策の意外な点にも触れ、論点を見極めることの大切さと、その問いを最後まで押さえ続けることで分析の方向性を見失わずに発想が広がるという実感を得ることができました。 新規開発はどう整理？ また、新規開発品の開発方針を決める際、数多くの課題に直面し論点が曖昧になってしまう、あるいは選択肢が絞り込めず必要な検討事項が増え続け、時間だけが過ぎていくという状況を経験していると感じました。今回の講義を通じ、これまで課題を十分に構造化できず、イシューの特定ができているつもりでできていなかった自分に気付き、早速ピラミッドストラクチャーなどの手法を活用しながら、状況をしっかりと整理していく決意を固めました。

どうして予測は有効？ 生成AIは、学習データに基づき予測を行いながら回答を導き出すという特徴が確認できました。その上、文脈の理解や原因の特定にも優れているため、その特性を十分に活かす運用が求められています。 なぜ希望通りでない？ 今後、生成AIからの回答が必ずしも自分の希望通りにならない場合、その理由を正しく理解できるようになりたいと考えています。 製品改善の秘訣は？ また、製品開発における問題点の抽出や改善提案において、生成AIが大いに役立つ可能性があると感じています。たとえば、開発した材料に対して製造ラインで問題が発生した際、関連条件の洗い出し、実機条件の確認、結果の予測や考察に活用できる点は大きな強みとなるでしょう。 どう入力すべき？ さらに、自分が欲しい回答を得るため、生成AIに入力する際の必要な情報や注意点について、皆さんと意見交換を行っていきたいと思います。

なぜ売れたのか？ 実例に沿って、なぜある商品が売れたのかを考えることは今まで経験していなかったため、とても印象に残りました。自分がよく知る商品についても同様に、なぜ売れたのか具体的な理由を探っていきたいと思います。また、行動観察を行ったことがなかったため、まずは身近なところから実践してみる意欲が湧いてきました。 実際の行動はどう？ 新規システムを開発する際には、これまで社長からの指示に従ってシステムを作ってきましたが、その結果、真のニーズが捉えられておらず、売れない原因になっていたと感じます。今後は、社長が想定する利用者像に留まらず、実際に利用者の行動を観察し、深いインタビューを行った上でシステムのコンセプトを策定していくことが重要だと実感しました。この点を踏まえ、予算申請にも利用者観察やインタビューのプロセスを組み込み、本当に解決すべき課題を明確にしていきたいと考えています。

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

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

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

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

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

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

クリティカルシンキングとは？ クリティカルシンキングは、よりよい答えを見つけ出すための考え方だと理解することができました。これまでは情報をそのまま受け取っていた自分に気づかされ、根拠や目的を確認するだけで判断の質が大きく変わるという実感を持ちました。 日常でどう実践する？ また、仕事や日常生活においても、いきなり結論を出すのではなく、一度立ち止まって考えることの大切さを再認識しました。システム開発の現場では、要件や依頼をただ受け取るのではなく、その目的や背景、根拠を確認して作業を進めることが重要だと感じています。 本当の原因は何？ さらに、障害対応や仕様検討の場合、表面的に見える事象のみで判断するのではなく、真の原因と影響範囲を整理して考える姿勢を身につけたいと思いました。

使ってみた結果は？ 同僚に「とりあえず便利だから使ってみて」と言われ、軽い気持ちで試してみたのですが、そのやり方では十分な効果が得られないと実感しました。今後活動の幅を広げるためには、企画・開発・デザイン、文章作成・校正・要約、数値計算といった多様な手順や考え方、テクニックを整理する必要があると感じています。 業務で何を磨く？ 業務においては、情報収集、取捨選択、試行、そして繰り返し改善を行うための知識や知恵を身につけることが重要だと考えています。 プライベートはどう？ また、プライベートでは、これまで自分には無理だと感じていたことや、もっとこう変えられないかと考えていたアイディアを実現するためのアプローチ手段として、生成AIを有効に活用していきたいと思います。

複数視点ってなぜ大切？ 一つの切り口だけでなく、層別や変数、プロセスといった複数の視点からデータや現象を分類することの重要性を学びました。自分一人で思いつく切り口には限りがあるため、複数人で意見を出し合いながら、さまざまな切り口を共有していくことが大事だと感じます。 開発現場でどう活かす？ また、開発職として業務に取り組む際に、得られたデータや現象の原因を洗い出すプロセスで、この手法を活用できると実感しました。一人の視点では見落としがちな要因も、他者とのディスカッションを通じて幅広い視点を取り入れることで、より深く理解できると考えています。