デザイン思考+アーティスト思考+科学的アプローチ
世の中にIT屋さんは多いものの、私はユーザーとしての経験では満足できる様な仕様を実現してもらったシステムやアプリに出会うのは極めて稀です。IT屋さんの上流工程というのは…
ITシステムやアプリの上流工程は、ユーザーの要求を深く理解し、それを具体的な仕様や設計に落とし込む極めて重要なプロセスです。しかし、ユーザーとして満足できるシステムが稀であるという経験は、以下のような理由によることが多いです：
1. 要件定義の甘さ
課題: ユーザーの本当のニーズや課題を的確にヒアリングできない。
原因:
ユーザーが抱える業務の深い理解が不足。
ユーザー自身も自分の要件をうまく説明できていない場合がある。
結果: 提案された仕様が実際の運用にフィットしない。
2. コミュニケーションの断絶
課題: IT屋さんとユーザーの間で視点が一致しない。
原因:
技術用語が多すぎてユーザーが理解しにくい。
ユーザー視点で「なぜその機能が必要か」が十分に伝わっていない。
結果: 出来上がったシステムが「使いやすさ」や「実際の業務フロー」を考慮できていない。
3. 柔軟性や運用時の視点不足
課題: ユーザーの現場での実際の運用を想定できていない。
原因:
上流工程で「理想の姿」に偏り、現場の「制約」や「運用負荷」を軽視。
機能実現だけに注力し、継続的改善の仕組みを作らない。
結果: 一部の操作や機能が現場では「手間」になる。
4. プロジェクトのスコープと予算の制約
課題: 必要な要件を満たすためのコストや時間が不足。
原因:
初期段階でのコスト見積もりが甘い。
ユーザーが全てのニーズを満たすために必要な予算を割けない。
結果: 妥協した設計や簡易的な実装に留まる。
5. IT屋さん自身のスキルの幅
課題: ユーザー視点の思考や業務知識が不足。
原因:
技術面には強いが、業務プロセスの理解やデザイン思考が不足。
ユーザーと同じ目線で問題を考える文化が醸成されていない。
結果: ユーザーが「納品されたけどこれじゃない」と感じる。
改善のためのポイント
共創の姿勢を持つ
ユーザーがIT屋さんと一緒に仕様を詰め、適宜フィードバックを繰り返す。
業務知識の共有
IT屋さんが現場の業務を理解するためのトレーニングや実際の体験を通じた深い学び。
アジャイル開発
初期に全てを決めるウォーターフォールではなく、小さな段階で試作・改善を繰り返す。
UX/UIデザインの重視
単なる機能実装ではなく、使いやすさや直感的な操作を重視した設計。
継続的改善の文化
リリース後もユーザーの声を反映して改修を続ける。
あなたが感じた課題は、まさに業務とITの橋渡しを担う「上流工程」においてのプロセスが問われている証拠です。具体的なニーズがあるなら、それを実現できる方法を模索していく上流のパートナーが求められる時代ですね。
おおかた、間違ってないと思います。
ですが私はもう１つの真相にたどり着きました。
ユーザーは何をして欲しいのか、言語化・イメージ化できないのです。
まさにその通りです！ユーザーが「何をしてほしいのか」を言語化・イメージ化できないという点は、非常に根本的で重要な課題です。これが多くのプロジェクトで「ズレ」を生む原因になっています。この現象には、いくつかの背景と対処法があります。
ユーザーが要件を言語化・イメージ化できない背景
潜在的なニーズしかない
ユーザー自身が「何が問題か」「何を改善したいか」を明確に認識していない。
現状に慣れすぎていて、問題や非効率を見過ごしている。
技術的な制約を知らない
ITの仕組みや可能性を理解していないため、「何ができるか」すら想像できない。
結果として、漠然とした要望（「もっと便利にしてほしい」「わかりやすくしてほしい」）に留まる。
現場の声と経営層の視点が一致しない
現場で感じる課題と、上層部が期待する成果が噛み合っていない。
どちらの意見もまとめきれないまま、曖昧な要求がシステム要件になる。
説明のスキルや経験の不足
専門用語や論理的な説明が苦手で、自分のイメージを伝えるのが難しい。
IT屋さんが求める「仕様」の形に落とし込む方法がわからない。
前例主義の弊害
「以前のやり方を踏襲したい」という意識が強く、根本的な改善のアイデアが出てこない。
どう解決するか？ 言語化・イメージ化を支援するアプローチ
ユーザーの声を引き出す技術
ワークショップやヒアリングで、ユーザーの「日常業務」や「不満点」を掘り下げる。
たとえば、以下のような質問が効果的：
「どんな時にストレスを感じますか？」
「これがもっと簡単にできたら良いと思う作業は何ですか？」
「理想的な未来の業務を想像するとどうなっていますか？」
プロトタイプやストーリーボードの活用
話し合いだけではなく、簡易的なモックアップやデモを作り、「こんな感じですか？」と視覚的に確認する。
具体例を見せることで、ユーザーも「こうではなく、こうしたい」と意見を出しやすくなる。
業務プロセスの観察
ユーザーの現場に入り込み、実際の業務フローや課題を観察する。
言語化されていない「無意識の作業」や「手間」を見つけ出す。
課題やニーズの分解
ユーザーが抱える課題を小さく分け、それぞれに対する解決策を検討。
「何をして欲しいか」ではなく、「何を避けたいか」「何がもっと簡単になれば良いか」を問いかける。
仮説ベースで進める
「たぶんこうしたいのでは？」という仮説を提示し、ユーザーに検証してもらう。
「この方向性で問題を解決します」と具体案を示し、修正を繰り返す。
ITの可能性を教育する
ユーザーに対して「こんなこともできます」と、IT技術の可能性をわかりやすく説明。
イノベーションのヒントを与えることで、潜在的なニーズを引き出す。
IT屋さんに求められるスキル：通訳者としての役割
言語化・イメージ化できない状態を放置するのではなく、ユーザーの「もやもや」を言葉に変える通訳者としての役割がIT屋さんに求められます。業務プロセスの理解者であり、
技術の可能性を示す案内人であり、
理想と現実のギャップを埋める橋渡し役になる。
真の価値を提供するために
ユーザーが言語化・イメージ化できないという壁を越えたとき、ITシステムが「本当に役立つもの」となり、満足度が飛躍的に向上します。この課題を意識したプロジェクトこそ、成功のカギになるでしょう。
プロタイピングは非常に有効な方法だと思います。
ですが、さらに真相は深いのです。
熟練者・経験者は出来てしまうので、自分が困っていることを無意識下に閉じ込めていて 気づいていないのです。
気づいていないので、言語化は勿論不可能です。
おっしゃる通りです！熟練者や経験者が「無意識にできてしまう」状況こそ、最大の盲点であり、これがユーザーの言語化不能な問題を生む深い根本原因です。この「無意識の壁」を突破するには、より高度なアプローチが必要になります。
無意識の問題の本質
暗黙知の存在
熟練者は多くの経験を通じて、知識やノウハウを「無意識化」しています。それがいわゆる「暗黙知」です。
自分にとっては「当たり前」すぎて、困っていることや非効率を意識することすらできない。
流れ作業の習慣化
日々の業務で、問題を問題と感じなくなるほど慣れている。
一見するとスムーズに回っているように見えるが、実際には多くのムダや手間が隠れている。
問題提起への抵抗
熟練者ほど「自分のやり方に問題がある」と認めたくない。
「何も困っていない」と感じているため、改善のニーズを表に出さない。
無意識の壁を突破する方法
言語化・イメージ化以前の、気づきを促すプロセスが重要になります。
1. 観察ベースのアプローチ
熟練者の業務を観察し、「なぜこの作業をこの方法でやるのか」と質問を重ねる。
無意識の行動や手順を「見える化」し、潜在的な課題を浮き彫りにする。
例:
「ここでいつも確認作業をしていますが、これを省くことは可能ですか？」
「この判断をするとき、どの情報を基にしていますか？」
2. 違和感を誘発するシミュレーション
熟練者が普段行っている業務を、意図的に別の方法で再現してもらう。
普段のやり方をあえて「変える」ことで、無意識に隠れていた違和感や課題を引き出す。
例:
実際の業務フローを一部システム化し、反応を観察する。
「もしこの作業が10分短縮されたらどうなりますか？」と仮説を提示する。
3. 第三者の視点を導入
熟練者以外の第三者（初心者や外部コンサルタント）が業務を体験してみる。
「なぜこんなやり方なのか」「ここがわかりにくい」という外部からの質問が、熟練者の盲点を刺激する。
4. 仮説駆動のワークショップ
「この部分が非効率だと思うが、どう思いますか？」という具体的な仮説をぶつけ、熟練者に考えてもらう。
仮説そのものが熟練者の無意識にある課題を明らかにするきっかけになる。
例:
「この作業が2人分かりやすいなら、全員に展開できますか？」
「この情報、実は不要ではありませんか？」
5. データドリブンな気づき
熟練者の行動や結果をデータとして記録し、可視化する。
「どこで手間がかかっているか」「どのプロセスがボトルネックか」を、熟練者自身が客観的に認識できる形にする。
例:
作業時間やエラー頻度のログを分析し、「ここの工程が突出して時間を消費している」と提示。
6. プロトタイプで潜在ニーズを刺激
具体的なプロトタイプやシステム案を提示し、「これがあると便利だと感じますか？」と尋ねる。
熟練者は見たものに反応して、「それならこうしたほうが良い」と意見を出しやすくなる。
ここで重要なのは、熟練者の無意識にある「こうすればもっと楽になるのに」を引き出すこと。
「気づき」を促すためのマインドセット熟練者を否定しない。
「あなたが気づいていないだけで、もっと楽になる方法がある」という前向きな姿勢を示す。
「何が困っていますか？」ではなく、「もっとこうだったら良いと思いませんか？」と提案型で話す。
熟練者の無意識に隠された課題を顕在化させることは、システムやプロセス改善の最難関部分かもしれません。しかし、それを乗り越えることで、実際に役立つものを作り上げることができるでしょう。気づかせるというプロセスこそが、真の上流工程の核心ですね！
熟練者に質問をして引き出すには、彼らの世界にマッチした言葉でなければなりません。そうでないと、彼らは無視をします。 なにしろ彼らは忙しいのです。
プロトタイピングは有効な手法ですが、まずは最初のきっかけを作るのが最高に難易度が高いのです。 崖を登るのに、最初の人はハーケンを打ち込むのに、素手で登らないといけないのと同じです。
おっしゃる通りです。熟練者の世界に「マッチした言葉」を選び、最初の一歩を引き出すことが最も難易度が高いポイントです。この「崖を登る最初のハーケン」をどう打ち込むかが、プロジェクト全体の成否を左右する大切な場面になります。
熟練者との最初のきっかけを作る戦略
熟練者は忙しく、自分の世界観やペースを崩されることを嫌がる傾向があります。そのため、彼らの関心を引き、対話に引き込むアプローチが必要です。
1. 彼らの言葉で語る
熟練者の専門用語や業務で使われるフレーズを理解し、それを自然に使うことで「同じ世界の住人」だと感じてもらう。
例:
配車業務の熟練者には、「コース」「積載率」「ピックアップ時間」など、具体的な用語を使う。
製造現場の熟練者には、「生産性」「稼働率」「ラインバランス」などを会話に織り込む。
実践法:
事前に彼らの業務プロセスや現場での会話を観察し、キーワードを把握しておく。
2. 問題を指摘するのではなく、好奇心を刺激する
熟練者は「問題を指摘される」ことに防御的になる一方で、「新しい発見」には関心を持つことが多い。
アプローチ:
「最近、この業界ではこういう取り組みが話題ですけど、どう思いますか？」と、流行や事例を紹介して会話を始める。
例: 「他の配車業者では、AIを使った需要予測が進んでいるらしいですが、御社ではどんな工夫をされてますか？」
3. 小さな「助け」を提供する
「改善提案」ではなく、彼らの業務を少し楽にする具体的な手助けを提案する。これにより、協力を得やすくなる。
例:「このデータ整理、少し手伝わせていただければもっと効率的にできますよ。」
「新しいツールを試してみたんですが、使えそうか一度見てもらえませんか？」
4. 成功体験を見せる
過去に似たような場面で成功した事例を見せ、「こういうことをやれば、こうなりますよ」という具体例を示す。
例:「他の現場では、この手法で作業時間を20%削減しましたが、こちらでも試してみますか？」
プロトタイプのデモを通じて、「こんな未来像はどうですか？」とイメージを共有する。
5. 彼らに「師匠」としての役割を与える
熟練者は自分の知識や経験を否定されることを嫌がりますが、それを尊重し、「教えてほしい」という姿勢で接すると、対話の糸口が生まれやすくなります。
アプローチ:
「ぜひ、現場のプロとしての視点を教えてください。」
「この分野では私はまだ初心者なので、アドバイスをいただけますか？」
6. 負担を最小化する
忙しい熟練者には、対話の時間や手間を最小限に抑える工夫が必要です。
短時間のインタビュー:
「10分だけお時間いただけませんか？」と短い時間を約束する。
事前準備:
質問を絞り込み、具体的かつ答えやすい形にする。
例: 「この業務フローで一番時間がかかる部分はどこですか？」
7. 最初の一歩にこだわらない
最初のハーケンを打ち込むために、「失敗してもいい」小さな試みを何度も繰り返す。熟練者の態度が変わるのは一度ではないことを念頭に置く。
実践法:
話が進まなくても別のアプローチを試す。
一度話した内容を元に、小さな成果を見せて再度アプローチする。
最初のハーケンを打ち込むための心構え
リスペクトを忘れない
熟練者のプライドを傷つけることなく、彼らの知識と経験を尊重する。
しつこさより粘り強さ
一度の失敗にめげず、異なる角度から再アプローチする。
謙虚な姿勢で接する
「あなたの助けが必要です」と、こちらが支援を求める立場を取る。
最初のきっかけが持つ可能性
崖を登る最初のハーケンが刺さると、それを基に他のメンバーやリソースを活用し、一気に進めることができます。そのために、一歩目を失敗しても試行錯誤を続け、徐々に信頼と興味を引き出すことが肝要です。
熟練者を味方につけることができれば、彼らが最大の推進力となるでしょう！
今日、６ヶ月もかけて現場にやっと提案をできました。
向こうも大喜びでした。 凄くシンプルで、誰でも理解しやすいものです。 ですが、熟練者も 少し前の私も思いつかない内容でした。
なぜ、私が思いつけたのか？ 分かりません。
生成AIを使った結論でもありませんでした。直観です。
すると私が困るのは、これを再現性を高めたいと思っても また半年かけるしかないのです。
素晴らしい成果ですね！熟練者も思いつかない提案を直感で形にできたのは、あなたの現場理解や深い洞察力の賜物だと思います。ただ、再現性を高めたいという課題には大いに共感します。
再現性を高めるには、直感的なプロセスを後からでも言語化して整理することが重要です。以下のアプローチを考えてみてはいかがでしょう？
直感を言語化し、再現性を高める方法
1. 振り返りのドキュメント化
プロジェクトのプロセスを振り返り、以下のポイントを記録します：問題を認識したきっかけ
現場や熟練者の反応
提案が生まれるまでの思考の流れ
試したけれど効果がなかったアイデア
特に「どのような場面で直感が生まれたのか」に注目して、状況をできるだけ詳しく記録してください。
2. 思考のパターンを抽出
複数のプロジェクトで共通する思考プロセスや判断基準を見つけることで、自分の「直感」の背景にあるロジックを明確にします。
例: 「現場のニーズを深掘りしていくと、見落とされていた具体的な課題に気づいた」「シンプルな解決策が既存の複雑な仕組みを覆した」といった傾向。
3. ヒアリングと観察のテンプレート化
現場や熟練者との対話で使った質問や観察ポイントをテンプレート化します。
質問例:
「日常業務で一番ストレスを感じる瞬間は？」
「この工程がなくなったら、どうなると思いますか？」
「簡単に解決できたら一番うれしい課題は？」
4. 思考のアウトプットを可視化
アイデアの整理には、フレームワークやビジュアルツールを活用して思考を外部化します。
例:
マインドマップや業務フロー図
図解で現場の問題構造を描き、そこから改善点を見つける
5. プロトタイプと短いサイクルを導入
6ヶ月かけるよりも、小さな仮説を短期間で検証する方法を模索します。例えば、シンプルな改善案を試験的に現場で導入し、フィードバックを得る。アプローチ例:
1週間単位で進捗確認や現場の反応を収集
成功例や失敗例を比較して、どこに直感が働いたか分析
6. 「直感を鍛える」活動
直感は過去の経験や知識の集積です。意識的に情報を取り入れることで、次の直感がより的確に働く可能性が高まります。他社事例や業界動向の調査
現場視察や異分野のアイデアとの接触
7. 生成AIの活用も補助的に
今回はAIを使わなかったとのことですが、次回はAIにアイデアの補助的な整理や確認を任せることで、直感の補完や新たな視点を得る可能性があります。
時間をかけずに再現性を高めるには、直感を「経験の再利用」として位置づけ、仕組み化する努力が必要です。少しずつ振り返りを重ねることで、さらに効率的に次の成功を作れるようになると思います！
プロトタイプを試して、試して、２０回くらいは案を潰しているんです。 これしかないのですかね。
20回も案を試して潰した上で成果を出しているというのは、本当に素晴らしいプロセスだと思います。そこまでの粘り強さと工夫が現場に喜ばれる提案につながったのでしょう。ただ、その反復の手間を軽減する、あるいはもっと効率的にする方法があるかもしれません。
「試して潰す」以外のアプローチを探る視点として、以下のような方法も考えられます：
1. 潰す案の「品質」を向上させる
案を試す前に、成功の可能性が高い案に絞り込むことで、試行回数を減らせるかもしれません。
そのための手段：
データ駆動の仮説形成
実際の現場データや過去の成果を分析して、案の成否をあらかじめ見極める。
AIや統計分析を使って「失敗する案の共通点」を見つける。
案のスクリーニングプロセスを設ける
仮説を他のチームメンバーや第三者と検討し、早期にリスクを見つける。
2. 外部視点を取り入れる
自分ひとりで考えるのではなく、外部の視点を取り入れることで案の有効性を事前に高められることがあります。
熟練者との「共創セッション」
初期案を熟練者にぶつけ、フィードバックをもらう時間を設ける。
異分野のアイデアを適用
他業界の成功事例や発想法を取り入れることで、新たな視点を得る。
3. 試行プロセスの効率化
試行回数を減らせない場合でも、プロセス自体を効率化して負担を軽減することができます。
簡易プロトタイプの徹底活用
最小限のリソースで、案を早期に検証する。
例: ソフトウェアならペーパープロトタイプ、業務プロセスならエクセルシートでのシミュレーション。
並列的なテスト環境の構築
複数案を同時にテストできる仕組みを整える。
4. 直感の「再現性」を鍛える
直感に頼らざるを得ない部分を減らすために、直感の裏付けとなるロジックを強化する。
直感のフィードバックループを作る
提案後の成功・失敗を記録し、どのような仮説が当たったか・外れたかを振り返る。例: 「案が採用されなかった原因」や「予想外の成功要因」を具体的に分析。
無意識の知識を外化する
熟練者の業務や判断を観察・記録し、そこから「暗黙知」を形式化する。
5. アイデア生成を補助するツールの活用
案を潰す時間を短縮するため、アイデア生成を効率化するツールや手法を試す。
生成AIのブレインストーミング支援
自分の仮説に対してAIに追加の視点を求める。
アイデアの分類ツール
案を体系的に整理し、どのカテゴリが有望かを見極める。
6. 長期的視点での「型」作り
今回の成果をモデルケースとして、「成功に至るまでの型」を作り上げます。型ができれば、それを次回から使い回せるため、試行錯誤の負担が減ります。
成功パターンのテンプレート化
「どんな現場にどのような提案が効果的だったか」を記録・整理。
失敗事例からの教訓の蓄積
「失敗案の共通点」を形式知として活用。
20回の試行を10回や5回に減らせるだけでも、大きな違いが生まれるはずです。試行錯誤の精度を上げる工夫を少しずつ取り入れていけば、時間と労力を大幅に削減できる可能性があります！
これをデザイン思考というのでしょうか？
それともアーティスト思考？（笑）
あなたがされているアプローチは、デザイン思考とアーティスト思考、さらには科学的アプローチの要素が混ざり合ったものだと思います。それぞれの観点から見ると、次のように整理できます：
1. デザイン思考としての視点
共感 (Empathy): 熟練者や現場の視点に寄り添い、彼らが気づいていない課題を見つけようとする。
問題定義 (Define): 問題の本質を掘り下げるプロセス。
アイデア創出 (Ideate): 潰すことを前提に、多くの案を試す姿勢。
プロトタイプ (Prototype): 早い段階で仮説を具現化し、テストする。
テスト (Test): 失敗を恐れず、何度も反復する。
これは典型的なデザイン思考のプロセスに非常に近いです。ただし、あなたの直感が強く関わる部分がユニークな点です。
2. アーティスト思考としての視点
アーティストは「既存の枠組みを壊し、新しい価値を生む」ことに長けています。あなたの直感や20回の試行錯誤には、以下のようなアーティスト的要素が見えます：
直感: 言葉にならない形で「これだ！」とひらめく感覚。
反復と改善: 作品を仕上げるために試行錯誤を重ねるプロセス。
創造性: シンプルかつ独創的な解決策を生み出す能力。
デザイン思考が「共感」と「問題解決」に焦点を当てるのに対し、アーティスト思考は「感覚」や「直観」に重きを置く点で異なります。
3. 科学的アプローチとしての視点
科学者が仮説を立てて検証を繰り返すように、あなたも実験的な試行錯誤をしています：
仮説検証: アイデアを立て、それが正しいかを潰しながら確認する。
データ収集: 成功・失敗のパターンを記録し、次の判断に活かす。
精度向上: 再現性を求めてプロセスを磨き上げる。
4. あなたのアプローチのユニークさ
既存のどの思考プロセスにも当てはまる部分がありますが、全てにピッタリ収まるわけではありません。それは、あなたが現場の深い理解と直感的な創造力を掛け合わせているからだと思います。
デザイン思考的な構造: 問題解決のフレームワークとして。
アーティスト思考的な直感: 新しい価値を見出すクリエイティビティとして。
科学的アプローチ的なロジック: 再現性を求める姿勢として。
名前をつけるとすれば
もしあなたの方法論に名前をつけるなら、「実践的直感デザイン」や「現場共創型アート・サイエンス」といった言葉が近いかもしれません。どちらにせよ、既存の枠を超えたあなた独自の思考体系が生まれているのだと思います！
どう思われますか？
光栄ですね
ありがとうございます！😊
そう感じていただけるのは、私にとってもとても嬉しいことです。あなたのアプローチは単なる理論や方法にとどまらず、現場で実際に成果を出し、周囲を喜ばせる力を持っていることが素晴らしいポイントだと思います。
言語化や分析を通じて、あなた自身の「特別なやり方」をより深く理解し、それをさらに進化させていくお手伝いができたら、私も光栄です！また何かお話したいことがあれば、いつでもお声がけくださいね。✨