初めてのアジャイル開発で知っておくべき基本的な考え方と手法

システム開発の２大プロセス

システム開発は大きくわけて２つの手法がよく用いられています。１つはウォーターフォール方式と呼ばれ、主に大規模な開発現場でよく用いられており、要件定義、設計、開発、テストといった工程を各担当が実施します。

今注目されているアジャイル開発という考え方

一方のアジャイル（素早く、俊敏といった意味の）方式では、顧客と開発者がチームを組んでイテレーション（反復）とよばれる短い単位での設計、開発、テストを繰り返して完成度を高めてゆく手法です。

実際に形になってゆくシステムを顧客と一緒に都度評価しながら進めていくアジャイル手法ですが、最近ではこの手法用いた開発案件が多くなってきました。

その中で、特にアジャイル手法の現場で感じたこと、求められた開発の進め方や手法について現役エンジニアの筆者がご紹介したいと思います。

大規模開発の現場から少数精鋭での開発現場へ

以前に某金融システムの大規模な開発現場でシナリオテストを担当した経験があります。

クライアントにとってはメイン業務の基幹となるシステムですので、要件定義、設計、開発、テストと各工程に数十人の担当者がおり、私はその中で開発・運用テスト担当の一員として参加しておりました。プロジェクト全体の参加人数にするとかなりの大所帯ということもあり、自身の担当以外の機能、作業フェーズには見えづらい点が多々ありました。

無事にシステムがカットオーバーして契約期間が終了したのち、これまでの汎用機を使った金融システムとは畑の異なる小規模なWEB開発の案件に携わることになったのですが、少数精鋭での開発現場では決められた設計書はなく、スピード感を求められるアジャイル開発での手法を用いていました。

もちろんシステム自体がこれまでとは異なる業種・システムではありますが、前職で培ったやり方やノウハウがそのままでは通じず、同じシステム開発現場であるにも関わらずまるで別世界のように感じる点が多々ありました。

アジャイル開発での戸惑い

ウォーターフォールの経験からアジャイルという手法に慣れるには多くの戸惑いがあります。あらかじめ仕様が決められており基本的には開発途中で仕様変更がない、フェーズごとに各担当が決められているといったウォーターフォールに比べて、開発を進めながらクライアントの要望を実現する、各フェーズを同じ人間が担当するアジャイルとでは真逆といっても過言ではないほど異なる点が存在します。

アジャイル開発で最もよく使用されているフレームワークに「スクラム」と呼ばれるものが存在します。

ラグビーのスクラムを思い出してください、チームのメンバーが横に並んで肩を組み、前へと押し合っている光景を連想するように、それぞれの立場の人間がチームとなり一体となって進めることを重視した手法です。

これと同じように開発者だけでなく、クライアントなどのステークホルダー（利害関係者）を巻き込み、コミュニケーションを取りながら進めることを重視します。

また要件定義や設計書といった概念がないため、必要な機能を作り上げるために関係者間で要件を共有する「ユーザーストーリー」というものを考える必要性があります。

このユーザーストーリーには「Card」「Conversation」「Confirmation」の頭文字を組み合わせた３Cと呼ばれる概念が大切となります。

Cardとは

Card（カード）では、クライアントが何を実現したいのか、何を求めているのかをブレーンストーミングの要領でリストアップしていきます。「サイト内で商品を検索したい」「商品を購入した際は決済機能を実装したい」といった要望などの項目を付箋のようなカードに書き留めるイメージです。

書き留めたカードはまず時間軸（グラフのx軸）に並べていきます。そこからそれぞれのカードに優先度で並べて、次に優先順位の軸（グラフのy軸）の観点で並べながらマトリックス表にしていきます。このように意見の見える化を図ることで、実装すべき機能とスケジュール感を把握することができるのです。

Conversationとは

１つめのCでは箇条書きの項目、いわば目次のようなものを作成しましたが、いざ開発を進めようとしてもこれだけは情報が不足しています。そこで次に必要となるのはConversation（会話）であり、書き出す時間よりもクライアントと開発者で詳細部分の機能を聞き出す時間が大切になります。よってこのフェーズで必要とされるのは会話の中でコミュニケーション力と言えるのです。

Confirmationとは

いざ開発が始まると、3つ目のCであるConfirmation（確認）が重要になります。カードを元にした情報と実際の会話を通して、何をもって完成とするのか、どの段階で完了とするのかを確認しながら取り決めておく必要があります。開発側が完成と認識していても、クライアントが確認するとイメージと違うといったケースが発生した場合、アジャイル開発の特性であるスピード感が裏目に出てしまいます。

このように３つのCを実践していく上で求められるスキルは多岐にわたります。いわば要件定義や設計、開発、テストを同じ人間が担当するわけですから、結果としてフルスタックとしてのスキルが必要になるのです。

アジャイル開発でのテスト工程が重要

このようなアジャイル手法における開発工程において、テスト工程はどの段階で実施すべきでしょうか？一般的な考え方としては、要件定義に沿った仕様になっているか、各機能が期待値通りの動作をするかといった観点でテスト仕様書や実施手順を作成して実施するといった流れになると思います。

しかし仕様が日々変化するアジャイル開発においては、テストケースも常にバージョンアップしなければなりません。もちろんそれが可能であれば手順を修正したり、テスト用のプログラムを使って自動化したりすることもできますが、すべてのチェックを網羅するのは容易ではありません。またどうしても開発作業が最優先である以上、テスト工程はどうしてもおろそかになってしまうでしょう。

テスト工程がさいごの砦と考えてはいけない

そこで重要となるのがすべての工程においてテストは実施可能という考え方です。開発を進めながら常に不具合が発生しないか、不都合なデータが作成されないか、ユーザーが使いにくいインターフェースになっていないかといった点を常に考慮しながら開発を進め、クライアントとの情報共有や実際に操作方法などをチェックしてもらうのです。

その都度改善をしながら進めることでテスト工数を削減することにも貢献でき、クライアントがイメージしていた仕様を満たしていない、あるいは使い勝手の悪いシステムになってしまったなど、予期せぬ事態を招くリスクを軽減することができます。

テスト項目を上流工程として設計する

さらには開発に着手する前にクライアントを交えてテスト項目を考えてしまうといったことも有効な手段のひとつです。

あくまでも大まかな項目しか洗い出すことはできませんが、先にテストでの観点でリストアップすることでユーザーストーリーに沿ったテスト設計が可能となり、仕様についても開発者とクライアントの間で認識の相違点を確認することが可能となるので、まさに一石二鳥ともいえるでしょう。

スキルアップと捉えれば絶好のチャンス

このようにアジャイル手法での開発現場では、プログラミングといった１つの役割だけでなく、広い視野を持ってさまざまな工程に携わることになります。

将来のキャリアビジョンを考えたとき、プログラマーからシステムエンジニアやディレクターといったポジションにステップアップを望むならば、アジャイル手法を用いた開発案件の経験は今後大きな資産となることでしょう。スキルアップを通じて将来の可能性が広がることは間違いなしです。

＼　ログインしなくても検討機能が使える♪　／

アジャイル開発の案件を見てみる