第4回従来型開発とアジャイル開発の違いその２

この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。

第4回目のテーマは、前回と同じく「従来型開発とアジャイル開発の違い」となり、前回とは異なる観点で比較を続けていきます。

この内容はUdemyで公開しているオンラインコース「現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム入門編」の内容を元にしています。

見積もりと計画づくりの比較
プロジェクト期間の比較
品質の比較
契約の比較
予算の比較
様々な比較を終えて

見積もりと計画づくりの比較

見積もりと計画づくりを比較してみましょう。見積もりと計画づくりは、チーム運営でとても重要な要素だと思います。ただ、ここにも大きな違いがあるため、従来型のプロマネ経験者であれば、アジャイル開発のやりかたに少し困惑する部分があるかもしれません。

繰り返しになりますが、従来型は、作るものが決まっていて、計画を長く見通せるものが得意です。よって、リリースから逆算して計画を立てて行くのが基本になります。

やることが決まっているので、この方法が通用しますが、逆に言うと、プロジェクト初期にやることを洗い出せない場合は、うまくスケジュールを作れません。おそらく定番なのは、「経験上これぐらいかかる」とざっくり工数を見積もり、スケジュールを立てる方法でしょう。ただ、このやり方だと、早期に見積もりを正確にしなければ、やることが意外にも大きくなってしまった場合、大きなリスクになります。

アジャイル開発は、短いリリースを繰り返していきます。アジャイル開発は、小さな成果物をちょっとずつリリースしていくので、ゴールまで成果を積み上げていく形のスケジューリングになります。

短いリリースは、タイムボックスで管理を行います。タイムボックスとは、固定の時間、固定の人数という箱をイメージしてください。この箱の中にやること（ユーザーストーリー）を詰め込み、小さくリリースを繰り返していきます。何を入れるべきかを考えるために必要なのが優先順位です。

プロジェクト期間の比較

プロジェクトの期間を比較します。アジャイル開発の場合は、プロジェクトじゃない場合もあるので、開発サイクルを比較します。

これまでになんども解説してきましたが、従来型は大きな開発を扱うのが得意なので、中長期的なプロジェクトが多くなります。従来型では、中途半端なプロダクトやシステムは顧客が望まないので、プロジェクトの中で完成を目指します。

アジャイル開発は、短くて1週間、長くて1ヶ月ぐらいの短期的な開発を繰り返していきます。小さく作って、大きく伸ばしていく方法です。この特性を生かした開発は、プロダクトを作りながら考え調整していくスタートアップでとても有効です。

品質の比較

品質について比較してみましょう。品質についても大きく考え方が変わってきます。

従来型の場合、テスト工程（フェーズ）が存在する場合が多いでしょう。つまり、それぞれの工程で品質を高める・維持するのも重要ですが、テスト工程の中で可能な限り品質を高めていきます。よって、テスト工程はとても重要です。

そして、基本的に、プロジェクトが終了するまでに品質を高めます。リリース後や納品後の品質向上は基本保証せず、別契約に移るケースが多いでしょう。

さて、ここまでに何度も出てきていますが、あらためて考えていただきたいことがあります。ここで語られている品質とは何でしょうか？

従来型の場合、プロジェクトの内容や条件が契約で決まっているケースが多いので「契約通りのものが作られたか」が品質と言えます。従来型では、作るものがだいたい決まっているので、ただしいプロセスで作れば、正しいものが出来上がるはず・・・という考え方が中心にあります。

この従来型の品質に対する考え方は、検証（Velificaiton)が中心になっていると言えます。あらかじめ作るものが決まっており、正解が存在するため、できあがった後に答え合わせできます。これがここでいう検証です。

アジャイル開発では小さな機能をどんどん開発し、リリースしていくので、小さい単位で品質を維持していきます。アジャイル開発では、リリースを繰り返すので、リリース後も品質を高められます。アジャイル開発では開発が続く限り、継続的にテストを行っていきます。

明確なテスト工程を定めると小さなウォーターフォールになるため、小さな機能をひとつひとつ作っていく形を取ります。手戻りを避けたいので、開発サイクルの後半にまとめてテスト工程を作るのを避けていこうとします。

アジャイル開発では、何が正解かわからないので、リリースごとに得られるフィードバックからヒントを学び、プロダクトをどんどん改善し、正解に近づけていこうとします。成果がでてやっと品質が高いと言えます。アジャイル開発における品質をまとめると、妥当性（Validation)が中心になっているのがわかります。

契約の比較

契約の比較をしてみましょう。

従来型の場合、やりたいことが決まっている顧客が、開発の専門組織に開発を発注するパターンが多いと思います。顧客は開発を発注し、開発側が受注する受発注の関係性になります。開発側の企業は成果物の納品まで契約に従って開発を進めます。

受発注型の契約は、納品時に「完成した」「してない」や「欲しい物じゃない」などでもめるケースが多いため、トラブルを防ぐための契約が重要です。よって、請負契約が中心です。

アジャイル開発を取り入れる企業をみると、自前で開発組織を持っているケースが多いので、社員の雇用契約以外の契約がない場合が多いです。自社で開発できるので特別な契約は必要なく、従業員が勤務時間に開発するだけです。

もし、自社の開発者が少ない場合は、外部に頼むケースもあるでしょう。しかし、何を作るかがはっきりしないアジャイル開発の場合は、完成の義務を追わない準委任契約が適しています。「ビジネスが必ず成功する機能を作ってください」と言われても約束できないので、完成の義務を負わない形にならざるをえません。

予算の比較

従来型の開発であれば、やることがすべて決まっている前提なので、プロジェクトを見積もるときに、かかる費用を綿密に計算できます。これらの費用をベースにして、年間計画を立てている企業も多いと思います。

アジャイル開発における予算管理は、よく質問される内容です。

基本的に予算の考え方は、従来型でもアジャイル開発でもかわりません。アジャイル型だと、アジャイルチームの人件費のみを定期的に計算する形が多いように思います。

アジャイル開発だと、プロダクトが続く限り開発が続くため、どこをひとくぎりとして予算を計算するか悩ましいところだと思います。たいていの企業は四半期、半期あたりで予算を立てるケースが多いように感じます。

ただ、このやりかただと、予算が固定されるので、変化に強いはずであるアジャイル開発でも柔軟な対応ができなくなってしまいます。

たとえば、プロダクトがヒットして急に人材を増やしたいときや、アクセスが集中したのでサーバを一気に増やしたい場合、予算が半年間固定されてしまうと柔軟に追加予算を使えません。対応策としては、予算を1年から3年先までの年間計画や人員計画に合わせてざっくり確保しておきます。また、予備的な追加予算も確保しておいて、緊急時に柔軟に追加投資してもいいでしょう。