コードの安全性・安定性を高める開発サイクル ~テスト管理の効率を上げ,脆弱性診断を自動で行う~

第7回 イノベーションを加速させるアジャイル開発/DevOps(前編)

この記事を読むのに必要な時間:およそ 2 分

はじめに

前回までの連載では開発プロセスと,DevOpsにおける「脆弱性チェック」「コンプライアンス違反チェック」に焦点をあてて解説しました。

DevOpsにより継続的に価値あるサービスを迅速にリリースできるようになりましたが,イノベーションを加速させるためには課題が残ります。みなさんがご存じのとおり,DevOpsにはアジャイル開発手法が必要ですが,その手法やツールだけ導入しても完全に実現することはできません。

ここからの連載では,DevOps実現に必要な「アジャイル開発手法」「テスト管理」⁠テスト自動化」についてお話をします。まず,前提として,今号担当の筆者はいくつかのSI企業に在籍した経験から「ウォーターフォール型」が大好きです。もちろん作るときは,とても楽しいExcel方眼紙でガントチャートも作成していました。そんな筆者の目線で「アジャイル手法」「ウォーターフォール手法」の違いなども含めてお話を進めていきます。

アジャイル手法導入に向けて

アジャイル手法を取り入れる場合,⁠文化(カルチャー)を変える必要がある」という話を聞きます。ですが,一朝一夕に文化(カルチャー)を変えるなんてできるわけがありません。

みなさんは,ラグビーのW杯をご覧になったでしょうか。まさにアジャイル手法を取り入れたチームはOne Team(ワンチーム)になることが大切です。

顧客も含めたチーム内での対話と協調によって出す成果はすばらしいものがあります。アジャイルソフトウェア開発宣言にも,そのように記載されています図1⁠。筆者も学生時代にラグビー部に所属していたため,とても共感する宣言です。

図1 アジャイルソフトウェア開発宣言

図1 アジャイルソフトウェア開発宣言

ウォーターフォール型は,仕事が完了する姿(=要件や成果物)が明確になっているため,筆者としては作業しやすいので好きな手法です。ですが近年,仕事が完了する姿(=要件や成果物)がプロジェクト進行中に変わってしまうことが多々あります。要件が変わり,設計も変更され,ソフトウェア開発者に伝達するころには「老いたな……父上。時すでに遅いのだがな」という某アニメの名ゼリフのように,待っているのは敗北だけです。こんなことにならないように,アジャイルを実践する,もしくはウォーターフォール手法の中にアジャイル要素を取り込むということを考えていく必要があります。

アジャイル手法には,かんばん方式とスクラム方式の2種類があります表1⁠。そのどちらを取り入れてもかまいませんが,まずは簡単に実践できる「かんばん方式」を採用してみるのも良いかと思います。

表1 かんばん方式とスクラム方式

かんばん方式

かんばん方式

優先順位と進行状況がベース
導入が簡単でわかりやすい
スクラム方式

スクラム方式

時間がベース
スクラム方式の知識が必要(スクラムマスターの存在が大切)

ウォーターフォールからアジャイルへ

ここでウォーターフォール型とアジャイル型の差をまとめてみました表2⁠。

表2 ウォーターフォール型とアジャイル型の違い

ウォーターフォール型アジャイル型
適用要件は決定していて,リリースまで変更が発生しない
例)組込み系ソフトウェア開発など
要件があいまいで,あとで変更が発生する(発生する可能性がある)
例)インターネットサービス系ソフトウェア開発など
柔軟性低い高い
工期長い短い
イメージ ウォーターフォール型 アジャイル型
駆動ドキュメント(成果物)チケット駆動,テスト駆動など
責任分界点工程役割
外部との契約(日本では)しやすいしにくい
※IPAにて非ウォーターフォール型の契約書雛形が公開されている
ミーティング回数少ない
※文化(カルチャー)によっては多い
多い
※デイリースクラムミーティングを行う場合
ミーティング参加人数少ない
※文化(カルチャー)によっては多い
多い
ミーティング時間長い(1時間以上)短い(30分未満)
だいたい15分程度
プロジェクト管理ツールExcelでも,なんとかできる?
⁠例:Excel方眼紙)
必須

この表において,ウォーターフォール型の「ミーティング回数」「ミーティング参加人数」の項目で「文化(カルチャー)によっては多い」と記載した理由は,文化によっては,儀式のようにプロジェクトに直接関係のない役職者たちが出席する場合のことを指しています。そのような参加者を少なくし,開発エンジニアやテストエンジニアなどをミーティングに参加させることをオススメします。

過去,ミーティングに多くの出席者がいると「コスト意識がない」⁠時間と人が無駄だ」という声を聞いたことがあります。ですが主要メンバーだけ出席し,そのあとに別のメンバーへ説明(共有)するミーティングを行うことを考えてみてください。チームメンバーが全員参加するミーティングなら1回だけで終わるので,時間とコストを考えれば効率的です。⁠よくよく考えてみれば,これまでの常識が非効率ではなかったのか?」という疑問を持つことこそが変わるキッカケになります。

アジャイル型の場合,顧客,ビジネスオーナー,スクラムマスター,開発エンジニア,テスト担当者などを同席させ,顧客またはビジネスオーナーから意見を聞く機会を作ったほうが良いです。ウォーターフォール型であっても,同じように各メンバーが同席することは重要だと思います。

そして,チームとして最適に機能させるには,人数は最大15名くらいを目安にしてみてください。まさにラグビーチームの人数ですね。

アジャイル手法の実践,またはウォーターフォールにアジャイル要素を取り入れるためには,ツール活用は必須条件となります。そこで後編ではツールの役割について説明します。

米国Atlassianから,2年連続で
「Top new business APAC」を受賞。
Atlassianセールスパートナーとして
アジアパシフィックで1位の証

米国Atlassianから,2年連続で「Top new business APAC」を受賞。Atlassianセールスパートナーとしてアジアパシフィックで1位の証

日本だけでなく,アジア圏でもアトラシアン製品販売のトップエキスパートであるリックソフトのWebサイトでは,各アトラシアン製品の体験版を提供しているほか,アトラシアン製品専用のコミュニティも運営しています。まずはアクセスしてみては!

Software Design

本誌最新号をチェック!
Software Design 2020年4月号

2020年3月18日発売
B5判/192ページ
定価(本体1,220円+税)

  • 第1特集
    AWSデータベース[詳解]導入ガイド
    定番のRDS,高機能のAurora,NoSQLのDynamoDB
  • 第2特集
    新人ITエンジニアのためのストレージ入門
    しくみから運用の基本までマスター
  • 一般記事
    複雑化するシステムをどうやって維持する?
    コンテナマイクロサービスの監視アプローチ

著者プロフィール

大塚和彦(おおつかかずひこ)

リックソフト株式会社

マーケティング/ソリューション営業を担当。

システム構築,プロジェクト管理が好きな営業!? 新しい技術・知識に出会い・習得するのが何より楽しい!

好きなモノは「注文書」。