« February 2009 | Main | April 2009 »

March 2009

Sunday, March 29, 2009

コンサルタントの「現場力」

野口吉昭:『コンサルタントの「現場力」』へのリンク(Amazon.co.jp) 「現場力」をテーマにしながら、コンサルタントの考え方や仕事の進め方のノウハウを紹介した本です。コンサルタントがクライアントに価値を提供していく上で、どのようなスキル、マインドが必要なのかを知ることができて、勉強になりました。

私がこれまで仕事を進める上では、コンサルタントとしての意識はほとんどありませんでした。実際のところ、技術者としての意識で仕事をすることが多かったと思います。しかし、それだけでは提供できる価値に限界があるということを最近強く感じています。

本書では、第一線のコンサルタントが現場でどのように考え、どのようにクライアントを巻き込んで仕事を進めていくのかについてヒントを得ることができまし た。本書で取り上げられているテーマは、コンサルタントに関わらず、(特に最近の私がそうなのですが)現場のビジネスマンも意識していく必要があるスキ ル・考え方だと思います。例えば以下のようなテーマが述べられているのですが、クライアントに対してだけではなく、社内で立ち振る舞う場合にも重要なポイントになると思いました。

1.「コンテンツコンサルティング」から「プロセスコンサルティング」へ
2.
「仕組む力」と「仕掛ける力」のバランス
3.「論理的思考」と「コンセプト思考」

フレームワークを活用して現状を分析することや、その結果を理路整然とプレゼンすることの重要性については、本書でも言及されています。しかし、そこで終わってしまっては意味がないということも本書では指摘しています。どんなに魅力的なアイデアやプランでも、クライアントが納得して動いてくれなかったら、ビジネスの世界では何の価値もないわけです。

クライアントの懐に入り込んで、心から納得してもらった上で、一緒にゴールを目指していくためには、 コンサルタントの人間性やコミュニケーション力が重要という点や、論理的思考も大事だが、それ以上にコンセプトを作り出して仕掛けていくことが大事だという点についても言及されています。「論理的思考」と「コンセプト思考」については、さらに以下の要素に分解されています。自分に欠けている要素を意識して、強化するようにしながら、日々の仕事に活かしていきたいと思います。

・論理的思考
  - 仮説思考
  - フレームワーク思考
  - オプション思考

・コンセプト思考
  - ゼロベース思考
  - 本質凝縮思考
  - シナリオ思考

| | Comments (0) | TrackBack (0)

Saturday, March 28, 2009

上野公園のお花見レポート(2009年)

今日(3月28日)は上野公園に桜を見に行ってきました。

桜はまだ満開ではなかったですが、例年通り人は多かったです。桜並木沿いの桜が真上に見える一等地は、すべて宴会する団体さんや席取りのシートで埋まっていました。

天気は比較的良くて日中は暖かでしたが、まだコートが必要ですね。今日はお昼すぎに出かけて、桜を見てお弁当を食べてきました。夕方には帰ったのですが、夜は冷え込みそうな感じでした。

上野公園の桜(まだ5分咲き)

今年は桜の開花が昨年より遅めですね。昨年は3月29日の時点ですでに満開だったのですが(過去記事参照)、今日見てきた限りではまだ5分咲きといったところでした。

この調子だと、次の週末(4月4日、5日)も天気が良ければ十分桜を楽しめそうです。

| | Comments (0) | TrackBack (0)

Tuesday, March 24, 2009

BPMツールとは何か

Bpm_2 先日、「BPMとBPMツールの関係」というブログ記事を書きました。その理由ですが、一般に「BPM」と「BPMツール(BPMS)」が一緒に語られる(ごちゃ混ぜになってしまう)ことが多いと思ったためです。
 実際のところ、BPMとBPMツールは全く別のもので、それぞれ単体で導入が可能です。そこで、前回の記事ではBPMとBPMツールの関係を整理しようと試みました。

ただし、なかなかうまく整理するところまではいかず、最終的には「BPM、BPMツール、SOAをうまく繋ぐ方法論が必要」という課題を提示して終わってしまいました。
 この「ビジネスとITを繋ぐ方法論が必要」という考えは今でも同じです。今月から始まったBPP研(ビジネスプロセスパターン研究)に参加する上での私の問題意識もそのあたりにあると考えています。ちなみに、来月のBPP研のテーマは「ビジネスと業務の構造化」ということですので、自分なりに業務をどのようにモジュール化できるかを考えていきたいと思います。

