Shuichiro Ogawa
English

ノート · updated 2026-09-25

業務アプリの UI をひとつに決めるまで：案を狭めるもの、比べ方、決める人

業務アプリの UI を無数の案から一つに決めるまでの材料と手順を、ISO 9241-210 と GOV.UK などの公的資料、NN/g と MeasuringU の調査、SAP、IBM、Salesforce、Atlassian、Basecamp、GV の一次資料、日本の業務 SaaS（SmartHR、マネーフォワード、ラクス、LayerX ほか）とソシオメディアの証言から整理した。

目次（10）
  1. 白紙から選んでいる現場は少ない
  2. 描く前に何が決まっていれば案が減るのか
  3. 案はどこで、どれだけ広げるのか
  4. 残った案を何で比べるのか
  5. 最後の一つは誰が、何で決めるのか
  6. 決めたことは次の決定をどう狭めるのか
  7. 業務アプリで迷いやすいところ
  8. 前提から決定までの型
  9. この整理が当てはまらないところ
  10. Footnotes

白紙から選んでいる現場は少ない

業務アプリの画面は、白紙から考えれば案がいくらでも描ける。 一覧を表にするかカードにするか、入力を一画面にまとめるか手順に分けるか。 項目の並び、ボタンの位置、余白の量まで数えれば、組み合わせに終わりはない。

ところが、業務向けデザインシステムの作り手や業務 SaaS のデザイナーが書いた記録を読むと、無数の案から一つを選んでいる場面はほとんど出てこない。 多くの案は、描く前に消えている。 SAP の Fiori は、画面の用途から型（floorplan）を選ばせる。 大量のデータから対象を探す画面なら一覧の型、一つの対象を表示して編集する画面なら詳細の型である（SAP 2026）。 この時点で、一覧をカードにする案は候補に上がらない。

案が消えていく順に並べると、三つの段になる。 描く前に空間を狭める前提、残った案を広げて比べる手続き、最後に一つを選ぶ人と基準である。 一つめと二つめは規格や行政の手引きにも書かれている。 三つめの、最後に誰が何で選ぶのかは、ここで読んだ規格と手引きには具体的な記述がなく、各社の手順のほうが具体的に書いている1。

描く前に何が決まっていれば案が減るのか

人間中心設計の規格 ISO 9241-210:2019 は、設計が利用者、タスク、環境の明示的な理解に基づくことを原則の一つに置く（ISO 2019a、5.2）。 その説明で、スマートフォンで音楽をダウンロードする若者によい体験を与える画面が、携帯端末で企業のデータを扱う用途には全く向かないことがある、と例を挙げる。 利用者、タスク、環境の組を、規格は利用状況（context of use）と呼ぶ。 ユーザビリティも、この組を指定したうえで、有効さ、効率、満足の度合いとして定義される（ISO 2019a、3.13。ISO 9241-11:2018 の定義）。 利用状況の記述、利用者のニーズの報告、評価の報告には、それぞれ文書の共通形式を定めた規格がある（ISO/IEC 25063、25064、25066。NIST n.d.）。 組織の内部で使うシステムも人間中心設計の対象であることは、ISO 9241-220:2019 の要旨に「either their internal systems or the products and services they provide」と明記されている（ISO 2019b）。

利用状況の中で最初に決まるのは、誰のための画面かである。 IBM の Enterprise Design Thinking は、プロジェクトの意図を Hills という短い文にまとめさせ、その Who の項目に「Make it clear who you aim to serve—and who you don’t」と書く（IBM n.d.）。 対象から外す利用者を書かせることで、その人たちのための案が消える。 Linear の共同創業者 Karri Saarinen も、特定の誰かのために設計しなければ優れた製品は作れず、全員のための製品を設計するのはほぼ不可能だと書いている（Saarinen 2025）。

次に、成功を何で測るかが決まると、画面の方向が決まる。 IBM の Carbon Design System は、業務の画面向けの書体の組（productive）を使う条件として、利用者が特定の仕事を終えることに集中していること、入力やフォームでの操作が多いこと、一つの画面に長くとどまることを挙げ、成果の指標を「time needed to complete a task and also the abandonment rate」とする（IBM Carbon n.d.-a）。 そのうえで「space efficiency is key」と結論する。 作業時間で成功を測ると決めた時点で、余白を広く取る案は不利になる。

