gists

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

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

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

成果物の違い

使い分け（例）

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

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

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

q

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

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

a

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This site is open source. Improve this page.