プロジェクト企画
2-20
小さなリリース単位
- 状況
-
kintoneで複数の業務アプリを構築している。それぞれのアプリは単体でも業務改善の効果があるが、効率を考えて全て同時にリリースしようと考えている。
- 問題
-
一度にたくさんの業務アプリをリリースすると、現場ユーザーからのフィードバック対応や不具合対応が膨大になってしまい、対応しきれない可能性がある。
一度にたくさんのリリースをしてしまうと、複数のアプリに対してユーザーからのフィードバックが集中してしまう。フィードバックの対応に時間がかかると、現場ユーザーの満足度が低下してしまうかもしれない。
また現場ユーザーは一度にたくさんのことを覚えきれず、アプリを使いこなせないかもしれない。何か問題が発生したときに「業務アプリの不具合」によるものなのか、「ユーザーの慣れ」によるものなのか、切り分けが難しくなる可能性もある。
たくさんの業務アプリのリリースタイミングを揃えようとすると、スケジュールを最もリリースの遅いアプリに合わせることになり、結果的に現場ユーザへの価値提供が遅くなってしまう。
- 解決
-
業務アプリのリリースは、小さい単位で提供する。
単体で業務が回るアプリから優先してリリースし、現場ユーザーに価値を提供しよう。リリースを【素早く繰り返す】(0-02)ことで現場ユーザーからのフィードバックも早くもらえる。
【小さなリリース単位】(2-20)で業務アプリを提供する際には、「コース料理のメニュー表」のように「リリースの全体像」や「いつ、どんなアプリがリリースされるか？という計画」を提示することで現場ユーザーも理解しやすくなる。
- 結果
-
現場ユーザーは日々の業務を一度に大きく変更するのではなく、小さい単位で業務アプリを使い始めれば良いので、比較的容易に新しい業務アプリに慣れる事ができる。また、現場ユーザーをサポートするIT部門の負担も平準化できるだろう。
【小さなリリース単位】(2-20)で業務アプリを提供すると、現場ユーザーからフィードバックを早くもらうことができるので、それを活かして次にリリースする業務アプリの品質向上に役立つはずだ。たとえば「日報アプリ」のリリース後に「顧客従業員規模という項目が欲しい」というフィードバックがあれば、その項目を次にリリースするアプリに事前に組み込める。より業務にフィットしたアプリとしてリリースできるはずだ。
また業務システム全体のロードマップを提示することで、現場ユーザーの混乱も小さく抑えられるだろう。
