Wadit Blog. tag:blog.wadit.jp,2010-11-17://1 2012-05-16T01:29:26Z 親子二人のIT企業 Wadit のブログ Movable Type 4.34-en 非定型業務のIT化　－　実装を考える tag:blog.wadit.jp,2012://1.49 2012-05-16T01:23:54Z 2012-05-16T01:29:26Z これまで、プロセスの構造や機能をどんなもににするのか、それをどう設計するのかとい... Masanori Wada http://kamawada.com/~masanori/blog/ これまで、プロセスの構造や機能をどんなもににするのか、それをどう設計するのかということを議論してきました。これからは設計されたプロセスをどうやって実装するのかという話になります。ここでもすごく重要なのはオペレーション発想です。オペレーションからの発想で構造を考え、それらがうまく機能するような設計をしたわけですが、それを実際に動かすプラットフォームに植えつけることをしていきます。

ここで、設計したものからプログラム仕様書に落としてコーディングするなんて考えないでくださいよ。もちろんそうやってもできますが、労多くして報い少なしです。設計のところでも見ていただけると分かると思いますが、特殊なこと、難しいことをやっているわけではありません。最初にオペレーション発想と言いましたのでもう一度「オペレーションとはいったい何をすることなのか？」をみていきましょう。何度もでてきたものです。

①ビジネス活動（プロセス）の進捗がわかること
②意思決定（データ確定・判断）に必要な参照情報を得られること
③コミュニケーションをしながら意思決定が行えること
④プロセス全体と単位意思決定の責任者が明確になっていること
⑤パフォーマンスの状況がわかり対応アクションがとれること
⑥オペレーションの結果がアーカイブされて、次に生かされること

簡単に言えば、これが実現できる仕組みと仕掛けをもったプラットフォームを持ってくればいいのです。ところが、こうした条件をすべて満たしてくれるものはないのです。じゃあ、やはりコーディングするかとは考えないでくださいよ。既成のソフトウエアを使ってできるだけ近づけるようにすべきです。

個々にはありそうですよね。例えば、①のプロセス進捗だとガントチャートなんかかもしれません。②では、検索やポップアップとかハイパーリンクですかねえ。③では掲示板やコメント、メールですね。④はアクセス権とかワークフロー、⑤はアラート、⑥はＢＩのようなものかもしれません。ですから、既存のソフトウエアそのものあるいはその中のひとつの機能といったものにあるわけです。

ほとんどを持っているのがＢＰＭS（Business Process Management Suite）です。ただ、それなりの価格ですので、コストパフォーマンスを考えたときに採用できる企業は限られてくるかもしれません。では、お金をあまりかけられない、あるいは効果がわからないのでスモールスタートしたいなんていう場合はどうしたらいいのでしょうか。

BPMS以外の安価な市販ソフトを利用することになります。場合によっては組み合わせて使うことをします。安価になるということは基本的には機能不足になるわけで、そこは人力で補足することになります。自分たちの身の丈にあったコストパフォーマンスを選択することを勧めます。

さて、具体的にどんなプラットフォームがあるのでしょうか。それを見るとき、プロセスの構造を思い出してください。2段プロセスです。プロセスの進捗をみるマクロフローと単位意思決定を行うミクロフローの組み合わせになります。簡単に言うとそれぞれを何でやるかになります。それらの組み合わせ例（マクロフロー＋ミクロフロー）をご紹介します。

Case－A　　BPMS（メインプロセス）＋BPMS（サブプロセス）
Case－B　　BPMS＋コミュニケーションツール（CMS、wiki、BTSなど）
Case－C　　手書きあるいは進捗管理ツール＋Webデータベース（デヂエ、Salesforceなど）

Case－Bのコミュニケーションツールは例えばPlone とかMTといったCMSではWebサイトの編集作業をそこで行うが、リンク情報を参照したり、承認ワークフローがあり、コメントも書き込めるので意思決定の場として使えます。その決定結果をBPMSに渡し、BPMSでプロセスを進めるといった動きになります。

Case－Cはプロセスエンジンを持たないケースです。ですからそこは人間が回すことになります。こんなことを言うとプロセスエンジンを使って自動化しないと意味がないという指摘をされそうですが、プロセスエンジンの重要性はそれほどないというのが現実です。この話はまた別途します。意思決定というのは最終的には決定された情報を登録しまうから、データベースソフトを利用します。例えば、サイボウズデヂエ（最近はKintone）のようなものが使用可能です。

少し飛躍するかもしれませんが、ARISとSAPの組み合わせでプロセス管理をする事例がありますが、この考え方も基本的には同じです。つまり、ARISでプロセス記述をしておき、そこの進捗に従って、SAPの機能と連動させるものです。

さて。この次からは具体的な実装の話になるわけですが、上記のプラットフォームのうち、サイボウズ社が昨年からデヂエの後継として売り出しているクラウド型のWebデータベース「Kintone」を使った実装についてシリーズを改めてエントリーすることにします。
　　
]]> 非定型業務のIT化　－　ITを考えないで業務オペレーションを描いてみる tag:blog.wadit.jp,2012://1.48 2012-05-10T01:25:18Z 2012-05-10T01:29:22Z どうやって実装するかの前に「ITを考えないで業務オペレーションを描いてみる」こと... Masanori Wada http://kamawada.com/~masanori/blog/ どうやって実装するかの前に「ITを考えないで業務オペレーションを描いてみる」ことをしてみましょう。このエントリーのタイトルが「非定型業務のIT化」ですからそれを否定するような言い方で矛盾していると指摘されそうですが、単にIT化するのが目的でなくて、言外にビジネスの役に立つためのITという意味が含まれています。

