全4351文字

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

 最終回となる今回は、初回リリース(本稼働)後に注意すべき6つのポイントについて、事例を交えながら解説する。

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

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

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

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

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

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

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

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

 だが投資対効果の評価基準に照らすと修正する「価値」は高くないため、バグ対応を先送りした。これに対してユーザーの批判はなかった。対応を優先させた追加機能の業務への効果が、バグ修正の効果を上回っていたからだ。特定の条件でのみ発生する頻度の低いバグの対応も同様に遅らせたが、現場からの不満はなかった。

ポイント2:IT統制と予算を意識しているか

 2つ目のポイントは「IT統制」とお金についてである。

 上場企業やその連結子会社には内部統制が求められており、システム部門はIT統制に取り組む必要がある。これまでウオーターフォール型開発に合わせて構築してきたIT統制をアジャイル開発に合わせて一部見直す必要がある。

 具体的にはIT統制の観点では「新規開発中の機能」と「リリース後の機能」を明確に分ける必要がある。「新規開発中の機能」については開発者が随時デプロイできる一方、「リリース後の機能」についてはそれを許してはいけない。

 「リリース後の機能」にはユーザーが使う業務データが蓄積されているため、データの改ざんを防ぐ必要があるためだ。新規開発の機能とリリース後の機能でデプロイ手順が異なると開発現場が混乱するケースもあるだろう。