ウォーターフォール開発は限界を迎えている、とたまーに言われますが、
しかしウチのご近所にこの流れははなかなか伝わっていません。
「ウチのご近所」は、基幹系システムに代表されるような SoR のあたりです。
ウォーターフォール一択、という風習にいまだ変化の兆しはなく、
これからもしばらくはウォーターフォールが主流のままであり続けると思います。
（終わりの時は近づいているようには感じます。）
もちろん、今すぐウォーターフォールなんか辞めちまえ、
などといった非現実的なことを言いたいわけではありません。
モダン開発からイテレーティブな概念を学んで、
改善活動を回せるようになって欲しいのです。
現状で主立った改善活動が回っていないような組織では、
「開発プロセスを見つめ直す」ことすら阻害されています。
ウォーターフォール開発チームにおけるその阻害要因を考えてみます。
目の前の仕事のキャパオーバー。
開発プロセスを考えられる人って、ウォーターフォールに於いても
上流でクリティカルな役割を担っているんですよね。
この状態を放置している組織は、持続性の低い
”一部のメンバー”の苦労に依存し続け、やがて脆く崩壊します。
ステークホルダーのしがらみ。
SoR（System of Record）の開発案件の多くは、
ミッションクリティカルに直結するという性質もあり、
顧客のトップダウンな意思決定が既に進行していることが多いです。
それなりの予算とミッションクリティカルがついてくるので、
ステークホルダーの賛同とアグリメントを得るには
それなりの労力とカリスマ性が求められます。。
逆に、一言返事で「うん」という人はたいてい
何も考えていないので、議論に巻き込んでいきましょう。
そして、ウォーターフォール構造そのものの問題。
何点かあるので、箇条書きで挙げます。
- 上流で決めるべき要件、仕様、設計を正しく定義するのは困難です。
- 上流の判断誤りや要件追加や仕様変更が発生すると、
軒並み工程を辿り直す必要があります。 - しばしば、プロジェクトの後半で障害が終息しない状況で
初めて原因分析が機能し、設計がダメダメであることが発覚します。 - 手戻りがない”前提”（但し、手戻りがないことなどない）で仕事をするので、
コーディングやテストの自動化への関心が比較的薄いです。
この、絶対発生するのに、発生しない「前提」で仕事をする馬鹿馬鹿しさ、どうにかしたいわね。。 - １つのライフサイクルが直列で長いので、改善活動プロセスが機能しにくいです。
これらは、組織やチームのスキルや体質
そのものの問題を含む、改善活動がやりづらい背景です。
あくまでウォーターフォールだから改善活動ができない、
というわけではもちろんありません。
そんなスキルや体質を踏まえ、改善活動プロセスを
機能した状態に持って行くのが重要です。
じゃぁ、どうするか？？
組織のすみっこにいるぼく達は。
既にある構造のなかで改善活動に漸進的に取り組んで、
小さな実績をコツコツと積み上げていきましょう。
実績から関係者の理解を少しずつ得ていくのが組織を強くするのだと思います。
ウチのチームはスクラムの概念を導入しています。
イテレーティブでシンプルな方法論なので、
改善活動プロセスが格段に動かしやすくなります。
※スクラムの中途半端な導入は混乱や品質低下の元です。
やるなら徹底的にやるべし。
さいごに
うまくいっていない開発プロセスを改善したいと考え、
行動する人たちはごくごく一部のように感じます。
SoR は「維持」が重要視されているということもあり、
性格として「変化」を望まない人が多いのもあるかもしれません。
個人が「変化」を望まないのは構いませんが、
それなくして苦労するのは自分たちなんだよ、
という意識を持ちたいものです。
この意識が持てない組織は、日々「変化」する世間のなかで
駆逐されていくんだと思います。
ただし気をつけなければいけないとおもうこと。
「誤った破壊的活動を提案していないか。」
組織である以上、これは慎重に見極めなければなりません。
言いたい事は 1/3 くらいなのに、なかなか言葉がまとまらないなぁ。
読み物書きは難しいですね。。
