ウォーターフォール開発宣言
アジャイルソフトウェア開発宣言というものがある。アジャイル界隈のエンジニアなら何度も読み返していて、暗唱もできるくらいだろう。
実際、この開発宣言は良いことを書いている。『プロセスやツールより 』の下りはソフトウェア開発プロジェクトでは、プロセスやツールは手段であり、達成しなければならないのはプロジェクトの目的の実現なのだから、目的と手段が入れ替わっているようなものだ。
では、これはアジャイル開発だけの洗練な考え方なのかと言えば、そうでもないのでは、と思う。
ソフトウェア開発に気持ちがフォーカスしているエンジニアなら、ウォーターフォールのソフトウェア開発であっても、プロセスやツールに時間を掛けるより、業務オーナの実現したいことに時間を掛けたいと考えているはずだ。
使われないドキュメントより、ソフトウェア開発プロジェクトの目的であるシステムを完成させたいと願っているはずだ。
ただ、プロマネが、声の大きい顧客が言うからと、思考を停止せず、なぜソフトウェア開発プロジェクトがそこに存在するのか、エンジニアとして自分がチームに必要とされているのか、本質を理解しているはずだ。
ソフトウェア開発プロジェクトの目的を理解せず、何で作るかという方に間違った方に走りすぎている周囲のノイズに汚染されてしまっているのではないか。
アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
本来の、ウォーターフォールを適用したソフトウェア開発プロジェクトに立ち戻るためには、エンジニアは次の考えを受け入れなければならないのではないか。
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよいプロジェクトの達成方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。エンジニアの自由や裁量よりも業務オーナと対話を、
使いもしないドキュメントよりも実現に必要なアウトプットを、
リソース調整よりもスコープとの協調を、
実現性のない規程に従うことよりも洗練された作業プロセスのデザインを、価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
『 エンジニアの自由や裁量より』の下りはとても炎上しそうではあるが、アジャイル開発のカンバンで列を区切った瞬間から、作業プロセスはチームで標準化され、それをエンジニアに強制する。
チームで決めた作業プロセスに従わないと言うことはできない。ただ、必要性があるとチームで決めたのなら、作業プロセスの列を変更する自由と裁量はチームに保留されている。
業務オーナとの対話は、要件では表現されない、プログラムでの挙動に落とし込むための情報を確かめるためである。通常、セッション形式で機能を詰めていくのはこのためであり、ここに相応の時間を掛けてToBeの業務で必要な機能仕様を具体化する。
プロジェクトの大小に関わらず、必要なドキュメントは必要であるし、あとあと読も修正もしないドキュメントは作る必要がない。開発のとき、運用で改修するときに必要な中間生産物はネグることはできない。それでも作りたくないなら、エンジニアはそのシステムと心中する覚悟を持つ必要があるが、その代償も大きいことは知っておくべきだ。
QCDSに必要な予算が足らないことで、確保するために奔走したり、説得するのは本末転倒もいいところである。であれば、スコープの調整を行い、必要最小限の価値のある機能を実現する方にリソースをぶち込んだ方が、より生産的である。
チームはなぜ存在するか、ソフトウェア開発プロジェクトはどうしてそこにあるのかをわかっていない外野は、自己のしがらみを押し付けてくる。しばしばソフトウェアの実現性を歪める。であれば、エンジニアは実現性のない規程は、プロジェクトの実現のために正しくテーラリングできなければならない。