つまり、ビジネスに貢献できないようなITなら入れない方がよいということです。ですから、大事なことは最初からIT化ありきではなく、ITを考えない中でその業務システムをオペレーションできるか、どんなオペレーションになるのかをみておくことも必要ではないかということです。

さて思い出してほしいのですが、業務プロセス設計でどんなことを決めたでしょうか。まずはプロセスフローを決めることをしました。そしてプロセスフローとは、アクティビティ(意思決定項目)の選定と順番というふうにしました。このことはオペレーションという観点では何を意味しているかというと、意思決定の進捗を管理することになります。

プロセスフローが決まると、確定情報、参照情報、適用業務ルール、ロール、制御変数などのアクティビティの属性を決めていきます。つまり、意思決定というのは結果としてある情報を確定することなので、その決定すべき情報とそのためにどんな参考情報やルールをみるのか、だれが決定・承認するのか、何をコントロール・監視するのかを決めることになります。

これも、オペレーション的には、迅速で質の高い意思決定を行えるように多くの有用情報を素早く取り出せ、知恵を持った人たちの助言を受けたり、上司と相談でき、また制約やコンプライアンスのチェックがなされる環境があることでしょう。こうしたことはパフォーマンスという面を考慮しなければITがあろうとなかろうと関係ない行動です。

そうなんですよね、ITがなければこうした行動、活動ができないのではなく、ITはあくまで早く、速く、多く、強く、高くなど"形容詞的"効果をもたらすものなのです。主語・述語・目的語、そして名詞・動詞はITには無関係です。では、プロセス設計されたものをITなしでのオペレーションをした場合を考えてみましょう。すなわち、コンピュータがない時代の業務です。

プロセスフローというと箱を矢印で結んで書かないといけないように思えますが、昔は"仕事の段取り"だとか、"工程表"などを紙に書いたり、黒板に書いたり、またカレンダーにマグネットを置いて管理したりしていました。有用情報は紙でキャビネットにあるバインダーに綴じられているものがほとんどです。そのページを指でめくって探したものです。他にも新聞の切り抜きをスクラップブックに貼ったりしました。マイクロフィルムというもありましたね。

コラボレーションというのも、隣のひととメール交換する現代よりもっとまともなコミュニケーションをしていたような気がします。何かあると皆が机の回りに集まって来てなんだかんだと議論しましたし、電話やFAXでやりとりもよく行われました。もちろん、契約書だってありますからちゃんとチェックしていました。期日管理なんていうのも大きな張り紙があったりしました。

こうしてみると、やっていることはいつの時代でも同じだったのです。しかし、それが効率的であるのか、迅速性がないのか、狭量的になっていないのかといった問題を抱えていたわけです。もっと早くやりたい、もっと多くのことを知りたい、もっと高度にしたいといった欲求不満を解消してあげる必要が生じたのです。

例えば、プロセス管理をホワイトボードでやると何が問題なのかというと、ホワイトボードに書ける情報量が少ないこと、書いてあることを手元で見られないあるいは遠隔地と共有化できないといった問題が出てきます。同じように、いつも紙をキャビネットから取り出してめくるのは嫌だなとか、書き写す手間が大変だなとか、情報を得るのに役所や図書館までいかなくてはとなるのです。

さて、もうおわかりかと思いますが、そういった欲求を満たしてあげるものとしてITが存在しています。この領分ではコンピュータが登場してからずいぶんと大きな貢献をしていると思います。取得する情報の量と速さはとてつもなく多くそして速くなっています。ただ、だからといってやみくもにITを導入すればいいというのではなく、身の丈にあった導入をはかるべきだと言っています。

ITがなくてもやってきたわけですから、それほど多くの情報量が必要でない会社、簡単なプロセスしかない会社は無理にIT化しなくても人間が介在することでも十分できるならそれでもよいと思う。つまり、人間とITがうまく役割分担して、ベターな仕組みを作ればよいのです。こうして考えると、業務システムをプログラミングして自動化を図るというアプローチが何だかおかしく思えてきませんか。
  
]]> 非定型業務のIT化　－　業務プロセス設計だけで実装できる？！ tag:blog.wadit.jp,2012://1.47 2012-04-30T03:22:00Z 2012-04-30T03:22:50Z 前回は、業務プロセス設計が肝であるという話をしました。普通はＶモデルのような開発... Masanori Wada http://kamawada.com/~masanori/blog/ 前回は、業務プロセス設計が肝であるという話をしました。普通はＶモデルのような開発工程があります。要求分析－基本設計－機能設計－詳細設計があってコーディングをして、そのあとそれぞれのレベルに対応した単体テスト－総合テスト－システムテスト－受け入れテストというわけです。では、業務プロセス設計というのは、どこに相当するのでしょうか。

