SIersに騙されないために、ITを学ぶ －Joan Robinsonから学ぶ－
私の部署にも新入社員が入ってきた。その際に話をしたことや、私の考えているシステム開発方針や考え方を整理しておくことにする。
【私のシステム開発方針 ―4つのキーワードー 】
まず、私のシステム開発・構築の方針を述べてみたい。Velocity, Visibility, Business Mind, Diversityの4つのキーワードでもって説明する。
(1) Velocity（速力）
ビジネスにおいては、当然スピードが大事である。我々システム部門がビジネスをサポートするには、自分たちの所属する部門のビジネスの向かう方向に合ったものを、タイミングよく、素早くリリースしなければならない。いくら良いものでも、タイミングが悪ければ、効果も落ちるものであるし、方向性が異なれば、意味のないものにもなりかねない。そういう意味で、Velocity（注１）（速力）が大切なのである。また、『「システムを捨てること」と、「いつでも捨てられるための準備」』でも述べたように、 開発対象を出来るだけ小さな機能単位のコンポーネンツ〔Business Application Functionality：BAF〕に分けて、素早くシステムを開発し、出来るだけ早くそのコストを回収できるようにする。そして、そのシステムをいつでも捨てられるようにするためにも、開発スピードを上げる必要がある。 実は、逆に開発のスピードを上げるためにも、ⅰ）過去の柵（しがらみ）からの解放、ⅱ）過去のドキュメントの解読や開発の引継ぎのための無駄な連絡（コミュニケーション）からの解放、ⅲ）その時点の最善の手法や最良の技術の導入 を考えて、「システムを捨てること」を前提としたいわけである。つまり、早く開発するためにも最初からシステムを捨てる前提で作るべきだし、システムを捨てる前提で作ることによって、早く開発できると考えられる。もちろん継続すべきコンセプトやインターフェイスは継承すれば良いわけだ。（注２）
（注１）Velocityを英英辞典（Oxford Advanced Learner’s Dictionary）で引くと、1.(technical) the speed of sth in a particular direction 2.(formal) high speedと出ている。「方向性を持った高速」とでも言えば良いのであろう。
（注２）このように言うと、『大きい会社はそのように出来るが中小企業では難しい』とか、『基幹システムの周りの小さな仕組みはそうできるが、基幹システム自体は無理だ』と言われるかもしれない。しかし、それはまったく違う。規模が小さな組織のほうがこのような考えをするほうが有利（必要なところからの導入も出来るし、コスト対効果も出る。外部に作ってもらうにしても、制約がなく自由度が高くなる分コストが抑えられる等々）だし、基幹システムでも、その中を小さな塊〔Business Application Functionalities〕に分け、Building Blocksのように考えれば、まったく同じように考えられる。要は発想の転換が出来るかどうかということである。
(2) Visibility（可視性）
私は、開発するシステムにおいてVisibilityの視点が非常に大切だと常日頃思っている。
つまり、「『見られること』と『見えること』 －可視性（Visibility）の意味－」において述べたように、Visibilityは
1) 『見られること』により、自分を美しくしよう／物、場所をきれいにしようとする側面（襟を正そうとする）⇒『見られる効果』/Observationによる効果
2) 『見えること』により、考え方・姿勢（mind-set）を前向きに変える側面⇒『見える効果』/Perceptionによる効果）
の二つの側面を持っており（注３）、この側面を大いに活用するための仕組みをユーザーに提供したいと思っている。
単にシステムが提供する解をもとに、人間が動きさえすれば良いという考え（「指示する」とか「与える」とかや、『要求は「存在」するものでなく、開発するものである』とかいう考え）は、人間の可能性をある意味で否定しているように感じてならない。（注４） ここでいう可視性（Visibility）は、人間の自主的な（能動的な）、積極的な側面を反映したものである。決して指示された、与えられたという受動的な側面ではない。そのために、一つの画面でまず全体の状況が掴め、その画面から詳細情報へリンクできるようなOne-view Managementが可能なユーザー・インターフェイスを提供し、人間に判断してもらいやすい情報を提供することが大切と思うし、我々システム部門は、そのようなシステムを提供するべきなのである。
開発自体の可視性（Visibility）も大切なことであるが、私の言う可視性は、ユーザーに可視性を提供することが第一義である。
（注３）Visibility = Observation + Perception
Observation makes facts clear and obvious.
Perception derives new information from observed facts.
"Visibility" and "Velocity" by System Federation/Integration can bring us "Value".
（注４）Perceptionによる効果（見える効果）は、Observationによる効果（見られる効果）より、一層人間の自主性や前向きさに依存するものであり、ある意味高度なものあるが、その効果はより大きなものとなりえるし、そこが人間の創造性の大切な部分だと思う。
(3) Business Mind（ビジネス・マインド）
私は、このビジネス・マインドに関して、二つの意味を込めている。一つは、我々はビジネスをしているわけだから、具体的で明確な結果（Concrete & Tangible result）を出すような仕組み（システム）を、我々システム部門は提供しなくてはならないことを常に意識して、システムを開発する姿勢を持つこと。もう一つは、ビジネスをプロセスで捉える（ビジネス・プロセス思考）ようにすることである。
ⅰ）具体的な明確な結果を出す
技術を優先するのでなく、そのシステムを使ったことによる効果を優先する。古い技術でも組み合わせにより面白いことが出来るなら、それも良し。もちろん、新しい技術を使って効果が出るなら、大いに使えば良いのは当然である。見栄えより、効果。如何にビジネスにおいて有用な情報を提供できるかが肝心である。有用な情報とは、先ほど可視性（Visibility）で述べたような情報のことである。
システム屋の自己満足だけでなく、「このシステムでなんぼ効果が出るのか」、「このシステムで、何が変わり、どうビジネスおよびビジネス・プロセスを変えることが出来るのか」を明確に意識することが大切なのである。（注５）
（注５）個人的には（Privateでは）、「『役立つ』とはなんだろうか？」、「遊び心の大切さ」、「実学だけで良いのか？」ということを考えている。しかし、ビジネスにおいては、上記のような視点は必要であり、ビジネスをサポートするシステム部門としても、常に「具体的で明確な結果」を出すシステムを作るんだという意識を持つことが大切である。次の項の「ビジネス・プロセス指向」も参照のこと。
ⅱ）ビジネス・プロセス指向（Business Process Oriented）
ビジネス・プロセスの話をする前に、プロセス自体の話を少ししてみる。昔、私は、よく親父から次のように言われたものだった。『お前は、始点と終点（ゴール）だけを考えていて、結果しか見ない。プロセスというものを見ようとない。お前は、結果の裏にある苦労やつらいプロセスを見ようとしないし、プロセスを楽しむこともしない。』と。
James Allenも“As a Man Thinketh”の本なかで（“Visions and Ideals”章において）次のような言っている。
They do not know the darkness and the heartaches; they only see the light and joy, and call it “luck;” do not see the long and arduous journey, but only behold the pleasant goal, and call it “good fortune;” do not understand the process, but only perceive the result, and call it “chance.” （注６）
（注６）〔慧根訳〕
彼ら（浅はかな人、無知な人、怠け心を持った人）は、成功の裏にある暗闇や心痛の部分を知りません。彼らは成功の光と喜びの部分しか見ないのです。光の部分だけを見て、それを幸運と呼びます。長くつらい道程を見ようとしないのです。心地よいゴールだけを見て、それを「幸運」と呼び、その裏にあるプロセスを理解しない。結果だけを見て、「幸運」と言うのです。（下線は慧根がつけた）
物事は、点で考えるのでなく、線・面で考えると同時に、流れの中で、いろいろな視点から考えるべきなのだ。実際のビジネスの限らず、生きていく上では、結果だけを追い求めるのではなく、プロセスを重視することが大切なのである。
ビジネス・プロセスは、組織やその利害関係者に対して付加価値を生み出すFunctionalitiesの集まりである。それぞれのFunctionalityがつながって（Federation & Integration）、価値を生み出していく一連の流れをビジネス・プロセスというと私は考えている。『システム開発と連続の視点』にも述べたが、今見ている箇所が全体の中でどういう位置付けであり、どのような役目を果たしているかを考慮し、前後の機能との関連を流れの中で考えることが重要であるということだ。プロセスの中で、繰り返す一連の作業や動作を自動化することも大切だが、自動化は『プロセスの固定化』にもつながり、適宜プロセスの見直しを行ない、硬直化しないようにしていくことも必要となる。
(4) Diversity （多様性）
私は、システム開発において、多様性（Diversity）を考えることは、非常に重要なことであり、多様性を認め、そのことをどうシステムに生かしていくかを常日頃から考える癖をつけることが、システムに関わる者にとって大切だと思っている。
多様性に関して、作家の鈴木光司が、「らせん」で以下のように書いているが、多様性の必要性を旨く表現している。
『多種多様なDNAが、山村貞子というひとつのDNAに収斂し、一本化していくこと、･･･、果たしてこれが進化といえるのかどうか。だが、考えてみれば、その点にこそ弱さがある。多様性があるからこそ、ペストに感染して死ぬ者もいれば、生き延びる者もいる。地球が氷河で覆われたとしても、イヌイットなら生き延びるかもしれない。それもまた人種の多様性だ。しかし、多様性がなければ、ほんのちょっとしたきっかけで種全体が滅んでしまう可能性がある。もし仮に、山村貞子が免疫系統に欠陥を持っているとすれば、その欠陥は全個体に継続され、ちょっとした風邪程度で大打撃を被ることになる。…』
（鈴木光司 「らせん」 角川ホラー文庫 P.394-395 から抜粋）
ⅰ）顧客はそれぞれのやり方がある（Each customer has each way.）
ビジネスのやり方は、各社各様である。各社には各社の文化、ビジネス・プロセス、システム・ポリシー等々があるし、過去からシステム化を進めていればいるほど、他社との違いも大きいものだ。特にSupplier側は、基本的にBuyerの仕組みを尊重せざるをえない。それらの多様性を認めるとして、一つ一つの顧客に合わせた一対一の仕組みを作ることはコストが掛かるが、メンテナンスにはより膨大なコストが掛かることになる。
そこで、顧客の多様性を認めつつ、Public ProcessとPrivate Processを分けて、内部の仕組みとXMLやMapping技術等を用いて、Functionalitiesをつなげる視点でシステムを構築する必要がある。各社の多様性を吸収する仕組みを如何に構築していくかが我々システム部門の腕の見せ所になるわけだ。
ⅱ）多種多様な技術をどう選択していくか
先ほどの鈴木光司の文章の「多様性がなければ、ほんのちょっとしたきっかけで種全体が滅んでしまう可能性がある」という言葉は、示唆深いものだ。たとえ現時点で優勢な技術（優性遺伝）でもって、全てを構築していたとして、環境変化によって、その優勢な技術が使えなくなった場合、直ぐにリカバリーが出来ないことになる。今まで劣勢の技術（劣性遺伝）と思っていたものが、逆に環境変化に対応できるケースだってありえるわけだ。例えば、Microsoftの技術で持って全てを構築すれば、いろいろ便利（技術習得も一つの技術の習得ということで、有利であろう）で、シームレスに対応できるかもしれないが、その技術は永遠でないかもしれないし、他の技術をベースにして構築している会社と連携しづらいかもしれない。（私は、Microsoftが別に嫌いでもないし、実際いくつもの製品も使っている。） つまり、「一つの技術に依存するもろさ」を自覚しようということだ。
また、流行ばかり追っかけず（三文字熟語やまやかしの流行技術に騙されず）、選択の自由を必ず残す（自由度の高いことは良いことだ！）と同時に、事の本質を見抜くようことを心がけよう。
（Do not follow the fashion, should have options and see through the essence of the matter.）
【両極端のものを併せ持つこととバランス感覚】
私は、新人が入ってくるときに、いつも「両極端のものを併せ持つ」ということの大切さの話をしている。
つまり、人間どうしても一つの偏った視点からのみ考える癖があるからである。全く違う視点からものを捉え
直すことの重要性を、私も含めて常に意識して事にあたるべきなのである。
この話をするときは、イギリスの経済学者のマーシャル（A. Marshall）”with cool heads but warm hearts” や アメリカの作家のフィッツジェランド（F, Scott Fitzgerald）の「第一級の知性とは、同時に二つの相反する考えを持ちながら、なおかつまだ頭脳が機能することである。（慧根訳）」という言葉を引用する。（注７）
（注７） #1 マーシャルの言葉 ⇒以前のブログ『今こそ「連続」の視点から見直そう』参照
マーシャルは、1885年にケンブリッジ大学の教授職に選ばれた後に行なった就任講義（「経済学の現状」）の最後に、「冷静なる頭脳と暖かい心（with cool heads but warm hearts）をもって、周りの社会的苦痛に取り組む最良の力の少なくとも幾分かを喜んで提供する者がケンブリッジから増えるようにできる限りのことをしたい」というようなことを述べている。 私は、この「冷静なる頭脳を持って、しかし暖かい心を持って（with cool heads but warm hearts）」という言葉は、"but"と接続詞が使われていることからも、『「冷静な頭脳」と「暖かい心」というある意味相反するもの（両極端）を、混ぜ合わせて真ん中でいくのでなく、うまいバランス感覚で、両極端を使い分けていけ！』と言っていると解釈している。 つまり、決して、両極端のどちらかに偏るということでも、両極端の真ん中でもなく、バランスをよく考えて必要に応じて使い分けていくということが大切であるということだと思っている。 私も、この「両極端を併せ持つ」という考え方は、ひじょうに大切だと思っている。
#2 フィッツジェラルドの言葉
The test of a first-rate intelligence is the ability to hold two opposing ideas in mind at the same time and still retain the ability to function.
【SIers（システム・インテグレーター）に騙されないために、ITを学ぶ】
イギリスの女性経済学者でJoan Robinson 〔ジョーン･ロビンソン
(1903-1983 : イギリスの経済学者) 右の絵は私が描いたロビンソンである〕が、以下のように言っています。
"the purpose of studying economics is not to acquire a set of ready-made answers to economic questions, but to learn how to avoid being deceived by economists.“
（経済学を学ぶ目的は、一連の出来合いの経済問題の答えを得るためではなく、経済学者に如何にしたら騙されないかを学ぶためである〔慧根訳〕）
つまり、「経済学者に騙されないために、経済学を学ぶ」というわけだ。
私は、これをもじって、
「SIers（システム・インテグレータ）に騙されないために、IT（Information Technology）を学ぶ」（“the purpose of studying IT is to learn how to avoid being deceived by system integrators.” by Econ）と言っている。
ここで言うSIerは広義のものであり、私は、SIerが必要ないと言っているのではないことをお断りしておく。
〔SIersの問題〕
私が考えるSIers（システム・インテグレーター）の問題点を挙げてみる。
① ビジネス・プロセスを知らない。
今まで大小何社ものSIersとお付き合いしてきたが、基本的にビジネス・プロセスをわかっていない。Supplierの立場からのConsignment model、Forecastの位置付けもほとんどのSIersがわかっていない、B2Bの仕組みを売ろうとしている人たちがである。確かに、SIersは、我々のようにビジネスの中身を全てわかっていろと言っているのではない。まず、売り込みなり、システム開発をするのなら、打合せ前にもう少し勉強しろと言いたいし、ビジネス・プロセス指向を持っての提案をすべきだということだ。
言われた（要求された？）ことだけのシステム化、理論だけの仕組みづくり、小手先だけの対応では、我々の望むシステムは作ることが出来ない。
② 人月工数での見積り
私は、よく行なわれる「人月工数での見積り」が気に食わない。全てのSIersがこの方式とは限らないだろうが、このようなことを続けていると、SIers自体力がつかないと思う。
いくつかのSIersとの経験では、どうしても人月工数で見積りをさせてくれと言われ、渋々受けた。当初の見積もった工数を使い果たしたら、これでやめるか、お金をもっとくれなきゃやらないと言われた。（確かに要求仕様にも問題があったかもしれないが、見積りの仕方が甘いのは間違いない。）
リスク・マネージメントをし、一つの仕事を請け負うという発想で出来ないものか？ （そのためにも発注側の考え方も変える必要はあるだろうが。）
③ Buzz Wordsとテクニカルなことごまかす
次から次に作り出されるBuzzWordを使い、ユーザーを惑わす。（例：Web Services、SOA、SOBA、SaaS、Web2.0･･･） プレゼンテーションだけすばらしくても、本質を語ってくれないSIersが多すぎる。
④ Black boxにしてのenclosure（囲い込み）
SIersも商売をしているから仕方ない面もあるのであろうが、開発する仕組みをBlack boxにして、他のSIersが入ってきにくくしているようで仕方がない。特にシステムがわからない中小企業ではこのようなことが起こっている。
⑤ 最初はすばらしいSEが出てくるが、後が続かない
最初はすばらしいSEが出てきて、が出てきて、いろいろな説明や提案を受ける場合も、合うたびに出てくるSEの質が下がってくるケースがある。いつの間にか、我々以下の対応しか出来ない人が主担当となる場合もある。これも仕方ないのかも知れない。そんな優秀なSEが世の中に多数いるわけではないのだから。ましてや、ビジネスとシステム両方わかっている人ってどれだけいるのだろうか。
では、我々は、どうあらねばならないのか？
だから、「SIersに騙されないために、IT（Information Technology）を学ぶ」必要があるのだ。
騙されないためには、どんな技術が我々のビジネス・プロセスでは必要なのかを常に勉強しておかねばならない。Buzz Words に振り回されてはダメである。本質を見極める眼力を養う必要がある。
SIersが妥当な技術を使おうとしているのか/使っているのか、どのくらいの工数がかかりそうで、出てきた見積りは妥当なのかがわかるぐらいの技術は常に持っていなければならない。
また、先般ブログに書いた「いつでもシステムを捨てられる準備」をすることが、「SIersに騙されないためにITを学ぶ」ことになるのだと思う。