各工程で開発マネージャとして意識すべきポイント
こうして企画／計画を完了させた小山氏が、次に取り掛かったのは要件定義だ。この工程を進めるにあたって小山氏は、「要件検討会の推進」と「要件概要書等の作成」という2つのタスクを軸に据えた。
要件検討会では、業務部門との定例会を通じて、要件と課題の調整を進める旗振り役を務めた。この取り組み自体にウォーターフォールとの大きな違いはないものの、スムーズに進めるためには「会議の前準備が重要」として、その内訳を次のように説明した。
「まずは、既存システムの不要な機能を事前にスリム化しておくこと。これにより無駄な議論を防ぎ、スケジュールの延長リスクを低減できる。
また、ユーザーとの定例会などの事前検討会を軸に、週次サイクルを構築し、資料作成やレビューのポイントを明確にしておくことも重要だ。この定例会も『なんとなく』で実施するのではなく、事前に論点とストーリーを決め、理想のアウトプットから逆算して議論するのが望ましい。
さらに検討会当日は、ユーザーから上がってきた要望を抽象化し、根本的な課題に焦点を当てるようにもしたい。例えば、『Excelファイルのアップロード機能が欲しい』という要望があった場合、背景にあるのは『入力が手間』といった根本的なニーズのはずだ。要望の深掘りを行うことで、いたずらに機能を増やすことを防げる。結果、工数の削減にもつながるわけだ」（小山氏）
一方の要件概要書については、ウォーターフォール型との違いが現れた。小山氏によれば、本プロジェクトのドキュメントは「ウォーターフォール型の詳細な要件定義書とは異なり、業務フローや業務ロジックといった普遍的な部分に焦点を当てた簡潔なものになった」という。UIなどの頻繁な更新が予想される部分には触れず、容易には更新されない部分のみを記載することで、後の保守やメンテナンスに役立つ構成としたのだ。
加えて小山氏は、要件概要書の他にも業務フロー、ビジネスルール、課題一覧、プロダクトバックログなどをこのフェーズで作成しておくことを推奨している。
要件が固まったら、いよいよアジャイル開発工程だ。この工程において小山氏は、「プロダクトバックログの管理」と「スプリントレビューの推進」のタスクを担った。
まず、プロダクトバックログは、要件定義で作成した要件を基に、システムに必要な機能を整理し、優先順位をつけて管理するリストのことだ。ウォーターフォールにはない概念であり、継続的なメンテナンスと調整が求められる。
このタスクで特に重要なのは、各機能の背景と必要性を明確にすることだという。「背景情報をしっかりと記載し、要件概要書との整合性を保つことで、後の工程で機能が増えても、目的や必要性が曖昧になることを回避できる」と小山氏は強調する。
機能の優先順位を「高・中・低」に分けたうえで、それぞれの優先度を数値化する工夫もした。なおかつこれらを継続的に見直し、改善することが「プロジェクトの成功に直結する」というのが、小山氏が得た知見だ。
一方、スプリントレビューの推進は、ユーザーからのフィードバックを元にシステムの改善を進めることを指す。このタスクについて小山氏は、「ユーザーに示す観点を決め、事前に練習することで、意味のあるフィードバックを得ることが重要だ。またそのためには、明確な受け入れ基準を定義し、ユーザーに見てもらうべきポイントを明示することも欠かせない」と話す。
さらには、ユーザーからのフィードバックを「修正」「改善」に切り分けることも大切だと小山氏は話す。「修正」は仕様通りに機能していない箇所への対応、「改善」はさらなる最適化であり、プロジェクト完遂に向けて優先すべきは「修正」だからだ。両者の混同を防ぐことで、開発チームの"わき見"を防止できるわけだ。
こうして、開発工程は結合テスト・総合テストへ。この工程において小山氏は、テスト計画書の作成と実施を主なタスクとして担当した。
ウォーターフォールとの違いについて、小山氏は「必要最低限の計画書のみを作成し、全体計画書や細かい工程ごとの計画書は作成しなかった。これにより、テスト実施の範囲が明確になり、作業を効率化できた」と語る。またテスト実施時にも、過剰なエビデンス取得はせず、最低限のポイントに留めたという。
テスト計画書の作成にあたっては、テストの目的や方針、各テスト工程の内容を明確に定義し、特に「どの範囲をスコープしたテストか」を明記。これにより、テストカバレッジを明確化しつつ、オーバーラップを減らした。
小山氏は、テスト工程における成功の秘訣として、「確認観点を明確にし、要件と紐付ける」ことを挙げた。要件定義フェーズで作成した要件概要書とテスト計画書をリファレンスとして参照し合うことで、テストの目的がブレることを防げるのだ。