どうも、このモデルとはマッチしませんね。それもそのはずです。コードを書かないからです。Vモデルは谷の底がコーディングです。つまり、コードを書くために一連の設計があってテストがあるわけで、そのコーディングがないのだから適用できないのです。そもそも、Ｖモデルはソフトウエア製品の開発に対してのものであって、それを業務システム開発に当てはめるのが間違っています。

というわけで、非定型業務で業務プロセスの設計がちゃんとできたらすぐに受け入れテストして運用ができるのです。なぜそんなことができるのかを考えていきましょう。というか、もしプログラマーがいなくて、あるいはお金がなくて開発費用が出せないといった制約の中で業務システムを作ろうとしたらあなただったらどうしますか。あきらめますか？

ユーザの人たちはどんなプロセスで仕事をしたい、業務を回したいという要求を出してくれたわけだから、その通りに動くものをつくればよいと思ってください。そこから余計な機能を引っ張り出すことも、凝った作りにすることも必要ありません。そして、何も全部ITでやれなくてもいいわけで、できなかったら人間がやればいいかもしれない。

ここのところが非常に重要なところで、業務システムの構築（ソフトウエアとかいＴ製品ではありませんよ。間違わないように）は、けっしてITシステムを構築しなければいけないなんて誰も言っていないということです。SIerやITコンサルのひとたちが言っているだけでしょ。つまり、プロセス設計で定義したことを実現できるものをどこからか探してきて組みあげればよいのです。

もちろん、それだけではできない場合があります。例えばシステム間の連携なんてひょっとしたらコードを書かなければいけないケースもあると思います。だが、それは仕方なしにそうするのであって、最初からコードを書くために設計してはいけません。データ連携にしても近頃はコードレスでマッパーで設定さえすればできるものも出てきています。

そうなんですね。いまここで言っていることは昔はなかなか難しかったのは確かですが、最近はいいソフトウエア部品がいっぱいあります。ですから、プロセス設計で定義し機能に合致した、あるいは機能は落ちるけど何とかできそうだという市販の汎用的なソフトウエアを選択してきて、それらを組み合わせて構築することを勧めているのです。
　　

]]> 非定型業務のIT化　－　業務プロセス設計が肝 tag:blog.wadit.jp,2012://1.46 2012-04-23T01:22:49Z 2012-04-23T01:32:09Z 前回は、Howということでどのようにして設計して実装していくかについてとっかかり... Masanori Wada http://kamawada.com/~masanori/blog/ 前回は、Howということでどのようにして設計して実装していくかについてとっかかりの考え方について議論しました。そこでは、プロセス中心、プロセス先行でみていくことが大切だということを言いました。今回は、設計のところを具体的にどのように進めるかについて考えていきましょう。

このエントリーのタイトルが「非定型業務のIT化」ですので、非定型業務であるがゆえの特徴をまず考えてみます。IT化のための設計というとどうしてもプログラムを書くためとか、パッケージを適用するための設計といったものになりがちです。いわゆる「要件定義」という行為が設計だと思ってしまうことがあります。ここはよく考えなくてはいけない問題で、一生懸命ユーザの人が業務上の要求を出しても、結局はITのための設計に行ってしまうので断絶が生じてしまうことがよくあります。

使う側の人たちが欲しているのはうまく仕事をする、円滑に業務を回すための仕組みと仕掛けを作ってくれと要望しているのであるから、極端なことを言えばどんなプログラムを書こうと、どんなソフトウエアを使おうともそれが実現できればいいのである。つまり、だいぶ前「Whatはオペレーションから発想する」に書いたようなWhatをどうやって作るのかなのである。もう一度、オペレーションプラットフォームが持つべき要件を思い出してほしい。

①ビジネス活動（プロセス）の進捗がわかること
②意思決定（データ確定・判断）に必要な参照情報を得られること
③コミュニケーションをしながら意思決定が行えること
④プロセス全体と単位意思決定の責任者が明確になっていること
⑤パフォーマンスの状況がわかり対応アクションがとれること
⑥オペレーションの結果がアーカイブされて、次に生かされること

これらの要件はユーザの人たちが実際にビジネスの現場でやっていることを表現しています。ですからこれらを満足させるための設計はいかにあるべきかが大切なのです。そして、ここにはプログラムがどうの、ソフトウエアがどうのということは出てきません。非定型業務のIT化にはこのレベル感が非常に重要になってきます。

いまの要件定義といわれているようなことはこの一段下のレベルのことを言っています。つまり、定型的な業務に落ちてしまっています。どんな画面や帳票でとか、ロジックはどうするのかとか、バリデーションはこうだとか、それって"非定型業務の結果を登録する定型化された業務"でしょう。

ちょっと話はそれますが、設計で機能要求とか非機能要求、あるいは外部設計とか内部設計といった言い方がありますが、意味は何となくわかるのですが、なぜ分ける必要があるのかとか、システムを使う人が理解できるのだろうかと思ってしまう。ましておや、これからクラウドの時代にはそぐわないだろう。

ということで、設計で大事なのは業務プロセス設計になります。先ほど提示したオペレーションプラットフォームの持つべき要件を満足させるために業務プロセス設計で決めることは何でしょうか。まずは、プロセスフローを決めることになります。ではそのプロセスフローとは何かですが、アクティビティ(意思決定項目)の選定と順番になります。ただ、順番は厳密なものではありませんのでだいたいの流れでかまいません。

