誰でもウォーターフォールを出来ると思ってたの。そんなのあるわけないじゃん…

アジャイル開発のスクラムの　アジャイル宣言　に書かれたことを実践するのはとてもハードルが高いと思っているということは以前に書いたことがあります。周りの知り合いでCSMなどの認定を受けていて実践しているの何人かに実践することの難易度について尋ねてもだいたい同じような答えが返ってくるのでそれほと間違ってはいないのでしょう、と思いたいところです。

もちろん、高いと思っているハードルに挑戦し、（理想的な）チームづくりに取り組むことは楽しいと思う方の人なので前述のハードルについては所謂、いい意味で、なのですけどね。

あれ、ウォーターフォール出来ないの…

とあるプロジェクトをプロジェクトマネージャに任せていたら、どうも様子がおかしい。プロジェクトのアーキテクトとランチをしていると愚痴っぽいことが出てくるようになってきたのでした。

色々と聞いていると専門がプロジェクトマネージャですからそんなのああすればい、こうすればいいと言いたくなりますし、なんでそんな当たり前な基本的な所作が出来ていないのか不思議でしかなかったのです。

とはいえ、最初からあれこれ口を出すのは育成や自律などの意味合いでよろしくないし当事者のプロジェクトマネージャだって面白くないでしょうし。だから経過を観察していたんですよね。そうしたら…

課題管理…

課題管理がまず杜撰だったことが判明したのです。

いや、課題管理で課題と識別して、優先順（優先順位ではない）を高レベルに設定いたいくつもの項目が期限を過ぎてもオープンしたままで全くクローズする気配もない状態でした。

課題管理の期限はそれを超えてしまうとスケジュールにインパクトを与え、余波でコストまで影響を受けるなどプロジェクトの進捗上の問題にクラスチェンジしてしまいます。

まあ、そういったケースが目白押しだったんですよ。

おかしいじゃないですか。課題管理をしているのに課題のコントロールをしていないんですから。

進捗管理…

課題管理がそんな状態での進捗というか作業計画がどうなっているかを想像できる人は手を挙げて考えを述べてください。

そうですよね、ひっちゃかめっちゃかになっているんですよ。課題は一向にクローズできない。でも、できることをやろうとするから迷惑なのはチームのメンバですね。次のタスクが予測できないと前段取りができませし、やっても割り込みになってしまいますからね。

で、おかしいと思ったんですよ。あれ、シニア層のベテランのエンジニアもいるし、って。

「アジャイル開発の本質とスケールアップ」では…

P76の欄外注記には、

アジャイルのリーダーであるジム・ハイスミスは次のように述べている。なぜ計画通りに進まなかったのか、自分たちの責任の所在を明らかにしようとしている多くの良いチームを見て、結論として、チームではなく計画が問題だったことを発見した。

引用　アジャイル開発の本質とスケールアップ　翔泳社

計画のボールドは原文のままですが、計画なのかと思うんですよ。そうじゃいないじゃないかって。

計画を目の敵にしなければならない対象なのか。でも、振り返ってみれば、担当したプロジェクトは全て計画どおりに終わっているのです。

ただ、他のプロジェクトマネージャが担当したプロジェクト（上述の例など）の中にはやはり失敗しかけたケースもあるのも事実です。

アジャイル開発の本質とスケールアップ　記載の計画が原因だったと発見したとあるようにそういう見方もできるので実は計画ではないのかもしれないと考えたのですが。

新しい発見…

ハイスミスがいう原因が計画にあるとするのは、上記の事例からいえば裏付けるエビデンスになります。一方、ワタシの実績例をエビデンスとするならば、ハイスミスがいう発見は誤りになるのではないでしょうか。

ここで上記の事例のプロジェクトマネジメントが途中でおかしくなってしまったことをプロジェクトを担当したプロジェクトマネージャの資質の問題にしてしまうのは間違いです。それではそのエンジニアを排除するか矯正することが対策となり、その人の属性問題になってしまい、他のプロジェクトにプラクティスを共有できなくなってしまいます。

そういった局所的な物の見方をするのはエンジニアに多いので常に外観から見る訓練をしておきたいところです。

さて、では外観から見たときに何が原因であったのか。

それは、ウォーターフォールというシステム開発手法自体を理解し、実践するための適合性があるのではないか、とうことです。

言い換えれば、ウォーターフォールは実践しようとするプロジェクトマネージャやエンジニアを選ぶ、ということです。

これって冒頭のアジャイル宣言と同じではないですか。

言い換えれば、誰でもウォーターフォールができると思ってはいけない、ということです。これって衝撃ですよね。でも、そうだと仮説を立てるとこれまで失敗とされてきたプロジェクトの原因を説明できるのではないか、と思うのです。

少し検証は必要かもしれませんが。