この記事は、筆者が小売業の業務改善・システム刷新プロジェクトの要件定義から設計・開発・テスト・リリースまで経験して感じた、反省と次のアクションについて雑多に書いたメモである。
※完全自分用メモですが、ほんの少しでも同業の方々のプラスになったらいいなと思い公開しました。
#要件定義
-
できれば要件定義前に、顧客の業界を全力でキャッチアップする。
- 業界本2冊くらい読めばだいぶ詳しくなれるはず。このスタートダッシュは超重要。顧客の業界や業務について何も知らない状態では何も革新的な発想なんてできやしない。少しでも情報があれば、ふとした瞬間の課題に対するアプローチの幅が広がるはず。
-
このフェーズでどれだけ顧客と気軽にコンタクトを取れる状況を作っておけるかが、後続フェーズでは鍵となる。
#基本設計
-
サブ、チーム間で線を引いて設計してしまった。そのためシステム間で仕様の認識があっていないところがあった。最低でもチームリーダーはシステム間のつながりや仕様を考えた設計を意識しなければならない。システム全体としてあるべきは何か？から逆算して自サブ機能を設計すべき。
-
リーダー的な役割を担う、システム間のつながりを意識してチーム全体の設計を見るなら、自分でタスクを持たない方がいい。（タスク抱えすぎてボトルネックに。。。） 要件決めまでやって、あとばざっくり設計にとどめてメンバーにパスすべきだった。
-
DFD,ERDは縦に線を引いて見てはいけない、他サブ、横のつながりで見ないと。
-
DFD,ERDはチーム全体でウォークスルーすべき。
- SDの中盤でやったけど、その時点では各機能の使用が詰まっていなかった。おそらく、PG入る前とかでもう一回やるべきだった。これをやっておけば、サブ間で仕様の認識齟齬とか、課題を早い段階で見つけることができる。
-
顧客相手に、要件と各機能の設計レベルのウォークスルーをやらなかったこと。
- プロジェクトリーダーがは、大きなリスクであることを認識し、PGフェーズとかでもやるべきだった。
- 今後は、SDフェーズ完了後、内部と顧客それぞれで業務要件と付き合わせた設計レベルのウォークスルーをやる。
-
画面を設計するときは、業務パターンを全網羅した設計を考え抜く。
- 期限的にもタイトだったため、業務オペレーションの考慮漏れの多い設計になってしまった。
- かっちりと時間内で決められたアジェンダで、ということを意識しすぎると、結果としてあまりいい設計はできないかも。気軽に業務の質問とかできるようにならないと品質上がらない。
-
1機能に要件を詰め込みすぎない、複数のことができるようにしない。
- 要件を詰めに詰め込んだ画面を設計してしまったことで、機能の難易度が跳ね上がった。スキルのあるメンバーしか開発できない画面になってしまったし、パフォーマンス面の課題も最後まで解決できなかった。
- 要件を分解して適切な機能分割を提案できるようにならないと。
-
SQL考えるときは、各テーブルのレコード件数を意識する。できるだけ駆動表が小さくなるように設計する。
-
画面の検索条件の必須項目設定に関しては、顧客のオペレーションを具体的に想像して、ヒアリングして、パターンにあったように設定する。検索した時に、この条件だとレコードが何件帰ってくるか具体的に想像して設計しないと。
- サクッと画面モック作って、早めに触ってもらったほうが後の仕様変更のリスクが小さくなる
#開発・単体テスト
-
パフォーマンスを意識したSQLを書くように意識する。
- 駆動表が小さくなるように意識してクエリを書くべし。
- 具体的にSQL実行時の処理イメージを持ちながら実装するとパフォーマンス良いSQLが作れるはず。
-
機能単体の品質が後続フェーズでは響いてくる。単体テストパターンは省略せず妥協せずやりきって品質を高める。
#結合テスト
- 初めからテストパターンをしぼってはいけない。
- 初めは全パターン洗い出す。その後に、残りの工数見合いで各テストパターンの実施要否を決めていくのがベスト。全ケース洗い出してかつテストケースの優先順位や色付けをしておくと、どこまでのテストを実施すればどの程度の品質が保証できるのか示すことができる。
#システムテスト
- このフェーズでは、基本的に仕様変更は受け付けてはいけない。
- このタイミングでの仕様変更はとてもリスクが高い。
- 仕様変更を対応する場合は、顧客にきちんとリスクを説明した上でお金と時間をいただく。
・システム間の重要なパターンをもれなく検証する。
・あらかじめシステム間結合で怪しそうなところは意識しておく
#リリース直前
-
胸を張って「リリースして問題ない」と言え得るレベルになっているか？ 言えないなら懸念点を名文化する。一人で抱え込まない。プロジェクトメンバーと課題は共有して、一丸となって課題解決に当たる。壁はつくらない。顧客調整が必要な場合は早急に行う。
-
現行システムからの移行を伴うプロジェクトの場合は、移行専任チームが組まれることが多い。このチームには絶対に業務とアプリの仕様に詳しいメンバーが必要。チームにいないなら、積極的に業務・アプリを知っている外部メンバーがフォローしないとリリースやばい。