メイン

誰のためのITですか アーカイブ

2006年9月 5日

企業情報システムの課題

ここ10数年企業における情報化に携わってきたが、結局根本的な問題の解決ができていないように思えます。それは何かというと経営や事業に貢献できるシステムができていないということです。

実はこう言うけれど定量的に費用対効果における効果が計測できないので何となく経営者やユーザが満足していないよなという感じなのかもしれません。ただそう感じているひとは多いことも確かです。究極的には、成果報酬型ならいいのでしょうが、この場合は、最初の経営改革や業務プロセス改革のフェーズから入らなくてはいけないし、トータルシステムとしてのパフォーマンスを見なくてはいけないので、おのずとこんなことができるベダーが限られてくる、というよりIBMくらいしかできないし、さらにそんなやり方を頼めるユーザ、もっと言えば経営者は非常に少ないと思います。

となると、経営者やエンドユーザがまあまあ満足できる効果的な企業情報システムを現実的なアプローチでどう構築するかを真剣に考えていかなくてはなりません。といって、それではそこのところを一体誰が考えるのだろうか、まずはここがこれまでの問題の重要なポイントなのです。これまで、往々にしてメーカ、ベンダーにおまかせのやり方だったのではないでしょうか。本来の姿であるユーザ主導のシステム構築にしていかないと、いつまでたっても使われないシステムが蔓延することになります。最近はこうした問題に危機感をもった人たちが、いろいろ発言し行動もしてくれて、例えばEAが策定されガイドラインも示されてだいぶよくはなったきていますが、まだ課題は多くあるような気がします。

そこでこれから、ユーザが主体となって自分たちの情報システムを自分たちの手で構築・運用していくにはどうしたらよいかを考えていきましょう。これは実は小泉さんではないが「構造改革」ということなのです。ただし小泉さんの言う「構造改革」とは違います。というのは「構造改革」というなら前提としての「構造化された構造」があってそれを変えていくというのが改革だと思うのですが、小泉さんは改革のターゲットあるいは社会全体の仕組みを構造化してちゃんとそれをわかりやすく説明しないで、ただ壊せばいいというようになってしまったように思えます。

ですから、まずやるべきことである企業情報システムの構造化をちゃんと行い、そこで
明らかになった問題点をどう解決していくのかという議論になるのではないでしょうか。

2006年9月16日

モデリングって何?

きのう「モデリングフォーラム2006」に行ってきました。このフォーラムは2日間にわたって行なわれ、その2日間とも出席を予定していたのですが、新会社の商談なんかがあって2日目の午後しか参加できなかった。そんなことなのであまりえらそうなことは言えないのだけれど、どうも焦点がぼけている感じは否めなかった。おそらく、トラックが多すぎて講師も集めるのも大変だったろうし、なにを言いたいのかぼやけて、セミナなの質が低下してしまいますよね。

そのなかでもというか最後の最後に(株)メタジトリーの丸山さんのプレゼンで救われたような気がします。要するに、経営に貢献できるためにはビジネスプロセスを可視化して組織の規模や成熟度に応じて段階的に進めていくことが大事だと言っています。丸山さんとは旧知の間なのですが、実践的な話や段階的アプローチなどの提示はわかりやすくなっていて好感がもてました。でも丸山さん最後のアニメはいらなかったんじゃない。

というわけで日本BPM協会の活動を興味をもって見ています。

2006年10月 8日

システムがほしいのではなくサービスがほしいのです

今、少しばかりマーケティングについて勉強しているが、ある本にマーケッティングコンセプトは生産志向→製品志向→販売指向→消費者志向→社会志向へと変遷していると書いてあった。これをIT業界、とりわけソリューションベンダーの視点で見てみると面白い。

この話をする前に、この業界あるいは企業の情報システム部門が抱えている課題について整理しておく必要がある。大きな2つの構造的な問題点がある。ひとつは、エンタープライズシステムの作りあるいは作り方そのものの問題、もうひとつは、ヒトや組織、ユーザとベンダーの関係、人材育成等のいわば人的な問題である。システムの構造というのは、簡単にいうとフレキシブルでアダプティブな構造になっているのか、真の意味のSOAやBPMが実現できているのかという問題なのだが、これについては後日議論します。人的な問題で主なところでは、まず、ユーザにためになる、言い換えれば経営に役にたつシステムをベンダーはユーザに提供できているのか、つぎにユーザの情報システム部門もベンダーに丸投げせずに自力でシステム化する努力をしているのか、といったところがあります。

冒頭の話は後者の問題に絡んだことになる。すなわち、これまで、ソリューションベンダー(メーカ系であれ、独立系であれ、ユーザ系であれ)は、言われたとおりにプログラムを生産することから始まり、あるいは、ハードウエア、ソフトウエアを本当に使われるかは後回しで言葉巧みに販売してきたように思われます。しかもそれらが役にたっていなくてもハードのお金やかかった工数の労務費を請求し、ユーザはわからないものだから言われるがままに支払うという関係でした。コンピュータがわかる経営者もいなかったため、何となく高いコストであると思いつつそのまま放っておいたというのがだいたいの会社の実態なのではないでしょうか。消費者志向、社会志向ということを本当に考えていかなくてはいけないと思います。

ところが、先日あるベンダーのひとと話をしていて、話題が国の中小企業のIT化支援になったのだが、経済産業省が「IT経営支援隊」というプロジェクトを始めて今年が最後の3年目になるそうで、最初は中小企業のIT化促進というのが前面に出ていたのが最近はどちらかというとベンダー寄りになってしまったと嘆いていました。結局、主管しているのが情報処理振興課なのでベンダー育成なんですね。国がこんな調子だから困ってしまうのだが、要はユーザに役立ってなんぼですからそういう観点で支援してほしいものです。それが、ベンダーの消費者志向、社会志向のマーケティングにつながると思うのだが、私はもう半ばあきらめていて、ユーザ自身が立ち上がらなければいけないというのは以前「企業情報システムの課題」で書いたとおりである。

とはいえ、ユーザ自身ができるのはあくまで大企業であって中小企業は無理です。そこで、中小企業向けにシステムの共同利用をめざしたセンター化が必要になってくると考えています。しかも中小企業ですから地域密着型です。いま、そうした考え方から「ITから生み出されるサービス」を提供する「地場中小企業向けビジネスサポートセンター」というものを構想中です。いろいろなところで仕掛けをしていますが、時間がかかるのは覚悟の上でがんばっていきたいと思っています。

2006年11月17日

ブログのアカルイミライ

