メイン

ビジネスサービスのつくり方 アーカイブ

2012年11月19日

ビジネスサービスのつくり方 - はじめに

明日11月20日にうちの社長が著した「Webサービスのつくり方」(技術評論社)という本が発売される。これまで多くのWebサービスをひとりでつくってきた経験を踏まえて、それこそ心構えから企画・設計・開発・運用までをやさしく解説した本である。これを読むと、僕のようにプログラミングもWebサービス開発もやったことのない人間でもちょっとやってみようかという気になる。それは、つくっている人の楽しげな気分が伝わるからだと思う。

翻って、業務システムのエリアでもそういうことがあるのだろうか。 そもそもWebサービスという呼び方に対応したものがあるのだろうか。少なくともサービスをつくるという発想は希薄なような気がします。しかしよく考えてみるとITを使って個人生活を楽しむ、スタイルを持つということを会社生活、仕事スタイルについても同じではないだろうか。ならばそうした"ビジネスサービス"を自分の手でつくってみたらいかがでしょうか。

ただ気をつけなくてはいけないのは、毎度のことですがいま注目のBYODの延長のように考える人がいるが、あくまでチームとして、組織としての活動に対してなので間違わないようにしたい。こうして自分たちが使うサービスを自らの手でつくると考えると旧来の方法と180度違うことに気がつきます。これまでの開発工程の要求分析とかテストといったものがほとんど必要ではなくなるのだ。

なぜなら、もともとニーズを持った人が、ニーズに答えられるような仕組みを作るわけだから、できた時は使う時なのである。このように使う人と作る人が同じであることのメリットは非常に大きい。今の開発の問題は両者のコミュニケーションギャップであるといっても過言ではないからである。だから、前にも言ったように失敗することはないのだ。だって、使えないものは最初から作らないし、できなかったら途中でやめるだけなのである。

ということで「ビジネスサービスのつくり方」というタイトルでシリーズ化して書いていきます。「Webサービスのつくり方」と同じように各フェーズの要素についてエッセイ風にまとめていきます。おそらく数は30くらいになろうかと思います。一応大きな章立ては元ネタに合わせて次のようにします。

1. 心構えと下準備
2. 企画
3. 設計
4. 開発
5. プロモーションと運用

上述した趣旨からもわかるように、ターゲットとしては情報システム部門あるいはユーザ部門のIT担当者を想定しています。ビジネスとITを両方知っている立場の人が担うべきことだと思うからです。ITの専門家は要らないというメッセージなのですが、SIerやベンダーあるいはコンサルの人たちを拒否するわけではけっしてありません。従来の構図がシフトしていますからそのことを理解していれば大丈夫です。

ビジネスソフトウエアを作る人とそれを使ってビジネスアプリを作る人が明確に分かれるというパラダイム変化を言っているのです。このビジネスアプリを作る人向けの記事になるのです。これを読んでぼくも、わたしも作ってみようかと思ってもらえることを願っています。
  


  

2012年11月26日

ビジネスサービスのつくり方 - 第1章 心構えと下準備

■ 「ぐだぐだ言ってないでプロセスを書けよ、ハゲ」
ウェブ系のハッカー(ハッカーというと不正侵入をする人みたいに言われますが、高い技術を持ったプログラマーという意味ですよ)たちの間で「肝に命じる」言葉として、
Shut the fuck up and write some code.
というのがある。ちょっと下品な言葉遣いですが、日本語に訳すと「ぐだぐだ言ってないでコードを書けよ、ハゲ」という感じになる。

小飼弾さんの「勝負Tシャツ」の文言でもあるが、彼曰く、たまたまコーダーだからこうなるけど、デザイナーならデザイン、絵師なら絵、ブロガーなら文書という具合に「とにかく作品作ろうぜ」というのがその真意だという。それにならうとぼくのいるところでは標題のようになる。ただ、コーダーには頭髪の問題を抱えた人が少ないからいいけど、業務系はズバリの人が多いので注意しましょう。

プロセスを中心にして業務を見ていこうということなのだから、とやかく言う前にプロセスを書こうぜというのが言いたいのである。ただ気をつけなくてはいけないのは、コードを書くということは実際に動く作品になっているということで、従って、プロセスを書くということはそれが動くということでないと、それこそ絵にかいた餅になってしまう。

まあ、それよりも前に戦略だとか、KPIだとかBSCだとか言うけどそこまででじゃあそれ実際の現場で動かして、やりたいことを実現しているのかというといささか心もとないのではいだろうか。「Webサービスの作り方」という本では、こうしたことについて、1000人いたとするとアイデアを思いつくのが100人、アイデアを実現するのが10人、アイデアで成功する人が1人と言っている。

業務系の世界で感じるのは、やはり100人のところに多くの人がいるように思います。アイデアの実現や成功は実際に動かして、検証して初めて行き着くところなのですが、そこまで踏み込まない人がほとんどです。思いつくのはいわば単なる個人の意見に過ぎないわけですが、プロセスを書くと考えていたことがどう動くかがみなに晒されて検証されることになります。ですから、思いつきの段階でよく同じことを俺も考えていたのにという人がいますが、動かしてみてから言って欲しいですよね。

ここで先ほど言った、プロセスを書くことが動くことでなくてはいけないということを考えてみましょう。コードは環境があれがすぐに動かすことができます。というこは、プロセスをすぐに動かす環境とはいったい何のかということになります。それがBPMN(Business Process Modeling Notation)ですよねと言われそうだが、そう短絡的に結論を出さないでちょっと待ってください。おいおいこのあたりの話をしていきます。

ここで、言いたいことは要するにああじゃないこうじゃないと言うのなら口先だけでなく実際に動くもの、つまりビジネス現場で働いている人が仕事で実際に使うものを作ってからにして欲しいと思うのである。自分で直接作れなくても少なくともプロセス設計ぐらいまでは自分でやるべきだと思うのですがいかがでしょうか。
  

2012年12月 3日

ビジネスサービスのつくり方 - 第1章 心構えと下準備

■ PCとネットワーク環境さえあれば

本では、「Mac一つあれば・・・」というタイトルである。業務システムの領域では、会社の中で与えられたものを使うというのが普通だと思います。今だと、BYODとか言って自分のMacを持ち込んでということがありえるかもしれないがまだまだ一般的ではなく、標準化された環境(標準化というのは、別な言い方をすると枯れたものを使うことだ)でやることになります。

それはそれとして大事なことではありますが、サービスをお客さんと一緒になって作っていくという点からみると使い勝手も悪いし、機動性に乏しい。ということで、これからは自分の好きなPCと外部でもさくさくつながる環境があればできてしまうことをめざすべきであろう。与えられたものではなく、自分なりに工夫した道具を持ってということです。

ビジネスサービスをつくるということは、「書を捨て街に出でよ!」の精神が非常に重要なことで、自分の会社に閉じこもってせっせとコードを書く事ではないから、自分なりの道具が要るということなのです。では、街に出てビジネスサービスを作るときに必要なことはなんでしょうか。

・ お客さんとの連絡、スケジューリング、情報共有
・ ユーザ要求の引き出し
・ ビジネスモデル記述、ビジネスプロセスモデルの提示
・ 新プロセスの記述・分析
・ プロセスのビジネスサービス化
・ ITにプロトタイプ実装

までくらいのことができればよいと思います。プロトタイプのあとはお客さん自身で使えるものにするというのがぼくのスタンスです。こうした活動にどんなツールを使っているのかというと次のようなものになります。ごく普通のデバイスです。

・ハード  :モバイルPC(Acerの安いやつを使っていたのだが、キーボードが壊れてしまったので、緊急避難で昔使っていたThinkPadにしています)、iPhone、イーモバイル
・ソフト  :Cybozu.com(live、kintone)、Cacoon、Excel

iPhoneはボイスメモを使ってワークショップの時の議論を録音します。また、ホワイトボードに書いたメモをカメラで写すという使い方になります。基本ひとりでやっていますので、議事録をとったりできませんので、この録音と写真は大変重宝します。イーモバイルも最近は速度が早く問題なく使えるようになりました。

ソフトウエアでは、サイボウズ社のものが便利です。今はクラウド化しているので、Cybozu.comから必要なものを選んで使います。ぼくの場合は、お客さんとの連絡、スケジューリング、情報共有にはサイボウズliveを使っています。20人までは無料ですから、ワークショップができるとすぐにメンバーの方々に登録してもらいます。

そして、ビジネスモデルやプロセスのモデルはCacooという描画ソフトを使います。Nulabという会社が提供しているWeb上で作図ができるものです。ここにモデルフローを書いてあるので、それをお客さんに見てもらうようにしています。また、プロセスの概略設計もここで行います。それをもとにkintoneのフォーム設計に落としていきます。いずれも低価格なのでぼくらのような零細企業にとっては助かります。次回に具体的な使い方を説明します。
 


2012年12月 7日

ビジネスサービスのつくり方 - 第1章 心構えと下準備

■自分なりの道具で
さて、前回ビジネスサービスをユーザの人たちと一緒につくっていく上で必要なぼくが使っているツールの話をしました。PCとiPhone、イーモバイル、Cacoo、サイボウズLiveとkintoneです。今回は実際にどのように使っているのかの話になります。PCとiPhone、イーモバイルは特に説明するほどでもないの、Cacoo、サイボウズLiveとkintoneについてお話します。

サービスをつくるのは基本的にはワークショップ形式にしています。そこに参加するメンバーを集めて始めるわけですが、頻繁に集まってワークショップを行うことはできません。特に営業の人たちを巻き込んだものなんかはメンバーが揃うことも難しいことがほとんどです。本当はそれでは困るのですが、それなりに長期戦になるので缶詰になってやるわけにはいかないからです。

そんな時には、実際に集まってやる以外でのコミュニケーションが必要になってきます。それと、ワークショップを通してでき上がっていく成果物や参考情報を共有することも必要です。それにはサイボウズLiveを使います。ワークショップのアジェンダ設定や結果のレビュー、スケジュール調整などをSNS的にやっていきます。

ただ、企業の人たちは意外とコメントのやりとりをしないなあというのが実感ですね。ちょっと話はそれますが、いま推奨しているサービスでは、意思決定をコメントの交換によるコミュニケーションを図りながら行いましょうと言っているので、若干危惧しているところです。メールには慣れてきているのだからとも思うのですが、メールはコミュニケーションとはちょっと違うのかもしれません。

ワークショップの進め方は、従来のシステム開発のようにヒアリングして、それを要件定義書にしてレビューするというのとは違って、ユーザの人たちの自主的な議論だとか、デザインワークを大切にして進めていきます。ですから、不断のコミュニケーションが大切なのでこうしたツールを活用することにしています。

ワークショップの具体的な進め方はまた後ろの章で書いていきますが、最初に持っておくものとしては、ビジネスモデル記述のためのフレームワークとビジネスプロセスモデル(ハイレベル)、プロセス記述テンプレート&ステンシルです。これらは、Cacooに保有してあるのでそれを使いますが、ビジネスモデル記述のためのフレームワークとプロセス記述テンプレートは、場合によってはExcelシートを使うことがあります。

書き方の説明には、Cacooで書いたものを使い、実際に中身を記述するときにはExcel表に書き込むのが簡単かもしれません。やはりその場でどんどん書いて行くにはExcelが良さそうだというのがぼくの感想です。下図がCacooで書いたビジネスプロセスモデルの一部です。
 
jigyoupurosesu.JPG
  



2012年12月11日

ビジネスサービスのつくり方 - 第1章 心構えと下準備

■モックアップツール
業務システムのエリアでは設計というとおおかたは紙に書いたもの、つまり設計書という形式に落とすことがやられてきました。ドキュメントをちゃんと残しましょうという掛け声で一生懸命書いたものです。ところが、がんばって残した割にはあまり役立っていないと思っている人もけっこういるのではないでしょうか。

では書かないですむ方法はないだろうかということです。ぼくがkintoneを設計ツールという位置づけとして使っているのはこのことである。kintone上で設計してしまおうという魂胆である。Kintoneはデータベースアプリでありコミュニケーションツールである。そのデータベースアプリは非常に簡単でパーツをフォーム上に配置すると出来上がってしまうという便利さである。つまり、パーツの配置と複数のパーツからなるブロックの順番を決めて並べることが設計とすることができる。

また、コミュニケーションツールであることも活用したらよい。フォームの設計を複数のメンバーで共同作業としてやる場合に編集における追加変更をコメントとして残しておいたり、変更履歴が残るのでちょっとしたバージョン管理もできるというわけである。何かのコンテンツをコラボレーション的に作り上げるイメージである。これはCMSなどのWebアプリの特徴でもある。

ここで設計されてできたいわば"モックアップ"を使って、さらに検討を加えることになるが、なおいいのはすぐに動くことである。ふつうモックアップといっても変更をかけたりするとそれなりに手間がかかるのだが、このツールはモックアップといえども製品であるからすぐに変更後のオペレーションの検証ができることがメリットである。

そこで、できればそのままkintoneで実運用に入ってもいいし、違ったソフトだとか今現在使っているもので同じようなことをしてもよいのである。要するに簡単に素早くシステムができてしまうソフトだからこそ、高度なモックアップツールとして活用できるのである。従来は、これが出来なかったので紙に書いていた。言い換えると、実際に動くように設計されたフォームがそのまま設計書になっているということである。

実際には、プロセスモデルを参照しながら、プロセス要素表というものを書いてそこからkintoneに落とし込みます。さすがに何もないところかいきなりフォーム設計は難しいからです。手書きのプロセス図でも、それこそホワイトボードに書いて写真にとったものでもかまいません。要するに、そこのドキュメント化に時間と手間をかけないということがポイントです。

kintoneでフォーム設計した例を下に示します。

%E3%83%A2%E3%83%83%E3%82%AFmitumori.JPG
 

2012年12月18日

ビジネスサービスのつくり方 - 第1章 心構えと下準備

■ ITって何かを知る
ここで少し心構え的なことを考えてみましょう。ビジネスサービスを広く捉えると、必ずしもITを使ったものでなくてはいけないということはありません。世の中にはITを使わないサービスは数多くあります。ですから、当たり前なのですが、サービスを提供するのに役に立つ部分にITを適用することになるわけです。ところが、時として何でもかんでもITでやろうとすることがあります。

○○システム開発といったプロジェクトを始めたとすると○○システムをどうやって作ろうかと考えてしまいがちです。パッケージを持ってくればいいとか、プログラミングを自動化して速く作ろうとかに頭が行ってしまいます。これはまさにITシステムを作ることが目的となってしまっています。そのプロジェクトの顧客は誰で、その人たちはどんなサービスを欲しがっているのかという見方が大事なのではないでしょうか。

ぼくはいつも「ITとは」という問いかけに対しては次の二人の言葉を思い出すことにしています。

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

ジョブズはだれでも知っていると思いますが、ウィノグラードはスタンフォード大学の先生で、以前は人工知能の大家であったが、その後人工知能の限界を唱え、人間とコンピュータの相互関係を重視したLAP(Language/Action Perspective)という理論を提案している。

簡単に言うと、認識を人間と環境との適合(カップリング)と考え、人間は言語を通じて環境とカップリングする生物であると規定します。従って、ビジネス(プロセス)は話し手と聞き手が相互にカップリングする、再現的な会話(言語行為)によって進行すると考えるのです。これはコンピュータには難しいのです。

二人ともITはあくまで人間が使う道具であると言っています。しかも注目すべきはジョブズは自動車ではなく自転車と呼んでいます。自分の手と足で自由に操れるものという意味なのです。つまり、あくまで人間主体であり、その人間が必要に応じてITを道具として使っているという姿が浮かんできます。

ITをサービスという観点で眺めていくと、サービスとは人間がITを使って生み出されるものであり、またITと人の合わせ技でビジネスサービスを使うというアプローチになるのです。ですから、ケースバイケースでITに任せる部分、人が関与する部分の割合が変わるのは当然で、道具との相性も含めて本来の目的を忘れずに柔軟に対応できるようにするのが大事になるのです。
 

2012年12月21日

ビジネスサービスのつくり方 - 第1章 心構えと下準備

■ ビジネスサービスを使うのをお手伝い

ビジネスサービスということを考えるとITから発想することは避けなければいけません。あくまでビジネスありき、業務ありきですから、当然そこから切り込んでどういったものが必要なのかという視点が重要です。ですから、ITシステムを持ってきて、そこにある機能をどうやって使うかということでは、ユーザが欲しいサービスにはなりません。

そして、よくある間違いは業務システムを新しく作ろうとすることです。これはあくまで業務システムのことを言っていますので誤解しないようにしてください。もちろん、ソフトウエアやツールなどは作るわけですが、業務システムはビジネスを実際にやっている限りどこにでも存在しています。それが、ITでできている場合もありますし、全くITを使わない場合もあります。