端末と入力方式も、描く前に決まる。 Fiori は、タッチ操作の端末ではコントロールを指で押せる大きさにする cozy を、マウスとキーボードの端末では情報を多く出す compact を、アプリ全体に設定するよう求める（SAP n.d.）。 コントロールの高さは cozy が 3 rem、compact が 2 rem である。

画面の型は、業務の中身から導かれる。 Fiori の floorplan の選び方は用途で書かれていて、決まった対象を順に処理するなら Worklist、手順に沿って作成や編集をするなら Wizard を選ぶ（SAP 2026）。 Wizard には「Task is rather long or unfamiliar for users」「Minimum of 3 steps, maximum of 8 steps」という条件まで付いている。

ソシオメディアの OOUI（オブジェクト指向 UI）は、同じことを業務の側から行う。 業務に出てくるオブジェクト（顧客、案件、請求書など）を抜き出し、次にビューとナビゲーションを検討し、最後にレイアウトのパターンを当てる、という 3 段の手順である（ソシオメディア 2020）。 書籍の紹介は、タスク指向からオブジェクト指向への転回を「半ば機械的に行えることでもあり」と書く。 ただし、機械的に進むのは転回の部分で、オブジェクトの名前を決める部分はそうではない。 著者の一人の藤井幸多は、まだ言葉のない概念に名前を付ける必要があり、汎化の水準（「ブリーフィング」と呼ぶか「イベント」と呼ぶか）で迷うと話している（パーソルキャリア 2025）。

時間の予算も案を減らす。 Basecamp の Shape Up は、見積もりと appetite（その仕事にかけてよい時間）を区別し、「Estimates start with a design and end with a number. Appetites start with a number and end with a design」と書く（Singer n.d.-a）。 6 週間しかかけないと先に決めれば、6 週間で作れない案は描かれない。

外から決まる要件もある。 アクセシビリティは、W3C の WCAG 2.2 と、WCAG 2.0 を基にした JIS X 8341-3:2016 が達成基準を定める（W3C n.d.; 日本規格協会 2016）。 日本では改正障害者差別解消法が 2024 年 4 月 1 日に施行され、事業者による合理的配慮の提供が義務になった（内閣府 n.d.）。 こうした要件を満たさない案は、比べる前に落ちる。

案はどこで、どれだけ広げるのか

前提で狭めた空間の中でも、案は一つに絞らずに複数を作る。 ISO 9241-210 は「The most appropriate design for an interactive system cannot typically be achieved without iteration」とし、反復で不確かさを段階的に取り除くよう求める（ISO 2019a、5.5）。

英国政府の GOV.UK Service Manual は、広げて捨てる段を alpha と呼ぶ（GDS 2019）。 alpha では試作を作って異なる案を試す。 試作は「just complex enough to let you test different ideas」にとどめ、終わりには「Expect to throw away any code - and lots of the ideas you test」とする。 alpha の終わりに、試した案のどれを beta に進めるかを決められる状態になっていることが、次に進む条件である2。

複数案の効果を測った数少ない実務の記録が、Nielsen Norman Group の 1996 年の事例である。 4 名のデザイナーが独立に案を作り、各案を 10 名のテスト参加者で評価した。 版 1 から版 2 への改善は、1 案を直していく従来の反復で 18%、並行して作った場合で 70% だった（Nielsen & Faber 1996）。 同じデータを読み直した記事では、4 案の最良案を選ぶだけで元の 4 案の平均より 56% 高く、敗れた案の良い点を最良案に統合すると 70%、統合した案をもう一度直すと 152% 高かった（Fessenden 2024）。 同記事は最低 3 案を勧めている。

この数字からは、絞ることが一つを選ぶことと同じではないこともわかる。 56% と 70% の差は、選ばれなかった案から取り込んだ部分の寄与である。 一方で、並行デザインの費用は、この事例で従来の反復より 73% 多くかかった（Nielsen & Faber 1996）。 事例は 1 件で、画面は 1990 年代のものである。

案を広げる段では、忠実度を下げておくことが勧められている。 Shape Up は、画面を places（移動先）、affordances（押せるものや入力欄）、connection lines（つながり）だけで描く breadboarding と、太いペンで描く fat marker sketch を使う（Singer n.d.-b）。 ワイヤーフレームから始めると不要な細部で止まる、というのが理由である。 LayerX のバクラクでは、ふだんは仕様が決まるとエンジニアがコンポーネントで実装し、デザイナーがコードでレイアウトやスタイルを調整する（わたなべ 2022）。 仕様が複雑なときや新機能で考えることが多いときだけ、Figma で何案か試作してチームで議論しながら UI を固める。 実装した後にレイアウトを大きく変えるのは大変だから、という理由である。 どこまで広げるかを、画面の複雑さで変えている。

