アジャイル開発の「考え方」と「やり方」を学べ

最近、「ウォーターフォール開発が危ない」と思うようになりました。アジャイル開発は従来の開発の延長線上にある（アジャイル開発におけるプロジェクト成功の定義 - アート・オブ・アジャイル デベロップメント -）とは思うものの、様々なほころびがある（[#TiDD] 従来法の限界とアジャイルの利点、そしてチケット駆動開発）ので、若い元気な人がアジャイル開発を目指す反面、社会動向と相まって既存企業は管理強化に向かい、従来法の大切な「考え方」が失われつつあるように思います。

従来法の問題点はトップダウンの管理（コマンドコントロール）によって、すべてのプロジェクトがうまくいくと思う人が少なからずいた事でしょう。しかし、ソフトウェア開発は人間が行うものです。人間がどのような「考え方」を持ち、どのように「やり方」を実践するか、によってプロジェクトの結果は大きく変わります。

アジャイル開発が革命的だったのは、それまで基本的な管理を学んださらにその先にあると思われていた「考え方」や「やり方」にアジャイル宣言で光を当てた事だと思います。

この「考え方」や「やり方」を理解して実践すれば、どのような状況でも一定の効果が得られるでしょう。また、トップダウンにアジャイル開発が導入された場合でも教条主義に陥らず、形骸化を防ぐ事ができるかもしれません。

「考え方」と「やり方」のふりかえり

ソフトウェア開発は構造化やプロダクトの設計法という「考え方」や「やり方」が中心でした。やがて生じている事象の説明に統計学が用いられるようになり、プロダクトを可視化する目的でメトリクスが使われるようになりました。

その後、プロダクトだけでなく、より「やり方」を示すプロセスメトリクスが注目されました。しかし、それは工程ごとのレビュー指摘件数など管理に必要なやり方で、リスクの低減に必要なプロトタイピングの検討有無など、より良い開発の「考え方」や「やり方」を示すものではありませんでした。

そのような中で、大切な「考え方」はトップダウンの管理の下、チームで育まれました。リーダーに求められる大切な事 - 100人のプロが選んだソフトウェア開発の名著 - に書いた他にも色々あり、それらはアジャイル開発と共通するものです。

しかし、プロセス管理は徐々に重くなる一方で、チームには利益の確保が求められ、そのゴールの実現で力を使い果たし、大切な考え方を見失いがちになってしまったようです。

大切な考え方

従来法とアジャイル開発のやり方から大切な「考え方」を説明します。

従来法	アジャイル	考え方
マイルストーン	イテレーション リズム	ゴールを近くに設定する事で、進捗が明確になり、チームが一丸になれま す。リリースのマイルストーンを定期的に設定すると、習熟度が向上します。
プロトタイピング	実装優先 スパイク	ユーザインタフェースなど確認に実物が必要な場合はプロトタイプを開発 します。実使用が可能な開発と、スパイクと呼ばれる性能などの技術要件の確認は誤解され易いので明確に区別します。
記録を残す	トラッカー	記録を残す事でエビデンス（証拠）になるだけでなく、プロジェクトの生 産性（ベロシティやスループット）を知る事ができるので、継続的に改善する事ができるようになります。
フロントローディング 手戻りを無くす	テスト駆動開発、ペアプロ ムダの排除	障害は後から取り除くのではなく、作り込まないようにします。決定でき ない事は、無理に決めて手戻りしないようにします。
状況の認識と共有 作業一覧（WBS）・線表	タスクボード、カンバン バックログ、バーンダウンチャート	プロジェクトの状況を常に認識し、共有します。状況を共有することで、 今後の見込みを知るだけでなく、お互いに助け合う事ができます。
Win-Winの関係	価値の提供 同じ方向を向く	顧客と開発者が目先の利益で対立するのではなく、長期的な視点を持ちます。リファクタリングを実践しつつ変化を受け入れるなど、価値の あるプロダクトを提供する事が顧客の利益になり、長期的には開発者の利益になります。
最大の能力を発揮させる	サーバントリーダーシップ プロジェクトファシリテーション	やらされ感をなくし、チームのやる気を引き出します。開発の障壁を取り 除き、（命令ではなく）チームを導く事で、効率的な開発を実施します。

まとめ

このように並べると、アジャイル開発が従来法の「考え方」や「やり方」を形式化し、シンプルなプロセスをパッケージングしている事がわかります。

あなたのポジションはどこでしょう。もし、従来法の開発をしているならアジャイル開発の価値観を学べば、管理以外の大切なことが理解でき、より良い開発ができるでしょう。もし、すでにアジャイル開発をしているなら、アジャイル開発の価値観を見直す事で形骸化を防ぐ事ができるかもしれません。

これは、チケット駆動開発に置いても同じです。[#TiDD] チケット駆動開発をプロジェクト管理の視点だけで考えてはいけないに書いたように自律的なチームを構築し、ソフトウェア開発の現場力を向上させることが大切です。

プロジェクトは言われた通りにすればうまくいくものではありません。常に状況を把握して、どうすべきかをよく考えないとうまくいきません。そこで、何をやったかを管理するのではなく、どのように考えて何をすべきかをきちんと理解する必要があると思います。

おまけ：違いについて

なお、アジャイル開発は一定のサービスが実現可能なら、スコープを調整する事ができますので、残業を前提としない事も可能な場合があります。

これに対して、 従来法はスコープを固定して、コストと納期で調整する方法です。仕様が膨らむとみんなで頑張るか納期をのばすしかありません。もし、リリース日が決まっているなら、頑張るか泣きつくしかありません。

（もちろん、上流を準委任にすると共に必要なプロトタイピングを実践して、あらかじめ予想できるようにできれば、仕様削減や段階的なリリースも可能です）

これは、従来法とアジャイル開発の本質的な違いです。最も学ぶべきところは、IT技術はビジネスの要（かなめ）であり、ユーザがリスクを取る事でより大きな利益が得られること、開発者はそれに開発を通じて協力する。という考え方なのかもしれません。