ウエブから申し込むと人間が介在しない全自動でサービスを受けられるなんてこともありますが、街の八百屋さんのようにITはどこにもなくてざるの中からおつりが出てくるなんてこともあるかもしれません。しかしながら、どちらも顧客要求に応えるシステムになっている点では同じなのです。ですから、そのシステムが思ったように動いて欲しいというのが使う人の要求になります。思ったようにというのは、お金をかけて速くして欲しいという人もいますし、いや遅くてもいいからお金をかけたくないというのもあるかもしれません。

これはあくまで使う人の考え方によります。ところが、それじゃあダメだからこんなやり方やいい道具があるから使わなければと指南する人がいます。コンサルタントとか呼ばれる人たちです。でもそれってよく考えてみるとおかしな話になると思いませんか。そのビジネス、その業界なりの専門家は誰でしょう。業界トップの例を持ってきて同じようにやれば業績が上がりますよというのも変ですよね。要するにユーザの人が一番業務を知っているのです。

結局は、お仕着せのものでうまくいくはずがありません。自分たちで自分たちのビジネスをとことん考え抜いた結果として、独自のビジネスモデル、ビジネスプロセスを持っていないと生き残れないと思うのです。人に教えてもらってビジネスをやっても長続きせず、いずれ化けの皮が剥がれます。ですから、いずれにしろ自分たちで考えるしかないわけで、そこでどうやってサービスを使うのかをお手伝いするという精神が大事になってきます。

Webサービスとの違いはここで、あくまでサービスを作ってプッシュするのではなく、ユーザから欲するサービスを引き出すプル型の対応が必要になります。ビジネスの主体者であるユーザが腹に入る、腑に落ちる、納得感をもつことを優先させるという心構えを忘れないようにしたいものです。
  

2012年12月28日

ビジネスサービスのつくり方 - 第1章 心構えと下準備

■ 失敗しないシステム開発

業務システム開発の世界ではプロジェクトの失敗例がよく出てきます。お金がかかり過ぎて途中でやめてしまったとか、作ったはいいが使い物にならなかったとか、当初の予算が倍になってしまったとかいった事例を見聞きします。こうしたことはなぜ起きるのでしょうか。やってみないとうまくいくかどうかわからないプロジェクトなのでしょうか。

そんなギャンブルのようなプロジェクトも考えてみればおかしな話ですよね。その原因は、簡単に言えば何を作るのかが明確になっていないからではないでしょうか。それにも二つあって、仕様そのものが明確になっていない場合と、作る人と使う人の理解に相違があってそこで齟齬が生じるというケースです。作ったものが使う人が考えていたものと違ったなんていうことです。

ですから、そうした問題が起きないようにするには使う側から作るものを決めるようにすればよいのです。業務を回す、仕事を行うために必要なビジネスサービスをイメージしてそのとおりに作れば、少なくとも作ったはいいが使わないということはなくなります。さらにそれを自分たちの好きなように作れたなおさらいいですよね。

つまり、使うものだけ、役に立つものだけを作れば失敗はしません。それができなかったら作るのをやめればいいのです。そのとき、作るときに大きな費用がかかるとなると問題なのです。途中でやめるのはいいが、それまで結構な投資をしてしまうと、それをサンクコストとして見てしまい、無理やり続けて傷口を広げてしまうということも起こります。ですから、大事なのは安価な投資でできるやり方でなければなりません。

ERPなどのように統合化された大がかりシステムはその可能性があるのですが、それに対する防御策は、固有性を排除して標準的なものにしておくことでしょう。固有的あるいは差別的な機能は外出しにしておくのです。それによって、仕様も標準のものであればでき上がりのイメージもつかめるので、できたはいいが使い物にならないということはないでしょう。そして、外出しにしたものは、個別に安価な開発費用でアダプティブに作ってつなげればよいのです。

ケースに応じて失敗しないようなやり方を採用していけば当然のように失敗しません。これから議論していくやり方は、そんな志向のものです。サービスという言い方をしているのは、ビジネスの役に立つ、使いこなせる、仕事がうまくいくためのサービスを選んで使うだけといったニュアンスだからです。

ちょっと、話はそれるかもしれませんが、サービスですから取り扱い説明書があればいいわけで、それも最初だけ必要でちょっと慣れればそれもいらなくなります。従来のようにドキュメントを作ってそれをメンテしてといった煩わしさは排除すべきです。サービス化とはそういうものでもあります。

結局、心構えとしてこれまでと違ってもっと気楽に使う人が、あるいは作る人が使う人と一緒になって、業務がやりやすい仕組みと仕掛けを組み上げるということではないでしょうか。そうすれば、失敗することもなく作ったらすぐに使えるようになるのです。
 

2013年1月 7日

ビジネスサービスのつくり方 - 第2章 企画

さてこれからは企画の話になります。「Webサービスのつくり方」という本では次のように書いてあります。

Webサービスにおいて、「何を」つくるかは最も重要なことです。いくら崇高な技術を持っていても。「何を」つくるかによって、その技術が生きるか死ぬかが決まってきます。何をつくるかをしっかり決めることにより、実際に本番用のコードを書く実装の段階にも確信が持てますし、リリースした際に得られるフィードバックも活きてくるでしょう。

ここに書かれていることは、Webサービスだけにとどまらず業務システム、すなわちビジネスサービスについても言えることではないでしょうか。「WhatはHowに優先する」ということを忘れないようにしたいですね。

■ 企画づくりの流れ
何となく頭の中で思い巡らしただけでは企画は生まれてきません。それなりの型があります。次の7つの項目を決めることです。
① 哲学
② アイデア
③ テーマ
④ コンセプト
⑤ 名前
⑥ デザイン
⑦ 内部設計

ここで留意しなくてはいけないのは、Webサービスとビジネスサービスでは、粒度的にレイヤーが一段違うように思います。つまり、ビジネスサービスはWebサービスのレベルのものの集合になっていると考えられます。しかしながら、上記の流れや基本的な考え方は同じように大事だということです。

ではそれぞれで見ていくと、哲学というのは、「Webサービスのつくり方」では"特定の興味に関する揺るがない気持ちのこと"と言っています。これをビジネスサービスに当てはめて考えてみましょう。"仕事を気持ちよくやりたい"ということかもしれません。あるいは、"自分を成長させてくれるもの"かもしれません。そこは会社にとって、また組織にとって揺るがないものを選択すればよいのですが、お気づきかもしれませんが、従来のビジネスサービスでこうした見方をしたでしょうか。効率一辺倒でしか見ていなかったのではなしでしょうか。哲学をしっかりと考えてから取りかかりたいものです。

次のアイデアは簡単にいえば、哲学を叶えるために「これが欲しい」というものを挙げて行くことです。そして、哲学をより具体的な形に落とし込んで狙っていくエリアがテーマになります。アイデアが出て、テーマが決まるとだんだん見えてきますよね。それを一言で表現したものがコンセプトになります。そして、名前付けをするのですが、ビジネスサービスではそんなに重要ではないと思いがちですが、意外と注意したほうがよいと思います。名は体を表すからです。

あとは、デザイン、内部設計といった従来よくやられていて、それなりの考え方がいっぱいある領域です。ここへ来ると、「何を」から「どのように」に入ってきますが、企画の段階では、あまり細かいところに踏み込まない方がよいでしょう。しっかりと「何を」つくるのかを固めることをして、その「何を」に気持ちや、思いや、願いなどを埋め込んでおくことが大切なのです。
  

2013年1月11日

ビジネスサービスのつくり方 - 第2章 企画

■ ビジネスサービスの企画って何?
Webサービスだと企画というのはどういうものかはわかりやすいと思いますが、さあそれではビジネスサービスの企画ってなんでしょうか。まず、一般的にやられている業務システム開発を考えてみましょう。企画なんてフェーズがあるのかという疑問が湧いてきます。スクラッチで開発するにしても、パッケージを適用するにしても、企画づくりの流れでいうと⑦のデザイフェーズから入っているように見受けられます。

要するに、データベースと画面の設計から入るというイメージでしょう。ユーザから要求をヒアリングするからそれは企画でしょうというかもしれませんが、そこには哲学とか「これが欲しい」というアイデアとかはあまりないように感じられます。サービスというのは、送り手と受け手が双方でコンセプトを共有して初めてサービスが成り立っていきます。一方的だとどこかでうまくいきません。

これまでのやり方でこうしたコンセプトの共有ということはあったでしょうか。どうも一方通行のような気がします。パッケージなんかは送り手の押し付けですし、スクラッチだとユーザのわがままを仕方なしに受けるなんてことが起きています。これから大事なことは、お互いに良いサービスを作り、使うのだという意識をもつことだと思います。

そこからは、企画の流れに示したようなステップを踏むことの必要性が見て取れます。ただ、さあアイデアを出してください、出しましょうといってもそう簡単なものではありません。現実的なやり方は、現状の問題点を探すことだろうと思います。Webサービスでも個人生活でこんなこと欲しいので何とかならないかといった発想をします。駅の時刻表はあるけど、どういう経路を行けば一番早いかを教えてもらうとうれしいなということで乗換案内サービスが出来たりするわけです。

ビジネスの世界でも基本的には同じですが、Webサービスがどちらかというと問題解決というより、もっと楽しく、もっと気分よくといったプラス方向のサービス指向ですが、ビジネスサービスではどうしても、問題があるのでそれを解決する方向が主になります。ここの処理に時間がかかるからもっと速くできるようにしたいなんてことが多くなります。

これは仕方ないことですが、これからの業務システムではサービス指向にすること、さらにプラス方向のサービス化を考えて行きたいものです。すなわち、日常の仕事がやらされてる感から、やってる感へ変えるとか、自分の仕事の成果が組織に貢献できたらみんながいいねと評価してくれるといったサービスを取り込めたらいいなあと思っています。

そのためにも一旦自分たちの足元をじっくりと見直したらいいと思います。会社はどう動いているのか、組織はどうしてあるか、どうあるべきか、その中の個人の役割は、それを実行するのにどんな障害があるのか、なぜ不機嫌な職場になっているのかといったことをじっくりと考えてみる必要があるでしょう。何となく、効率化や自動化を目的としてシステムを導入してやしませんか。そこを見直すことも企画の大きな目的でもあるのです。
 



2013年1月15日

ビジネスサービスのつくり方 - 第2章 企画

■ アイデア創出はジネスモデル起点で
どういうサービスにするかのアイデアを導出する具体的なやり方について考えてみましょう。アイデアというと斬新なものがパッと浮かんでくるのだと思っている人もいるかもしれませんが、そんなことはほとんどありません。ただそれでも、ぼくの場合は、寝ている時とか新聞を読んでいるときとか風呂に使っている時とかにひらめくことがあります。ですから、いつもメモ用紙と鉛筆を置いておきます。(さすがに風呂場には持ち込みませんが)最近では、iPhoneのメモに書いたり、ボイスメモに録ったりします。

しかしながら、いま言ったように全くゼロから発想するようなものはほとんどなく、もやもやしていたことが晴れるとか、もつれた糸がほぐれたといった感じでしょうか。というのもアイデアというのは、「Webサービスのつくり方」にも紹介してあるジェームス・W・ヤングの言葉のように「アイデアとは既存の要素の新しい組み合わせ以外の何ものでもないということである」ということだからでしょう。

それと、アイデアと言っても目的というか、こういうことができるといいかなあといったものがあるわけだから、手がかりがあるのである。ではビジネスサービスの場合はその手がかりは何なのだろうか。それがモデル起点というアプローチにあるように思っています。つまり、モデルを書いてそれを眺めることによってアイデアを湧出させようとすることです。最初にビジネスモデルを描くことで、そのモデルのどこの部分でどんなサービスがほしいかという観点で練ることになります。

ビジネスモデルというのは、何から構成されているのかという問題については、最近よく売れている本に『ビジネスモデル・ジェネレーション ビジネスモデル設計書』(アレックス・オスターワルダー (著 )/ イヴ・ピニュール (著 )/ 小山龍介 (訳 )/ 翔泳社)というのがあります。そこでは、ビジネスモデルの構成要素を次のように定義しています。

①顧客セグメント(Customer Segment)
②提供する価値(Value Proposition)
③チャネル(Channel)
④顧客との関係(Customer Relation)
⑤収入の流れ(Revenue Stream)
⑥主なリソース(Key Resource)
⑦主な活動(Key Activity)
⑧パートナー(Key Partner)
⑨コスト(Cost Structure)

これらの要素をビジネスモデルキャンバスというところ記述していくわけです。これを埋めていきながらアイデアを出していくとよいでしょう。ただ、これだと"提供する価値"の中にアイデアが詰まっていくように思えてくる。つまり、他の要素を検討しながら価値へつなげていくのが順序だと思うのである。いきなりは価値は書けないのではないでしょうか。

従って、ぼくのやり方は、どこの誰に(市場・顧客)にどんな商品(製品・サービス)をどのリソース(人・モノ・金・技術・チャネル等)を使って、どのように提供(サプライチェーン)して、どうやって儲けるか(収益モデル)をまず記述して、それぞれの強み弱みの分析結果や思いを表現したものが価値となるように思っています。

その価値を実現するのがビジネスサービスであり、そこからどんなものにするのかというアイデアを導き出すのです。いずれにしろ、ビジネスモデルをまずは書いてみて己の立ち位置を確認していてそこから発想するのが現実的で実現性の高いアイデが生まれるのではないでしょうか。
 


2013年1月21日

ビジネスサービスのつくり方 - 第2章 企画

■ ハイブリッッド型アプローチ

ビジネスモデル起点でビジネスサービスを企画していくわけですが、そこでいきなりビジネスサービスを浮かべるというのもなかなか難しいでしょう。ビジネスサービスというのは結局ビジネスプロセスのどこかを切り取ったものであるとも言えるので、ハイレベルのビジネスプロセスに展開してから吟味、導出を行ったほうがよいと思います。

それを、まっさらのところから始めるのも難しいものです。そんな時には参照モデルを利用するのも一策です。企業というものが登場してきてから、あまたのビジネスモデルが現出しているわけだから、そのなかから成功モデルを抽出して標準化すれば参照モデルができます。そうしたものをお手本にしたら時間の節約にもなるし、抜けがないものになるのです。そうした、参照モデルの代表的なものは次のようなものがあります。

1.VRM(Value Reference Model)
2.PCF(Process Classification Framework)
3.SCOR(Supply-Chain Operations Reference)
4.DCOR(Design-Chain Operations Reference)

こうした参照モデルは、汎用性を持たせているがゆえにわりと抽象度の高いところで止めています。細かくすればするほど個別性というか特有な要素を入れなくてはいけなくなって、カテゴライズし派生させて複雑化してしまうからです。ですから、そこからのサービスへの落とし込みは個別にやる必要があります。

その時、ハイレベルのモデルプロセスをさらに詳細に分解していくトップダウンアプローチでは限界があります。先ほど言ったようにモデルはどれにもあてはまるように網羅的な作りになっていて、どうしても冗長的ですから要らないものをそぎ落とす作業が必要になります。ではそうしたそぎ落としはどうやったらよいかというとボトムアップ的にやらざるを得ません。そのビジネスに何が必要なのかは、実際のビジネス形態から発想されるからです。

つまり、おおかたの枠組みはモデルベースでトップダウン的に固めておき、その要不要を含めた中身はボトムアップ的なアプローチでサービスを導出するというのが現実的な解であると考えています。これがハイブリッド型のアプローチです。トップダウンの網羅性であるがゆえの冗長性とボトムアップのAsIsベースであるがゆえの抜けという弱点を補完するやりかたです。

ところで、ビジネスモデルというとついお金儲けのスキームみたいな捉え方がされます。昔はビジネスモデル特許というような話題があったと思いますし、最近ではネットビジネスの広告モデルとが携帯課金モデルとか、はたまたAKB48モデルとかが喧伝されています。確かに、ビジネスモデルといえばそうなのですが、ここではもう少し広い意味でビジネスモデルと言っていますので注意してください。

ちなみに、今例をあげたものは狭い意味のビジネスモデルで収益モデルあるいは商流モデルといった表現にしています。ここにも参照モデルのようなものがあってぼくは「ピクト図解」というのを利用しています。このように参照モデルとリアルモデルをうまく組み合わせてサービス定義をしていくのが大事になってきます。
 


2013年1月29日

ビジネスサービスのつくり方 - 第2章 企画

■ どこから始めたらよいのか

ビジネスサービスの企画はビジネスモデル起点のハイブリッドアプローチで行うのが基本なのだが、現実にはそうはいかないケースが多くあると思う。つまり、もう問題の所在が明らかで具体的にやるべきものが見えていたり、早く効率的ないオペレーションをしたいといった場合にはそこから始めてもかまわないということである。

立案された戦略から、それを実現するための業務プロセスを特定し、そこにKPIを設定し、といったやり方は教科書的には正しいが、それは全社的なプロジェクトとなって、大がかりな進め方が始まるとそこで疲れてしまって挫折するなんてことにもなりかねない。だから、目の前の改善要求に対して企画するというのもありだと思っている。特に、部門内やグループでの起案では仕方ないでしょう。

