ウォーターフォールでも良いもの作りたい！アジャイルと従来プロセスの狭間でもがいてみる

初めまして、NTTテクノクロスの西原といいます。
普段はアジャイル開発のスクラムマスターやウォーターフォール開発のPLを担当しています。
この記事はNTTテクノクロスアドベントカレンダー2023、9日目の記事です。

本記事は、従来のウォーターフォールプロセス(以下、WF)によるシステム開発にアジャイルマインドを取り入れることで、WFでの進め方を大きく崩すことなくより良いものを作ろう(より良いものを作れるチームにしよう)という取り組みについて書いています。

こういう方におすすめの記事です！

• WF開発に従事しているが、チームでの仕事の進め方をもっと良くできないか悩んでいる方
• アジャイル開発に挑戦してみたいが、いきなりはハードルが高そうなので十分に準備してから挑みたいと思っている方

■初めに

皆さんはアジャイル開発を経験したことがありますでしょうか？
IT業界でアジャイルという言葉が出てきて約20年、多くのITエンジニアがアジャイル開発に挑戦してきました。
一方、すべてのシステム開発がアジャイルになったわけではなくWFでの開発も未だ多く存在しています。(私がこれまで担当してきた開発もWFが大半でした)
しかしながら、世に出ている「今どきの開発手法」「最新の開発プロセス」といった解説本や解説記事は基本的にアジャイルにおける進め方や手法について言及しており、WFについては
「すべてのシステム開発にアジャイルが適しているわけではなく、従来のWFを採用したほうが良い場合もある。」
といったアドバイスで済まされてしまうのが現状です。
例えばPMBOKを見てみると、第7版にて大幅に改定されアジャイル開発で重視される要素にフォーカスを当てた内容になりましたが、第6版までと大きく変わったため「従来のWF開発に従事している人はどう変わっていけば良いのか？」という点については分かりづらいものになっています。

以降の章では

• 「WFの工程にどうやってアジャイルマインドを取り入れるか？」
• 「WFの改善のためにどういう取り組みが考えられるか？」

という課題について、アジャイルとWF両方の経験を元に対応内容を記載していきます。
※ここで記載している内容が正解というわけではなく、私自身も試行錯誤中の真っ最中であることはご了承ください。

■取り組み内容:日常の活動

まずは日常的なプロセスについて書きます。
実践してみた感想としては、チームの改善という意味ではここが一番重要なのではないかと感じています。

改善案

• 毎日の朝ミーティングを実施する
• 工程ごとのチーム振り返りを実施する

・朝ミについて
アジャイルでは、毎朝開発チーム全員が集まって自身のタスクや課題を共有する軽めのミーティングを実施します(10分～15分程度)
WFでもチームメンバのタスク確認や課題管理は大事です。
ですが、忙しくなるとつい「リーダーが一人でタスクチケットを整理して終わり」「メンバからの進捗報告をチャットで見て終わり」になりがちです。
ここで意識しておきたいのは、少しでもメンバ同士で対話することが重要ということです。
「報告するほどではなかったんですがそういえば～」みたいな会話から意識できていなかった課題の発見につながることはよくありますし、何よりチームメンバとのコミュニケーションが活性化します。

・振り返りについて
アジャイルではスプリント単位(だいたい2週間)でチームメンバ全員を集めた振り返りを実施します。
何か機能を一つ開発完了する度に振り返りを実施するイメージですね。
しかしこれをWFにそのまま適用しようとすると開発完了時=PJ終了時となってしまい、振り返りのタイミングとしては遅くなってしまいます。(数か月前のことを思い出しながら振り返りするのって結構しんどいですよね？)
ですので、WFでの振り返り実施タイミングは各工程終了時をおすすめします。
※ただし、1工程に1カ月以上かかる場合は1カ月経過時点で途中振り返りの実施を考えたほうが良いです。でないと振り返りで得られた改善案が時期を逃してしまうかもしれません。

振り返りのやり方についてはアジャイルと同様にKPT法(Keep Problem Try)をおすすめしますが、そのチームで普段から慣れている振り返り方法があればそれでかまいません。
振り返りの目的については、チームやPJの改善自体もありますがチームメンバの自律を促すという意味合いが大きいです。

WFで実施する改善検討というと、品質分析が頭に浮かんでくる人も多いと思います。
しかし、品質分析の思い出というと、PLが問処やレビュー記録票を一人で黙々と整理して説明資料を作成し他メンバは実際のバグ対処にあたる。といった光景が思い浮かびます。
「システムに対する品質分析」だと知識経験も必要になってきますし、担当者レベルだと「品質向上のために今後どうするか？」について意識する余裕も無く、結果としてPL一人で考える。なんて珍しくないですよね？
ですが、「チームに対する品質分析」なら担当者レベルでも参加する意義が出てきます。
自分のおかれた環境に対してなら、誰しも何かしらの改善要望や意見を持ってるでしょうから。

