ソフトウェア開発に正しいとか正論は何も解決しない

要件は仮初めで変わるものなのだから、それに変化できるようにプログラムを作るのが当たり前じゃないか。要件が変わって容易に修正できないアーキテクチャやコードは…

TLに流れてきたつぶやきなんだけれど、どれだけひどい経験をしたのか、と不憫に思えなくもない。

不憫ではあるのだけれど、どこのレベルで言っているのか前提がわからなくて。何かとても狭い世界で毒を吐いているように思えるんですよ。

要件が変わる

ここは同意するんですよね。どうしてかというと、発注者であるオーナ自身が現物をみてこれを作って欲しいと言ったわけではないので。

RFPにしろ発注仕様書にしろ調達仕様書にしろ、机上での話であって実際に動くソフトウェアを元に業務委託なんぞしていませんから。

こんなことを「実現したい（はず）」で発注しているので。受注側も「これを実現するんですね」と「はず」を前提に見積もっているんですから。

発注者側が実現されるシステムに対して確信を持って発注なんてしていないのです。ここが後から見れば要件が変わる、の1つ目になるのです。

受注側も「実現したい（はず）」を受注者の経験を参考に解釈して提案するのでここも解釈のずれから要件が変わったように思えるわけです。

要件は変わっても対応できないのはダメなのか

全く対応できないことって現実にあるんでしょうか。その点においては対応できないアーキテクチャもコードも存在しないのではないかと思うのですよ。そこがソフトウェアの特徴でしょう、と。極論を言えば、オーバーラップする新しいコードで旧コードを亡き者にしてしまえばいいのですから。極論ですけど。

でも現実に不要となった機能を削除することなく、残置する行為は発注者側と協議して残すことは見かけますね。監査対応ぽいですが。

それで、コードを直すのが容易かどうかか、それはあるかもしれません。でも、その容易かどうかってどんな基準なんですかね。

まず、それが疑問。いちゃもんを言っている割には定性的なんですよね。それも個人に依存しているのでどーでも解釈できるし、言っている側のポジションが一見正しく見える。

世の中で一見正しく見える意見は、全く価値のない暴言だと思わないこともないです。つまり、思っているのですが。

一見、正しいことを要求していても、じゃあ、それどう解決するのかと返せば、それはお前たちが考えることだ的な物言いになるやつ。

そっちの方がゴミですね。問題なら解決しないと。

確かに、保守性が良いアーキテクチャ、コードの方がいいに決まっています。それに対してどこまで求めるかというと制約がつくんですよ。

スタートアップなら、そんなことは言わずにまずは動くソフトウェアをリリースしないとスタートアップ自身が絶命するんですから。お金がなくなって。そこに、柔軟に要件が変わっても対応できるアーキテクチャにしろとか、コードを書けというのかということです。大事なことはお金がショートする前にリリースして投資資金を回収しろってことです。

これが大規模開発になるとまた別の例で同じようになるんです。例えば400人/月のSEにアーキテクチャやコードを書かせるのに柔軟性のあるコードを書けと言ってどれだけ目が届くかってことです。

これの大前提に400人/月としないとオーナの要件が実現できない（時間制約的にとかで）からオーナも受注者も合意してプロジェクトを始めるわけです。

このとき、何が重要になるかを考えればわかることですが、400人を同じ作業品質で同じ要求品質の仕様もコードも求められるんです。

それに必要なのは少人数でアーティスティックでエレガントなコードではないのです。エンジニアリングとしてしてのコードです。

もちろん、大量のコードが作られる（1700ステップ/月＊6ヶ月＊400人だったら40,800,000ステップですよ）のですから保守性の良いコードを書け、って言いますよ。エンジニアリングの観点でも。