しかしながら、注意しなくてはいけないのは、そういった始め方だと部分最適であって、全体最適にはならないのではないかという批判がついてまわる。ですから、お勧めしたいのは、ある程度進んだ段階、そうですね、プロセスの概要ができてきたぐらいで、そこからビジネスモデルに遡ることをしたほうがよいということです。

いま自分たちが作ろうとしているビジネスサービスは自分たちが営んでいる事業のビジネスモデルのどこに位置するものかという確認をすることが大事だと思う。先にサービスのイメージを作っておいて、それが事業戦略やビジネスモデルの目的に合致しているかどうかチェックするのである。いくら、問題があるからとか緊急性があるからとか言っても、事業の目的とかけ離れていたら作る必要はないかもしれないからである。

よく、企画では目的の明確化ということが言われます。しかしながら、注意しなくてはいけないのは、時として目的の目的化、手段の目的化がおきてしまうことです。どういうことかというと、お客さんの問い合わせに応えるのが煩雑だから自動応答サービスを作るという企画を立てたとします。すると、問い合わせ対応業務を分析してその業務を自動化するということが目的になります。そこは明確ですとなる。

ところが、事業の性格から、ただ早く答えればいいというのではなく遅くてもいいから丁寧に対応することで顧客満足度を高めているのがその事業の強みでそこで他社との競争に勝っているとしたら目的は明確化しているかもしれないが十分ではない、あるいは逆行してしまうことだってある。ですから、重要なことは目的の明確化の前に、"合目的性"をちゃんとチェックすることが重要なのである。

さて、身近なところから泥臭く始めても構わないが、いったん目を高みに転じて、それこそ"上から目線"で作ろうとしているサービスを眺めてみたらどうかという提言である。始めるための敷居は低いほうがよいという面は否めないので、気楽に初めて立ち止まり、またさっさとやるという循環サイクルをお勧めします。日本BPM協会の推進フレームワークにある3つの輪は循環サイクルとなっていて、どこから始めてもいいが必ず全体を見ることなのです。
 
BPMsannbonnnoya.JPG

2013年2月 5日

ビジネスサービスのつくり方 - 第3章 設計

■ サービスは何から成り立っているのか

さて、次は設計フェーズに入ってきます。ビジネスサービスの何を設計することになるのでしょうか。それを考えるにはサービスは何から成り立っているのかを見るのがよいでしょう。まずはサービス学会のサービスの定義は「提供者が受給者の望む状態変化を引き起こす行為」となっています。ところで、サービスという概念で見るとこの定義のようにITシステムのことではないことがわかると思います。

つい、企業的なビジネスサービスはITシステムによるサービスだと思いがちですが、人手によるおもてなしもサービスになるわけです。ただ、会社は、組織としての活動が基本ですから、おもてなし風な個人に依拠したものはあまり対象にはしませんが、ITだけではなく人とITとの合わせ技だということを理解してください。

ですから、ここでは「提供者が受給者の望む状態変化を引き起こす行為」がうまくいくような仕組みはどんなものであるのかという捉え方をします。ビジネスでは往々にして受給者は顧客ということになります。ですから、お客さんがこんなものが欲しい、こんなことをして欲しいと望んだとき、それに答えてやることです。ただ、この受給者は顧客だけに限ったことではなく、例えば社内の従業員に向けてサービスを提供するなんてこともあるので、社内外に受給者がいます。

さて、サービスを提供する仕組みはどんな要素から成り立っているのでしょうか。メタレベルで見ると「プロセス」「機能」「情報(データ)」から成り立っていると考えています。つまり、サービスはワンショットで終わることはほとんどなくて、いくつかのサービス要素を順番に繰り出すことが多いと思います。これがプロセスです。連続、非連続問わず徐々に望む状態に変化させるという流れです。

そのときの変化のさせ方とか提供の仕方などは受給者が望むようにしようとします。早くしてほしいのかとか、驚きを与えてくれとか、逆に安心感をもたせてくれといったように提供の仕方に工夫がいります。それが機能です。ITで機能というと検索ができるようにとか、計算速度を早くとか、画面のレスポンスが何秒とかいうシステム的な機能を考えがちですが、最初の段階ではもう少し抽象度を上げて見たほうがよいでしょう。

そして、ビジネスサービスでは結局は受給者に与えるものは「情報」という形になります。もちろん、商品という物理的なものを渡すというサービスがありますが、それでも、受給者はモノそのものというより、そのモノに付帯した情報を求めているのではないでしょうか。つまり、そこに載せる情報は何がよいのか、どんな情報を参考にしてモノを渡すのか、サービスを行った結果も情報として残るということもあるわけです。

ということで、ビジネスサービスを構成する要素は大きく「プロセス」「機能」「情報」になると考えています。ということで、ビジネスサービスを構成する要素はどんなものが必要なのか、その組み合わせ構造をどうしたらよいのかが設計になります。実際の設計ではこうした要素を更に分解していき具体的な要素機能や構造に落とし込んでいきます。
 

2013年2月12日

ビジネスサービスのつくり方 - 第3章 設計

■ デザイン領域

ビジネスサービスをデザインする場合、サービスの持つ機能と同時にどこの領域をデザインするのかを議論する必要があります。ビジネス活動というのは、経営から現場の作業、会社全体から個人というように多岐にわたるからである。この縦横の各領域で求めるサービスも違うし、やらなければいけないことも異なってきます。

ここをあまり細かく分けてもまたわからなくなりますので次の3つくらいの領域に分かることでよいかと思います。

①Design in Management
②Design in Operation
③Design in Action

最初のマネジメントのデザインですが、サービスデザインという言葉が似合わない感じがしますね。特に日本ではあまりイメージがわかないと思います。しかしながら、サービスという意味合いが薄いかもしれませんが、デザインという考え方はぜひ採り入れたいものです。一番のいい例は「戦略のデザイン」や「事業のデザイン」です。どうもこの辺をきちんとデザインできている経営者や事業部長が少ないような気がします。

それは別な言葉で言うとプロフェッショナルがいないということです。マネジメントのプロはちゃんとデザインをしますというかここが命です。日本では現場のプロはいっぱいいますが、経営のプロというのはわずかです。本来は経営や事業運営も気合だけの人、みんなに好かれる人、過去に実績のあった人がするようなものではなく、高度なデザイン力を持った人がなるべきでしょう。

オペレーションというのは、組織に割り当てられた業務プロセスを円滑に運営することです。それに必要なことは、「適正なコントロール」「効率的なオペレーション」「正確なモニタリング」ができるようにデザインすることです。このなかで「効率的なオペレーション」というのがちょっとあいまいですが、要はスピードと質の高い意思決定ができているかということです。そして、それを可能にするためには、センシングをちゃんとやって、状態を的確に把握して、管理目標から乖離したらそれを修正するように制御しすることができていないといけないわけです。ここのところのデザインが非常に重要になってきます。

アクションレベルでは、基本的には役割を与えられた人が、その責任においてやるべきことを適切に実行できるかが問われます。つまり、所与の単位意思決定を行って業務進めていきます。そうした、アクションレベルのデザインで気をつけなくてはいけないのは、孤立したアクション、すなわち個人が自分の勝手な判断で行わないようにすることです。それと、自分の行為が受益者にとってよいサービスとなっているかを絶えず意識することではないでしょうか。

それぞれのレベル、エリアでつながりのある動きができて、その結果が顧客にとって良いサービスとなることをデザインすることがサービス提供者としての責務になってくるのです。これらはとりもなおさず「組織論」あるいは「組織能力」になっていることがお分かりだと思います。ビジネスは組織が提供するサービスによって収益を確保することで成り立っているわけです。
  

 


2013年2月19日

ビジネスサービスのつくり方 - 第3章 設計

■ WhatはHowに優先する
サービスの構成要素とサービスをデザインすべき領域について議論してきたが、いったい何を設計したらよいのでしょうか。サービスを提供する実体というか広い意味でのツールは何かを考えてみましょう。それは少し抽象的かもしれませんが「プロセス」と言ってもよいと考えています。

サービスの構成要素は「プロセス」「機能」「情報」ということを言いましたが、この3つが等価に並んでいるのでしょうか。どうも主従関係がありそうですね。これからは「プロセス」を広くとって主として見ることにします。すなわち、「機能」「情報」はプロセスの中に包含して考えていこうということです。プロセスをオペレーションするためにもつべき機能であり、サービスを受けるための機能であり、プロセスにおける意思決定のための情報であったり、プロセスで生成されるデータであったり、サービスそのものが情報の固まりだったりするわけです。

ということは、サービスを提供するのは「プロセス」を通して行われると規定できそうです。そのとき、すぐにサービスプロセスをどうやって作ったらよいのかという進み方はちょっと勇み足ですよね。それだと、サービスごとにあるいはサービス受給者ごとに作らないといけなくなります。そこはちゃんと構造化して、こんな形のサービス形態で提供するというふうに考えたいものです。ある程度標準化、共通化することが望まれます。

それでその構造はどうあるべきかを発想するときにはオペレーションから見ていくことをお勧めします。なぜならば、所詮ツールを作るのですから、使われないものをせっせと作っても意味がありません。使ってもらって、あるいは受けてもらった結果としてサービス受給者が満足しなくてはいけません。ですから、実際のサービスオペレーションから使ってもらえるため、喜んでもらえるためにはどんなサービスの形がいいのか、つまりHowの前にWhatをしっかりとデザインすることが大切です。

こうしたWhatはHowに優先するという考え方をもたないと、たとえば情報システムをつくる場合なんかだと、直ぐにどんな言語で開発したらよいのかとか、パッケージはどれにしようかといった技術視点でのHowからのアプローチになりがちでです。いくら腕のいい大工さんが家を作ったとしても、ひどい設計の家だと何ともならんでしょう。ところが日本ではHowの技術を評価する傾向が強いように思います。いいものを作れば売れるという思いもここから出ています。

よく例え話をするのですが、有名な岡野工業の岡野社長の話です。直径0.2ミリという極細の痛くない注射針(現在は0.18ミリだそうです)を深絞りというプレス加工技術で作ってしまったことで有名になりました。多くの人は岡野さんを絶賛するのですが、もちろんそれを否定するわけではないのですが、もう少しインシュリンの注射針で苦しんでいる人を助けてあげたいということから極細の注射針を作ってくれと頼み込んだテルモの人を褒めてあげたいのです。

HowではなくWhatを考えた人です。もちろん、両方とも重要であることは間違いないのですが、岡野さんのHowを生かすためのWhatを考えたことがすごいのであり、そこからあのような製品ができたのです。サービス学会では「製造業=製造代行サービス業」と定義していることからもビジネスサービスではWhatを先行させるアプローチが重要なのです。
 


2013年2月27日

ビジネスサービスのつくり方 - 第3章 設計

■ 身近なところから始めてみたら

何度も繰り返してしつこいと思われるかもしれませんが、設計といってもITシステムを設計するわけではありません。どんなサービスをどんなふうに提供したら喜ばれるのかということ、すなわち"スタイル"のようなものを設計することが大事になってきます。ですから、企業でいえば社風とか事業方針といったものが反映されてくるわけです。

そう考えると、ITはひとまず置いておいておもてなしのスタイルを考えましょうというのが出発点のようです。これだと、何か身近にありそうですよね。会社の業務ではなくても、例えば何かのイベントを行うとか、ボランティアなんかもそうだし、簡単な例でいくと、職場の忘年会の幹事に指名された時を想定してみてください。

ある日、部長からお前今年の忘年会を企画してくれと依頼されたらあなたはどうしますか?参加するみんなが喜ぶような企画・計画をしますよね。そして、実行して皆さんが満足できたらうれしいと思うはずです。そのためにどうしたらよいのかが設計となるわけです。ここで気がつくと思いますが、そんなことにITシステムを設計するだろうか。もちろん、計画を進めてたり、実行するときにITを使いますが、それはあくまで道具として使うわけです。

言い方はおかしいのですが、忘年会開催プロセスも立派なプロセスです。では、実際にプロセス的に追っかけてみましょう。まずは、部長からだいたいこのあたりで、部全体でやろうぐらいな言い方で頼まれるはずです。さらに、今は業績も良くないのであまり派手にはやらない方がいいだろうといった制約を言われることもあるでしょう。

忘年会の開催を頼まれ、それに応えて実施するまでの手順がプロセスですから、さてどうしましょうかと考えたとき、おそらくいつまでに何を決めたらよいのかということが浮かぶと思います。つまり、決めるべきこと、それはいつまでなのか、決めるにはどんな情報を参照するのか、制約条件はあるのか、だれに相談をしたらよいのかといったことになるでしょう。

もう少し具体的に見ていくと、わかりやすいのは5W1Hで考えたらよいでしょう。まあ目的は忘年会だからWhyは除いてもいいので、まずはいつでしょうね。日時(When)を決めます。次に場所(Where)、そしてどんな形式や会費(What)にするのか、それが決まると参加者(Who(m))を募集します。さらに当日の進行(How)を決めて実施ということになると思います。

ただ、こうしたことが簡単に決められるとは限りません。日時にしても部の業務のスケジュールとか部長の出張の日とかをチェックするはずです。場所はそれこそ「ぐるなび」や「食べログ」で調べるとか、過去に評判がよかったところとかを探しますよね。また、出欠をとるのにメールじゃないアプリを使うでしょう。

ですから、プロセスを実行するうえで決めなくては行けないこと、それを決めるときに参考とする情報や制約、それがいつまでなのかという管理指標などを定義していくのがプロセス設計なのです。そこに全体の進捗が見えるようにするためとか、情報がネットからリンクされるとか、通知配信する仕組みとか、そういったところで必要に応じてITを使うことだと思います。

当たり前のことですが、この幹事さんが、スマホだけで忘年会を企画・計画・実施したからといって、プロセス設計、オペレーションをしていないとは言えないでしょう。自分の手帳に手書きで書いてそれをチェックしながらやるのもプロセスオペレーションです。つまり誰でもやっていることなのだが、それをもっと明示的にオープンにして行くことなのだが、そのためには前回提起したように標準的構造化をしたWhatが必要で、その構造にあった中味をデザインすることが大切なのです。
  

2013年3月 4日

ビジネスサービスのつくり方 - 第3章 設計

■ いきなりToBeを書く

プロセス設計というと普通は現状分析をしてAsIsとして書き出して、それをいろいろな角度から分析して、見直しをして、変えるところを見つけ出し追加・削除・変更を施してToBeにする。これって、ちょっと変だと思いませんか。AsIsに問題があるから、直そうとしているのにAsIsをベースにしているわけです。そこでは、どうしても現在の延長線すなわち連続的な思考になり、少なくともイノベーティブなものは出てきそうもないですよね。

だから、そんなことをする必要があるのかということです。もちろん、業務プロセスは現状にないわけではなく、現にビジネスをやっている限りどんな企業でも必ずあります。それならその業務プロセスがAsIsではないのかという指摘もあろうかと思います。問題は、ほとんどの場合、AsIsのプロセスを書いていますといっても業務分析、作業手順になってしまっているから意味がないと言っているのです。

業務体系表に従って、組織のそして個人のタスクを書き出すわけです。それって、組織や人の仕事を解析するのであって、改革とかビジネスモデル変更要求引き出しとかいった動きとは別です。重要なのは、今やっている事業にとってどういう業務プロセスだとビジネスの要請から持ち込まれる要求を実現できるかである。設計とは、そういった業務プロセスを設計することです。

ですから、設計アプローチは現状がどうのというよりToBeをいきなり設計するという感じにならざるを得ないのです。つまり、これも何度も言っているのですが、組織と人から離れて、かつITシステとも無関係に俯瞰的な目線で書き出しましょうと言っているわけで、そうなるとほぼ必要なプロセスは決まってきます。このプロセス(まだフローを主体にしたもの)はすでにToBeというわけです。

さらに、そのプロセスに必要な要素を当てはめていくことで全体としてのToBeになります。ただ、ここで気をつけなくてはいけないのが、ToBeのレベルのことである。本当に理想的なものといったら技術的に難しかったり、リソースが不足していたりということは往々にしてありますし、経済合理性がない場合もあります。ですから、ToBeという言い方がよくないのかもしれません。ベストは難しいのです。

会社の成熟度に応じた、その時点で採れる最適な形態をToBeというふうに定義したほうがよいと思う。現有する経営資源のもとで当該ビジネスの執行にもっともよい業務プロセスを現状からではなく、ビジネス起点で書いてみるというのが最も簡潔で分かり安いアプローチだと思うのです。いきなりToBeを書こうというよりも、ビジネス起点で書き出すと自ずとToBeを書く事と同じになってしまうと言ったほうが適切なのかもしれませんね。
 


2013年3月14日

ビジネスサービスのつくり方 - 第3章 設計

■ いったい何を定義したら設計されたことになるのか

