初めまして。
京都でアジャイル開発を実践しているITエンジニアの あじゃりもち と申します。
フクザワイナゾウ氏と大学院時代から縁があり、ブログのタイトルと方向性が異なりますがアジャイル開発の記事を投稿させてもらうことになりました。
よろしくお願いいたします。

さて、記念すべき初投稿は、これからアジャイル開発に関わる可能性がある方々に向けて、開発を始める前に理解しておく重要なポイントを３つ紹介させて頂きます。

その前に、簡単に あじゃりもち のプロフィールを紹介させて頂きます。

• 2013年頃よりアジャイル開発に関心を持ち、主にScrumとXP（両者ともアジャイル開発に分類される開発手法）について学び始める。
• 2014年頃から、仕事でもアジャイル開発に触れる機会が増え、様々な案件でのアジャイル開発を経験。
• 2017年 ユーザ企業に移籍し、内製型のアジャイル開発を経験。現在に至る。

ご覧の通り、決してアジャイル開発のキャリアが長い訳ではありませんが、自分の経験した範囲で１つでも役に立てる情報を発信出来ればと考えています。よろしくお願いします。

また本来、アジャイル開発に関する説明も必要だと思われますが、今回は既にアジャイル開発の概要程度は知っている方を読者として想定しているため、次回以降に割愛させて頂きます。

理解しておくべき３つのこと

これから紹介する３つのことを理解していれば、アジャイル開発の成功確立はぐんっとアップすると思います。私が現場での経験で学んだ事です。

1.「上手く作る」から「上手く稼ぐ」へ、価値観のシフトが必要

ウォータフォール開発のような従来のやり方からアジャイル開発へシフトさせる際、多くの人は「プロセスを変えれば上手くいく」と考えるかもしれません、しかしそれでは上手くいきません。ウォータフォール開発とアジャイル開発では前提となる価値観が異なっています。プロセスを実行する人や、それを管理する人の価値観もセットで変えない限り、プロセスを何と無く真似た中途半端なアジャイル開発風？開発となり、アジャイル開発のメリットを得ることは難しいです。

ではウォータフォール開発とアジャイル開発の価値観の違いを説明します。端的に言えば次の通りになります。

• ウォータフォール開発は計画通りに開発することに価値を置く
• アジャイル開発はビジネス観点での費用対効果を最大化する事に価値を置く

ウォータフォール開発の場合、当初に計画した通りのプロダクトを、計画したスケジュール通りに、計画通りの予算で開発する事を目的にしています。目線はあくまで作り手側（開発者視点）です。作ったプロダクトがエンドユーザに受け入れられて顧客に収益をもたらしたか、否かは、ウォータフォールという手法の守備範囲外なのです。

一方、アジャイル開発の場合、より少ない予算でより大きな利益を生む（つまり費用対効果を最大化する）事を目的にしています。ビジネス目線です。計画通りに開発したか？　効率的に沢山のソースコードを書いたか？　ではなく、収益（又は費用削減効果等のビジネス目線での効果）でプロジェクトを評価します。
計画した通りのプロダクトを、計画したスケジュール通りに、計画通りの予算で開発したとしても、収益を生まなければアジャイル開発の価値観では失敗なのです。

この価値観の違いを理解しないまま、ウォータフォールの価値観でアジャイル開発に取り組むと様々な問題を生じます。

• 当初に計画したものをただ反復的に開発しただけで、プロダクトの価値（プロダクトから生じる収益や費用削減効果など、ビジネス目線の成果）を高めるレビューやプランニングを活用せずに終わる・・・わざわざアジャイル開発を導入しなくても良かったじゃん！
• エンドユーザのフィードバックに基づく機能改修を現場は「手戻り」とネガティブに捉える
• 追加要件や改善要望が出された際に、初期要件とのトレードオフが出来ずにスコープが肥大化する
• etc…

2.アジャイルシフトの影響範囲は広い！

プロジェクトマネージャなど、組織の中である程度立場の高い人に多い印象ですが、「アジャイル開発は現場の開発者が変われば導入できる」という誤解があります。開発者がアジャイル開発のやり方を覚えればプロジェクトにアジャイル開発を導入できると考えているのです。
このような組織では往々にして、アジャイル開発の研修を開催してもマネージャ層は多忙を理由に参加されません。現場の開発チームと各チームリーダ層だけで研修を行うことになります。

しかしこれは間違っています。

アジャイル開発をプロジェクトに取り入れようとすれば、プロジェクトを治める組織レベルでルールの見直しが必要だからです。

例えば品質管理のやり方について、ウォータフォール開発の場合は工程毎に完了判定を行い、上位層の承認を得て次の工程に進むのが一般的だと思います。一つの工程が数ヶ月にも及ぶウォータフォール開発の場合は問題ありませんが、1週間〜2週間で要件決定から開発、デプロイまで実施するアジャイル開発に同じルールを適用するのは現実的ではありません。

月曜日の17時から要件定義の完了判定、翌火曜日の12時には基本設計の完了判定、同日17時に詳細設計の完了判定…と物凄い頻度で判定会議が必要になります。さらに完了判定のあいだ開発は止まります。さらにさらに、開発の合間に判定会議用の資料を作って、レビューもして…

恐れく破綻するでしょう。

このように、アジャイル開発の導入には組織レベルで変更が必要なことが沢山あります。まずは上位層の人達がその必要性を理解することが必要です。

3.アジャイル開発は信頼関係を前提にしている

アジャイル開発では、要件の見積りの決定権が現場の開発チームにあります。
ウォータフォールの場合はプロジェクトマネージャやチームリーダが見積りを決めていたと思います。ですので、これまでウォータフォール開発でプロジェクトマネージャやチームリーダを担当されていただ方から「開発チームに見積りを任せて大丈夫なのか？」という質問を受ける事が多いです。
「開発チームに見積りを任せたら、彼らはサボるために過大な見積りをするに決まっている」とおっしゃる方までいます。

見積りの他にも、ウォータフォール開発のPMやチームリーダが不安を感じるようなポイントはいくつかあります。

アジャイル開発のフレームワークが何故そのようになっているかと言うと、信頼関係を前提にして開発チームに裁量や権限をもたせた方が、結果的にプロジェクトのアジリティを高め、費用対効果の最大化に有利であったからです。

ですので、アジャイル開発を始める際は開発チームだけでなくプロジェクト全体でのチームビルディングを行い、お互いの信頼関係を高めておく必要があります。

先の見積りの例になりますが、要件の決定権者（プロダクトオーナと呼ぶ）と開発チームの間に信頼関係があり、お互いに譲歩しながらチーム全体として最適な解を議論できれば、開発チームは過大な見積りをする必要がありません。
　しかし、両者に信頼関係が無く、お互いに「開発チームは作業を与えないとサボる」「プロダクトオーナは要件を詰め込もうとする」と考えていたら、自然に見積りは過大（バッファを多く積む）になります。
　そこでプロダクトオーナが立場を利用して（本来、開発チームとプロダクトオーナに上下関係はありませんが、実際のプロジェクトではプロダクトオーナの方が強い立場を持っている事が多い）無理やりにも開発チームにスコープを詰め込めば、更に見積りは過大になる事でしょう。
　最終的に開発チームが見積りをする意味が無くなり、従来通りにプロジェクトオーナやチームリーダが各メンバに指示を出して開発をする従来のスタイルに戻ります。しかしそれではアジャイル開発を実践できているチームにスピードで勝つことは難しいでしょう。

以上、長くなりましたが、今回は私が経験から感じているアジャイル開発を始める前に理解しておくべき３つのことを紹介させて頂きました。最後までお読み頂きありがとうございます。