これをウォーターフォール型のシステム開発手法と呼んでいいのだろうか

自分のプロジェクトでは次のプロジェクトのポリシーを伝え、価値観を共有できるメンバと推進する。価値観を共有し定着するまで何度も、それこそ毎日伝える。価値観を伝えるだけではなく、エンジニアの作業プロセスに組み込み、その価値観に自然となじめる環境で一緒に働く。価値観を理解して行動するメンバにはメンバを守ると伝え、メンバ自身のエゴに基づく行動をした場合は、一切擁護しないと伝える(もちろん、程度もあるし、伝え方は相手を尊敬した上で)。

作業プロセスや成果物を変えようとするとき、その変更で価値を失わないならいくらでも変えていいと宣言する。プロジェクトマネージャの知っているやり方は、知っている実践知から作ったものだし、第一、成果物を手に入れる作業プロセスやチームのルールはチームメンバであるエンジニアのものだ。目的である成果物の価値が損なわれないなら、いくら変えてもらってもいい。

成果の価値は出来上がればすぐにでも届けたい。もちろん、実現可能なスケジュールで、自分たちのチームで合意した品質を満たしていなければならない。

成果の価値の変更はあって当たり前だ。なぜなら、それは誰も見たことがないものをチームで作ろうとしているのだから。見たことがないから変わることは当然だし、それはそれを必要とする顧客も、我々チームも同じだ。ただ、価値に向いているシステム開発手法をとると手法の制限によりどこまで変えられるかと言う制約がつく。予め想定がつくなら、それに見合ったシステム開発手法を選ぶのもエンジニアの成果に対する価値観の現れだと考える。

時間を長く取ってしまうとリリースするまで考えることができそうだが、実は別の割り込みが入ってしまうためいいことはない。だから区切りを設けて成果を形作っていく。成果をケーキの断面を縦で届けるか、横で届けるかは、成果の性質による。ただ、横にすると全容を理解するまでに時間がかかってしまう。だから、アウトラインからみせ、動くものを見てもらう。これは顧客にそれで業務が成り立つかを判断する材料にしてもらう意味合いを持つが、チームでの実現性を検証する意味合いもある。

自分のプロジェクトでは、業務を取り扱うから業務を教えてもらう。知っている業務の知見を絵に描き、それをどうしたいかを考えてもらう。この方法の良いところは、成果の作り方の一番早い方法を知っているエンジニアが早く成果を届けられること。顧客は雛形の業務で何をするかを決めてもらえばいい。まだやったことがない業務なら、学びながら組織の情報を集めて割り当てれば、技術的な方法を考え示すことができる。こうした場は濃厚に持つ。それこそ本業に影響するくらい割いてもらうがこれは顧客の明日を疑似体験してもらっている。だから、真剣に作り上げる。でも、やったことのない業務だから、多分こうだろう、と言う前提でしかない。それを昇華させるために、組織内に向けたアクションを取ってもらうことで使える業務になるかを判別してもらう。これをプロジェクトの最初の工程からやる。

こうした活動は、顧客を含めた一つのチームとして一体感を作っていく。もちろん、対面で。

顧客の上司への報告や属する組織の都合で色々と管理のためのレポートも作るが、それはそれを必要とする人がいるからだ。

自分たちのチームはこれをウォーターフォールと呼ばれるシステム開発手法でやってきた。

ところで、これをウォーターフォール型のシステム開発手法と呼んでいいのだろうか。