こうした議論で設計というといわゆるITシステムの設計というふうに捉えられがちである。そうなると、(1)要件定義 (2)外部設計 (3)内部設計とか、あるいは(2)(3)を概要設計、詳細設計と呼んだりします。まずシステム要件を定義して、それに従って、システム機能設計、具体的には、画面設計、帳票(レポート)設計、データベース設計などを行い、そこで決まった機能をプログラムレベルに落とした設計を行うというわけです。

ところがここでは、"ビジネスサービスの提供プロセス"を設計することですから、ITシステム設計とは異なることがおわかりになるとい思います。画面や帳票、データベースを設計することはもちろん必要ですが、それは一部といった側面しかないように思えます。この章の最初に言ったようにサービスとは「提供者が受給者の望む状態変化を引き起こす行為」であるから、そのための構造や機能を設計することになります。

つまり、"受給者の望む"ことが何なのか、そのリクエストに対して、どうやって応えていくのか、その結果として"受給者が満足してくれる"かという一連のプロセスを設計することが大事なのです。しかも、それはただ格好を作るだけではなく継続的に使い続けることを考慮したものでなければいけないのです。そうなると、プロセスをオペレーションするために必要な機能から発想したらどうでしょうか。これも一種の要件定義ですが、システムにとっての要件ではなく、サービス提供プロセスとしての要件ということになります。

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

これらは、サービスを提供するプロセスの機能概要ということになります。次にこうした要求機能を実現するためにプロセスを構成する要素が必要になってきます。プロセスというのは、始点と終点があってその間に複数のアクティビティがあるもので、アクティビティというのは単位意思決定を伴うものです。単位意思決定というのはさらに具体的に言うと、データを確定すること(文書も含む)、判断をすることです。

さて標題の「いったい何を定義したら設計されたことになるのか」ということになりますが、まずはコアで必須の要素である「確定するデータは何か、どんな判断をするのか」を定義します。プロセス設計というと順序性を重視してフローの定義を一生懸命しますが、サービスプロセスはそれほど厳密ではなくてもかまいません。サービスの順番ってきちっと決められたものではありませんよね。お客さんによっては順番を変えたりすることもあるからです。ですから、おおよその順番で並べておきます。

次に、各アクティビティ(単位意思決定=データ確定・判断)で必要なプロセス要素を定義します。「付帯登録情報」「業務ルール」「参照情報」「ロール」「パフォーマンス管理指標」「分岐先・連携先」といったものになります。この段階でIT的な設計がないのがおわかりだと思いますが、基本的にはプログラミングしてスクラッチで開発することは考えていないからです。つまり、市販ソフトウエアを利用するのでそこに内包している機能を使えばよいからです。
 

2013年3月24日

ビジネスサービスのつくり方 - 第3章 設計

■ プロセス要素の定義

具体的なプロセス要素の定義をみていきましょう。コアのデータ確定というのは意思決定の典型的なものですよね。例えば提供商品名を決めるとか、納期を確定するなんてことになります。確定するデータがどんなものなのか、どういった判断をすることなのかが決まるとそういった意思決定に必要な"もの"や"こと"をプロセス要素として定義していきます。

確定データは基本的にひとつなのですが、現実的には複数になることもあるし、補足するべき情報として登録したいものが出てきます。このあとのほうで言っているものが「付帯登録情報」です。例えば、納期が確定データだとそれに付随する納入条件といったものはこうした付帯情報として定義しておくということです。

意思決定というのは、単に誰かが勝手に決めることもでき、よく言えばと裁量ということになるのですが、往々にして属人的な決定プロセスになってしまい、人が変わると決定の仕方も変わってしまうことになります。ですから正常な組織ではそうした属人性をできるだけ排除すべく取り決めをすることになります。それが業務ルールです。実際にプロセス設計をしていくとルールがない状態が多いことに気づくと思います。ただルールといってもきちんとルールブックに記述していなくてもよくて、組織構成員で共有されていればよいと考えても構わないでしょう。

業務ルールには、規程・基準・規則・ガイドラインといった様々な名前がつけられていますがあまりこだわる必要がないと思っています。そこをきちんとしようというとルール体系を作りましょうとなるわけですが必ず失敗します。重要なことは、プロセスの意思決定のために使うルールは何かというアプローチでルールを定義することです。そのルールがどんなプロセスのどの場面で使われるかに紐づいていないと意味がないということなのです。ですから、ルールマネジメントというのは必ずプロセスに従属的にやるべきことなのです。

意思決定には情報を参照して行うという側面もあります。その参考とする情報にはどんな種類のものがるのかというと、事実情報、判断情報、制約情報の3種類です。業務ルールも参照情報の判断情報一種ですが重要なので抜き出しでおきます。事実情報には、マスタ、販売実績のような履歴情報、予算といった計画情報、競合他社情報といった外部環境情報などがあります。

判断情報には、業務ルールの他にリソース状況のようなものがあります。例えば担当者を指名する場合に要員の稼働スケジュールをみるなんてことをするわけです。また、ちょっとした計算だとかシミュレーションをした結果から何かを判断する場合もあります。さらに帝国データバンクに与信チェックをしてもらうような外部サービス情報なんてこともあります。制約情報は、契約・規約、制約条件、コンプライアンスといったものから得る情報になります。

次はロールです。ロールはプロセスの意思決定に関係する役割のことです。例えば、起案、確認、承認といった役割を誰にやらせるかになります。一番重要なのはだれが最終的にその意思決定に責任を持つのかです。すなわち、承認者は部長なのか課長なのかといったことを定義することです。業務プロセスでは、基本的にはプロセス全体の責任者と単位意思決定の責任者という階層を持ちます。このあたりも今は曖昧になっているケースをよく見かけます。

最後に「パフォーマンス管理指標」についてですが、プロセス制御という考え方からいうと何か変な方向に向かいそうになるとそれを戻すような動きをすることが大事です。その変な方向なのかを測定する指標のことです。ですから、測定対象となる変数とその正しい設定値と異常を検知した場合の知らせ方と戻し方を定義することになります。例えば、見積提出期限というものを制御するとします。測定対象は見積書作成日となり、設定値は提出期限の一週間前で、それを超えたらすぐに作成担当者にメール通知機能を使って早期作成を促すメッセージを送るといった具合に定義します。

まだ、多少定義したほうがよい項目もありますが基本的にはこうしたここにあげた要素を定義すると設計が完了します。
 


2013年3月31日

ビジネスサービスのつくり方 - 第4章 開発

■ コードは書かない、ドキュメントは作らない

さて、ここからは開発ということになります。設計フェーズではプロセスを構成する要素を定義し、「プロセス要素表」というものを作成します。開発ではそれに従って実装していきます。具体的なやり方に入る前にすこし考え方のようなことについて議論していきましょう。開発というと要件定義から起こされたプログラム仕様書に従ってコーディングをするというのが一般的ですが、そこを考え直そうではないかというのが趣旨です。

ですから、Webサービスとも違うわけです。Webサービスは明らかにコードを書いてサービスを作っていきます。もちろん、フレームワークやモジュールを利用したり、マッシュアップといった組み合わせもありますが、基本的にはコーディングが開発作業の重要な位置を占めているわけです。そういったやり方だと開発という言葉が合うのですが、コードを書かないとなると開発というのもおかしいかもしれません。

では、コードを書かないのならどうやってシステムを作っていくのかということになります。ざっくり言うと既成のソフトウエアを組み合わせてシステムを作るということです。家を建てるのにプレハブ工法というのがありますがそんなイメージになります。ですから、開発という言葉はそぐわないですね。家を開発するとは言いませんから。開発ではなく構築と言ったほうがぴったりします。従って、業務システムの場合はシステム開発とはいわずにシステム構築と呼ぶことにします。

逆に、業務システムに使われるソフトウエアは開発することになります。ある機能を実現するために開発されたソフトウエアを組み合わせて組み上がったものが業務システムとなっていくわけです。ノンコーディングで構築されるというのはこういうことです。ただ、全部が全部コードレスかというと現実には多少のプログラミングをする場合ももちろんあります。本当に特殊な機能の盛り込みとかインターフェースといった部分です。

また、既成のソフトウエアは特定の業務システム向けの仕様で作ってあるわけではありませんから、ぴったりフィットしない場合や不足機能があったりします。そんなときについアドオンとかカスタマイズということをしたくなります。それは極力しない方向で考えます。不充分なところや不足する点は人間がカバーしてもよいという割り切りをします。何でもかんでもITで自動化するというのはやめたほうがよいと思います。

例えば、業務フロー進行を自動化しようとすると分岐の嵐になったり頻繁な差し戻しがおきて却って複雑してしまうということがあります。あるいは、トラブルがあった時の異常の発見、復旧に時間がかかることもしばしばおきます。人間の目で管理できる限界を超えてしまっているわけです。しかしある程度人間がシステムに入り込んでおけば防ぐことが可能です。

それと、業務システム構築の段階でプログラミングすればするほどバグの発生という危険が待っています。よくERPなんかでもテストの時にバグが発見されて修正に追われるのはアドオン部分だと言われています。その点、既成のソフトウエアを利用すればその点は非常に楽です。きちっとテストされバグフィックスされたものが納入されるわけですから安心して使えます。だから、余計な手をあとから加えないでそのまま使えばよいのです。

今や、そうしたソフトウエアがクラウド上に多く置かれるようになったのでそれを利用しない手はありません。このクラウドソフトを見てもお分かりのようにドキュメントはありませんよね。多くは、ソフトウエアのヘルプを開けば分かるようになっています。昔のように分厚いドキュメントを書くのだが、いつも間にかメンテできなくなり誰も読まなくなり、結局はコードを書いた人に聞くなんて破目に陥ることもなくなっています。"コードは書かない、ドキュメントは作らない"という方向で行きたいものです。
 

2013年4月 8日

ビジネスサービスのつくり方 - 第4章 開発

■ 再び「ぐだぐだ言ってないでプロセスを書けよ、ハゲ」

前回にコードを書かないという話をしました。そして、シリーズの第1章でウェブ系のハッカーたちの間で「肝に命じる」言葉として、「Shut the fuck up and write some code.」というのがあって、その意味する「ぐだぐだ言ってないでコードを書けよ」のコードをプロセスに置き換えて「ぐだぐだ言ってないでプロセスを書けよ」という話を書いた。つまり、プロセスを中心にして業務を見ていこうということなのだから、とやかく言う前にプロセスを書こうぜということである。

このコードの代わりにプロセスとしたというのが前回の議論のポイントなのである。Webサービスとビジネスサービスではサービス粒度が違っていることに注意してください。単一的なものに対して複合的であるとでも言いましょうか、アクティビティレベルなのかプロセスレベルのなのかという言い方になる。つまり、Webサービスはアクティビティレベルが多く、ビジネスサービスはアクティビティの連なりであるプロセスから成り立っている。

ですから、Webサービスでコードを書くというのが、ビジネスサービスでプロセスを書くことに対応するということになる。コードを書くことでアクティビティを生成するのに対し、アクティビティを組み合わせフロー化することでプロセスを生成するということである。例え話でいうと、自動車や家電製品を作るのがWebサービスで、それらを使ったライフスタイルがビジネスサービスと考えてみてください。田舎に住んでいたら自動車は必須ですが、都会では電車を利用するから必要ないといったことになるわけです。

もうおわかりだと思いますが、田舎に住んでいるから田舎暮らしに適した自動車を設計して作りますか。部屋の空いているスペースにぴったり収まるテレビを作りますか。スタイルをデザインして、それに沿って活動するということは、システム製品を作ることが目的ではありませんよね。いかに快適にとか、節約できるとかいったことが目的になります。

さて、「ぐだぐだ言ってないでコードを書けよ」というのは何しろ動くものを作れよということであるから、プロセスを書いたら直ぐに動かさなくてはいけない。逆に言うと、イメージしたビジネスサービスが直ぐに動くようにするためにはどうしたらよいかである。それがシステム開発(システム構築と言ったほうがよいというのは前回書きましたが)となるはずである。設計フェーズで実際にオペレーションするイメージが持てるようにプロセス要素を定義したのはこの流れを意識しているわけです。

従来のように要件定義書やプログラム仕様書ではオペレーションのイメージをわかすことができるでしょうか。コードを書くということはアクティビティレベルのサービスのイメージはわきますが、プロセスレベルのものは難しいでしょう。ですから、設計ではできるだけ業務視野で記述して、そのまま実装できるのが望ましいのです。

設計から直ぐに動かそうとしたらコードを書いてなんていられないので前回に提起したようにコードはやむを得ない場合のみにして極力書かない旨を徹底することだと思います。ということは、自動車や家電に相当するような既成のものとしてあるコンポーネントを利用することです。要求ユーザの前でレゴ細工のように組み上げて見せるようなやり方が必要になるのです。
 

2013年4月15日

ビジネスサービスのつくり方 - 第4章 開発

■ 生産形態と開発メソッド

開発というと、最近ではウオーターフォールなのかアジャイルなのかなんて議論があったりします。どんなメソッドで開発するのかという話です。ただ、あたりまえ前の話として、どうやって作るかというHowは、どんなものを作るかというWhatに依存する。作るものや動かすものの性格によって作り方は違ってくる。

このことは、何もITシステムに限ったことではなく、一般的な製造業も同じというか、そもそも製造業は何を作るのかというプロダクトがあって、その生産のためにどんな生産方式を採るのかということになる。なので、ちょっと寄り道をしますが、生産形態について見ていきましょう。生産形態にはタイミングとか、製品の種類、生産方式などで分類することが一般的です。

・ 受注タイミング :受注生産/見込み生産
・ 製品の種類と量 :多品種少量生産/中量生産/少品種大量生産
・ 生産方式    :個別生産/ロット(バッチ)生産/連続生産

といったところですが、それぞれ全部の組み合わせがあるかというとそうではなく、大体次の6種類になります。
(1) 見込み生産/少品種大量生産/連続生産
(2) 見込み生産/少品種大量生産/ロット(バッチ)生産
(3) 見込み生産/中量生産/ロット(バッチ)生産
(4) 受注生産/中量生産/ロット(バッチ)生産
(5) 受注生産/多品種少量生産/ロット(バッチ)生産
(6) 受注生産/多品種大量生産/個別生産

さて、IT(ソフトウエアやサービスシステム)の場合はどうなるのであろうか。どうも物理的な実体がある一般製造業とは違って、量的な問題はあまりないように思える。つまり、物理的な大きさとか数というのは、コピーもいくらでもできるし、倉庫に在庫として持つこともないからである。そうなると、見込み生産型なのかそれとも受注生産型なのか、それとどういった生産方式になるのかになる。ただし、連続生産というのはないだろうから、個別生産かロット生産かになる。

これらの組み合わせも大体決まっていて、受注生産型は個別生産方式であり、見込み生産型はロット生産方式といってもいいだろう。ロット生産というのは製品ごとにあるまとまった量を作っておくことなので、ITではそんなことはしないと言われそうだが、ある量を販売するためにあらかじめ用意しておくという意味でロット生産と呼んでもいいだろう。

さて、システム開発という大雑把な言い方をした時に、その生産形態はどうなのかと見ると、ソフトウエアとかパッケージはどうも見込み生産/ロット生産と言えそうだし、業務システムは受注生産/個別生産のようだ。特定の会社の業務システムがそのまま他の会社で使えるかというとそうはいかないので個別に作り込むことになる。

では、冒頭に言ったウオーターフォールなのかアジャイルというのは、個別生産に向いているのか、あるいはロット生産に向いているのかという見方にもなりそうだ。どうも、作り手側で製品の仕様を決めて生産するやり方はウオーターフォールが合ってそうだし、お客さんの要求を調整しながら、場合によっては開発や設計行為も入り込みながら作り込むのはアジャイルが良さそうだ。

ここでお気づきかと思いますが、これまでは、受注・個別生産型である業務システムをウオーターフォールで作ってきたことである。この問題点がいまクローズアップされているように思う。ただ、昔にもアジャイルでやればよかったとは言えない。そういった技術もインフラもなかったのだから仕方がなかった。しかし、現代は環境がずいぶんと進歩したので、問題を引きずることから脱却しなくてはいけない。

ですから、従来のやり方では、受注・個別生産型なのに、製造工程に移る段階で要件定義と称してあらかじめ決められた仕様に沿って作る方式である見込み・ロット生産型にしてしまったのである。その結果、一度決めたら最後まで行って後戻りできない羽目に陥っていたのである。これからの業務システム開発は受注設計生産型にマッチした開発方式を採用すべきなのである。
 


2013年4月22日

ビジネスサービスのつくり方 - 第4章 開発

■ 受注設計生産型の開発方式とは

業務システムは、受注設計生産型にマッチしたような開発方式を採用すべきだと言った。ではその開発方式はどのようなものだろうか。お客さんの注文(要求)に対して、そのものズバリのものがないから、ある程度の設計をしてみて、そこでできたものを見てもらいながら、追加・修正を繰り返しながら仕上げていくことである。とてもアジャイル的である。イテレーションとか、タイムボックス、スプリント、あるいはテスト駆動といったようなことを言わなくても、というかよく知らないから、もっとプリミティブに考えている。