一方、今回のブログ記事の目的ですが、「BPMツール」の定義を明確化することです。前回の記事でBPMとBPMツールの関係を整理してみましたが、そもそもBPMツールとは何なのか、何ができるのかをここで明確にしておきたいと思ったのです。今回のブログ記事を書くにあたっては、以下の記事が参考になりました。

CIO Online : 「BPMツール選択ガイド」
http://www.ciojp.com/contents/?id=00002398;t=10

この記事に書かれているBPMツールの定義をまとめると以下のようになります。

1.BPMツールの定義

「人やシステムが行うビジネスプロセスの管理・監視を自動化するためのソフトウェア」

2.BPMツールが提供する機能

次に、「BPMツールを使うと何ができるのか」ですが、「日経SYSTEMS 2008.9号」の記事は、BPMツールが提供する機能を以下の3つに分類しています。

  1. モデリング機能(ビジネスプロセスの設計・可視化)
  2. プロセスの構成要素に実行プログラム(Webサービスなど)をひも付ける機能
  3. BPELなどで記述されたプログラムを実行する機能

一方、前掲の記事「BPMツール選択ガイド」では、BPMツールの機能を以下の3つに分類しています。

  1. モニタリング・ツール
    (プロセスを監視し、イベント発生時に関係者に通知する)
  2. ワークフロー・ツール
    (定義されたフローに基づいて、プロセスを実行する)
  3. EAIツール
    (システム統合を支援する)

こちらの定義の方が、BPMツールの機能全体を網羅していると思います。日経SYSTEMSの記事は、2つ目の「ワークフロー・ツール」の部分にフォーカスしているのだと言えそうです。そこで、当ブログ記事では、BPMツールが提供する機能を以下のように整理しておきたいと思います。

BPMツールが提供する機能

  1. モニタリング(プロセス監視、イベント発生時の通知)
  2. ワークフロー(プロセス定義、実行)
    1. モデリング(ビジネスプロセスの定義)
    2. プログラム呼出(プロセスからWebサービスなどのプログラムを実行)
    3. フロー実行(BPELなどで記述されたフローを実行)
  3. EAI(システム統合)

3.上記の定義は何に役立つか?

上記のように「BPMツール」を整理しておくことで以下のメリットがあると考えています。

ユーザにとってのメリット:
BPMツール導入を検討する際の評価軸として使用できます。

ベンダーにとってのメリット:
BPMツールについて説明・議論する際、内容を漏れなく網羅するためのマップとして使用できます。

| | Comments (0) | TrackBack (1)

Saturday, March 21, 2009

つくばエクスプレス 沿線探訪

「時刻表&沿線マップ」の表紙今日はつくばエクスプレス(以下「TX」と書きます)に乗ってきました。目的は沿線のオープンハウスを見学することと、駅周辺の環境を確認することです。

将来は一戸建てに住みたいと思っているので、TX沿線に良さそうな場所がないか、今のうちから調査しておこうと思ったのです。

今回はいろいろな駅で途中下車するつもりだったので、一日乗車券を購入しました(右下の写真参照)。金額は大人1名 2,300円です。

一日乗車券東京メトロやゆりかもめの一日乗車券と比べると3倍ぐらいの価格なので、ちょっとびっくりしました。しかし、TXは特急なみのスピードですし、全般に運賃が高めなので、2,300円も妥当な金額なのかなーとは思います。

ということで、一日乗車券の分を取り戻そう!というわけではないのですが、以下の駅で途中下車しました。今回の目的は、駅周辺の雰囲気や環境を確認することなので、中には改札を出てから5分ほどでホームに戻った駅もあります。

  • 北千住
  • 柏の葉キャンパス
  • 守屋
  • つくば
  • 万博記念公園
  • 柏たなか
  • 流山おおたかの森
  • 流山セントラルパーク
  • 南流山
  • 浅草

路線

柏の葉キャンパスやおおたかの森は、駅に大規模なショッピングセンターがあったりして、買い物に便利そうです。今回はモデルルームの地図を持参していかなかったので、オープンハウスは一件しか見ませんでした。どちらかというと、つくばの中央公園でお弁当を食べたりと、ちょっとした旅行感覚でした。以下の写真は、つくばエキスポセンターのロケットです。

つくばエキスポセンターのロケット

しかし、それぞれの駅の雰囲気を確認することができたのは、大きな収穫でした。快速や区間快速が停まる駅は、やはり人が多くて駅前のお店が充実している傾向があります。
 一方で、駅によってはまだまだ発展途上の(良く言えば、店舗や人が少なく静かで自然が多い)ところもありました。駅前は以下の写真のような感じです。

駅前の様子

