前回の記事をご覧になってアジャイル 開発や、アジャイル 開発のメリットデメリットについてご理解いただけたでしょうか。

今回は、アジャイル 開発ででてくる用語について見ていきましょう。ただでさえ横文字が多いIT業界ですが、アジャイル 開発でも様々な単語がでてきます。

そんなに多くないので覚えてきましょう。

チームについて

プロダクトオーナー

プロダクトの価値最大化に責任をもつ人です。プロダクトバックログ(必要な機能)と優先順位の明確化を行います。プロダクト自体に責任を持つ人がなることが多いです。場合によっては外部の人もあり得ます。

スクラムマスター

スクラムの促進と支援に責任をもつ人。チームから障害を取り除き、ファシリテート及びコーチングします。スクラムマスターはアジャイル経験者にお願いしましょう。

開発チーム

職能横断的でプロダクトに必要な専門家で構成。責任自体はチームで負います。問題VS私たち。

開発について

インセプションデッキ

「なぜ我々はここにいるか」などのWHYやトレードオフスライダーなどのHOWをチームで向き合い理解を揃えるためのデッキ。目的やミッション、約束事や優先順位などを明確にしておきます。チームに求められる「期待」を可視化するのです。

ワーキングアグリーメント

チーム開発で前提としておく決まりやルールの共通理解です。本番リリースはペアでやる、ユーザーのFBを最優先におくなどです。多すぎても運用できないので全体で７つ程度を目安に入れ替えたり、内容を改めます。

ユーザーストーリー

「要件」です。ユーザー目線でユーザーにとって価値があり、本当に実現すべきこととなります。「前回と同じ商品を買いたい」「人気順や新着順で並べ変えたい」など機能をユーザー目線でポストイットなどに洗い出していきます。

ユーザーストーリー・マッピング

ユーザーの行動を時系列に書き出し、発生する課題やそれを解決する機能を洗い出します。例えばユーザーが「前回と同じ商品を買いたい」という行動に対しては、購入履歴の表示という機能が思い浮かびますよね。

イテレーション

イテレーションとは開発サイクルのことです。アジャイル開発は反復的(iterative)にサイクルを繰り返し、改善を少しずつ続けていきます。イテレーションはXP(エクストリームプログラミング)で使われる用語です。スクラムにおいてはスプリントと呼ぶことが一般的で、1〜2週間が目安です。

スプリント

イテレーションと紛らわしいスプリントですが、同じくアジャイル 開発の1サイクルの期間の単位です。こちらはスクラム(開発においての仕事の進め方を意味するフレームワーク)で使われます。

プロダクトバックログ

作るべき物一覧です。タスクの見える化が目的です。必ず優先順位をつけ意思決定をスムーズにしなくてはなりません。

注意点

• それぞれが独立していて明確で他項目に依存しない
• 項目毎の内容を小さく(1日以内)
• 優先順位で並べ何からやればいいか明確にする(入れ替え可能)

スプリントプランニング

1. 【WHATの計画作り】これからのスプリントにおけるゴールを話し合い必要となる機能をプロダクトバックログから選択
2. 【HOWの計画作り】選択したプロダクトバックログをどのようにして実現するのか、そのために必要なものの洗い出しを行う

計画したことをなぁなぁにせず、いかに「やりきる」ことを反復し続けられるかが成功の鍵となります。定義→開発→テストにおいて何をもってOKなのかを予め箇条書きで明確にしておきましょう。

スプリントレビュー

スプリントプランニングで立てた計画がどのように実行されたか、レビューし次の構想を練るのがスプリントレビューです。関係者全員が参加します。

• 進捗についてプロダクトオーナーが説明。完成、未完成機能について
• 今回のスプリントの成果物をお披露目。開発チームがデモを行う
• デモの結果に対してフィードバックを集める
• 今後必要な機能について構想を練りプロダクトバックログを改訂する

スプリントレトロスペクティブ

プロダクトだけでなくチームも共に成長し作り上げていくもの。アジャイル 開発ではチームも成果物として考えます。スプリントレトロスペクティブでは、チームの内省を行い振り返り、改善していきます。

プランニングポーカー

ベテランも新人も一緒にチーム全員で工数の見積もりを行う手法です。マネージャーが勝手に全てを決めてしまうと、齟齬が生まれがちです。

とはいえ実際プランニングポーカーを行うとバラバラな工数になることがほとんどです。ですが、これ自体がミソで、何故そう思ったかをお互いの経験や憶測を踏まえ、納得いくまで話し合って決めます。それにより最初から認識のズレを解消するということです。

ポイント