まず、お客さんがどんなことをしたいかは、プロセス設計の段階で聞き取りをすることになる。すなわち、プロセスの始点、終点を決めて、その間のアクティビティを書き、プロセス要素表を作成することで大方の要求が見えてくる。そこには、どんな意思決定すなわち、確定するデータは何か、どういう判断をするのかがあり、そこで使われるルールや参照情報、誰が担当して誰が責任を持つのか、何をコントロールするのかといったことが書かれている。

そこでは、まだ確実なものになっていない可能性が高い。人間は紙の上に書いたものだけではいくら想像力をたくましくしても限界がある。ですから、実際に動くものを見せるのが一番早い。それも紙芝居のようなものより、できるだけ実オペレーションに近いものである必要がある。ということは、いくら早くプログラミングできるからといってもコードを書いていたのでは遅いのである。自動プログラミングとかプログラミングファーストとかは業務システム開発にとってはアジャイルではないのである。

実オペレーションのためのプラットフォームで要求をそのままお客さんと一緒に作り込んでしまえればそれにこしたことはないと思いませんか。それには、既にアプリケーションとして確立できていて、設定だけでシステム構築ができるものを使うことになる。ただ、そうは言っても、完全なものはないわけで、やっぱり作り込みがあるはずだと言う反論はあろうかと思います。そうですが程度問題があって、基本的な部分ができていれば良しとする精神が大切です。

よくある作り込みは、ユーザインターフェースとか帳票です。ここにいくと正解はこれですはないわけで、ほとんどが個人の趣味の領域になります。そんなところに注力するのは後まわしにしておけばいいのです。いまや、Webにしておけば何とかなる話です。ちょっとそれる逸れるかもしれませんが、これまでの業務システムが抱えてきた諸問題、例えば、情報連携・共有、システム運用、セキュリティ、資産管理といったところの面倒臭ささはWebとクラウドでかなり改善していると思うのですがいかがでしょうか。

そういう時代です。Webで作ったコンポーネントがクラウド上にたくさんあって、しかも安価に利用できるようになっています。もう何十年も世界中で業務システムを作り続けています。業務システムで必要な機能は、ビジネスモデルが変化していてもそれほど増えていくわけではありません。いまだに同じものをせっせとコーディングするのもおかしいと思いませんか。お客さんと一緒に有り合わせのものですぐに作って、ああじゃないこうじゃないと議論しながらブラッシュアップしていくやり方でいきましょうよ。
   


2013年4月30日

ビジネスサービスのつくり方 - 第4章 開発

■ なぜBPMSではなくWebデータベースを使うのか

クラウド上にあるWebで作ったコンポーネントを利用してサクッと作りたいと言った。その主要なコンポーネントがWebデータベースである。具体的にはサイボウズ社の提供する「kintone」というソフトウエアを推奨している。ただ、そんなことを言うと業務プロセスシステムだから、なぜBPMS(Business Process Management Suite)を使わないのですかと問われる。当然である。業務プロセスを開発するために作られたツールなのだから、それを使えばサクッと作れるでしょうという。

そう簡単に考えないで、よーく吟味してみましょう。まあ、概して高価であるということもあるが、そうでない切り口でみていく。企業の方々は、ERPのバカ高いパッケージと開発費用がトラウマになっているのかどうか分かりませんが、もうその手には乗らないぞということがあって、費用対効果に疑問を抱いているように思います。だから、なかなかBPMSを導入するのが進んでいないようです。

さて、価格に対する抵抗感はさておくにしてもBPMSが浸透していかない理由は、ベンダーもユーザーもまだまだシステム開発ツールという理解があるのではないでしょうか。スクラッチでコード書いていたのでは生産性があがらないので、フローのロジックのところをパターン化してモジュールにして、設定作業化させればいいのだという考え方である。確かに、ツールになれてくると生産性はあがるので効果的だと思うのでしょうが、そのことはユーザにとってのメリットになるのでしょうか。

皮肉っぽくいえば、ベンダーはいくら生産性をあげたからといって、開発費を下げようとする力学は働きませんから、高価なままなので、何だ開発費用はそんなに下がらないじゃないかとなってしまう。ではそれ以外にどんなメリットがあるでしょうか。開発ツールではないと規定したら、何と考えるべきだろうか。このシリーズで言い続けている業務オペレーションのためのツールと考えてみましょう。

BPMSを使って日常業務のオペレーションを想像してみてください。おそらく、使い方としては業務プロセスの進捗を管理してフローを回して最終的にはデータ登録という形になるわけです。プロセスというのは、案件の処理というふうにとらえてもよいので、入ってきた案件をどう処理してその結果はどうなったかを記録するということでもあります。そうしたオペレーションがBPMSはやりやすいのでしょうか。

BPMSは、基本的には自動化を目指しています。つまり、処理フローのロジックを設定しておけば、決められた流れで処理してくれるというスタンスになります。それはユーザが望むことでしょうか。要するに、自動化してくれるとうれしいのかどうかです。IT導入という出発点は確かに自動化の追求です。電子計算機です。それはそれで大いに進んできました。ですから、その領域はほぼやり尽くしているように思えます。

まだ自動化を追求するところがあるのでしょうか。これからのIT導入は単なる自動化ではなくもっと違った目的をもったものになるような気がします。どうも、自動化に向いていない非定型的な業務に焦点があたってきて、そこの領域のIT化がねらいどころになっていると思います。ですから、そこに定型的な処理をもってこようとするBPMSに矛盾を感じるのです。どうもこの辺の違和感があるために使うのを躊躇している。だから、プロセスといっても最終的にはデータ登録になるわけだから、データ登録がやりやすい、どうやってそのデータを記録したのかがわかるような工夫ができるようなWebデータベースを選択しているのである。
 
 

2013年5月 7日

ビジネスサービスのつくり方 - 第4章 開発

さて、連休も明けたので、ITの話でもしますか。

■ Webデータベースを使う上での工夫

これまで、BPMSが定型処理の方向に向いているのに対して、現実にIT化の要請は非定型業務にあるという矛盾を感じたために、開発基盤、オペレーション基盤に本来それように作られたはずのBPMSではなくWebデータベースを持ち込んだことを述べた。実は、この非定型業務のプラットフォームは目新しいことでもなく、以前BPMの実行基盤を探っていたとき、いくつかの参考事例に出会うことになった。

ぼくは、ずっとエンタープライズの世界でのITを追いかけていたが、息子と起業して知ったWebの世界に非常に興味を抱くようになった。ここではビジネスサービスの代わりにWebサービスを作っているのだが、その開発のやり方が参考になったのである。とは言っても、システム開発の類似性を言っているのではなく、仕事の進め方、すなわち業務オペレーションの方である。彼らはチームでそれぞれの得意を活かし、たえずコミニュケーションをはかりながら、コミットメントを繰り返してサービスを作りだすというオープンな世界を確立している。

そのとき、これからのビジネスの世界もこうしたスタイルで仕事をしていく時代になると思ったのである。ですから、ビジネスシステムも同じような仕組みにしたいなあと考えていた。これは、BPMSや従来のソフトウエアやパッケージではできないものであった。


ちょっと逸れるが、既成のSIerやITベンダーに若いWebエンジニアーを混ぜたらいかがでしょうか。もうそういう技術は使っていると言われそうだが、技術の問題ではなく精神のことだから、Webの世界のもつ文化・風土の持ち込みも少しはやったらよいと思う。自分たちの働き方が、旧態依然としたものであったら、新しいスタイルを創ろうとしているビジネス前線に対応した提案ができるわけがない。

それと、CMS(Contennts Management System)に触れることで、具体的なプラットフォームイメージわかしたことがあった。ご存知のように、CMSというのは、Webサイトの構築・管理に使われるツールで、テキストや画像などのコンテンツを作成したり、それを体系的に管理し、Web上で配信するためのものである。そこでは、Webサイトという製品を作るために、誰かが素案を提示し、それに対して関係する人たちが、コミュニケーションをしながら編集していく、そのプロセスのステータスも管理して、最後は承認という形で公開される。

できたものは、設定したディレクトリー構造のリポジトリーに格納され、それらは日常的にバージョンアップされて、その都度バージョン管理もされ、さらにログ監視など、オペレーション昨日も装備されている。wikiやSNSなどもCMSの一種だからわかると思いますが、参加型で集合知、またリンクによる情報連携といったWebの良さが発揮できるわけです。

ただ、CMSはあくまでテキストとか画像が中心ですので業務システムにはちょっとなじみません。従って、CMSの持つ思想を生かしたようなかたちでWebデータベースを活用するというのが、現時点での選択肢であると考えているわけです。
 

2013年5月14日

ビジネスサービスのつくり方 - 第4章 開発

■ 3Dプリンターのように作り、百均のように組み合わせる

またまた、ちょっと寄り道です。従来のように要件定義してプログラム仕様書を書いてコーディングするというやり方とまったく違った方向に持っていこうということなので、その考え方なりを丁寧に説明した方がいいと思うからである。ただ、やり方を詳しく説明してもなかなかわかりずらいこともあるので、その前に抽象的ではありますがたとえ話をします。

まずは、「3Dプリンターのように作る」です。皆さんご存知のように3Dプリンターというのは、CADなどの3DデータをもとにABS樹脂などを加工して3Dの実体を造形してしまうことで(高額なものは石膏とかもあります)、こうした立体物を作りだすのを3Dプリンティングという。これまではずいぶんと高かったのがここへきて非常に安いものがでてききたので大注目です。

ただ、これでものができてしまうと勘違いしている人がいますが、あくまでプロトタイプというか試作品(おもちゃならそれでいいかもしれないが)ができるだけで、実際に工業製品とするには無理があります。しかし、平面でしかイメージできなかったのが立体感をもって見れるのでだいぶ違います。こんなものがつくりたいというイメージがすぐに形になって現れるので、そこから修正したり、追加しながらできるので、制作効率や品質が向上する。

いまは、製造業や建設業、医療などに利用されているようだが、この考え方をシステム構築に活かせないかということである。つまり、業務システムのイメージをどこかに書いてみて、それを"印刷"ってするとプロトシステムができあがるというわけである。モックアップに近いと思うのですが、そこから実際に動くものになればいい。今の3Dプリンターはあくまで模型なので実生産品にはできないが、システムだったらできる。

ただ、言うまでもないかもしれないが、3DプリンターがCADなどでちゃんと設計しないといけないのと一緒で、業務プロセスの設計ができて初めて可能である。それは構造を設計することが肝で、中味はあとから調整することになる。これができると、ユーザと一緒に"じゃあちょっと印刷してみます"といった具合にやり取りすることで本当に使えるものが短期間でできあがる。

さて、もう一つの「百均のように組み合わせる」である。最近の100円ショップはもうばかにできないほど進化していて、驚くような商品がたくさん提供されている。そんな中、百均商品を組み合わせて使用する主婦が現れている。様々なものをつなぎ合わせて立派なインテリアを作ってしまうといったことである。店で商品をみながら発想するのでしょうね。実に楽しそうにやっています。

百均ショップをクラウド上のAppStoreと見立てたらどうでしょうか。単機能のアプリケーションやツールといったソフトウエアをつなげたり、マッシュアップしたり、並列配置したりといったアレンジをすることで広い範囲のアプリケーションを生み出すのである。それぞれのAPIをもうちょっと使い勝手のよい形にする必要があるかもしれないが面白いと思いませんか。

結局、モノづくりはデザイン/制作・製造・実装/オペレーションといった工程がシームレス化してきているわけで、これは物理的実体をもったものでも、ITシステムのようなデジタル情報でも、サービスでも基本的には同じだろうと思う。いちいち百均にあるものを最初から作ることはしないと思うのですがいかがでしょうか。

2013年5月20日

ビジネスサービスのつくり方 - 第4章 開発

■ Webデータベースとはどんなものか

だいぶ寄り道をしましたが、コンセプトを変えていかなくてはいけないことがおわかりになったでしょうか。くどいようですが、おさらいをしておきますと、昔と違って今はビジネス環境がものすごい勢いで変化する時代になっていて、そこにITを使った業務システムが追いついていていない。その原因は、単純にシステム構築スピードが遅いということもあるし、業務側のIT化要求エリアが変化していることがあげられます。

要求エリアのことで言えば、元来のIT化要求領域である経理計算とか、決算システムのような定型化処理である内部プロセスから、お客さんの要求に的確・迅速に対応する顧客接点プロセスの重要性が増したきたわけです。ここは、非定型的で人間が介在し調整による意思決定が重要な機能となっています。従って、こうしたシステム上の性格を表現するには従来のような開発のやり方では対応できないということを指摘しているのです。

さて、これからはより具体的なアプローチとして、まずはサイボウズ社が提供する「kintone」というソフトウエアを例にしてWebデータベースとはどんなものかをみていきましょう。「kintone」は3月にバージョンアップしてかなり機能的に向上してきました。ひとことで言うと、よりSNS的というか、チームによる仕事のやり方を支援する方向になったということです。ですから、データベースという言い方も薄れてきています。

詳しくはここをご覧になってもらえばよいかと思いますし、無料お試し版もありますので実際に使ってみることをお勧めします。そこには、ビジネススピードに応えるファストシステムという表現があって、要するにファストフードのように簡単に提供できるというこで、その持つ主要機能が、「データベース」「プロセス」「コミュニケーション」です。まさに、これからのITシステムが具備すべき三種の神器といえます。

皆さんよく考えてみてください。この三つの要素はこれまでは独立していたように思いませんか。データベースはデータを登録・検索・レポート出力というところが主で、プロセスとかコミュニケーションという機能はありませんでした。プロセスはワークフローという個人ベースのものはありましたが組織能力の発揮という側面では取り残されていました。また。コミュニケーションというとほとんどが電子メールで一部グループウエアがあったくらいでしょう。そして、それぞれが連動していたわけではありませんでした。

ですから、kintoneのコンセプトは時宜にかなったものと言えるでしょう。ただし、kintoneでいうところのプロセスはどちらかというとワークフローに近いものです。つまり、データベース化のためのデータを登録し、それを承認するというワークフローになっています。チームの恊働作業として案件を処理していくというオペレーションをカバーするには弱いのです。工夫が要るということです。

最近は、クラウドとかスマホやタブレット対応とかビッグデータだとかがもてはやされていますが、一般的な企業の業務システムでは、「コミュニケーション」を主体として「プロセス」を回し「データベース」を確定するという機能がコアであることを忘れないでもらいたいのです。
 


2013年5月27日

ビジネスサービスのつくり方 - 第4章 開発

■ 開発で失敗することはあるのか

またちょっと脱線します。よく「開発に失敗しないためには」とか「成功のための守るべきこと」と言ったような語られ方をする。ということは当たり前だが失敗することがあるからそう言うのだろう。ところで、業務システム開発で失敗するというのは何を意味しているのだろうか。すなわち、受託開発で失敗するのはどういう状態をいうのか。プロダクトを開発する場合はほとんどが売れないことが失敗だろう。

ところが、受託開発では買ってくれるのは前提なのだから、言われたものが作れなかったことなのだろうか。そうしたケースはデスマーチになりながらも何とか納入はするのではないだろうか。それでも出来上がればプロジェクトとしては失敗ではないかかもしれない。(中にはスルガ銀行とか特許庁の例もあるし、ぼくも経験があるが)となると、作ったはいいが使われなかった、あるいは使えることは使えるのだが所定の効果がでなかったといったことが失敗だったとなるのではないでしょうか。

つまり、成功するというゴールを要件定義で決められた仕様通りに作ることに持っていくことが間違いであることを意味している。使ってもらえるかどうか分からない段階で失敗したとかうまくいったと言っても始まらないのだ。そう考えると発想の原点がずれていることに気づくと思う。最初から、こんなものを使って業務を遂行したい、仕事がうまく行くためにはこんな道具があるといった視点でシステムを考え、デザインすべきだと思いませんか。

「オペレーション発想のシステム設計と開発」が重要なアプローチになるでしょう。こうすれば、最初に使い手側と合意したオペレーションプラットフォーム、つまり業務適用に使うことがあらかじめ決まっているアプリケーションを作るわけだから失敗のしようがない。いや、それが作れなかったら失敗でしょうと言われかねないが、作れないならやめればいい。まだ、そういった技術やツールがないのだから時期尚早とあきらめればいいだけだ。

以前、セブンイレブンの人の話を聞いてこのことを思ったのだが、あの有名なPOSデータを解析して、売れ筋を把握し各店舗の品揃えを素早く変えていくという仕組みは、当初はネットワークのパフォーマンスが低くて、思ったものができないということであきらめていたそうだ。そして、そのうち飛躍的なネットワークパフォーマンスの向上がなると即座に実行に移したという。技術的あるいはコスト的な制約があるときはじっと我慢して、所定の能力が確保できたとなると実行したわけで、これでは失敗するわけがない。

