はじめに

多くの制約をクリアし頑張ってシステムを作ったものの使われない
「リリース直後からユーザーより使いづらいという声が…」
長らくシステム開発に携わってきた中で、多くのユーザ企業システム部門の方がこういった悩みを抱えている声をよく耳にしてきました。
システム開発を推進するプロジェクト関係者は「良いサービス・システムを作ろう!」という情熱を持たれてプロジェクトを開始するにも関わらず、なぜこういった問題に至ってしまうのでしょうか。今回はその原因について掘り下げていきたいと思います。

システム開発プロセスで陥りやすい問題

なぜ前述のような状態に陥ってしまうのでしょうか。
企画フェーズは発注者であるユーザ企業が主体となって検討を進めていきますが、実は一般的なシステム開発プロセスに沿って進めると、ユーザ視点が入りづらくなる傾向があります。
「良いサービス・システムを作ろう!」と考えているにも関わらず、どうして”提供価値” が十分に議論されずに進んでしまうのか。
ここではシステム開発で陥りやすい問題点をご説明します。

1.企業視点中心に作るモノ(How)が決まりやすい

一般的に企画フェーズでは、企業の事業計画を元に「どのようなシステムを作るのか(How)」「それによる企業価値への効果」が議論されます。特に企画フェーズはユーザ企業主導で進むため企業側のWill つまり、「ユーザ(消費者/従業員)視点」がないままに議論が進みやすくなります。
また、後続プロセスへ繋がるアウトプット(RFP・システム化機能一覧等)もシステム開発に必要な要件が記載されていれば充足するため、”ユーザへの提供価値” が検討されていなくても進めることはできます。

出典: IPA情報処理推進機構HP RFP事例(要件定義)より抜粋

https://www.ipa.go.jp/sec/softwareengineering/tool/ep/ep3.html

IPAが開示しているRFP事例サンプルを見ても、そのシステムはユーザにとって「何が嬉しいのか(What)」「どんな体験が提供されるのか(Why)」に該当する記載はないことが見て取れます。

2.システム部門と業務部門の溝

「システム開発」を目的としたプロジェクトで業務部門を巻き込む場合、プロジェクトオーナーはシステム部門、業務部門はアドバイザリーといった関係性で体制を組むことになります。
こういった体制の場合、以下のような問題で”ユーザ視点” から遠ざかってしまうことがしばしば起こります。

  • 業務部門の主体性が薄れ、売上up/顧客満足度向上に向けた本質的な課題が出てこないケース
  • ユーザ視点での課題が挙がったとしてもシステム開発を目的としているシステム部門からは「自分たちの課題ではない」という雰囲気が漂い深いディスカッションに至らないケース

3.「まずは作る」が先行しやすく、作った後に「使われない」ことに苦悩

上記のような問題を感じつつも、プロジェクトが走り出すとスケジュール・コストが決まってしまうため、一度決めたプロセスを再考するのは非常に難しくなります。
運用が開始した後に「そもそもどんな価値を提供したかったのか」を改めて検討するものの、構築済の仕様により実現性に制約がかかることも多くあります。

本質的な課題

上記3点の問題を生み出している原因はなんでしょうか。
私はプロジェクトの目的設定が原因と考えています。システム開発プロジェクトが発足する場合、当然のことながらプロジェクトの目的は「システムを開発すること」と定義されます。
「システム開発」という実現方法(How)を目的としていると上記の問題からはなかなか脱せません。本来であれば「システム開発」よりも上位の目的に「本当に解決すべき問題(Why)の解決」があったはずです。
まずはこの意識から変える必要があります。

例えば先ほどのIPA RFP事例の目的設定を考えてみましょう。
 ×:企業価値向上に向けた経営管理システムの再構築
 〇:経営管理システムの再構築による顧客満足度向上・売上拡大

言葉を入れ替えているだけのようにも見えますが、2つの意味合いは全く異なります。
前者はシステム開発が目的であり、あくまでシステム部門の課題ですが、後者はサービスのデザインが目的のため業務部門、ひいては経営課題に繋がります。
また、主眼が提供価値に向かっているため、必然的にユーザ(消費者/従業員)へ視点が向きます。

サービスデザインの有用性

では、視点が変わったところで具体的にどのようにプロセスを改善すればよいのでしょうか?
NTTデータでは以下のデザインプロセスを企画フェーズに組み込むことで、明示的にユーザの声を取込み、それをアイデア・コンセプトに落とし込んでいく取り組みを行っています。

サービスデザインには3つのベネフィットがあります。
1.共創によるプロジェクトメンバーの合意形成
2.部門サイロ化の打破
3.可視化と検証から素早く形にする

引用)デザイン思考の事例から見る3つのベネフィット

https://www.nttdata.com/jp/ja/data-insight/2022/021402/

サービスデザインの事例は上記記事でも紹介していますのでこの場では語りませんが、これらのベネフィットにより、システム部門・業務部門の垣根を取り払い、システムの提供価値・コンセプトを定義していきます。
また、コンセプト段階でユーザ検証をかけることで、システム開発前に ”ユーザが使いたいと感じるサービス”を形作ることができます。

おわりに

”デザイン”という言葉が有名になって久しく、既に多くの企業でも取り入れられていることと思います。
しかし、まだまだ多くの企業が従来のプロセスの問題から脱却できていなかったり、ペルソナ・カスタマージャーニーは使っているもののツールの使い方に終始してしまい、サービスデザインの本質に至らず、システム開発後に苦しんだ末に相談いただくケースが多くあります。
本記事を読んでいただいた皆様が改めて「検討しているプロセスで本当に ”提供価値を定義”できるのか?」を考えるきっかけとなり、サービスデザインの考え方を取り入れていただければ幸いです。