「Business Blog&SNS World]というセミナが、11月16日、17日に大手町のサンケイプラザで開かれた。ビジネスブログという言葉自体非常に新しいもので、ブログという道具を使って今までの個人レベルから企業レベルの情報共有に拡げていこうということのようだ。

ぼくが聞いたプレゼンは、シックス・アパートの「ブログ・オン・ビジネス」というブログの概説みたいな話、ニフティの「ココログラボの事例」、これは面白かった、事例として「ブカツブログ2006」というのがあって、ナイキがやっているんだけど、全然表に出てこないというのがいいし、伊藤園のホームページのブランドイメージアップ作戦とか、スバルのレガシーファンのコミュ二ティサイトだとか、要はブログのもつ双方向性をうまく活用している事例を紹介していた。あとは、ドリコム、スカイアークシステムから、企業内での情報共有の事例をもとに成功の秘訣やデメリットの話があった。スカイアークのユニクロの本部と店舗のコミュニケーションの話も参考になった。

実はその後のパネルディスカッションが一番面白かったのです。パネラーは、ドリコムの内藤裕紀さん、フィードパスの小川浩さん、ヤマハの鞍掛靖さんの3名でモデレータが何とあの神田敏晶さんということでビジネスブログの有効性みたなディスカッションだったのですが、当然のようにブログがこれから企業の中に浸透していくという結論です。

ただ、神田さんの”これまでのグループウエア例えばサイボウズのようなものとどう違うのですかねえ”という問いに明確に答えられていなかったのはなぜなのだろうか。どうもぼくが思うにはパネラーの彼らは企業の日常業務活動の実態あるいは管理のありようということが経験として分かっていないので、比較できないんじゃないのかな。だから、ブログ、特にイントラブログというような社内情報共有あるいは日報などの業務の一部としての使い方の場合に、最初に起こるコンフリクトがそのあたりにあるように思える。すなわち、企業というのは基本的にコンサーバティブなので、ブログベンダー側の茶髪のお兄さんが、ブログ良いですよみたいなノリで薦めても、”それ入れて何が良くなるの? ブログを書いている時間があったらもっと仕事をしたほうが会社のためだ”てなことを言われしまう。

内藤さん(内藤君といったほうがいいのだが、まだ27歳ですよ)も言っていたが、ブログが成功するかどうかは、会社として職位やキャリアなどがちがっても一人一人が自由に意見が出せる環境をもっているかどうかにかかっていて、ブログを使って管理しようとしたら必ず失敗するそうだ。とはいえおおかたの経営者、管理職は旧来型の管理志向は変えられないのでそこをどうチェンジマネージメントできるかが鍵のようだ。ただ救いとしてERPのように大金がかかるわけではないので、とりあえずやってみたらができることだ。

セミナーの全般的なトーンは、ブログよさである”簡単に情報発信できること”、”トラックバック・コメントによる双方向コミュニケーションが図れること”、”情報が自然に整理される”ということが顧客接点、従業員接点で威力を発揮できるため、ますます企業に普及拡大していくというものであった。ぼくも当然この意見に与するものであり、あくまでいい道具であり、最後は人だということさえ忘れなければ、非常に有効な手段を手に入れたと思う。

で黒澤清監督の映画「アカルイミライ」にでてくるクラゲのようにブログは繁殖し続けているのです。

2007年2月23日

違和感

昨日、先週と同じ目黒の雅叙園で行われた「経営とITの融合(KIU)」研究会主催の「第1回 アジャイル・エンタープライズ・カンファレンス」に行ってきました。副題が「<俊敏で柔軟な企業/組織の変革>のロードマップを求めて」ということで、内容的にはほとんどがSOAとBPMの話。

ここのところにわかにSOAやBPMが脚光を浴びてきたようだ。内部統制も後押ししているが、やはり、従来型のシステム開発の限界を認識し出したのかと思う。

ぼくは、自慢するわけではないが、かれこれ5年前にまだBPMという言葉もほとんど知られていない、やっとWebサービスという言葉が出てきたころに、BPMの仕組みを使ったアプリケーションの開発を行っていた。まだ、標準化されたインターフェースがなかなかなくてすごく苦労した覚えがある。SAVVIONというソフトがバージョンアップでそれを実現してくれたのでやっとできた。

だから、いま皆さんが声高にBPMといっているが、かなりのひとがはやりものに乗っかっている感じで、ぼくから言うと、とってつけたようにBPMだとかSOAと言ってみただけのように思える。なぜこの仕掛けが要るのかということを身をもって分かっているかということです。つまり、いいシステムをどういう構造にしたらいいのか、どうやって作ったらいいのかということを懸命に考え、苦労し、失敗もしてたどりついたかどうかということなのだ。みんな本当に分かっていて言っているのかと違和感を覚える。

それと、このカンファレンスというか、そもそも「経営とITの融合」と言うこと自体多少違和感を感じ始めた。以前はぼくも経営戦略をちゃんとし、KPIでビジネスのゴールを設定して、そういうことが重要で、みたいなことを言っていたのだが、最近はどうも違うんじゃないかと思うようになっている。

まず、ITから経営がどうのこうのいうのは“おこがましい”のじゃないかということだ。現に、このカンファレンスでも実際にユーザ企業で経営に携わっているひとが発表しているわけでもないので、IT側から一方的に経営ってこうですよねみたいに言っているのは、片思いというか、きつい言い方だと滑稽に思えてくる。だから、最近この近辺の話を聞くたびに、もやもやしている、違和感がある。

なんか、一度リセットして考え、ゼロベースで再設計する必要があるような気がしてならない。それが具体的に何なのかがまだ出てこないのだけれど、例えば、ITは経営がどうのこうのではなく、“いい技術・道具を提供する”ことだけで十分ではないのかとか、そんな発想ありかもしれないなと思ったりする。

そういう意味で、最後のパネルディスカッションで示唆的な意見が2つあった。ひとつは、オージス総研の山崎さんのテクノロジーからBPM、SOAを語ったことと、メタジトリーの丸山さんが、挑発的にみな大企業のことばかり言うが、本当にBPMが必要なのは中小の会社でそのビジネスモデルで差別化を図りたいところではないかと言われたことで、それらがヒントになると思う。

帰りは、会議のあと一緒する予定であったひとが話が違っていてふられてしまい、やむなくひとりで大船の「鳥恵」で一杯呑んで帰る。居酒屋もいろいろあるが、「鳥恵」はどうもひとりで行くところではなさそうだ。周りは男女2人連れが多くここでも違和感を覚えたのであります。

