システム開発と連続の視点

　前回、『今こそ「連続」の視点から見てみよう』という題目で、「連続」に関して言及したので、今回と次回でコンピュータ・システムの「連続性」と関連する話をしてみようと思う。　コンピュータ・システムの連続性と言ってもいろんな視点がある。　「システムの操作性（ユーザー・インターフェイス）」や「システムの稼動」といった視点から「連続」を考えることもあろうが、今回は、「システム開発と連続の視点」とについて言及することにする。　これに関して、私の部署でシステム開発をしてくれている人たちの考え方に対して、最近思うことがあり、『考え方』を中心に話をすることにしたい。　また次回に、「システムを使い捨てることと、いつでも捨てられるための準備」について述べたい。

【前提】　今回及び次回の話の中でのコンピュータ・システムは、通常の企業活動で使用する、オーダーエントリなどの販売管理や在庫管理、倉庫管理、財務管理などの基幹系システムや営業などの業務報告、営業支援やデータウェアハウスなどの情報系システムなどの業務アプリケーション・ソフトのことである。　OSなどの基本ソフトウェアや開発言語や業務系システムを作るためのツールなどのことを言っているのではないことをお断りしておく。

【ユーザー vs. システム開発者】
　業務アプリケーションを使う側のユーザーはどういう人たちであろうか？
（1） 一般ユーザーは保守的です。　現在使っている仕組みに、自らを縛って仕事をしています。　比較するときは現在の仕組みだけです。
（2） 自分たちの直面する問題ばかりをクローズアップし、全体最適を考えません。
（3） 仕様を作るときには、あまり意見を出さず、実際使い始めると、あれもダメ、これも足りないと言い出します。
（4） 導入前は、通常自分たちの業務に終われていると言って、十分な議論やテストはやってもらえません。
（5） 要望とやろうとしていることと矛盾があることが多々あります。（例えば、彼らはリアル・タイム処理を望みながら、バッチ処理での運用をベースに考えて行動してしまうということです。）　そして、その矛盾を解決してくれと、頻繁なる仕様変更の要求がなされます。　　
（6） 良くなった/良くなるところはあまり言及してくれませんが、操作性を含め、現在と違うところ、悪くなるところに対して文句を言います。
と書くと、ユーザーが悪者で、システム開発者が良い者のようだが、それは全く違う。　ユーザーから見れば、システム開発者は、
(a) 訳のわからぬ専門用語を用い、開発者の趣味でシステムを作ってしまう。
(b) 開発者の出来る範囲でしか作らない。
(c) 具体的に理解しやすい現存のシステムの機能実現は出来ても、新たな要求事項はうまく実現できない。
(d) ユーザーの使い勝手なんか考えてくれない。
(e) 実際のビジネスやビジネス・プロセスを全く分かっていない。
(f) 導入時には、いつもバタバタ、不具合ばかり発生し、いつまでも不具合を直してくれない。
と思っているのである。
ある意味で、ユーザーも、システム開発者も同じ穴の貉（むじな）なのだ。
ユーザー（使う側）もシステム開発者（作る側）も、同じような発想・考え方でいることにより、互いに不平・不満が生じる。上記の不平・不満のもとになっている『考え方』のままならば、使う側と作る側の立場が入れ変わっても、結局同じことが起こるであろう。
不満のもとの『考え方』とは、まとめると、以下のようになろう。
1) 一方向からしか見ていない、偏った「視点」
2) たとえ連続した変化だとしても、「なだらかな変化」しかついていけないし、想定できない。（連続でも微分係数の絶対値が大きいものはあるが、微分係数の絶対値が非常に小さなものしか対応できないということだ。）
3) 双方での基本部分の捉え方において最初の少しのズレが、結果として大きな勘違いや誤解を生み出してしまう。　基本部分での最初のたった１度のズレが、時間が経るにつれ、絶対値で大きな距離の差となってしまう。（「あなたと私の言っていることは、言い方が違うだけで同じことですね。」と言われることは多いが、それが本当のことって少ないと、私は思っている。）