プロセス	実施内容	主目的
WF	進捗定例+工程ごとの品質分析	PJの進捗管理、システムの品質管理
アジャイル	デイリースクラム+スプリントごとの振り返り	コミュニケーション活性化、自律、チームの品質管理
改善案	朝ミーティング+工程ごとのチーム振り返り	コミュニケーション活性化、自律、チームの品質管理

話が少し脱線してしまいますが、個人的にはこの「定期的な振り返りの実施」というのがWFとアジャイルの大きな違いだと感じています。
WF開発PJの終了後に即追加開発スタートというケースはよくありますし、近年はWFでの開発期間も短くなっています。
では、「短期間でのWF開発の繰り返し」と「アジャイル開発」で何が違うかと言えば、この「振り返り」というプロセスが間に挟まるかどうかなのではないでしょうか？
(もちろん、スコープとコストの関係といった概念の違いや、ストーリーポイントを利用した見積もりといった手法の違いもあります)

■取り組み内容_設計工程

改善案

• 設計書の内部レビュを集合レビュにし、その場修正OKとする
• 途中経過状態でのレビュも実施する

・集合レビュについて
アジャイルでは、1スプリントごとに開発した機能に対する実機レビュを実施します。(スプリントレビュ)
意図としては、実際に動くものを関係者に見てもらい迅速なフィードバックにつなげるためですが、チームメンバ一人一人が「自分たちが何を作っているのか？「自分たちが何のためにこの仕事をしているのか？」を意識できる機会でもあります。

一方WFにおけるレビュは工程ごとの作成物に対して実施するものであり、設計工程では設計書をレビュします。
その際のレビュ方式としては、大まかに分けると回覧レビュと集合レビュがあります。
回覧レビュには、記録票の書き漏れが出にくい、被レビュ者の時間消費が少ない等のメリットがありますがここで推奨したいのは集合レビュのほうです。
(チームメンバが多すぎる場合は、集合するメンバを大項目単位や関連機能の担当者などで絞ることになります)

レビュの進め方としては、設計書作成者が自身の記載範囲について解説、それに対しリーダー含めたメンバが自由に質問/指摘していくことになります。その際には、指摘に応じて設計書をその場修正してOKとしレビュー記録票は後で整理します。

この取り組みにはアジャイルと同様に以下の目的があります。

• 自身の担当機能について責任を自覚できるようになること
• 担当部分以外の機能についても詳しくなること
• そもそもの機能開発の目的について理解が深まること

集合レビュを実施することで、「自分にまかされたタスクだけやっていればいい」「担当機能だけ理解していればいい」といった認識から脱却し、チーム全体の目的を意識して仕事を進められるようになればと考えています。

・途中経過状態でのレビュについて
これについては、アジャイル/WF関係なく皆さんも実は実施している内容ではないでしょうか？
レビュとしてではないですが「試しにちょっと書いたので見てくれませんか？」といった感じで内容を確認することがあると思います。これを集合レビュでやってみてはどうでしょう？という提案になります。
ただ、ここでの指摘を正式なレビュ記録票に起こすのはあまりお勧めしません。
(内部用のメモとして残しておくのはOKです)。
記録票として管理されると思うと、作成者としては逆にちゃんと書いてからレビュしてもらおうという意識が働いてしまいます。

プロセス	実施内容	主目的
WF	回覧レビュ+レビュー記録票による管理	設計書の品質を上げるための取り組み
アジャイル	スプリントレビュ	顧客フィードバックの迅速な吸収、開発目的の共有
改善案	集合レビュ(途中経過+完成版)	メンバ間の知識差解消、担当機能についての自覚、開発目的の共有

■取り組み内容_製造工程

アジャイル開発の製造においてよく語られる重要な点として、
「メンバ間の技術格差を少なくする(どのメンバがどの機能でも担当できるようにする)」
というものがあります。
一方WFでは、技術格差(あるいは機能間での知識差)について、積極的に解消しようという動きはあまり発生しないと思われます。
(最低限のプログラム知識を全員が身に着ける取り組みぐらいはするでしょうが)
設計書を作成した人がそのままソースも作成することが多いですし、別の人が担当する場合でも設計書通りに作ればいいという前提であれば問題になりにくいからです。
しかし、PJ終了後の保守や追加開発まで考えるとどうでしょう？
「この機能は複雑なので当時担当した〇〇さんがいないと改修は難しい」「でも当時のチームは解散して〇〇さんも今は別部署」なんてことは珍しくないと思います。
これを解決しようとするならば、WFでもメンバ間での知識差はできる限り少なくしていく必要があります。
では、そのためにどういった手法が考えらえるでしょうか？