それが決まると、アクティビティの属性を決めて行きます。意思決定をするために定義しておかなければいけない項目です。それは、確定情報（データ、判断、文書）、参照情報（事実情報、判断情報、制約情報）、適用業務ルール、ロール（権限、参加者、承認者）、制御変数（プロセスメトリクス）となります。実際には、これらの基本情報に付帯する情報も必要に応じて定義しておきます。非定型業務の設計はこの程度でかまわないのです。緩すぎないかと思うかもしれませんが、要するに非定型なのですから定型化してはいけないのです。
　

]]> 非定型業務のIT化　－　Howを考える tag:blog.wadit.jp,2012://1.45 2012-04-16T00:58:13Z 2012-04-16T00:58:53Z さて、これまではWhat を考えてきましたが、ここからはHowについて検討してい... Masanori Wada http://kamawada.com/~masanori/blog/ さて、これまではWhat を考えてきましたが、ここからはHowについて検討していきましょう。ビジネスの貢献する仕組みと仕掛け、すなわちプロセスの構造とか機能をどんなものにするのかから、それをどうやって設計し、実装していくかという問題です。

そこで重要なコンセプトを思い出してください。「Function/Data Oriented」「Development Excellence」「Independent Work」から「Process Oriented」「Operation Excellence」「Collaborative Work」にシフトしましょうということを提案しました。この新しいコンセプトに沿ったHowを考えて行きます。ただ、「Development Excellence」から「Operation Excellence」だから、開発はあまり重要ではないと思わないでください。重点が移動したのであって、まだその重要性は変わりません。

Howの最初はプロセス設計になりますが、そこで大事なのは「プロセス中心アプローチ」という考え方を理解することです。設計ではプロセス中心というよりもプロセス先行といった方がわかりやすいと思います。言葉のとおり、まずプロセスを作っておいてそこにそれ以外の要素を定義していくというやり方です。

こういうことを言うとそれはデータ中心でやるべきだとかという声が聞こえてきます。なるほどDOA（Data Oriented Approach）ですね。以前にも何回かこのブログでも言及しましたが、プロセス中心かデータ中心のどっちを取るのかという議論ではなく、向き不向きがあるので使い分けることが大切です。

つまり、データでマスタのようなリソース系のデータ（名詞形で表現できる）はデータ中心でやるべきです。リソース系というのは、企業活動の原動力になるわけですから、個々のプロセスには関係なく前もって決めておくものです。例えば、従業員データとか取引先マスタといったものは、それがビジネスを動かすためにあるというか、手持ちのリソースを使ってどんなビジネスをするのかが決まったりします。しかも全社に渡って使われるものですから、あらかじめデータベースを設計しておくことをします。

一方、トランザクションから発生するようなイベント系のデータ（動詞形で表現できる）は、プロセス中心でやるべきであると主張しています。イベントデータはプロセスがあってこそ存在するわけですから、まずは企業活動の一部としてどんなプロセスがあって、そこで生成するデータは何かというアプローチになるわけです。

例えば、受注データというイベントデータは、受注プロセスから出てきますし、売上データも同じように販売プロセスと対になっています。取引先データは購買プロセスから出てきませんよね。ですから、理想的にはプロセスを正規化しておけばイベントデータも正規化されることになります。このことは業務の標準化や共通化という視点からも重要なことだと思います。

ということで、データ中心ではプロセス設計はかなり難しくなりますので、プロセス先行設計を勧めています。まず最初に業務の流れを中心としたプロセスを描き、そこに必要なデータは何か、使うユーザインターフェースはどんなものにするのか、どんな業務ルールに従うのか、責任の所在はどこにあるのか、何を測定してコントロールするのかといったことを設計、定義していくのです。

このやり方は、実はユーザの人たちにとってもなじみやすいこともあります。なぜならば、業務の流れとか、仕事の段取りといったようなことって結局プロセスだよねということです。データフロー図（DFD）を追っても、ER図をながめてもユーザの人はなかなか理解できないのではないでしょうか。
　

]]> コンサルティングの成果が紹介されました tag:blog.wadit.jp,2012://1.44 2012-04-13T02:33:14Z 2012-04-13T02:34:47Z 昨日のソフトバンクの「ビジネス＋IT」に先月の「BPMフォーラム」のセッションで... Masanori Wada http://kamawada.com/~masanori/blog/ 昨日のソフトバンクの「ビジネス＋IT」に先月の「BPMフォーラム」のセッションで発表した事例についての記事が掲載されました。「ある油圧機器メーカー社長が掲げた「特注品で売上を伸ばす」を実現したBPMの取り組み」と題した内容で日本BPM協会の岩田アキラさんの「BPM推進フレームワーク」の紹介に続いて、ぼくが一昨年と昨年に参加した「業務見える化」プロジェクトの成果を発表したことについて書かれています。

１カ月以上も前なので今ごろかとか、記事のジャンルがコスト削減だったといったツッコミはあるにしても、こうして記事にしてくれたことは単純にうれしい。フォーラムでの話は「BPM推進フレームワーク」に準じて実行したら成功しましたという流れですが、実際には同時進行といった方があっていて、つまり、実際のプロジェクトをやりながら、一方ではフレームワークの作成も行っていた。