2007年2月25日

デブサミ補完ビデオ

デブサミ2007に行った話をしたが、その中で開発者の人たちの話を直接聞かなかったので、何となく気になっていたら、デブサミの講演そのままではないが、同じ話がちゃんとビデオで聞けるようになってなっていた。

それは、永和システムマネジメントの角谷信太郎さんの「実践『From Java to Ruby』 ~ 血があつい鉄道ならば/走りぬけてゆく汽車はいつかは心臓を通るだろう ~」というタイトルのプレゼンがGoogleVideoで見ることができる。今日時間があったので、80分くらいのものを全部聞いてしまった。

デブサミの感想でも評判のプレゼンで角谷さんの熱き思いが好評であった。確かに、聞いているとRubyに対する思いがひしひしと伝わってくる。私は、プログラマーに誇りを持っていますと言うのがすごく好感が持てた。なぜか、日本のソフト業界では、SEやアナリストに比べるとプログラマーは低く見られがちだが、そうではないとぼくは前から思っていたので、そういう気概をもった若い人が増えることを願っている。

ただ、ぼくには理解不能な箇所が随所に出てくる。なぜなら、早口でTechnical Termを頻発すること、文学的かつ哲学的な表現が断片的に登場するのでちとつらいところがある。それでも、一生懸命聞けば、またVideoのいいところはわからなかったら、戻って確認できることで、だいたいのところは分かった。

ぼくは自分でプログラムが書けないので、JavaとRubyの比較を見せられても本当に腹に入らないけれど、RubyもRubyOnRailesというフレームワークが大ブレークしたので、今後小規模あるいはフロント業務系で使われていくのは間違いないように思える。しかも、国産だから、ぜひ成長させて、グローバルに展開してほしい。IPAなんかももっとこういうものを支援したらいいと思う。

さて、このプレゼンで最初にRubyはビジネスと相性がいいというテーマで話出したので、期待したのだが、どうもこのビジネスというのが、ソフトハウスにとってのビジネスのことのようであった。ぼくは、こうした第一線の優秀な開発者がいかにいいビジネスシステムを作るかという視点で語ってほしいし、そういう方法論を確立してほしいと願っている。

例えが必ずしも適当でないかもしれないが、近くのディスカウントショップに行くといつも思っていることと似ているのでそのことを書く。

その店には、数人のアルバイトの子がいて、商品棚の整理をしている。商品を並べ変えたり、段ボールから新しい商品を出して陳列したりしているんだけど、買い物しているこちらとしては、邪魔でしょうがない。もうぼくらのことは見向きもしないで一生懸命で、時にはとなりのバイト仲間とおしゃべりしながら、仕事をこなしている。おそらく、この子らに「あなたの仕事は何ですか?」と聞いたら、きっと「商品をきれいに陳列することです」と答えるでしょう。そうならこの子らは優秀なバイトですね。そうでしょうか。違いますよね。あなたの仕事は、”お客様に気持ちよく買い物をしてもらい、商品をいっぱい買ってもらうこと”じゃないの。

そうなんですね。システムもお客さんが使ってくれてなんぼなんです。そんなことを考ええてしまった。もちろん角谷さんがそうだと言っているわけではなく、現場では実践しているかもしれませんし、むしろ、こうした最近の優秀なプログラマーの人たちがそこを埋めてくれそうな予感もあると思っている。プレゼンでもその芽のような話も出ていたので期待したい。

“スーツぽい”話だっておもしろいですよ。

2007年7月 2日

第一回BPMオフ会

第0回BPMオフ会というのを5月18日に行なってから、最初の勉強会である「第一回BPMオフ会」が昨日、月島で開かれた。午後から、マイクロソフトのエバンジェリスト松崎さんからマイクロソフトのワークフローエンジンWF(WindowsWorkflowFoundation)の話とスターロジック社長の羽生さんから業務の見える化ツール「マジカ」の実習を交えた紹介をしてもらう。

ワークフローエンジンの中身の話とそのエンジンに乗せる最初の業務分析のところの話でいわば最上流と最下流という感じ。すごいおもしろかった。やはり、前線で活躍しているひとを言っていることは迫力があるし、説得力がある。羽生さんには、懇親会のとき若干話したが、もう少し「マジカ」で仕事を洗い出したあとの整理の仕方を教えてもらいたい。

ぼくとこのBPMオフ会の関係はというと、ぼくはずっとBPM(Business Process Management)に興味をもっていて、いろいろ調べたりしていたが、そのなかでBPMに関するブログを書いている人を捜してみた。そのときひっかかったのが、「わきぶろぐ」、「Go The Distance」、「犬の耳」の三人の方々でした。それで、すぐに前者2二人に実際に会って話をすることにしました。そうしたら、近々にBPMの勉強会みたいなことを立ち上げたいという話だったので、是非やったらどうでしょうよと言っていたら、5月に最初の集まりがあって、今回2回目ですが勉強会という形で始まったわけです。

しかし、日曜日にもかかわらず16人も参加していて感心してしまいます。ぼくと「犬の耳」の澤田さんのようなおじさんから、20代の若い子まで幅広いメンバー構成で、昨日は仙台から参加してくれた方もおりました。

勉強会が終わったあとは。月島なのでもんじゃ焼きで懇親会です。ここでは、酒を呑みながらお互いに言いたいことを言える雰囲気で盛り上がるのです。

普段の会社のしがらみを忘れて利害関係のないコミュニケーションをとることも非常に大切のように思えた一日でした。

2007年7月27日

少しずつ変化が

今朝の朝日新聞に「IT調達改革の星」という記事があった。長崎県の島村さんというCIOの活躍を書いたものである。行政のIT化に必要な機器やシステムの調達を改善し、情報コストの低減とともに地場IT企業の育成、県職員のITリテラシーの向上を実現した話である。

最初の調達コストを下げた件は、従来は大手ベンダーに発注して割高になっていたのを直接地元業者に発注してことが大きい。発注側としては、実績もない小さな会社に依頼するのはリスクがあるのだが、そこを多少の失敗は覚悟でまかせたのだ。なんといってもこのスタンスがすばらしい。これで、コストは下げられるし、地元の業者は育っていくという大きなメリットをもたらしてくれる。お役所は冒険はしないところと決まっていたが、こういった挑戦的な役所も現れてきたのだ。

