こんばんは。it-daxです。

社内システムや基幹システムの全体刷新！ようやく出来上がったぞ！
いざ出来上がってみると
使いにくい…
こうじゃない…
思ってたのと違う…
そんな声が上がってくるなんて想像もしたくないですよね…。

しかしシステム企画や要件定義でやるべきことが抜けていると現実に起こりうることです。
そうならないためにも、これからご紹介することをチェックしてみてください。

後悔するシステムとは

そもそもなぜ開発したシステムに対して後悔してしまうのか？
問題は様々ありますが、わたしは機能とアーキテクチャの２つに分類されると思っています。

機能

• 必要な機能が不足している

• 余計な機能が入っていている

• 操作性が悪い

• ビジネス目標を実現できていない

アーキテクチャ

• システムの変更作業にコストがかかる

• レスポンスが悪い

• 頻繁にバグが発生する

• インフラコストが高すぎる

上記は例になりますが、作ってから後悔するシステムはこのような問題を抱えていることが多いです。
発生の原因とアプローチを一部ご紹介します。

企画フェーズ

1.システム企画を「なんとなく」やっている

システム企画をよく分からずになんとなくやっていませんか？

システム企画は経営層から現場まで漏れなく要求を拾い上げて精査し、あるべき姿にすることが重要です。
経営層からは中長期的な経営戦略と施策、経営課題といったストラテジーを確認します。
その後、既存の業務やシステムを調査・分析し課題解決や目標達成のためのシステム戦略を策定する必要があります。

ストラテジーについては対象外なので省きますが、目指すべき目標がシステム戦略に落とせるほどにブレイクダウンされている必要があります。
もし抽象的すぎる場合は、まずは経営層と共に具体的な施策を考えましょう。

ここから先はEA（エンタープライズアーキテクチャ）を軸に進めていくことで関連する組織・業務・システム全ての最適化の方針を打ち立てることができます。

EAについて詳しく書くと腱鞘炎になってしまうので、とても参考になるリンクを貼っておきます。
https://rakusui.org/ea/

盛大にコストをかけて完璧に策定する必要はありません。
しかし常に見直す必要があります。
ビジネスの状況に柔軟に対応できるような仕組みをあるべき姿として策定することがなによりも重要です。

要件定義フェーズ

2. アプリケーションのUXを考えていない

UXとはUser Experienceの略で、ユーザーがサービスやシステムの利用を通して得る体験のことを指します。
使いやすさ・見やすさ・付加価値・サポート体制など、ユーザーが得る価値を最大限引き出すことで高い満足度を実現します。

近年UIの綺麗さだけをスコープしてUXデザインと謳う企業も多いですが、根本的に間違いです。
システム要件定義の機能だけでなく非機能の部分に関してもアプローチしなければいけません。
でなければ、画面は綺麗だけどいらないシステムが出来上がってしまいます。

必要なアプローチはAs-Is/To-Beの業務フロー+サービスブループリントでの分析と、プロトタイプによるリサーチになります。

1.As-Is分析とTo-Be策定

あなたのチームで詳細な業務のあるべき姿を描きます。
まずはAs-Isでは様々な観点で業務を分析します。
「課題」「人的コスト」「金銭的コスト」「変革のポイント」「制約事項」などが観点の一例として挙げられます。
これらのインプットをもとにTo-Beを描くことで、理想的な業務の姿が導き出されます。

To-Beから書くことで理想の業務が導き出されるというやり方もありますが、業務システムの場合には「制約事項」を確認しなければいけませんので、As-Isから入ることがベターとなると考えています。

2.サービスブループリントによる接点の洗い出し

サービスブループリントは、あるサービス提供のプロセスにおける、ユーザー体験・サービス提供者双方の動きを時系列で表したものです。
業務フローとは違いユーザー体験とプロセスを俯瞰してみることができます。
ここでは「サービスの課題」「最適化のポイント」「担当や部署の連携」を分析することができます。
実はここのプロセスではこのような課題があり待機時間が長いなどといった全体最適の視点でシステムを俯瞰することができます。

修正すべき点が見つかったらTo-Beに反映しましょう。

3.プロトタイプによるリサーチ

To-Beをプロトタイプとして作成します。
webデザインツールや模型などさまざまな作成方法があります。
重要なのは体験してもらってフィードバックを得ることです。
現場目線の操作性の感想や業務の実現可能性などを確かめられるレベルに抑えてプロトタイプは作成しましょう。

フィードバック結果をTo-Beに反映し、ブラッシュアップしてUXの検討は完了です。
もし不安であれば何度かこの工程を繰り返すといいでしょう。

おわり

どうでしょうか。特別なことではないので、皆さんもなんとなくは知っていたのではないでしょうか。
ほかにも注力すべきポイントはあると思います。
ただこの２つのアプローチをちゃんと実施するだけでほとんどのシステムは「いらなかった」と言われないようになるはずです。

しかし検討してみると複雑で難しく、専門的な知識も必要となってきます。
実施する際にはシステムの専門家や業務の専門家、精通したコンサルタントがいると安心ですね。
わたしはいつでもお待ちしております。

なにか質問事項などありましたら、ツイッターまでご連絡ください。