まあ、結果的には推進フレームワークに則ったやり方だった、あるいは実際にやって効果を出したことをフレームワークに反映させたということになります。これはぼくが両方にかかわっていたからこそとちょっぴり自負しています。 今ではBPM協会の「BPM入門セミナー」でも紹介されています。具体的な事例があるのとないのとは雲泥の差があります。掛け声だけでは説得力がないのでこうした事例を交えた進言が意味があるのです。

事例があるというのは、ただやってみましたということではなく、きっちりと成果を出さなくては意味がありません。記事に出ている会社ではすぐに成果が定量的にもでてきたという成功例です。それが、単に業務プロセスを見える化したからだけではなく、経営者のリーダシップ、進取の精神に富んだ企業風土の醸成、情報共有・コミュニケーションの活性化、技術・ノウハウの継承、人材育成など多くの要因によって達成されています。

ですから、コストダウンという即物的なジャンルで括られても困るのですが、非常に参考になる取り組みです。日本の中小企業が強くなるヒントが詰まっているように思います。（大企業にも当てはまると思いますが、組織の壁と決定のスピード感のなさ、リスクテイクできない体質という問題が横たわっていてすぐの実行は難しい）現在も続いていますので、また新たな成果が出たら紹介していこうと思います。
  

]]> もしSIerのエンジニアがジョブズのスピーチを聞いたら（４） tag:blog.wadit.jp,2012://1.43 2012-04-09T02:05:28Z 2012-04-09T02:09:10Z 上流・下流の分断の話が、ソフトウエアの開発と業務システムの構築の混同により、議論... Masanori Wada http://kamawada.com/~masanori/blog/ 上流・下流の分断の話が、ソフトウエアの開発と業務システムの構築の混同により、議論がちぐはぐになっていることを指摘した。つまり、業務システムを作る商売をしているSIerがソフトウエアを作ることと勘違いして、相変わらず業務システムのためにプロジェクトごとにコードを書いていること、ソフトウエアのようなプロダクトアウトの発想であること、また顧客ニーズをわかっていないことのために起こっている問題なのであって、まずはそこの勘違いを正すことではないでしょうか。

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

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

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

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

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

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

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

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

]]> もしSIerのエンジニアがジョブズのスピーチを聞いたら（３） tag:blog.wadit.jp,2012://1.42 2012-04-08T01:28:13Z 2012-04-08T02:11:04Z 前回、上流と下流の分断の問題をソフトウエア開発のケースで論じたので、今回は業務シ... Masanori Wada http://kamawada.com/~masanori/blog/ 前回、上流と下流の分断の問題をソフトウエア開発のケースで論じたので、今回は業務システム開発のエリアの話をしましょう。まずは、業務システム開発とソフトウエア開発とでは明確に違うということを指摘したいと思う。大きな違いは、プロダクトアウトかそうでないかです。

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

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

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

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

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

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

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

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

]]> もしSIerのエンジニアがジョブズのスピーチを聞いたら（２） tag:blog.wadit.jp,2012://1.41 2012-04-04T01:15:13Z 2012-04-08T01:30:02Z ぼくは最近、昼メシを自分で料理することにしている。同じ敷地にある家に住んでいたぼ... Masanori Wada http://kamawada.com/~masanori/blog/ ぼくは最近、昼メシを自分で料理することにしている。同じ敷地にある家に住んでいたぼくの母親が老人ホームに入ったので台所が使えるようになったからである。以前から昼メシは自分で何とかしてくれとヨメさんに言われているので外食していたのだが、自分で作ることにした。

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

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

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

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

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

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

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

]]> もしSIerのエンジニアがジョブズのスピーチを聞いたら（１） tag:blog.wadit.jp,2012://1.40 2012-04-03T02:15:31Z 2012-04-03T02:25:29Z 最近、いわゆるSIerと呼ばれる業態がヤバそうだという話が聞こえてくる。富士通の... Masanori Wada http://kamawada.com/~masanori/blog/ 最近、いわゆるSIerと呼ばれる業態がヤバそうだという話が聞こえてくる。富士通の3万人のSE職の転換とかが話題になった。おそらくどこのSIerも相当の危機感を抱いているのちがいない。従って、そこで働いているエンジニアのかたがたもこれからの行く末に悩んでおられると思う。

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

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

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

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

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

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

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

]]> 非定型業務のIT化　－　プロセスの基本構造 tag:blog.wadit.jp,2012://1.39 2012-03-27T01:05:41Z 2012-03-27T01:06:09Z 前回は、業務プロセスの骨格ということで、始点が依頼を受付けることで、中間点として... Masanori Wada http://kamawada.com/~masanori/blog/ 前回は、業務プロセスの骨格ということで、始点が依頼を受付けることで、中間点として意思決定というアクティビティをつなげて作業をおこない終点である報告・登録で終えるというものを提示した。今回はそれをもう少し骨組みの中味を探ってみることにします。

非定型業務をIT化するときこのプロセスの構造ということが非常に重要になります。つまり、非定型といってもはなから非定型ではなく階層化された中で、あるレベルになると非定型になるというものだからです。その一歩手前の定型化された構造をきちんと設計しモデル化することが大事なのです。