どうしてこういうことができたかというと、島村さんは民間から来た人なのだ。6年前に金子知事に招かれて日本総研から出向してきた(今は正式の職員になった)そうだ。こういう試みは大いにやるべきだし、他の行政も見習ってほしい。ぼくも盛んに言っていることだが、ITを梃子にした地場産業の活性化というのにも、こうしたケースは含まれている。すなわち、行政の仕事を地場のIT企業がやることで成長し、ひいては全国展開できるくらい力をつけることである。ITは地方からでもグローバル化できるのだ。

ところで、その記事の中に、国際大学の地方自治体IT調達協議会の調査の結果が出ていて、02、03年度都道府県の公募型IT調達では、NTT、富士通、NEC、日立製作所の4グループの合計シェアが何と75.8%で、しかも13政令指定都市では91.6%になるという。これってびっくりするでしょ。

ただし、実際に手を下してシステム開発をしているのは、下請けの業者だから、実開発業者のデータをとって調べたらおもしろいと思うが、上記4グループまあ言ってみればゼネコンだけど、彼らが全部上前をはねるという全くの女衒商売をやっているわけだ。だからこの構造を変えていかなくてはいけない。

さらに、島村さんは「殿様商売」に安住する大手IT企業には大きな技術的進歩が望めないのではないかとも指摘している。全くその通りだと思う。特に地方自治体なんかはITの妥当な価格は分からないし、そもそも予算さえとれれば、その予算どおりにつくればいいわけで、そこにはコストを下げるための工夫だとか、コストパフォーマンスの考えなんかないのだ。そうなると、ゼネコン企業側もこれだけ人月がかかりましたからお金をくださいといえば、そのとおりもらえるから、安全な方法で、あるいは今までと同じやり方でやっとけばいいやとなって、新しい技術を採用するだとか、少し開発的要素があるけどがんばってみようかということができなくなっているのだ。

その意味でも長崎県の事例は非常に参考になるし、単なる先進事例だけで終わらせることなく、他の県も追随していってほしい。そのためには、ゼネコン会社から人を受けるのではなく、その利害から外れたところにいた島村さんのような人をどんどん行政に送り込む必要があると思う。

2008年9月24日

業務システムの変化

技術とか考え方などは時とともに変化するものである。それは、新しいいいものが開発されたり、世の環境の変化に対応するために形を変えることがおこる。

その場合、往々にして変わるタイミングが問題になる。すなわち、あまり早く新規技術を取り入れてもうまくいかないし、遅すぎるとメリットを享受する時間が短いことになる。

なぜこんなことを書いているかというと、ちょっと前に羽生章洋さんがブログに書いた「今だから出来る業務システムを」という記事を読んだからである。そして、羽生さんの言うことに激しく同意したからである。

ITのIはインフォメーションすなわち情報です。業務システムをIT化する・IT化されたシステムを刷新する、というのは、業務における情報のあり方を見直すということです。情報を見直すことを通じて、仕事の流れを整理し直していくというのが、本来の意味での業務のシステム化です。ですが、伝票がそのままであるということは、おそらく業務自体は何も変わっていないのであろうと見て取れるのです。これはROIが相当に問われるケースかと思うのですが、得てして日本のシステム構築というのはこの辺何となく許されてしまえるようです。

というくだりなど思わずうなずいてしまうのである。単に今様の技術を使ったから新しいシステムであるということはない。新しい技術が生まれてきた背景を考えると、突然出てくるわけではなく、使う人のニーズだったり、時代の要請があるのであるからこそ使われる技術になる。だから必然の産物なのである。

ということはそうした時代の変化に合ったような使い方をしないと意味がない。羽生さんの言うように仕事の流れを旧態依然のままにして新規ITで作りましたといわれても何のためのシステム化だということになる。

例えば、Webの技術を使うのだったら、どうしてそういう技術が登場したのか、それによってどういう変化がおき、どんないいことをもたらしてくれたかをちゃんと理解して利用しないと意味がない。

伝票がなぜ必要だったのか、今の道具と仕事のやりかたのなかで伝票の役目は昔のままなのか、といった問いかけをしていかないといけない。

このブログでも、帳票というのは「電子化された業務と電子化されていない業務をつなぐもの」と書いたが、その定義から言えば、現在のように仕事がどんどん電子化されている状況では、その必要性は減っていっているはずなのに、帳票にこだわる人がいたりする。

画面もそうで、追加・更新・削除はないよなあとぼくも思う。

また、業務改革というように大上段にふりかぶらないでも新しいITやそれを活用する考え方を“正しく”適用していけば、かなりの部分で業務改善くらいはできるはずだ。

よく技術はどうでもよくて思想が大事だみたいな言われ方をするが、そういう一面はあるにしても、前述したようにその技術の登場した背景を考えるとかいった技術からの発想も思っている以上に大事であることを強調したい。

2008年9月25日

単純を極めた先に技術の革新がある

もう至言である。これを言ったのは、「折りたたみ携帯電話の未来を開いた男 久保田直基」である。「未来創造堂」というテレビ番組(これは時々見る)で登場した。

彼は、スプリングの特性を生かして、凹凸のあるパーツと組み合わせる新たな蝶番を考案したのである。いまや世界のトップメーカもこのスプリング式開閉システムを採用しているという。

確かに、別に特別な仕掛けや複雑な構造になっているわけではない。まさにシンプルで誰でも思いつきそうなものである。しかし、そういうものこそ革新的なのだ。こういうことを“目からうろこ”ともいう。

創造活動におけるこのような視点は非常に大事だといつも思う。どうしても、皆と違うことをするとか、今までにないものを作るというと、いかに違いを付加するかという方向に行ってしまうのではないだろうか。そうしたことはクリエイティブでもなんでもない。そこを勘違いしてはいけない。あくまで、シンプルなものを作ってこそクリエイティブであるといえる。

ところがこのシンプル化は大変難しい。もの作りではなくても、例えば簡単な例でプレゼンテーションでもいいが、言いたいことを1枚で書けと言われるくらい難しいことはない。ぐたぐたいろんなことを並べることはできるが簡潔に言いたいことだけにするのはすごく苦労するのは皆さんも経験あると思います。

ましておや、創造的活動で単純を極めるのは至難の業だが、どうしたらそういうことができるのだろうか。

前提条件として、たえずゼロベースでものが考えられて、ものごとの本質をえぐれる人がなしえることができると思う。壁にぶち当たったときに、“そもそもこれは”と立ち止まれることだ。もちろんそれを実現できる能力がなければいけないが、少なくともそういった態度の上で生み出されるように思える。

そして忘れてはいけないのは、単純なものほど美しいということである。美しいものほど人に愛され、長く残るのである。