ということでオペレーション発想ということを強調したが、スクラッチでコードを書いているようで、こうしたアプローチはできない。従って、市販の既に動いているソフトウエアをベースにこんな道具で、こうしてオペレーションするんだというイメージがわきやすいものを選択しているのである。

ただ、世の中にあるソフトウエアやパッケージがオペレーション発想でできているのかというといささかお寒い話ではある。その点、Webサービスは逆にそこが生命線だから、いいものがいっぱいある。なぜ、ビジネスサービス特に供給サイドの人たちが使うものにないのだろうか。きっと、業務システムとはデータを登録するためのものだという旧態依然の考えから抜け出ていないからではないでしょうか。
 

2013年6月14日

ビジネスサービスのつくり方 - 第4章 開発

■ プロセス要素表さえあれば

さて、だいぶ遠回りをしてきましたが、実際にWebデータベースに実装していきましょう。この章の最初に言ったように設計フェーズで作成した「プロセス要素表」に沿って設定していきます。プロセス要素表には、当該業務プロセスをオペレーションするために必要な項目を列挙してあります。ですから、基本的にはその通りにオペレーションできればよいことになります。

おさらいの意味で何が書いてあるか確認しておくと、まずはプロセスを構成しているアクティビティ(単位意思決定)とそのフロー(アクティビティの順番)が書いてあります。そして、各アクティビティの中の設定項目が定義されてます。確定データ、付帯登録情報、業務ルール、参照情報、ロール、パフォーマンス管理指標などです。

これらが設定され、案件が発生したらそこにデータがエントリーされていくと業務が遂行されるわけです。仕事というのは、ある意味業務依頼書の空欄を埋めていくことに等しいと言えます。そうした業務プロセスが適正に動かすためにアクティビティの中の項目が設定されています。すなわち、業務の進捗がわかること、どんな情報を見て意思決定をしたか、誰が責任を持っているのか、プロセスをコントロールしているのかといったことオープンなプラットフォームに現れていることが重要になります。

前にも言ったようにこうした考え方にぴったり当てはまるソフトウエアはありませんから、現状では使いやすいWebデータベース、具体的にはサイボウズ社の「kintoe」を使います。その適用にあたっての工夫を下記に示します。

  ・プロセス全体を一つのアプリとする
  ・プロセス要素表をそのまま入力フォームに書き込む
  ・アクティビティ単位をフィールドグループとして区切って表示する
  ・各アクティビティのステータスを入力するフィールドを設置する
  ・進捗管理一覧表にステータスを表示する
  ・情報共有やコミュニケーションは、コメント欄や添付ファイルで行う
  ・参照情報の取得はルックアップ、ハイパーリンクなどで行う
  ・アラートは通知機能を活用する

実際のソフトウエアを知らない人にはわかりにくいので若干の説明を加えておきます。普通、データベースソフトというのは、1件1葉の画面、すなわち登録フィールドを埋めてエンターとするのが基本です。そこを、複数の登録画面を配置し、ぞの全体をひとつのアプリケーションとします。「kintone」は最新のバージョンアップでなんとそれをフィールドグループとして括れるようになったのです。これで、アクティビティごとの区分けが明示でき非常にわかりやすくなりました。

データベースソフトは、基本的にはデータエントリー画面と一覧表からなっていますので、その一覧表に各アクティビティのステータスを表示させると、プロセスの進捗がわかります。また、「kintone」にはデータエントリー画面の右横にコメント欄がついています。ここに関係者がコメントを書き込むことでコミュニケーションをしながら意思決定ができることになります。さらに、参加者へのメール通知機能がありますので、アクションを促したり、注意を喚起することもできます。こうして見ると、何もコードを書かなくてもソフトウエアのもつ機能(本来の目的と違っていても)を工夫して使えばかなりのことができてしまいます。

2013年6月24日

ビジネスサービスのつくり方 - 第4章 開発

■ kintoneを使ったアプリ作成手順(1)

それでは、サイボウズ社のkintoneを使って実際のアプリを作る手順を説明していきます。実際に手元にないとわかりづらいかもしれませんので、もし必要ならば無料のお試し版がありますので使ってみてはいかがでしょうか。ポータルを開き、アプリ作成のボタンを開くと次のような画面が出てきます。

アプリ.png


アプリを作るきっかけがいくつか用意されています。
1. アプリストアから選ぶ
 kintoneにはアプリストアというものがあります。そこにはすでに作られた様々なアプリが置かれていて、無料、有料で得ることができます。汎用的なもので、そのまま使えるようなものであればすぐに利用できます。
2. テンプレートから選ぶ
 基本的な構造ができていて、そこに追加修正を加えることで要求するアプリが作れるテンプレートを活用する手もあります。アプリストアにピッタリのものがないが、一から作るのも手間だという場合などに使います。
3. Excel/CSVから作成
 小規模のデータベースをExcelで作ってあるというのはよく見かけます。それを移行することができます。ただし、セルが結合されているといった複雑なものはできませんので、単純な縦横の表であれがすぐにマイグレーションすることができます。
4. はじめから作成
 新規に何もないところから設定していくやりかたです。以後はこのケースで説明していきます。
5. ほかのアプリを再利用
実際に使われているアプリをちょっとした手直しをして別のアプリにして使うやり方です。例えば、あるアプリがあるのだが、別の地域で使おうとすると機能を一部追加しなくてはいけないといったケースでは、似通った2つのアプリを作るといったことです。

さて、「はじめから作成」を選択すると下記のような画面になります。ここで、各種の設定をしながらアプリの作成を行なっていきます。プログラミングをするのではなくあくまで設定するという感覚です。個別にいく前に大きな流れを見ていくと次のようになります。

ステップ1 アプリの名前を入力
ステップ2 一般設定
ステップ3 フォームの設定
ステップ4 一覧の追加
これらが終わると、アプリの運用を開始するために「設定完了」をクリックします。

setteigamen.bmp


次回から各設定の詳細を説明します。


2013年7月 2日

ビジネスサービスのつくり方 - 第4章 開発

■ kintoneを使ったアプリ作成手順(2)

今回からは、個別設定についてみていきます。

ステップ1 アプリの名前を入力
最初に、下記のような画面が出てきますので「アプリ名」を入力します。適当な名前を入れてもかまいませんが、それがどんなアプリであるかがわかるようなものにしてください。個人的な趣味のようなものとか、逆に大雑把な感じのものは避けましょう。よく、〇〇管理システムというような付け方をしますが、あまり感心しませんね。例えば、「見積管理システム」よりも、「特注品見積提示プロセス」といったようにします。入力したら保存を押します。

apurikannri.bmp


ステップ2 一般設定
次が一般設定になります。アプリの用途に合ったアイコンやデザインテーマを選ぶことになります。アイコンは候補の中から選ぶこともできますし、好きな画像をアップロードすることもできます。デザインテーマというのは、画面表示のデザインのことで、クリップボードとかバインダーといったものがあります。あと、アプリグループを設定することで誰でも入れるのとグループ限定にすることもできます。アプリの説明が必要なら書いておきます。入力したら保存を押します。

ippannsetteisumi.bmp



ステップ3 フォームの設定

アプリ名とアイコンやデザインテーマなどが設定されるとメインのフォームの設定になります。データの入力フォームを作ることになります。フォームの設定画面は下記のようになります。左側にパーツ(フィールド)が置かれていて、右側の空白のキャンバスに必要なパーツをドラッグアンドドロップして配置されます。

フォームの設定.png


各パーツの説明は次回。


2013年7月10日

ビジネスサービスのつくり方 - 第4章 開発

■ kintoneを使ったアプリ作成手順(3)

前回は、フォームの設定というところまでいきました。設定画面には、左側にパーツが置かれ、右側のキャンバスにパーツをドラッグアンドドロップで配置すると画面ができてしまいす。ではまず、どんなパーツがあるのかを見ていきましょう。

フォームの設定.png

ラベル
フォームにテキストを追加するパーツです。フォームにタイトルを付けたり、入力項目に説明を付けたりできます。
文字列(1行)
1行のテキスト欄を追加するパーツです。このパーツで追加したテキスト欄では、テキストを改行できません。
リッチエディター
複数行のテキスト欄を追加するパーツです。
「文字列(複数行)」と異なり、フィールドに入力した文字の大きさや、色などを変更できます。
文字列(複数行)
複数行のテキスト欄を追加するパーツです。
数値
1行の数値入力欄を追加するパーツです。
計算
ほかのフィールドの値を参照して計算、または変換した値を自動入力するパーツです。
ラジオボタン
ラジオボタンのフィールドを追加するパーツです。一つだけ選択可能な選択肢項目に使用します。
チェックボックス
チェックボックスのフィールドを追加するパーツです。複数選択が可能な選択肢項目に使用します。
複数選択
複数選択が可能な選択肢のリストを追加するパーツです。
ドロップダウン
ドロップダウンリストのフィールドを追加するパーツです。一つだけ選択可能な選択肢項目に使用します。
日付
日付のフィールドを追加するパーツです。カレンダーから日付を選択できます。
時刻
時刻のフィールドを追加するパーツです
日時
日付と時刻を組み合わせたフィールドを追加するパーツです。
添付ファイル
ファイルを添付するフィールドを追加するパーツです。
リンク
Webサイトのアドレス、電話番号、またはメールアドレスを入力するフィールドを追加するパーツです。
フィールドに入力された値は、フィールドの設定に応じた種類のリンクになります。
ユーザー選択
kintoneの利用ユーザーから1人または複数人を選択するフィールドを追加するパーツです。
関連レコード一覧
ほかのアプリのデータをフォームに表示するパーツです。
ルックアップ
ルックアップ先として設定したアプリからデータをコピーするフィールドを追加するパーツです。
スペース
フォームにスペースを追加するパーツです。フィールドの表示位置の調整に使用します。
右端や下端をドラッグして、スペースのサイズを変更できます。
罫線
フォームに罫線を追加するパーツです。フィールド間の区切りに使用します。
右端をドラッグして、罫線のサイズを変更できます。
グループ
フィールドをグループ化して、グループ内のフィールドの表示/非表示を切り替えられるようにするパーツです。
フォームに配置するフィールドが多い場合に、フィールドをグループ化して、一度に表示するフィールドの数を減らせます。

だいぶ長々と説明してしまいましたが、これが多いか少ないかは、対象プロセスによりますし、どれだけ凝った画面が必要かによりますが、大方のものは工夫をしたり、ちょっとした裏技を使えばこれでできると思います。ただ、データ登録画面だからであって、オペレーション画面という捉え方をすると不十分さは否めません。これは、kintoneに限ったことではありません。業務システムのほとんどがデータ登録画面と一覧表と検索画面から成り立っていて、オペレーション用コンソール(ポータルとも違う)になっていません。これからの課題です。

パーツの中で特徴的なものに「グループ」というのがあります。これは今年の春のバージョンアップで追加されたもので、後で詳しく使い方は説明しますが、プロセスを構成するアクティビティをグループとして対応させることで表現力が格段に向上しました。折りたたみ機能もありますから、視認性もよくなって管理しやすくなりました。
  

2013年7月18日

ビジネスサービスのつくり方 - 第4章 開発

■ kintoneを使ったアプリ作成手順(4)

前回は、各パーツの説明をしました。フォームの設定では、これらのパーツをドラッグアンドドロップで配置していきます。例えば、案件名だと文字列(1行)を置いて設定で「案件名」というフィールド名にしておけばよいですし、いつ受付けたかを登録するのであれば日付のパーツを置き「受付日」という名前にしておきます。

また、選択するような場合には、一つしか選べないのか、複数でもいいのか、候補の中から選ぶようにするのかといったことを勘案して、ラジオボタン、チェックボックス、ドロップダウンを配置していきます。このあたりは、別の機会に実際にアプリを作りながら説明していきます。


setteigamen.bmp


フォームの設定が終わると、一覧の追加に行きます。Webデータベースは基本的には、データの登録画面と一覧画面から成っています。フォームの設定でデータ登録画面を生成すると、その登録されたデータを一覧形式でみれるように設計します。一覧画面を作るためには一覧の追加をクリックします。次のような画面が現れます。

一覧追加.png

まずは、一覧名を適当につけます。案件一覧とか、受注一覧とかいったものです。次に、レコード一覧の表示形式を表形式とカレンダー形式のどちらかを選択します。カレンダー形式というのは文字通りカレンダーが出てきて、その日付にデータを表示するもので、例えば、納期を表示できるようにするとかといった使い方になります。ただ、多くは表形式となりますのでそれで説明します。

この画面を開いた時点で、フォームの設定で配置されたフィールドが出てきますので、一覧表の横に並ぶ項目として設定します。これもドラッグアンドドロップで簡単に配置することができます。また、一覧表に表示するレコードの絞り込みもできますので、その条件を設定しておくと、ある特定のグルーピングで表示することもできます。

この表はいくつも作ることが可能ですので、見たい切り口に沿ってフィールドを選択することになります。プロセス中心のアプローチでは、マクロプロセスとして、進捗管理ができることが大事なので、この一覧表を利用することになります。案件の意思決定のステータスを時系列(プロセス順序)に並べておくと、どこまで進んだのかといった進捗管理が可能になります。
  

2013年7月30日

ビジネスサービスのつくり方 - 第4章 開発

■ kintoneを使ったアプリ作成手順(5)

さて、一般設定からフォーム設定そして一覧の追加の手順を示しましたが、最近、kintoneのバージョナップがあって、追加機能も含めてわかりやすく説明してくれていますので、そちらを参照してください。ここでは、プロセス設計で作成した「プロセス要素表」とkintoneのパーツのマッチングについてです。下表の対応表を見ていただければわかると思いますが、全くマッチングするというわけにはいきませんが、なんとか表現できます。

マッチング.png
いちいち説明するのは省くとして、特徴的なところを説明します。それは「グループ」というパーツの使い方です。前々回のパーツの説明ではグループを「フィールドをグループ化して、グループ内のフィールドの表示/非表示を切り替えられるようにするパーツ」ということでした。

このパーツのおかげで、マクロプロセスフローが表現できて、まさに意思決定の連鎖がわかりやすい形で実現できるようになりました。結局プロセス管理というのは案件単位でその案件がどういう経過を辿って終わらせたかを制御し管理するわけですから、それが一覧的に見えるのがうれしいですね。

しかしながら、問題があります。それは、オペレーションのコンソールとして適当かという問題です。ということでオペレーションのやり方をみていきましょう。基本はアクティビティを順番に処理して行くことになります。具体的には、フィールドグループにある入力フィールドにデータを登録して行くことです。データ入力は編集モードで行い、必要なデータ入力が終わると保存し、設定完了とします。これを繰り返して、全部の入力が終わるとそのプロセス(案件)は完了します。またプロセスの進捗は、進捗一覧表で監視、管理し、案件処理の結果は、グラフ等を参照して分析します。

お気づきかと思いますが、ちょっと違和感がありますよね。基本的には、一回で全部のデータを登録するようになっています。大方の業務アプリはこうなっています。実は、kintoneには「プロセス管理」という機能があって、そういう意味では一括入力というより、ワークフローになっていますが、データの登録ステータスを進めていく機能なのですが、意思決定系のプロセスだと行ったり来たりする柔軟性が必要となるので、あまり使えません。ただ、新バージョンではAPIが充実しましたのでこのあたりも工夫できるかもしれません。

まあ、機能を説明してもなかなかわからないと思いますので、ここで開発編を終わらせて、次回からは実際に業務アプリを作っていくという「アプリ作成」編に移ろうと思います。
  

2013年8月 5日

ビジネスサービスのつくり方 - 第5章 業務アプリ作成

■ はじめに

さて、今回からは新しい章が始まります。題して「業務アプリ作成」ということで、これまで、心構えと下準備・企画・設計・開発ときたので、実際のアプリを作ってみようという試みです。ライブコーディングというのがありますが、いわば誌上ライブインプリメンテーションといった趣でしょうか、紙の上で表現するのは難しいのですがやってみたいと思います。

まず始める前に前提条件や前置きを確認しておきます。
・ プロセス設計から入ります。
・ 対象プロセスは、筆者が経験したものや見聞きしたものが中心となります。
・ 詳細でスペシフィックな設計ではなく、基本的な部分についてになります。
・ インプリするプラットフォームはサイボウズ社の「kintone」になります。
・ 実際に動くものをつくって、その画面をキャプチャしたものをお見せします。

それと、少しおさらいをしながらどういう進め方になるかをお話しておきます。プロセス志向アプローチ(プロセスを中心に据え、アクティビティとそのフローを先行させて記述するアプローチ)であることは何度も申し上げています。プロセスというのは「ユーザからのサービス要求に対して、いくつかの意思決定を連鎖させて、満足のいくサービスを提供する過程」のことですから、どんな要求があって、それに対する答えをどう決めて、そろったところで何を報告するというのを決めることが先決になってきます。

