April 2012 Archives

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

上流・下流の分断の話が、ソフトウエアの開発と業務システムの構築の混同により、議論がちぐはぐになっていることを指摘した。つまり、業務システムを作る商売をしている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でのキャリアパスを考える」というイベントに登壇しました」というエントリーで(別に個人的にどうのというのではなく一般論として取り上げてみたのである、湯本君ゴメン)、そこでのプレゼン資料を公開され、その解説が書いてある。

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

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

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

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

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

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

About this Archive

This page is an archive of entries from April 2012 listed from newest to oldest.

March 2012 is the previous archive.

May 2012 is the next archive.

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

Pages

Powered by Movable Type 4.34-en