デジタルテクノロジーの進化により、私たちの生活や社会、ビジネスは大きく変わろうとしています。デジタルエクスペリエンスやサービスが広まる中、フォーデジットは「未来のあるべき姿」をユーザー中心に体験を描き、デジタル領域のコンサルティングから制作・アウトプットまで手がけてきました。2018年にNTTデータと資本提携を結び、クライアントの課題解決に向けた取り組みを加速させています。

そもそも文化も考え方も違うIT会社とデザイン会社が協業すると、さまざまなすれ違いが生まれるのは当然。そこでフォーデジットとNTTデータ、それぞれの立場から「Design×IT」の現場で起こるリアルな問題と、今後の展望を語る座談会を開催。その模様を前後編でお届けします。

前編となる今回は、IT会社とデザイン会社の協業の現場で、どのような“すれ違い”が起こるのか、その“すれ違い”はどこからくるのかがテーマ。IT側にとっては一見自由に思えるデザイン側の思考が、実はISO規格にのっとった「HCD（人間中心設計）プロセス」だったことも判明します。

龍神：そもそも僕らの協業って、アライアンス前から自然な感じで始まっていましたよね。いくつか一緒にプロジェクトに取り組んで「サービスデザインの領域って、お互い本格的に取り組んだほうが世の中の役に立つよね」と。

田口：そうですね。NTTデータ社内では、サービスデザインへの流れって、どういう感じでしたか？

龍神：話題にはなっていましたけれど、時代の流れに後押しされていた感があります。同業他社も「ユーザーエクスペリエンス（以下UX）」をやりはじめていたし、「ビジネスモデルキャンバス」とか「カスタマージャーニー」なんて言葉も出てきたし。そういう流れを受けて、本質的に取り組んでみたいと思う人はいたものの、どういう角度で入っていくべきか、みんなすごく悩んでいた気がします。

田口：確かにUXという言葉、バズってましたよね（笑）。表面のデザインじゃないものが全部「UX」と呼ばれ出して、正直、違和感がありました。実際「それUXじゃなくて、UIの話じゃないですか？」なんていうケースも多くて。しかも僕らはもともとデジタルの領域から出発しているので、「ITとデザイン」なんて考え方もなかった。「今の世の中、デジタルで当たり前ですよね？」という認識でした。

龍神：IT屋の視点だと「システム開発のためのデザインって何？」というのが頭から離れなかったんじゃないかと思います。

末成：課題に対するソリューションが透けて見える段階になってから、UXについて考え始める。サービスデザインというのは本来、まずUXを検討してからデザインを導き出すのですが、IT会社側は思考が逆引きになりがちということですよね。

龍神：「エンドユーザーのことを考えることが大切だ」という概念は理解しているものの、IT屋の考え方というのは、あるひとつのプロセスを実行して、そこから出たアウトプットが次の工程のインプットにつながっていくウォーターフォール型が基本。それにのっとって考えると、システム開発を前提とした基本要件プロセスが起点にあって、その前段階としてユーザーデザインをしなきゃ、という順番になってしまう。いわゆる“IT屋あるある”ですよね

田口：なるほど。

末成：デザインコンサルも、最終的にはモノづくりに落とすことを考えますから、めざすゴールは同じ。アプローチの違いはあれど、根っこの部分はそんなに変わらないはずなんですけどね。

龍神：ITに対する捉え方の違いはありそうですね。「決められた要件のシステムを開発する」ということが目的なら、ウォーターフォール型はやはり合理的なんですよ。でも今の世の中、デジタルテクノロジーが媒介しないと大半のモノは作れない。本当の目的は「システム開発」ことではなく、その先の「モノやサービス」にあって、さらには「エンドユーザーの体験」にあるのではないか、というのがサービスデザインの考え方。

田口：そうそう。だから僕らは「デジタルテクノロジーの活用は当たり前なのだから、わざわざ情報システムをモノづくりの土台に置く必要、なくていいよね」と。

龍神：それが我々のアライアンスの大きなポイントだと思うんです。「もはやデジタルテクノロジーは空気みたいな存在だ」という共通の視点に立ったうえで、デザイン業界とIT会社が協業することに意味があると思うんです。

龍神：とはいえ、サービスデザインとかUXに対する認識って、まだまだ過渡期ですよね。アライアンスを組んでやってはいるものの、実際協業してみてどうですか？

末成：やりにくさで言えば、まず入り口におけるハードルの高さ。僕らの考え方やプロセスを理解してもらうのに時間がかかりがち。NTTデータの担当者でさえ、腹落ちするまでにはある程度の時間が必要です。さらにその先のお客様企業に伝えるところまで到達するには、相当の時間がかかってしまう。僕らが提供する価値を価値として納得してもらえて、発注してもらうまでのリードタイムがどうしても大きくなる。

龍神：ああ、確かにそれはある。

末成：実際にプロジェクトが動き出すと、さらにすれ違いが出てきます。デザイン思考って、作業の進め方が一見ぐちゃぐちゃに見えると思うんです（笑）。まずサービス提供側が知らないこと、気づきにくいことをいろいろな方向からユーザーに聞いて、それをちゃんと理解してから次の動きをする。全方位にアプローチして、出たとこ勝負的な動きをしますから。

龍神：可視化するとこんな感じ？（※図1参照）。全方位アプローチ型のデザイン思考は、上にも横にも斜めにもぐちゃぐちゃっと進む。一方でIT屋が慣れ親しんでいる思考は、左から右へ流れるウォーターフォール型。