そのあとに、要求に対する答えを用意する、すなわ単位意思決定を行うために必要な判断は誰がどんな情報にもとづいて行い、コントロールし管理しているのかなどを記述することになります。これを、「プロセス要素表」というワークシートに記入して、それをそのままに近い形で実装していきます。できるだけ早く動くものにしていくことが大事です。

こうしたプロトタイピング手法では、生煮えでもいいからまず作って見せることで改良点や新たな発見があるものです。これを反復することでよりいいものに仕上げていく(イテレーション)というやり方になります。そして、プロセス要素が全部完璧に揃うなんてことはあり得ないのだから、そこもあるものだけで使いだし、不足は人間が手作業で補うことで始めたらいいと思います。

「適用領域の適正化がものすごく大事なこと」という別のエントリーで書いていることなのですが、こうしたやり方が通用するプロセスが主体となった領域が対象となっています。というかプロセス志向アプローチはプロセスが重要であるからプロセス志向なのです。つまり、データを集約してそれを計算してレポートを作成するといった領域では、プロセスはあまり意味を持たない、あるいは機械的に手順化できるので対象にしていません。ここは、よく理解しておいてください。
  

2013年8月12日

ビジネスサービスのつくり方 - 第5章 業務アプリ作成

■ 標準品見積提示プロセス(設計)
最初に毎度おなじみの見積のプロセスを取り上げます。世の中には見積に関する業務アプリがたくさんあります。しかし、名前からどんな内容なのかわからないことが多いと思いませんか。単に見積書を作るアプリだったり、見積書の格納・検索アプリだったり、対象商品が標準品、在庫品、特注品、仕入販売品、はたまたサービスだったり様々です。

ですから、アプリ名は、そのあたりがわかるようなネーミングにします。今回は、システムキッチンを例にそのなかの標準品の見積依頼を受けて見積書を提示するまでのプロセスを対象としたアプリとします。ですから、お客さんから、ある商品の見積を依頼されるのが始点になります。そして、終点は見積書送付になります。「標準品見積提示プロセス」という名前になります。

つぎにこの始点と終点との間にどんなアクティビティがあるのかを見ていきます。書類を作って送るような例では、書類に書き込む必須データを確定するのがそれに当たります。ですから、言い方を変えると、まっさらの見積書からデータを転記していくのがプロセスとも言えるのです。見積書の記載事項は浮かびますよね。品名、型式、型番、サイズ、数量、単価、合計額、納期、納入条件といったものになります。品名や数量、納入条件などは見積依頼の時に指定されますから、結局、型式や型番などが特定された品名、数量×単価である売価、それと納期が中間のアクティビティとなります。そして作業としては見積書作成があります。

つまり、「見積依頼を受付ける→提供商品を選定する→納期を確定する→売価を決定する→見積書を作成する→見積書を送付する」というプロセスになります。さて、次にこれをベースに「プロセス要素表」を書いていくことになります。下記の空欄を埋める作業です。

プロセス要素表.png

始点の「見積依頼受付」アクティビティでは、お客さんからの依頼内容を確定します。ですから、確定データは依頼内容ということですが基本的には5Wが確定データになります。いつどこの誰から、どういう目的でどんな案件の依頼があっていつまでに答えるのかを記します。具体的には、依頼日、依頼会社、担当者名、案件名、依頼内容、提出期限となります。それにIDをふって置きますが、自動付番もできるのでまかせてもまかいません。

最低限このくらいのデータを配置しますが、このアクティビティはあくまでどんな依頼なのかをわかることが目的で、受付けるということが意思決定となります。従って、受付を承認するには、この会社との取引履歴を見たいとか、財務状況を知りたいといったことがあれば参照情報として登録してきます。また、受付承認の責任者は誰なのか、部長なのか課長なのか、担当者なのかを決めアクセス権を設定します。ここでは担当者の鈴木さんにしておきます。

次が商品選択になります。見積依頼は、商品名から型式やサイズなどを細かく指定してくる場合もありますが、要望に従ってこちらから選んであげるということもあると思います。そんなケースだと、タイプ、扉グループ、間口、数量といったものが確定データとなります。この決定にはカタログをみて決めるようなことがるかと思いますので、参照情報として商品カタログを設定します。(続きは次回)
 


2013年8月20日

ビジネスサービスのつくり方 - 第5章 業務アプリ作成

■ 標準品見積提示プロセス(設計続き)

次に納期の確定を行っていきます。確定すべきデータは納入日となります。その他付帯情報として、納入場所や納入条件、また提供商品を確保できているかどうかを設定します。ここでは、営業だけでは納入日を決めることはできませんから、工場だったり、出荷倉庫だったりから在庫情報ばどを入手して決めるか、決定する部門があったらそこから直接納期情報を取得します。関係部署とコミュニケーションをとることが重要となります。

商品選択と納期確定が終わると最も重要な見積価格の決定に入ります。この価格決定は各社あるいは各部門でやり方が異なるケースが多く見られます。極端な話、その場その場の営業の個人判断で決めているなんてこともあるかもしれません。ただし、こうしなくてはいけないということはありませんが、準拠するルールは何か、それが共有化されているのかどうかが大事なポイントです。

プロセスを先行させ、プロセスを中心にして設計するという利点というか意義はここのところで、つまりその意思決定はどんな業務ルールにのっとって誰が責任をもって決定しているのかということを書き出すことで明らかにするからです。いやー、うちにはルールはありませんというところがあるかもしれませんが、明文化されていなくて、誰かの頭のなかにあるかもしれませんが、大切なことはそれを表に出すことです。暗黙知から形式知にすることです。

最初はそんな立派なルールでなくてもかまいません。いくつもの案件をこなしていくうちに、こんな場合にどうしたらいいのかが書いてないので足しておきましょうとか、事業方針が変わったのでルールも改変しましょうとかすればいいのです。また、ガチガチのルールをむりやり作る必要はありません。プロセスオペレーションでは必ずといっていいほど裁量の余地が生じてきます。一部は人間の判断に任すようなものでもかまいません。

ここでも、納期確定と同様に原価だとか、仕切価格などの情報をもらってそこに営業経費や利益を載せて売価を決定していきます。さらに、値引きなどの扱いも入ってくるでしょう。そこの決定手順が残っていることも重要で、そうすることで後々のなぜ受注できたのかあるいは逆に成約にいたらなかったのといった解析ができるのです。

さて、見積書に記載する基本情報を決定すると見積書の作成を行います。作業のアクティビティです。ここでは、確定データは作成済というものでもいいですし、作成日という日付でもかまいません。見積書は通常は帳票として作成されますが、kintoneで直接見積書を作成するのは難しいのでデータを伝送してExcelなどの外部ツールで作成します。作成された帳票は参照できるように設定しておきます。最後のアクティビティは見積書の送付です。この場合の確定データは送付日と送付先になります。

以上、基本的なプロセス設計が終わると、「プロセス要素表」を埋めることで実装に向かっていきます。「標準品見積提示プロセス」のプロセス要素表は次のようになります。

見積プロセス要素表.png

2013年8月28日

ビジネスサービスのつくり方 - 第5章 業務アプリ作成

■ 標準品見積提示プロセス(実装その1)

前回「プロセス要素表」を書きましたが、それをそのまま実装していきます。実装はサイボウズ社の「kintone」を使います。最初に基本的な約束ごとと前提条件を言っておきます。「プロセス管理表」に記述した「標準品見積提示プロセス」を全部同じアプリに実装していきます。ただし、参照情報や業務ルールで使うデータベースなど別アプリにしておきます。例えば、顧客台帳だとか業務ルール集といったものは他のデータベースに持ちます。

こうしたデータベースは、連携のしやすさから「kintone」上にもつことをおすすめします。Excelだとか他のDBソフトなどで持っている場合ありますが、移行したほうが便利です。「プロセス要素表」の左端にあるアクテイビティはその単位でフィールドグループとしてまとめておきます。そのフィールドグループの中に、確定データや付帯情報、参照情報、業務ルールなどを設定していくことになります。

一覧表は、基本的にはプロセス全体の進捗がわかるものと案件ごとの内容がわかるものと2種類を用意するのがよいと思います。その結果をグラフ化してどう見るかといったところまでは含めません。また、組織/ユーザ登録やセキュリティの設定などは、cybozu.comの共通管理であらかじめ行ってあるという前提にしておきます。

それでは、「プロセス要素表」を横において、「kintone」ログイン画面からID、PWを入力して入ります。そしてポータル画面を開きます。アプリを作成するから"はじめから作成" というボタンを押します。アプリ名を「標準品見積提示プロセス」とします。一般設定は、アイコン、デザインテーマ、アプリグループ、アプリの説明がありますが、適当に選択し、記述します。

続いて、フォームの設定になります。左側にパーツが配置され、右側は白紙のキャンバスが現れます。最初のアクティビティは「見積依頼受付」です。従って、"グループ"というパーツをドラッグアンドドロップして先頭に置きます。歯車印をクリックして設定画面を開き、フィール名を「見積依頼受付」と入力して保存します。

このグループの中にプロセス要素表に書いた各要素を入れていきます。まずは確定データである依頼日、案件No、依頼会社名、案件名、依頼内容、担当営業名を当てはめます。依頼日は、"日付"、依頼会社名、案件名、担当営業名は"文字列"(1行)、依頼内容は長くなりますので"文字列(複数行)というパーツを選択します。案件Noについては、自動付番で構わなければ"レコード番号"というパーツにすると自動的に番号をふってくれます。

次いで付帯登録情報である依頼会社住所、提出期限についても同様に、"文字列"(1行)と"日付"パーツを使います。ただ、依頼会社住所については、既存顧客のような場合都度入力するのではなく、顧客リストとか顧客台帳といったところ(同じkintoenのアプリとして作成しておく)に情報を持っておけば、そこから取得できいちいち入力することがなくなります。それには、"ルックアップ"というパーツを使います。その設定画面で関連付けるアプリを顧客リストとして、コピー元のフィールドを会社名とします。次に顧客リストのフィールドと作成するフィールドの対応付けを行います。こうしておくと、案件登録時に会社名を入力して取得というボタンを押すと、郵便番号、住所、電話番号が自動的に入力されます。

そして、参照情報にある地図については、JavaScriptAPIを使って、Googleマップと連動させます。これはまた後で説明します。最後にこのアクティビティ(フィールドグループ)の登録のステータスを表示するフィールドを置きます。"ドロップダウン"パーツで、プロセス要素表で定義したステータス表示の受付中と受付完了を設定しておきます。なお、ステータス表示は各フィールドグループごとに配置してもよいのですが、折りたたんだ時に見えなくなるため一覧性が損なわれるので外出しすることにします。これもまた後で説明します。結局、「見積依頼受付」は次のようなフォームとなります。
  
依頼受付.JPG


2013年9月 3日

ビジネスサービスのつくり方 - 第5章 業務アプリ作成

■ 標準品見積提示プロセス(実装その2)

前回は「見積依頼受付」というアクティビティのフォーム設定を行いました。次は「プロセス要素表」の2番めにある「商品選択」というアクティビティになります。前と同じようにグループというパーツをドラッグアンドドロップして名前を「商品選択」と入力します。次にプロセス要素の中の確定データをみると、タイプ、扉グループ、間口、数量となっています。

タイプは、それほど数があるわけではなく決まったものが数種類なのでラジオボタンを選択します。フィールド名をタイプとし、項目と順番にAAとASという名前を登録します。扉グループは、比較的数が多いので、ラジオボタンだとずらっと並んで表示されるので、ドロップダウンを使うことにします。1Aだとか2Bだとかといった設定を行います。間口も同様な設定となります。数量は数値データですので数値というパーツにします。

次に、参照情報が商品カタログとなっています。商品カタログがどこにあるのかで設定も変わってくるのですが、ここではHP上にアップしてある商品カタログを参照して、お客さんの要求にあったタイプ、扉グループ、間口を選定するということにします。この場合、ラベルというパーツを使います。ラベルに書いた文章の言葉にリンクを貼ることにします。"商品カタログ参照"という中の商品カタログにリンクを設定し、参照先のURLを入力します。「商品選択」は次のようなフォームとなります。

商品選択.bmp

「商品選択」の次は「納期確定」になります。確定データは納入日ですから、日付というパーツを選択し、名前を納入日とします。付帯登録情報として、納入場所、納入条件、商品確保があります。納入場所と納入条件は文字列パーツを使い、商品確保は、依頼中なのか確保済みなのかの2通りなのでラジオボタンにします。納入場所も住所を入れると地図が表示されるようにしたかったら、依頼受付アクティビティと同様にGoogleマップと連動させることもできます。

参照情報の在庫状況は前の商品カタログと同様にラベルでリンクを貼っていますが、同じkintoneに用意してある在庫管理アプリをリンク先にしてあります。ですから、もしリンクではなく、「見積依頼受付」でやったようにルックアップを使って、商品が入力されたら、自動的に在庫数を表示させることもできます。結局、「納期確定」というアクティビティは次のようになります。
  
納期確定.bmp

2013年9月 9日

ビジネスサービスのつくり方 - 第5章 業務アプリ作成

■ 標準品見積提示プロセス(実装その3)

前回までは、「見積依頼受付」「商品選択」「納期確定」というアクティビティについてプロセス要素表か該当するパーツを選んで設定を行いました。次に残りのアクティビティの設定を行います。「価格設定」です。見積書に記載する売価で非常に重要なところですね。この決め方は、一義的に決まらないし、各社各様の決め方があると思います。

ひどい場合は、営業の胸三寸で決めるなんてこともあるかもしれませんが普通はルールというものがあるはずです。それは別に明文化されいなくても何らかの形で共有化されていればよいと思います。このケースでは、外部を参照するのではなくアプリのフィールドグループの中に直接記述してしまおうというものです。こんなルールにしておきました。

見積価格の決定は次のルールに従って決定してください。
1)価格構成は、仕切り価格+営業経費+利益とする。
2)営業経費は仕切価格の20%とする。最終的には営業部長判断とする。
3)利益は、仕切価格+営業経費の30%とする。

ですから見積金額は、仕切り価格を入力すると自動的に計算するというフォーマットにしています。では仕切り価格はどう決まるのかはここでは言及していませんが、製造原価から出すかもしれませんし、仕入れ価格かもしれませんが、外部アプリからの情報に依ります。データ連携で自動的に持ってきてもかまいません。

まず、ここで入力する仕切り価格は、数値というパーツを持ってきます。そして、このああと計算に使いますので、フィールドコードをわかりやすいように「仕切り価格」としておきます。(何もしないと数値_1といったように自動的にふられています)営業経費、利益、見積価格はそれぞれが計算されるものなので、計算というパーツを選択します。この場合の設定は、例えば営業経費であれば、フィールド名は「営業経費」となり、計算式のフィードには「仕切り価格*0.2」というふうに登録します。表示形式を選んでここでもフィールドコードを「営業経費」としておきます。価格決定のアクティビティは次のようになります。

価格決定.bmp

次は見積書作成アクティビティです。いわゆる作業のアクティビティで、前段の意思決定にに従って要求に対する報告を作成する作業になります。ここでは、見積書を作成するのに必要なデータが決定されたかどうかのチェックをするようにします。複数のチェックになりますのでチェックボタンのパーツを使います。また、作成された見積書がどんなものであるかがわかるように添付ボタンを付けて参照できるようにしておきます。見積書のような帳票はkintonで作るは無理なので、Excelや帳票ツールで作成したものを添付します。

最後は、見積書送付です。ここの確定データは送付日にしてあります。ステータスだけでもいいのですが、日付と送付先のほうが確実なのでそうしてあります。見積書作成と見積書送付のアクティビティは下記のようになります。

見積書作成.bmp

次に、各アクティビティのステータス表示をどうするかという問題があります。それぞれのフィールドグループの最後に置いても構わないのですが、折りたたんでしまうと見えなくなってしまうので、プロセスの進捗がわかるように全体の頭のところに横に並べることにしました。それぞれステータス表示で設定した名称を入れたドロップダウンパーツを並べておきます。以上で基本的なフォーム設定は終わります。

ステータス.bmp

2013年9月18日

ビジネスサービスのつくり方 - 第5章 業務アプリ作成

■ 標準品見積提示プロセス(実装その4)

さて、一般設定、フォームの設定ときたので次は一覧の追加になります。アプリを見るときに最初に出てくるのが一覧表ですので、玄関のところをどういうものにするかを考えます。やはり最初のところですから全体を見通せるものがよいと思います。つまり案件ごとの進捗がわかるものが必要です。また、プロセスというのは案件の処理だとも言えますから、その案件がどんな内容なのかも知りたいところです。

従って、基本的な一覧表としては、プロセス進捗と案件一覧を作ります。その他にも好きなように作れますが、条件ごとでソートできる絞り込みの機能がありますのでそれを使えば、切り口を変えて一覧表をみることができます。ですから、ここでは「進捗表」と「見積案件一覧」の2つを作成します。

