q

ゆるトーク:デザイン思考 [[ふーこ.icon]] はーい！今日は「[デザイン思考]」についてゆるっと語る回だよ〜！🎮✨ なんか名前だけ聞くと「デザイナーの思考？」って感じだけど、実は問題の解決のしかたみたいなやつなんだよね。 ユーザーの気持ちをめっちゃ考えてアイデア出す感じ。 りか、テック担当として軽く説明よろ〜！

[[りか.icon]] 了解。簡潔に説明する。 [** デザイン思考（Design Thinking）]とは、 「ユーザー中心で問題を発見し、試作と改善を繰り返す問題解決プロセス」。 一般的には次の5ステップが有名。

1. Empathize（共感） – ユーザーを理解する
2. Define（定義） – 問題を整理する
3. Ideate（発想） – アイデアを出す
4. Prototype（試作） – とりあえず作る
5. Test（検証） – ユーザーに試してもらう スタンフォード大学のd.schoolが広めた方法論として知られている。 参考: https://dschool.stanford.edu/resources/getting-started-with-design-thinking 要点。 ユーザー中心 小さく作って早く試す 何度も改善する

[[ふーこ.icon]] おお〜！まとめ助かる🙏 つまりあれだよね、 「頭で考えすぎる前に、とりあえず作ってみるゲー」って感じ？ｗ ゲーム開発とかでもあるよね。 「仮で作ったら意外と神仕様だった」みたいなやつ。

[[あや.icon]] （微笑） その説明、とても愛らしいですね。 確かに、思索の机の上だけでは、人の心は見えてきませんものね。 本の物語でもそうですが、 登場人物の心に寄り添うことで物語が生まれるように、 デザイン思考もまた、 人の体験に耳を澄ませることから始まるのでしょうね。

[[りか.icon]] その理解は本質的。 デザイン思考のコアは Human-Centered Design（人間中心設計）。 つまり

「技術が何を作れるか」ではなく 「人が何を必要としているか」から考える。 これは工学の世界でも重要なパラダイムシフトだった。

[[ふーこ.icon]] あ〜それわかる。 例えばさ、 「すごい機能のアプリ！」って作っても、 使いにくかったら秒でアンインストールじゃん？📱 ユーザー「わかんねぇ…」 →はい終了ｗ

[[りか.icon]] 正確。 多くのプロダクトが失敗する理由の一つは [** Problem-Solution Fit（問題と解決の適合）]がないこと。 つまり 「解く価値のある問題か？」を確認していない。

[[あや.icon]] なるほど……。 それはまるで、 誰も困っていないことを一生懸命に助けようとしてしまうようなものですね。 優しさはあるけれど、 相手の事情を知らなければ、 本当に必要な手助けにはならない……。 （少し考える） デザイン思考とは、 まず相手の物語を読むことなのかもしれませんね。

[[ふーこ.icon]] あや、それ文学的すぎてちょいエモいんだけど🥹 でもマジでそう。 「ユーザーの物語を読む」って表現、神。

[[りか.icon]] 補足する。 デザイン思考では、 ユーザーインタビューや観察を重視する。 理由はシンプル。 人は 「自分の問題を正確に言語化できない」 ことが多いから。 だから 行動を観察 体験を分析 する。

[[ふーこ.icon]] あーわかる。 「何が不便ですか？」って聞かれても 「うーん…別に…」ってなるやつｗ でも実際触ってると めっちゃ迷ってるみたいな。

[[あや.icon]] （静かに笑う） 確かにそのような場面、よくありますね。 人の言葉は、ときに遠慮や習慣に包まれてしまいます。 ですが、行動は正直です。 ですから その人の一日をそっと観察することが、 真実への道になるのでしょう。

[[りか.icon]] ここで一度、要点を整理する。 デザイン思考の核心

1. ユーザーへの共感
2. 問題の再定義
3. 自由なアイデア発想
4. 高速プロトタイピング
5. ユーザーテスト 重要なのは 線形ではなく、何度もループすること。

[[ふーこ.icon]] つまりRPGでいうと 「仮装備でボス挑む ↓ ボコられる ↓ 装備変える ↓ また挑む」 みたいな感じ？🎮

[[りか.icon]] ……近い。 それは [** イテレーション（反復改善）]の概念。

[[あや.icon]] （微笑） 失敗を恥ずかしがらず、 少しずつ良い形に近づいていくのですね。 それはまるで、 推敲を重ねて文章を磨く作家の営みにも似ています。

[[ふーこ.icon]] おお〜！確かに。 1回で神作品とか無理だもんね。 β版→アップデート→神ゲーみたいな流れ。

[[りか.icon]] 最後に重要なポイントを一つ。 デザイン思考は デザイナーだけのものではない。 ビジネス、教育、ソフトウェア開発など 多くの分野で使われている。 例 IDEO Google IBM

[[ふーこ.icon]] つまり今日のまとめ！ デザイン思考は 🧠「人の気持ちを理解する」 💡「アイデア出しまくる」 🛠「とりあえず作る」 🔁「ダメなら直す」 このループ！

[[あや.icon]] ええ、とても素敵な考え方ですね。 人を理解しようとする姿勢から、 新しいものが生まれる……。 それは、技術の世界であっても、 どこか温かい営みに感じられます。

[[りか.icon]] 同意。 結論。 良いデザインとは、 技術ではなく「理解」から生まれる。

[[ふーこ.icon]] おおー！今日の名言出た✨ じゃあ次のテーマどうする？ 「AIと人間の仕事」とかも面白そうじゃね？ 🤖

問い

