お気の毒に・・。
スパゲティコードになるプロセスはよーくわかる。
仕様変更に次ぐ仕様変更、当初の想定が間違っていたことのフォローアップ、一つ一つ丁寧に進めていきつつ、当初の見積工数を超えないようにこれまでの成果物をできるだけ活かしたら、最終的にできるのはスパゲティーになる。
スパゲティーを作る人が悪いんじゃなくて、オーダーした人がスパゲティーを望んだからだとしか言いようがない。スパゲティーを作って欲しいと言っている人に、スパゲティー以外を料理する方法が思いつかない。麺類なら許されるのか？。
大企業のプロジェクト運用体制に、１つ起因する問題もある。長期に運用するシステムの場合、同じ担当者がずっと担当し続けることが難しいことだ。人が入れ替わる前提だと、毎回引き継ぎのタイミングで過去の情報を振り返らないといけない。この時ほぼ情報は抜け漏れる。どんなに優秀な人が担当しても、だ。どんなに全ての情報を残していても、である。時間が経てば経つほど情報量は大きくなる。そして、抜け漏れ防止活動で、細かい情報も全てデータベースに残そうとすると、たちまち情報量が膨れ上がっていく。そしたら、追いかける方も追いかけきれないのである。
こちらは顧客側、つまり国や自治体側にも同じことが言える。定期的に担当者が異動になるので、これまでの経緯が引き継がれるがその際に抜け漏れが起きる。そして、また新しい担当者が、あれ、これ仕様通りじゃない、とか言い出すわけだ。え、前回の担当者には説明して承認頂けたじゃないですか。エビデンスもありますよ。みたいなことを繰り返しているのがシステムの継続開発・運用の現場である。
制度設計がスパゲティーになっているのに、なぜソースコードがスパゲティーにならないと思うのか。
なお、よくパッケージソフトを使ったり、外国のPaaSやSaaSを組み入れ、API連携してソースをスッキリさせるという話もある。しかし、PaaSやSaaSの先にもソースコードがある。ある業務を動かすときのソースコードの量は一定であり、それをアウトソースして見えなくしているだけの話だ。で「ノーコード」「ローコード」なんてのはちょっと痛い話だと思っている。要件がスパゲティー状態なら、ノーコードやローコードなのにスパゲティー状態となるのも必至だ。そう、コードが無くてもスパゲティーはできる。そのとき何と表現するべきなんだろうか。
システムトラブルに対し、ITエンジニアばかりチラチラ見るのは止めるべきだ。どういう業務なのか。業務内容は法律の変化などでどれぐらい変更頻度や量があるか。メインシステムとサブシステムなど、変化時の柔軟性は構築当初どの程度考えられていたか。システム構築時の想定を大きく変えた利用の仕方となり、無理に適応させていないか。
AIはさておき、コンピューターというものは、指示した通り動くもの。その指示があっちからこっちから出てきて、しかもその出し手も受け手も体制が流動的で、そして法律改正でじゃんじゃか変更要件が膨らむなんて、スパゲティーを作りたいとしか思えないのだがどうか。
