ある朝、在庫管理の小さな修正が請求書発行まで止めた話
月曜の朝9時、システム担当者は「在庫の表示単位を『個』から『箱』に変えてほしい」という現場からの依頼を受けて、ほんの数行のコードを書き換えた。テストも軽く済ませ、昼前にはリリースを完了させた。ところが午後2時、経理担当者から悲鳴のような電話が入る。「請求書が1枚も発行できません」。原因を探ると、在庫管理機能の修正が、まったく関係のないはずの請求書発行機能を巻き込んでシステム全体を止めていたことがわかった。結局その日は開発会社に緊急連絡し、システムを丸ごと再起動し、原因究明と切り戻し作業に追われて夜まで対応が続いた。現場からは「なぜ在庫の表示を変えただけで請求書が止まるのか」という当然の疑問が飛んだが、担当者もその場では明確に答えられなかった。
こうした「一部分の修正のはずが、全体を止めてしまう」というトラブルは、実は珍しいことではない。多くの中小企業の基幹システムが抱える構造的な問題であり、原因を理解しないまま同じ事故を繰り返している会社も少なくない。
なぜ1つの修正がシステム全体に影響してしまうのか
この現象には、システムの作られ方に由来する明確な理由が3つある。
1つ目は、すべての機能が1つの巨大なプログラムとして密接に絡み合っているという構造上の問題だ。在庫管理も請求書発行も、見た目は別々の画面や別々の業務に見えるが、内部ではひとつの大きなプログラムの中で、共通の部品や共通のデータを介してつながっていることが多い。ちょうど、1本の太い糸で編み上げたセーターの一部をほどこうとすると、思いがけず別の場所の編み目まで崩れてしまうのに似ている。見た目には独立しているはずの部分が、内部では切り離せないほど絡み合っているのだ。
2つ目は、一部分のテストのつもりが、実際にはシステム全体の再起動が必要になってしまうという運用上の問題だ。プログラムがひとつにまとまっている以上、どこか一箇所を書き換えて動作を確認するには、システム全体を一度止めて、全体を丸ごと立ち上げ直す必要がある。在庫管理の1機能だけを試したいだけなのに、請求書発行も、顧客管理も、すべてを巻き込んで再起動しなければならない。これが、修正のたびに業務全体を止めなければならない根本的な理由になっている。
3つ目は、担当者が変わると、どこにどう影響するか誰も把握できなくなるという属人化の問題だ。長年運用してきたシステムほど、内部のつながりは複雑に積み重なっている。最初に作った担当者であれば「この部分を触ると、あそこにも影響が出る」と経験的にわかっていたとしても、担当が引き継がれるたびにその知識は薄れていく。結果として、新しい担当者は影響範囲を正確に予測できないまま修正に踏み切ることになり、思わぬ箇所で不具合が表面化する。今回の請求書発行のトラブルも、まさにこのパターンだった。
この状態を放置するとどうなるか
こうした構造を放置したまま運用を続けると、会社にとって深刻な足かせになっていく。
まず、改修のたびに業務全体を止める必要が出てくる。小さな修正であっても、システム全体を再起動しなければならないため、営業時間中には手を出せず、深夜や休日にしか作業ができなくなる。これは開発コストの上昇にも直結する。
次に、新機能を追加するスピードが目に見えて落ちていく。新しい機能を1つ足すだけでも、既存のどこに影響するかを隅々まで確認しなければならず、確認作業そのものが開発期間の大半を占めるようになる。競合他社がスピーディに新サービスを展開する中、自社だけが身動きを取れなくなるという事態にもつながりかねない。
そして最終的には、システムに誰も手を出せなくなるという最悪の状態に行き着く。影響範囲が読めない、テストにも時間がかかる、担当者も入れ替わっている。こうした条件が重なると、開発会社も「修正すると何が起きるかわからない」という理由で改修を渋るようになり、経営者は身動きの取れないシステムを抱えたまま、事業の変化に対応できなくなってしまう。
モノリスとマイクロサービスとは何か、何が違うのか
この問題を理解する鍵になるのが、モノリスとマイクロサービスという2つの作り方の違いだ。どちらも聞き慣れない言葉かもしれないが、考え方自体はシンプルだ。
1つの大きな工場か、独立した専門工房の集まりか
モノリスとは、すべての機能を1つの大きなプログラムにまとめて作る方式のことを指す。これは、1つの巨大な工場の中に、在庫管理ライン、請求書発行ライン、顧客管理ラインをすべて詰め込んで、電源も配管も設備もすべて共有している状態に近い。どこか1つのラインを止めて修理しようとすると、工場全体の電源を落とさなければならない。効率よく一体で作れる反面、1箇所のトラブルが工場全体に波及しやすい。
一方、マイクロサービスとは、機能ごとに独立した小さなプログラムとして分けて作る方式だ。これは、在庫管理は在庫管理専門の工房、請求書発行は請求書発行専門の工房というように、それぞれが独立した建物と電源を持っている状態に近い。在庫管理の工房を一時的に閉めて改装しても、隣の請求書発行の工房は通常どおり稼働し続けられる。
影響範囲を機能単位に閉じ込められるという意味
この違いが実務にもたらす最大の価値は、影響範囲を機能単位に閉じ込められることにある。マイクロサービスの構成であれば、在庫管理の表示単位を変更する修正は、在庫管理の工房の中だけで完結する。請求書発行や顧客管理を巻き込むことはなく、修正のためにシステム全体を止める必要もない。冒頭のトラブルのような事態は、構造上そもそも起こりにくくなる。
開発コストと柔軟性のトレードオフ
ただし、マイクロサービスにも代償はある。工房を分けるということは、工房同士をつなぐ配送の仕組みや、それぞれの工房を個別に管理する体制が必要になるということでもある。小規模なシステムであれば、最初からモノリスで作った方がシンプルで低コストな場合も多い。どちらが優れているという単純な話ではなく、事業の規模や将来の変化のスピードに応じて選ぶべきものだと理解しておく必要がある。
発注時に確認すべきポイント
これから新規開発や大規模な作り直しを発注する場合、あるいは既存システムの改修を依頼する場合は、次の点を開発会社に確認しておきたい。
まず、機能ごとの独立性がどの程度確保される設計になっているかを尋ねる。すべてが1つのプログラムに一体化しているのか、それとも機能単位である程度切り離せる作りになっているのかは、初回の打ち合わせで確認できる。次に、1つの機能を修正した場合に、他のどの機能まで再起動や再テストが必要になるのかを具体的に説明してもらう。この質問に明確に答えられない場合は、影響範囲そのものが把握できていない可能性がある。さらに、将来的に機能を追加したり、一部だけを切り出して作り直したりする際の柔軟性についても、あらかじめ見通しを共有してもらうとよい。
現実的な進め方
ここまで読むと、今すぐすべてをマイクロサービスに作り替えなければならないと感じるかもしれないが、その必要はない。いきなり全体をマイクロサービス化しようとすると、かえって開発コストが膨らみ、移行作業自体が新たなトラブルの火種になりかねない。
現実的なのは、段階的な切り出しだ。まずは、今回のトラブルのように影響範囲が大きく、かつ改修頻度の高い機能から1つずつ独立させていく。たとえば請求書発行のように、他の業務への影響を絶対に避けたい機能から着手し、実際に切り離してみて運用が安定することを確認しながら、次の機能へと広げていく。この積み重ねによって、事業の成長に合わせてシステムの柔軟性を無理なく高めていくことができる。急いで全部を作り替えるのではなく、痛みを感じている場所から着実に手を入れていく姿勢が、結果的にもっとも確実な道になる。
壁を越えて働く人たちへ
システムのトラブルに追われる日々の中で、本当に向き合いたいのは目の前の業務であり、お客様であり、これから挑もうとしている新しい挑戦のはずだ。1つの修正におびえてシステムに手を出せなくなることは、事業を前に進めようとする人たちにとって、見えない壁になる。オルアナが目指すのは、その壁を一段ずつ取り払い、変化を恐れずに次の一手を打てる状態をつくることだ。システムは止まるためではなく、動き続けるために存在する。壁を越えて働く人たちの隣に、これからも立ち続けたい。