システム構築やソフトウエア開発の場合にもここで言っていることが当然当てはまるので、これから一層肝に銘じようと思う。
 

2008年9月30日

IT化を妨げるもの

日本のIT投資はなかなか増えないようだ。政府でもIT投資の促進を謳っていても、笛吹けど踊らず感がある。まあ、笛の吹き方も悪いけど。

どうして、投資をしないのだろうか? 経営者がITを理解していないだとか、IT戦略を立てられるCIOがいないだとか、ROIが成立しない、日本では従業員が優秀だから人手でやってしまうとか、いろいろな言われ方をされているがいったいどれが決め手なのだ。

ぼくが思うに、大きな理由のひとつに、雇用の流動性の欠如があるように思える。風が吹けば桶やが儲かる式の話になるが、日本では依然として終身雇用制が残っている。そうであると、今いる会社で長く存在感を発揮することが給与を上げることになる。

ということは自分の存在意義として固有性を保持することが重要となり、仕事が属人化する。IT化は標準化のことだから、属人性を排除して成り立つのでそこでコンフリクトが起きて、IT化抵抗勢力が形成される。

経営者はそれを改革してまでIT投資をする気がない、というか正当化するための理論武装ができるほどITに理解がないからIT化は夢と化す。

これをいいとか悪いとかいう議論でいうとよくわからない。別に無理してIT化する必要はない。ITなんか使わなくても、自分の会社の身の丈にあっていればそれでいいのだ。

だが、日本における雇用の流動性の欠如はIT化の問題に限らず、どうも日本の活力を失っている原因のひとつのようだから、そのうち雇用の流動性が今よりおこっていく可能性は高い。そうなると、仕事の標準化がおき、そこにITをぶつけていく事態は当然予想され、そういう意味ではいまから準備しておくことなのだろう。

もうひとつ言えるのは、経営者にIT投資がおしなべて高いというイメージが刷り込まれていることではないだろうか。高い投資額がIT化を妨げているということだ。そうしたら、ITの価格が下がれば導入が進むのだろうか。ことはそう簡単ではないような気がする。

だいぶ前になるが面白い話を聞いたことがある。あるパッケージソフトがよく売れているというので、その数を聞いたらものすごい数なのだ。そのまま、全部使われていたら大変なことになる。ところが、それほどでもない。

どうしてかというと、入れたはいいが使ってない数が多いということである。捨ててしまったというわけだ。要するにこのソフトは“使えなかったら捨ててもかまわない”値段だったというわけだ。この話を聞いたときになるほどと感心してしまった。

もうひとつ、逆の話として安いと信頼感をもてないというか、安かろう悪かろうと考えてしまい、ある程度高くないと使わないという心理もある。これもおかしな話なのだが、こんなにお金をかけたのだからいいものを手に入れたはずだと思い込む。開発のようなケースでもあって、あまり早く安く作るといいものではないと思われたりする。

だから、必ずしも、安くすればIT投資は増えてくれるのかというと必ずしもそうはいかない。ただし、それは、いまもかなりIT化をしているような大企業のケースが多い。IT化が遅れている中堅・中小はそんなことは言ってられないので、安いのにこしたことはないと思う。

まあそうは言っても結局は、安けりゃみなさん使ってくれるはずだ。やっぱ、IT化を妨げている一番のものは価格であるとしておこう。ユーザのみなさんよく言いますよね”もうちょっと安ければ買ってあげるのに”(ウソかホントかわからないが)
 

2008年10月 2日

SOAは終ったのか

先日「「SOA ユーザ企業自身がデザインする、導入のかたち」とうタイトルのセミナーがあったので参加した。このタイトルからすると、なんかユーザがSOAの仕組みをばんばん作っているイメージになる。ところが、基調講演はよかったのだが、それ以外に5セッションあったが期待を裏切られた。

基調講演はカシオ計算機の事例であったが、これはすばらしい。SOAをきちんと理解し、しかも実践しているというところは見習うべきところがいっぱいある。しかも、Web2.0技術も積極的に取り入れている。

ぼくは今カシオの人たちといろいろ議論しているが、おそらく自分たちはSOAをやっていますという意識はないと思う。競争優位を得られるためのITはどうあるべきかということを追及した結果として、SOA的なものになったはずだ。

さて、なぜタイトルで「SOAは終わったのか」としたかというと、最初に言ったように、基調講演以外のものをながめたとき見るべきものがなかったからである。というより、「ユーザ企業自身がデザインする」と謳っておきながら、カシオ以外にちゃんとしたユーザ事例がないのだ。

これは何を意味しているのかというと、カシオの例で言ったようにビジネスユーザは意識してSOAをやろうなんて思わないのだ。だから、SOAだと言っているのは、システム部門がシステム基盤整備で構造化する場合か、ベンダーが製品を売らんがためのものでしかないということである。

そして、さらに言うと、SOAのサービスが定義されていなから、大きいものから小さいものから、何でもかんでもSOAと言っている。大きいところではコンポジットアプリケーションなんて言っているが、これはもうERPやパッケージを入れてしまったので、しかたなしにそういう概念を持ち出しているようにしか思えない。

よーく考えてみてください。まっさらからシステム構築しようとしたとき、はじめからそんな考え方を採りますか。だから無理がある。やるなら、既存アプリをスリム化してからつなぐことだ。

それから、システム機能をサービスと言うのもちょっと違うのではないかと思ってしまう。その辺は、フレームワークに埋め込んでしまえばいいんじゃないかということだ。

結局、ビジネスに貢献できるためにSOAはどうなんだを説明できていない。だから、ユーザ視点を失ったSOAは消えていかざるを得ない。

FlexibleでAdaptiveな構造の仕組みにしたら、それが結果的にSOAだったということでいいのではないだろうか。要するに、目的語から形容詞になったってことだと思う。
 

2008年12月11日

ドキュメントはブレーキになる

自分で言うのもなんだが、何やらわけのわからないタイトルである。最初は、ウオーターフォール開発とアジャイル開発の比較みたいのことを書き出したら、いつの間にかドキュメントのことがひっかかってきて、それは、開発方法のことだけではなく、生産システムや業務プロセスのところにも関係すると思われてきて、じゃあいっそのことそのドキュメントについて書いてみることにしようと思ったのである。

しかし、出だしは開発のところからになる。情報システムの開発方法で昔からのウオーターフォール開発とアジャイル開発というのがある。この2つを比較する場合、字句をあげつらうようだが、この2つは対立軸が違う言葉であるので、そのまま対比させるのもおかしい。