改善案

• ソースレビュをペアプロモブプロの「イベント」にする。

アジャイルでは技術格差の解消のためペアプロやモブプロといった手法が取られることが多いです。
これらの具体的な手法についてはここでは割愛しますが、残念ながらWFにそのまま適用するのは難しいものになります。
そこで、「常時」ペアプロモブプロはできないが「イベント化」してその時だけ実施するという形式をとることが考えられます。
ある程度までは各担当者で進めてもらった上でタイミングを見てメンバに集合してもらい、全員が一つのソースを見るイベントを作ります。
ではそのイベントとして合致するのは何か？というと「ソースレビュー」が良いのではないでしょうか？

つまり、ソースレビュの形式を以下のようにします。

• 完成状態だけでなく途中状態でもレビューを実施する。
• 途中状態のレビュでは記録票は作成しない。
• チーム全員が参加する集合形式で実施する。
• ソース作成者は、自身のソースコードについて内容を解説する。
• その場で指摘して修正してOK、被レビュ者及び指摘者以外が修正するのもOKとする

上記の手法をとることで、設計工程と同様に各メンバの知識差をなるべく埋めつつ、自身の担当箇所により自覚を持てるようになるのではないでしょうか。

プロセス	内容	主目的
WF	各担当者が製造、レビュー記録票での管理	ソースの品質を上げる
アジャイル	常時ペアプロ/モブプロ	メンバの成長/育成、メンバ間の知識差解消、継続開発での作業効率化
改善案	ソースレビュをペアプロ/モブプロのイベントに	メンバの成長/育成、メンバ間の知識差解消

■取り組み内容_試験工程

試験におけるアジャイルとWFの取り組みの違いは何かと言いますと、自動テストの「目的」になるのではないでしょうか？
WFでも自動テストに取り組むことはあると思います。
しかし、WFにおける自動テストが試験効率化と開発機能に対する品質担保を主目的として実装されるのに対し、アジャイルにおける自動テストは継続的に開発を進める際に重要となる「保守性」を高める手法として実施されます。
この目的の違いから現場では何が発生しているでしょうか？
ここで2点、WFで自動テストを作ったことがある方に聞いてみたいことがあります。

「作った自動テストは今もきちんと動いていますか？」
「どんな自動テストが動いているか詳細に解説できますか？」

私には苦い経験があります。
以前担当した追加開発PJで、初期開発で実装された自動テストの実行方法がどうしてもわからず、泣く泣くその自動テストを破棄して手動で試験しなおした。というものです。
このような悲劇を繰り返さないためには、WFにおいても保守性を意識した自動テストに取り組んでいく必要があると痛感しております。

※本記事での自動テストは、テストサイズで言うところのSmallなテストにのみ言及しています。Medium及びLargeサイズの自動テストをWFで作成するのはコスト面から難しいためです。

アジャイルではテスト駆動開発という手法を実施することで、実装とテストコードの両面から保守性を高めています。
WFでは製造工程と試験工程が明確に分かれているため、実装が完了してからテストコードの作成に取り掛かることになるでしょう。
ではWFの試験工程でどのように保守性を高めていくかというと、試験観点作成とテストコード作成の二つの作業で改善案が考えられます。

改善案

• 関数やクラスの役割を元に単体試験観点書を作成し、メンバ全員でレビュする。
• テストコードのみでテスト内容が理解できるものを作成する。

・試験観点について
皆さんは単体試験の観点と聞いて、どういったものを浮かべるでしょうか？境界値試験？網羅性？純正常と異常系？色々あると思います。
しかしここで作成する観点とはそういった汎用的なものではなく、実際の機能や処理を元にして作ります。
具体的には以下のような観点書を作成します。

• 大項目は対象のクラス
• 中項目はクラス内のパブリックな関数
• 小項目は関数内で行われる処理や役割

そして、設計書やソースと同様に作成した観点書を全員で集まってレビュします。
観点書の作成と共有によって、これから作成するテストコードの意味づけを整理し意味の分かるテストコード作成の準備とします。

・テストコードについて
テストコードを作成する際に重要なのは、
テストコードだけを見て何のテストをしているか理解できることです。
「試験項目1-1-1のテスト」みたいなテスト名にしてしまったり、「メソッド〇〇に変数xを入れてtrueが返ってくること」みたいなコード直訳なコメントしか入っていないテストコードを作ってしまうと、試験項目書や実装を見ないと何をしているか分からないテストコードになってしまいます。

