概要
いまや開発スタイルのトレンドはウォーターフォールではなく、アジャイルとなっておりますが、単にアジャイルを名乗るだけではなく、スピードを優先した上で「仕様変更しやすい体制」、「形骸的な無駄なドキュメントを作らない」、「テスト重視し、動くソフトウェアを保証」だけでなく、アジャイルの本質を見極め、組織にあった仕組みづくりが必要になります。
下記リンクはアジャイルの一次ドキュメントといえる「アジャイルソフトウェア開発宣言」のリンクです。
http://agilemanifesto.org/iso/ja/principles.html
アジャイルでは、どういったルールや仕組みが自分の組織にマッチするか試行錯誤する必要がありますが、素敵なプロジェクトにするために必要なテクニック10を紹介していきます。
短期マイルストーンを設定しない
アジャイル開発では、週次ひいては日次で顧客の要望により、仕様変更が発生します。
そのため週次や月次のような短期のマイルストーンは設定せず、大まかな開発期間、結合テスト期間、総合テスト期間のみで十分です。
一度開発終了した機能でも仕様変更が発生し、新しい仕様にシステムが対応できず次フェーズに移れない場合は、全て開発者の責任です。
技術調査でOKした実装案に条件をつけて、仕様策定後一気に難易度を上げる
アジャイル開発では、仕様変更の発生はありきでスケジューリングされているため、一度技術調査においてOKした機能にビジネス担当が技術調査において検討されなかった微細な条件を追加しても問題ありません。
開発担当としては困難なチャレンジを経験できモチベーションが高まるとともに、追加条件によって実現困難だとしても先にOK出した開発の責任であるため、優秀なビジネス担当に変わって何かしらの対案を出す必要が開発にはあります。
引き継ぎをしない
アジャイル開発では、スピード重視のため引き継ぎをしている時間は無駄なリードタイムです。もしプロジェクトが落ち着き開発担当が少なくなった状態でも残っている開発メンバーはすばやく前任者が仕事を理解し、必要な作業と技術的に説明をビジネス担当へ行うべきです。（MTGが必要なのでビジネス側のみであり、開発担当はMTG不要。）
振り返りをしない
アジャイル開発では、スピード重視のためフェーズ終了後の振り返り作業も無駄なリードタイムです。開発で溜まった知見はほとんど次のプロジェクトは持ち越せるものはありませんし、ビジネス担当、開発担当各々、「今回こうすべきだったから次回からはそうしたい」みたいなアイデアは一円にもなりませんし、「最初からなんでそうしてなかったの」と追求されてしまいます。（PDCAは各自で回そう。）
MTGの内容を共有しない。
アジャイル開発では、開発着手段階で仕様未決定の機能が多くあり、仕様決定次第、確定した仕様が連携される形ですが、仕様を決定するプロセスで発生したMTGについての内容は、開発担当としては不要であるため、共有する必要はありません。
単に決定した仕様や変更内容を伝えるべきです。（イソップ物語の3人のレンガ職人ではありませんが、「歴史に残る偉大な教会を作る」より「レンガを積んでいる」ほうが、作業のバックグラウンドが不明瞭である分、作業内容が明確です。）
エンジニアを大事にしない
アジャイル開発では、クライアントと日々仕様調整するビジネスメンバが主役です。ビジネス担当はクライアントとラポールを築いており、クライアントと対等の関係であるため、クライアント＝ビジネス担当＞開発担当であるべきです。
もし短絡的で、横柄で、品性のないビジネス担当だとしても、ビジネス担当のミス・考慮漏れをあれこれ指摘して困らせるようではいけません。（あくまでビジネス担当が主役のため、納得が行かない熟練開発メンバは離任させ、無垢な新人へ担当替えすべき）
問題解決より、責任追求を重視
アジャイル開発では、短納期であるためケアレスなミスにより重大の障害を発生させることは少なくありません。
その時に発生した問題をいかに解決し、どのように再発防止をするか考えるのではなく、ビジネス側は原因を説明する必要があるため、「誰が」、「いつ」、「何をして」問題が発生したかを一番に考える必要があります。（そのとき離任もしくは退社したメンバを槍玉に挙げるとみんな幸せになるのは言うまでもありません。※）
遅くまで仕事をする
アジャイル開発では、変更が日々発生しますが、今日どこまでやっておきたいかというビジネス担当（＝クライアント）目安はあります。そのため、一日の作業を就業時間内に終えて帰社するのではなく、ビジネス担当（＝神様）が仕事をしている限り、就業時間後何があっても対応できるよう、開発担当は同じ時間まで残業する必要があります。決して帰社後に残っているメンバでは解決できない簡単な問題が発生しても攻めてはいけません。（早く仕事を終えて帰社後する人間はアジャイルには向いていません。）
ドキュメントを更新しない
アジャイル開発では、変更が日々発生しますが、正しい仕様をドキュメントへ反映させるのはビジネス担当にとって大きな負荷になります。そのためざっくりと開発担当へ決定事項を連携し、最終確認は後工程のテスト担当へ伝えるのが最も効率が良い方法です。ドキュメントは最終的に納品時に完成されていればOKのため、手戻りが発生するような作業をビジネス担当させてはいけません。ビジネス担当はMTGでは会話する準備に忙しいのです。（ビジネス担当は口、開発担当は手を動かすのが仕事）
労働環境を重視しない
アジャイル開発は、人の異動も激しく、その都度新しいメンバの労働環境を整えるのは無駄な作業です。ビジネス担当はMTGでほとんど自席にいませんし、開発担当もPCがおければ問題ありません。「自席が狭い（テーブルスペース幅１M以内）」「ディスプレイがない」「周りで世間話をずっとされる」が開発担当にとって集中できない労働環境の上位にあがりますが、アジャイルにとって問題ありません。開発者は音楽を聞いたり、リモート作業することもできるので、労働環境の整備に時間を使うべきではありません。（東京オリンピックのための国のテレワーク施策があるにもかかわらず、そもそもテレワークできない労働環境はその限りではない）