CNDT2021、大規模ウォーターフォール開発をクラウドネイティブにするためのヒントをNTTデータのエバンジェリストが解説

CNDT2021はクラウドネイティブなシステムに関連するカンファレンスだ。そのため、ウォーターフォール型開発のプロジェクトを手掛けているエンジニアに対してクラウドネイティブに向かうための方法論を解説するセッションがあってもよいだろう。今回は、そのようなセッションを紹介する。プレゼンテーションを行ったのは株式会社NTTデータ システム技術本部生産技術部 ソフトウェア技術センタ所属のエバンジェリスト菅原亮氏とソフトウェアアーキテクトの菅村泰隆氏だ。

動画：クラウドネイティブ時代の大規模ウォーターフォール開発

セッションは前半を菅原氏、後半を菅村氏が担当する形で始まった。全体を通じて技術的な内容というよりも、取り組み方、注意点、改善方法などを解説する形になっている。注意して欲しいのは、前半は大規模ウォーターフォール開発における改善点の解説となっているが、後半は大規模アジャイル開発によってマイクロサービスを開発する際の注意点の解説となっていることだ。

この点はプレゼンターである菅原氏にも確認済みで、前半は大規模ウォーターフォール開発の内容だが、後半は大規模アジャイル開発、そして菅村氏が得意とするマイクロサービスに関する話に寄ってしまったと回答を貰っている。

プレゼンテーションを行う菅原氏

ウォーターフォール開発における改善点

菅原氏は、すべてのソフトウェア開発がアジャイル開発に替わることはないと考えており、またウォーターフォール開発にも利点はあるとして、クラウドネイティブ時代にふさわしいウォーターフォール開発を提案したいという。

アジャイル開発が個人の能力に依存するのに対してウォーターフォール開発は組織で対応

大規模ウォーターフォール開発では多数のエンジニアが組織されるが、実際には他のチームが何をやっているのかは知り得ないことが多いことを指摘。ここの説明では「協力会社」という名称が出てくるように、さまざまな企業が下請けの形で参加するかたちで大規模ソフトウェア開発を経験してきたNTTデータらしい実感だろう。その上で規模の大きい組織をまとめるためには、大量のドキュメント、ルールや手順などが作成されることを指摘した。

大規模チーム内の距離感を減らすためにはリポジトリーの統合を

その上で大規模ウォーターフォール開発においては、組織やレイヤーごとに作成されるソース管理のためのリポジトリーを一元化しようと提案している。さらにCI/CDやツールも共通化することで、チーム間のコミュニケーションが良くなると説明した。

異なるチームでリポジトリーを一元化する際のベストプラクティスとは

ここでソースコードリポジトリのブランチに対するベストプラクティスとして「コード昇格モデル」という方法を提案した。これはマスターからシステムテスト、結合テストのためのブランチの下に機能ごと、つまり協力会社ごとのブランチを作り、それを上流のブランチにマージしていくことで最終的なマスターブランチのリリースができあがっていくという方法だ。緊急度の高いバグなどについてはHotfixという形でブランチを作り、それをマスターにマージするという実践的な内容となっている。

構成情報などのExcel管理から脱却しようと提案

またドキュメントについては、従来のExcelシートで管理されている構成情報などのパラメータシートは、いきなりExcelで書くことを止めさせるのではなく、VBAを使ってYAMLに自動変換する仕組みを実装することを提案している。コードの形になれば、Gitなどを使った差分管理も容易になることなどを説明した。ただしExcelを方眼紙のように使ってワープロとして利用するようなやり方は救いようがなく、すぐにでも止めることを強調した。

前半のまとめ

ここまででソースコードリポジトリの統合と、パラメータシートなどのドキュメントの自動変換を提案。さらにウォーターフォール開発であってもアジャイル開発に利用されるツールなどを要所要所に適用することで、ウォーターフォール開発であってもデベロッパーを助けることができると説明した。

Excelの設計書を止めてMarkdown＋PlantUMLに

またドキュメント作成という部分については、特に踏み込んでMarkdown記法とPlantUMLによるダイアグラムを使うことで、テキストベースでダイアグラムが生成できることを説明。Excelの図形を使ってフローや構成図を書くことを止めようと提案した。

PlantUMLについては以下を参照されたい。

参考：https://plantuml.com/ja/

アジャイル開発における開発の統制

後半の菅村氏のプレゼンテーションは大規模なアジャイル開発における開発の統制に関するもので、前半の大規模ウォーターフォール開発とは別の内容になっている。

大規模アジャイル開発には開発統制が必要

ここではアジャイル開発において自由と制約のバランスが重要だとして、アジャイル開発を行うスクラムチームがそれぞれ勝手にソースコードリポジトリを使い始めるとどうなるのか？ を説明した。

統制がないスクラムチームによる弊害の説明

この弊害は単に統制が利かないだけではない。ミッションクリティカルな大規模システムにおいては、障害発生時に開発を担当したエンジニア以外の第三者が解析を担当することが有り得る。そのため、どのチームのリポジトリーも同じような構成、命名基準、採番基準が必要になることを指摘した。ここでも、NTTデータのソフトウェア開発の知見が表れていると言えるだろう。

モジュールの共通化はマイクロサービスにおいてはアンチパターン

このスライドでは、開発チームが複数のマイクロサービスを担当する際に、共通ロジックなどを切り出してモジュール化することはやってはいけないと強調した。菅村氏がコメントした「DRYな考え方」というのは「Don't Repeat Yourself」の略でDRY原則と呼ばれるものを指している。DRY原則では同じ情報は重複して存在してはいけない、同じ機能を果たすものを複数作ってはいけないと考えられているため、共通モジュールなどを切り出して実装することを指していると思われる。しかし、マイクロサービスにおいてはモジュール間の結合を強めてしまうために避けるべきという意味だろう。

頻繁にリリースすることの恐怖を克服しようと提案

このスライドではアジャイル開発、マイクロサービス開発においてはリリースを頻繁に行うことが求められているが、実際にすでに稼働しているソフトウェアを置き換えることには不安が伴うことに理解を示している。それでも、頻繁なリリースを可能にするにはテストの自動化が必須であると解説した。またクラウドネイティブなシステムのコアとなるオープンソースソフトウェアも、頻繁にリリースされている状況を考えれば、アプリケーション以外にも頻繁なシステムの更新は必須であると説明した。

後半のまとめ

最後のまとめではアジャイル開発において開発統制は必須であり、リポジトリーのルール作り、マイクロサービス間の依存関係のチェック、テストの自動化が必要であると解説した。

前半の大規模ウォーターフォール開発に関する解説と、後半の大規模なアジャイルによるマイクロサービス開発の解説は別々の内容となっており、そのことを把握した上で視聴することでウォーターフォール開発に従事している担当者も混乱を避けることができるだろう。