※自動テストの具体的な実装方針や手法については、テスト自動化第一人者の和田卓人さんがWebで連載している以下のブログが大変参考になりますのでリンクを載せておきます。
サバンナ便り ～ソフトウェア開発の荒野を生き抜く～

プロセス	実施内容	主目的
WF	試験項目書レビュ+レビュー記録票による管理	ソースと試験の品質を上げる
アジャイル	テスト駆動開発	仕様への理解を深める、ソースとテストコードの保守性を高める
改善案	機能を元にした観点書の作成+わかりやすいテストコードの作成	ソースとテストコードの保守性を高める

■取り組み内容_PJ終了後(保守と追加開発に向けて)

WFにて、顧客への納品あるいはシステムリリースをもって無事PJが終了した後にすべきことは何が考えられるでしょうか？
アジャイルでは、スプリント終了時に振り返りを実施します。
また、アジャイルとは若干話が変わってきますがDevOpsについて考える場合、保守メンバや次期開発メンバへの引継ぎが重要になってきます。
そのため、WFでのPJ終了時に以下を実施することが考えられます。

改善案

• チーム全員で全体の振り返りを実施する。
• 担当メンバのスキルマップメモを作っておく。
• 開発した機能についての内部向け紹介資料を作る。

・全体振り返りについて
全体振り返りでは、これまで実施してきた振り返り内容自体を振り返ることで当時考えた改善策が実際どうだったのかも合わせて振り返ることができます。

・スキルマップメモについて
誰が何の機能を担当したかのメモを残しておこうという話です。
設計や製造工程にてできる限り担当者の知識差を解消していこうと取り組みを紹介しましたが、WFである以上完全な解消は難しいでしょう。
であるならせめて、誰がどの機能に詳しいかはきちんと整理しておこうという取り組みになります。
この資料があれば、保守で問い合わせやアラートが発生した際に「誰だったら調査ができるか？」が分かるようになります。

・機能の紹介資料について
開発したメンバがそのまま保守として残る場合は良いのですが、保守専任のメンバが担当するケースもあるでしょう。
そういった場合に、開発した機能の紹介や保守作業時の注意点、アラート調査で重要な点などの資料を作成しておくことで、より迅速な保守作業が可能になります。
(内部向けですのできちんとした体裁資料でなくとも、効果はあります)

プロセス	実施内容	主目的
WF	PJ終了報告	顧客や自社上位層に向けた報告
アジャイル	振り返り	コミュニケーション活性化、自律、チームの品質管理
改善案	振り返り+スキルマップ作成+内部向け紹介資料作成	次期開発に向けたチーム改善、保守チームとの協働促進

■最後に

ここまで長々と読んでいただきありがとうございます。
しかし、ここまで読んでいただいた方にはこう思った方もいるのではないでしょうか？
「なんか大層な雰囲気で書いてあるけど、要はWFをより丁寧にやるっていうだけじゃないのか？」
と。
・
・
・
おっしゃる通りです。
ここにあるものはすべて「WFをより丁寧に実施する」ということの「より丁寧」とは何かをひたすら具体的に記載したものになっています。

この記事を書こうと思ったきっかけとして、私がWFに対して疑問に感じている点があります。
「WFは作って終わりのPJである」
「WFでは変化に対応できない」
これって本当なのかな？という点です。

皆さんの現場では↓のようなことが発生したことが無いでしょうか？

• 作ってリリースした後に顧客から要望が発生して追加開発PJが起こる。
• なんなら作ってる最中から吸収できないぐらいの追加要件が発生して、STEP2開発の予定が組まれる。
• 顧客からどうしてもという要望を受けて、今後の費用調整を相談しつつ仕様変更に対応する。
• 工程内で決まらない箇所があり、次工程でも期間を設けて変更を受け付ける

これってつまり、WFでも継続的に開発することがある(≒継続的に開発しないといけない)し、WFでも状況の変化に対応することがある(≒変化に対応しないといけない)ということですよね？
アジャイルとの違いは、その頻度や受け入れる基本スタンスの違いに過ぎないんじゃないかと感じています。
(アジャイルに触れてまだ日が浅い私の妄言だったらゴメンなさい)

• アジャイルプロセスが日々改善され続けているのと同様に、WFについてもまだまだ改善できる余地があるんじゃないか？
• アジャイルとまではいかないまでも、ある程度変化を許容しそこそこの期間継続的に開発していくためにWFをどう改善していくか？

について考えた時に、「より丁寧」というのを定量的な部分(指標値、計画と実績の乖離、カバレッジ率等)だけでなく定性的な部分(コミュニケーション、知識格差の解消、分かりやすいテストコード等)に目を向けていけばどうだろうか？と考え、今回の記事を書かせていただきました。