開発プロセス・手法
ウォーターフォールとアジャイル、XPとスクラム、DevOpsとCI/CD、共通フレームやCMMIという開発プロセスの手法を理解できるようになります。
ねらい
ソフトウェア開発の進め方の型を学びます。このレッスンを終えると、代表的な開発モデルの違い、XPとスクラムの実践、DevOpsの考え方、開発プロセスの標準と成熟度モデルを説明できるようになります。
ストーリー
半年かけて要件どおりのシステムを納品したら、「業務が変わったので、もう要らない機能ばかり」と言われてしまった。変化の速い時代には、作り方そのものを変える必要があります。小さく作り、早く見せ、頻繁に直す。アジャイルはそんな時代の答えのひとつです。
ソフトウェア開発モデル
開発の進め方の型をソフトウェア開発モデルといいます。
| モデル | 特徴 |
|---|---|
| ウォーターフォールモデル | 要件定義から保守まで工程を順に進める。後戻りしない前提で管理しやすい |
| プロトタイピングモデル | 試作品を早期に作って確かめ、手戻りを防ぐ |
| 段階的モデル(Incremental Model) | 機能を分けて段階的にリリースする |
| 進展的モデル(Evolutionary Model) | 作りながら要求を進化させていく |
| アジャイル | 短い反復で動くソフトウェアを積み上げる軽量な手法の総称 |
似た製品群を共通の部品基盤から生み出すソフトウェアプロダクトライン、機械学習の開発と運用をつなぐMLOpsという型もあります。
アジャイル:小さく速く回す
アジャイルの価値観はアジャイルソフトウェア開発宣言と、それを支えるアジャイルソフトウェアの12の原則にまとめられています。要求はユーザーストーリーで表し、反復の終わりにはふりかえり(レトロスペクティブ)を行います。ふりかえりの整理には、続けること・問題・試すことを挙げるKPT(Keep、Problem、Try)が使われます。
XP(エクストリームプログラミング)
技術の実践を重視する手法がXPです。テストを先に書いてから実装するテスト駆動開発(TDD)、2人で1つの画面に向かうペアプログラミング(チーム全員ならモブプログラミング)、内部構造を継続的に整えるリファクタリング、変更のたびに自動でビルドとテストを行う継続的インテグレーション(CI)、ソースコードの共同所有が代表的な実践です。「必要になるまで作らない」というYAGNIの原則も知られています。
スクラム
チーム運営の枠組みを定めた手法がスクラムです。スクラムチームは、作る物の価値に責任を持つプロダクトオーナー、実際に作る開発者、進め方を支援するスクラムマスターで構成されます。開発はスプリントという固定長の反復で進み、要求の一覧であるプロダクトバックログから、そのスプリントで行う分をスプリントバックログとして選び取ります。スプリントの完了後にふりかえりを行い、その結果を次のプロダクトバックログに反映することで、この一連の流れが繰り返し循環します。
DevOpsとその発展
開発(Development)チームと運用(Operations)チームが連携し、迅速かつ柔軟にソフトウェアを届け続ける考え方がDevOpsです。CIに加えて、いつでもリリースできる状態を保つ継続的デリバリー(CD)、さらに自動で本番反映まで行う継続的デプロイを実践します。コード変更からCI、CDを経て継続的デプロイに至る一方向の流れだけでなく、運用で得た知見を開発へ戻す連携が続くところにDevOpsの特徴があります。運用の信頼性をエンジニアリングで高める役割をSRE、わざと障害を起こして回復力を確かめる手法をカオスエンジニアリング、セキュリティを最初から組み込む発展形をDevSecOpsといいます。
その他の開発手法
- ローコード/ノーコード開発は、専門的なコーディングの知識がなくても開発できる手法です。速い反面、細かな要求への対応には限界があります。
- ソフトウェア再利用は、モジュールの独立性と標準化を前提に部品を設計し、ソフトウェアパッケージのカスタマイズも含めて生産性と品質を高めます。
- リバースエンジニアリングは、既存ソフトウェアを解析して仕様や構成(互換性の確認やコールグラフなど)を得る手法です。権利者の許可なく解析結果からソフトウェアを開発・販売すると知的財産権を侵害するおそれがあり、利用許諾契約で禁止されている場合もあります。
- マッシュアップは、複数の提供元のAPIを組み合わせて新しいサービスを作る手法です。
- モバイルアプリケーションソフトウェア開発では、ブラウザで動くモバイル用Webアプリケーション、OSごとに作るネイティブアプリケーション、両者を組み合わせたハイブリッドアプリケーション、Webの技術でアプリのような体験を実現するPWAという選択肢があり、パーミッション要求やアプリケーションソフトウェア審査・配布という固有の手順があります。
このほか、従来からの構造化手法(階層構造化、段階的詳細化、構造化チャート、状態遷移図、HIPO、DFD)と、仕様を形式仕様記述言語で厳密に書く形式手法(VDMToolsなど)も試験範囲です。
開発プロセスの標準と成熟度
開発から保守までの工程の共通の枠組みがSLCP(ソフトウェアライフサイクルプロセス)で、JIS X 0160や、日本の共通フレーム(SLCP-JCF)として整備されています。発注者と受注者の間で用語と作業範囲の認識を合わせるための「共通のものさし」です。
組織の開発プロセスの成熟度を5段階などで評価するモデルがCMMIで、プロセス改善の指針として使われます。
例題
次の問いに答えてください。
問1 スクラムで、プロダクトの価値に責任を持ち、プロダクトバックログを管理する役割を何といいますか。
問2 実装より先にテストを書き、テストを通すように実装を進める開発手法を何といいますか。
解答と解説
問1の答えはプロダクトオーナーです。開発者、スクラムマスターと合わせた3つの役割でスクラムチームを構成します。
問2の答えはテスト駆動開発(TDD)です。XPの代表的な実践で、テストが仕様の役割を果たします。
応用
本試験を意識した問題を解いてみましょう。
問 開発者がコードの変更をリポジトリに統合するたびに、自動的にビルドとテストを実行して問題を早期に発見する実践はどれでしょうか。次の中から選んでください。
- 継続的インテグレーション
- ペアプログラミング
- リファクタリング
- カオスエンジニアリング
解答と解説
答えは1の継続的インテグレーション(CI)です。統合を頻繁に行い、ビルドとテストを自動化することで、問題を小さいうちに見つけられます。2のペアプログラミングは2人で1つのコードに向かう実践で、自動化の仕組みではありません。3のリファクタリングは、外部の振る舞いを変えずに内部構造を整理する活動です。4のカオスエンジニアリングは、本番環境でわざと障害を起こしてシステムの回復力を確かめる手法であり、変更のたびの自動ビルド・テストとは別の実践です。
分からなかった点・気になった点
読み込み中です。