さて、そのプロセスの基本構造ですが、前回の骨格をプロセス化すると、依頼受付―単位意思決定の連鎖―作業―報告・登録となります。次に検討しなくてはいけないのが、単位意思決定の中味はどんなことをすることなのかになります。実はこの中もプロセスになっています。ですので、最初の方がマクロフローで、意思決定のところがミクロフローということがいえます。

つまりこの2段プロセスが基本構造の重要な考え方となります。マクロフローのレベルではほぼ定型的な動きになりますが、ミクロフローでは非定型的、すなわち行ったり来たり、ケースバイケース、人間の判断、調整といった決まりきった動きではないことが多くなります。ですから、順序が定型化されたものとして構造化できないのでこれ以上分解をしない方がよいということになります。

皆さんが普段やられている仕事や組織としての業務をごらんになればわかると思いますが、おおまかな流れは決まっていますが、細かいところでは決まりきったものってそう多くはないと思います。そうですよね、もしそうならば、派遣社員にまかせればいいし、中国へアウトソーシングすればいいわけです。非定型業務こそが差別化や競争優位の源泉であるのです。そんなところって単純なITではできるわけではないということがわかると思います。

さて、それでは意思決定プロセスというのはどうなっているのかですが、前回サイモンの意思決定プロセスということを提示しました。具体的に考えてみましょう。最初の情報活動とは意思決定に必要となる情報を収集することです。次の設計活動は代替案の探索・代替案の評価、つまり起案したものを検討・評価してこれでいこうという最終案を提示し、選択活動では代替案の選択、つまり意思決定と承認を行うわけです。

こうした活動を行う場合、前に言ったように定型的ではありませんから、手順を自動化するようなIT化はできません。ですから簡単に言うと"質の高い意思決定を早くできるような環境を提供する"ことが求められるのです。ではそうした環境とはいったいどんなものなのでしょうか。

それは、情報共有・コミュニケーションと有用な情報サービスの取得による意思決定ができる場ではないでしょうか。非定型業務では、チーム間や外部とでコミュニケーションをとりながら、調整や相談をすることをします。また、それぞれの活動で情報を必要としています。例えば、情報活動では事実情報、設計活動では判断情報、選択活動では制約情報といった種類のものがあると意思決定の質は上がります。

結局、プロセス構造は依頼を受付けて答えるまでのマクロフローとそこにあるミクロフローである単位意思決定を行う情報共有・コミュニケーションの場と情報サービスを受けられる仕組みがプロセス基本構造となるのです。
　

]]> 非定型業務のIT化　－　業務プロセスの骨格 tag:blog.wadit.jp,2012://1.38 2012-03-24T08:30:59Z 2012-03-24T08:31:29Z 前回は、オペレーションプラットフォームが持つべき6つの要件について考えてみました... Masanori Wada http://kamawada.com/~masanori/blog/ 前回は、オペレーションプラットフォームが持つべき6つの要件について考えてみました。今回からは、こうした要件を満たしてくれるプロセスの構造について考えていきます。こうして、オペレーションから発想したプロセス設計が大事なってきます。

業務オペレーションはいったい何をすることなのかというと超簡単に言うと、顧客の依頼あるいはサービス要求に答えることです。そして、その答えを作るのにはいくつかの意思決定を行うのが普通です。そうした意思決定の連鎖つまり答えを作っていく過程をプロセスと規定しています。ここで顧客と言いましたが、狭い意味のお客さんだけではなくて、取引先、サプライヤー、経営者、従業員といったところからも依頼がきますので、それらを含めた広い意味での顧客を想定しています。

プロセスは大まかに言うと、始点と終点があってその間にアクティビティとよばれるものがある構造になるわけです。アクティビティはだいたいは単位意思決定というふうに考えてもらってかまいません。ではまずプロセスの出発点すなわち始点は何なのでしょうか。それは最初にいったように依頼が来てから始まるわけですから、「依頼を受付ける」ことが最初になります。

この場合の依頼の来方は様々です。電話やFAX、メールなんていうこともありますし、注文書とか依頼書とかいった紙で来る場合もあります。最近ではEDIみたいなシステム的な依頼形態もあります。しかしいずれも一旦受付けてその依頼内容を確認することをします。非定型業務だと必ずしますが、定型業務だとそのままエスカレーションすることもあります。

依頼を受付けるとその依頼項目に従って答えを作ることになります。答えを作るのが意思決定でこれも実はプロセスでもあります。意思決定プロセスというとH・A・サイモンのものが有名ですが、もうそのままです。サイモンの意思決定プロセスは、情報活動、設計活動、選択活動、検討活動の4つから成り立っています。

意思決定に必要となる情報を収集（情報活動）して、代替案の探索・代替案の評価（設計活動）を行い、代替案の選択（選択活動）し、実施し、その結果をフィードバック（検討活動）することです。日常のプロセス管理では初めの3つが重要な要素となります。

こうして、意思決定を行って、答えを作るのに何か作業がいるようなら、作業というアクティビティが入ってきます。例えば、見積を出すのに見積書作成という作業があってそれが入ることがありますし、修理依頼がきたら実際に修理作業を行って修理調製品として返すなんてこともあります。