一覧表は、フォームの設定で配置した各フィールドとその並び順を指定することを行います。一覧の追加をクリックすると、設定したフィールドが左側に自動的に置かれていますので、それをドラッグ&ドロップで配置します。順番としては案件Noと案件名をキーにして、各アクティビティのステータスを持ってきます。登録画面(閲覧画面)でも上段にステータスを表示させましたが同じことをここでもします。登録画面では案件ごとの進捗しか見れませんが、一覧表では複数の案件を同時にみることができます。進捗表は次のように設定されます。

進捗表.bmp

次は、見積案件一覧表になります。これも同じように左側に配置されたフィールドパーツをドラッグ&ドロップで置いていきます。ここでは、案件NO 、依頼日、案件名、納入日、担当営業名、見積金額としておきます。もちろん項目は自由に追加してかまいません。見積案件一覧表は次のようになります。

案件一覧.bmp

さて、基本的な設定が終わったので、その他の設定について見ていきましょう。まずはカテゴリーです。単純なプロセスだとカテゴリーに分けなくてもいいのですが、例えば、見積プロセスでも商品が単一ではなく種類が多くなったりすると商品カテゴリーで分けたくなりますよね。そのために、カテゴリーを設定することができます。

ここでは、住宅設備を対象にしていますので、キッチン、バスルーム、洗面所、トイレというふうにカテゴライスしました。また、キッチンにも標準のものと特注のものがあるとして、階層的に分けるようにします。下記のように設定しておきます。

カテゴリー.bmp

2013年9月25日

ビジネスサービスのつくり方 - 第5章 業務アプリ作成

■ 標準品見積提示プロセス(実装その5)

前回は、その他の設定でカテゴリーを取り上げました。つぎに通知の設定とアクセス権の設定を行っていきます。前提として、ここでは説明しませんが、cybozu.comで組織/ユーザーの設定が終わっているものとします。すなわち、kintoneの対象となっているアプリに参加する組織と人が登録されているという前提になります。

通知というのは、何かのアクションをきっかけに通知をするというもので、その条件としては、レコード追加、レコード編集、コメント書き込み、ステータスの更新、ファイル読み込みがあります。誰が何をした時誰に通知するかを設定することになります。通知はメールが飛んで行きますし、アプリのポータルでもわかります。下記のような設定になります。

通知.bmp

また、リマインダーという設定があります。これは、ある条件(通知のタイミング)になったらお知らせというかアラートを発するのですが、これが、実はパフォーマンス管理に使うことができます。つまりあるフィールド項目に条件を与えて、通知内容を設定するとそれを通知してくれます。ここでの例でいうと、見積提出期限の5日前になったら"見積作成急いでください!"という通知を担当者に送るわけです。

使い方としては期日管理が多いかもしれませんが、例えば、金額とか数量がある限度を超えたら注意をうながすということもできます。この機能を使ってパフォーマンス管理を行うようにします。リマンダーの設定は下記のようになります。

リマインダー.bmp


つぎは、アクセス権の設定になります。アクセス権がかけられるのは、「アプリ」「レコード」「フィールド」ごとにできます。それぞれの許可されるものが違っていて、アプリでは、レコード閲覧、レコード追加、レコード編集、レコード削除、アプリ管理、ファイル読み込み、ファイル書き出しで、レコードでは閲覧、編集、削除で、フィールドになると閲覧、編集となっています。このアクセス権によって担当者はだれなのか、責任者はだれなのかがわかるようになりますし、承認などのボタン(フィールド)は権限を持った役職者しか編集できないようにします。

さらに最近各種APIが提供されるようになってきました。その中で、「アプリのJavaScriptカスタマイズ」を行ってみましょう。その設定は、アプリの管理画面にある詳細設定を開きます。そこに「JavaScriptによるカスタマイズ」という項目がありますので、そこをクリックするとJavaScriptファイルをアップロードする画面になりますので、適用するファイルを参照ボタンから選択します。

JavaScriptファイルはもちろん自分で書くことができますが、下記のようなサンプルが用意されています。
• レコード一覧でステータスに応じて書式を設定する
• 住所から地図を表示する
• To Do をガントチャートで表示する
• 自動採番して、レコード登録する
• 経過年数を表示する
ここでは、最初の2つを実装してみます。サンプルコードの項目名を変更して適当な名前を付けておきます。「進捗一覧表」のアクティビティのステータスに応じて色が変わるようにします。そのアクティビティが完了すると文字が緑色になるように設定しました。また、住所からGoogleMapが表示できますので、例えば、依頼会社の住所とか納入先住所などを入力すると自動的にその地図が表示されるようにしました。

以上で、「標準品見積提示プロセス」の実装フェーズの説明は終わります。普通はこれで終わってしまうのですが、次回からはオペレーションについてエントリーしていきます。作っておわりではなく、使ってみてまた改善してというサイクルを回すのがゴールですので大事なところになります。

2013年10月 1日

ビジネスサービスのつくり方 - 第6章 業務適用

■ はじめに

さて、今回からは新しい章が始まります。題して「業務適用」ということで、前章で作っったアプリを使って業務を行っててみようという試みです。これも実際に動くものを見るのがいいのですが、紙の上での説明となります。従来のシステム開発では、業務アプリを作って終わりというケースが多いように思います。理由は作り手側と使い手側の乖離です。

使い手側いわゆるユーザーが、SIerとかの開発会社に頼んで業務システムを作ってもらうという図式で、作り手側はできたものを納品して終わりという関係である。従って、いざ使おうとするとうまく動かないという事態が発生する。システム的にバグだとか行ったものは改修してくれるのですが、業務オペレーション上で問題が生じるとそこは直してくれない。

というのも、仕様は最初の方に決められていて、その時って業務オペレーションがどうなるかのイメージが乏しいわけで、できて動かしてみて初めてこんなはずではなかったとなる。また、これもよくあるのだが、システム開発のプロジェクトにアサインされる担当ってキーパーソンでない場合が多い。仕様決めは彼らがやるわけだから、インフォーマルにやられているような部分は仕様から外れてしまうので、表層的な機能しか実装できないことになって使えないとなる。

だから、そうならないためにはシステム開発のプロジェクトでは、作り手と使い手の共同作業にしなくてはいけません。前章では実装編ということでインプリメンテーションをとりあえずやったという段階です。その段階でもユーザだけでやる場合は問題ないのですが、開発ベンダーが入っている場合でもユーザは必ず入ってむしろ主導権をとるようにして行います。

そして、業務適用という段階に入っていくわけですが、ちゃんと使えるように実装されたかというと難しいものがあります。動かさないと分からない、あるいは動かしてみてこんなはずではなかったと気がつくこともあります。ですから、まだプロトタイプと言ってもよいでしょう。ここから、プロトタイプを動かしながら実装に戻ることもしながらブラッシュアップしていきます。

このようなプロトタイピング手法が重要なメソッドになります。動かしてみて追加修正が出てきたらまた設計しなおして実装してという繰り返しを行います。ですから、そういったことができるプラットフォーム、ツールでなくてはいけません。いちいちコードを書きなおしたり、高いスキルでないとできないというのは不適です。Kintoneを採用しているのはIT専門家でないユーザ部門のひとでもできるからです。次回から、実際にオペレーションをしながら検証していきます。
  

2013年10月11日

ビジネスサービスのつくり方 - 第6章 業務適用

■ オペレーション(1)
前章で作成されたアプリは「標準品見積プロセス」という名前が付けられて「kintone」のポータルのアプリリストに入っています。まずは、なんらかの手段で営業の窓口のところに見積の依頼がきます。電話、FAX、メール、訪問といった手段で来ることが多いと思いますが、これからはWebサイトからとか、会員制みたいにして「kintone」のアプリに直接入って来れるようにすることも可能になるでしょう。

さて、依頼を受け付けた営業担当者は、ポータルのアプリをクリックします。そうすると「進捗表」の画面が出てきます。全く最初からだと"データがありません"と表示されるので新たにデータの登録をします。それ以後は、案件ごとの進捗が表示されることになります。ここでは、すでに2件が進行中であるとします。その画面は下のようになっています。

image01.bmp

進捗表は、アプリ作成で説明したように、各アクティビティのステータスを表示していますが、ここでJavaScriptAPIを使って色替えするようにしましたので、アクティビティが完了していると緑色に変わっています。色は好きなものでかまいませんが、こうして見やすい工夫は必要になっていきます。

新規のデータ登録画面に行くには、左上にある「+」ボタンをクリックします。そうすると、次のような画面が出てきます。

image02.bmp

最初のアクティビティである「見積依頼受付」のステータスが「受付中」(デフォルトでそうしている)になっている以外はまだデータは入っていません。また、グループフィールドに設定したところは、畳まれていて名称だけが表示されています。ここから順番にデータを入力していきます。カテゴリーは提供商品によって選択しますが、商品選択したあとで設定してもかまいません。とりあえず「キッチン>標準」を選択しておきます。

次に、ステータスはさておき、最初のアクティビティである「見積依頼受付」を拡げます。そうすると、下記画面が現れます。

image04.bmp

依頼日は、初期値を登録時の日付にしているためにその日付が表示されています。空欄にしたかったら、設定でチェックを外しておきます。案件Noは自動付番されるようにしていますのでそのままにします。次が依頼会社名の入力です。ここでも工夫は、ルックアップというパーツを使っていることで、会社名をいれて"取得"というボタンを押すと付属情報である、郵便番号、住所、電話番号が自動的に表示されます。これは、別の「顧客リスト」というアプリで登録されているデータを引っ張ってきています。

さらにここでもJavaScriptAPIで住所からGoogleの地図を表示させるようにしています。その他のデータも入力すると、最初のアクティビティが完了します。次のような画面になります。

image05.bmp

ここで一旦保存しておきます。また、ステータスのところを「受付完了」に進めておきます。そして、次の商品選択のアクティビティが開始されたら、2番めのアクティビティである「商品選択」のステータスを「選択中」にしておきます。このあたりは、自動ではなく人間が手で進めていくので面倒かもしれませんが、みんなで確認しながら進める意味もあるので手間を惜しまずやっていきましょう。

2013年10月21日

ビジネスサービスのつくり方 - 第6章 業務適用

■ オペレーション(2)
前回は、最初のアクティビティの「依頼受付」のオペレーションを行いました。このフィールドグループのデータを登録してステータスを完了にしました。一旦保存しておき、次のアクティビティである「商品選択」に行くわけですが、再びポータルから「標準品見積提示プロセス」を開きます。そうすると一覧表が出てきます。そこで該当する案件の左端をクリックすると案件のデータ登録された画面が出てきます。まだ、受付のところにデータが入っただけのものです。

ここから、追記していくというイメージになります。従って、編集モードに切り替えます。アクティビティは「商品選択」ですから、タイプ、扉グループ、間口から該当するものを選択し、数量を入力します。こうした作業をするときどの商品にするのかをカタログを見て選ぶケースがあるかもしれませんので、そのために商品カタログにリンクを張って参照できるようにしておきますが、開くときは"リンクを新しいウインドウで開く"で見に行った方がよいでしょう。ここでデータが確定するとステータスを確定済みに進めておき保存します。

image12.bmp

これで、プロセスは受付と商品選択が済んで、次は「納期確定」に行きます。これも同様にポータルからアプリを選んでそこから案件を開き、編集モードにします。納期確定では、納入日、納入場所、納入条件を入れますが、それを確定するには在庫の状況を確認して、例えば工場とか倉庫とかで納入品を確保しておく必要があるという想定で商品確保というラジオボタンをつけています。そこで確保済みになるとステータスを確定済みに進めます。

image13.bmp

次が価格決定で、価格は担当営業が勝手に決めるわけにはいかないのでルールに従って決めます。ルールは簡単で大事なものであると別のDBから参照するより直接書き込んでおくということも有効ですのでそうしてあります。そのルールで、見積金額は仕切り価格+営業経費+利益というふうにして、仕切り価格が決まると自動的に見積もり金額がきまるというシンプルな例でテーブル化しています。簡単な計算はkintoneでできます。ステータスは、価格決定にします。

image14.bmp

5番目は作業アクティビティです。「見積書作成」になります。ここでは、それまでに確定したデータを集約して見積書に記載することを行います。Kintoneは帳票作成は苦手ですから実際にはオフラインで行います。ただCSVで吐き出せますのでそこからExcelで見積書作成も可能です。作成された書類は、添付資料という形で収めておくと参照することができます。ステータスは作成済とします。

最後の報告・登録アクティビティは、「見積書送付」になります。ここでの入力は送付日と送付先にしてあります。そして、相手方が受領を確認したらステータスを受領確認にしてこの案件は完了します。あくまで簡単なモデルですので実際にはまだ多くの登録データや他システムとの連動などがあり、またグラフの設定をしていませんが、担当者別案件数だとか、月別の見積件数だとか見積金額総計だとか見たければそうした設定を行います。
 
image15.bmp

以上で業務適用を終わりますが、感じられたと思いますが、多少ぎごちないところがあるのは否めません。というのも残念ながら業務プロセスをオペレーションするのに適したソフトウエアは少なく高価です。その中にあってkintoneは比較的シンプルでかつ機能的にも優れているので何とか使えると思っています。何よりも協働的な業務オペレーションに向いているからです。

2013年11月 2日

ビジネスサービスのつくり方 - おわりに

さて、いちおう第1章の「心構えと下準備」から第6章の「業務適用」まで(本は第5章が「プロモーションと運用」なっていますが、業務アプリなので、「アプリ作成」と「業務適用」に分けました)を書いてきましたが、書いているうちに補足したほうがよいものが出てきましたのでそれを付記しておきます。

ここで取り上げた事例である「標準品見積提示プロセス」では、プロセスがすんなりと一本になっていますが、現実にそういうものばかりでしょうか。また、作業アクティビティが見積書作成といった簡単な作業だけなのだろうかという疑問を持たれたかもしれません。そう単純にはいかないようですね。そこで、ここから「ケース分割」と「タスク分解」という考え方を採り入れることにします。

まずはケース分割という考え方です。プロセスはアクティビティが順番に並んだものですが、全部が独立してあるとは限りません。前のアクティビティの結果に影響される、あるいは前の結果が決まらないと次のアクティビティの内容が定まらないといったことがあります。そうした場合にアクティビティの確定データが複数になたったときにケース分割ということをします。たとえば、営業プロモーションでキャンペーンの方法を選定するというアクティビティで展示会への出展とWebサイトを活用というのが選ばれたようなケースです。この2つの方法では、後のアクティビティが違ったものになります。

これは分岐ですねと言われそうですが、分岐とはちょっと違います。分岐はorが主ですがあくまでand回路だからです。そのとき同じプロセスで扱うと複雑になり混乱してしまいますから、ケースを分けてプロセス化したほうがよいと思います。まあ兄弟プロセスを作るというイメージですね。この検討は、プロセス要素表を書く前に、「業務コンテ作成」というステップを入れてそこでやることにします。コンテというのは、どんな依頼があって、確定すべきことや判断すべきことだけを並べて見ることで、その時複数になったら、別の名のプロセスにするということです。

次に、作業アクティビティをどう扱うかという問題です。何が問題かというと、作業を外側においてしまって(ブラックボックス化)いいのだろうかということです。簡単な作業、例えば書類を作成 するなんてはそれでいいかもしれませんが、この例のように複数の人間が多くの作業を協働するなんていう場合は、ちゃんと見えるようにしておいたほうがいいと思うからです。そこで「タスク分解」という考え方をとって、別にタスク管理アプリを作成(kintone で作成できます)して連携するのがよいでしょう。作業依頼をして作業結果を返してもらう感じです。

これもサブプロセスを作ればいいのではと言われそうですが、この場合はプロセス的な部分が薄いタスク管理なのでサブプロセスとは呼ばないようにしています。では、サブプロセスとはどういうものなんのでしょうか。メインプロセスがあってそこから従属的なプロセスへ落とし込むも親子関係になるわけですが、この方法論だとあまりないように思います。むしろ、サービス要求を別のプロセスへ投げることと考えられるので入れ子構造のプロセス間連携というふうに捉えています。

いずれにしろ、きっちりとしたフォームに嵌めこまなくてはいけないということではありません。意思決定の項目と順番を決め、各意思決定を素早く正しく行うために必要な要素を定義し、必要とあらば他プロセスやタスク管理、データベースなどと連携する仕組みと仕掛けができれば、組織目的を達成する業務オペレーションがやりやすくなるのではないでしょうか。(完)
  

About ビジネスサービスのつくり方

ブログ「mark-wada blog」のカテゴリ「ビジネスサービスのつくり方」に投稿されたすべてのエントリーのアーカイブのページです。新しい順番に並んでいます。

次のカテゴリはパラダイムシフトの正体です。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。

Powered by
Movable Type