超主観で書き出す、長期ウォーターフォールの難しいところ

これまで受託開発で12年ばかし、3ヶ月スパン程度の短期プロジェクトと、半年〜数年の長期プロジェクトを経験してきた。いずれもウォーターフォール開発のプロセスで、一連のフェーズを経て進行する。僕自身はこの5-6年、ほぼ長いものにしか関わっていない。

スクラムやアジャイルを横目に見ながら、個人の実力は棚上げしながら（笑）、なんとなく難しいことを振り返っている。プロジェクトの都合に合っていたか？作ってる時間や運用してるなかで、変えがたい事は何か？得られた経験があったか？

反証、課題意識を持つ前に、今更感のあるあるべき論や思想、フレームワークを一度忘れて、自分なりに難しい部分に向き合ってみたい。

長期の取り組みが世に出る喜び

長いプロジェクトのなかで嬉しい瞬間といえば、リリースされる時。作ってきたモノが世の中に出て、ヒトが動いて、コトに変わる。それまでの苦労が報われて達成感を味わえる。これがないと続けていない。

ただ、長期で報われるのはリリース時だけだったか？というと、正直なところ終わった瞬間に苦労した記憶が薄まって思い出せなくなる。運用はこれからだし、止まっていいんだろうか？だけど、契約上はここまで。

気分的な話を抜きにして、疑問や難しさを感じる部分には課題が潜んでいると思う。

要求の増加とデメリット

ステークホルダーの数ほど、承認のプロセスを経るほど、要求は増加する。「とはいえ」「ただし」「かつ」といった言葉が増える。RPFにない要求が現れて、アレやコレや、右往左往する。いくつかの要件に適うモノができあがる。だけど反対に、いくつか以外の要求に適わないモノになる。良し悪しあるものの、デメリットのほうが多いように思う。

無用の長物になりやすい

成果の話。こじらせた片思いがストーカーになるような道理、自分の強い思惑だけで他者は動かない。「このユーザーはAをして、Bをして、Cをして、Dをして、EをしたらFができる」みたいに、思い描くシナリオやその中の条件が複雑化するほど、ユーザーの難易度が上がる。コンテンツの一回性、一義性が強まり、一方で、コンテンツの再利用性は下がる。無用の長物と化す。

扱いづらい

運用の話。独特な要求を考慮した仕組みであるほど、運用を考慮しなければしないほど、運用者の覚えることが増える。また、ユニークな仕様が多いほど、運用業務もメンテナンスも大変になる。コストは高まり、扱いづらいモノになる。

認識がブレる

どれだけエビデンスをまとめても、大勢が関わるプロジェクトで、長期に渡ってフェーズ進行すれば、ある時点の決めごとを忘れたり、認識がブレたりする。結果的に回収できない要件が発生する。

不整合が生じやすい

リスクの話。条件が複雑になるほど、開発難度は上がり、テストケースが増える。密結合な仕組みになればなるほど、アッチを変えればコッチが動かない。そんな事態が生じる。結果的に、バグやセキュリティホールの温床のようなモノができてしまう。

スキルが伸びない

開発側の話。長い期間のプロジェクトになるほど、文脈を考慮すればするほど、その都度、違う視点で違う作業に取り組むことが増える。仕事はラーニングでないのは当然だとしても、短期プロジェクトと比較すると圧倒的に、長期プロジェクトでスキルアップするのは難しい。

変えられないなかで考えること

難しく思うところを、主観でザッと書き出してみた。

難しさの背景には、規模、期間、座組、承認、検収、予算、契約etc 変えられない都合がたくさんあると思う。口で言うのはカンタン、でも変えるのは難しい。個人としての都合があれば、チーム、プロジェクト、会社組織での都合もある。結果、こういう旧来の開発プロセスを取ることも理解できる。

ただし、変えられないなかで、何をするか、というと、できることをやる。逆にできないことはしない。個人が頭だけで考えると、こうも面白くない結論に至ってしまう。

こう自分の言葉で書き出してみれば、根底から問い続ける必要はある、と感じる。某展覧会の中止が話題になっているけど、他方の意見を認めず、問うことを止めさせることをすれば元も子もなくなる。

本当にお互いに良いことは何か？いつか同じような受託ビジネスを離れても、問う気持ちは大切にしたい。