全4561文字

 DXプロジェクトを進めるパン屋チェーン、JQベーカリー。「DXプロジェクトの進め方[要件定義]」講座で、サービス内容を具体化する要件定義の進め方について説明しました。

 ここからは、いよいよシステムの設計に入ります。中心となるのは、システム開発を委託されたITベンダーです。しかし発注者であるJQベーカリーにとっても、押さえるべきポイントがいくつもあります。

 では、JQベーカリーでの一幕を見てみましょう。要件定義が終わり、一息ついたDXリーダーの和田さんと、PMOの平川さんの会話です。

和田:ようやく要件定義が終わったね。サービスの中身も決まったし、リリースが待ち遠しいね。

平川:そうですね、でもここからが長いんですよね。設計や開発には時間がかかるし、出来上がったシステムのレビューも大変ですね。

和田:結構大変だよね。他社に先駆けて一刻も早くリリースしたいし、我々はただ悠長に待っているだけでいいのかな……。

平川:確かに。それに、システムに詳しいメンバーばかりではないので、きちんとレビューできる体制が組めないかもしれません……。

和田:うちとしては、どう取り組めばいいのだろう。

 新サービス系DXプロジェクトの場合、サービスのリリースを迎えるというのはゴールではなく、スタートラインに立ったにすぎません。まずサービスをリリースし、ユーザーの反応を見ながら改善するのがあるべき姿です。つまり開発期間を長く取り、リリースを悠長に待つのは得策ではありません。

 もちろん、一定の開発期間は必要です。新サービスの場合でも品質は求められますから、それを満たすにはそれなりの時間がかかります。ただ、プロジェクトのメンバーが品質確保に貢献できるかというと、そうでもありません。DXプロジェクトにアサインされるメンバーのうちシステム部門以外の人は、システム開発自体に不慣れです。これらのメンバーが、ベンダーの報告や成果物を基に、品質確保の役割の一端を担うのは難しいのが実情です。