ソフトウエア開発の主な手法
『ソフトウエア開発』にはアプリケーションの開発や成果物の事前定義など多くの工程が必要とされ、計画性を持って進めなければ開発を完遂させることは困難です。
そのため、アイデアの発生からシステムの配備までを『構造化・計画・制御』し、整然とした形で逐次的に実行するための『フレームワーク』が重要になります。
ここでいうフレームワークとは『SDM』と呼ばれる『ソフトウエア開発方法論』あるいは『システム開発方法論』のことです。
ソフトウエア開発フレームワークには『ソフトウエア工学』の誕生から長年にわたって様々なものが考案されてきており、それぞれにメリット・デメリットがあります。
プロジェクトの性格によって適したフレームワークは異なりますので、最適なものを選ぶことが重要です。
ウォーターフォール開発
Waterfallは『滝』という意味ですが『ウォーターフォール開発』は水が上から下へ流れるように上流工程から下流工程へと順次推移していく開発手法です。
基本的な流れは以下のとおりです。
- 要件定義
- 設計（ソフトウエア設計）
- 実装（プログラミング）
- 評価（テスト）
- 保守（メンテナンス）
これらの工程を『線表（ガントチャート）』で進捗管理し、前工程が終了しなければ次工程に進まないことを前提としています。
最も古くからある開発手法で、製造業や建設業などで運用されてきた『従来の工学的開発手法』を『情報技術』の領域にそのまま適用したもの、とイメージすると良いでしょう。
『直線的なフレームワーク』という性格を持ち、進捗管理はしやすいものの柔軟性を欠くというデメリットがあります。
スパイラル開発
『スパイラル開発』は設計・実装・テスト・試作といったサイクルを繰り返していく開発手法で、螺旋を描いて工程を反復させます。
1回のサイクルで1つの『モジュール』を完成させたりシステム全体の改良を行なったりと、柔軟に次のループを選択していきます。
それにより『ソフトウエア開発工程』において欠かすことのできない『トップダウン設計』と『ボトムアップ設計』の利点を生かすことができるのです。
『トップダウン設計』では、まずシステム全体を十分に理解した上で定式化し、次々に小さな単位へと段階的に、実装できるまで詳細化していきます。
『ボトムアップ設計』では、まずシステムを構成するモジュール群を細部まで設計し、これらを組み合わせて次第に大きなシステムとしていき、最終的にシステム全体を完成させます。
プロトタイプ開発
プロトタイプ（Prototype）とは『試作』を意味します。『プロトタイプ開発』は、ソフトウエアの不完全なバージョン（試作品）を実装し、検証しながら開発を進めていく手法です。
流れとしては、『要件定義』を行いプロトタイプを『実装』、クライアントからのフィードバックをもらう『レビュー』を経て、プロトタイプの『改良』を行います。再度レビュー・改良と繰り返すこともよくあることです。そのため『反復的なフレームワーク』と言えるでしょう。
『ラピッドプロトタイピング』と呼ばれる、使い捨てを前提としたプロトタイプを作る開発手法もあります。
それに対して『進化的プロトタイピング』では、最終形のソフトウエアとなるまで改良し続けることを前提としてプロトタイプを実装します。この場合、ウォーターフォール開発のようにシステム全体を設計するのではなく、理解できるところから開発を始め、機能追加していくことがポイントです。
アジャイル開発
アジャイル（agile）とは『素早い』『機敏な』などの意味があります。『アジャイル開発』は、従来よりも効率的に、短期間で開発することを目的に考案された開発手法の総称です。
『イテレーション』（反復）と呼ばれる1週間から4週間ほどの短い開発サイクルを繰り返していきます。開発対象をソフトウエア全体ではなく多数の小さな機能群に分割し、これらを1つのインテレーション内で1つずつ実装していくイメージです。
アジャイル開発の主な手法
アジャイル開発にはいくつかの種類があります。代表的な3つの手法を押さえておきましょう。
XP
XP（エクストリーム・プログラミング）は代表的なアジャイル開発手法です。
設計よりもソースコードを重視し、個人を組織的開発の歯車とするのではなく、個人の責任と勇気を重んじる手法として、プログラマーから支持を受けています。
XPでは『4つの価値』と『19のプラクティス（実践）』が定められており、比較的少人数での開発に向いているといえるでしょう。
プラクティスには『テスト駆動開発』と呼ばれる手法が定められています。はじめにテストから書く『テストファースト』を実施し、そのテストをクリアする必要最低限のプログラムを『素早く実装』し、コードを洗練させていくという短いプロセスを反復するスタイルです。
FDD
FDD（ユーザー機能駆動開発）は、クライアントにとって価値ある『機能（Feature）』に主眼を置き、実際に動作するソフトウエアを適切な間隔で提供することが主な目的です。
FDDは以下の5つの基本活動を持ちます。
- 全体モデルの開発
- 機能のリストアップ
- 機能の計画
- 機能の設計
- 機能の構築
ここでいう機能とは、例えば『売り上げを計算する』あるいは『ユーザーのパスワードを検査する』といった、クライアントが価値を見いだす機能の小単位のことです。
最初の3つの活動によりクライアントが求める機能を明確化し、機能単位での小規模なチームを作ります。次にチームごとに機能を実現する設計・構築に移り、全体として機能ごとの達成率を進捗管理します。
スクラム
スクラムはチーム一丸となり活動する、柔軟で自由度の高い開発手法をラグビーのスクラムにたとえて言ったものです。
スクラムの特徴としてまず挙げられるのは、チームメンバー『全員が物理的に同じ場所にいる』ことや、毎日決まった時間に『必ず小規模な会議を行う』ことなどのルールが重視されていることです。詳細は次の項目から解説します。
スクラム開発について知ろう
アジャイル開発の中でも特徴的なスクラム開発について、詳細を見ていきましょう。
スクラムの理論的基盤
システム開発の途中でクライアントは『いつでも要求や必要事項を変えられる』という前提があります。予測できない変更に対して計画通りにプロジェクトを進めるわけにはいかず、スクラムではここで『経験に基づくアプローチ』を採用します。
システムについて十分な理解も定義も得られないなら、要求に対する『チームの即応力を最大化』することに集中すべき、という考えがスクラムの根幹にあります。
スクラム開発の流れ
スクラム開発は主に『計画ミーティング』『製品基準の調整・レビュー・配布』『スプリント』『スプリントレビュー』『振り返り』『クロージャ』という6つの基本活動からなります。
プロジェクトは1週間から4週間の期間に分割され、それぞれが『スプリント』を繰り返して振り返り・改善をしていきます。
工程のうち『計画ミーティング・スプリント・スプリントレビュー・振り返り』が反復されると覚えましょう。
大まかな流れとしては、まず『計画ミーティング』でスプリントにおいて達成すべき目標の優先順位とゴールを明らかにします。次に『スプリント』で実装を行い、スプリントの後には必ず『スプリントレビュー』が行われます。その後『振り返り』を行い問題点と改善策を話し合って、次のスプリントの『計画ミーティング』が行われるのです。
プロジェクトの締めくくりには『クロージャ』と呼ばれる、最終的な『デバッグ』『マーケティング』『販売促進』を行う工程があり、これらの完了をもってプロジェクトは終了となります。
従来の手法との違い
ソフトウエア開発における伝統的な手法の多くは、あらかじめ（しばしば実施内容の詳細まで）決められた工程を逐次行う『シーケンシャル』なアプローチであったと言えます。
これに対しスクラムでは、チームメンバーそれぞれが『スポーツチーム』のような『作業プロセス』と『作業結果』に対する責任を持ち、自らが『チームの管理』を行います。
チーム全体として『同じゴール』を目指すことで、チームが自発的に組織立って行動する『自己組織化』を促しているのです。
スクラム開発のメリット
スクラム開発のメリットを詳細に見ていきましょう。
見積もりがしやすく納期を短縮しやすい
従来のウォーターフォール開発では、予測不能であるにもかかわらずプロジェクト初期段階でシステム全体を定義し、その時点で（現実的ではない見込みであっても）『工数』を見積もっていました。
それに加え、開発途中に余儀なくされた『仕様変更』などが引き起こす『計画修正』による工数の肥大化を避けることが難しいというデメリットがありました。
これに対しスクラム開発は『固定周期』のスプリントを繰り返すスタイルであり『工数見積もり』がしやすいというメリットがあります。
軌道修正やトラブルなど柔軟に対処できる
スクラム開発では、想定外の問題が発生した場合であっても自己組織化により軌道修正が容易に行えます。
チームメンバーは毎日同じ時間にミーティングを繰り返すため『内部要因』による問題の発覚が早まり、その修正もチーム全体の共通認識を得た上でスムーズに取り組むことができるでしょう。
またスクラム開発は機能追加や仕様変更が前提とされた開発姿勢を持ちます。スプリント後にはクライアントに対するレビューを行うため『外部要因』による問題が後手に回ることを避けられ、これを踏まえ次のスプリントで改善することができます。
スクラム開発のデメリット
スクラム開発にもデメリットがありますので理解を深めておきましょう。
チームや個人における問題
チームとしての開発を目的とするため、チームメンバーの『経験やスキル』に大きな差がある場合は『足並みを揃えにくい』という点がデメリットとして挙げられます。
スプリントを繰り返すごとにスクラムに慣れ『業務効率』は向上する傾向がありますが、固定周期であるにもかかわらずスプリントごとの成果に『ムラが大きい』とも言えるでしょう。
またチームを重視するあまり『チームメンバーが交代』するときや『チームが拡大』する際に『業務割り当てが混乱』し、従来型の開発手法に頼らざるを得なくなるケースもあります。
チームの用語や役割について知ろう
スクラム開発のキーポイントである『チーム』の詳細を見てみましょう。スポーツのようにチームの人数は5～9人が適当とされます。
プロダクトオーナー
『プロダクトオーナー』は製品の総責任者であり、クライアントの意思の代表として振る舞います。
『ROI（投資利益率）』などビジネスの視点を持ち『顧客の要望（ユーザーストーリー）』を明らかにします。これを製品開発の優先順位付けに反映させる、たとえるなら『チームの監督』のような存在です。
スクラムマスター
『スクラムマスター』はスクラムのフレームワークが正しく運用されているかを保証する役割を担いますが、チームメンバーの一員であるため権限は絶対ではありません。
ミーティングの進行や調整を行うことを『組織間調整（ファシリテーション）』といい、チームに対して『公正』な立場で話し合いの『グループ・プロセス（グループの状況）』に介入する『ファシリテーター』でもあります。
またチームにとって『役に立つこと・立たないこと』をクライアントなど外部関係者に説明し理解してもらうこともスクラムマスターの役割の一つです。
スクラムチームと開発チーム
『スクラムチーム』は『プロダクトオーナー』『スクラムマスター』『開発チーム』からなります。
『開発チーム』はプログラミングの専門家で構成され、スプリントの終わりに『リリース可能』な『インクリメント（追加機能製品）』をクライアントに提出する役割を担います。
開発チームのメンバーそれぞれに専門能力や専門分野があっても『肩書』もなければ『サブチーム』もありません。インクリメントの作成方法はメンバー『各自が選択』し、最終的な責任は『開発チーム全体』が持ちます。
ステークホルダー
『ステークホルダー』は、エンドユーザー・スポンサー・社内の上司など『プロダクト』に利害関係を持つスクラムチーム以外の人たちのことを指します。
ステークホルダーの役割は、スプリントレビューに参加してプロダクトに対する『フィードバック』を与えることです。
ただし、スプリントレビュー外で開発チームに機能の追加や要件の変更を指示することはできず、これはプロダクトオーナーが優先順位を判断し最終決定権限を持ちます。
スプリントの流れとポイント
『スプリント』はリリース可能なインクリメントを作るための1～4週間の『タイムボックス』であり、開発中のスプリントの長さは常に一定です。1つのスプリントが終了するとすぐに次のスプリントが開始されます。
まず『スプリントプランニング』でスプリントの作業を計画し『スプリントゴール』を設定します。スプリント中には毎日『デイリースクラム』と呼ばれるミーティングがあり、計画の達成度を測りながらインクリメントを作成していくことがポイントです。
スプリントの終了時には『スプリントレビュー』においてスクラムチームとステークホルダーがスプリントの成果を評価します。その後『スプリントレトロスペクティブ』と呼ばれる『振り返り』を行います。
スプリントにおいては密なコミュニケーションが要求され『明確なゴール』は設定するもののそれに至る『過程はフレキシブル』であることがポイントです。
これはチームと作業環境の継続的な改善に繋がり『透明性』や『創造性』を高めることが期待されています。
バックログの作成やミーティング
『プロダクトバックログ』はプロダクトに必要と判断しているもの全てを並べた一覧であり、これを『唯一の情報源』として開発を進めていきます。
一覧の上にあるアイテムほど情報は詳細であり、プロダクトオーナーと開発チームが協働してこれを更新していきます。最終的な『見積もりを正確に行う』ためにも必須の作業といえます。
スプリントレビューにおいてゴールの達成度やプロジェクトの『進捗状況を判断する指標』にもなるため非常に重要です。
スクラムで定義するバックログとは
開発チームの自主性から創発される『スプリントバックログ』はスプリントゴールを達成するために必要な作業を視覚化するものです。
振り返りで判明した、優先順位の高い『プロセスの改善策』などが書かれており、これをスプリント中に更新できるのは開発チームのみと決められています。
デイリースクラムやレビュー
スプリント中には『デイリースクラム』が行われます。これは、毎日同じ時間・場所で開催される15分間のミーティングで、次の24時間の『作業を計画』するものです。
開発チームがゴールを達成するために自分が昨日何をしたか・今日何をするか、といったことが簡潔に述べられ『開発意識の共有』と『進捗状況の透明化』を実現します。
スプリントの最後には『スプリントレビュー』があり、ここでスプリントとしての最終的なゴール達成度と問題点・改善点などを話し合い、ステークホルダーの意見を聞きます。次のスプリントをさらに良いものとするために重要なプロセスです。
まとめ
以上がソフトウエア開発フレームワークの概説です。
『企業文化』の違いや『プロジェクトの性質』によって採用されているフレームワークは異なります。また『複数のフレームワーク』を組み合わせて応用しているケースもあるでしょう。
これまで開発に携わってきた環境が『ベストなフレームワークを選択』していたか一考してみることは『今後のキャリア』に影響するのではないでしょうか。
『副業や転職』をする際にも意識しておいた方が良いポイントでもあります。『所属チームに即応』するためにはフレームワークの理解は重要になります。
進化を続けるソフトウエア開発の現場で、読者さまの『有意義なワークライフ』の一助となれたなら幸いです。