見積もる規模感で使われる単位。あくまでも絶対的な時間ではなく相対的なものなのでポイントといった単位を使う。プランニングポーカーでは、(1)、1、2、3、5、8、13、21、34、、と前２つの数字を足すという規則の数列のフィボナッチ数列が広く使われています。仮に10、11、12、13、、と続くと感覚が狭く比較がうまくできなくなるためです。最初は細かく刻みすぎず、2、8、13、21のように大まかに始めてみるのもいいでしょう。

ベロシティ

チームの開発速度のことです。1スプリントにこなせたチームのポイントの合計です。次のスプリントの計画で、前のスプリントを振り返り達成可能であるかどうかを判断にするためのものがベロシティです。

さらに全体でどれくらいの工数となるかの見積もりが可能となります。全体のストーリーの合計が100だとして、チームのベロシティが10なら、100÷10で10スプリントとなります。1スプリント週間とする場合10週で完了すると見込みと言えます。

ベロシティは直近のものだけでなく、平均で見るようにしましょう。例えば直近3スプリントのベロシティが10、12、8でしたら8ではなく10とカウントするべきです。

朝会(デイリースクラム・たちっぱ)

進捗報告と問題の早期発見のために毎朝行います。デイリースクラムやたちっぱともいいます。基本的には以下項目を共有します。

• 昨日やったこと
• 今日やること
• 障害となっていること

そして、他の案件や家の事情で早退や途中で抜ける場合も朝会で共有します。透明性をもち、顔を合わせ決まった時間に繰り替えし集まりリズムを整える事が大切です。その際は、それぞれのPCを見るのではなくボードや、一つのディスプレイに集中しましょう！

ポイントとしては会議中に詳細に発展し、長くなってしまう時は、朝会の後に関係者のみで話すようにしましょう。二次会といったりします。

ペアプログラミング

一つのPC及びディスプレイで、2人でプログラミングを行うことです。高い集中力を保ったまま、レビューを同時に行う事となり、書き直しも少なくなるペアプログラミングは効率的です。

KPT

スプリントの最後にチームで振り返ることはとても重要な作業です。その際の手法にKPT(Keep/Problem/Try)があります。読み方はケプトと呼びます。

• Keep →よかった事・続ける事
• Problem→悪かったことや問題点
• Try→KeepやProblemをもとに挑戦する事

作業手順としては以下のようになります。

1. KeepとProblemをそれぞれポストイットに書き出しておく
2. Keepを貼りだしスクラムマスターが共有
3. Problemを貼りだしスクラムマスターが共有
4. それらを元にTryをチームで考案し、貼る
5. Tryに例えば各自3票ずつなどを投票し、上位3項目を目安に優先順位及び担当者、期日を確定

更に、GKPT(Goodのシェア)や、KPTのあとに各メンバーへの感謝を示すなどというオリジナリティを追加する文化も素敵ですね。

まとめ

いかがでしたでしょうか。今回は前回の記事に引き続きこれからアジャイル 開発を始める方にむけて、アジャイル の用語を解説しました。次回はいよいよ実際にアジャイル開発の実例や運用方法を学びつつ、実際にアジャイル 開発をはじめていきましょう。

プロダクト開発のご依頼をいただいたり、自社開発で新プロジェクトを立ち上げることになったあなた。

アジャイル 開発という開発手法を聞いたことはあるけれど、実際どうすればいいの？何から始めればいいの？と困ってませんでしょうか。

このシリーズではそんな初心者エンジニアの方やPMになりたての方に向けて、アジャイル開発での経験や失敗を繰り返してきた筆者が、アジャイル開発について説明していきます。

• アジャイル 開発について
• アジャイル 開発のメリット・デメリット
• アジャイル 開発の用語 (失敗しない！初めてのアジャイル開発②〜アジャイル 開発について知ろう〜)
• アジャイル 開発で失敗しないために
• アジャイル 開発の最強のチームとは
• アジャイル 開発おすすめ運用法

読み終わる頃には、上記がある程度理解できて、早速アジャイル 開発に取り掛かれる状態を目標とします。※ものすごくざっくりと簡潔に書くので詳細はこちらの本などから勉強をおすすめします。

アジャイル開発とは？

アジャイル 開発について知るためには古くからあるもう一つの開発手法について触れておく必要があります。大きく分けて二つある開発手法のうちのもうひとつ、ウォーターフォールモデルです。

要件定義＞設計＞実装＞テスト＞運用

このように滝のように工程が決まっている開発手法となります。要件定義で、クライアントの要求に対して、ソフトウェアで実現することを決めます。

そして基本設計で機能やどう実現するかを決め、実装で開発に入ります。

