突然ですが、皆さんの会社には「なぜ作ったのかわからない」「作ったはいいけど、誰も使っていない」……そんな社内システムは眠っていませんか？
いわゆる JTC（日本の伝統的な大企業）では、こうした課題が起こりがちだと感じています。
今回は、そんな課題に一石を投じるべく、社内システムの PoC 開発に「デザイン思考」を取り入れてみたお話です。
なぜデザイン思考だったのか？
きっかけは、情報システム部門（情シス）が主導する、ある社内システムの PoC 開発プロジェクトに私達（エンジニア 5 名のチーム）が参加させてもらったことでした。
プロジェクトのプロダクトオーナー（PO）を任されたのは、情シスの若手社員の A さん。A さんにとって、今回の PoC が初めてのシステム開発経験でした。
ユーザーは社内にいる研究員たちです。
JTC の情シスにおけるシステム開発は、ユーザーから聞いた要件を元に仕様を固め、ウォーターフォールで開発を進めるスタイルがまだまだ主流です。しかし、この進め方では、ユーザーの本当の課題を見過ごしてしまいがちです。
「せっかく新しいシステムを作るなら、本当にユーザーに喜ばれる、価値あるものを作りたい！」
そんな想いから、私達は PO の A さんに「ユーザーの課題を深く理解するところから始めませんか？」と提案し、チームでデザイン思考のプロセスを実践することにしました。
私達が実践した 3 つのステップ＋ α
具体的に私達が取り組んだプロセスは以下の通りです。
1. ユーザーインタビュー 〜「現場」を知る〜
何はともあれ、まずはユーザーの声を聞くことから始めました。
今回のユーザーである研究員の方々に、時間をいただいてインタビューを実施しました。
インタビューを通して得られた最大の気づきは、「同じ研究員という職種でも、担当業務や役割によって見ている世界が全く違う」 ということでした。私達が漠然と抱いていた「研究員」というユーザー像が、いかに解像度の低いものだったかを痛感した瞬間です。
日々の業務で何に時間を取られているのか、どんなことにストレスを感じているのか。
生の声を聞くことで、私達のユーザーに対する解像度は爆発的に上がっていきました。
2. 共感マップ 〜ユーザーの「気持ち」になりきる〜
次に、インタビューで得た情報を元に「共感マップ」を作成しました。
これは、ユーザーが「見ていること」「聞いていること」「考えていること・感じていること」「言っていること・行動していること」を整理し、ユーザーのペイン（悩み）とゲイン（喜び）を深く理解するためのフレームワークです。
チーム全員で「このユーザーさんは、きっとこんなことでイライラしてるよね」「こういう情報がパッと手に入ったら嬉しいはずだ」と議論を重ねることで、メンバー間の目線が揃い、ユーザーへの共感が一気に深まりました。
このプロセスを通じて、PO の A さんも「何のためにこのシステムを作るのか」という目的意識をより強く持てたようでした。
3. ユーザーストーリーマップ 〜届ける「価値」を見える化〜
ユーザーへの共感が深まったところで、いよいよ「何を作るか」を具体化していきます。
私達は、ユーザーの業務フローを軸に、提供したい価値をマッピングしていく「ユーザーストーリーマップ」を作成しました。
これにより、
- ユーザーが本当に価値を感じる機能は何か？
- どの順番で開発すれば、最小限の労力で最大の価値を届けられるか？（MVP（Minimum Viable Product: 実用最小限の製品）はどこか？）
といった、開発の全体像と優先順位がクリアになりました。
要件定義書をいきなり書き始めるのではなく、ユーザーの体験価値を軸に開発スコープを決めることができたのは、非常に大きな収穫でした。
＋ α. インセプションデッキ 〜チームの「北極星」を作る〜
デザイン思考のプロセスとは少し毛色が異なりますが、その後のスクラム開発にスムーズに移行するため、「インセプションデッキ」も作成しました。
インセプションデッキは、プロジェクトの「なぜ？（Why）」と「どうやって？（How）」を明確にし、チーム全員のベクトルを合わせるための強力なツールです。
- われわれはなぜここにいるのか？
- エレベーターピッチ
- パッケージデザイン
- やらないことリスト
- 「ご近所さん」を探せ
- 解決案を描く
- 夜も眠れなくなるような問題は何だろうか？
- 期間を見極める
- トレードオフスライダー
- 何がどれだけ必要か
これらの問いにチームで答えていくことで、「このプロジェクトで何を成し遂げ、何を成し遂げないのか」という"北極星"を全員で共有することができました。
やってみてどうだったか？
一連のプロセスを終えたところ、チームからポジティブなフィードバックがあり、特に PO の A さんからは次のような声が聞かれました。
「最初は手探りでしたが、研究員さんの顔や困っている姿が具体的に思い浮かぶので、何を作るべきかが明確になりました。このプロセスがなければ、ただ言われたものを作るだけになっていたと思います。」
これを聞いて、私達は「やってよかった！」と心から思いました。
さらに、嬉しいことに、この活動はユーザーである研究員の方々にも伝わり、途中から開発チームに研究員が 2 名参加してくれることになったのです。
実際にユーザーがチームに加わってくれたことで、私達だけでは気づけなかった専門的な観点からの指摘や、プロトタイプに対する的確なフィードバックを迅速に得られるようになりました。これにより、システムの精度は格段に向上しました。
そして、今回の経験を通して強く感じたのは、「JTC の社内システム開発にこそ、デザイン思考は必要だ」 ということです。
BtoC や BtoB のサービス開発と違い、社内システム開発のユーザーは同じ会社にいる仲間です。
「ちょっと 30 分いいですか？」と、気軽にユーザーインタビューのアポが取れる。これは、デザイン思考を実践する上でとてつもないアドバンテージです。この恵まれた環境を活かさない手はありません。
作ってから「使われない」と嘆く前に、作る前に「本当に価値があるのか」をユーザーと一緒に考える。
この当たり前だけど忘れがちなプロセスが、社内の資産となる本当に使えるシステムを生み出すのだと思います。
おわりに
今回は、私達が社内システムの PoC 開発でデザイン思考を実践した事例をご紹介しました。
この活動が、私達の会社の中で「ユーザー中心の開発」が当たり前になる、その第一歩になればと願っています。
この記事を読んでくださった皆さんも、もし身の回りに「なんだか使いにくい」社内システムがあれば、ぜひユーザーインタビューから始めてみてはいかがでしょうか。
きっと、たくさんの発見があるはずです。