アジャイルの反対は、SlowとかDullとなるし、ウオーターフォールに対比させるならイテレーションということになる。そうなると、“俊敏”な開発はイテレーションだけかという話になってしまう。

だから、そんな比較をしてもしょうがなくて、どんなやり方でもいいから、“俊敏”な開発ができればいい。
これと似たようなことが生産ラインにもある。ベルトコンベアー方式とセル生産方式がそれにあたるかもしれない。

仕事でも、逐次的に流すものとプロジェクト的に完結させるようなタイプがある。要するに、定型化されたフロー型と非定型のストック(情報共有)型にわけることができると思っている。

それで、これまでの世界では、どうも前者の定型化されたフローで処理していくやり方が主流であったといえる。前の処理が終わると次の処理に回してという流れ作業である。これは、前述したように、システム開発のみならず工場の生産方式、会社の中の業務処理もみな共通しているやりかたである。

それは、もともと分業という考え方で、各自の役割をきちんと決めて、ひとつづつ着実に歩むことが、よい結果を生み出すと考えられた。しかも、それが効率的だとみなされていたのだ。

それは、環境変化のスピードが遅い時代であれば、そう言えたかもしれないが、現代のようにめまぐるしく変化する時代では足手まといになりかねない。

なぜ非効率なのでしょうか。ここでその象徴的なものとして「ドキュメント」(ここでは紙のドキュメントを言います)の存在について考えてみましょう。

流れ作業や逐次フロー型の処理では、各々の工程間をつなぐものとして、仕様書とか手順書、伝票といったドキュメントがある。そこに情報を埋め込んで次の工程に伝達する。それが問題になっているように思えるのだ。

このドキュメントを作る手間もけっこう大変なことは誰しも経験することではないでしょうか。しかも、どんどん変化していくので、その都度変更をかけていかなくてはいけないのだが、そのうちメンテできなくなり、いつの間にかインフォーマルなメモが横行したりする。

さらに、情報伝達が正確にいくかという問題もついてまわる。書き物ではその行間を伝えきれないのである。こうしたドキュメントが俊敏性や効率性を損なっているように思えませんか。

一般的には、ドキュメントをきちんと書くことが大事だと教えられる。そうなのだろうかと思うのである。もちろんそれは正しい意見であるが、ドキュメントがちゃんと機能するための労力とその効果が見合うかどうかということだ。一生懸命作ってもあまり使われなくてがっかりすることも多いのである。

それと、ここで言っているドキュメントは情報伝達のためでしかないのであって、最終成果物ではないということにも起因していると思う。例えば、システム開発の最終成果物はプログラムであり、プログラムというドキュメントが重要でそれが実相をあらわしている。ですから、そういうものは本当にきちんと間違いのないものを作るのである。

こうしたことを考えると、ドキュメントを媒介にした定型逐次型では、システム開発も生産システム、業務プロセスも限界があるように思える。

個人プレーのつながりでは、スピードと変化対応力が担保できないのだ。個人ではなく組織とかチームとして機能させるほうが効果を生むことができる。その場合、紙としてのドキュメントではない違った情報伝達の媒体をもつ必要がある。もちろんそれは電子化されていて、スピード感がある情報伝達、情報共有ができるようにすることだ。それが、例えばWebサイト上のコンテンツでもいいのである。

さて、ここまできておわかりのように、紙のドキュメントを使う処理では、ドキュメントが“ブレーキ”になってしまうということなのだ。ドキュメントを介した情報伝達のところでスピードが鈍ってしまうのだ。

ただし、だからといって全面的にやめろと言っているわけではない。早く走るにはアクセルだけあればいいというものではない。ブレーキがあってこそアクセルを踏めるのである。紙のドキュメントに立ち戻ることもあるからである。ですから、いざという時のためにドキュメントがあるという意味である。

日本のある有名な会社では電子化システムと平行して紙の伝票を走らせるそうだ。もし何かあっても紙で仕事ができるようにとのことだそうだ。

確かに、ブレーキとしてのドキュメントは必要かもしれないが、紙は業務処理のスピードを抑えるわけだから、アクセルを踏みながらブレーキをかけたり、何度もブレーキを踏むようなことはやめたいのである。
 

2009年5月31日

IPAの存在意義

一昨日、IPAX2009のことについて書いているうち、つい筆が滑ってIPAはいったい何をしようとしているのかというようなことを言ってしまった。そのイベントで感じたIPAになぜ失望したかについて書く。

IPAの研究成果にしても、民間が単独でできないようなことをしてくれればいいのであって、だから、セキュリティや人材発掘、ベンチャー支援のようなことは大いにやればいいが、ほっといてよと思えるところまで手を出しているように思える。

それと、ITを取り巻く現状の問題は何なのかをきちんと分析していない。問題の所在、課題の抽出がぜんぜんできていない。

だから、正確な見積方法だとかプロジェクトの「見える化」の研究なんてやってもしょうがないと思うのである。ソフトウエアエンジニアリングの推進なんて言わないでもいいのだ。だって、開発の方法論や技術がどんどん変化している世の中で旧態依然のあり方をベースにして検討したってしょうがないと思うのだが。

こうしたことはなぜ起きるのかというと、その立ち位置がSIer側なのかユーザなのかという問題が大きい。で、IPAの上部は経済産業省の情報処理振興課だからそのその立場でどちら寄りかわかる。

そこで、その所掌事務を見ると、最初に「情報処理システムの開発及び普及」とある。ええーと思うが、これだとやはりSIerやベンダーサイドに立っているようだ。当然ながら、お国が国内のIT会社に対してシステムを開発しましょう、それをユーザに使わせましょうと旗を振っていることになる。

こういう姿勢だからいつまで経ってもSIer目線の政策しか打てないことになる。そういう観点の研究開発テーマになってくる。消費者庁ができるというのにそれでいいのだろうか?

そもそも、いまのシステム開発の実態として、ユーザとSIerが相対する関係にあることを認識しなくてはいけない。利害が一致していないわけで、ユーザ側は、低コスト高品質のシステムを短期間で作ってもらうことが望みであり、これは消費者であれば当然のことであるが、これは今のSIerにとってビジネス的に決して望ましいことではないのである。

このことが現状のIT業界が抱える最大の問題だとぼくは思う。この利害不一致のバランスがSIer側に重心がいっているため、必要もないシステムを作り続けていたり、ユーザの要求品質に答えられていないのである。

