システム開発手法を語る暇があったらコードを書け
ウォーターフォールとアジャイルのスクラム。しばしば、対立する象徴として引き合いに出され、新興勢力とはいってもすでに１０年は経っているがアジャイル勢力にdisられる。実際に、とある場で一方的にdisする光景を見たときには微妙な気持ちになったわけです。だって、何か自分の知らないことを学びに来たのにidsるのがはけ口のような雰囲気だったんですから。
これまでのブログを読んでもらえるなら、ワタシのポジションは
「プロジェクトが成功するやり方だけを採用する」
なのです。プロジェクトマネージャでもマネージャでも成功するやり方を採用するし、そうしたやり方があることを助言するんです。それがそのプロジェクトをやる理由なのですから。
じゃあ、そのdisられるウォーターフォールがどれだけアジャイルのスクラムが持っている主張するポテンシャルを持っていないかを見てみましょう。
変化を受け入れるタイミング
アジャイルの特徴は変化を受け入れることです。では、ウォーターフォールには変化は受けれないのでしょうか。プロジェクトマネジメント管理手法のPMBOKには、変更管理を設けるように記載されているし、実際、今時のプロジェクトで仕様変更を想定してプロシージャを規定していないプロジェクトってあるんでしょうか。
プロシージャさえあれば、ウォーターフォールだってどのタイミングでも変更を受けれられるわけです。まずは、受け付ける。実際にそのあとの影響範囲や仕様変更に伴う見積もりをし、変更要件に対する効果と仕様変更で掛けるコストを天秤にかけてスポンサが判断すると。
変化を受け入れるについてはイーブンです。
ロールが多く構造が複雑
アジャイルのスクラムは、７人±２人が理想の人数と書いてあった本があった記憶があります。そうかな、とも思うし、５人±２人でもいいのでは、とも思うわけです。
では、ウォーターフォールではどうでしょう。そんなのプロジェクトの規模によりますよね。大きなプロジェクト、１００人とか３００人とかになればそうでしょう。でも昨今は中〜小規模のプロジェクトが多いです。そんなプロジェクト、特に小規模なプロジェクトなら７人±２人だったり、それより少なかったりします。
そうすると人数的にほぼ同等になるケースが少なくないと言えるわけです。これはどう意味があるか、というと、「人数が少なければ役割は自然と少なくなる」ということです。人数が少ないのですから多くのロールは置けないし、少人数のチームであるからこそ複雑にしようにもできないわけです。
アジャイルのスクラムにしろ、ウォーターフォールにしろ、少人数のチームでは、プロジェクトの継続性のリスク、例えばトラックナンバーの問題の解決方法と同じようにマルチスキルを要求するのは同じです。
リーン開発の現場 カンバンによる大規模プロジェクトの運営で取り扱われているように、アジャイルでも大規模なプロジェクトではスクラムのチームを横並びさせるほかなく、そうするとスクラムマスターのリーダ会を上にかぶせてチームの横串を通す必要があります。こうしたことからも、人員的な規模が大きくなれば、結果的には同じような構造をプロジェクトとしての組織構造を折らなければ立ち行かなくなるということがわかります。
この観点についてもイーブンと思います。
コミュニケーションの複雑性
コミュニケーションが複雑になる要因は、コミュニケーションをとる必要がある人の数と役割です。人が多くなり、役割分担は多くなれば、当然、自分の担当する仕事を進めるための調整する先は増えるものです。逆に、人数に対して役割が増えなければ、役割を負う人にコンタクトが集中するのでボトルネックになるだけです。
マネージメントの難易度
プロジェクトマネジメントの管理手法の意味合いでのマネジメントもについてですが、結局、ウォーターフォールもスクラムもどちらも「システム開発手法」でしかありません。お客さまなり、開発主体の組織がどのようなプロジェクトマネジメントの管理を望んでいるか、によります。
マネージャ、プロジェクトオーナー、スポンサー、プロダクトオーナーの誰でもいいのですが、どういったマネジメントの観点で報告を期待しているかにより、プロジェクトの状態をダンプし、レポートとして情報のサイズとメトリクスが決定づけられるのです。
あとは、それを遂行する対象のプロジェクトの規模により、プロジェクトマネージャなりスクラムマスターが目が届く範囲であれば、規律やルールで十分だろうし、大規模で誰が何を開発しているのかチームごとのスクラムマスターでしかわからないのであれば、横断的な標準や規定類が最小限の範囲で必要になるでしょう、その標準や規定類には、人の手続きとしてのプロシージャも含まれます。
マネージメントの難易度についてもイーブンでしょう。
開発スピード
アジャイルのスクラムではリリースを頻繁に行い、お客さまが投下したコストに対する価値を早く届けることを大切にしています。では、ウォーターフォールは投下するコストを大切にしないのでしょうか。
もしそうだとしたら、なぜ、システム開発手法の手法が経営者の判断でスクラムに切り替わらないのか、という疑問を思ってしまいます。システム開発の投資を決定するのは経営者なんですから。
違う面から見てみましょう。開発スピード、つまり、リリースまでの期間はシステム開発における、人物金が揃えば長くても短くても机上では可能です。現実問題としてできないとするならば、人物金をリソースとして使ってシステム開発をする際のプロシージャが適用するプロジェクトの特性に適合しているかどうか、ということです。
３人のメンバのシステム開発に重厚な金融システム向けのプロジェクトマネジメント管理手法では回らないことは誰にでも想像がつきます。これは、プロジェクトマネジメント管理手法は、プロジェクトの特性により人金物、言い換えるとQCDに影響するということを示しています。
つまり、プロジェクトの特性として納期を優先せよというならそれ以外のことについては全て考慮から外すことが求められるということです。この考え方は、スクラム固有の物ではありません。現実に数ヶ月のシステム開発なんていくらでもあるのですから。
これについてもイーブンでいいのではないかと思うのです。
システム開発手法を語る暇があるならコードを書け
結局、システム開発手法は単なるシステムの実現手段でしかなく、プロジェクトの特性を考慮してプロジェクトマネジメント管理手法やシステム開発手法を選択し、特性が要求するプロシージャでプロジェクトを回せる業務を設計できるか、ということではないのでしょうか。
つまり、ウォーターフォールとスクラムを対峙させ煽ってるのは自分たちのシステム開発に適用する業務設計ができないことを隠蔽しているだけなのではないか、と勘ぐってしまうのです。だから、ここ１−２年は1disっているより、スクラムして成果を出せという基調になっているのではないかと思うのです。