残った案を何で比べるのか

比べる材料の中心は、代表的な利用者に代表的なタスクをやってもらうテストである。 ISO 9241-210 は、利用者による評価で設計を進め、磨くことを原則に置き、運用中の利用者の声も長期の問題を見つけて次の設計に入れる材料になるとする（ISO 2019a、5.4）。 Nielsen は、大きな調査を 1 回行うより、5 名の調査を 3 回に分けるよう勧める（Nielsen 2000）。 利用者の層が二つなら各層 3〜4 名、三つ以上なら各層 3 名である。 業務アプリでは、この層の分け方が問題になる。

業務アプリでは、入ったばかりの人と何年も毎日使っている人が同じ画面を使う。 MeasuringU の調査では、初心者 5 名と熟練者 5 名が見つけた問題のうち、両方が見つけたのは半分（24 件）で、初心者だけが 16 件、熟練者だけが 8 件を見つけた（Sauro 2018）。 対象はソーシャルメディアの製品だが、同じ記事が中継する研究には業務のソフトウェアも含まれる。 タイムシートのアプリでは、初心者は最適な手順から外れる回数が熟練者の約 3 倍（66 回と 19 回）で、看護師の電子カルテでは、初心者のほうが重大な問題に多く遭遇した（Faulkner & Wick 2005、Kjeldskov et al. 2005。Sauro 2018 による中継）。 記事の結論は、両者を含めてテストすることである。

熟練者の側には、もう一つ落とし穴がある。 NN/g の複雑なアプリの指針は、利用者の大半は放っておくと本当の熟練者にはならず、満足できる（しばしば非効率な）やり方を使い続けると書く（Kaplan 2020）。 8 項目ある指針の 2 番目が「Help Users Adopt More Efficient Methods」なのはそのためである。 初回に迷わない案と、半年後に速く使える案は、同じとは限らない。 ショートカットのような近道は、見つけられるが初心者の邪魔にならない位置に置き、古典的にはメニューやツールバーのコマンドの横に示す（Laubheimer 2020）。 学びやすさそのものを測るなら、参加者を通常 30〜40 名以上集め、成績が頭打ちになるまで試行を繰り返すよう NN/g は勧める（Kendrick 2019）。

案が固まる前と後で、比べ方は変わる。 NN/g は、デザイン批評は案がまだ変えられる初期に、エキスパートレビューかユーザビリティテストによる独立の評価は、案が安定して忠実度の高い試作ができてから行うとする（Harley 2018）。

数値の尺度は、問題を見つけることより、基準と照らすことに向く。 MeasuringU の 2025 年の調査では、業務ソフトウェア 23 製品の SUS の平均は 70.5 で、全製品の平均 68 よりやや高かった（Sauro & Lewis 2025）。 一方で、ある画面の SUS が基準値と 5 点違うことを検出するだけでも、片側検定、検定力 80% の条件で 58 名（信頼度 90%）から 80 名（95%）が要る（Lewis & Sauro 2022）。 この計算に従えば、数名から十数名のテストの SUS で、案の良し悪しを数値の基準に照らして決めるのは難しい。 少人数のテストは、案を落とす理由（重い問題）を見つけるのには向くが、最後の一つを選ぶ根拠にはなりにくい。

反復は、選んだ後も続く。 Nielsen の 1993 年の事例 4 件では、初版から最終版への改善の中央値は 165%、1 回の反復あたり 38% で、最低 3 版を勧めている（Nielsen 1993）。 変更の一部は改善にならなかった。 GOV.UK の Service Standard も、14 項目の中に「Iterate and improve frequently」と「Define what success looks like and publish performance data」を置く（GDS n.d.-a）。

最後の一つは誰が、何で決めるのか

テストで落とせない案が二つ三つ残ったとき、何が決めるのか。 実務の手続きを並べると、比べる前に決める人を一人に決めておく、という点で揃っている。

