NTTコムウェアのアジャイルとScrum Fest Osaka 2021 TOPページへ
2021年6月25日・26日の2日間、Scrum Fest Osaka 2021がオンラインで開催された。このイベントは、スクラムやアジャイルプラクティスに関心が高いユーザー企業やIT企業から集結したエキスパートや初心者たちが、自らの知識や情熱を共有するために活発な議論を行う場である。NTTコムウェアからはAgileエバンジェリストの伊山宗吉が登壇し、ウォーターフォール(WF)開発とアジャイル開発における“品質”のギャップと対処について語った。
(講演資料はこちら)※外部サイト
関連記事
<開発者の現場で考えるべき、プロダクトの品質とユーザー視点の品質>
<アジャイル推進組織奮闘記~NTT コムウェアの場合~>
NTTコムウェアは現在、SoE拡大のため、ウォーターフォール開発からアジャイル開発へのシフトを積極的に進めている。さまざまな課題に直面してきた中で、今回のテーマは“品質”。
長年、ウォーターフォール開発で培ったノウハウや仕組みによって、NTTなどライフラインに関わるような大規模システムに求められる高い“品質”を確保してきたが、アジャイル開発にそのまま適用するには大きなギャップがある。このギャップを埋めようとした営みで、大きく4つの課題が顕在化した。
これらのギャップを埋め、システム開発における“NTT品質”を守るために行われてきた施策をここに紹介する。
ウォーターフォールでは、NTTコムウェアを始め多くの企業で蓄積した豊富なノウハウを組織的に活用できるよう、管理方法や成果物としてバグ密度や収束判定、試験項目表などの標準化・共通化が進められ、ドキュメントに定義されている。
しかし、アジャイル開発においてそのままでは使えない。そこで、“スクラムガイド”※をベースに「NTTコムウェア用アジャイル開発ガイド」を作成した。
“スクラムガイド”の考え方はそのまま継承するが、共通認識として使うために、現場での具体的なやり方を補完する必要があった。そこで自社の状況に合わせた、開発前の企画や準備段階の記述を増やしている。
※スクラムガイド スクラムの定義、理論が記載されているKen Schwaber & Jeff Sutherlandによる⽂書で、スクラムの考え方の原典とされる。直近の改訂は2020年版。
そして、「NTTコムウェア用アジャイル開発ガイド」には“スクラムガイド”にない項目を1つ追加している。それが今回のテーマである“品質”に関する役割である。
アジャイル開発においても“品質”をしっかり担保するため、“スクラムガイド”で不足している品質管理のロール(役割)を定義し、「クオリティコントローラー」と名付けた。このロールは開発の品質状況を可視化し、懸念事項の透明性を確保するとともに、継続的な改善をスクラムチームに促す役割を担う。
しかし、他のロールの邪魔になるようではアジャイル開発の良さが生きてこない。よって、品質改善の活動は促すが、“品質”の責任はスクラムチーム全員で持つと定義した。「クオリティコントローラー」は、スクラムマスターにおけるインペディメントリスト(障害一覧)に相当する、“品質”の懸念を可視化するためのリストを定義し、“品質”へのアプローチをより手厚く行っている。
また、多くの場合において、アジャイル案件の増加が、経験者や知識を持った人材の育成・増加よりも速くなる。NTTコムウェアでも問題案件が発生した際、課題の根本にあったのは、アジャイル開発に対する基本的な理解の不足や誤解だった。
そのような状況では、スクラムチームの自主性や工夫を前提にしたアジャイルの思想に基づく開発ガイドだけでは不十分だと結論づけ、プロセス改善を促すために「各プロセスにおけるチェックポイント」を作成して展開。
チームとしてプロダクトの“品質”を高めるために各タイミング(企画、開発準備、各種スクラムイベント、リリースなど)のチェックポイントを整理し、メンバーの経験のあるなしでバラつきがでることを防げるように、開発メンバーの共通理解への対策とした。こうして、アジャイル開発の“品質”の保証に挑んでいる。
アジャイル推進組織にいる者はコーチとして、さまざまな案件の支援に入っている。担当した現場にあった課題と解決策、よくある勘違い、チームに対する研修資料などのノウハウをポータルサイトにまとめて情報発信している。
もちろんポータルサイトを見てもらうだけでは足りないため、部門横断でノウハウ情報を共有する場として、『アジャイル推進連絡会』を発足させた。ここでは各部門でアジャイルを実践しリードしていく立場のメンバーを中心に、技術やプラクティス、課題の共有に留まらず、案件特化でのノウハウやお客さま対応の相談、アジャイルに適した社内制度の改善要望の取りまとめなど、各案件の開発、そして“品質”に寄り添った場所になっている。
関連記事
<開発者の現場で考えるべき、プロダクトの品質とユーザー視点の品質>
<アジャイル推進組織奮闘記~NTT コムウェアの場合~>
ウォーターフォールの大規模開発では、領域毎にスペシャリストが率いる専門チームを作り、この専門チームが知見を深め、各々の専門性を高めていくことで、“品質”を守る仕組みだった。
しかし、アジャイル開発の個々のスクラムチームに対して、この専門チームをバラバラにまぶしてしまっては、スキル差が生まれ“品質”を守ることはできない。そこで以下の方針を整えた。
ただし、もちろんこれはとても難しいことで、支援者の力を借りて、日々苦労しながら進めている。(一部は次期スペシャリスト候補として育成)
各領域のスペシャリストは要求・設計・テストの実施および確認方法の方針の作成、テストのバリエーションや非機能要件の確認など、“品質”を守り、多能工人材を育成するために多岐に渡る支援を行って、“NTT品質”へのアジャイル開発に挑んでいる。
ウォーターフォールでは、ソフトウェアの工程完了に向け、最後に統合して試験を行う。バグは修正が進めば収束する。蓄積した過去の類似案件を元に試験密度・バグ密度などのデータを各プロセスで評価できる。
しかし、アジャイルでは都度、統合して試験し、バグがでたらすぐに修正という動きであり、短期で変わり続けるソフトウェアを確認することになる。優先順位の高いものから開発するため、いつ複雑な機能のバグとそうでないバグが出ているのか分かりにくく、収束傾向であるかの判断も難しい。
こうしたことから、アジャイルでは、蓄積したデータを比較する、ましてや他のチームや案件のデータと比較することはたいへん難しいことになる。
多くの会社でも同様の悩みから、アジャイルでの品質評価は、いったい何を比較すればよいのか、という課題が提示されている。採用技術や開発プロセスの多様化により他案件の統計データと比較も困難である。
しかし、自身のチームの各反復は類似性があるので、過去の自分たちのチームと比較することは可能であると考えられる。
そこで現在取り組んでいるのは、自身のチームでの品質管理データを継続的に収集・蓄積し、“品質”に関するなんらかの予兆を検知し是正する、あるいは問題が発生した時の原因分析に用いる、というアプローチである。
とはいえ、やはり将来的にはチームを横断する分析評価を行いたい。案件数が増え、データの蓄積が進んでいく中で、品質評価につながる知見を獲得し、NTTコムウェアの強みとしたいと考えている。
ここまで紹介したアジャイル開発における“品質”に関する対応には、難しい部分も多くあるが、具体的な活動への反映も始まっている。
私たちが大切にしてきた“品質”、そして高い“NTT品質”についての挑戦は、今後も継続して取り組みを進め、成果を多くの方々と広く共有していきたい。また、他社で行われている“品質”についての取り組みもこのようなコミニティイベントなどを通してぜひ学んでいきたい。
本セッションをきっかけとして、今後さらにアジャイル開発における“品質”について、情報や意見の交換ができるようになれば良いと考えている。
エバンジェリスト(Agile)
コラム一覧