IT再考－WhatがHowに優先する (mark-wada blog)
先頃のエントリーで「BPM交流会」のことを書いた。その中で、ぼくの行った講演のポイントの初めのところに“WhatがHowに優先する”ということを指摘したので、もう少し詳しく説明しようと思う。大変に大事なことだと思うからである。 Whatというのは、ビジネス要求を実現するための仕組みと仕掛けをどんなものにするのかである。それをどうやって作るかはHowであるが、まずは仕組みと仕掛けを設計しておくことが先決であると言っている。そんなことは当たり前だと思われるかもしれませんが、意外といいかげんになっていて、Howを優先しがちになっているのが現状ではないでしょうか。 どうしてこうしたことが起きるのでしょうか。ぼくは次のような3点があるように思っている。そのひとつが、システム化することはITを使うことだと勘違いしていることがある。ビジネス要求を実現するためには、システム化することは重要である。つまり、
Web技術の活用の前に (mark-wada blog)
最近では、エンタープライズシステムにWebの技術を活用しようという動きがよく出てきている。Twitterを使ってみたらとか、SNSで何かやろうなんてことを言っている。しかし、ちょっと待てよと思うことがある。それは、単に技術だけあるいはアプリケーションだけを入れれば素晴らしいことができるという錯覚であるのではないかということだ。 これでは、仏作って魂入れずという感じで、ほんとうの良さを発揮できないことになる。技術論も大事だが、その精神についてちゃんと理解しておくこともより大事なのである。 ぼくは、技術論的な見地から言うと、つぎのような技術がイノベーションを起こしていると思っている。 （１）双方向コミュニケーション （２）ハイパーリンク （３）オンデマンド もっと中味のことで言えば、山本陽平君が書いた「Webを支える技術」（科学技術評論社）で言っているように「HTTP、URI、HTMLそしてR
IT雑感－Webの恩恵 (mark-wada blog)
Webを支える技術は、HTTP、URI、HTML、そしてRESTということを書いた。このおかげでシンプルで拡張性に優れたWebサービスが作られるようになった。ではこうした技術が企業において、あるいはビジネスの世界においてどんな恩恵をもたらしてくれているのだろうか。 こう書くと、それはEnterprise2.0のことですねという人がいる。数年前に言われていた概念で今はどうなっているのか知らないが、要するにメッセージングやSNS、ブログ、wiki、コラボレーションツールなどのWebの技術をビジネスに生かそうという試みである。 まあ、だいたいにおいてナレジマネジメントと似たようなニュアンスで語られる。個人の知的生産性の向上といった響きだ。だから、グループウエアの拡張みたいな使われ方になる。しかし、そんな使われ方がはたして正しいのだろうか。どうも違うように思うのである。 そんな時は、技術そのものが
Webを支える技術 (mark-wada blog)
この間社長（息子）からこれ読んでみたらと言ってある本を手渡された。タイトルが「Webを支える技術」（技術評論社）である。こんな技術本を読めるほどぼくにはベースがないのでなぜかと思ったら、社長がj自分のブログでこの本の書評を書いたら、著者の山本陽平さんからTwitterで「mark-wadaにもよろしく」と言われたらしい。 実は、山本陽平さんとは1年ほど前にビジネスプロセスパターン研究会というの主宰したとき、メンバーに入ってもらったという経緯がある。社長のPerl友だちの職場の同僚という関係で誘ったのである。 会社が引けてからの2時間くらいの短い時間だったのだが、5ヶ月間で数回の議論をしたが、いろいろな角度から話がはずみすごく楽しかった。あれから会っていないのでしばらくぶりの絡みだ。 でぼくには難しすぎやしないかと思って、本を読むのをちょっと躊躇したが、せっかくだから読んでみることにした。と
セミナーに出ます (mark-wada blog)
先日、マジカジャパンの羽生さんのところに行ったら、今度セミナーをやるのでそこで「Kailas」の紹介をしてくれということになった。羽生さんの会社は、以前はスターロジックという名前だったが、今年の７月に社名もマジカジャパンに変えて、業務フローに特化することになった。 マジカというのは、自分の仕事を紙のカードに書いて貼ったりしながら業務フローを作成するためのツールです。世の中に小難しく高価なソフトウエアはありますが、そうしたものを使えばちゃんと業務フローが書けるというわけではありません。その点、マジカは実践的で、業務を簡単に整理でき、見える化できるものです。 弊社ワディットで開発した「Kailas」は、業務フローが書ければ、それをできるだけそのままで実装し、動かしてしまおうというフレームワークですから、マジカで書いたものをベースに業務アプリケーションを構築するという技法を提示しようと思っていま
プロセス志向のデータベース設計 (mark-wada blog)
このあいだ、「SOA時代のデータ管理」というエントリーを書いたが、そこではデータベース設計をどうやるかには言及していない。それで、最近そのことについてずっと考えているが、なかなか答えが見つからない。 データベース設計というと、DOAが浮かんできます。データ総研の椿さんはいつも、DOAの条件として、「データ先行・リソース先行・概念先行」ということをおっしゃっています。データをプロセス／処理に先行して考え、イベントデー タ（受注・出荷・請求など）より先にリソースデータ（社員・顧客・商品など）を固め、物理データベースより概念データベースを先行するという意味です。 では、POA（という言葉があるとすれば）だとどうなるのでしょうか。「プロセス先行・マクロプロセス先行・概念先行」といったところでしょうか。しかしデータベースはどうするのだの答えにはなっていません。 DOAだと一般的に言われるのは、画面と
ビジネスと業務の構造化～業務の階層化と粒度～ (mark-wada blog)
前回は事業を実行するための企業の構造についてみましたが、まだかなり大きな括りですので、これを分解していくことになります。 前回最後の方で書いたリファレンスモデルでは、そこの落としこみをおこなっています。しかしながら、これもまだ粗いのでさらに細かくしていく必要があるのですが、リファレンスモデルではそこまでできていません。 ここは例をあげて説明した方が分かりやすいので、ごくオーソドックスな受注して出荷するというプロセスで考えてみます。 まず大きなプロセスである「受注―出荷」があり、それを分解すると、「受注」、「在庫引当」、「輸送手配」といったものに分解できます。つぎに、「受注」というものをみると、その中にもプロセスが内在しています。「受注受付」、「与信」、「納期確定」、「オーダー発行」といったものがあります。そして、最終アクションとして「受注メモ作成」、「連絡」、「承認」、「入力」といったもの
第1回勉強会 (mark-wada blog)
昨日は銀座のルノワールでビジネスプロセスパターン研究の第１回の勉強会を行なった。家を出るときてっきり6時半からだと思い込み、少し早めに出たつもりだったのだが、新橋から銀座に向かう途中で、そうだ6時からだったと気がつきあわてて走って向かう。若干遅れて到着。早めに出てよかったと胸をなでおろす。遅れて来る二人を除いてもう7人が席についていて、はあはあ言いながら始める。 昨日は第１回目なので、趣旨説明や自己紹介を行う。メンバーは主に20～30代（中にひとり気持ち20代の40歳の人がいます）のベンダー系に勤めている人たちで構成されています。ぼくがブログやBPMオフ会で出会った人とうちの社長関係で知り合った人たちです。 議論の第一歩は、「現状の業務システムはビジネスの要求に答えられているか」である。ぼくの方から、ここ15年間業務システムが変わっていないので何とか変革しなくてはいけないという話をする。ビ
ビジネスプロセスパターン研究 (mark-wada blog)
来月から、標記のようなテーマで勉強会（BPP研）をやろうと思っています。なぜこうしたことをやろうとしているのかというと、オバマではないですが、変わらない、変わろうともしない業務システムを抜本的に“Change”させたいからです。 ビジネスプロセスパターンというのは、あまり聞きなれないと思いますが、その意味するところは、業務を階層化し、ある粒度に分解していくとそれぞれの階層でパターン化できるのではないかという仮説に基づいています。 これを「業務の構造化」と考えていますが、そうした構造化により、システム構築の方法もシステム構造そのものもひいては仕事のやり方も変えられるかもしれないということです。 それを皆さんの知恵を借りながら仕上げていこうと思っています。そして、パターン化された業務コンポーネントをベースにどう業務プロセスを設計し実装していくかという実践的な議論をしようと考えています。 そこで
本質を見抜く (mark-wada blog)
ここのところスタロジの羽生さんが立て続けにブログですごくいいことを書いているので反応したくなった。「営業マン」「起業・経営の必要条件」「制約が工夫と本質を磨く」である。 GoTheDistanceさんもこのエントリーに対してコメントしているが、ぼくはぼくなりのちょっと違った視点で考えてみた。羽生さんが書いていることは、会社でモノを作ってそれをお客さんに売って会社の経営を立ち行かせるには、何が大事なのかをこれだけの行数でほぼ言い尽くしてあるのに驚かされる。 ぼくも２年半まえに起業してまがりなりにも会社を経営しているので身につまされる思いで読んだのである。ただし、これは何も起業している人たちだけではなく、普通に会社で働いている人にとっても当てはまることでもある。 ブログの記事に言及する前に最近の問題も絡んでくるのでそのことに少し触れておく。いま、派遣だとか非正規社員だとかいう問題が喚起されてい
Web2.0の導入レベル (mark-wada blog)
Web2.0の技術やサービスを企業に導入するにはといったテーマで勉強会をしているという話は前に書いた。そのとき、どういうエリアで導入すべきなのかという問題がある。仕事の種類でどういった技術やサービスが適用できるかということである。 そこで、そうした業務の性格をながめてみた。３つのエリアというかステップがあるように思うのである。 その３つはつぎのような業務形態ではないかと思いいたった。 １） 個人の知的生産性に関するところ ２） グループで行うプロジェクト的業務に関するところ ３） ルーティン的な基幹業務プロセスに関するところ それぞれで求められる要件が違うように思う。 １）では、あくまで個人であるので個人がどれだけいい情報に早く到達できるかであろう。当然情報取得は人からもあるから、効率的なコミュニケーション能力というのも含まれる。 ２）のところでは、ある設定された目的に対して、それぞれの役
ギョイゾー！はヤバイ！！ (mark-wada blog)
先日の情シスオフ会でスタロジの羽生さんが「ブリスタ」を惜しげもなく公開して、そのすごさにびっくりしたとwkzkさんのブログに記事が出ていて、その中にこんな記述があった。 そうそう、それはmark-wadaさんのいう対面式で開発を行うというあのお話と一緒だなぁと。mark-wadaさん強敵ですよ、これは。正確にはmark-wadaさんだけにいうことじゃないんだけど、ま、そこまでは書かない(^^; それで、こりゃ一言おうかと思ったのだが、具体的に分からなかったのでやめておいた。いつか羽生さんに聞こうかなと思っていたら、羽生さんが、そのあとブログで「ギョイゾー！の裏側」というタイトルで記事を書いていた。びっくりした。ここまで書いていいのかということとここまでやっているんだという驚きである。 読んですぐに分かった。分かったといっても、ぼくは中味のことはまったくといっていいほど理解できないと思うが、
Web+DBPressに載ります (mark-wada blog)
今月の24日に発売になる「Web+DBPress」Vol.47にぼくの書いた記事が掲載されます。タイトルが「実践的BPMのための 業務プロセスの設計作法」です。 このブログにも書いてあることですが、BPMアプリケーションを開発するためには、上位のプロセス設計が大事になってくるという主旨で、そのための設計作法について書いています。 一緒に社長の知り合いのYappoさんや、つい先日お会いした山本陽平さんも記事を書いているのでけっこう感激しているのです。 元々は8月発売の前号に載せるはずだったのですが、事情があって2ヶ月遅れとなりました。したがって、微妙に変えたいところもあったのですが、そのままにしてあります。 この雑誌は、若い開発者向けだそうですが、ぼくのような年寄りが書けるのかと逡巡しましたが、開発者にとって業務プロセスをきちんと捉えておくことは非常に重要であると思っていたので、そこに焦点を
BPMオフ会 (mark-wada blog)
OSACのセミナーの後BPMオフ会に行ってきました。夜の8時からだったのでOSACの懇親会が終わってかけつけてちょうどよかった。ただし、すでに若干酔っ払い状態。 今回のオフ会はサイボウズラボのid:n_shuyoさんのFlowrについてである。どうもFlowrを知って面白そうだということでid:yojikさんやid:wkzkさんが取り上げてそこからコミュニケーションができ今回の臨時オフ会になったとのこと。こういう動きもネットコミュならではの面白さですごくいいことだと思う。 昨日は30人弱の参加で、幹事のid:GoTheDistanceさん、wkzkさん、いつものid:habuakihiro、id:makotan、ToiToiさんや久しぶりのmatsuさん、それに結構初めての若い子がいっぱい。 Flowrの話はぼくにとってはかなりむずかしいのでよく理解できなかった。雰囲気としてひょっとしたら
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
第2回BPP研究会 (mark-wada blog)