とりあえずウォーターフォールモデルをぶった切る

はじめに

先日職場の先輩とプロジェクトマネジメントについて議論してた内容の一部を抜粋。

先輩「生産性は今のところ科学的な方式で出せる方法がないってことです。
　　　そうすると、それで管理しようとすることに無理が出てきてしまうと。」

私「定量的な基準がないため、人を管理することは難しい。
　　　そもそも管理型マネジメントが破綻している、ということですかね。」

先輩「そうです。幻想です。ペガサスファンタジーです。」

…これはラストのところだっんだが、まぁここまでバッサリ言ってもらうと、逆にスカッとしたわw （余談だが、このネタが分かる人ってだんだん減ってきてるんじゃろうなぁ…） 前職でそのウォーターフォールモデルでずっと仕事をしてきて、いろいろ不満やら疑問やらあり、 それでも耐えてきたのだが(笑)

これ言われてから、改めてウォーターフォールモデルについて考えてみたが、 やっぱりこのやり方はクソ。もう本当にクソだと思ったわ。よっぽどのキセキ がないとうまくいくとは到底思えない。 まだウォーターフォールモデルでプロジェクトを進めているチームや、 これからPMになろうとしている人に警鐘を鳴らす意味でも、どうダメなのかをまとめる。

ちょっと余談

このテーマについては既にかなり多くの記事が投稿されていて、その中でよーく目にするとても有名な本「人月の神話」。 この本を読んでいなくても銀の弾などないという名言を目にしたことがある人も多いと思う。この本でもウォーターフォールモデルが痛烈に非難されているらしい。

しかし、自分はこの本を読んだことがないけん、個人的な経験から書くのでご了承。

ウォーターフォールモデルの問題

まぁこれも似たり寄ったりな内容だと思うが、やっぱり書かずにはおられんわ。 ものごっつざっくり図にすると、ウォーターフォールモデルはこんな感じになる。

要は、予定通り行くはずがないと言いたい。人間と仕事しているのだから変化するのが当然で、予定はあくまで予定。 実際に動き出すと予定は崩れるもの。もう少し具体的に喋りたいので一個ずついくべ。

・そもそも要件定義は全てではない

ウォーターフォールの前提を覆すかもしれないが、実際の現場ではこれが当たり前。 まず最初に、与えられたリソースの範囲内でプロジェクトでやることをお客さんと一緒に全て洗い出すことを要件定義（※要求定義ともいうが、私はこれで統一している）、 それをドキュメントに起したものを要件定義書と言うが、ハッキリ言ってこれに書かれたものは絶対に全てではない。 ほぼ必ず、後から漏れていたものが加わる。

完璧に全てを把握している、また必要なものが全て分かっている人間などいない。 いたとしたら、その人はまず確実に会社の上の人間か、自分を過信しているだけだろう。 上から下まで運用の全てを把握し、その全ての問題点・改善点を把握できるとは到底思えない。 ということで、PMはそういうことを予想して見積もりをする必要があるのだが、それは完全に予測でしかないので、 とても不安定だ。

・一度決めた仕様は変わる

これもほぼ確実に発生する。プロジェクトが進み、入念に考え始めると、どんどん仕様に漏れがあったり、 不都合が生じていることが発覚する。要件定義の段階では、しっかり考えられていなかった運用フロー、 色んなヒューマンエラーやシステムのエラー、それに対する対応策（例：ログの取り方）など、考えが煮詰まっていないことが明らかになっていき、 後から修正せざるを得ないのだ。

それは当然のこと。人間、初めから全てを考えられるとは思えない。だからこそ、時間をとってしっかり考える必要があるのだが、 最近は要求される開発スピードも速くなり、あまり時間をかけずに突っ走る傾向にある。それに付随して品質も下がるので、 大抵がデスマーチを走るか、リリース後に燃える。

・PMの見積もりは当たらない

これは上記2つのことの副産物だが、まぁPMの当初の見つもった工数から遅れる事が多い。 そりゃ追加機能開発や仕様変更が起こったのに、ケツが変わらにゃ稼働を上げるしかないけん、

エンジニアは疲弊
↓
生産性が下がる
↓
開発が遅れる

ことになる。
※ここでいう生産性は曖昧に使ってます。

・人を管理（マネジメント）することは現状できない

こういうと少し御幣を招くかもしれないが、そもそも人を管理すると言っても、人の生産性は定量的に判断することができない（定量的なモノサシがない）けん、 人を管理することはできないし、本来はする必要がない。

管理すべきはプロジェクトの進捗である。たいてい進捗が悪いのは、色んなしがらみ（上司のやり方が悪いなど）により、手を動かす側がベストを尽くせないことだと思う。 進捗が悪ければ、その原因とどうするかアクションを考えないといけない。それは管理する側だけでなく、手を動かす側も同様。 どうすればベストを尽くせるか、どうすれば快適に働けるか、そのために必要なツールは何か、など。

・ほぼ完成するまでお客さんはモノが見えない

ある意味でこれが最大の問題じゃの。いくら要件定義して、認識を合わせても、実際にできたものが違うとか微妙にズレとる なんてこともある、というか基本的にズレるじゃろう。しかし、8割がた完成したところで「これは頼んだものと違う！」と言われたら、 修正する工数が大きいし、モチベーションも下がる。さらに、再度テストし直す必要があるため、テストの工数が倍かかる。

システムの開発だけでなく、デザインでも同様のことが言えるため、なおさらこのやり方は爆弾だなと。

じゃあどうすりゃええ？

個人的な一つの回答としては、やはりアジャイルっぽい開発かなと。完全にリソースがあり、環境・条件が整っているのであれば、 Scrum開発が理想。ただ、これは現実では大企業でない限り難しいかと。理由は単純で、条件が揃わないから。
例えば、

• ちゃんとスクラムマスターやれる人はおる？
• お客さんが納得する？
• 開発メンバーでチーム組める？
• 各種バックログや開発機能などの成果物に対するフィードバックする人はいる？

など、これらの条件を満たす環境じゃないと、Scrum開発はできない。だから、アジャイルっぽい開発が答え。 つまり、①スプリントでやることを決める。②バックログに残す。③スプリントを走りそこでできた成果物をお客さんに見せる。④フィードバックをもらった後、 何か追加・変更があればそれも含めて次のスプリントでやることを決める。⑤また走る。これの繰り返し。最後にプロダクトバックログを残す。

ここで大事なのは、リリース時に必要不可欠なものをしっかり決めること。手を動かすものとお客さんと交渉する人は上下関係でなく同じチームの一員だけん、 手を動かす側にも一定の権限を与えること。こうすれば、都度軌道修正できるので、本当に走っても大丈夫か、間に合うのかなど話し会えるし、 現状どこまで来ているかお客さんもある程度見えるので、相談がしやすくなる。また、チームも快適に働けるように動けるし、しがらみを取り外せるので進捗は良くなるだろう。

この進め方の別の利点は、追加開発するとしてもこの進め方の続きなのですぐに入れること。また、バックログが残っているので、 何が必要とかどういう経緯でその機能が必要になったのかが分かりやすい。

終わりに

あーすっきりしたw 前職では完全にウォーターフォールモデルだったけん働きづらいし、 PMによってはとにかく言いなりにならざるを得なく無償で対応することもしょっちゅうだった。 せめてウォーターフォールモデルでやり通すなら、上に立つものはプロジェクトを着地させるためにしっかり考えて欲しい。 考え続けて欲しい。チーム内だから命令する、じゃあマネジメントになってないのだよ。

もしウォーターフォールモデルをまだやっているチーム、やろうとしているチームの人、 今すぐやめよう。