このタイトルの話は非常に重たい話なので、1回のコラムでは書ききれません。折に触れて少しずつ紹介することにしますが、「新サービス」とは社内システムやお客さま向けのシステム全てを総称します。何もシステムが無い時には「これをやろう」と決心さえすれば、後はお金と時間の問題で新しいサービスはいずれ必ず立ち上がります。それが仮に有る程度成功すると、今度は少し欲張りになってしまい、「では次はこれもやろう」と意気込んで機能拡張なり、関係するサービスを立ち上げることでしょう。

この状態で何年か投資してゆくと、おそらく数個のシステムが動いている状態になります。社内向けであろうとも社外向けであろうとも、いずれも何らかのデータベースを持っていますから、相互に何かの連携機能があるのであれば、当然それらは相互依存関係になります。例えば社外向けなのであれば、顧客データベースをどこかに持つことが多いので、複数のシステムを立てた場合はどれか一つのシステムの顧客データベースを共有することになります。一つのサービスを立ち上げるたびに顧客データベースとの連携機能が増え、もしかしたら顧客データベースに新たな情報種別が追加され、その上に更なる機能が実装される…。しかし作っている一方の段階では特にこれには問題ありません。合理的に作ろうとすればこうなることははっきりしています。ここまでは実はとてもラクなことなので、比較的容易に出来てしまいます。問題はここからです。

さて、あるとき「AとBとCのシステムを運営してきたが、需要がマッチしないので、2番目に立ち上げたBのシステムをやめよう」という話が持ち上がったとします。ビジネスオーナーは当初「Bの機能を削除するだけで良い」と思い込んでいるでしょう。時として技術者から、思いもよらぬ「えっ？Bだけやめるんですか？それはちょっと難しいです…」という声が返ってくることがあるのです。

それは、Bの機能はAの機能の上に作られており、かつ、Cの機能の基礎になっているからです。この階層構造について、ビジネスオーナーは把握していないことが多く、技術者のみが安価に合理的に作るためのアイディアとして案出した構造だったりすることが多いので、「新規構築するときは全く問題にならないが、改造したりやめようとしたりすると途端に問題として顕在化する」ことがあるのです。

建物をイメージしていただければわかりやすいと思います。

最初に平屋を建てた。
その上に2Fを増築した。
更にその上に3F部分を増築した。
でも、2F部分が不要になったので取り去ろう思った。

という、無理難題と同じなのです。建物なのであれば目に見えますし、図面で提示されれば素人でも「2Fを取り去ることはできない」と理解できます。しかし、ソフトウェアの集合体であるシステムの場合、それらの関係性を素人が理解できる図面は基本的には存在しません。大まかな構造は描くことは可能ですが、細かな機能連携まで素人に分かりやすく表すことは極めて困難なのです。

Bの機能を簡単に削るということはできないことを、後になって気がついて後悔する…。このようなことは比較的簡単に起きてしまいます。それを避ける方法は、全体構想を最初の段階で明確化しておくしかありません。これはこれでハードルが高いことではありますが。。。

新しく作るのは簡単。でも部分撤退は難しい。こんなことがシステムの場合は結構起こりえること、それを可能な限り避ける為には、グランドデザインを初期の段階できちんと作るべきであることをご理解いただければと思います。

実は他にも「やめる際のハードル」があります。それは「使う側の激変」です。これは回を改めてご説明します。