【「連続性」を考える三つのポイント】
　私は、この不平・不満のもとの考え方は、「連続性」を意識しないことに起因すると思っている。　後に、この点を「システム開発の考え方のポイント」として述べるが、システムで「連続性」を考えるには、「視点（point of view）」と「連携する・つなぐ（integrate & federate）」と「組み合せる・調整する・調和する・（coordinate）」の三つが重要だ。
「視点（point of view）」：　一つの視点でしか見ないと偏った判断しか出来ない。過去からの視点と将来からの視点、部分最適からの視点と全体最適の視点（Micro-viewとMacro-view）、「自分」からの視点と「相手」からの視点、モデルの中の人の視点とモデルの所有者の視点等々がある。連続を数学的に考えるときにも、「左側連続」と「右側連続」があるし、不連続にも第一種の不連続、第二種の不連続があり、それにより連続の概念が明確になる。　このように種々の視点から見るようにすることが、「連続」を意識することになる。
「連携する・つなぐ（integrate & federate）」：　これは、「連携する・つなぐ」ことにより、いろいろなものを、「連続」にしていこうという積極的な動きである。　私は、「連携する・つなぐ」を表わす英単語として、"integrate"と"federate"を良く使うが、この"integrate"と"federate"とを以下のFig.1とFig.2のように捉えている。　ともに重要な概念であるとは思うが、私としては、"federate"がより一層大切であると考えている。　
    情報は発生したところで、その情報を管理するべきで、基本的に、一つにまとめ（Integrate）なくても良いと思っている。もちろん一つにまとめたほうが良い場合もあるし、楽な場合もあろうが。　入口（Portal）は一つでも、実際のデータは分散DBで良いわけである（Location Transparency）。　OXFORD Advanced Learner's Dictionaryの"federate"の項の説明には" to unite under a central government or organization while keeping some local control"とある。そのイメージが、まさしくFig.2 である。　ユーザーにとっては、分散したデータベースをあたかも一つのデータベースとして連携されて（federate）いれば、意識せずにそのバーチャルデータベースにアクセスすることにより透過的に分散データベースにアクセスできるようになるわけである。
また、ビジネスをつなぐために、Business Application Functionalities〔BAF：私が、勝手に名づけた言葉だが、ビジネス・プロセスでの小さな機能単位のコンポーネンツのことで、Fig.2では、△、○、□などで示される。〕の"federation（連携）“が、安価で、簡単な方法〔たとえば、SMTPでのSimple XML Messagesのハンドリングで実現?〕で、出来ることが望まれる。
「組み合せる・調整する・調和する（coordinate）」：　皆が革新的な発明・発見が出来るわけでないし、それらを使う必要が常にあるわけではない。今存在する適切なソフトウェア、コンポーネンツや物や者（人間）をつなげたり、くっつけたりすることで、革新的なものではないかもしれないが、今までとは違う何かを生み出すことだって可能だと思う。　私を含めた普通の人は、コーディネートすることで、something newを作れる、見つけられるのである。

