プロセス改善の第一歩に『ハイブリッドアジャイルの実践』
アジャイルというプロセスは、主に小規模な開発案件で適応できるものかと思っていましたが、以下の本を見つけたので読んでみました。
大規模案件へのアジャイル適応のノウハウを事例とともに紹介したものです。ベーシックなアジャイルの導入が難しいときに、部分的にアジャイルの考え方を取り込んだ「ハイブリッドアジャイル」を提唱しています。
著者
株式会社日立ソリューションズの方々が執筆しています。日立ソリューションズは日立グループのIT分野の中枢企業であり、大規模なシステム開発案件も手掛けています。グループ内には別のIT系子会社もあるのですが、日立ソリューションズはその中でも設計に強みを持っているらしいです(中の人談)。本書では、関西電力向けの大規模システムにアジャイルを適用したときの事例が取り上げられています。
本の概要
開発モデルの選択
アジャイルといえばスクラムやXP等の方法論が語られる事が多いですが、それらは数ある方法論の一つでしかありません。アジャイルマニフェストによって宣言されているもののうち、プロダクトが何を重要視するかによって採用すべき開発モデルは変わります。（方法論を愚直に実行するだけでは、開発規模の大小に関わらず成功しません）
大規模開発のウォーターフォール(WF)型をベースとする場合、プロセス全てにアジャイルを導入するのは困難なので、改善すべき課題に合わせて部分的にアジャイル開発を適用します。たとえば
などがあります。
開発プロセスの作り方
開発モデルの選択でも述べましたが、開発プロセスを作る上では目的(現プロセスでの課題)を明確にしてから解決策を検討する必要があります。目的は例えば
- タイムリーな市場投入
- 優先的変更への対応
- 生産性向上
などがあります。ここで決めた目的と、プロジェクトの特性に応じてプロセスを決定します。
ここから、以下の項目について検討します。
- 作業内容の改善
- どの作業を削減するか
- どうやって作業スピードを上げるか
- プロジェクトの管理方法・体制の検討
- 進捗管理の方法
- コスト管理（システム規模の見積もり）方法
- 品質基準
- 変更管理（変更を受け入れるタイミングと手順）
これらを事前決定して初めてプロセスが適用できます。プロセスを実施し、イテレーション毎に改善を進めながら開発を進めることが基本です。イテレーション後・開発完了後の節目には定量評価、定性評価の実施も忘れず行います。
プロジェクト計画
主に以下に留意しながら、プロジェクトを進めます。
- 破綻を避けるための方策
- 仕様変更への対応期限を確定させた上で、ゆとりをもたせたスケジュールを組む
- コスト上限を考慮して計画・委託する
- イテレーション毎に変更管理を実施し、対応要否を検討する
- 適用プラクティスの検討
要点
- プロセス定義の時点で、必ず作業量の削減、作業スピードの向上策を決める（WFモデルと同様の作業としない）
- どの時点でどこまでドキュメントが必要かを明確にし、喫緊でないドキュメントは後回し or 簡略化する。
- 仕様の伝達（不明点の確認）はコミュニケーションベースで。そのために朝会等の双方向伝達を定期的に実施する。
- 伝達ロス削減のため同アイテムに関しては同じ人が設計〜テストまで実施する。
- アジャイル固有の作業を必ず計画する
- イテレーション毎のレトロスペクティブとか
- 変更要望の受け入れ検討時間とかタイミングとか
- 進捗管理はWFよりも細かい単位で行う
- イテレーション単位と日次単位で
- 一日以下で完了できる作業を最小単位とし、進捗の傾向をすぐに把握できるようにする
実践
ペーペーの見習いなので実際にアジャイルを主導するのはだいぶ先ですが、実践する上で以下のプラクティスは優先的に取り入れようと思います。
削減する作業を明確にする
要点でも述べたように、プロセスの実施順を変えただけではアジャイルの成果は見込めません。おそらく多くの場合で、詳細設計等の「品質への影響が小さいドキュメントの作成」を省くことになるでしょう。プロジェクトによって全く作らないか後追いで作るかはまちまちですが、品質要求が高いほど最終的に求められる成果物の量が多くなると思います。「いつの時点で」「どこまで作るか」を予め明確にしておく（必要であれば顧客と整合しておく）ことで、開発者がいちいちドキュメントの粒度や分量を気にせず作業できると思いました。むしろプロセス定義とかそういった次元の話かもしれません。（そういう働きかけをPMまたはPLが積極的に行う事が前提となりますが、少なくとも弊チームでは見たことがありません…）
コミュニケーションを絶やさない
当たり前のことですが大切です。朝会で昨日やったこと、今日やること、懸念点、気がついたことを共有します。そのためにはタスクを日次レベルまで落とし込む必要があり（そうしないと毎日「〇〇の検討をします」みたいな中身のない報告会になります）、進捗管理もやりやすくなります。そもそもアイテム単位の計画を開発メンバが各々で立てて報告するのが最善なのですが、これが以外と難しい。
加えてレトロスペクティブを欠かさないことです。誰がどういった機能を担当したか、どういった問題が発生したか等は最低限共有しないと、自分が次に担当する機能への影響が把握できません（仕様や課題解決の伝達がドキュメントベースだと時間がかかる）。組み込み系ならハードチーム、ソフトチームで速やかに情報共有できる仕組みがほしいですね。
他社の実例に基づく
やっぱり偉い人は前例を欲しがるので、なんやかんやこれに落ち着くかもしれないです。規模の大きい開発の中でも、車載ECUのソフト開発という品質要求の高い事例でのアジャイル適用事例を見つけました。
https://www.juse.jp/sqip/symposium/2019/timetable/files/C2-1_happyou.pdf
ここでは本書で紹介されたプラクティスがいくつか使われていますが、車載開発用にテーラリングされ実績を残しています。個人的には「各メンバの担当、委託先とプロパの責任範囲を明確にする」ということが開発開始前にしっかり行われているのがすごいと思いました。これも当たり前の話なんですが、どうも自分の現場はそこらへんがテキトーでまかり通っているので…。
まとめ
WFモデルをベースに、アジャイルの要素を取り入れるための考え方を学びました。やはり実践にはアジャイルに精通した人が最低一人は必要で、かつプロセス再定義に積極的なPMがいることがスタートラインとなりそうです。
