RSGT2023のKeynoteでレガシーコードの話題が出たが、SIerの文脈でのレガシーコードってKeynoteで言っているレガシーコードと一緒なのか？と思ったので、 SIerのn次受けからみたソースコードのレガシーさをアウトプットしてみようと思う。 ここでいうレガシーさとは、不健全さや不健康さという意味が含まれている。 また、ここでの話は個人の経験からくる予想や妄想が大いに含まれており、誰かを揶揄したり否定するような目的はない。
ソースコードはどのように見えているのか？
設計書をインプットに作成され、次の工程でテストを行うもの。みたいな感じではないかと思う。 ソースコード自体の良し悪しを測ったりすることはなく、バグが一定以上出ているか？とか、設計の時点でソースコードが読めない人でも納得できるようになっているか？ が重要視されているように見える。 当然リファクタリングの工数なんてものは存在しない。 大抵はオフショアなど比較的安いんだろうなと思われるところに投げて、自分はなるべく上流へ行きたがる。そして上流の方が儲かる。 「まだソースコードを書いているのか？」などと言われることもある。（最近はないかも？） たまに上流でソースコードをかける人が、小規模なPoCを開発規模や難易度を度外視して使えと下流に流してくることもある。
そして、ソースコードは劣化しない資産であるとみているのではないかと思う。 継ぎ足していくと価値が単純に高まっていくと思われていて、機能の削除は歓迎されない。
このような傾向があるように感じる。
実際ソースコードはどうなっているのか？
いい状態とは言えないと感じる。少なくともレガシーコードからの脱却を目指すような動きが見えるコードは少ない。ユニットテストはない傾向にある。 動くことというか、動いたことが重要視され、拡張しやすいなどは軽視されがちである。 単純にクソコードと言ってしまってもいいが、単純にそういうものでもなく、実際にコードを書いている人はクソコードを書こうとしているわけではないのは見て取れる。 その場その場で各人ができることを全力でやっているが、結果いいコードが生まれないプロセスになっていると感じる。とても悲しい。
なぜこんな悲しいことになっているのか、思いつくままにあげていこうと思う。
ソースコードはアーキテクチャではなく政治によって設計されている
ソースコードは最低限のアーキテクチャには則っているが、基本的にはコーディング開始までの企業、チーム間の政治によって設計されている。 そのため、政治力の強いチームに政治力の弱いチームが合わせるようになる。もしくは早く参加したチームが強くなる。 各チームは政治力を駆使して、いかにバグが発生したときに自分が直さなくて済むかを考え責任を押し付けていく。 例えば、あるフラグがOFFの時はONにする、ONの時は何もしない。といった操作が必要な場合、 - ONと言ったら言われた側で判断する - 事前にONかOFFか取得して、OFFの時だけ処理をする この２つの解決方法は政治によって決定する。ソフトウェアの設計を考えれば、前者が正しい責務分担と言えると思うが、 ONの時にONした時にバグが発生した場合、後者であれば、事前に確認しないのが悪いと呼び出し側にバグを押し付けることができる。実に政治的である。
もう少し大きなところであれば、リポジトリ構成やディレクトリ構成、ツールチェーンなども政治的な側面が垣間見える。 リポジトリは1チームしかさわれない。つまり、機能とチームによって分割される。チームとは企業であるので、発注とリポジトリは切っても切れない関係にある。 なので、チームを跨いだ共通機能リポジトリにみんながコミットするような動きは発生しない。やりたくても制御し切れないであろう。
ソースコードはRVを重視して修正されている
RVを重視しているから、綺麗に書いていて、無駄な処理がなくてというわけではなく、RVの時にいかに見やすいかが重要視されていると感じる。 修正前のコードはコメントアウトされたまま残され、追加したコードはADDなどのコメントで挟まれている。 これは将来的な読みやすさではなく、修正した時に発生するRVでいかに見やすいかを求めている。 差分ビューアーも綺麗に差分を見せてくれるとは限らない。そもそも差分しか見る気がないのである。
ソースコードは修正に対して影響が少なく書かれている
一見いいことのように感じるが、そうでもない。極端に言えば、共通化は悪となるのである。 共通処理は変更したいときに漏れなく変更できるというメリットがあるが、同時に変更すると影響範囲が大きくなるというデメリットがある。 このデメリットを重く見ていると感じる。 新たに同じ処理をしたいときに、共通部分を部品にするのではなく、コピペすることになる。 共通の振る舞いを変更するのに手間がかかるが、手間がかかるだけなのである。 共通部分でバグが出たとしても、共通化したかしていないかによってバグの件数は変わらないのである。 バグを一つずつ直せばいいのである。簡単なバグがコツコツ治るのでたいして批判は起きないのである。
ソースコードにはtypoが多く含まれている
ソースコードにはテストがなく、RVのために差分がわかりやすくする必要がある。つまり、typoが直せないのである。 ついでにIDEを使っているとも限らず、スペルチェックツールを導入していないことも珍しくない。 なによりまともに英語ができるのであればこんな状況でソースコードを書いていないのである。 良いtypoはニックネームとして定着するのである。
ソースコードは読みにくいが読めないわけではない程度の可読性になっている
ソースコードなので読めるのだが、なぜ？がなかなか解消されないのである。 なぜここでこの処理が必要？などは、おおよそ歴史的な背景からなっていてそのほとんどがホットフィックスレベルの修正だったりする。 ソースコードの構成も特色が出ていたり、当時の課題に対して有効だと思われるものであり、今の読み手と気が合わないことが多い。 コメントはコードを日本語に翻訳しているだけか、RV向けのものが多く信用できない。ドキュメントもまた然りである。 頑張って読み解き、歴史的な背景を想像しながら読んでいく必要がある。 そんな思いをして読む必要はないのではないか？あるのである。流用と言って安いよと謳って過去のソースを投げてくるのである。 投げられた時点では実行環境もなかったりするので、とりあえず読むしかないのである。
何が問題なのか？
特に問題はないのだと思う。もちろん社会的であったり、もっと大きな目線から見れば大いに問題だと思うが、これらのエコシステムの中にいる人にとっては問題ではなく、 むしろこのままでなければ問題があるという面があるように感じる。
これに関しても思いつくままにあげていこうと思う。
難しいものは難しいままの方が儲かる
契約がプロジェクト方式なので、難しいものを難しいままにして、自分だけが理解できるようにしておくことが継続発注のためには有効である。 極端に難しくするのはそれはそれで継続できるか疑問ではあるが、少なくともすごくシンプルにしようという力学は働かない。 そもそもシンプルにせよという発注は来ない。シンプルさを測る術を持っていないので発注しても無駄なのである。 仮にすごくシンプルにすごく良いソースコードがかけたとしても、おそらくそのソースコードの所有権は良いコードを書いた人にはない。
無駄は儲かる
無駄によって被害を被るのは発注側だけであって、それ以外の人にとっては無駄は儲かるものであって、適度に無駄を生み出すと売り上げが上がるのである。 このような状況下にあると、やらないよりやった方が良いことがいつの間にか必須なことになっていく。 無駄を生み出すことが良いことであると、無駄を生み出すことができる人が必要になる。やることは減らずに増えていく一方なのである。 ただし、無駄を生み出す人と無駄を処理する人は異なり、無駄を処理する人は無駄だなと思いながら無駄なことをこなしているのである。モチベーションは無くなっていく。
高度なスキルが必要ない
難しいことを簡単にしたり、無駄をなくしたりするには高度なスキルが必要である。これらを求めない代わりに、高度なスキルがなくても無駄を処理できるようになっている。 これは、時間と人数によって売り上げが決まる仕組みに対して有利である。人の確保も比較的容易である。教育のコストも低い。 そもそも、スキルの習得や教育のコストはどこが払うべきなのか、絶妙に定まっていないように見える。言うなれば個人が払うようになっている。 個人が何もしなければ、スキルは上がらない。上がるとしてもガラパゴス的なオレオレスキルだけである。そして単価も上がらない。
何が問題なのか？(外から)
あらためて少し大きな目線から問題を見てみよう。
プラットフォームが作られない
世界はいかにプラットフォーマーになるかが競われている面がある。しかし、今のような構造だと、継続的に改善し続けることができない。 そもそも、プラットフォーム自体を発注しないし、プラットフォームとアプリというような発注でも、品質が低いのでプラットフォームとして満足なものは作られない。 そもそも、プロジェクト方式の契約だとプラットフォームを作ることは難しい。
単価もスキルも上がらない
このエコシステムにいる限り、スキルの向上は単価の向上につながらない。単価を上げるためにはいかに上流にいくかが重要である。 上流に上手く食い込んで、適度に無駄を作り、充分に中抜きした金額で責任と作業を下流に投げつけることが重要である。 逆にスキルが上がれば上がるほど、現状に切なさを覚えるようになる。
人材の確保が難しくなる
問題の解決方法は基本的にマンパワーであるため、人材の確保が難しくなる。スキルなど参入のハードルは低いが、人口が減って行く日本では、人材の確保が難しくなる。 とはいえ、正直誰でもいいという究極の多様性を許容している感もあるので、まだ持つとは思う。
さいごに
ダラダラと愚痴っぽくなってしまって申し訳ないし、悲しくなってきただけな気もしますが、個人の見解としてはこんなものです。 印象としては、どこもそんなに困ってないんだなという感じです。 ここでいう発注者のような大企業のアプリはレビューが低いのが当たり前みたいな消費者の意識ができていたり、それでも使わざるを得ないようになっているからなぁ。 みたいな悲しい感じがあったりしないかなと思います。
話が逸れた気がしますが、SIerにおけるレガシーさはもう少し根が深いかなと思います。 ソースコードだけの問題ではなく、レガシーな体質だったりがスクラムチームぐらいの規模だと太刀打ちできないぐらい大きいのではないかと思います。
