「知らない技術」より「既存システム」が怖い話

Tweet

こんにちは！SJC共同開発推進室の坂根です。
早いもので、入社から3年が経過し、エンジニア4年目に突入しました。

新人だったころに比べると、知らない技術への抵抗感はかなり減ったように思います。
最近では、知らないライブラリや新しいツールを触る機会でも、「とりあえず触ってみよう」「サンプルを使ってコードを書いてみよう」「調べながらで何とかなるだろう」と思える場面が増えてきました。
生成AIの存在もあり、以前よりハードルはかなり下がったように感じます。

逆に、最近難しさを感じるのは、何年も運用されている既存システムです。
今回は、4年目になった今だからこそ感じている、「新技術より、長く動いている既存システムのほうが怖い」という話をしようと思います。

知らない技術は意外と怖くない

もちろん、知らない技術を触るのも簡単ではありません。

知らない単語もあれば、はじめは何をしているのかわからないこともあります。
すぐに取り入れて大丈夫なのか、実績はあるのか、といったことも考えなければいけません。

ただ、最近は公式ドキュメントも豊富ですし、サンプルコードも充実しています。
生成AIに頼めば、サンプルコードを作ってもらうことも容易です。
また、導入事例やコミュニティの情報を調べたりすることで、「本当に業務で使えそうか」を以前より判断しやすくなってきたように感じます。
ですので、少しずつ時間をかければ理解できるケースがほとんどです。

4年目にして、「調べれば何とかなる」という感覚が身についてきました。

本当に怖いのは、長く動いているシステム

逆に、最近難しさを感じるのは、何年も運用されている既存システムです。
既存システムだからすべて難しい・怖いというわけではありません。
設計やドキュメントが整理されていて、とても保守しやすいシステムもあります。

実際に引き継いだシステムでも、過去の担当者の方々が残してくださった資料やコメントに助けられる場面が本当に多く、「ここまで残してくれていたのか……！」と感じることも少なくありません。

その一方で、自分が対応した機能を久しぶりに見返したときに、「なんでこの経緯を残していないんだ」「ほしい説明が足りない」と、過去の自分を叱りたくなる場面も増えてきました。
コード自体は読めても、「なぜこのコードになったのか」という背景が分からない。
最近は、そこに既存システムの難しさがあるのだと感じています。

どんな怖さがあるのか、もう少し具体的に書いてみます。

一見不要そうなのに消せないコード

コードを読んでいると、「この処理、本当に必要なのかな？」「もっとシンプルにできそうなのに」と思うことがあります。
新人の頃の自分なら、かなり高い確率で「整理した方がいい」と考えていたと思います。

ですが、実際には、その意味が分からない処理によって助けられているケースも少なくありません。
過去に発生した障害への対応だったり、特定条件下でだけ起きる不具合を回避するためだったり、運用上どうしても必要な処理だったり。
長年運用されているシステムほど、そういった「歴史」がコードの中に残っています。

その際に厄介なのが、その背景がコードやドキュメントに残っていないことです。

• コメントもなく、設計書にも書かれていない。

• 当時の担当者もすでに退職したり、異動していたりする。

でも、システムは今も問題なく動いている。
だからこそ、「不要そうだから消す」という判断が難しいです。

コメントがない暫定対応

不安になるのが、「暫定対応」や「TODO」とだけ書かれているコードです。

例えば、

のようなコメントを見たことはないでしょうか。
思い返すと、このようなコメントを書いたことがある気がします……。

• なぜ暫定なのか
• 何を回避するためなのか
• いつ、どんな条件で直す想定だったのか

そういった背景が残っていないまま、コードだけが残されているケースは意外と多い気がします。
障害を止めるためだったり、影響範囲を最小限に抑えるためだったり、暫定対応はその場では本当に必要なことがほとんどです。
その瞬間の判断としては、むしろ正しいことも多いと思います。
ただ、数か月、数年経つと、その背景を知っている人がいなくなってしまいます。

逆に、例えば、

のように、背景や判断理由が少し残っているだけでも、後から読む側の安心感はかなり違います。

