Wadit Blog.

非定型業務のIT化　－　実装を考える

By Masanori Wada on May 16, 2012 10:23 AM | No Comments | No TrackBacks |

これまで、プロセスの構造や機能をどんなもににするのか、それをどう設計するのかということを議論してきました。これからは設計されたプロセスをどうやって実装するのかという話になります。ここでもすごく重要なのはオペレーション発想です。オペレーションからの発想で構造を考え、それらがうまく機能するような設計をしたわけですが、それを実際に動かすプラットフォームに植えつけることをしていきます。

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

①ビジネス活動（プロセス）の進捗がわかること

②意思決定（データ確定・判断）に必要な参照情報を得られること

③コミュニケーションをしながら意思決定が行えること

④プロセス全体と単位意思決定の責任者が明確になっていること

⑤パフォーマンスの状況がわかり対応アクションがとれること

⑥オペレーションの結果がアーカイブされて、次に生かされること

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

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

ほとんどを持っているのがＢＰＭ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を考えないで業務オペレーションを描いてみる

By Masanori Wada on May 10, 2012 10:25 AM | No Comments | No TrackBacks |

はてなブックマーク - 非定型業務のIT化　－　ITを考えないで業務オペレーションを描いてみる

どうやって実装するかの前に「ITを考えないで業務オペレーションを描いてみる」ことをしてみましょう。このエントリーのタイトルが「非定型業務のIT化」ですからそれを否定するような言い方で矛盾していると指摘されそうですが、単にIT化するのが目的でなくて、言外にビジネスの役に立つためのITという意味が含まれています。

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

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

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

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

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

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

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

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

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

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

ITがなくてもやってきたわけですから、それほど多くの情報量が必要でない会社、簡単なプロセスしかない会社は無理にIT化しなくても人間が介在することでも十分できるならそれでもよいと思う。つまり、人間とITがうまく役割分担して、ベターな仕組みを作ればよいのです。こうして考えると、業務システムをプログラミングして自動化を図るというアプローチが何だかおかしく思えてきませんか。

非定型業務のIT化　－　業務プロセス設計だけで実装できる？！

By Masanori Wada on April 30, 2012 12:22 PM | No Comments | No TrackBacks |

はてなブックマーク - 非定型業務のIT化　－　業務プロセス設計だけで実装できる？！

前回は、業務プロセス設計が肝であるという話をしました。普通はＶモデルのような開発工程があります。要求分析－基本設計－機能設計－詳細設計があってコーディングをして、そのあとそれぞれのレベルに対応した単体テスト－総合テスト－システムテスト－受け入れテストというわけです。では、業務プロセス設計というのは、どこに相当するのでしょうか。

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

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

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

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

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

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

非定型業務のIT化　－　業務プロセス設計が肝

By Masanori Wada on April 23, 2012 10:22 AM | No Comments | No TrackBacks |

前回は、Howということでどのようにして設計して実装していくかについてとっかかりの考え方について議論しました。そこでは、プロセス中心、プロセス先行でみていくことが大切だということを言いました。今回は、設計のところを具体的にどのように進めるかについて考えていきましょう。

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

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

①ビジネス活動（プロセス）の進捗がわかること

②意思決定（データ確定・判断）に必要な参照情報を得られること

③コミュニケーションをしながら意思決定が行えること

④プロセス全体と単位意思決定の責任者が明確になっていること

⑤パフォーマンスの状況がわかり対応アクションがとれること

⑥オペレーションの結果がアーカイブされて、次に生かされること

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

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

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

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

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

非定型業務のIT化　－　Howを考える

By Masanori Wada on April 16, 2012 9:58 AM | No Comments | No TrackBacks |

さて、これまでは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図をながめてもユーザの人はなかなか理解できないのではないでしょうか。

コンサルティングの成果が紹介されました

By Masanori Wada on April 13, 2012 11:33 AM | No Comments | No TrackBacks |

昨日のソフトバンクの「ビジネス＋IT」に先月の「BPMフォーラム」のセッションで発表した事例についての記事が掲載されました。「ある油圧機器メーカー社長が掲げた「特注品で売上を伸ばす」を実現したBPMの取り組み」と題した内容で日本BPM協会の岩田アキラさんの「BPM推進フレームワーク」の紹介に続いて、ぼくが一昨年と昨年に参加した「業務見える化」プロジェクトの成果を発表したことについて書かれています。

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

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

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

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

もしSIerのエンジニアがジョブズのスピーチを聞いたら（４）

By Masanori Wada on April 9, 2012 11:05 AM | No Comments | No TrackBacks |

はてなブックマーク - もしSIerのエンジニアがジョブズのスピーチを聞いたら（４）

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

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

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

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

　　　　　　　　　　　　　　　　　　　　　　　－Steven Paul Jobs－

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

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

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

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

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

もしSIerのエンジニアがジョブズのスピーチを聞いたら（３）

By Masanori Wada on April 8, 2012 10:28 AM | No Comments | No TrackBacks |

はてなブックマーク - もしSIerのエンジニアがジョブズのスピーチを聞いたら（３）

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

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

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

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

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

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

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

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

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

もしSIerのエンジニアがジョブズのスピーチを聞いたら（２）

By Masanori Wada on April 4, 2012 10:15 AM | No Comments | No TrackBacks |

はてなブックマーク - もしSIerのエンジニアがジョブズのスピーチを聞いたら（２）

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

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

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

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

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

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

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

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

もしSIerのエンジニアがジョブズのスピーチを聞いたら（１）

By Masanori Wada on April 3, 2012 11:15 AM | No Comments | No TrackBacks |

はてなブックマーク - もしSIerのエンジニアがジョブズのスピーチを聞いたら（１）

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

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

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

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

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

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

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

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