Recently in IT再考 Category

上流・下流の分断の話が、ソフトウエアの開発と業務システムの構築の混同により、議論がちぐはぐになっていることを指摘した。つまり、業務システムを作る商売をしているSIerがソフトウエアを作ることと勘違いして、相変わらず業務システムのためにプロジェクトごとにコードを書いていること、ソフトウエアのようなプロダクトアウトの発想であること、また顧客ニーズをわかっていないことのために起こっている問題なのであって、まずはそこの勘違いを正すことではないでしょうか。

そもそも業務システム"開発"というところで間違っているのである。業務システムは開発するものではありません。ITが無くても業務システムは厳然として存在するわけです。もちろんIT化プロジェクトで新たに業務システムを開発することもありますが、それはIT化とは別の問題です。ですから、開発された業務システムを効率的に、円滑に動かす仕組みを"構築"するというのが正しいのではないでしょうか。

要するに、ITは何かという根源的な問いに対する答えがこんなところにもあるように思います。これは、何も業務システムやビジネス向けに限ったことではなく、ソフトウエアやコンシューマ向けアプリにも当てはまるはずです。さて、ここでスティーブ・ジョブズにご登場願おう。

僕にとってのコンピュータは、人間が考えついた最も素晴らしい道具なんだ。それは知性にとっての自転車に相当するものだ。                                                       
                                -Steven Paul Jobs-

ジョブズが言っている言葉の中でキーになるのは、「道具」ということと「自転車」ということだと思う。強調したいのは単に人間がやっていることを代行するものとしてではなく道具としてのITであるということ、自動車ではなく自転車であるということなのである。あくまでITの使い手として人間がいるということであり、自動車では人が乗せられてしまう、使われてしまうイメージなのではないでしょうか。知性の自動車ってあり得るのでしょうか。

さて、この言葉もう一度かみしめてみるとおもしろい。自転車を作る人と自転車に乗る人を考える。みなさんもうお分かりだと思いますが、自転車をつくる人、つまり機能や構造をデザインしてそれを製作する人がソフトウエアエンジニアでありプログラマーです。その自転車に乗ってどんなライフスタイルを実行するのか、どんな仕事をするのかをデザインしてスタイルを確立するのがユーザ自身であり、それをサポートするSIエンジニアでありビジネスエンジニアです。

さて、SIerにいるエンジニアのみなさん、あなたはどちらのエンジニアをめざしますか?と言ったところで、こうしたキャリアパスがないので無理なことを言うなという声が聞こえてきそうです。ですから早急に作ってもらいたいと思いますが、そのためのビジネスモデルの変革や制度設計ができていないのが大問題ですね。

どうしたらよいかは、地道だがユーザの声を徐々に反映し、大きな流れにしていくということだと思う。これだけビジネス環境の急激な変化やグローバル化の嵐にさらされている企業はすでに声をあげ始めています。もちろん大前提は、供給側が顧客ニーズを吸い上げた本当にビジネスに貢献する、日常の仕事に役に立つ業務システムを少しづつでいいから提供し続けて、それができるエンジニアを増やすといった対応を行っていくことなのだろう。

だから、大事なのは問題解決型にしろ、仮説検証型にしろ、問題と仮説の設定がすべてといっても過言ではない。そこを間違わないようにしよう。従来の延長で考えるのをやめよう。実は、問題や仮説はそのときの置かれている環境に大きく左右される。時代はものすごいスピードで変化している。そういう意味ではWebの世界に較べて業務システムのエリアの硬直化は目を覆うばかりだ。若い人がなぜそれに気づかないのだろうか。そこに日本のITの未来はある。
  

前回、上流と下流の分断の問題をソフトウエア開発のケースで論じたので、今回は業務システム開発のエリアの話をしましょう。まずは、業務システム開発とソフトウエア開発とでは明確に違うということを指摘したいと思う。大きな違いは、プロダクトアウトかそうでないかです。

業務システムというのは、特定のユーザの特定の要求により、その要求に答えるようにシステム構築を行います。一方、ソフトウエアというのは、不特定多数の想定ユーザために作り手側で要件を決めてプロダクトをあらかじめ作ってそれを売るということをします。だから、極論するとソフトウエアは使われなくてもいいというか、勝手に作ってしまうわけですが、業務システムは使われなったら意味がありません。また、ソフトウエアは自分たちがこうしたいというものを作るから当然コードを書かなくてはできません。

