はじめに
システム開発プロセスで陥りやすい問題
１．企業視点中心に作るモノ（How）が決まりやすい
一般的に企画フェーズでは、企業の事業計画を元に「どのようなシステムを作るのか（How）」「それによる企業価値への効果」が議論されます。特に企画フェーズはユーザ企業主導で進むため企業側のWill つまり、「ユーザ（消費者/従業員）視点」がないままに議論が進みやすくなります。
また、後続プロセスへ繋がるアウトプット（RFP・システム化機能一覧等）もシステム開発に必要な要件が記載されていれば充足するため、”ユーザへの提供価値” が検討されていなくても進めることはできます。
出典： IPA情報処理推進機構HP RFP事例(要件定義)より抜粋
https://www.ipa.go.jp/sec/softwareengineering/tool/ep/ep3.html
IPAが開示しているRFP事例サンプルを見ても、そのシステムはユーザにとって「何が嬉しいのか（What）」「どんな体験が提供されるのか（Why）」に該当する記載はないことが見て取れます。
２．システム部門と業務部門の溝
３．「まずは作る」が先行しやすく、作った後に「使われない」ことに苦悩
上記のような問題を感じつつも、プロジェクトが走り出すとスケジュール・コストが決まってしまうため、一度決めたプロセスを再考するのは非常に難しくなります。
運用が開始した後に「そもそもどんな価値を提供したかったのか」を改めて検討するものの、構築済の仕様により実現性に制約がかかることも多くあります。
本質的な課題
上記3点の問題を生み出している原因はなんでしょうか。
私はプロジェクトの目的設定が原因と考えています。システム開発プロジェクトが発足する場合、当然のことながらプロジェクトの目的は「システムを開発すること」と定義されます。
「システム開発」という実現方法（How）を目的としていると上記の問題からはなかなか脱せません。本来であれば「システム開発」よりも上位の目的に「本当に解決すべき問題（Why）の解決」があったはずです。
まずはこの意識から変える必要があります。
言葉を入れ替えているだけのようにも見えますが、2つの意味合いは全く異なります。
前者はシステム開発が目的であり、あくまでシステム部門の課題ですが、後者はサービスのデザインが目的のため業務部門、ひいては経営課題に繋がります。
また、主眼が提供価値に向かっているため、必然的にユーザ（消費者/従業員）へ視点が向きます。
サービスデザインの有用性
では、視点が変わったところで具体的にどのようにプロセスを改善すればよいのでしょうか？
NTTデータでは以下のデザインプロセスを企画フェーズに組み込むことで、明示的にユーザの声を取込み、それをアイデア・コンセプトに落とし込んでいく取り組みを行っています。
サービスデザインには3つのベネフィットがあります。
1．共創によるプロジェクトメンバーの合意形成
2．部門サイロ化の打破
3．可視化と検証から素早く形にする
引用）デザイン思考の事例から見る3つのベネフィット
https://www.nttdata.com/jp/ja/data-insight/2022/021402/
サービスデザインの事例は上記記事でも紹介していますのでこの場では語りませんが、これらのベネフィットにより、システム部門・業務部門の垣根を取り払い、システムの提供価値・コンセプトを定義していきます。
また、コンセプト段階でユーザ検証をかけることで、システム開発前に ”ユーザが使いたいと感じるサービス”を形作ることができます。
おわりに
”デザイン”という言葉が有名になって久しく、既に多くの企業でも取り入れられていることと思います。
しかし、まだまだ多くの企業が従来のプロセスの問題から脱却できていなかったり、ペルソナ・カスタマージャーニーは使っているもののツールの使い方に終始してしまい、サービスデザインの本質に至らず、システム開発後に苦しんだ末に相談いただくケースが多くあります。
本記事を読んでいただいた皆様が改めて「検討しているプロセスで本当に ”提供価値を定義”できるのか？」を考えるきっかけとなり、サービスデザインの考え方を取り入れていただければ幸いです。