DXを実現する・新規サービスを立ち上げる、といった目的でシステムの開発を始める中で、システム開発に失敗してしまうケースがございます。
本記事ではDX・新規サービス立ち上げ時の実例をもとに、よくある落とし穴と、回避策について解説します。
目次
ケーススタディ
しばしば見かける問題のあるシステム開発の例は下記のようなものです。
数千万円規模の社内システムの開発プロジェクトについてRFPを作成し相見積もりを取り請負で発注した。
ユーザー企業のシステム担当者は2名で、各業務のリーダーとベンダと共に業務とシステム要件を整理し、仕様書を承認した。
仕様書承認では各業務のリーダーからの要望も予算内で無事ベンダに対してねじ込むことができて一安心。
実際に開発が完了し受け入れテストの段階となって、
各業務のリーダーからは言ったことと違うとクレーム・変更要求が多数挙がった（承認をとったはずなのに・・・）
変更要求の見積もりをベンダに依頼したところ、想定より大幅に高い金額の見積もりが出てきた
特定のカテゴリの機能で不具合が多数出てシステムローンチの時期が遅延した
パフォーマンステストの結果AWSコストが見積もりより増加してしまった
といった問題が出てきます。
システムローンチをしたあとも、問題が多発しシステム担当者は日々疲弊していきます。
こういった問題はなぜ発生するのでしょうか？
原因1: 利用者のニーズに適合しない機能が盛り込まれている
業務のマニュアル化・業務フローが整備されていないケース
業務のマニュアル化や業務フロー整備が不十分な状況でシステム化を試みるとき、一般的にはシステム化を機会にマニュアル化や業務フロー整備を行います。
しかし、マニュアルや業務フローを一度作ったとしても、ヒアリングに対して全てのパターンを伝えきれていなかったり、担当者が正確に確認できなかったため、誤った情報の含まれるマニュアルや業務フローが作成されてしまうことがあります。
そういったマニュアルや業務フローを元にシステムを作成してしまった場合、実際には業務で使いづらいシステムとなってしまうケースがあります。
ユーザー企業担当者のマンパワーが足りないケース
システム開発のスケジュールを達成するためには、限られた期間で仕様のレビューを行う必要があります。しかし、限られた期間・リソースで仕様のレビューを行うことは困難であり、レビューミスや考慮漏れが出るケースが多々あります。
ユーザー企業の業務担当者から適切なフィードバックが得られないケース
システム開発を管理するユーザー企業担当者が自社の業務を全て把握しているケースは稀です。したがって、ユーザー企業の業務担当者にレビューを依頼することになります。
システム開発を管理するユーザー企業担当者は仕様書等を把握することに長けていますが、
実際にシステムを利用する業務担当者は仕様書を読んで実際の動作をイメージすることに長けていないことが多いです。
したがって、真面目にレビューに取り組まれていたとしても「仕様書だとイメージが難しい」といったコメントが寄せられることになりがちです。
社外のお客様に利用してもらうシステムであっても同様のリスクがあります。
顧客のニーズを汲み取れないケース
ニーズがあるはず、とシステムを企画・開発しても、実際にシステムをリリースしたら顧客が十分に獲得できないケースがあります。
大枠としてのニーズが合っていたとしても、個別の機能については顧客の要望に合っていないケースもあります。
実際のシステムの動きのイメージと一致しないケース
仕様書上で確認をしていたとしても、システムが完成したときユーザー体験の部分でイメージと異なるといったケースも多々あります。
原因2: システムが不安定化している
リリース後、改修を行ったりシステムを維持していくための保守・運用の費用（金銭的コスト・人的コスト）が高止まりするリスクがあります。
システムの複雑性によるケース
本来必要なかったり必要性の少ない機能がシステムに存在した場合、システムの複雑性が不必要に増した状態となります。
複雑性は改修を困難にし、コストを増加させます。
また、不具合の発生リスクが上昇することで、ベンダのみならずユーザー企業側のコストも高止まりしてしまいます。
システムのパフォーマンスによるケース
設計やプログラムの記述方法によりシステムのパフォーマンスが悪い場合様々な問題を引き起こします。
レスポンス速度の低下によるユーザビリティの低下
必要なインフラ(サーバー)の性能要求が大きくなりインフラコストが高い
バッチの実行時間等、運用上の制約が大きくなる
これらは、保守・運用にかかる金銭的コスト・人的コストの増加に繋がります
問題を避けるアプローチ
これまで述べたシステム開発リスクを抑えるには、
利用者の反応を得ながら仕様を決める
不必要な複雑性をシステムに取り込まない
運用・保守のレベルを開発しながら上げていく
といった姿勢が重要です。
利用者の反応を得ながらシステムの最終形を模索する・不必要な複雑性をシステムに取り込まない
社内向けのシステムであれば、システムを実際に触ってもらい反応を見ながら必要な機能や項目の最終形を模索します。
実際にシステムの重要機能を触ることで業務担当者の理解が深まり、システムのあるべき姿を示すコメントが業務担当者から得られやすくなります。
外部のユーザー向けのシステムであれば、必要最小限の機能を提供し、利用動態を見ながら機能やUIのブラッシュアップを行います。
ユーザーの実際の反応を数値で議論することができるようになり、UXの設計に活かすことができます。
反応を得ながらシステムを増築していくことで、必要な機能だけを開発する、不必要な機能を作り込んでしまった場合は削除する、という姿勢で開発を進めることができ、システムの複雑性の増加を防ぐことができます。
上記を実現するためには、開発の目的を仮説の検証に設定し、初期に開発するシステムの規模を小さくすることが重要です。
もちろんシステムを開発せずとも検証できる仮説についてはシステムを開発せずに検証してしまうことがリスクの低減・コストの削減に繋がります。
運用・保守のレベルを開発しながら上げていく
運用・保守のレベルを上げるための代表的な手法は、CI・アラート・計測の活用です。
CIとは継続的インテグレーションの略称です。新たな機能を実装する事に自動でテストを行い問題点を発見します。CIを導入することで、保守・運用の金銭的コスト・人的コストを抑制します。
アラートの活用も重要です。システムでエラーが発生したケースや、パフォーマンスの問題が発生したときに、報告→報告者へのヒアリング→ログの探索、と対応していると、報告者が正確な情報を記憶しておらず調査工数が多大になったり、原因の特定が不可能に陥ったりといったことが発生します。
自動でアラートを通知することで、コストを抑制すると共に問題が解消できる確率を上げることができます。
仮説検証・改善には計測が不可欠です。利用動態を把握することで、機能を変更・削除・追加すべきかが見えてきます。
これらの情報をユーザー企業のシステム担当者が把握し活用していきながら、コストを削減するための試行錯誤をしていくことが重要です。
まとめ
DX・新規サービス立ち上げ時の実例をもとに、よくある落とし穴と、回避策について解説しました。
DX・新規サービスの立ち上げにあたり、経験豊富なパートナーをお探しの方は、是非弊社までご相談ください。