「システムを捨てること」と、「いつでも捨てられるための準備」
前回予告したように、今回は「システムを捨てることと、いつでも捨てられるための準備」ということに関して、私の意見を述べてみようと思う。
私が、この「システムを捨てることと、いつでも捨てられるための準備」ということを、意識し始めたのは、2000年ごろSCMに取り組み、B2Bの仕組みの開発を真剣にやり始めた頃である。
各社には各様のビジネス・プロセス、仕組みが存在する。〔Each customer has each way(each system).〕１対１で対応する仕組みを一々作ることはきりがないし、ビジネスはどんどん変化する。その変化に伴って、ビジネス・プロセス、仕組みも変化し、メンテナンスがどんどん増える。【注】 将来を考え、再利用性、拡張性を考えると、開発が遅れるし、複雑になる。そうであるなら、割り切って、短期間の使用でコストを上回るメリットを出し、数ヶ月でペイし、いつでも今のシステムを捨てられる状態にし、必要に応じて新たにシステムを作る前提の方が、ライフサイクルを長くしようとするシステム開発より、健全なのではないかと思ったわけである。
【前提】前回と同様、話の中でのコンピュータ・システムおよびシステムは、業務アプリケーション・ソフトのことである。 OSなどの基本ソフトウェアや開発言語や業務系システムを作るためのツールなどのことを言っているのではないことをお断りしておく。
【注】経済学者マルサス 〔 Malthus, T. Robert : 1776-1834〕は、『人口論』で、「人口は、制限されなければ幾何級数的に増大し、食糧は算術級数的にしか増大しない」（"Population, when unchecked, increases in a geometrical ratio. Subsistence increases only in an arithmetical ratio.” An Essay on the Principle of Population, 1798）と述べているが、
私は、「システムは算術級数的にしか増大しないとしても、システム・メンテナンスは、制限されなければ幾何級数的に増大する」（“If System increases only in an arithmetical ratio, System Maintenance, when unchecked, increases in a geometrical ratio.”）と思っている。
0) ビジネスの連続性（継続性）
15世紀中頃から17世紀中頃まで続いた大航海時代には、一回の航海毎に会社が作られ、航海が終了した時点で清算されていた。しかし、現在の事業活動は基本的には継続的（連続的）に行なうことを前提としている。つまり、going concern（ゴーイングコンサーン）としての企業活動が前提となる。
ビジネス自体が複雑になり、各プロセスに迅速さ、正確さが求められる現在は、良きにつけ、悪しきにつけ、コンピュータ・システムが必要となっている。私たちは、ビジネスを継続するために、種々のコンピュータ・システムを使わざるを得ないのだ。
システムが途切れてしまうことにより、ビジネスが続かなくなるのは言語道断である。システムが途切れるとは、一つにユーザーのミスやシステムの故障や障害によりシステム自体が止まったり、データの不整合が発生することである。もう一つが、システムが現実のビジネス・プロセスに合わず（変化に適応できず）、大きな機会費用を発生させ、市場における優位性を貶める結果となるものである。
最近、前者の問題がメディアで報道されているが、以下の問題に起因していると思われる。
① ビジネスの継続性のためのシステムを止めない技術は、ハードウェア、ソフトウェアの進歩で大きく改善されてきているものの、いろいろな制約（金銭面の制約、過去とのしがらみ等々）で実現できていない
② 古い仕組み（システム）を捨てられず、メンテナンスが難しいという問題は、まさしく今回のテーマと関係する
③ ビジネスの継続性に関する考え方は業種や会社のポリシーに依存する
後者は、直接社会に問題が現れないため、メディア等では取り上げられないが、本来のシステム導入の意義を否定するもので、大きな問題である。前者、後者とも、今回のテーマに関連する部分が多いと思われる。
1)システムそのものの連続性とデータの連続性
システム（業務アプリケーション・ソフト）は、ビジネス・プロセスに対応するものである。上で述べたように、今日の事業活動（ビジネス）は、継続を前提としているが、ビジネス環境は日々変わるわけだから、それに合うシステムも日々ビジネスの変化に対して出来る限り適応すべきである。しかし、システム化とは、ビジネス・プロセスの効率化、自動化（Streamline and Automation of Business Processes）を行なうことにより、逆に固定化してしまい、Flexibilityがなくなり、競争力を落としてしまう側面を常に持っていると言わざるを得ない。現時点では、システムが自分自身を周りの環境に適切に合わせていくようなSFのような仕組みはまだ実現できていない（ゲーデルの「不完全性定理」は、今日の有限な命令と有限なデータで動く論理マシンであるコンピュータには、限界があると言っていると思うが、この話は別途行ないたい）ので、システム自体が、プロセスを固定化することは仕方のないことである。ビジネス環境が、めまぐるしく変われば変わるほど、システムの陳腐が進み、ビジネスの連続性の阻害要因になりかねない。運用である程度はFlexibilityを補強できるかもしれないが、それにも限界があるし、運用に頼ると逆に運用ミスによる問題を起こしかねない。
では、一方データはどうか？
今までの経験で（帰納的すぎるか？）データの方が、コンピュータ・システムより、はるかに長持ちすると思われる。プロセスで必要なデータは、プロセス自体より早く変化しないのである。たとえば、B2Bにおける確定注文データを考えてみよう。確かに、EDIFACT、JEITAやRosettaNetのメッセージにおいては非常に多くの項目が提示されているが、要するに必要なのは、品目、納期、数量、単価、送付先、決済先ぐらいである。フォーキャストも然りである。確かにいろいろな付加情報などはあろうが、必須情報は、どこの会社も似ているが、ビジネス・プロセスは各社各様である。必要なデータはそんなにすぐに変わるものではない。（実際、私どもでは、受注、売上等々のDBのフィールドは変更することなく、2000年以前から分納ベースで持ち続けられている）基本的に必要な情報は決まっているほうが圧倒的に多い。また、人間は、時系列分析をしたがることもあり、データの連続性を必要とする場合が多い。
もちろん、データの連続性が必要だと言っても、
ⅰ）データの構造が変わる場合がある：過去のデータと現在のデータの連続性が、変化要因のために保たれなくなったり、データのそのものの定義の変化する場合がある。 （大学時代のアルバイトで、社会主義国のマクロ経済分析したことがあるが、当時の社会主義国の統計データは、定義がころころ変わり、データの連続性がなかったケースも多く、分析するのに大変だった。）
ⅱ）カテゴリーが変わる場合がある
ⅲ）分析したいが、過去にはデータ系列がない
という場合もあり得るし、データの連続性を維持できない場合があることは事実であろう。しかし、データの連続性を維持できないならば、そういうデータを持っていても、現実役立たないと割り切って、使える範囲で使うとすべきなのだ。
データはプロセス（システム）より、連続性（普遍性）はあるし、データの連続性は多くの場合望まれることから、データの定義の明確化と標準化が必要である。それに、分類（カテゴリー）が変わりえることから、可能限り最小単位のデータとして蓄積することが必要と考えている。そうすることにより、システムとデータを分離することができる。良いコンセプトとインターフェイスの連続性はシステムにとって必要だが、システム自体の連続性は不要であるので、「システムを捨てる」ことは、可能なわけである。（ちょっと議論が横着かもしれないが…）
2) システムを捨てるということ
私が言う「システムを捨てる」ということは、既存のシステムにおいて、単純にいらないものを捨てようというものではない。「要らないシステムを捨てて…」というような捨て方でなく、開発当初から早期に捨てるつもりなのである。 もしそれが、たまたまビジネスの変化が遅く、当初設定した期間より長く使えるものであれば、そのまま当初の予定より長く使うこともありうるであろう（その分だけメリットは丸々享受するはずだが）が、いつまでも使い続けるつもりはない。近いうちにシステム自体を捨てるのである。もちろん、システム・コンセプトやアイディアの中で、良いものは、継続（連続）されるべきである。
【システムを捨てるメリット】
システム（ソフトウェア）は、物（ハードウェア）を捨てるわけではないので、ゴミにならない。
■ 将来を考えすぎた再利用性、拡張性や過度のモデル化による時間を削減できる
■ 無駄なコスト（膨大なドキュメント類、メンバー間の引継ぎや仕様の理解に要する時間、ソースの管理等）の削減
■ 過去の制約（しがらみ）から解き放たれる結果、開発期間が短縮される
■ 新しい技術を取り込める：過去の仕組みを捨てるわけであるから、必要時応じて新しい技術も使える可能性が大きい
■ ユーザー、お客様の要望の変化に対応できやすい
■ プロセスの固定化を防ぎやすい：ソフトウェアのライフサイクルを短くすることと、変化の対応した新たな仕組みを入れることによって、固定化を防ぎ、Flexibilityをあげられる。
開発当初から、早期にシステムを捨てるつもりでシステムを作るという発想の転換で、ユーザー（B2Bの場合はパートナーをもユーザーとなる）、開発者双方に大きなメリットが生まれるわけである。
3) いつでも捨てられる準備をする
しかし、システムは使い捨てるんだから、どんな考え方で作ってもいいとか、どんなシステムでも良いというわけではない。
私は、以下に示す「いつでもシステムを捨てられる準備をする」ことが、「システムを捨てる」ことの前提と考えている。
□ いつでも捨てられるように、すぐにメリットが出るような仕組みでなくてはならない。つまり、すばやく作って（"3ヶ月ルール"、"100-day rule"として、BAF単位を三ヶ月で作り、稼動させることを目標にする）、出来るだけ早くコストを回収し、メリットを出すことを心がける。
少し前の本だが、シスコシステムズの関係者が書いた本で『ネット・レディ －インターネット経済における成功戦略―』（ソフトバンクパブリッシング株式会社）〔原本："Net Ready" by Amir Harman and John Sifonis with John Kardor〕
のP.18 （翻訳版）に以下のように書かれている。
『・短期間で結果を出す：eビジネスプロジェクトはすべて、3～6人の担当で3～6ヶ月以内に完了すべきであり、そうでなければ別のことをしたほうがよい。つまり、小さく始めよ、ということである（だが、重要性が低いことをしろというのではない）。効果が大きく、すばやく達成できることにまず集中する。長期プロジェクトは、目標が測りやすい短期プロジェクトに分割する。仕事を進めながら検証していく･･･』
□ いつでも捨てられるということは、常に次のシステムの準備ができていることが必要、いつでも次に取り掛かれるように技術的な準備・構想を練っておくことが必要
今のシステムを捨てるということは、次のシステムをスムーズにリリースしていく必要があるわけだ。次の仕組みを構築するために、次に利用する技術、製品を常に捜し求め、勉強していくことが必要。もちろん、新しいものが、常にいいものではない。既にあるもの、古いものの中でもいいものがある。捨てると同時に、既存のツール、過去のシステム、コードや先人の考えやソースから「拾う」ことも大いに必要だ。
□ システム開発の『考え方』のポイントを念頭に置く（前回のブログ参照）
□ 軽いシンプルな仕組みづくりを心がける ⇒BAFをつなぐという発想
確かに、基幹システム（Back-end System）に近ければ、近いほど捨てにくいと思われる。そこで、まず、①基幹の周りと②本当の基幹に分けて考えると、①はまったく、この発想でよいであろう。②は、基幹システム自体を一つの仕組みと考えず、いくつかのBusiness Application Functionalities（BAF：私が、勝手に名づけた言葉だが、ビジネス・プロセスでの小さな機能単位のコンポーネンツのこと⇒前回を参照）に分ければ、①と同じように考えて対応できると思う。
□ 次につながる仕組みでなければならない
失敗を認めるわけではないが、たとえ失敗しても、明日につながる失敗、次のシステムに繋がるシステムであるべきだ。
□ 自分の考え・ポリシーを明確にすること
① 自分の考え・ポリシーをしっかり持つことによって、やろうとすることにおいて、ふらつかなくなる。②外に向かって、きちんとした考えを述べていると、周りの人が、いろいろ意見やアイディアを与えてくれる（助けてもくれる）
現在、上記のことを、全てのシステムで行なえているわけではないが、既にいくつかのシステムで実践している。その結果はここでは示すことはできないが、きわめて高い効果を出せている。発想の転換が大きな効果を挙げる一例であろう。
最後に課題を述べておく。
1) 基本的に設計から導入までを3ヶ月（大きいものは最長6ヶ月）とするようにしているが、コスト回収期間の設定やメリットの定量化をもう少し厳密にする必要がある。（ただ、このあたりをあまり定量化しても、実際ユーザーが入れてよかったと思ってくれるシステムであればそれでいいのかもしれないが）
2) 捨てるべきタイミングの判断方法の目安が必要である。
3) BAF（Business Application Functionalities）の粒度の設定方法の明確化
4) システム連携が多くなるが、そのときにどのようにQuasi-realtimeを図っていくか（全社の基幹システムとの連携では、Schedule Batchにならざるを得ない場合が、現状ある）
いろいろご批判もあろうが、私は、前回述べた「『連続性』の概念に基づいたシステム開発」と「システムを捨てることと、いつでも捨てられるための準備」をベースに、システム開発を考えている。