作業が終わって、依頼に対する回答がそろうとそれを依頼元へ返事を返さなくてはいけませんし、結果をデータベースに登録しなくてはいけません。このアクティビティが終点となります。報告・登録を行ってこのプロセスが完了するわけです。こうした構造がプロセスの骨格となります。
  

]]> 非定型業務のIT化　－　オペレーションとはいったい何をすることなのか？ tag:blog.wadit.jp,2012://1.37 2012-03-19T02:37:57Z 2012-03-19T02:51:27Z 前回は、Ｗhatすなわちプロセスの仕組みはオペレーションから発想すべきという提案... Masanori Wada http://kamawada.com/~masanori/blog/ 前回は、Ｗhatすなわちプロセスの仕組みはオペレーションから発想すべきという提案をしました。このプロセスオペレーションというのはおおかたは非定型業務になります。定型の場合は自動化できるので人間によるオペレーションという範疇からは外れるからです。IＴに任せてしまうようなプロセスではなく、人間が介在して扱うプロセスは非定型でそのオペレーションを適切に行うためにはどんな道具が必要であるのかという発想です。

このことは何回も繰り返しますが、システムは使ってナンボ、使われてナンボだからです。決して作ってナンボではありません。従来のシステム開発の発想が作るところが主眼になっていて、それがどう使われようとも、いやもっときつい言い方をすると使われなくてもかまわないとういうスタンスだったように思います。そこを逆転させる必要があるわけで、作ったものを使ってもらうではなく、使われるものしか作らないということになります。

こうした発想になると、ITシステムというよりオペレーションプラットフォームをどうするか、どんなものの上で業務を遂行するのかというアプローチになります。そうしたプラットフォームが持つべき要件にはいったいどんなものあるのでしょうか。こんなものがあったら、こんなことができたらいいなあというものです。次のように考えています。

①ビジネス活動（プロセス）の進捗がわかること
②意思決定（データ確定・判断）に必要な参照情報を得られること
③コミュニケーションをしながら意思決定が行えること
④プロセス全体と単位意思決定の責任者が明確になっていること
⑤パフォーマンスの状況がわかり対応アクションがとれること
⑥オペレーションの結果がアーカイブされて、次に生かされること

このことは、別にITシステムだからというわけではないのがお分かりだと思います。ITがなかった昔から行われていました。例えば、進捗管理は黒板や模造紙に書いて眺めていたり、電話や机の前の会話で意思疎通を図ってしたし、参照情報はキャビネットのファイルを拡げたり、新聞のスクラップブックを見たりしていました。責任者にしても、昔の方がちゃんとしていたかもしれないし、対応アクションも現場の課長が的確に指示し早かったかもしれない。記録も紙だったけど報告書を書いていた。

つまり、何を言いたいかと言うと、ITに関係なく業務プロセス、仕事を効率的にかつ質の高いものにできるなら、そこにITを入れていくという心構えが大切であるということです。何も、ITで今までと違う特別なことをするわけではなく、ITを使うことで早くできたり、多くの選択肢から選べたり、助言や指導が受けやすかったりできるようになるということなのです。

ただ、ここで忘れてはいけないのが、今までと違う特別なことをするわけではないと言いましたが、それはあくまでITのレベルの話なのであって、業務プロセスのところでは、従来と違ったものを設計していくことが大事であるということです。こんなことを言うと、インターネットや、最近のスマートフォンやiPADの登場で仕事のやり方が変わりじゃないかと突っ込まれそうですが、確かにビジネスモデルが変わって、プロセスの変更もあると思いますが、あくまでHow toのところの話が主なような気がします。

結局大事なのは、ビジネスに貢献するための業務プロセスの仕組みと仕掛けの設計のところで、ここが肝だということなのです。それをはき違えるとやれクラウドだiPADだとか、ビックデータだとかが出てくると右往左往してしまうのです。そうしたデバイスやテクノロジーを有効に使えるようなプロセス設計ができていないといくらハイテクを入れても猫に小判システムができるだけで意味がないと言いたいのです。
 

]]> 非定型業務のIT化　－　Whatはオペレーションから発想する tag:blog.wadit.jp,2012://1.36 2012-03-16T01:42:14Z 2012-03-16T01:42:47Z 前回は、Whatすなわちプロセスの仕組みを考えるとき既成概念から離れて新しいコン... Masanori Wada http://kamawada.com/~masanori/blog/ 前回は、Whatすなわちプロセスの仕組みを考えるとき既成概念から離れて新しいコンセプトのもとで考察すべきだとし、「Process Oriented」」「Operation Excellence」「Collaborative Work」というコンセプトを提示した。この考え方をベースにWhatをみていきます。

なぜ、オペレーションから発想すべきなのでしょうか。ここはなかなか気がつかないのですが、非常に重要なことです。つまり、上にあげたコンセプトの二番目にあるOperation Excellenceというのは、従来のように作ったら終わりではなくオペレーションして成果を上げて初めて終わりになるということを意味しています。ですから、成果をあげられるものでなくては使わないぞというユーザの意思であり、使ってもらってこそのシステムの価値が出るのです。