世の中この違いをあまり理解していないのではないでしょうか。もしちゃんとわかっているなら、なぜ業務システムでいつも特定のユーザの特定の要求に対して特定のコードを書くのでしょうか。まるで料理を作るその時に、醤油や味噌を一から作り出していつように思えてなりません。おそらくこの瞬間でも世界中で同じコードを多くのプログラマーが書いているのないででしょうか。だから人月の罠にはまるわけである。

なぜ、"コードはソフトウエアを作る時に書いて、業務システムはそのソフトウエアを使って組み上げる"ことができないのでしょうか。プログラマーは、役に立つ魅力あるソフトウエア(ツール)を産み出すことに自分のスキル、意欲を傾注したらいい。そして業務システムを作る人は、業務プロセス、仕事スタイルをデザインできる人がすればいい。後者こそ本来のSIerのめざすところではないでしょうか。こうすればユーザ自身に作らすことも可能になる。GoTheDistanceさんがブログの最後にこう言っています。

<blockquote>一番大切なことは「自分が使っていて楽しい、自分が作っていて楽しい」そういうサービスなりシステムなりに触れて、どのような問題解決をITで行うことが自己実現に繋がるのかを見いだすことだと思います。</blockquote>

これを誰に対して言っているかです。ここには前に言った混在があります。すなわち、「自分が使っていて楽しい、自分が作っていて楽しい」そういうサービスなりシステムを作るのは、プロダクトデザイナーとプログラマーです。どのような問題解決をITで行うことが自己実現に繋がるのかを見い出しお客さんに提示するのがSIエンジニア(ビジネスエンジニア)ではないでしょうか。

実はこの混同はソフトウエアベンダーにもあります。その象徴的な例として、BPMツールのことを言うと、BPMツールがなかなか売れていないのですが、その理由はソフトウエアを買うところとBPMを買うところが違うのです。つまり、ソフトウエアというのはあくまでシステム開発のフェーズで使うものとして捉えられるのでどちらかというと企業では情報システム部門が対象になります。

しかしながら、BPMはそうではなくて現実のビジネスに貢献できるよう業務システムをどう構築するのか、それをどうオペレーションしていくかが大事なので、当然のように事業部などの現業へのアプローチが必要になるわけです。ここは、システムの作り方も売り方も違っているわけです。

要するに、上流・下流の分断の問題ではなく、最大の問題はIT業界全体が顧客ニーズがわかっていないということに尽きます。顧客の定義さえできていないし、提供すべき商材の意味も理解していないから、ユーザが欲しくないものも一から作りだして結局使われない。それではそこで働く人たちにとって何のために自分のスキルが活かされているのかが見えない悲劇であるということになります。そこにはそもそもITとは何かという根源的な問題も潜んでいるように思えます。
 

ぼくは最近、昼メシを自分で料理することにしている。同じ敷地にある家に住んでいたぼくの母親が老人ホームに入ったので台所が使えるようになったからである。以前から昼メシは自分で何とかしてくれとヨメさんに言われているので外食していたのだが、自分で作ることにした。

なぜこんなことを書くかというと、別に他人が書いたレシピでも作れるということを言いたかったのだ。実際によく利用するのはクックパッドなのだが、そこから自分の好きな料理、あるいは手持ちの材料をどう使ったらいいのかなどの情報を得る。そして、適当なレシピを印刷して脇に置きながら作るのである。自分で言うのも何なのだが、まあまあのものができあがる。

さて、ここで問題を整理してみよう。仕様を書くのがレシピでプログラミングが調理だという話になっている。料理ではレシピを見ながら料理だってできるし、フェラン・アドリアのようにレシピは作るが調理をしないというやりかたもある。ただ、業務システムが料理なのかというとどうも違うように思えるのだ。

多くの人が混同するのだが、ITという括りであたかも同じように語られるのが、業務システムの開発とソフトウエアの開発である。営業システムとか生産システムといったものが業務システムで、MSのオフィス製品だとか、DBMSだとか、パッケージのようなものがソフトウエアとすると、それぞれを開発するやり方は違うと思いませんか。

