クラウドネイティブ時代の大規模ウォーターフォール開発（CloudNative Days Tokyo 2021 発表資料）
- 1. © 2021 NTT DATA Corporation 1 © 2021 NTT DATA Corporation 2021年11月4日 株式会社NTTデータ 開発基盤モダナイズ エバンジェリスト 菅原 亮 / ITスペシャリスト 菅村 泰隆 クラウドネイティブ時代の大規模ウォーターフォール開発 Web公開向け資料
- 2. © 2021 NTT DATA Corporation 2 はじめに アジャイル開発の手法は日本でも徐々に浸透しつつありますが、 大規模な開発プロジェクトにおいてウォーターフォール開発はまだ主流派です。 ウォーターフォール開発にはウォーターフォールならではの利点もあり、 アジャイル開発にすべてが置き換わることは無いでしょう。 また昨今はアジャイル開発のプラクティスを取り込んで 効率化を目指す動きも活発になってきていますが、 様々な障壁が待ち構えており困難を極めることも少なくありません。 本セッションでは大規模トラディショナルシステムにおける 開発環境のモダナイゼーションを推進してきた経験を基に、 大規模ウォーター開発でのCI/CD適用における障壁や回避策、ブランチ戦略の立て方、 クラウドネイティブ時代にふさわしいウォーターフォール開発の在り方について紹介します。
- 3. © 2021 NTT DATA Corporation 3 自己紹介 名前： 菅原 亮（すがはら りょう） @denkas1973 所属： 株式会社NTTデータ 技術革新統括本部 システム技術本部 生産技術部 ソフトウェア技術センタ 開発基盤モダナイズ エバンジェリスト 得意な分野： インフラ技術全般、特にインフラ自動化分野 Puppetに関する記事や著書をいろいろ執筆 日本Puppetユーザ会 会長 …最近活動できてないけど
- 4. © 2021 NTT DATA Corporation 4 自己紹介 名前： 熊川 一平（くまがわ いっぺい） 所属： 株式会社NTTデータ 技術革新統括本部 システム技術本部 生産技術部 ソフトウェア技術センタ イノベータ(ソフトウェアプロセス) 得意な分野： ソフトウェアテストおよび品質保証を中心に、 開発プロセスの標準化やモダナイズに従事 JaSSTなど各種シンポジウムでの受賞歴多数
- 5. © 2021 NTT DATA Corporation 5 遠く離れた心の距離 大規模ウォーターフォール開発の実情
- 6. © 2021 NTT DATA Corporation 6 遠く離れた心の距離 すぐ近くに居るはずなのに、近くて遠い、触れたい触れられない… 隣のチームのメンバ、あなたにとって近くて遠い存在ではありませんか？ 隣に居るチームのメンバの名前を 僕達はまだ知らない 大規模ウォーターフォール開発の現場では 大抵サブシステム毎にチームが組まれています。 1つのフロアに複数のチームが入っています。 でも隣の列に居る別のチームのメンバ、 誰も名前がわかりません。 リモートになって名前だけでなく、顔までわからなくなった! チームが違うと開発環境、CI/CD仕組み、 さらにはソース管理リポジトリまで別々です。
- 7. © 2021 NTT DATA Corporation 7 せめて、自分らしく… アジャイル開発は少数精鋭、個人の能力を引き出して高パフォーマンスを得ますが、 ウォーターフォール開発ではプロセス、手順を確立し、組織として対応します。 誰でも、それなりに動けるように 大量のドキュメントが生み出される ウォーターフォール開発においては全てプロセス化、 手順化されることで、属人化が排除されます。 それに伴い個人の能力依存が無くなります。 もちろん組織として、プロジェクト推進の上で 属人化の排除は大事ですが、 代わりに大量のドキュメントが生まれます。 また決められた手順から外れる事は悪とされ、 効率化するモチベーションは削がれます。
- 8. © 2021 NTT DATA Corporation 8 せめて、自分らしく… アジャイル開発は少数精鋭、個人の能力を引き出して高パフォーマンスを得ますが、 ウォーターフォール開発ではプロセス、手順を確立し、組織として対応します。 誰でも、それなりに動けるように 大量のドキュメントが生み出される ウォーターフォール開発においては全てプロセス化、 手順化されることで、属人化が排除されます。 それに伴い個人の能力依存が無くなります。 組織として、プロジェクト推進の上で 属人化の排除は大事ですが、 代わりに大量のドキュメントが生まれます。 また決められた手順から外れる事は悪とされ、 効率化するモチベーションは削がれます。 この話を思い出してください 大規模オンプレミス環境はGitOpsの夢を見るか（CI/CD Conference 2021 by CloudNative Days 発表資料） https://www.slideshare.net/nttdata-tech/gitops-and-on-premises-ci-cd-conference-2021
- 9. © 2021 NTT DATA Corporation 9 近づきたいよ、君の理想に 理想の開発スタイルを大規模ウォーターフォール開発でも
- 10. © 2021 NTT DATA Corporation 10 心の距離を縮めたい クラウドネイティブの理想に恋焦がれる大規模ウォーターフォール開発、 両者の心の距離を縮めるにはどうすればよいのでしょう？ 構成管理リポジトリの統合で 離れた心の距離を縮めよう サブシステム毎にチームは分かれていて ソース管理リポジトリもチーム毎に別々に。 いろいろ事情はありますが、まずはリポジトリ統合で 一緒に同じシステムに携わる仲間意識を醸成し、 ツールやCI/CDの仕組みも共通化しましょう。 でも、ブランチ戦略はどうするのが良いの？ 一例をご紹介します！
- 11. © 2021 NTT DATA Corporation 11 心の距離を縮めたい クラウドネイティブの理想に恋焦がれる大規模ウォーターフォール開発、 両者の心の距離を縮めるにはどうすればよいのでしょう？ 構成管理リポジトリの統合で 離れた心の距離を縮めよう サブシステム毎にチームは分かれていて ソース管理リポジトリもチーム毎に別々に。 いろいろ事情はありますが、まずはリポジトリ統合で 一緒に同じシステムに携わる仲間意識を醸成し、 ツールやCI/CDの仕組みも共通化しましょう。 でも、ブランチ戦略はどうするのが良いの？ 一例をご紹介します！ master develop/ST develop/IT ver.1.0 feature/001 feature feature/002 hotfix ver.1.1
- 12. © 2021 NTT DATA Corporation 12 心の距離を縮めたい クラウドネイティブの理想に恋焦がれる大規模ウォーターフォール開発、 両者の心の距離を縮めるにはどうすればよいのでしょう？ 構成管理リポジトリの統合で 離れた心の距離を縮めよう サブシステム毎にチームは分かれていて ソース管理リポジトリもチーム毎に別々に。 いろいろ事情はありますが、まずはリポジトリ統合で 一緒に同じシステムに携わる仲間意識を醸成し、 ツールやCI/CDの仕組みも共通化しましょう。 でも、ブランチ戦略はどうするのが良いの？ 一例をご紹介します！ master develop/ST develop/IT ver.1.0 feature/001 feature feature/002 hotfix ver.1.1 コード昇格モデル
- 13. © 2021 NTT DATA Corporation 13 変換したらYAMLファイルだった件 人間に読みやすく書かれたドキュメントはツールで使うため変換が必要ですが、 パラメーターシートからplaybookに転記するようでは本末転倒です。 ドキュメントから設定ファイルを 自動変換する工夫をしよう 大抵のパラメータ―シート類はExcelで作成。 であればVBAでひと手間掛けるだけで 簡単お手軽にYAMLファイルは生成できます。 お客様に成果物として提供するドキュメントとして Excelは残しつつも、各種ツールで利用可能な YAMLファイルを生成できるのでオススメです。 差分管理もExcelより簡単になります。
- 14. © 2021 NTT DATA Corporation 14 変換したらYAMLファイルだった件 人間に読みやすく書かれたドキュメントはツールで使うため変換が必要ですが、 パラメーターシートからplaybookに転記するようでは本末転倒です。 ドキュメントから設定ファイルを 自動変換する工夫をしよう 大抵のパラメータ―シート類はExcelで作成。 であればVBAでひと手間掛けるだけで 簡単お手軽にYAMLファイルは生成できます。 お客様に成果物として提供するドキュメントとして Excelは残しつつも、各種ツールで利用可能な YAMLファイルを生成できるのでオススメです。 差分管理もExcelより簡単になります。 方眼紙状に正方形のマスが作られた謎書式、 いわゆる“ネ申Excel ” これで変換VBA作るのはほぼ不可能です…
- 15. © 2021 NTT DATA Corporation 15 変換したらYAMLファイルだった件 人間に読みやすく書かれたドキュメントはツールで使うため変換が必要ですが、 パラメーターシートからplaybookに転記するようでは本末転倒です。 ドキュメントから設定ファイルを 自動変換する工夫をしよう 大抵のパラメータ―シート類はExcelで作成。 であればVBAでひと手間掛けるだけで 簡単お手軽にYAMLファイルは生成できます。 お客様に成果物として提供するドキュメントとして Excelは残しつつも、各種ツールで利用可能な YAMLファイルを生成できるのでオススメです。 差分管理もExcelより簡単になります。 方眼紙状に正方形のマスが作られた謎書式、 いわゆる“ネ申Excel ” これで変換VBA作るのはほぼ不可能です… ただし “ネ申Excel” テメーはダメだ
- 16. © 2021 NTT DATA Corporation 16 ここまでのまとめ
- 17. © 2021 NTT DATA Corporation 17 ここまでのまとめ サブシステム毎に分かれたチーム体制に起因する問題の例と解決策、 Excelで作成されたドキュメントを各種ツールで利用する方法をご紹介しました。 リポジトリ統合で「和解」しよう 全体を見れば同じシステムを開発している仲間、 それなのにリポジトリも何もかも別々では非効率です。 リポジトリ統合で共通化、チーム間も「和解」しましょう。 ドキュメントは自動変換しよう ExcelをはじめOffice製品には強力なVBAがあります。 これを使ってYAMLファイルコンバーターを実装して、 納品ドキュメントのフォーマットと両立を図りましょう。
- 18. © 2021 NTT DATA Corporation 18 さらなる効率化への挑戦
- 19. © 2021 NTT DATA Corporation 19 さらなる効率化への挑戦（1/2） ウォーターフォール開発にも、アジャイルで活用されるモダンな開発技術を。 軽量でコンパクトな開発標準 箸の上げ下げまで決めるのではなく 思想や考え方を中心に。 デファクト技術の取り込み 古い開発管理技術(SVN,手動テスト…)か ら脱却。
- 20. © 2021 NTT DATA Corporation 20 さらなる効率化への挑戦（2/2） 例えばExcelの設計書は、Markdown+PlantUMLに。 設計書はプレインテキストに オートシェイプの配置や色使いなど 本質的でないことに拘らないで済む Gitで管理する ソースと同じように、Pull-Requestでレ ビューが回るので効率的。 web化して情報共有する Hugoを使ってhtml化し、設計書にとって 最も大事な使いやすさを向上。
- 21. © 2021 NTT DATA Corporation 21 スピーカー交代
- 22. © 2021 NTT DATA Corporation 22 自己紹介 名前： 菅村 泰隆（すがむら やすたか） 所属： 株式会社NTTデータ 技術革新統括本部 システム技術本部 生産技術部 ソフトウェア技術センタ ソフトウェアアーキテクト 得意な分野： ソフトウェア開発における開発生産性および 品質の安定化を中心に、技術コンサルティ ングや開発プロジェクト支援に従事 バックエンド技術, MSA, Java
- 23. © 2021 NTT DATA Corporation 23 めぐるめぐるよ時代はめぐる 大規模アジャイル視点の開発統制の重要性
- 24. © 2021 NTT DATA Corporation 24 開発統制の重要性 システム・ソフトウェアの品質を作り込むには、開発統制が必要不可欠である。 それは、大規模アジャイル開発でも同様です。 大規模アジャイル開発における 開発統制は、 自由と制約のバランスが大切 1. リポジトリは開発の写し鏡 2. 共通化は悪魔の囁き 3. 技術先行の罠を回避せよ
- 25. © 2021 NTT DATA Corporation 25 開発統制の重要性 システム・ソフトウェアの品質を作り込むには、開発統制が必要不可欠である。 それは、大規模アジャイル開発でも同様です。 1. リポジトリは開発の写し鏡 2. 共通化は悪魔の囁き 3. 技術先行の罠を回避せよ 4. 環境差異をコントロールせよ 「開発ガイドラインを大量に作る」と言うわけではなく、 できるだけ仕組みでカバーしていくこと大切です。 また、開発統制を行うべきポイントを、 納得感ある状況を作り上げる必要があります。 大規模アジャイル開発（SAFe🄬Scaled Agile Framework） SAFe🄬 https://www.scaledagileframework.com/ ART：プロダクト スクラムチームA スクラム チーム B スクラム チーム C … PO SM Dev Team 4, 5名 BO PM RTE SA ART：プロダクト スクラムチームA スクラム チーム B スクラム チーム C … PO SM Dev Team 4, 5名 BO PM RTE SA ART：プロダクトX スクラムチームA スクラム チーム B スクラム チーム C ・・・ PO SM Dev 4, 5名 BO PM RTE SA System Team
- 26. © 2021 NTT DATA Corporation 26 開発統制の重要性 – 1. リポジトリは開発の写し鏡 大規模開発では、ウォータフォール、アジャイル関係なく、 リポジトリの運用方針を、決めてから開発を進めなければなりません。 大規模ウォータフォール開発では、 リポジトリ運用方針は、開発統制に よって、決められていました。 大規模アジャイル開発では、 アジャイルの名の元に、 各スクラムチームに自由が 与えられました。 その結果…
- 27. © 2021 NTT DATA Corporation 27 開発統制の重要性 – 1. リポジトリは開発の写し鏡 リポジトリを見ると、そのプロジェクト（チーム）の状況が手に取るように分かります。 そのプロジェクトの名前は何ですか？ 大規模ウォータフォール開発では、 リポジトリ運用方針は、決められていました。 大規模アジャイル開発では、 各スクラムチーム単位に自由が 与えられました。 その結果… 大規模開発では、ミッションクリティカルな システムが多く、障害発生時は、迅速に解決 するために、第三者が解析に駆け付けます。 各スクラムチームに自由が与えられたことにより、 個性豊かなリポジトリ構成になりました。 スクラムチームA スクラムチームB スクラムチームC
- 28. © 2021 NTT DATA Corporation 28 開発統制の重要性 – 1. リポジトリは開発の写し鏡 リポジトリを見ると、そのプロジェクト（チーム）の状況が手に取るように分かります。 そのプロジェクトの名前は何ですか？ 大規模ウォータフォール開発では、 リポジトリ運用方針は、決められていました。 大規模アジャイル開発では、 各スクラムチーム単位に自由が 与えられました。 その結果… 大規模開発では、ミッションクリティカルな システムが多く、障害発生時は、迅速に解決 するために、第三者が解析に駆け付けます。 各スクラムチームに自由が与えられたことにより、 個性豊かなリポジトリ構成になりました。 大規模開発では、ミッションクリティカルなシステムが多く、 障害発生時は、迅速に解決するために、第三者が解析に駆け付けます。 何がどこに格納されているか、即座に把握するために、リポジトリの統制は必ず必要です。 スクラムチームA スクラムチームB スクラムチームC
- 29. © 2021 NTT DATA Corporation 29 開発統制の重要性 – 2. 共通化は悪魔の囁き 大規模ウォータフォール開発では、当たり前の共通化ですが、 マイクロサービス間でコードの共通化をしてはいけません。 マイクロサービス間の共通化は、 マイクロサービスの切り出し以外で 絶対に行ってはいけないんです。 モノリシックなアプリケーションと異なり、 マイクロサービス間は疎結合でなければなりません。 大規模アジャイル開発では、1つのスクラムチームが 複数のマイクロサービスを担当することがあります。 分かっていても、今までのDRYな考えで、マイクロ サービス間に依存を持たせてしまうケースがあります。 マイクロ サービスA マイクロ サービスB マイクロ サービスC 共通業務 ロジックAB 共通業務 ロジックBC 共通業務 ライブラリ 業務ロジック 業務ロジック 業務ロジック
- 30. © 2021 NTT DATA Corporation 30 開発統制の重要性 – 2. 共通化は悪魔の囁き 大規模ウォータフォール開発では、当たり前の共通化ですが、 マイクロサービス間でコードの共通化をしてはいけません。 マイクロサービス間の共通化は、 マイクロサービスの切り出し以外で 絶対に行ってはいけないんです。 モノリシックなアプリケーションと異なり、 マイクロサービス間は疎結合でなければなりません。 大規模アジャイル開発では、1つのスクラムチームが 複数のマイクロサービスを担当することがあります。 分かっていても、今までのDRYな考えで、マイクロ サービス間に依存を持たせてしまうケースがあります。 マイクロ サービスA マイクロ サービスB マイクロ サービスC 共通業務 ロジックAB 共通業務 ロジックBC 共通業務 ライブラリ 業務ロジック 業務ロジック 業務ロジック
- 31. © 2021 NTT DATA Corporation 31 開発統制の重要性 – 3. 技術先行の罠を回避せよ 日進月歩であるクラウドネイティブ技術を取り入れるのであれば、 アジリティのある組織に変革し、試験自動化を成し遂げなければなりません。 「リリースすることへの恐怖」を克服 することはできていますか？ 商用故障が許されない日本において、 できるだけリリースをしたくはないのが本音です。 クラウドネイティブ技術を利用し、 冪等性を担保する試験自動化を整備すれば、 その恐怖を克服できるかもしれません。 試験の自動化は、ユーザストーリー（E2E）, API（マイ クロサービス）, UT と3段階に分けて実現します。 そのためにもクラウドネイティブの技術は最適です。
- 32. © 2021 NTT DATA Corporation 32 まとめ
- 33. © 2021 NTT DATA Corporation 33 まとめ 大規模アジャイル開発での開発統制の重要性について、 CI/CD関連の実例をご紹介しました。 大規模アジャイル開発での開発統制は、 自由と制約のバランスが大切です。 • リポジトリは、 統一したルールで分かりやすく • マイクロサービス間の 依存関係に注意 • 試験自動化で、 リリースへの恐怖を克服する
- 34. © 2021 NTT DATA Corporation 34 © 2021 NTT DATA Corporation 本資料に記載されている会社名、商品名、又はサービス名は、各社の登録商標又は商標です。