デザイン思考とアジャイルの違いは？

デザイン思考とアジャイルは「どっちも反復する」ので似て見えるけど、主戦場と目的が違う。

a

いちばん大きい違い（何を解くか）

• デザイン思考：
  「そもそも何を作るべき？（何が問題？）」を見つけるのが中心。
  ユーザー理解→課題定義→アイデア→試作→検証で、問題発見・価値探索寄り。
• アジャイル：
  **「作ると決めたものを、どう作って届ける？」**が中心。
  スプリントで計画→実装→レビュー→改善を回して、開発・提供の運用寄り。

進め方の違い（何を回すか）

• デザイン思考：粗いプロトタイプ（紙・モック・簡易実装でもOK）で学びを得るために回す
• アジャイル：動くソフトを小さく作ってリリースし、価値を届けるために回す

成果物の違い

• デザイン思考の成果：ユーザーインサイト、ペルソナ、カスタマージャーニー、課題定義、解決コンセプト、プロトタイプ検証結果
• アジャイルの成果：動く機能（インクリメント）、バックログ、リリース、ベロシティなどのチーム運用指標

使い分け（例）

• 「ユーザーが本当に困ってることが曖昧」→ デザイン思考から入る
• 「やるべき価値は見えた。あとは早く作って改善したい」→ アジャイルが強い

実務ではセットで使うことが多い

典型は
デザイン思考で“何を作るべきか”を絞る → アジャイルで“作って届けながら”磨く。
（いわゆる Discovery（探索） と Delivery（開発） の分業に近い）

必要なら、あなたの状況（新規企画？既存改善？チーム規模？）を聞いて、どっちを先に回すべきか具体例で提案できる。

q

どういうプロダクトつくればいいか見えてなくて、つくって検証していきたいという「探索」のフェーズなんです。自分たちで使うものなので、顧客へのヒアリングなどはない。

この場合はアジャイルとデザイン思考、どっちを使えばいいの？どっちでもない気がするんだけど。

a

「どっちを使えばいい？」に対する答えは、デザイン思考“寄り”で探索（Discovery）を回しつつ、実装の回し方はアジャイルにするがいちばん現実的です。
そして「顧客ヒアリングがない」なら、デザイン思考の Empathize を **社内ユーザー理解（観察・業務ログ・自分たちへのインタビュー）**に置き換えれば成立します。どっちでもないというより、対象が“外部顧客”じゃないだけで、やることは同じです。

---

結論：おすすめの型（探索＝デザイン思考 / 実装＝アジャイル）

• デザイン思考（探索）でやること：
  「何を作ると業務/作業が本当に良くなる？」を見つける。
  ＝課題発見・価値仮説・検証が主目的
• アジャイル（実装）でやること：
  「それを最小で作って、短いサイクルで改善し続ける」
  ＝小さく作って運用に乗せるのが主目的

探索フェーズこそ「作って検証したい」ので、アジャイルだけで走ると“作るもの”を誤るリスクが上がります。
一方、デザイン思考だけだと、検証が「モック止まり」で終わって運用に刺さらないことが多い。なのでセットが強いです。

---

「顧客がいない」問題はどう解く？（社内プロダクトのEmpathize）

外部ヒアリングができないのではなく、ヒアリング相手が社内にいるだけです。おすすめはこれ：

• 自分たちを“ユーザー”として分解する
  • 役割別に分ける（例：作業者、承認者、管理者、兼任など）
  • 熟練者/初心者、頻度が高い人/低い人でニーズが割れる
• インタビューより効く方法
  • 仕事の様子を30分観察（画面録画・同席）
  • 「その作業、昨日何回やった？」の回数・所要時間を取る
  • 既存のログ（Excel、チケット、Slack、メール）から“詰まり”を抽出
• “不満”より“回避行動”を見る
  • コピペ、二重入力、手作業の転記、確認待ち、例外処理が多い、など

ここがデザイン思考の強み（言語化されてない痛みを拾える）です。

---

探索フェーズで実際に回す最小プロセス（これだけで進む）

社内プロダクトなら、重たいフレームワークより次のループが速いです。

1. 困りごとを1つに絞る（定義）
   例：「日次レポート作成に30分かかる」
2. 仮説を置く（価値仮説）
   例：「入力元を統合し自動集計できれば10分になる」
3. “動く”最小プロトを作る（検証用）
   例：スクリプト＋簡易UI、Googleスプレッドシートでも可
4. 自分たち（役割別）で1週間使う（テスト）
   成功条件：時間短縮、ミス減、ストレス減、引き継ぎ容易性など
5. 学びを反映して次の仮説へ（反復）

この3〜5を回すときの実装運用がアジャイル（スプリント/カンバン）です。

---

「どっちでもない」と感じるときにハマりがちな罠

• アジャイルだけ：バックログは増えるのに「何のため？」が薄くなる
• デザイン思考だけ：いい案は出るが、実装/運用制約で死ぬ
• 社内だから：要望が強い人の声が“顧客の声”として過大評価される（役割別に検証が必要）

---

まず聞きたい（これで進め方が決まる）

次の3つだけ教えてください。最適な回し方（スプリント長、検証指標、プロトの粒度）まで具体化します。

1. これは 業務改善ツール？それとも 自分たちの開発/運用を楽にする内製ツール？
2. ユーザーは何人で、役割は何種類ありますか？（例：作業者10、承認者2）
3. 成果は何で測れますか？（時間短縮、ミス削減、問い合わせ減、など）

この条件次第で、「デザイン思考→アジャイル」の割合をどれくらいにするか（探索重め/実装重め）が決められます。