それにしても、TXが思っていた以上に速いのにびっくりしました。茨城県の守谷から秋葉原まで、快速で33分ということで、十分通勤圏内になりそうです。
 今回は半分旅行で終わってしまいましたが、次回行く時には、ポイントをしぼっていろいろな住宅を見てまわりたいと思います。

| | Comments (0) | TrackBack (0)

Monday, March 16, 2009

BPMとBPMツールの関係

Bpm_2 3/10(火)に開催された「第1回 ビジネスプロセスパターン研究(BPP研究)」に参加してきました。社外の勉強会に参加するのは、ほとんど初めての経験だったのですが、様々な経験を持った方々のお話を聞くことができて、よい刺激を受けることができました。今回は会の趣旨や議題を聞くだけで終わってしまった感じもありますが、次回からはテーマに対して自分なりの意見を発表できるように準備していきたいと思います。

BPP研究の目標は、「ビジネスが求めるITを実現するためのフレームワーク」の構築にあると理解しています。私はIT・システムを提供するSIer/ベンダー側の人間なので、どうしてもシステムやツールありきで考えることが多かったです。しかし、最近は勉強会に参加したり、mark-wadaさんのブログを拝見したりする中で、ビジネス寄りの視点でシステムを考える必要性を感じています。

特に、昨年からは仕事でBPMツールを扱っていますが、BPMツール導入のメリットをお客様にアピールするのは難しいと感じています。そこで、「BPM」と「ビジネス」と「システム」の関係を一度整理しておきたいというのが、今回のブログエントリの理由です。
 まず、以下の表を作ってみました(表1)。縦軸は企業が組織的にBPMを実践しているかどうかを示しています。横軸は企業がBPMツール(BPMS)を使用しているかどうかを示します。そして、各象限にはビジネス・システムの視点から見た組織の状況を記述してみました。

表1:BPM取組状況とBPMツール使用有無のマトリクス

BPMツールの利用
ありなし
BPMの実践あり

ビジネスの視点:
業務プロセスの可視化と改善が意識されている。

システムの視点:
機能とプロセスが分離されている。ビジネスルールが分離されている。システムが統合・連携されている。

ビジネスの視点:
業務プロセスの可視化と改善が意識されている。

システムの視点:
従来型のシステム開発。サイロ型・スパゲッティ型のシステム。

なし

ビジネスの視点:
BPMを意識することはない。

システムの視点:
機能とプロセスが分離されている。ビジネスルールが分離されている。システムが統合・連携されている。

ビジネスの視点:
BPMを意識することはない。

システムの視点:
従来型のシステム開発。サイロ型・スパゲッティ型のシステム。

BPMツールを使っていても、組織的にはBPMを実践していないケースが存在すると考えられます。また逆に、BPMを実践しているが、BPMツールは使用していない・もしくは必要ないケースも考えられます。そこで、表1を作ってみたのですが、BPMが目指す理想は左上の象限だと考えられます。しかし、それ以外の象限であっても、企業としてそれなりのメリットを享受できているケースは存在すると思います。また、右下の象限に留まっていても、これまでのやり方でそれなりに業務が回っているというケースもあるかもしれません。

ここで言いたいことは、ビジネスとITをつなぐためには、単なるBPMやBPMツール以外の何かが必要だということです。というのも、ビジネス寄りの人はBPM的な視点から業務を見ていて、システムのことは気にしていないのが普通だと思います。また、システム寄りの人は従来型の機能ベース、もしくはSOA的な視点からシステムを見ているが、システムの開発や保守に忙殺されているかもしれません。この状態では、BPMやBPMツールを取り入れても、企業にとってのメリットが限定的なものになってしまう可能性があります。

これまでビジネスとITを繋いでいたのは、システム開発における「要求分析」や「要件定義」といったフェーズだと思います。「業務プロセスの可視化」というのは、BPMで初めて出てきたものではなく、これまでもシステム開発の上流工程では普通に行っていたことのはずです。そこで、本当の意味でビジネスとITをつなぐためには、単にBPMやツールを導入するのではなくて、以下の2つのいずれかの方法が必要であると考えられます。

  1. これまでのシステム開発のやり方を踏襲する場合、上流工程において、BPMとSOAの両方を意識した「要求分析」や「要件定義」を行う。
  2. これまでのシステム開発に代わる、BPM・SOAならではの開発方法論を導入する。

ビジネスとITを連携させるためには、BPMだけではだめで、BPMツールやSOAだけでもだめで、BPMとSOAの両方を実践・推進していくためのフレームワーク、考え方が必要なのだと思います。今後の課題として、そのようなフレームワークを模索していきたいです。

| | Comments (0) | TrackBack (0)

« February 2009 | Main | April 2009 »