ということで、前回の議論で言っている上流・下流分断論とか、料理をしないでレシピだけ書いている料理人はプログラムもできないのに仕様書を書いているエンジニアと同じ論にしても、何のためのプログラムを書いている時の話なのだろうか。業務システムなのかソフトウエアなのかである。

ソフトウエアを作るときのことであれば言わんとすることはわかる。なぜならプログラムを書くからである。しかしながら、もしそうであったらフェラン・アドリアのように分断されてもいいと思うし、ましておやジョブズのようにコードを書くわけではないがある意味立派な仕様書を書いているに等しい。つまり、プログラム仕様書なんてさして重要ではないのだ。コードをどう書くかではなく、どんな商品にしてどんな使われ方に対応できるかといったユーザ目線でのスペックが重要だからである。

そもそも、プログラム仕様書を書くのが上流でコードを書くのが下流というのもおかしいと言えばおかしい。本当の上流というのはもうちょっと上のレベルでどんなものをつくるのか、何ができるのか、こんな風に使ってほしいといったことをデザインすることだと思う。そこでデザインされたものを作りだすためのプログラム仕様書作成からプログラミングはプログラマーの仕事にしたらよい。だから、分断される箇所を変える必要があり、そうすることでプログラマーの地位も向上するのではないでしょうか。

では、業務システムのほうはどうなってしまうのだろうか。

最近、いわゆるSIerと呼ばれる業態がヤバそうだという話が聞こえてくる。富士通の3万人のSE職の転換とかが話題になった。おそらくどこのSIerも相当の危機感を抱いているのちがいない。従って、そこで働いているエンジニアのかたがたもこれからの行く末に悩んでおられると思う。

そこでちょっと旧聞に属する話で恐縮なのですが、いくつかのブログ記事についてコメントしておきたいと思う。流しておけばいいのだが、どうも根本的なところで勘違いしているようで気になっていたのであえて取り上げておくことにする。まずは、GoTheDistanceさんの「「SIerでのキャリアパスを考える」というイベントに登壇しました」というエントリーで(別に個人的にどうのというのではなく一般論として取り上げてみたのである、湯本君ゴメン)、そこでのプレゼン資料を公開され、その解説が書いてある。

最初の問題提起として、「僕が常々問題にしているのは「上流工程と下流工程が分断されていること」です」と言っている。そして、その工程を分断させないためには、アジャイルでありプログラミングファーストなのだが、それらの開発手法を現実のものにするのは大変難しく、その理由が人月見積もりにあるとのこと。どうも問題の設定と組み立てがおかしいと思うのである。じゃあ、人月見積ではなくて一括請負とか成功報酬契約とかすれば解決するのだろうか。

この上流と下流との分断については、小野和俊さんも中島聡さんの「ソフトウェアの仕様書は料理のレシピに似ている」というエントリーを持ちだして同じようなことを言っている。ここのところは重要なのでその中島さんの有名なエントリーの文章を見てみましょう。こう書いてあります。

プログラムの仕様書は料理のレシピに似ている。ソフトウェアのアーキテクトが自らプログラムを書いたり、下っ端のエンジニアの書いたコードをレビューする のは、レストランのシェフが自ら料理をしたり、下っ端の料理人の作ったスープの味見をするとの同じである。もちろん、レストランに行く側の立場になってみ れば、そんなレストランで食事をしたいのは当然である。シェフがレシピだけ書いてキッチンにも立たないレストランには行きたくないし、ましてや自分で料理 したこともないシェフが書いたレシピを元に作った料理がおいしいわけがない。

ぼくはこの意見には与しません。「エル・ブリの秘密 世界一予約のとれないレストラン」という映画をご存じだろうか。まだ、上映しているというからロングランが続いている。エル・ブリというのはスペインにある小さなレストランであるが、毎年多くの人が予約したがるがなかなか予約ができないという大変な繁盛店です。

そこのシェフがフェラン・アドリアで、この人の創作する料理が出されますが、彼はいっさい調理をしません。料理のアイデアは出しますが、実際に作るのは別の調理人がするわけです。つまり、上流と下流は分断されています。シェフがレシピだけ書いてキッチンにも立たないレストランなのです。フェランは言います。おいしさより驚きだと。