末成：そうですね。で、IT思考だと、ステップごとにドキュメント化された成果が出て、最終的には100ページくらいの要件定義書が出てくる。でもデザイン思考からは、最後の最後にビジュアライズされたアウトプットしか出てこない。当然、IT側にしてみれば、プロセスそのものに対して不安感を抱きますよね。「え、成果物これだけなのに、こんなに時間とお金かかるの？」と。

龍神：IT屋の思考でいくと、デザイン思考の途中でちゃんと成果物を出してもらわないと、システムを作る要件定義ができない。

末成：そうですよね。だから途中で「ドキュメント化してください」と言われるんです。でもデザイン側にしてみれば「まだユーザーを理解しきっていないから、今はこうだけど、1週間後に結果が180°ひっくり返る結果になる可能性もあります」と。

龍神：でもIT側からすれば「とにかく要求仕様書を出してもらわないと、システム開発には移れません」となる。だってそれがないと、いつ、どのタイミングで自分が何をするかが見えないんですよ。

末成：逆に僕らは、ユーザーを知るための大切なセッションを始めているのに、IT側のメンバーが積極的に参加してくれないことに不信感を持つことがあります。

龍神：ああ、そうか。デザイン側からすると、同じチームなら一緒に考えるのが当たり前なのに、IT側は「え、あなたたちの会社が担当する部分なのに、なんで私たちがセッションに参加しなければならないわけ？」と思っている。

末成：プロセスに対する思考の違いから、お互いに対する不信感や不安感が醸成されていく。そうなるともう「大丈夫、信じてください」って言うしかない。ケイパビリティの話になっちゃうんですよね。

龍神：IT屋としては、発注側と受託側を常に意識して動くのが基本動作。「お互いの役割、権限、責任範囲をきちんと規定して、最後モノに落とす。それこそがプロジェクトマネジメントだ」という金科玉条がある。大規模でミッションクリティカルなシステム開発の場合、こうしたスコープの定義をしっかりしないと問題化する恐れがあるんです。でもUXのような取り組みを進めるには、デザイン側とIT側がワンチームになって考え方を共有しないといけない。その理屈はわかるけれど、お互い今まで培ってきた思考から抜けきれない、というのが現状なのかもしれません。

田口：ウォーターフォール型思考に慣れているIT側は、UXのデザインプロセスそのものが理解しづらいのでしょうね。

龍神：デザインプロセスなんてあるんだ!？

田口：ありますよ。しかも国際規格ですから！　ISO9241「HCD（人間中心設計）プロセス」として定義されています（※図2参照）。簡単に説明すると、スタートラインが「ユーザーを知る」。次が「ちゃんと知る」。これ、ISOにのっとったプロセスですから！　ちなみに僕らは「このプロセスを要件に落として、工数見積もってください」って言われることが怖い（笑）。

龍神：IT屋にしてみれば「見積もってくれないとプロジェクト計画立てられないぞ」と（笑）。

田口：そうそう。しかも、このプロセスの後に出てくる成果物は何かというと「共感」なんです。でも「共感」を納品することなんてできません。これがすごくやっかいなんですよね。で、次の「困りごとを解決する」「うまくいっているかどうか調べる」を経て、再び「ユーザーを知る」に戻る、と。

龍神：いやいや、これは（笑）。我々IT屋もお客様企業のIT部門も、一度では理解しがたい。システム開発はウォーターフォール型の一方通行だけれど、デザインプロセスはサイクルで循環する。カルチャーとしても、受け入れがたいところがあるんだろうな——。

田口：さっき「参加してくれないことに不信感がある」といったのは、この図を見るとわかると思います。僕らからすれば、「ちゃんと知る」というプロセスに参加しないということは、「共感」を得るためのプロセスを飛ばして、いきなり「解決」から加わろうとする感じ。

龍神：なるほど。システム開発工程になぞらえると、要件定義も基本設計もせずに、いきなりメイクに入りテストします、というようなもの。「それでIT屋さん、本当にいいんですか」と（笑）。

末成：NTTデータのようなIT会社であれ、お客様企業であれ、その先にエンドユーザーの顔があるならば、僕たちはワンチームとなって、このデザインプロセスを踏むべきだと思っています。デザイン側もIT会社側も、そしてお客様企業側もフラットに参加して、ユーザーを知るためのプロセスを共有すれば、その過程でお互いに対する不信感や不安感もなくなっていくはず。不安に思ったら、会話すればいい。

龍神：コミュニケーションは大事ですよね。そのうえで、デザインプロセスから最後に出てきた映像やスケッチが、次はシステムを作る要件定義に落ちないといけない。デザイン思考のぐちゃぐちゃさと、IT思考のシーケンシャルさのハイブリッドって、どうしたらいいんだろう。

末成：僕らもある程度の並走作業は考えています。開発期間が左から右まであるとして、左端のスタートは一緒です（※図3参照）。で、僕らデザイン側はさっきのサイクルに従って、ぐちゃぐちゃぐちゃーっと進めていく。でも後半になればある程度落ち着いてきて、アイデアを出すことができます。それも1つではなく、「ここでも出ました、ここでも出ました」と、複数回出てくるはず。それをIT側とキャッチボールしながら、高速でシステムに落としていけたらいいな、と。

龍神：現実にはそこをどうするかが課題ですよね。実際の取り組みの中で試行錯誤しながら、探っていくしかない。僕らのアライアンスは、デザインとITが協業作業するための新たな方法を見つけ出す練習台にもなるはずですから。

（後編へ続く）

次回後編では、フォーデジットとNTTデータのデザイン×ITチームが「お客様企業にどんな価値を提供し、どのようにUXに巻き込んでいくか」がテーマ。サービスデザインという考え方をベースにお客様企業のビジネスをサポートするときの課題についても、興味深いトークが続きます。お楽しみに。