デザイン思考

デザイン思考とは、ユーザーに寄り添うことで問題を解決に導くために用いられる思考法です。デザインとは、美術のデザインではなく、「設計」としてのデザインを指します。
デザイン思考は、「ユーザーが困っていることは何か」「なぜ改善が必要なのか」「どうやって解決するか」「ユーザーは何に価値を感じるか」など、常にユーザー視点で共感し思考を進めていきます。

デザイン思考は、以下の５つのプロセスから構成されます。

共感 (Empathise)
定義 (Define)
概念化 (Ideate)
試作 (Prototype)
テスト (Test)

共感 (Empathise)

ユーザーの行動を理解し、寄り添い、共感し、何が問題なのかを見つけます。
インタビューやアンケートでユーザーのニーズを深く理解することが必要です。
相手になりきるくらい、その人の普段の思考・行動を知ることが重要です。

定義 (Define)

ユーザーのニーズや問題点、みずからが考えることを明確にします
「ユーザーが困っていることは何か」「なぜ改善が必要なのか」を明確にします。このフェーズでは、さらに掘り下げた観察と問題定義を繰り返しながら、コアとなる問題を見つけ出します。「本当に求めている」潜在的ニーズまで深堀りしていきます。

概念化 (Ideate)

課題を整理し分類します。その上で仮説を立て、新しい解決方法となるアイデアを創造します。
「どうやって解決するか」「ユーザーは何に価値を感じるか」などを仮設立ててまとめていきます。

試作 (Prototype)

早い段階で試作品・プロトタイプを作り、ユーザーに触ってもらいます。

テスト (Test)

プロトタイプでユーザーテストを行い実際に課題が解決できるのかを検証します。
試作・検証・改善を繰り返すことで、最終的にユーザビリティーの高い成果物を創り出す事ができます。

デザイン思考の目的

デザイン思考の目的は、「ユーザーの課題を解決する事」です。
その手段として、ユーザー視点で思考し試作・検証・改善を繰り返します。

プログラマー思考

システム開発を依頼された際に、開発者はプログラマーの視点で思考しがちだと思います。
「プログラムが作りにくい」「コストがかかる」「そんなに細かく検討していると納期に間に合わない」などユーザー視点とは関係ないところが気になってしまいます。
確かに、納期やコスト管理は重要ですし、整理されていないシステムを作ってはいけません。

ユーザーの課題には優先順位がある

ユーザーの課題には優先順位があります。
全ての課題を実現しているとお客様の予算内で実現する事は不可能となりますし、希望実現時期も満たすことができなくなります。
システムエンジニアは、ユーザー視点で課題を理解しつつ、お客様の予算内・希望納期内でシステムを実現するために、優先順位の低い課題を諦めてもらったり、代替え案を提案する能力が求められます。以下に失敗プロジェクトの事例を示します。

失敗事例１

お客様目線で全ての課題を実現しようとした結果、予算が大幅に超過し、納期が間に合わなくなり、さらに納期が延びている間にも要件が膨らみ続けた。
最終的に追加要件について払う払わないの言い争いになり、納期が遅延した事について責任のなすり合いになり、プロジェクトは修羅場と化す。

失敗事例２

予算内・納期内にプロジェクトを押さえるために、システムエンジニアは早い段階で作りにくい要件をお客様に了解を得たつもりで削減したが、９０％作り終えたところで、ユーザー説明会を行うと、「こんなシステム使えるか」と全員に拒否反応を示され、プロジェクトが中止となった。

失敗事例３

要件定義時に、お客様のニーズを全て拾いきれておらず、後から五月雨式に仕様追加が発生した為、追加で費用を請求しお客様も支払いをしていただくが、お客様の不満は相当高まっている。言われたことだけをやるといった姿勢では無く、プロとして潜在的なニーズまで掘り起こしてほしいとお客様から釘をさされる。

システム価値

いくらプログラマーが自己満足する美しいプログラムを開発したとしても「使えないシステム」には、全く価値がありません。
開発者としては、「売上」「利益」「作っていて楽しい」が目的になりがちですが、結果的にお客様の目的とは大きく乖離しています。
上記の様な失敗が発生すると、お客様は二度と発注したくなくなります。
短期的にはプロジェクト損益が黒字になり、よかったと思うかもしれませんが、長期的にはリードが少なくなり、受注金額が減り、稼働損が増えて、会社の経営が困難になります。
リピータ率が低い事業は、営業効率が悪いと思います。でもその根本的な原因は技術サイドにある場合が多いと考えます。