お客さんがああ楽しかった、こんな体験ができてうれしかったといった感動を与えるような料理を作るには上流も下流も意識する必要がないと言っているのではないだろうか。この話からちょっと角度を変えてみてみると、エンタープライズ系の業務システムというのは料理なのかどうかという問題があります。この話は次回に。

前回は組み合わせで効果を出すということで、対立概念のいいとこどりのようなことを書いた。今回は、人とITの組み合わせということについて考えてみようと思う。いまの情報システムについていちばん大きな過ちというか勘違いは、システム化イコールIT化だと思っていることである。

おそらくコンピュータの出自からして勘違いしやすい歴史がある。元々「電子計算機」として登場してきたので、手で計算するとかそろばんを使って計算するといった人間の所作の代替を行うことが役割であったから、それがシステム化であると考えたのである。それがだんだんとコンピュータによる自動処理という方向に行って、システム化イコール自動化へと進んでいった。

一方で自動化できないものもあるのだが、そこはシステム化の対象外ということで片づけてしまっている。一時、人工知能(AI)なんていうのがもてはやされていたが、結局一部の定型的な処理に近い領域でしか生き残れない。それは当然で、人間の判断をコンピュータが替わってやれるとは思えないからである。

ですから、会社における業務も、もっと広く人間の営みは必ずコンピュータ、ITでは代替できない部分があるということである。そう考えると、発想を変えてみる必要があるのに気づく。つまり、主体をどちらに置くかという問題で、従来はシステム化というとITを使って自動化をめざすことに軸足がいっていたのを逆にすることを薦めたい。

主体をITから人間に置くという意識が重要になると思う。いずれにしろ、"人とITの組み合わせ"でやっていくしかないのだから、そのとき人間がITを使うという関係が実は最も効率的で、経済的であるのではないでしょうか。すなわち、人間がITを使うという意味は、使えないITは使わないという単純な関係をも言っているわけで、役に立たないITを導入することはあり得ないのである。

こうして、人とITの組み合わせという中でその割合なり、重心をどこに置くかはケーバイケースである。会社の規模や成熟度、あるいは対象とする業務、投資能力といったものに左右されてくる。それと大事なことは、アウトプットの完成度というか、あくまで100点をとろうとするのか、70点でよしとするかという考え方で、その会社の事情にあった最善のコストパフォーマンスをねらうことだろう。

従来のアプローチだと、ITシステムを導入することが目的化していて、そこは人間にまかせればいいというような部分にもITを導入するというムダを平気でやっていたと思う。ムダならまだいいかもしれなくて、かえって逆効果になることもある。例えば、自動化が進み過ぎて、そこでひとたび異常が発生してもだれも修復できないという悲惨なことも起きる。

結局、人とITのその時点での最適な役割分担を自分たちの組織能力や手持ちリソースあるいは風土などを勘案して決めていくことが大切である。そして、その"システム"を運用していくうちにIT化したほうがいいところを後から追加して行けばいいのである。こうした柔軟な取り組みをぜひ行っていってほしいと思う。
  

前回、システム構造や開発にも「中庸」の考えかたが必要だということを書いた。そして、対立概念のバランスとか組み合わせが大事であるということを言った。その組み合わせという意味を少し考えてみようと思う。

世の中というものは「陰陽説」を持ち出すまでもなく、大小、長短、明暗といった類から、収縮・膨張、遠心力・求心力といったものまで様々な対立的な概念が存在する。ただ、そうした対立概念のどちらか一方しかないということはあり得なくて、どっちに軸足があるかといった差であると思う。また、場合によってその軸足を変えることもある。

ここでシステム構築のケースについてみてみるとトップダウンアプローチかボトムアップアプローチかという議論がある。具体的には「非定型業務のIT化」というエントリーでも言及しているのでそちらを読んでもらうとして、コンセプト的な話をここではする。

簡単に言うと、トップダウンというのは、上位の戦略からだんだんと分解・詳細化してシステムを開発するというやり方で、一方のボトムアップというのは、システム構造からそれに合うようにセットアップしていくやり方である。もちろんどちらがいいのかということではなく、その特徴をよく理解して使い分ける、あるいはそれらを組み合わせて最適化することが重要になってくる。