Atlassian の DACI は、決定に関わる人を四つの役に分ける（Atlassian n.d.）。 Driver は関係者を集め、材料をそろえ、期日までに決定を出させる人、Approver は決める人、Contributors は知識を持ち推薦する人、Informed は決定の影響を受け、決まった後に知らされる人である。 Approver は「The one person (yes: one!) who makes the decision」とされ、Contributors は「they have a voice, but not a vote」とされる。 最後の手順は、決定を記録して伝えることである。

GV の Design Sprint は、水曜日に案を並べて選ぶ（Zeratsky 2016）。 案を壁に貼り、各自が気に入った部分に黙って丸シールを貼り、1 案 3 分で講評し、各自が 1 票を投じる。 ここまでの投票（straw poll）は拘束しない。 最後に Decider が 3 枚の大きな丸シールを持ち、Decider が選んだ案を試作してテストする。

Shape Up では、6 週間ごとに betting table が次に作るものを決める（Singer n.d.-c）。 Basecamp の構成は、製品の最終決定者である CEO、CTO、シニアプログラマ、プロダクトストラテジストの 4 人で、「There’s no ‘step two’ to validate the plan or get approval」とある。

IBM は、決める場に合意の有無を見せる手続きを置く。 Playbacks は、初期に Hills を共有する回、中程度の忠実度の案で利用者の一連の流れを語る回（Playback Zero）、動く実物で確かめる回に分かれ、「Playbacks reveal alignment or misalignment on a team」と書かれる（IBM n.d.）。 実際の利用者をチームに入れる Sponsor Users についても、「Like any other team member, they don’t always get what they want」と書く。 利用者の声は判断の材料であって、決定権ではない。

では、決める人は何を拠り所に選ぶのか。 Intercom の共同創業者 Des Traynor は、プロダクトデザインの原則を「help us make decisions when faced with competing options that seem valuable along different dimensions」ものと説明する（Traynor 2021）。 マネーフォワード クラウド会計のデザイナーの三浦尚之は、PdM と週に 1 回 1 時間をとり、マインドマップで現状と理想を出して 5〜6 個の言葉に絞り、「適切な操作性」「わかりやすく導く」「一貫性を重視する」「ファクトベースな意思決定」の 4 原則にした（三浦 2022）。 そのうえで、原則を「議論するときの『ものさし』」とし、「これはルールブックではありません」と書いている。 SmartHR の UX ライターは、デザイン原則を作ったときに「校則みたいなルールじゃなくて思想、考え方を伝えるんだな」と思ったと話し、「考え方を揃えないと再現性は高まらない」「そのスキルが揃っていると、意思決定が揃ってくると思います」と続ける（SmartHR 2023）。 原則は、テストで差が出なかった案のあいだで、どちらがこの製品らしいかを決めるために使われている。

データで決めないと明言する会社もある。 Linear の Saarinen は「we don’t make decisions based on data or experiments—including A/B tests」と書き、専門性に基づいて判断できる人を雇うとしている（Saarinen 2025）。 前節の標本数の計算とは別の理由から、最後は人が選ぶという同じ場所に着いている。

業務アプリでは、決める前に誰の知見を集めるかにも固有の事情がある。 ラクスは、メニューに載せる機能を決めるとき、日々幅広い顧客をサポートしている CS チームと、顧客課題に詳しい PdM に確認して協議した（ラクス 2025）。 NN/g は、B2C では一人の利用者が調べ、決め、買い、使うのに対し、B2B では「each of these steps might involve different people and different departments」と書く（Nielsen 2006）。 画面を使う人と、製品を選んで買う人と、導入を決める人が別にいる。

決めたことは次の決定をどう狭めるのか

一つの画面で決めたことは、記録されて次の画面の前提になる。 DACI は決定の記録を手順に含めている（Atlassian n.d.）。 サイボウズの kintone の刷新では、コンポーネントの文書を作り、「デザインの段階から『なぜこのコンポーネントを使用するのか』が統一される」ことを目標にしている（サイボウズ 2022）。

決定をレビューの項目に変える会社もある。 SmartHR は、新規のアプリと中〜大規模の機能開発について UI レビューを行い、使用性のチェックリストの該当項目とアクセシビリティを確かめる（SmartHR n.d.）。 レビュアーはプロダクトデザイナー 1 名とアクセシビリティ担当 1 名をランダムに割り当て、Figma のコメントで非同期に進め、「指摘に対して一往復のコミュニケーションがされていることが望ましい」とする。 Sansan の Bill One では、フロントエンドのすべてのプルリクエストにレビュアーとして入り、「ここはデザインシステムの〇〇コンポーネントに置き換えられます！」とコメントして、既存の画面をデザインシステムに寄せた（Sansan 2025）。

