アジャイルについて

2016年6月15日 plugout
  1. アジャイルとは？
    アジャイルとは『すばやい』『俊敏な』という意味です。
    近年、アジャイル開発という言葉を耳にする様になったと思います。
    アジャイル開発とはなんでしょうか？
    簡単に説明すると、少人数の熟練した技術者が集まり、短期間でシステム開発を行うことです。
    「なんだ、その様なスタイルの開発は今までもあったし、名前が付いていなかったので名前を付けただけなんじゃない？」と思ったあなた、その認識は大きく違っています。
    どこが違うのかを詳しく説明して行きます。

  2. ウォーターフォール開発との比較
    2.1 ウォーターフォール開発手法とは
    ソフトウェア開発手法として、多くのプロジェクトでは、ウォーターフォール開発を行ってきました。
    システム開発工程を次の様に決め(プロジェクトにより工程名称は異なる場合がある)、最初の要件定義で決まった内容を基にシステム開発計画を立案し納品まで開発作業を行います。
    業務分析
    要件定義
    基本設計
    詳細設計
    製造
    単体テスト
    結合テスト
    システムテスト
    開発工程の最後には必ずチェックを行う機会があり、そのチェックを通過しないと次の工程には進めないという厳格なルールが存在します。
    そのため、工程の途中で何か変更が発生すると、すでに完了した工程まで遡ってやり直す必要が発生する場合もあります。
    これが開発期間の延長と開発費用の増大を発生させる大きな要因です。
    各開発工程が終わってから次の開発工程に着手する様子から、水が上から下に順々に落ちてゆく様子になぞらえて、「ウォーターフォール」と呼ばれています。
    2.2 ウォーターフォール開発を採用する理由
    大手SIerは開発(または作業)標準というドキュメントを持っています。
    これは各工程でどの様なドキュメントやプログラムを成果物として作成し、どの様に作業をすれば良いかを事細かに記載したプロジェクト運営手順書の様なものです。
    この開発標準がウォーターフォール開発を前提に作られているので、結果的にウォーターフォール開発になってしまいます。
    開発標準があると大規模プロジェクトの場合、プロジェクトメンバーへの作業指示や管理方法が統一されるので、参画技術者のスキルレベルに差があったとしてもその差を吸収できるというメリットがあります。
    人を人とみなすのではなく、機械の部品の一部とみなす考え方に近いといえます。
    これが、IT業界の技術者不足を招いている大きな要因であるとも考えています。
    2.3 アジャイル開発は救世主になれるのか
    アジャイル開発は、おおまかに次の様な感じで開発を進め行きます。
    メンバー：少人数の熟達した技術者です。
    作業の切り出し：短い期間(大体2週間が多い)で完了する様に作業を分割します。
    グルーミング：作業の分担と優先順位を決めます。
    開発：切り出された作業をその期間内に完成させます。
    レビュー：エンドユーザに確認してもらいます。
    修正作業や仕様変更は新しい作業として短い期間に切り出されます。

  3. 反復開発
    アジャイル開発は、反復(イテレーション)開発と言われます。
    同じ反復開発として、スパイラル手法を連想される方も多いのではないでしょうか？
    スパイラル手法でも、プロトタイプとなるプログラムを完成させて、そこで確認できたら、次の拡張部分を完成させてまた確認して行きます。
    それを繰り返すことで最終的なシステムを構築する手法です。
    アジャイル開発とスパイラル手法は似てはいますが、スパイラル手法のプロトタイプは完全形を作るのではなく、あくまでも作り手のイメージを具現化した非完全形でしかありません。
    そこでエンドユーザとの乖離が大きければ、手戻りも大きいし次のプロトタイプ完成までの期間は長くなります。
    アジャイル開発のイテレーションは、決められた期間で完成する様に作業を切り出していますから、その期日にエンドユーザにレビューしてもらうことが可能です。
    それは、機能的に完成したものなので、開発者は次の作業にすぐに取りかかれば、次の期日にはエンドユーザにレビューしてもらうことが可能になります。
    これを繰り返して開発を進めて行きます。

  4. 計画重視よりも価値重視
    ウォーターフォール開発では、最初の要件定義で決まったものは、何か何でも開発をするという計画重視の考え方です。
    だから途中で仕様変更が発生すれば、開発期間の延長と開発費用の増大に繋がります。
    開発期間の延長は、最初の計画時から稼働時までの時間の経過を大きくすることになります。
    時代の移り変わりの激しい昨今では、発注日と稼働日の時間差が大きくなるということは、それだけ事業収益の機会を損していることにもなりかねません。
    アジャイル開発では、計画重視ではなく価値を重視します。
    エンドユーザの予算と稼働日が決まっているのであれば、その稼働日までに開発できる機能に限定して開発すれば良いでしょう。
    稼働後、機能追加を順次行えば、最終的にエンドユーザの希望するシステムを開発できるという考え方です。

  5. スクラム
    スクラムとは、アジャイル開発手法のひとつです。
    スクラムの優れているところは、ソフトウェア開発だけに留まらず、他の業務でプロジェクトを運営する上でも活用できる点です。
    スクラムでは、登場人物と役割が明確になっています。それに大切なのは、一人の人間が複数の役割を兼任しないという大原則があることです。
    ウォーターフォール開発では、プロジェクトマネージャーがプロジェクトを計画／運営し顧客との折衝も行うという、かなりの重責を担っています。
    スクラムでは、プロジェクトマネージャーは存在せず、プロジェクトの主体は開発チームになります。
    そして、ウォーターフォール開発では発注者でしかなかったエンドユーザは、スクラムでは出来上がった機能をチェックする役割を常に担います。

  6. 登場人物と役割
    (1)エンドユーザーと利害関係者
    開発するソフトウェアの発注者である。
    プロダクトオーナーと連携し、ソフトウェアの納期、機能や要求をまとめる。
    スプリントレビューでは、リリース可能な機能に対して、本来の目的と適合しているかどうかや進捗状況を確認する。
    (2)プロダクトオーナー
    プロダクトオーナーとは、作るべきソフトウェアの機能や要求をすべて理解しているチームのリーダーのことである。
    このため、開発するソフトウェアの機能の実装と優先順位に責任をもっており、プロダクトバックログと呼ばれるソフトウェアの機能や要求の整理と優先付けを行う。このため、プロダクトオーナーは、ソフトウェアの機能や要求のメンテナンスを行うために、技術的なことも含めてプロジェクトに係るすべての利害関係社と常に話し合いを行い、ソフトウェアの機能や要求を必要に応じて追加や削除を繰り返しながら整理していく。
    また、開発チームからの機能や要求に関する疑問に対して、スクラムマスターと協働しながら、できる限り早く回答を行い、実装やテストを支援して、チームの生産性を向上させる役割も持っている。
    (3)スクラムマスター
    スクラムマスターとは、プロダクトオーナーと開発チームのコーチとして、最高のパフォーマンスを発揮できるようにするチームのマネージャーである。
    スクラムを導入する場合、チーム内に不安や混乱が生じることが少なくない。スクラムマスターは、チームのマインドセットシフトの手助けを行い、スクラムの導入に関して直面する不安を解消しながら、チームに合った適切なプロセスを定義してチームの生産性を改善を行っていく。
    またチームの生産性を向上させるために、チームメンバーが直面した障害や外部からの妨害を取り除くことにも責任をもつ。スクラムマスターはサーバントリーダーと呼ばれており、チームメンバーへ指示を行わず、チームを助けるために活動のみを行う。
    (4)開発チーム
    開発チームとは、プロダクトオーナーと話し合って決めたスプリントバックログを、予め決められた期間で設計、実装及びテストを行うチームのことである。 スクラムにおける開発チームでは、アーキテクトやデザイナー、データベース管理者、テスターなどが一つのチームとして構成され、設計と実装、テスト等、プロダクトを作るために必要な作業に責任を持つ。
    また、開発チームはソフトウェアを開発することに専念するために、チーム外のコミュニケーションは基本的に行わない。開発時に機能の詳細や要求事項で疑問が生じた場合は、開発するための機能や要求の詳細を把握しているプロ ダクトオーナーに対して相談を行う。発時に発生する様々な障害や問題の場合は、スクラムマスターに相談をしながら解決していく。

  7. 開発者が中心でエンドユーザも巻き込む
    スクラムの場合、開発者がプロジェクトの中心になります。
    開発者は何か問題が起きると、スクラムマスターやプロダクトオーナーと相談して問題を解決します。
    そのために、スクラムマスターやプロダクトオーナーは縁の下の力持ち的な役回りになります。
    プロダクトオーナーがエンドユーザと関連しているので、エンドユーザとも連携が密になります。
    ウォーターフォール開発のエンドユーザは、発注者の立場で最後に出来上がったものをチェックし受け取る存在で、プロジェクトの途中で頻繁に口出しができる状況にありませんでした。
    しかし、スクラムではエンドユーザを巻き込んで、むしろ積極的にプロジェクトに関与させる様になっています。
    これが、変化に強いソフトウェア開発ができる大きな要因に繋がっています。

  8. OutSystems Platform との融合
    超高速開発ツールでもあり、運用プラットフォームでもある OutSystems Platform とスクラムによるソフトウェア開発が融合すれば、開発者にとってもエンドユーザに取っても大きなメリットが出てきます。
    この点をご理解頂ければ、OutSystems Platform を使ったスクラムによるソフトウェア開発が効率的且つプロジェクトの成功率を上げるかをご理解頂けると思います。
    これは、単純にQCDの向上に留まらず、ソフトウェア業界の働き方を変える事にも繋がると確信しています。