このバランスはどうあるべきなのだろうか。答えは決まっています。ユーザ側に重心を移すべきです。なぜかって、当たり前の話として、IT業界(エンタープライズ系を言っています)はユーザ企業があって初めて成り立つビジネスですから、“主”にはなれないのです。ユーザが何も頼まなかったらつぶれてしまいます。

ですから、言うまでもなく、ユーザ企業がいかにこのグローバル経済の中で勝ち残っていけるかをITが後押しすることなのです。きつい言い方をすると、IPAは日本経済あるいはユーザ企業が倒れてもIT業界だけ生き残ればいいとでも思っているのだろうか。

こういうとユーザはITのことがわからないから、こちらから提案してあげないといけないのだとくる。それをこれまでずっと繰り返してきて何がいいことがあったのでしょうか。使い手側も作り手側も両者がハッピーになれるためには従来型の発想を捨ててよく考えるべきではないでしょうか。
 

2009年6月17日

システム側のおせっかい

SIerのユーザに対する不満によくでてくるフレーズは、「要求をまとめてくれない」「仕様を決めてくれない」というものがある。だったら作らなけりゃいいと思うのだが、そんな状態でもシステム開発プロジェクトをはじめてしまうという変な産業なのである。

どうしてそうなっているかというと、人を抱えたベンダーはシステム開発をやり続けなくてはいけないのだ。一所懸命になって、「こういうことでしょ」「こうしたらいいでしょ」とユーザに言って、やみくもに突っ込んでいく。

ユーザにメリットがあろうがなかろうがどうでもいいことで、ただプロジェクトを起こせばいいというだけのインセンティブで動く。それで、ユーザはというとできてから、お前らの言うことを聞いて作ったけどこれじゃあダメなんだけどと言う。すごい世界だと思いませんか。

これは、単純にSIerを非難しているわけではない。もちろんユーザも悪い。そうした構造、関係性が歪んでいると言っているのである。それを気がついているのかいないのか誰も言い出さないというのが怖しいのである。

今から、その怖しいことを言う。SIerはおせっかいをやめたらどうだということである。ユーザに対して、こうしろああしろと言わない。ITがKPIだとかROIなんて言わないのはもちろんのこと、ユーザ側から要求仕様がちゃんと出てきたらやるという風に変えてしまうのである。

そういうと、ユーザがその要求仕様が作れないから困るんだとすぐ言うが、それでもいいじゃないかということだ。すなわち、この部分はユーザに責任をもってもらうっていう当たり前のことなのだ。

結局要求仕様というのはビジネスとしての要件が最初に出てくるわけだから、そのビジネス要件を満たすものができれば、どういう効果をもたらすかはユーザが責任もって定義したらいい。その投資対効果で実施可否を決める。

従って、両者の関係は、ビジネス側から見ると、要求はこちらでちゃんと考えるからとやかく言うな、そのかわりITでそれをきちんと実現してくれとなる。一方、IT側から見ると、ビジネス要求をちゃんと定義してくれたら、それを効率的、機能的に作ってやりましょう、あるいはこんなソリューションを使えという関係になる。

しかし、こんなことを実際にやろうとするとすごい構造改革となる。従来のビジネス形態がまるで変わってしまう。ただ、ここを突破しないと、ビジネスとITのWin-Win関係は永遠にできないはずである。もちろんなかにはこうしたことを提言する人もいることはいるが、しょせん双方から“野次っている”だけなのである。

ではここを打破するにはどうしたらいいのだろうか。ぼくは、「ベンチャーが実績を積むこと」だと思っている。使う方も作る方もベンチャーがやって、今言ったような関係を作ってしまうことをぜひ実行してほしいと願っている。そのためにクリアーにしなくてはいけないことをよく考えて乗り越えてもらいたいのである。それこそ若い元気のある人たちの出番である。
 

2009年6月19日

システム化の原点

一昨日のエントリーでユーザが本当にシステム化を必要とし、何を実現するか明確になったたときにこそITの導入をすべきで、そうした関係を築くには使うほうも作るほうもベンチャー企業同士でやったらどうかという提案をした。

どうしてそう思ったかのそのヒントは、先日ある若い人と呑んでいたとき聞いた話にある。彼は、コンサル会社を経て、事業再生を行う会社で実際に破綻した会社を再生させる仕事やっていた。

そのとき、再生のためのシステム再構築を検討するのだが、もちろんお金がないから、本当に必要なのかを見極めること、あるいは必要なところだけに投資すること、そして何よりも安いコストでなくてはやれないことを突き詰めざるを得なかったということなのである。

そして、それを実行するためには、名だたるSIerは問題外で、名は知られていないがキラリと光るものをもっていて、ユーザのために早く安く作ってくれるところを必死に探したという。実際にそういう会社があるのだそうだ。

そして、導入ではそうしたある意味チャレンジャブルな方法でやっても、誰も文句は言わない。既成のそこそこ業績をあげているような会社では、必ず壁になる社員がいるが、一旦つぶれた会社は、そんなことを言っている場合ではないわけで、這い上がるために改革しかないからである。

ぼくは、ここにシステム化の原点を見る思いがする。

今言ったような既成の会社は、誰にも文句を言われない無難な方法で、しかもお金もそこそこあるので、安心して頼めるなじみの会社にやってもらうというのが多く見受けられる。

お互い持ちつ持たれつの関係でずーっときている。ITがあるいは導入したシステムが役に立とうが立つまいが関係ないのであって、両者は継続的にプロジェクトがあることが重要なのである。

だから、お金がない、しがらみがない、既成概念がない、そんな会社が初めて正しいシステム導入ができるような気がしたのである。それに該当するのが、破綻して再出発しなくてはいけない会社なのだが、そんな会社は数多くあるわけではないので、それと似たような環境ということでベンチャー企業を対象にしたらどうかと言ったのである。
 

2009年7月 2日

社名変更

羽生さんの会社が、「スターロジック」から「マジカジャパン」に社名変更しました。そして、社名だけではなく、業容も変わるようです。

システム開発から上流設計というか要件定義の前のところに集中するようです。ですから、マジカが中心になるので社名もそうしたようです。ジャパンと付けたのが心意気を感じますよね。

この変化は、わかるような気がします。羽生さんから直接聞いたわけではないので当たっていないかもしれませんが、ビジネス的な問題と技術的な問題の両面から、今までのやり方の限界を感じていたと思います。

ビジネス的なことで言うと、先ごろ「ギョイゾー!」を出していますがそのことに関してです。「ギョイゾー!」というのはシステム開発の効率化を目指したフレームワークですが、ぼくなんかはすごく認めているのですが、世間はまだなのかもしれません。おそらく、こうした開発の効率化という価値を経済性の観点からちゃんと評価できていないのではないでしょうか。