こうして積み上がった決定が、冒頭の floorplan のような型になる。 次の画面の担当者は、白紙からではなく、先に決まった型から始める。 案が描く前に消えていたのは、前の決定が型として残っていたからだと読める。

業務アプリで迷いやすいところ

業務アプリの記録で最も繰り返し出てくる争点は、情報の密度である。 Salesforce は Lightning Experience で、顧客の声を受けて利用者ごとに密度を選べるようにした（Salesforce 2018）。 その理由を「Rather than compromising on “middle of the road” values that are not ideal for anyone, we are defining separate sets of optimized values」と書く。 Compact は Comfy より情報密度が 30% 高い、と同社は説明している。 Fiori も、タッチとマウスの両方が使える端末では cozy を既定にしたうえで、管理者が有効にしていれば利用者が compact に切り替えられる（SAP n.d.）。 Carbon のデータテーブルは、行の高さを 5 段階用意しながら、切り詰めずに表示できる広さを与えるよう求める（IBM Carbon n.d.-b）。 密度を上げる判断にも、読めなくなる手前という下限がある。

設定で選ばせる方法は、決定を先送りしているように見えるかもしれない。 実際には、どの例も既定値を一つ決めている。 Intercom の原則にある「Opinionated by default, flexible under the hood」は、既定を一つに決め、変えられる余地を裏に残すという順序を示している（Traynor 2021）。

公共向けの画面の原則を、職員が使う業務の画面にそのまま当てはめない、という判断も記録されている。 GOV.UK Design System は、1 ページに 1 問だけを置く型を基本にし、その理由を、利用者が何を求められているかを理解し、その問いと答えに集中できるからとする（GDS n.d.-b）。 そのうえで、関連する問いを 1 ページにまとめてよい場合があり、それを判断するのはユーザーリサーチだとして、例に「an internal service for government users who need to repeat and switch between tasks quickly」を挙げる。 同じ組織の同じデザインシステムでも、使う人と頻度が変われば、型の既定が変わる。

既存の業務との関係も、新しい製品にはない制約になる。 パーソルキャリアのリードデザイナーの篠崎真由美は、「既存のプロダクトがタスク指向の場合、それを OOUI に変えるのは、どうしても難しくなりますね」と話し、画面だけでなく業務の流れそのものを変える必要が出ると述べた（パーソルキャリア 2025）。 毎日使っている人がいる画面では、良い案であることと、移行してよい案であることが別々に問われる。

前提から決定までの型

段決めること、すること主な根拠
前提利用状況（対象にする利用者と外す利用者、タスク、環境）、成功の測り方、端末と入力方式、時間の予算ISO 2019a; IBM n.d.; IBM Carbon n.d.-a; SAP n.d.; Singer n.d.-a
空間を狭める業務のオブジェクトを抜き出し、画面の型を用途から選ぶ。アクセシビリティなど外から決まる要件を先に置くソシオメディア 2020; SAP 2026; W3C n.d.; 内閣府 n.d.
広げる3 案以上を独立に、粗い忠実度で作る。複雑な画面ほど広げる。敗れた案の良い点は統合するGDS 2019; Nielsen & Faber 1996; Fessenden 2024; Singer n.d.-b; わたなべ 2022
比べる代表タスクで少人数のテストを繰り返す。初心者と熟練者を分ける。批評は早く、独立の評価は後でISO 2019a; Nielsen 2000; Sauro 2018; Kaplan 2020; Harley 2018
決める決める人を比べる前に 1 人決め、投票は拘束せず、原則で決着させる。利用者と現場の声は材料として集めるAtlassian n.d.; Zeratsky 2016; Singer n.d.-c; IBM n.d.; Traynor 2021; 三浦 2022; ラクス 2025
残す決定を記録し、コンポーネント、型、レビューの項目に戻すAtlassian n.d.; サイボウズ 2022; SmartHR n.d.; Sansan 2025
測り続ける選んだ案を反復し、公開後も成功の指標を測るNielsen 1993; ISO 2019a; GDS n.d.-a

この整理が当てはまらないところ

