全4654文字
PR

アジャイル開発において、リリース(本稼働)はゴールではない。システムの「価値」を高め続けるため開発を継続し、運用チームにも引き継いでいく。社内システムのアジャイル開発で成長したチームをさらに成長させるのが、DXの舞台だ。

 アジャイル開発の経験が少なく、中央集権型の日本企業において、組織や文化を変革せずこれまで通りに開発ベンダーを活用しながら、SoR(System of Record)領域の業務システムのアジャイル開発を成功させるにはどうすればいいのか。そのポイントを解説する連載の7回目(最終回)である。

 第5回と第6回では、開発工程における要点について解説した。最終回である今回は、初回リリース(本稼働)後に注意すべき6つのポイントについて、事例を交えながら解説する。

ポイント1:バグ対応と新規開発、優先させるのはどっち?

 1つ目のポイントは優先すべき対応事項の決め方だ。

図 作業の優先順位を決めるプロセス
図 作業の優先順位を決めるプロセス
「バグ」と「要望」のどちらを先に対応するかを同じ土俵で決める(出所:シグマクシス)
[画像のクリックで拡大表示]

 よく知られる通り、アジャイル開発ではリリースはゴールではない。リリース後も開発を続け、より価値の高いシステムを提供していくことが前提の開発手法である。原則として開発チームは初回リリース後も開発し続け、「バグの修正」「機能の改善」「新規機能の開発」の3つを並行していくことになる。

 ユーザーはシステムを減点方式で評価するケースが多く、良い部分(実現できたこと)よりも悪い部分(不具合やバグ)に目を向けがちだ。そのためユーザーからの批判を減らしたい情報システム部門や現場部門の管理者は、ユーザー側の代表者としてプロダクトの価値を最大化する役割を担う「プロダクトオーナー(PO)」に対して、「できるだけバグを早く解消したい」と働き掛けてくる。

 開発者自身もウオーターフォール型で習慣となった請負契約における瑕疵(かし)担保責任の感覚に追い立てられて、バグ修正から先に手を付けるものだ。「バグだから」「すぐに対応できるから」と優先順位を上げて作業しがちだが、1つのバグの修正が数珠つなぎで他のバグ修正につながる例は珍しくなく、そうなると結果的に対応に多くの時間を費やしてしまう。

 実際に現場のユーザーにヒアリングすると、バグの修正よりも機能の改善や新機能の開発を優先してほしいという声は少なくない。限られた工数で最大限の価値を出すには、無条件にバグの修正を優先するのではなく、「バグの修正」「機能の改善」「新機能の開発」を同じ基準の土俵に上げたうえで優先順位を決める必要がある。

 ある企業が社内で使う「通知・通達システム」をアジャイル開発で再構築した際、初回リリース後に出てきたバグや要望への対応優先順位を「業務への影響度」と「対応工数」の2軸のマトリクスを使って評価した。「フォントの色が違う」「項目名が統一されていない」といったバグは、表記を統一してユーザーに分かりやすくするという点では修正する意味があり、対応工数としては軽微である。

 だが投資対効果の評価基準に照らすと修正する「価値」は高くないため、バグ対応を先送りした。これに対してユーザーの批判はなかった。

 対応を優先させた追加機能の業務への効果が、バグ修正の効果を上回っていたからだ。特定の条件でのみ発生する頻度の低いバグの対応も同様に遅らせたが、現場からの不満はなかった。