簡単に言えば、誰がそこにお金を出してくれるかということになります。羽生さんのところは、直接ユーザのところに行って開発するというスタイルですから、お客さん自身が、システム開発を安く仕上げられるということを実感して、それで採用しますと言ってくれなくてはいけないわけです。

その場合、フレームワークそのものがこんなつくりになっていて、こんな技術を使っていますと言っても、そこには価値を見出してくれないわけで、結果としいていいものができたのかという評価しかない。

ところがこれからは次の技術的な問題とも絡んできますが、このいいものであるかどうかは、いかに上流の要求定義が正しくされていたかにかかってきます。そこがきちんとできていないなかで開発をしても、早くできたところでもともとの要求とのギャップがあったら何もならないという結果になってしまいます。

そこで、技術な問題なのですが、ここで言う技術はITではなく、いかに顧客の抱える問題を抽出し、それをどう解決するかを定義して、共有するかという技術のことです。ここなくして、どんないい開発ツールや技法を持ってきても、“必要のないものを正しく早く作ってしまう”ことになります。

たぶん、羽生さんはこのことをまた原点に戻ってしっかりやろうじゃないかと言っているのだと思います。ここのところはぼくも何回も言っているように、ビジネスとIT、事業とITの同期のためには、要求定義技術とシステム開発技術が途切れない一貫性を保つことが重要になります。

とうことで、ぼくも両方とも大事だと思っていて、めざすところは上流の要求定義すなわちビジネスとしてやりたいことを定義するとそれが実装されるということで、それを一緒に考えながらその場でできあがりイメージを見せてあげるというやり方を志向したいと思っている。

ですから、羽生さんにはぜひ「マジカ」で定義するとそのまま「ギョイゾー!」がその業務を動かしてくれるという技法を確立してほしいと願っている。それができると、ユーザが自分の仕事を早くITを駆使して実現し、改善できることの価値を理解してくれるのではないでしょうか。

2009年9月24日

正解主義のワナ

久しぶりの“ワナ”シリーズ(え、いつのまにかシリーズ化してたのというツッコミはなしで)。今回は、正解主義のワナといういことで、世の中では問題の答えが必ずある、あるいは答えは出すものだというが本当だろうかという話である。

学校で教えられるのは答えを出すことで、試験も答えを書かなくてはいけないのとその答えがひとつであるというのが普通である。でもこれっておかしいと思うことがありますよね。

だいいち、社会に出て仕事をするようになると、いつも正解がひとつあるという方が少ないかもしれない。全く合理的なものは無理で限定的にならざるを得ない。H・A・サイモンもこれを「限定合理性」と呼んでいる。

そうしたとき、よりよい答えを導きだすわけだから、そのプロセスが非常に大事になる。どれだけ、答えを出すために必要な知識や情報を持ち出せるか、それをより正しい基準で導出できるかということである。

ここで、このワナシリーズで「自動化のワナ」というエントリーを書いたが、それに関連して思うのは、自動化というのは、正解主義の表れではないだろうかということである。何がなんでもひとつの答えを出すという考えが自動化に向かうような気がする。だが、そう簡単に自動化できるとは思えない。


特に、「イノベーションの新時代」という本でも出てきた“個客経験の共創”というような概念では、答えはひとつではないというのがよくわかると思う。答えを創り出すようなプロセスなのである。そこには、決まりきったように処理すればいいやということはない。

だからといって、教育の問題へ持っていくのはいやなのだが、学校では教えてくれない答えを考え、創り出すプロセスの大切さを強調しておきたい。

これまた、業務システムにこじつけるのもいやなのだが、これまでの業務システムはこの正解主義で作られたシステムです。ですから、これからはそうではない“個客経験の共創”が実現できるシステムが求められているのです。ところで、くれぐれもこの個客には従業員も含まれることを忘れないように。
 

2010年2月27日

もうひとつの自動化のワナ

以前、「自動化のワナ」というタイトルで記事を書いたが、その趣旨は、システムを何でも自動化することは危険性があって、人間の判断や操作を入れて作った方がいということを述べている。

今回の自動化の意味は、「自動プログラミング」のことである。実は、最近このプログラミングを自動化する技術について、接する機会があって、またその有効性の検討を行っている。そうした技術をみているうちにふと疑問がわいてきたのである。

以前から自動プログラミングというのは皆さんの悲願みたいなところがあって、いろいろなチャレンジがされてきています。究極の生産性向上のめざすところというわけです。確かに、仕様を定義しさえすれば、自動的に製造してくれるとうれしくなります。しかし、本当にそうなのかということを考えてみたい。

まず浮かんだことは、いつもいつもプログラムを自動生成するということはどういうことなのかである。毎回、違うプログラムを書くから、それを自動化することが生産性の向上につながるのである。しかしながら、そのように自動化するにしても、同じことを繰り返す非生産性を前提にすることになるわけだから自家撞着ではないのだろうか。

やはり、その前提となる非生産性のところを改善することの方が重要な気がする。すなわち、類似のプログラムを繰り返し書かないように、モジュール化したり、部品化、コンポーネント化して再利用するというのが先決ではないでしょうか。

そうだとすると、そのモジュールや部品のプログラムはどうするのかということになる。それを自動プログラミングにすればいいという話はおかしいのは皆さんもおわかりだと思います。一回しか作らないプログラムを自動化する必要はありません。むしろ、そんなことをするよりも、スーパープログラマーが質の高いコードを書いて終わりです。

ですから、部品化、コンポーネント化による再利用という方向と自動プログラミングの方向は全く逆方向なのです。おそらく、自動プログラミングを進めていくと同じパターンが頻出するとそれは部品化していくと思います。ということは、自動化がめざすのは、自動化をやめることになるとも言えます。

まあ、そうは言っても現実的には、新規プログラミングの領域は残ると思うので、そういうところでは自動化し、繰り返しのところは部品化して再利用するということでしょう。要は、自動化できるからといって、何でもコードを書くのはやめた方がいいということである。なぜかというと、おそらく自動化でつくられたプロググラムの質がそう高くないと思うからである。

About 誰のためのITですか

ブログ「mark-wada blog」のカテゴリ「誰のためのITですか」に投稿されたすべてのエントリーのアーカイブのページです。新しい順番に並んでいます。

前のカテゴリは私家版業務システム変遷史です。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。

Powered by
Movable Type