私自身、過去に自分で書いたコードを見返して、「なんでこうしたんだっけ……？」となることがあります。
そのたびに、未来の保守担当って未来の誰かではなく、数か月後の自分自身でもあるんだなと感じます。

「コードを書く」より「理解する」時間が増えた

こうした経験を通して、最近は「コードを書く時間」よりも、「理解する時間」の方が長いと感じることが増えました。
コードそのものは数行の修正でも、その前に確認することがたくさんあります。

ログやDBのデータを確認する。
影響範囲を調べるために、関連する画面やバッチを探す。
過去の経緯を知っていそうな人に確認する。

そうやって調べていくと、修正作業よりも、安全に修正するための調査の方に時間がかかることもあります。
新人の頃は、コードを書いている時間こそが開発だと思っていました。
でも今は、壊さずに変更するために調べる時間も、かなり大事な開発の一部なんだと感じています。

「動くようにする」から「今まで通りを守る」へ

既存システムの改修では、「動くようにすること」よりも「今動いているものを壊さないこと」が難しいと思います。
新しく作る場合は自分で仕様をコントロールできますが、既存システムはすでに利用者がいて、運用が回っていて、他の機能と密接につながっているからです。

そのため、たった数行の修正であっても簡単には触れません。
この値は別の処理でも参照されていないか、このログは運用で使われていないかなど、常にブレーキをかけながら進める必要があります。

新人の頃は、コードを読むときも、「何をしているのか」「どう動くのか」ばかり見ていました。
しかし最近は、「なぜこのコードになったのか」「なぜこの処理が必要だったのか」という背景を考えるようになりました。
一見すると冗長で綺麗じゃないコードに見えても、運用上の制約があったのかもしれない。
そういった「今も残っている理由」も意識するようになりました。

ドキュメント整備の重要性

こうした恐怖を経験するたびに、ドキュメントやコメントのありがたみが身に染みます。
完璧な最新の設計書がなくても、画面遷移図やテーブル定義、過去の障害履歴が少しあるだけで、調査のスピードは劇的に変わります。

逆に一番つらいのは、「何も情報がない」状態です。

コードを読むことはできます。
ただ、「何が正しい動きなのか」が分からない。
仕様なのか、不具合なのか、意図した挙動なのか、たまたまそう動いているだけなのか。
そこが判断できないと、修正の方向性すら決められないことがあります。

README、作業メモ、障害時の対応履歴、対応したチケットのリンクなどが少し残っているだけで、未来の保守担当はかなり助かります。
実際に直近で、このような問い合わせ対応集に助けられました。

開発で意識するようになったこと

こうした経験を通して、最近は開発に対する考え方も少し変わってきました。

以前は、

• まず動かす
• 綺麗なコードを書く
• 共通化する

といったことを強く意識していた気がします。
今でもそれは大事ですが、最近はそれに加えて、次のような「未来の保守担当が困らないか」という視点を意識するようになりました。

• コードの背景や経緯を後から追えるか
• 数か月後の自分や、別の担当者が見ても迷わず理解できるか
• 将来の保守担当者が、安心して調査・改修できる状態になっているか

障害対応や緊急対応では、とりあえず今を乗り切ることが必要な場面もありますが、その場しのぎで入れた処理が、数年後まで残り続けることも珍しくありません。
背景が分からなくなった暫定対応は、長く動いているシステムの中で、簡単には触れない存在になっていきます。
そうならないよう、特に、その場しのぎになりがちな暫定対応ほど、慎重に背景を残すようにしています。

まとめ

4年目になって、新しい技術への抵抗感は以前よりかなり減りました。
その代わり、長く動いているシステムを安全に触る難しさを強く感じるようになっています。

最近は、「どうコードを書くか」だけではなく、「なぜこのコードなのか」という背景を少し考えながらコードを読み、書くように意識しています。

数年後の誰かが困らないように。
未来の自分が「なんでこうしたんだっけ……？」とならないように。

そんなことを少し意識するようになったのが、エンジニア4年目になって変わったことの一つなのかもしれません。

エコモットでは一緒にモノづくりをしていく仲間を随時募集しています。弊社に少しでも興味がある方はぜひ下記の採用ページをご覧ください！