「全体設計」という一言の中で、あなたは何に悩み、何を決めてきましたか。

「システムの設計を決める」

開発の仕事ではよく耳にする言葉ですが、実際には、いったい何を決めるのでしょうか。

使う言語やフレームワーク。
サーバーやデータベースの構成。
ほかのシステムとのつなぎ方。

そこには、実に多くの判断があります。

そして、一つひとつの判断が、開発の進めやすさや、利用者の使いやすさ、数年後の変更のしやすさにつながっています。

「何を採用したか」とともに「なぜ、その選択をしたのか」を話せる開発組織でありたいと考えています。

全体設計は、システムに関わる人たちの共通の土台をつくる仕事。

必要な機能を挙げることはできます。しかし、それぞれの機能をつくり始める前に、すり合わせておきたいことがあります。

利用が集中しても、業務を続けられるか。
障害が起きたとき、どこまで復旧できるか。
誰が、どの情報にアクセスできるか。
既存システムから、どう安全に切り替えるか。

こうした問いへの答えが曖昧なままだと、担当者ごとの判断が食い違い、後から大きな手戻りにつながることがあります。

だからこそ、システム全体として守る方針や、共通の仕組みを決める必要があります。

① システムを、どのような構造にするか

画面、業務の処理、データの保存を、どのように役割分担させるか。
どこを一つのまとまりにし、どこを分けるか。

たとえば、計算ルールが変わるたびに、多数の画面や処理を修正する構造では、変更の影響が広がってしまいます。

変わりやすい部分を見極め、変更の影響を抑えられる構造を考える。
そこには、技術の知識と業務への理解の両方が必要です。

② 障害や誤操作が起きても、業務やデータをどう守るか

どの業務は停止を避けたいのか。
停止した場合、どれくらいの時間で復旧する必要があるのか。
どの時点のデータまで戻せればよいのか。

バックアップを取得するだけで、十分とは限りません。
必要な時間内に復元できることや、処理の途中で止まってもデータの不整合を残さないことまで考えます。

「絶対に止まらない」という曖昧な目標を、業務に必要な水準と、それを実現する仕組みに落とし込む判断です。

③ 開発・テスト・本番の環境を、どう用意するか

開発中の変更を、どの環境で確認するか。
本番に近い条件で、どこまで検証できるようにするか。
環境ごとの設定やデータを、どう管理するか。

開発環境では動いたのに、本番では動かない。
テストのつもりで、実際の利用者に通知が届いてしまう。

こうした事態を防ぐためにも、環境の分け方や利用ルールを、全体として考える必要があります。

④ どのくらいの速さで、どれだけの利用に応えるか

通常時だけでなく、利用が集中する場面を想像します。
多くのユーザーが一斉に操作する時間帯。
大量の帳票を作成するタイミング。

利用人数やデータ量、許容できる待ち時間を確認し、構成や処理方式を決める。
時間のかかる処理は、受け付け後に裏側で実行する方法もあります。

必要な性能と費用のバランスも、設計の大切な判断です。

⑤ 誰が、どの情報を扱えるようにするか

ログインできることと、すべての情報を見られることは別です。

閲覧はできても、変更はできない人。業務上の役割に応じて権限を整理し、操作の記録やデータの保護も考えます。

安全性を確保しながら、必要な業務を無理なく進められるようにする。その両立が求められます。

⑥ リリース後、誰がどう運用するか

異常をどう検知するか。
通知を誰が受け取り、何を確認するか。
原因を調べるために、どの記録を残すか。

エラーが発生するたびに、開発者が手作業で調査しなければならない仕組みでは、運用の負担が積み重なります。

運用する人の体制やスキルも踏まえ、日々の確認や復旧を進められる仕組みを考えます。

⑦ ほかのシステムと、どう情報を受け渡すか

APIで即時に連携するのか。
一定の時間ごとに、まとめて連携するのか。
どのシステムが、正しい情報の管理元になるのか。

さらに、相手のシステムが停止していたらどうするか。
同じデータが二度届いたら、どう扱うか。

接続できることに加えて、連携が失敗したときも含めて、業務が成り立つように考える必要があります。

⑧ チームで、何を共通のルールにするか

命名、エラー処理、ログの出し方、共通部品の使い方。

担当者ごとに方針が異なると、ほかの人がコードを理解したり、修正したりする負担が増えます。

一方で、細かく決めすぎると、開発の柔軟性を失うこともあります。

品質と保守性を支えるために、何をそろえ、どこに裁量を残すか。
標準化にも、判断が必要です。

⑨ システム全体の品質を、どう確かめるか

個々の機能が動くことに加えて、業務の流れが最後まで成立するか。
利用が集中しても、必要な性能を満たすか。
障害が起きたとき、想定どおりに復旧できるか。

何を、どの環境で、誰が確認するのか。
合格とする基準をどう置くのか。

設計した方針を検証できるよう、テストの進め方も早い段階から考えます。

⑩ 現在の業務から、新しい仕組みへどう切り替えるか

既存データを、どう移すか。
移行結果が正しいことを、どう確認するか。
切り替えのために、業務をどれくらい止められるか。

問題が見つかった場合に、元へ戻せるかどうかも重要です。

新しいシステムが完成していても、現場が使い始められなければ、価値は届きません。
移行も、全体設計で向き合うテーマの一つです。

一つひとつの判断は、つながっている。

性能を高めようと構成を複雑にすれば、運用の負担が増えるかもしれません。
連携を即時化すれば、相手のシステムが停止したときの対応も必要になります。
費用を抑えた構成が、求められる復旧時間を満たせないこともあります。

それぞれの項目で最適に見える選択が、全体として最適になるとは限りません。

利用者、事業、開発、運用という複数の視点を持ち、関係者と優先順位をすり合わせることが大切です。

また、最初にすべてを細部まで確定させる必要があるわけでもありません。

先に決めなければ影響が大きいこと。
検証してから決めたいこと。
変更を見越して余地を残すこと。

その見極めも、設計する力だと私たちは考えています。

日本教育クリエイトが内製化を通じて目指しているのは、自分たちが使うシステムを深く理解し、長く育てていける開発組織です。

そのために、設計の判断と実装、その後の運用をつなげて考える姿勢を大切にしていきたいと思っています✨

自分が考えた仕組みが、現場でどう役立ったのか。
何が想定と違い、次にどう改善すべきなのか。

そこまで向き合う経験は、エンジニアとしての判断の幅を広げてくれるはずです。

「全体設計」という一言の中で、あなたは何に悩み、何を決めてきましたか。ぜひ、そのお話を聞かせてください😊