【システム開発の『考え方』のポイント】
　「連続性」の概念に基づいたシステム開発とはどのような『考え方』をするべきなのかを以下に挙げる。
ある人は、具体性がないと言われるかもしれないし、またある人は当然のことと言われるかもしれない。何を精神論をと言われるかもしれないが、私はまず、このような『考え方』が、すべてのスタートと考える。　確かに技術や能力がなければならないのは当然であるが、逆に技術や能力があったとしても、『考え方』が間違っていたり、方向が違っていれば、ユーザーが望むシステムは作れない。
(1) "As is"（現状）と"To be"（あるべき姿）をつなげる
　まず、「現状」と「あるべき姿」のギャップをきちんと見極め、そのギャップをどう埋めるか考える。　原理原則に則って何が正しいかを考えていけば、必ずヒントが得られる。　しかし、現状とあるべき姿においてギャップが大きければ、いきなりそのギャップを埋めようとしても無理があるかもしれない。そのときは、公正・公平といういたって当然の基準から外れないようにしながら（簡単そうで、非常に難しいのだが）、漸次的にあるべき姿へつなげていくようにする。
(2) 私たちは何をしようとしているのか？
　今１度の角度の違いが、時間に経過にしたがって、絶対的な距離の差がドンドン大きく広がっていく。当初明確だと思っていたことも、時間が経れば、不明確になったり、あやふやになったりするものだ。だから、自分たちが何を目指しているのかを何度も確認しながら、絶えず目標に対して補正を行なっていく。　
(3) 過去および過去の単純な延長線上の仕組みの中でしか考えられない、または考えようとしない姿勢が前進を妨げることを認識すべきである
　確かに過去⇒現在⇒未来という時間の流れには違いないが、過去からだけの視点では、乗り越えられない場合がある。　バッチ・ベースでは、非常に評判の良いEDIのソフトウェアがあった。しかし、それはバッチ・ベースのものでリアル･タイムのものではなかったので、将来的には大きな変更をしていなければならなかったが、過去の売上実績が非常に良かったし、少しの手直しでその場は凌げていた。それで、どうしても大きな変更に踏み切れなかった。　その結果、そのソフトウェアは時代に置いていかれた。　過去が良ければ良いほど、次の手が遅れてしまうものだ。　
(4) 「今ある技術や近い将来出てくる技術に立脚したシステムの視点」と「過去のシステムの視点」との相違を常に認識する
　技術はImproveする。あるときは、断絶しているように見えたり、全く違う視点からの技術がでてくることもある。　また、集中化（centralization）と分散化（decentralization）のように、振り子のごとく往ったり戻ったりすることはあり得るが、過去にだけ縛られず、将来を見据えながら、現在使用しているシステムとの整合性を確保していくために、相違を常に認識するべきである。　片側連続性（この場合、左側〔過去〕連続で、右側〔未来〕連続でない）の不連続では、ユーザーにとって使いにくいものとなってしまう。　
(5) 今、どの視点またはどのシステムから見ているのかを常に意識する
　"Macro-view"（マクロの視点、全体から見る目）と"Micro-view"（ミクロの視点、部分から見る目）の両方の見方が必要だが、我々のビジネスにおいては、多種のシステムを使っており、相互に関連しているため、今どこのシステムから見ているかを明確するかが大切である。
(6) ビジネスをプロセスとして捉える
　ビジネス・プロセスとは、たとえば「・・・受注請け⇒オーダー・エントリ⇒納期回答〔在庫確認、在庫がないなら製造部門からの回答をもとに納期回答を作成・・・〕⇒出荷指示⇒出荷・・・」などの業務の一連の流れである。つまり、業務の小さな単位（Business Application Functionaliteies〔BAF〕）が、機能的につながったものがビジネス・プロセスで、そのつながったものが、また別のプロセスとつながっていく入れ子構造を持っているものである。　　『ビジネスをプロセスとして捉える』とは、点で捉えるのでなく、線、面で捉えるということである。『面』というのは、分岐があり、関連部署が複数同時に対応することもあるため、一次元の表示ならないためである。　上の例で、単純に納期回答の部分のお客様とのやり取りだけの仕組みを考えるのではなく、全体の中でその部分がどういう位置付けであり、どのような役目を果たしているかを考慮し、前後の機能との関係を流れの中で考えることである。　また、プロセスのうちで、繰り返す一連の作業や動作があれば、そのプロセスの自動化（Streamline & Automate Processes）を考えてみるのも一つの大切なことである。ただし、自動化するということは、プロセスを固定化することにもなり、一度自動化したから「良し」と考えるのでなく、適宜見直しをかけていくことも必要である。
(7) システムを「つなぐ」ということ
　上記(6)でも述べたビジネスにおける機能の小さな単位（Business Application Functionaliteies〔BAF〕）を、出来るだけ軽い仕組みでつなぎ合わせ、一つのビジネス・プロセスにし、そのビジネス・プロセスをもう一段大きなビジネス・プロセスにしていく。つまりBAFをつなげていき、一つの仕組みを作っていくことが、ビジネスのシステム化と私は考える。
　① Locationについて　－　BAFF（Business Application Functionalities Federation）
　　BAFをつなげていくとき、「プログラムやデータは、何処にあってもいい（Location Transparency）」を如何に実現していくかが、システム開発者の腕の見せ所ではないか。そのためにも、出来るだけ軽い仕様の仕組みでつなぎたい。
　② Private process とPublic processについて
　　また、私たちのBuyerにしても、Supplierにしても、Logistics Providerにしても、各社各様の仕組み、プロセスを持っている、それに　一々あわせていくと、恐ろしい数の組み合わせに対応する必要がでてくるし、そのメンテナンスを考えるとぞっとする。そのため、社内のプロセスであるPrivate processと社外のプロセスであるPublic processを切り離し、その間にハブとなる変換装置を置くこととXMLを使うことで、One-to-Many（１対多）の仕組みを築くことを進めていきたい。これは、社内社外だけでなく、社内の自部門と他部門の間でも有効な考えだと思う。
　③ 時間について
　　開発しているシステムがたとえリアル・タイム・ベースであっても、つなぐ相手がバッチ・ベースならリアル・タイム連携はできないのは当然のこと。　私は、時間をReal-time（リアル・タイム）、Quasi-ｒealtime（準リアル・タイム）、Scheduled Batch（バッチ）の三つに分けて考えている。
　　ⅰ）Real-time:　リクエストに対して同期した処理が実行され、その結果が返される。この間一つのセッションと見なされる。
　　ⅱ）Quasi-realtime:　リクエストに対しては即時処理がなされるが、処理自体は非同期で、イベント・ドリブン的な処理。
　　ⅲ）Shceduled Batch:　時間起動等で、定期的およびそれに準じた方法で処理が実行される非同期の処理。
該当システムでは、どの処理形態が有効か、相手の仕組みとも関連させて考えるわけだが、今後は、ⅱ）のAsyncronous（非同期）な仕組みが、非常に重要になってくると思う。

　以上のような「連続性」を意識した考え方で、「冷静なる頭脳（cool heads）」で仕様を作った後は、なんとしてでも、皆のために遣り遂げるんだという「暖かい心（warm hearts）」と「強い思い、執着心」とが必要なのである。〔「冷静なる頭脳と暖かい心（with cool heads but warm hearts）」は前回の【相反するものを併せ持つこととバランス感覚】の項を
参照のこと〕　（もちろん、技術、能力は絶対に必要だ。ただ、あまりにも「思い」が弱く、ちょっとした困難の前に、諦めが早い人たちが多いので、最近寂しく感じている）

　次回は、以前から社内外で話してきていた「システムを使い捨てることと、いつでも捨てられるための準備」について私の考え方を、『システムそのものの』および『データ』の連続性を絡めて、「システムを使い捨てること」の意味と「捨てるため準備」とは何かについて述べることにする。