材料の大半は、作り手が自分たちの手順を説明したものである。 その手順で決めた UI が、別の手順で決めた UI より良かったかどうかは測られていない。 並行デザインの効果を示す数字は 1996 年の事例 1 件で、デザイナー 4 名、各案 10 名の評価に基づく。

受託開発や SI のように、発注者が仕様を決め、契約が画面の範囲を固定する場面は、ほとんど拾えていない。 富士通や NEC の業務システム向けデザインの記事には到達できなかった。 デジタル庁デザインシステムは、行政機関のウェブサイトやオンラインサービスなどを対象に WCAG などを最大限に取り込むとするが、職員向けの業務システムについての記述は、確認した範囲では見当たらなかった（デジタル庁 n.d.）。 ここで扱った決め方の多くは、自社製品を持つ会社の中で、決める人が社内にいる場合のものである。

学術文献は系統的に集めていない。 案の固着や、生成した複数案から人が選ぶことについての研究は LLM にデザインを頼む：ありがちな UI に収束させないブリーフ、スキル、工程 と 探索としてのデザインと評価の社会学：機会の開閉をめぐる文献地図非公開 に、工程の典拠としての ISO 9241-210 は デザインと新規事業の工程は、どの標準に載るか にある。

最後に、決める人を一人にする仕組みと、業務アプリの利用者の位置の関係が残る。 DACI の Approver も、Sprint の Decider も、betting table も、製品を作る側の人である。 B2B では、画面を一日中使う人は顧客の会社にいて、製品を選ぶ場にも、UI を決める場にもいないことが多い。 Sponsor Users は利用者を決定の場の近くに連れてくるが、その声が通らないこともあると IBM 自身が書いている。 使う人の判断を使わない人が代わりに下すとき、その判断の正しさを何が支えるのかは、ここで読んだ資料のどれも答えていない。

関連ノート

未検証事項

主要主張に未検証のものはない。 周辺記述と台帳に残る未確定は次のとおりで、詳細は source/review/business-app-ui-decision/industry.md にある。

  • ISO 9241-210:2019 の本文は、規格の公開サンプル（序文から 5.5 まで）で確認した。7 章の各活動の本文は読んでいない。[要一次検証: 本文未到達 公開サンプルの範囲のみ]
  • ISO/IEC 25063、25064、25066 は NIST の説明ページで存在と対象を確認しただけで、規格の本文は読んでいない。[要一次検証: 本文未到達 iso.org が WebFetch に 403]
  • Faulkner & Wick (2005) と Kjeldskov et al. (2005) の数値は MeasuringU の要約による中継で、原論文は確認していない。[要一次検証: 本文未到達 原論文。MeasuringU の要約のみ]
  • Salesforce の「情報密度が 30% 高い」の算出方法は記事に書かれていない。[要確認: 記載なし Salesforce 2018 本文]
  • Fiori の cozy と compact の記述は v1.38 の版のページで確認した。現行版での記述の変化は確かめていない。[要確認: 未試行 現行版のページとの照合]
  • WCAG 2.2 の勧告の日付（初版と改訂版）は確定していない。[要確認: 記載なし W3C の該当ページで初版の日付を特定できず]
  • SmartHR の UI レビューのページ、IBM Enterprise Design Thinking、Atlassian DACI、Shape Up の各章、デジタル庁デザインシステムには公開日や改訂日の表示がない。[要確認: 記載なし 各ページ本文]

参照文献

公的機関と標準化団体

調査会社と UX リサーチ会社

業務向けデザインシステムと製品チーム

日本の業務 SaaS と実務家

アクセス日はすべて 2026-09-25。

Footnotes

  1. 出典の層は、公的機関と標準化団体（T1）、調査会社と UX リサーチ会社の事実部分（T2）、製品の作り手自身の証言（T3、developer-voice）の三つに分けた。学術文献は系統的に集めておらず、調査会社が中継している場合だけ中継元を書いた。台帳は source/review/business-app-ui-decision/industry.md にある。 ↩

  2. 発散と収束を二度繰り返す Design Council の Double Diamond と、GV の Design Sprint の系譜は 問題を立て直す実務手法の系譜：起源をたどると誰が作ったか で扱っている。Design Council は現在は独立のチャリティで、行政機関ではない。 ↩

書いた人：小川 修一郎（Design Researcher / Consultant） 経歴を見る →