ソフトウェアには「メンテナンス」が必要ということが、プログラミングをやったことがない方になかなか伝わらない。作ったら作りっぱなしで放置するものだと考えてほしくないので、ソフトウェアのメンテナンスとはどういうことかを説明します。

1つはバージョンアップ等、環境変化に対応すること。iOSが13→14に上がることで、iOSアプリを開発するためのプログラミング言語のバージョンであったり、開発ツールのバージョンもあがる。

また、後で書くけどオープンソースのライブラリのメンテナンス、最新化対応もコストがかかる。

見た目は同じかもしれないけど、同じものを提供するにも現時点の最新の環境に追随し続けないといけない。

2つ目が改修・増築に伴い、肥大化するソースコードの管理です。

昨今は「オープンソース」の活用が欠かせない。というか、無いと何も出来ない。ネットワーク通信、ファイルの読み込み、画像の表示や拡大、端末のサイズ判定... 私がリリースしているアプリでも、10数個のオープンソースのライブラリを使っている。自分で書くより圧倒的に早く機能が実装できるので、使わない理由がない。

このオープンソースのライブラリのバージョンアップ対応も必要です。9から10に変わった！書き方ぜんぜん違うやん！とかまぁまぁあります。また、今までAを使ってたけど、今度リリースされたBがめっちゃええやん。こっちに切り替えたろ！みたいなのもあります。色々あるんだ大人は。

バージョンアップだけではありません。使われている(売れている)アプリのソースコードは肥大化する宿命を持っています。

アプリの内部構造は、さながらジェンガのようになっています。1つ1つのブロックやパーツが、いい感じに組み合わさっています。

次から次へと出てくる課題に対してあれもこれもとプログラムを実装すると、プログラムは肥大化します。自分の脳内のキャパを余裕で超えていく。正常に各々の機能が動くことを担保するために手動テストは限界があるので、「自分の書いたプログラムをチェックするためのテストプログラム」を用意します。今まで動いていたプログラムから不具合が出るリスクを最小化するためです。

今まで動いていたプログラムから不具合が出ることをデグレといい、ユーザーが最も忌み嫌うものです。 そして、デグレを起こさない仕組みを作るのは、それ相応の技術と手間がかかる。

使われているサービスは新しい機能をどんどん実装して、サービスを拡充します。その結果、ジェンガの土台の作りから逸脱してしまい、今まではキレイに収まっていたパーツが収まらくなり、凸凹した感じになり始め、その凸凹の上に新しいパーツを乗っける、みたいなことが起こります。イメージで申し訳ない。これを技術的負債などと、言ったりします。

この負債の解消を行うにはジェンガの土台を組み直す(建て替える)必要がありますが、建て替えても品質は担保しないといけないので、前述のテストの自動化が重要になります。

ソフトウェアはコードを書いた瞬間から陳腐化が始まり、その陳腐化によってメンテナンスできずに外から崇める「レガシー」なシステムにしないためにも、継続的に手を入れ、改修する技術を引き継がないといけないのであります。