【初心者向け】アジャイルの概念と開発手法を学ぶ!

  • このエントリーをはてなブックマークに追加
  •      
  • LINEで送る

どうも、マツバラヤスユキ(@yaspontax)です。

 

社内での公式なロールとしては存在しないがプロダクトマネージャーと自ら名乗り社外の人と会って情報交換したり、セミナーやイベント、本でプロダクトマネジメントに関する勉強を始めてからというもの、所属する企業における開発手法に疑問を抱き、アジャイル開発に興味を持ち始めました。

Web記事や本を読んで勉強しておりますが、理解度を高める為にも、振り返りを行うと為にも記事にまとめておきます。

何かを始める時に遅いなんてことはありません。気付いて始めようと思った時が、自分にとって最速のタイミングです。もしアジャイルについて学びたいと思っていたけど、なかなか重い腰を上げられていなかった方は、この記事がきっかけにして勉強を始めてみてください。

僕がアジャイルについて学び始めるきっかけになった本との出会いを以下の記事にまとめておりますので、ご興味ある方はどうぞご覧ください。

 

本記事はこんな方にオススメ

  • アジャイルに興味を持ちこれから勉強を始めたい方
  • ウォーターフォール型開発しか経験はなく、アジャイルの概要を手軽に知りたい方

 

アジャイル開発とは

アジャイル開発は、システム開発やソフトウェア開発における開発手法の一つで、現場で発生する新規要求や要求の変更への対応を主な問題意識とし、小さな単位で実装とテストを繰り返して開発を進める適応的な開発手法である。アジャイル(Agile)とは、「機敏な」という意味である。

従来の開発手法は、ウォーターフォールモデルと呼ばれ、上流の計画が細部に分解され、予定通りに流れることが大前提となっている。アジャイルという概念が出てきた背景として、従来の開発手法が機敏なものではなく、要求を随時取り入れることができない、事業環境の変化に柔軟に対応できないの諸欠陥への反省があると言われている。

アジャイルの考え方は、特に変化の激しいWeb系、オープンソース系の開発で重視されている。



アジャイル開発の特徴

アジャイル開発の特徴として、以下のようなものが挙げられる。

  • 利用者の要求を随時取り入れる
  • 実際に動作するプログラムをこれまでよりも短いサイクルでリリースする
  • 日々試験をし結果をフィードバックする
  • チームの連携を重視する
  • 計画よりも具体的な実践を重視する
  • 持続的・継続的な保守を前提とする

 

アジャイルソフトウェア開発の公式文書

2001年に、アジャイルソフトウェア開発手法 (当時は軽量ソフトウェア開発手法と呼ばれていた)の分野において名声のある17人が、それぞれ別個に提唱していた開発手法の重要な部分を統合することを議論し、「アジャイルソフトウェア開発宣言」という文書にまとめた。アジャイルソフトウェア開発の定義とそれに基づく12の原則を公式に定義した文書文書であると広く認められている。

アジャイルソフトウェア開発宣言

私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

引用:アジャイルソフトウェア開発宣言

アジャイルソフトウェアの12の原則

私たちは以下の原則に従う:
顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。

要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。

動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。

ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。

意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。

情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。

動くソフトウェアこそが進捗の最も重要な尺度です。

アジャイル・プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。

技術的卓越性と優れた設計に対する
不断の注意が機敏さを高めます。

シンプルさ(ムダなく作れる量を最大限にすること)が本質です。

最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。

チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。

引用:アジャイル宣言の背後にある原則



アジャイルである開発手法

アジャイルである開発手法として以下の開発手法が挙げられる(一部)。

スクラム(Scrum)

スクラムは、1990 年代初頭から複雑なプロダクトの作業管理に使用されてきたプロセスフレームワ
ークである。プロダクトを構築するプロセス、技法、決定的な方法論などではない。さまざまなプロ
セスや技法を取り入れることのできるフレームワークである。スクラムは、これまでのプロダクト管理
や仕事のテクニックの相対的な有効性を明確にして、プロダクト・チーム・作業環境の継続的な改
善を可能にする。

スクラムガイド(2017年11月)

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

その名前が示すように、XPはプログラマ中心の開発手法であり、技術的なプラクティスを重視して、実際に動作するソフトウェアを引き渡す頻度を高くすることでスキルの高い開発を推進する。

以下の4つに最大の価値を置く。

  • コミュニケーション
  • 単純さ
  • フィードバック
  • 勇気

リーン開発

リーンソフトウェア開発は、製造業を中心に展開されているリーン生産方式を、ソフトウェア製品に適用した開発手法で、メアリー・ポッペンディークとトム・ポッペンディークが提唱しアジャイル開発手法の1つになっている。リーン生産方式は、日本の自動車産業の強さを探るため、特にトヨタ生産方式(TPS)を研究し、それを一般化・再体系化した際に付けられた名称である。したがってリーン生産方式は、トヨタで働く人間としてどのような価値観を共有し、どのように行動をとるべきかを示した「トヨタウェイ2001」の考え方が強く反映されている。トヨタウェイ2001の2本柱は、「知恵と改善」そして「人間性尊重」である。現状に満足せずより高い価値を追求し、そのための知恵を絞り続ける行動を社員に求めている。

リーンソフトウェア開発は、具体的なプラクティスや体系的なフレームワークの形ではなく、ソフトウェア開発を実践するときの行動指針となるよう、以下の7つの原則を提示している。

原則1.全体を最適化する

原則2.ムダをなくす

原則3.チームに権限委譲する

原則4.学習を強化する

原則5.早く提供する

原則6.品質を作り込む

原則7.決定を遅らせる

リーンソフトウェア開発の7つの原則

 

アジャイルを学ぶ為の本

カイゼン・ジャーニーはかなりお気に入りの本なのですが、意識カイゼンを促し、カイゼン活動の一歩を踏み出させてくれる内容になってます。以下の記事はカイゼン・ジャーニーの感想も交えて書いた記事になっていますので、興味のある方は読んでみてください。

スポンサーリンク

SNSでもご購読できます。