もう何度も言っていますが、作ってナンボではなくて使ってナンボなのです。使ってナンボと言っても単に使うだけではなく、結果的に目標を達成して事業成果に結び付かないと意味がありません。従って、オペレーションという中には、コントロールという意味合いも含んでいることを忘れてはいけません。コントロールというのは、制御対象の測定値が目標から乖離していた場合、それを近づけようとして手を打つことです。

プロセスマネジメントの重要な要素にこのコントロールという概念があることも忘れてはいけません。というかある意味肝のところでもあります。戦略目標からKGIとかKPIといった定量的な指標に落ちてきて、さらにプロセスメトリクスというようなオペレーションレベルの指標となります。こうして、定性的であいまいな指標ではなく、具体的な目標値をコントロールすることで成果を出すことが求められているわけです。

それと、コントロールできるかどうかは、測定値をきちんとモニタリングできているのかも大事になってきます。当然正しく、そして所定のタイミングでセンシングできないと適切なレスポンスが返せないのである。このセンス＆レスポンスが不十分だと、手を打つタイミングを逃したり、危険を察知するのが遅れたりする。化学プロセスなどはここが命でうまくいかないと事故を起こしたりしてしまいます。ビジネスプロセスも基本的には同じ考え方でみていくべきだと思います。

以上のように、正確なモニタリングにより、適正なコントロールが行われ、結果的に効率的なオペレーションが維持されている状態が必要があって、それを実現させるために使う道具は何かという話です。よくそれはプラントのように自動制御でやればよいのではと言われます。

しかし、実は化学プランスのようなものとビジネスプロセスの違いがあって、何が違うかというと、科学的、論理的なのか、そうでないのかということです。ビジネスプロセスは、人間の判断という要素がたっぷり入りこんでいますので、非科学的で非論理的な部分が多いからです。ですから、多くのビジネスプロセスには、自動化されたシステムではなく、人間が使う道具が欲しいのです。
　　

]]> 非定型業務のIT化　－　新しいWhatを考えるためにコンセプトを変える tag:blog.wadit.jp,2012://1.35 2012-03-09T01:19:48Z 2012-03-09T01:25:02Z 前回は、WhatはHowに優先するということが非常に大事であるという指摘をした。... Masanori Wada http://kamawada.com/~masanori/blog/ 前回は、WhatはHowに優先するということが非常に大事であるという指摘をした。悪いWhatをいくら良いHowで作っても意味がないのである。それなのに、巷ではHowの話ばかりしていて肝心のWhatの議論がほとんどない。30年間ずっと変わらないWhatの疲労がきているのにもかかわらず。

さて、Whatとは何か。まずは少し抽象的ですが、概念を言おうと思います。「Whatとは、ビジネスの貢献する仕組みと仕掛け」としてみました。仕組みというのは別の言葉で言うと構造ですね。おなじく仕掛けは機能とでも言ったらいいかもしれません。要するに、単なる箱ではなく、仕掛けをもった、機能を具備した構造体を指しています。

ここで具体的な中味を議論する前に、コンセプトレベルでもこれまでと違った見方をする必要があります。小手先だけ変えるのでは本質的な変革はできません。これはおおげさに言えばパラダイムの転換ということです。では、これまでの「ものの見方や捉え方」はどうであってこれからどう変えるべきなのでしょうか。

システム開発あるいは業務システムの世界での従来の考え方の特徴を３つあげると、「Function/Data Oriented」「Development Excellence」「Independent Work」だと考えています。最初のFunction/Data Orientedというのは、システムを作る時に画面から、あるいはデータから考えるということです。もちろん、データ、機能、プロセスのどれもが必要なのですが、どれを中心に、あるいは先行してアプローチするかということで、これまでは画面やデータを中心にというやりかたが多かったのです。

Development Excellenceというのは、開発が目的化しているという意味になります。システム屋さんに開発してもらったはいいが、プロジェクトが終わるとさっさと引き上げてしまい、どんなふうに使われているかは無関心ということが多いと思います。要するに作ってナンボの世界なのである。

後のIndependent Workというのは、作られたシステムは、個人が画面に向かってデータを打つ、帳票を出すためのものになっていることを言っている。コンピュータは決まった時間に決まったフォーマットでデータを入れろと命令してくる。それに個人が一生懸命答えているという姿が浮かんできますよね。

どうもこれではいけないと感じていると思うのですが、ではどう「ものの見方や捉え方」を変えるのでしょうか。上に挙げた3つに対しての新しいコンセプトは、「Process Oriented」「Operation Excellence」「Collaborative Work」です。画面やデータに対してプロセスを中心に考えましょうということ、作ってナンボではなく使ってナンボなんですよということ、個人の作業ではなくチームとして情報共有の場で仕事しようよという意味になります。

新しいコンセプトと言いながらふと考えたのは、別に新しいことではなく昔から業務や仕事の場では当たり前のことなのではないかということである。だから、システムの世界が現実から乖離していたという言い方もできる。なぜもっと素直に現場で行われていることを写像しなかったのかと思うのであるが、これは別のところで書く。

とは言え、業務システムにとってはコンセプト変えることであり、着手点もHowではなくてまずはあるべきWhatの姿を考えて見ようというのが大切な態度だと思うのである。
 　

]]>