はじめに
前回までの連載では開発プロセスと、DevOpsにおける「脆弱性チェック」と「コンプライアンス違反チェック」に焦点をあてて解説しました。
DevOpsにより継続的に価値あるサービスを迅速にリリースできるようになりましたが、イノベーションを加速させるためには課題が残ります。みなさんがご存じのとおり、DevOpsにはアジャイル開発手法が必要ですが、その手法やツールだけ導入しても完全に実現することはできません。
ここからの連載では、DevOps実現に必要な「アジャイル開発手法」と「テスト管理」「テスト自動化」についてお話をします。まず、前提として、今号担当の筆者はいくつかのSI企業に在籍した経験から「ウォーターフォール型」が大好きです。もちろん作るときは、とても楽しいExcel方眼紙でガントチャートも作成していました。そんな筆者の目線で「アジャイル手法」と「ウォーターフォール手法」の違いなども含めてお話を進めていきます。
アジャイル手法導入に向けて
アジャイル手法を取り入れる場合、「文化（カルチャー）を変える必要がある」という話を聞きます。ですが、一朝一夕に文化（カルチャー）を変えるなんてできるわけがありません。
みなさんは、ラグビーのW杯をご覧になったでしょうか。まさにアジャイル手法を取り入れたチームはOne Team（ワンチーム）になることが大切です。
顧客も含めたチーム内での対話と協調によって出す成果はすばらしいものがあります。「アジャイルソフトウェア開発宣言」にも、そのように記載されています（図1）。筆者も学生時代にラグビー部に所属していたため、とても共感する宣言です。
図1 アジャイルソフトウェア開発宣言
ウォーターフォール型は、仕事が完了する姿（＝要件や成果物）が明確になっているため、筆者としては作業しやすいので好きな手法です。ですが近年、仕事が完了する姿（＝要件や成果物）がプロジェクト進行中に変わってしまうことが多々あります。要件が変わり、設計も変更され、ソフトウェア開発者に伝達するころには「老いたな……父上。時すでに遅いのだがな」という某アニメの名ゼリフのように、待っているのは敗北だけです。こんなことにならないように、アジャイルを実践する、もしくはウォーターフォール手法の中にアジャイル要素を取り込むということを考えていく必要があります。
アジャイル手法には、かんばん方式とスクラム方式の2種類があります（表1）。そのどちらを取り入れてもかまいませんが、まずは簡単に実践できる「かんばん方式」を採用してみるのも良いかと思います。
表1 かんばん方式とスクラム方式
| かんばん方式 |
|
|---|
| 優先順位と進行状況がベース |
| 導入が簡単でわかりやすい |
| スクラム方式 |
|
|---|
| 時間がベース |
| スクラム方式の知識が必要（スクラムマスターの存在が大切） |
ウォーターフォールからアジャイルへ
ここでウォーターフォール型とアジャイル型の差をまとめてみました（表2）。
表2 ウォーターフォール型とアジャイル型の違い
| ウォーターフォール型 | アジャイル型 |
|---|
| 適用 | 要件は決定していて、リリースまで変更が発生しない
例）組込み系ソフトウェア開発など | 要件があいまいで、あとで変更が発生する（発生する可能性がある）
例）インターネットサービス系ソフトウェア開発など |
| 柔軟性 | 低い | 高い |
| 工期 | 長い | 短い |
| イメージ |
|
|
| 駆動 | ドキュメント（成果物） | チケット駆動、テスト駆動など |
| 責任分界点 | 工程 | 役割 |
| 外部との契約（日本では） | しやすい | しにくい
※IPAにて非ウォーターフォール型の契約書雛形が公開されている |
| ミーティング回数 | 少ない
※文化（カルチャー）によっては多い | 多い
※デイリースクラムミーティングを行う場合 |
| ミーティング参加人数 | 少ない
※文化（カルチャー）によっては多い | 多い
|
| ミーティング時間 | 長い（1時間以上） | 短い（30分未満）
だいたい15分程度 |
| プロジェクト管理ツール | Excelでも、なんとかできる？
（例：Excel方眼紙） | 必須 |
この表において、ウォーターフォール型の「ミーティング回数」と「ミーティング参加人数」の項目で「文化（カルチャー）によっては多い」と記載した理由は、文化によっては、儀式のようにプロジェクトに直接関係のない役職者たちが出席する場合のことを指しています。そのような参加者を少なくし、開発エンジニアやテストエンジニアなどをミーティングに参加させることをオススメします。
過去、ミーティングに多くの出席者がいると「コスト意識がない」「時間と人が無駄だ」という声を聞いたことがあります。ですが主要メンバーだけ出席し、そのあとに別のメンバーへ説明（共有）するミーティングを行うことを考えてみてください。チームメンバーが全員参加するミーティングなら1回だけで終わるので、時間とコストを考えれば効率的です。「よくよく考えてみれば、これまでの常識が非効率ではなかったのか？」という疑問を持つことこそが変わるキッカケになります。
アジャイル型の場合、顧客、ビジネスオーナー、スクラムマスター、開発エンジニア、テスト担当者などを同席させ、顧客またはビジネスオーナーから意見を聞く機会を作ったほうが良いです。ウォーターフォール型であっても、同じように各メンバーが同席することは重要だと思います。
そして、チームとして最適に機能させるには、人数は最大15名くらいを目安にしてみてください。まさにラグビーチームの人数ですね。
アジャイル手法の実践、またはウォーターフォールにアジャイル要素を取り入れるためには、ツール活用は必須条件となります。そこで後編ではツールの役割について説明します。
米国Atlassianから、2年連続で
「Top new business APAC」を受賞。
Atlassianセールスパートナーとして
アジアパシフィックで1位の証
日本だけでなく、アジア圏でもアトラシアン製品販売のトップエキスパートであるリックソフトのWebサイトでは、各アトラシアン製品の体験版を提供しているほか、アトラシアン製品専用のコミュニティも運営しています。まずはアクセスしてみては！
- 第1特集
MySQL アプリ開発者の必修5科目
不意なトラブルに困らないためのRDB基礎知識
- 第2特集
「知りたい」「使いたい」「発信したい」をかなえる
OSSソースコードリーディングのススメ
- 特別企画
企業のシステムを支えるOSとエコシステムの全貌
［特別企画］Red Hat Enterprise Linux 9最新ガイド
- 短期連載
今さら聞けないSSH
［前編］リモートログインとコマンドの実行
- 短期連載
MySQLで学ぶ文字コード
［最終回］文字コードのハマりどころTips集
- 短期連載
新生「Ansible」徹底解説
［4］Playbookの実行環境（基礎編）
