プログラマの思索

「カイゼンジャーニー」を一気に読んだ後で、もう一度、アジャイル開発とは何なのか、現時点で考えを整理しておく。
自分の中の暗黙知を整理するのにとても役立ったので、下記の記事をリンクしておく。
特に主張なし。

【１】アジャイル開発では「個人のパフォーマンスで駆動」されるので、チームワークや心理的安全を重視する。
一方、WF型開発では、プロジェクトの成功を「組織の力で担保」する。

となると、先日の冬季オリンピックで、日本女子がパシュートで金メダルを取った事例を振り返ると、日本人は組織の力を重視する方が好きなのか？
ならば、個人のパフォーマンスで駆動する開発プロセスを志向するアジャイル開発は、日本人の文化とは本来合わないものなのか？

アジャイルとウォーターフォールは文化や価値観のレベルで異なるという話 - たなかこういちの開発ノート

(引用開始)
このプロジェクトでは“本物”の「スクラム」を実施していました。アジャイル手法をほんとうに実践している現場の経験は初めてでした。
当初は本当に戸惑いました。
自分が“普通の”エンタープライズ・システム開発でPMを務めるようなときは、Unified Processの「アーキテクチャー・セントリック」や「リスク・ドリブン」を意識しつつ、要件たる機能セットの全体を明らかにして、スコープ管理を重視したスタイルで進めます。
今回のプロジェクトでは、スクラムとして「バックログ」としてタスクが列挙されはしていますが、システムのアーキテクチャーや機能スコープの管理がされているようには思えず、「これで破綻無くゴールできるのか？」と大いに不安を感じました。
（引用終了）

(引用開始)
そして、得られた一定の理解は次のようなものです。
「アジャイル」の本質は、「イテレーティブに進める」などというところには無い。
本質は「メンバー個々が個々としてプロジェクトあるいはプロダクトにコミットし、メンバー個々が如何にすればプロジェクトの成功あるいはプロダクトの完成に貢献できるか、自ら強いオーナーシップをもって考える、その点にいわば賭けている」、という点にある。

対して、ウォーターフォールの本質は、「プロジェクトの成功あるいはプロダクトの完成を、組織として仕組みとして担保しよう」と考えている点にあると言える。
よく"Collaboration and Teamwork" vs. "Command and Control"などのフレーズで対比されます。「個人の力」を信じるか、「組織の力」でこその安心か。。
このような“文化的背景の違い”からみれば、Unified Processもほとんどウォーターフォールの一変種でしかありません。

「イテレーティブ」という点では、アジャイル系方法論もUnified Processも類似に見えます。
しかし、個人のパフォーマンスで駆動しようとするか、組織の仕組みで駆動しようとするか、その価値の置き方は全く異なります。
（引用終了）

【１－２】アジャイルにおける「計画」とは優先順位を見極めること。
一方、WF型開発の「計画」は、QCDの決定事項であり、予実管理すべきもの。

(引用開始)
また、アジャイルとウォーターフォールでは「計画」に対する考え方が全く異なると感じました。
ウォーターフォールでは、スケジュールと機能スコープが示され、それに対して必要リソース（お金や人）を見積もり、Work Breakdown Structureを作成したりします。
投入可能リソースによって、スケジュールやスコープを調整するものの、それで決定された「計画」は、基本的に遵守すべき事項となり、その「計画」を達成することを目的にしてプロジェクトは進みます。
「計画」通りに進捗しない事象が生じた場合は、リソース配分を調整し、WBSを組み替え、新たなクリティカル・パスを構築します。

アジャイル（※ここでは主にスクラムでの考え方に基づきます）では、最初にリソース（主に人）を制約として捉えます。まずメンバーが具体的に決定されます。
その具体的なリソース（メンバー）は一定期間にどれだけの開発パフォーマンスを出せるのか実測します。（スクラム用語で「ベロシティ」と言います。）
それにより、このチームが一定期間に達成できそうな開発量の見通しを立てることができます。そして開発タスクを優先順位をつけて順次消化していきます。
目標への見通しはあるものの、そこには「いつまでに何を」というかたちで管理され遵守されるべきという意味での「計画」はありません。
アジャイルにおける「計画」とは優先順位を見極めることです。
（引用終了）

【２】アジャイル開発では「全部つくらない」を前提とする。
一方、WF型開発では、「全部つくること」を前提とするので、請負契約と相性が良い。
だから、日本のIT業界では、発注側が委託ベンダーにリスクを一方的に背負わせる方向に向くために、請負契約から離れられない。

アジャイル開発の本質 ? アジャイルとウォーターフォールの違いとは | Social Change!

(引用開始)
アジャイルとウォーターフォールの本質的な違いは、プラクティスを実践するかどうかではなく、手順として繰り返し型にするかどうかではなく、「全部つくらない」を前提とするか「全部つくること」を前提とするかの違いだと考えています。昔あったスパイラルとかRUPとかありましたが、それも「全部つくること」を前提にしていたように思います。だからうまくいかなかった。ただ繰り返しても駄目なんです。

私がシステムインテグレーターで働いていた頃に、プロジェクトをアジャイルに進めるために多くの人に協力や説得をしてまわったことがあります。そこで出た意見が以下のようなものでした。

「アジャイルとは、つまり、これまでのプロジェクトでやってきたようなベストプラクティスを取り入れるということかね？」
「ウォーターフォールでも、ふりかえりとかテスト駆動開発とかを取り入れてやってきたんだけど、それとは何が違うんだ？」

一括請負でビジネスをしているシステムインテグレーターにとっては、システムを完成させることがゴールであり、全部つくることでお客さまに検収してもらえて報酬が支払われます。つまり「全部作ること」こそが仕事な訳です。そんな中で「全部作らないこと」をしましょう、と言っても伝わりません。

そこでアジャイルの良さを伝えるために出来ることは「変化に対応する」とか「人を大事にする」とか「顧客満足度を向上」とか「速く・安く」とか、そういったボンヤリした言葉で伝えるしかなくなる訳です。しかし、それらはどれも絶対にアジャイルでなければいけないものではない訳です。これまでのやり方だってやろうと思えば出来るものです。

これまでのウォーターフォールのやり方から、決定的に違うことを言うのであれば「当初に想定した機能は"全部"つくらない」ということになります。しかし、それは一括請負として「決まった機能を"全部"つくること」でビジネスをしている会社では言うことは出来ませんね。
（引用終了）

【３】Agile 2016の基調講演: モダンアジャイル

(引用開始)
モダンアジャイルの4つの指導理念は以下である。

人々を尊重する
安全な状態を前提とする
素早い実験と学習
価値を継続的に届ける

Joshua氏は、改めて古いアジャイル原則を見ると、古い大きなラップトップを誰かが持っているようで良い印象を持たないだろうという意見を持っている。そして彼はスクラムに対して以下のように言及した。

少し年をとり、素晴らしい寿命を迎え、歴史の一部と認識されて立派な引退をするのに相応しい。
（引用終了）