https://active.nikkeibp.co.jp/atcl/act/19/00134/080900054/?n_cid=nbpnxta_mlma1_3_atcl3
誰のためにつくったのかよく分からない、「残念な」ITシステムやアプリケーション。時間をかけて要件定義し、お金と人手をかけて構築したにもかかわらずようやく出来上がったのはなんともイケていないインターフェース、イケていない機能や導線の仕組み。煩雑かつ古風な業務プロセスをそのままに、ただデジタル化しただけ。利用者の無駄な手間を増やすのはもちろん、問い合わせやクレームなどで対応するスタッフも疲弊していく。
そんな切ない景色が今日も日本のどこかで繰り広げられている。この問題、単に要件定義の質を上げれば解決するものでもない。どのようにして突破していくか、具体例を基に考えてみよう。
動画視聴サービスを事例に考えてみる
話を分かりやすくするために、具体的なITサービスやアプリケーションを例に挙げることとする。ある情報メディア企業（A社）が動画視聴サービスを始めることになった。
A社が保有するニュース記事やコンテンツをインターネット上で動画として展開し、利用者や見込み顧客に閲覧してもらうためのサイトだ。既存顧客の満足度向上はもちろん、見込み顧客とA社との接点を増やすことも目的としている。
ところで読者諸氏は、インターネット上の動画視聴サイトと聞いてどのような機能をイメージするだろうか。ただ動画を視聴できるだけでは不十分であろう。
- 検索できる
- 視聴履歴が保持されており、途中まで見た動画であっても後から容易に探して視聴できる
- 「オススメ」動画のサムネイルが表示される
これらの機能を期待するのではなかろうか。ところが、実際に完成しリリースされたサービスはそれらの機能は一切ないか不十分であった。
利用者から次のような不満が続出した。
「検索してもヒットしない」
「前回見ていた動画は最初から探し直し」
やがて、次のようなA社への不信に形を変えた。
「利用者の気持ちが分かっていない」
「この企業（A社）の担当者も開発者も、動画視聴サービスを利用したことがないのか」
「利用体験不在」「利用者目線無視」の背景にあるもの
いわば「利用体験不在」「利用者目線無視」の、独りよがりなITシステム開発。この問題が起こる背景に、いくつかの要因が考えられる。単にITに詳しい人間と、業務に詳しい人間、すなわちITのプロと業務のプロがいればよいというものではない。
1．ベンダー丸投げや下請け体質
A社の業務担当者は、「言わずもがな」でそれらの機能を期待していた。いまどき、広く利用されている動画視聴サービスでも検索、視聴履歴保持、リコメンドなどの機能は当たり前のように実装されているし、当然今回のサービスにも実装されると思っていた。開発側、すなわちA社の情報システム担当者とITベンダーの言い分は「言われていないから実装しませんでした」。予算も納期も限られており、厳しかった開発側の事情もあろう。
顧客（A社の業務担当者）は「言わずもがな」で今や当たり前と思っていた機能の実装を期待する。あるいは、動画視聴サービスの機能のトレンドなどをむしろ情報システム担当者やITベンダーに提案してほしいと思っている。
一方で、情報システム担当者やITベンダーは「それは顧客の仕事」だと思っている。自分たちはあくまでITシステムやアプリケーションをつくるプロであり、要件のプロではない。「要件を事細かに言語化するのが顧客の役割」だと思っている。ここに相互の期待のズレが生じている。この登場人物だけで、利用者目線に立った良いサービスができるはずがない。
2．相互他責
それでもまだ顧客と開発サイドのコミュニケーションが良ければ、途中でリカバリーできたかもしれない。ところが、業務担当者、情報システム担当者、ITベンダー（1次請け、2次請け、3次請け……）それぞれがお互いに他責。
業務担当者は要件をどこまで細かく言語化したらよいのか分からなかったかもしれない。中には、自分たちでも気づいていない潜在ニーズなどもあろう。
「相手はITのプロだから、この手のシステムやサービスをたくさんつくってきた実績もあるだろうから、いい感じに仕上げてくれるだろう」
「抜け漏れがあれば提案してくれるだろう」
そんなふうに楽観的に思って要件定義工程を完了する。
ひょっとしたら、情報システム部門やITベンダーにも「検索機能がイケていないと思います……」「視聴履歴が出ないのは不便でしょう」と思っていた人もいるかもしれない。ところがそれを業務担当者に伝える場もきっかけもない。あるいは各組織のリーダーや責任者から「余計なことは言うな」「顧客から言われたことだけをやれ」とくぎを刺される。
「やぶへび」で、予算も納期もそのままに、やることだけが増やされた黒歴史を体験しているからだ。
こうして同じゴールを目指すプロジェクトチームであるにもかかわらず、縦割りかつ相互他責なカルチャーが醸成される。
3．全員が利用の素人
あるいはこのシステム開発に携わった全員が、利用の素人だった可能性も考えられる。
例えばインターネットの動画視聴サイトなどを利用したことがない、または利用経験が少ない。日頃、テレビしか見ない人たちであれば、検索機能、履歴保持機能、リコメンド機能などの発想すら浮かばない。それでもってそれらの機能を悪気なく実装せず、インターネット動画視聴に慣れた利用者を幻滅させる。
4．ノウハウ共有不全
情報システム担当部門やITベンダー内のノウハウ共有不足の問題も大きい。
動画視聴のようないまや汎用的なシステムやサービスは、既に世の中の多くの企業が展開していたり、自社内に他の顧客向けに開発したノウハウもあったりする。ところがそれが社内共有されない。「セキュリティー」の名の下に、他社事例を中で囲ってしまう。
他社事例を横展開すれば要件定義の手間も省け、なおかつ仕様や機能の「悪気ない抜け漏れ」も防ぐこともできるのに、毎度ゼロから創ろうとする。いわば車輪の再発明をしている。でもって、妙にオリジナル感にあふれた、なじみにくく、使いにくいシステムが出来上がる。
これは顧客サイドの、何でもかんでも秘匿扱いしたがる「過剰セキュリティー症候群」「秘匿病」に起因するところも大きい。
「利用体験不在」の悲劇は非ITの現場でも見られる
似たような問題は、鉄道会社が刷新した自動発券システムでも指摘された。
- 直感的に操作できない
- オンライン窓口に問い合わせをしないと発券できない種類の切符がある
- にもかかわらず、窓口の電話が混雑していてつながらない
- 前に並んでいる利用客が操作に手間取り、券売機に長蛇の列。ただでさえ本数が削減されて少ない列車に乗り遅れる
例えば上記のように、利用者から非難ごうごうであった。自動発券システムと引き換えに駅の窓口を廃止してオンライン窓口に集約し、人員を削減したことも、利用者の不満に火をつけた。
話を聞いてみると、このシステムは従来の窓口スタッフが、利用者の依頼を受けて切符を発券するプロセスをほぼそのままデジタル化したものであることが分かってきた。すなわち、利用者が直接切符を発券するフローやプロセスになっていない。必然的に業務の素人である利用者がそのまま操作するには分かりにくく、使いにくい仕組みにならざるを得ない。
業務のプロである窓口スタッフにいくらヒアリングしたところで、利用者にとって理想的な業務プロセスを描くのは難しいであろう。
「業務のプロ」といわれてアサインされた、業務担当者が「利用のプロ」（もっとも、この場合は「利用の素人」の目線こそ必要だが）であるとは限らない。とはいえ顧客が業務の代表としてアサインした人である以上、その人の言葉通りにシステムの要件定義と開発をせざるを得ない。心あるITベンダーの開発担当者も、「何か違う」とうすうす思いつつも、半ば偶像化した「業務のプロ」「業務部門のエース」を信じて突き進むしかないのだ。ITベンダーも「顧客に言われたままつくりました」のスタンスを維持せざるを得ない。
これはもはやシステム開発を通り越した、業務全体のデザイン、行動設計のレベルの問題である。
このような「利用体験不在」「利用者目線無視」のデザインは、ITシステムの世界にとどまらない。例えば、近年全国でブームのインバウンド施策においても散見される。
駅や空港、街の案内や動線などが利用者目線で設計されていない。同じ観光施設が別の言葉で説明されていたり（一貫性がない）、そもそも行き方を案内しにくかったり、現地ローカルの仕組みでしか支払いができなかったり。それらは当事者である旅行者はもちろん、ツアーガイドや駐在員など旅行者をアテンド（案内）する第三者にとっても不親切である。
筆者はグローバル企業勤務が長く、海外からの訪日者をアテンドすることが多かったが、アテンドする人の手間がかからない土地は大変ありがたく喜んでリピートしたくなる。インバウンドを掲げる自治体や事業者は、ぜひともアテンドする立場にある人たちの目線や声を積極的に取り入れてほしい。
デザイン思考を高めよう。キーワードは対話、共創、他者体験
利用者や利用を促進する人たち、あるいは利用者にサービスを提供する人たち。そのような人たちの視点や声を取り入れて、よりよいサービスを提供する考え方。それを「デザイン思考」と言う。
近年、ITシステム開発やサービス開発にも重視され始めている考え方の1つだが、デザイン思考を高めるために我々は組織として個人としてどうしたらよいだろうか？ キーワードは3つ。対話、共創、そして他者体験である。
1．対話
指示・命令型、一方通行型ではなく他者とフラットに対話し、相手の視点や考え方を取り入れる。そのためにはフラットな立場で対話をする能力を身に付けていく必要があろう。
2．共創
下請け構造ではなく、業務担当者、情報システム担当者、ITベンダー、利用者などがフラットな対話をして、お互いの視点や背景を理解しながら課題解決をする。いわば共創するための能力と経験を組織に増やしていく必要がある。
そのためには、アジャイルな業務プロセスやカルチャーはもちろん、個々の傾聴能力、プレゼンテーション能力、ファシリテーション能力、ロジカルシンキング（論理的思考）、クリティカルシンキング（批判的思考）、アンラーニング（固定観念を棄却する行為）習慣などを身に付けていくことが欠かせない。逐次の報連相型ではなく、グループチャットなどで非同期かつオープンに意見を述べ合ったり、情報共有し合ったりする体験の定着も肝である。相手をパートナーではなく、業者扱いするような重厚長大な事務手続きやプロセスも問題だ。共創型に変えていこう。
3．他者体験
他の立場を体験する能力や機会も必須である。
- 利用者の立場を日頃から体験する
- 利用者を案内する体験をする
- サービス提供者の視点で物事を考える
このような他者体験を、開発プロセスに積極的に取り入れていくべきだ。あるいは、利用者などとの対話を通じて疑似体験をする。さもないと、「分かっていない」システムやサービスが乱立する一方だ。大手プラットフォーマーが運営するSNS（交流サイト）などでも、「開発者が利用体験していないのだろうな……」と残念に思う仕様や設計のものもある。あるいはその企業に対し「利用者目線を持った開発者の声が、経営に届かない風通しの悪い組織カルチャーなんだろうな」と勘ぐり、妙に納得してしまう。そのような企業に、イノベーションを顧客は期待できるであろうか。
利用者体験が豊富な人との対話なども含めて、他者体験をする時間を開発プロセスに織り込む。そのための時間とお金を確保する。その姿勢を組織として持つ必要がある。他者体験や他者目線を取り入れる行為を、「無駄なプロセス」「無駄な作業」「無駄なコスト」としてすっ飛ばそうとする責任者もいるが、そういう人の存在こそが無駄かもしれない。
VUCA（変動性・不確実性・複雑性・曖昧性）の時代といわれている。多様化や複雑化が進む世の中だからこそ、さまざまな立場を体験してサービス開発できる人たちは間違いなく強い。自分たちだけで解決しようとせず、さまざまな人たちの視点や体験を組織に取り入れていこう。越境し共創できる組織にトランスフォーメーションを！
0 コメント:
コメントを投稿