アジャイル開発とスクワッド開発｜プロの現場ではどうやって開発してるのシリーズ

開発手法という意思決定フローがあります

顧客やユーザーに何を提供するかについて意思決定の方法にはお決まりのスタイルがいつくかあり時代や規模とともに流行りがあります。 開発現場で働くことをイメージするためにもその良く用いられる開発手法について理解していくべきです。

今回紹介する開発手法のお話は次の通り

1. ウォーターフォール開発
2. アジャイル開発
3. スクアッド開発
4. 【おまけ】メテオフォール型開発

それではさっそく見ていきましょう。

ウォーターフォール開発

ウォーターフォール開発はその字の如く、滝に水が落ちるように上流工程から下流工程に、上から下に意思決定が降りてきて要件定義から設計〜実務へと具体的になっていくものです。 これは主に昔からある大きなソフトウェア会社のやり方として根強く、大きな会社組織の中での意思決定と実務に分かれていく様がそのまま現れているようなものです。 それぞれの工程の中で専門職の人員が割り当てられており、その箇所だけを次々をこなしていくことができるというものです。

工程の流れ

1. 要件定義
2. 設計
3. 実装
4. テスト
5. リリース

メリット

• 要件定義の意思決定に発注者の意思をそのまま下ろせる
• 内容と工数（作業コスト）と期日を見通しやすく開発会社への受発注に当てはめやすい
• 上級エンジニアによって設計し実務者が実装に取り掛かるので実務エンジニアに能力の差があっても画一的に取り組める
• 作業内容があらかた定められている状況なので臨時雇用エンジニアを大量に集めて取り組むプロジェクトにも適している

デメリット

• 要件定義に誤りがある場合に見直される機会がない
• 現場による工夫を入れる余地が限りなくない
• 工数が厳格に定められているがゆえメンテナンス性が犠牲になる
• スケジュールのタイトさゆえ遅延により大炎上する場合がある

ウォーターフォール開発に向いている案件

• 大規模ビジネスシステム系案件
• 社内ツール等の機能要件が満たせれば足りるソフトウェア
• 意思決定が社外にあり開発のみを受託している環境にあるもの

ウォーターフォール開発に向いていない案件

• 使い勝手やユーザー評価が製品の良し悪しを決定づけるソフトウェアやサービス 　 - ゲーム系またはSNS等のサービス
• 現場レビューやユーザーレビューを通してクリエイティブをしていく発見や改善を伴ってコンテンツを成長させるもの

アジャイル開発

より柔軟な開発スタイルとして生み出された手法にアジャイル開発があります。 アジャイルとは「素早い」や「活発な」という意味があります。 要件定義、設計、実装、テスト、リリースのサイクルをチーム主体で2週間程度の比較的短期間で行い、反応を見て再び次に必要な要件を設定することができるというものです。 つまり、より素早く開発してビジネス機会を逃さず市場に投入して顧客の反応を得て起動修正していくことができる開発スタイルになります。 または実際の商用リリースとはせず、課題ごとに小さくゴールを設定する意図として、完了後にレビューによって振り返っては再び要件定義を見直す、という軌道修正のためのアプローチである場合もあります。

アジャイル開発の手段

アジャイル開発を実現する手段にはいくつかの有名なアプローチがあります。

アジャイル開発手段

1. スクラム
2. エクストリーム・プログラミング
3. ユーザー機能駆動開発（feature driven developent）

スクラム開発

スクラムはポリシーのような存在です。 チームが一体となって共通の課題達成を目指すというもので、自発的に組織だって行動し、素早く対応するためのチームの能力の最大化に集中することを可能にするものです。意思決定においてはスクラムマスターやプロジェクトマネージャーが責任を持ちます。 これはまさにベンチャー的な考え方に当てはまりやすいです。

スクラム　仕事が４倍速くなる“世界標準”のチーム戦術 (早川書房)

エクストリーム・プログラミング

これはソフトウェアエンジニアに対する考え方の指針です。 品質を向上させ、顧客の変化する要求に対応することを目的としているもので、短いサイクルで頻繁にリリースすることで、またその時点で得られる顧客の要求を次のリリースに取り入れることができるというものです。

関連して、

• 機能は実際に必要になるまで実装しない
• ペアプログラミング
• ユニットテスト
• 自動テスト
• コードレビュー

といったことをエンジニア達は適宜継続的に取り入れてソフトウェアの品質を高めていくものになります。 コードレビューやペアによってコードを精査し、テストを導入し、必要なもののみが組み込まれているということは不適格な実装や不具合発見の短縮に役立ち、結果それは品質向上と同時に開発期間の短縮につながります。

エクストリームプログラミング

ユーザー機能駆動開発（feature driven development）

ユーザーに提供する機能価値（feature）、つまり要件ごとにチームを分け、計画や管理、提供を行っていきます。目的は継続的な反復で開発とリリースを行なっていくことにあり、それぞれは2週間以内に完了しリリースしていくよう細分化して取り組まれます。

チケット駆動開発

あえて追記的に記載しましたが親和性が高くアジャイル開発の一部としてよく用いられる手法です。 要件定義から作業内容に落とし込んだとき、プロジェクトマネジャーや企画者、またはテスト者がチケットというタスクを発行して実務者に渡し作業を行うスタイルで、原則全ての実務はチケットのもとに行います。 これにより、要件はうやむやにならず進捗管理のされた決定的な作業指示となります。