開発が終わると単体テスト(単体機能)と結合テスト(機能間)、総合(システム)テストを行った後、ようやくリリースとなります。ローンチともいったりしますね。その後運用フェーズに入っていきます。

いかがでしょうか。とても納得感のある開発手法に思いませんか？要件定義や設計から順番になされ、スケジュール通りにピシッと進めていく。抜け漏れなく工程を管理し、レベルの高いスケジュール及び品質管理が要求されます。

開発において最も重要なQCD(Quality:品質、Cost:コスト、Delivery:納期)の見通しや精度も高くクライアント側も安心して任せられそうですね。

その反面、あることが絶対にできなくなっています。

それは、工程の後戻り、仕様変更です。

そして工程にあわせた分業化により、予算があり最適な人材配置ができる大規模開発にはむいていますが、仕様変更や予期せぬトラブルなどの不確実性には弱いです。つまり小規模のWEB開発やアプリ開発、頻繁な仕様変更が予測されるゲーム開発などはウォーターフォールは向いていないと言えます。

では、アジャイル 開発をみてみましょう。

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

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

ウォーターフォールでは、要件定義＞設計＞実装＞テスト＞運用の工程の一つ一つの成果物が完成品となり、例えば設計段階で「そもそもこの機能いらなくない？」となっても要件定義には戻れないのです。

その点アジャイル 開発では以下の図のように開発工程が進んでいきます。1〜4週間のイテレーション（反復）と呼ばれるサイクルを繰り返します。

1.柔軟な軌道修正が可能

もともとAgileとは「機敏な、回転の速い」という意味です。

アジャイル 開発では、小さくスプリント という一定の期間を繰り返し進んでいくので、PDCAサイクルを回しながら柔軟に進めていくことができます。

早い段階でシステムに触れ、フィードバックを得ることができ、柔軟かつ機敏な軌道修正が可能です。

2.素早くスピーディに開発ができる

ウォーターフォールに比べ、がっちがちにスケジュールを組んだりする必要がありません。設計から開発に移行する早さが、とても早くスムーズです。後述しますが、ドキュメントの量も最小限であるため、その分開発の速度もスピーディです。

3.ドキュメントが最小限

ウォーターフォールと比べ途中で仕様変更などある前提でプロジェクトが進みます。なので、予め文書作成を細かくやる必要がありません。そして分業もウォーターフォールほどしていないため、「あのドキュメントはどうだ」「この実装はどうだ」など、チーム内での不毛な評論が発生しにくいともいえます。

さらにドキュメントが少ないので工数が削減され、低コストで短納期の実現にもつながります。中小企業ですと低コストでスピーディな開発を要求されることも多いので、アジャイル 開発はむいていると感じます。

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

1.納期遅れが多い

柔軟な分、かっちりと決まっていないため、スクラムマスターはじめチームが自律し主体的に動いていないとすぐにスケジュールがぶれます。日本の企業では上が設計した作業をこなすという工程が多いので、言葉を選ばずにいうと思考停止でも仕事がもらえ、なんとなくこなしていればどうにかなるという一面がありますよね。

アジャイルの場合、毎日のスクラムなど始め、チーム全員で決めることも多いので、プロダクトに対してある程度前のめりな姿勢が要求されます。その分チーム自体のレベルが低いと納期遅れが頻発するのも事実です。柔軟な分、無駄な贅肉(価値を生まない機能)を開発してしまったり、迷走した結果納期に遅れてしまうことも多いのです。

2.ブレやすい

スプリント毎に振り返り、見直します。その際陥りがちなのが機能のブレです。これも必要じゃない？これ本当にいる？など様々な意見が飛び交うのは悪いことではありません。しかし、そもそもなんのために作るのかというところをしっかりチームで共有していないと余計な機能を開発することになったりと、ブレがちなのも事実です。

3.難易度が高い

正直これが一番ネックではないでしょうか。チーム全体でストーリーポイントをフィボナッチ数列で見積もったりと議論する場が多くなります。そのため、チーム全体のレベルがモロに見積もりやスケジュールに反映されます。

また、プロダクトの管理も柔軟だからこそ難易度が相当高いです。会議に当てる時間もある程度割かなくてはいけないため、マネージャーは予算管理や工数管理も、バッファをもった計画を立てる必要があります。

まとめ

いかがでしたでしょうか。今回はアジャイル 開発が初めての人に向けて、ざっくりとアジャイル開発の全体像について説明しました。ウォーターフォールとの違い、アジャイル 開発のメリット・デメリットについて理解していただけたかと思います。次回「失敗しない！初めてのアジャイル開発②〜アジャイル 開発について知ろう〜」はアジャイル 開発で出てくる用語を知り、より実戦に向けた詳細を学んでいきましょう。