従来型のシステム化

従来のシステム化の例としては、「これまで紙を使って申請をしていたが、システムを使って効率化をしたい」などが主な例として挙がられる。
このような場合には、ビジネス部門がどのようなビジネスフローにすべきかということがほぼ見えており、そのために具体的なシステム要件にまで落とし込み、システム部門にシステム要件を伝えることが可能である(もしくはビジネスコンサルタントが入ることで、システム要件化を進める)。つまり、目指すゴールはビジネス部門の中にある。システム要件が明確であれば、システム設計を行い、開発を行い、リリースを行うというウォーターフォール的な開発でシステムが完成すると考えている。

DX化によって創り出す世にない新しいサービス

一方のDX化の場合には、「こんなことをしたい」「こんなサービスを立ち上げたい」というまだ世にないサービスを出していくために、非常にざっくりとした目的がビジネス部門から出てくることが多い。

その場合にはビジネス部門からシステム要件を出してもらうとしても、そのシステム要件が明確ではないために、システム化をいきなり進めることはできない。よって、DX化を行う場合には、ビジネス部門からの目的を一旦はシステム部門が活用するデジタル技術を見据え、概要レベルでシステムのデザイン化を行い、

  • ビジネス・スキーム(ステークホルダー間の関係)
  • ビジネスの流れ(概要レベルでの業務フロー)
  • 画面の概要イメージ

という概要レベルでのすり合わせをまず行わないと、目指すサービスの具体的な姿が見えてこない。つまりデジタル技術を知りながらも、ビジネスの流れを想定しながら、目指すシステムの絵を描いていくという妄想力が必要になる。これまでの要件が出ないと動けないというシステム部門/企業の動きでは、新たな世界は作りにくい。またやはり走りながらも途中で追加要件が出てきたり、法的なチェックからこのような画面も追加する必要がある、などの急な変更が入りやすい。

よって概要レベルでのすり合わせがアジャイル的に何度か繰り返され、かつ設計や開発が具体的に進んでも途中での変更は考えられる。よって設計内容などもなるべくビジネス部門と共有をしながら、完全なウォーターフォールでなく、少し柔軟性を残した開発のプロセスとすることが望ましいと思われる。

矢島 弘士

2/5ページ目