「使われ続ける システム」 をつくる設計の話。

「せっかく作ったのに、数年で使われなくなった」。システム開発の現場で、これほど切ない結末はありません。導入直後は華やかでも、業務が少し変わるたびに継ぎ接ぎが増え、誰も全体を把握できなくなり、やがて「触ると壊れるから、なるべく触らない」存在へと沈んでいく。私たちが新しいご相談を受けるとき、その背景に“前のシステムが重荷になっていた”ケースは、決して少なくありません。

だからこそ私たちは、システムを「完成させるもの」ではなく「使い続けられるように育てるもの」として設計します。本記事でお伝えしたいのは、特別な新技術の話ではありません。運用・保守・改善という“その後の長い時間”を最初から織り込んだ、地味だが効く設計の考え方です。10年付き合えるシステムには、いくつかの共通条件があります。

「作って終わり」が、いちばん高くつく

システムの費用というと、つい開発費に目が向きます。けれど実際には、稼働してからの運用・改修にかかる時間のほうが、合計では大きくなることがほとんどです。業務は生きものですから、組織が変わり、取引先が変わり、法令が変われば、システムも追随しなければなりません。つまり「変更が起きること」は例外ではなく前提です。

この前提を最初に受け入れているかどうかで、設計の質は大きく変わります。変更を“想定外の事故”として扱う設計は、改修のたびにあちこちが壊れます。逆に、変更を“当たり前の日常”として迎え入れる設計は、手を入れるほど健やかになる。使われ続けるシステムとは、完璧に固まったものではなく、安全に直し続けられるものなのです。

変更に強い構造をつくる

長持ちするシステムの背骨は「変更のしやすさ」です。私たちが構造を組むときに繰り返し問うのは、たったひとつ——「ここを直したいとき、他のどこまで影響するか」です。理想は、変えたい一点だけを安全に変えられること。そのために、設計段階で次のようなことを意識します。

• 画面・業務ロジック・データを層として分け、役割を混ぜない
• よく変わる部分（税率・料金・区分など）はコードに埋めず、設定として外に出す
• 同じ処理を二重三重に書かず、一か所にまとめて参照する
• 外部サービスとの接続は窓口を一本化し、差し替えに備える

派手さはありませんが、こうした分け方が効いてきます。たとえば料金体系の変更を、料金表という一か所だけで完結できれば、改修は数時間で済み、影響範囲も読み切れます。逆に料金の判定が画面のあちこちに散らばっていると、ひとつ直すたびに見落としが生まれ、テストの量も恐怖も膨らんでいく。構造とは、未来の自分や後任者への“手数の貸し借り”なのです。

— Note

「良い設計とは、変えてはいけない所を守り、
変えてよい所を“変えやすく”開いておくことです。」

引き継げるドキュメントを残す

システムが寿命を縮める典型的なパターンが「作った人しか分からない」状態、いわゆる属人化です。担当者の異動や退職、開発会社の交代をきっかけに、誰も中身を説明できなくなり、怖くて手を出せなくなる。これを防ぐのは、難解な分厚い仕様書ではありません。必要なのは、次の人がすぐに動き出せる“最小限の地図”です。

私たちが特に大切にするのは、コードを読めば分かることではなく、コードを読んでも分からないこと——つまり「なぜそう作ったのか」を残すことです。なぜこの区分を設けたのか、なぜこの順序で処理するのか。背景にある業務上の理由が分かれば、後任者は安心して手を入れられます。具体的には、次のような記録を、過剰にならない範囲で整えておきます。

• 全体像が一枚で分かる構成図と、データの流れ
• 「この値は何を意味するか」が分かる項目の説明
• 設定変更や復旧など、運用でよく行う作業の手順
• 過去の判断の理由——「なぜこの仕様にしたか」のメモ

ドキュメントは、書いて終わりにすると古びて嘘をつき始めます。だからこそ、量よりも“更新し続けられる軽さ”を優先します。引き継げる記録があることは、特定の誰かに依存しない安心を組織に残すこと。それは、システムそのものと同じくらい価値のある資産です。

現場が触れる「余白」を残す

長く使われるシステムには、ある共通点があります。それは、現場の人が自分の手で“少しだけ調整できる”余白を持っていることです。何から何まで開発会社に依頼しなければ変えられないシステムは、小さな変更ですら時間とお金がかかり、いつしか「不便でもこのまま使おう」と諦められていきます。その諦めが、システムを過去のものにします。

もちろん、何でも触れるようにすればよいわけではありません。壊してはいけない根幹はしっかり守りつつ、安全に変えてよい範囲だけを現場に開く——その線引きこそが設計者の仕事です。たとえば、お知らせ文や選択肢の追加、帳票の項目順、通知の宛先といった“日々ちょっと変えたくなる部分”を、管理画面から現場が自分で直せるようにしておく。すると、現場は「自分たちのシステム」として愛着を持ち、小さな改善が自然に積み重なっていきます。

この余白は、開発側の手離れを良くするためのものではありません。現場が主体になって育てていけることこそが、システムを生かし続ける最大のエンジンだからです。使い手が育てられるシステムは、放っておいても古びにくいのです。

10年付き合えるシステムの条件

ここまでをまとめれば、使われ続けるシステムの条件はシンプルです。変更に強い構造を持ち、次の人へ引き継げる記録があり、現場が自分で触れる余白がある。この三つが揃ったとき、システムは納品時点が最高ではなく、年を重ねるほど現場に馴染み、頼られる存在になっていきます。新しさを競うより、こうした地味な条件を満たすことのほうが、結果として長く役に立ちます。

私たち d-studio が設計で最も時間をかけるのは、最新の道具選びではなく、お客様の業務がこの先どう変わっていきそうかを一緒に想像することです。北九州を拠点に、地域の企業と長くお付き合いするなかで、私たちは“納品して終わり”ではなく“一緒に育て続ける”立場を選んできました。だからこそ、その後の変更に耐える設計を、最初の一行から大切にしています。

「今あるシステムが、だんだん重荷になってきた」「次に作るなら、長く使えるものにしたい」——そう感じておられるなら、ぜひ一度お話を聞かせてください。作り直すかどうかを決める前の、現状を整理する段階からご一緒できます。10年後も使われているシステムの条件を、あなたの会社の言葉で一緒に描いていきましょう。