よくドラマなどで見かける付箋の付け外しもこの部分を指していると言っていいでしょう。 そのほかチケット管理専用ソフトウェアがあって、「Redmine」「JIRA」「Backlog」「Brabio」「Mantis Bug Tracker」あたりはよく使ってきました。

アジャイル開発のメリット

• チームが主体的に取り組めることでより大きな発見や成果を出しやすい
• 継続的にリリースすることで市場の反応をこまめに見て改善していけるので市場の動向を掴みやすい
• 2週間といった短期でリリースされることでチームが健全に活動することができ継続して取り組みやすい

柔軟に迅速に開発することを目的に近年取り入れられてきた手法であるがゆえ働きやすそうに思います。

アジャイル開発のデメリット

• まだプロジェクトマネジャーやアジャイルマスターのような意思決定者に依存する

スクワッド (squad)開発 ｜次の時代のスタイル

スクワット開発は近年、海外も含めたスタートアップベンチャーや日本テック企業が取り入れはじめているという事例を目にするようになってきました。

スクワッド体制であることを公表している企業のいくつか

• Spotify（音楽配信サービス）
• アフラック生命保険（うち、ネット保険）
• メルカリ（フリマサービス）
• クラシル（料理レシピ動画）

スクワットは分隊や部隊といった意味で、前記するユーザー機能駆動開発のような要素ごとにチーム化しているものですが、最大の違いはチーム自体に必要な全ての人員が揃っていて自立しているということが挙げられます。 またその割り当てられた要素に対する権限はそのスクワットというチームに任され、機能が準備出来次第リリースできる状況にあります。 これは予め、ソフトウェアにもそういった要素ごとに開発やリリースが分離できる設計がされていることが求められます。

分離できていることで、それぞれのチームの進捗に引っ張られることなく、ミッションという組織の目標のもと、各スクワッドが自立して計画を遂行していきます。 また意思決定においても、プロジェクトリーダーは設置されず、プロダクトオーナーが推進していくミッションやロードマップに、チームが自分たちで考え実現していく自律性を持っています。 これはさらに近代的で技術力のあるベンチャーにとって、より迅速に遂行できる開発スタイルであると言えます。

スクワッド

スクワッドは1つの要素や機能を受け持った一つのチームを指し、多くの場合8名以下で編成されるといいます。 アジャイルとどう違うのかというと、スクワッドは共通のvvvミッションやスクワッドの課題に向けて自分たちで考えて解決策を導いていくことにある。 単なる「野菜切り係」ではない、ということです。

ドライブ

いくつかの関連するスクワッドを束ね連携を深めた、事業部やミニ企業のような位置づけになるものです。 関連するスクワッドどうしが情報や技術やコードを共有することでより円滑に取り組めるときドライブにまとまります。 例えば決済関連の決済認証ドライブ、ハードウェアへの組み込みを受け持つハードウェアドライブ、といったものが挙げられます。 ドライブどうしの依存も最小限に抑えられ、ドライブが独立して意思決定できリリースも準備が出来次第できます。

チャプター

チャプターはドライブ内の複数スクワッドを横断し同じ専門性をもったグループ。 つまりフロントエンジニアチャプターだとかデザインチャプターといった位置づけになります。 この同じ専門性をもった人間どうしの連携やチャプターリードの働きによって情報共有や助言、指導、といったコミュニケーションが図れます。

ギルド

最後にギルドは、同じ専門分野に興味があるメンバーがドライブを横断して形成されるコミュニティです。 会社組織ではなく権限をもったものではありませんが、情報共有やカンファレンスなどの開催を通して社内コミュニティを形成します。

参考

炎上プロジェクトの失敗例｜メテオフォール型開発

この「メテオフォール型開発」は一時、ソフトウェアエンジニア界でネタとして有名になりました。 こういう開発スタイルがあるわけではなく、従業員たちはせっせと「アジャイル開発」で「スクラム開発」していたり、しっかり要件定義して「ウォーターフォール開発」に取り組んでいても、「神」と言われる会長や社長、役員や業界著名大先生といった大なたを振るう人間の鶴の一声によって、一から作り直しが言い渡されるというものです。 このことはソフトウェア開発において往々にしてある、ということを面白おかしく示していました。

なおこの場合は必ずしも金銭的に不遇なわけではなく、延期する場合にはその分の開発費がしっかり出ており、従業員であれば延期しようが別案件に移動しようが給与面では影響はありませんが、一向にゴールできない、しっかりと計画的に開発業務に当たっていたのに作り直しになった、といった精神面に対して計り知れないダメージを与えるものです。

あるいはひどい環境の場合にはスケジュールは変わらないので残業が積まれる、ということになるかもしれませんがここ数年は労働環境や残業時間に対して大変シビアになってきているので、そういった根性論は会社もとりずらくなっているはずです。 また延期するなり、きちんと戦ってくれるプロジェクトマネージャーと一緒に仕事をするということは必要かもしれません。

アジャイル開発を素朴にやって失敗する。: 日本で実践する発注型アジャイル開発　和アジャイルのすすめ【要約版】 (MyISBN - デザインエッグ社)