ここで少し話はとぶのですが、別のアプローチ法として問題解決型か仮説検証法かなんて議論もある。これも使い分けと組み合わせであることは言うまでもない。さて、トップダウンとボトムアップでは上記のものとどういう組み合わせになるのだろうか。

おそらくトップダウンは、問題解決型アプローチとの組み合わせになり、ボトムアップは、仮説検証型アプローチになると思うのである。トップダウンというのは、上位の戦略とか事業方針、ビジネスモデルというようなところで問題点や課題を抽出することを行う。つまり、そうしたビジネス要求を実現するための課題をどう解決していくのかという観点でシステム化を行うわけである。

それに対して、ボトムアップでは、業務プロセスをオペレーションするためにはどんな仕組みと仕掛けにしておくのかという見方をする。そして、そのコンセプトはある程度構造化できるので、その構造と機能を仮説として提示するわけである。そこに実際の要求事項を埋め込み、オペレーションの実行性を検証するのである。

どちらか一方だけでやりきれるかというと難しいというのはお分かりだと思います。トップダウンで分解・詳細化しても実際にオペレーションに供する仕組みと仕掛けは出てきません。また、ボトムアップで口を開けて待っていてもビジネス要求は出てきません。

ですから必然的に役に立つシステムを構築しようとするとトップダウンとボトムアップの組み合わせにならざるを得ないのである。トップダウンの下降点とボトムアップの上昇点を適当なところで出会わすことが大事になるのです。これを「ハイブリッド型アプローチ」と呼んでいる。
  
中庸」という言葉をご存知ですか。儒教の教書である「四書」うちのひとつにこの名前がある。意味は、偏ることなく、常に変わらないこと、過不足がなく調和がとれていることである。このことが大事であるということはどんな世界でも言えるのだが、ITのところで考えてみましょう。

システム屋さんって、どちらかというと"反"中庸の人が多いような気がしませんか。自分の流儀や好きな技術に偏るし、新しいトレンドにすぐにとびつくし、うまくバランスをとることが苦手なように思えます。中庸というのは足して2で割るということではなく、両方のいいとこどりといった意味なので、自分が好きではないものもよければ使う精神が大切である。

だから、中庸的なシステム構造、中庸的なシステム開発がどうしたらできるのかを考えるのは意味があると思うのである。システム構造でいえば、昔から較べると今はSOA的な指向が出てきてインターフェースさえあればうまくサービスコンポーネント組み合わせてバランスをとれるようになった。別な言い方をすると、中庸的な組み立てをしないとSOAをやる意義はないということでもある。

一方のシステム開発の局面をみてみると、まずは開発アプローチでデータ、プロセス、機能のそれぞれでどうやるかの議論があるが、どれでなくてはいけないというのではなく、ここでも調和させてやることが大事になってくる。何でもDOAでやるべきではないし、パッケージ開発だけでやるべきでもない、もちろんプロセス志向だけでいいというわけではない。

このブログでは、プロセス中心アプローチを推薦しているじゃないかと言われそうですが、それだけだとは言っていない。ビジネス活動の部分においてはプロセスから考えることを推しているが、リソースデータの管理についてはDOAでやるべきだと言っている。リソースデータというのは、個別のプロセスとは関係なく会社全体で見渡すべきで、会社としてビジネス活動を行う資源にはどんなものがあって、どういう能力があるのかをつかむためにあるからである。ですから、リソース系のデータはDOAで、イベント系のデータに関しては、プロセスから考えるべきなのである。こうした中庸的な見方が必要である。

また、業務システムの開発アプローチで上流から下りてくるトップダウンアプローチとシステム構造から迫るボトムアップアプローチがあるが、ここでも同様に両者を融合した取り組みが重要である。このことは本ブログでも何度も取り上げていてそれをハイブリッド型アプローチと呼んでいる。実は、ハイブリッドとは中庸の精神であると思いだしている。

要するに、多くは2項対立的な世界にあるわけでその時どちらか一方に偏ってはいけないのであって、2項のバランスというか組み合わせといったことをよく考えることがシステムを作る上でも大事になってくるのである。
  


About this Archive

This page is an archive of recent entries in the IT再考 category.

IT雑感 is the next category.

Find recent content on the main index or look in the archives to find all content.

Pages

Powered by Movable Type 4.34-en