Recently in 「Kintone」を使いたおす Category

3つのパラダイム変化の2番目の「作って終わりから使ってナンボへ」というのは、システム構築のゴールはどこかという話になります。つまり、作ることがゴールではなく、動かしてみて、もっと言えば成果を上げた時点がゴールですよと言っているのです。こんなことは至極当たり前だと思われるかもしれませんが、存外そうなっていない例を多くみかけます。

なぜそうなってしまったのかは、ユーザとITベンダーやSIerとの関係に見ることができます。ユーザはITのことがわからないからといってこんなものが作りたいと言っただけでITベンダーやSIerに丸投げします。特に一昔前の経営者は最初からITを遠ざけている人が多かった。また、ITベンダーやSIerはあいまいな要求仕様のままプログラム仕様書を書き、プログラマーに丸投げします。無責任連鎖です。

さて開発会社はそうやってできたシステムはこれだけ人月を要したのでそれに見合う費用を請求して受け取るわけです。だから、開発会社は極端な話その時点で仕事は終わります。ITベンダーもSIerも同様にユーザに対して言われたことをやりましたと言って、"プログラムが正常に動くこと"を確認して検収してもらうことになります。

これってどこかおかしいと思いませんか。ITベンダーやSIerにしても受託した開発会社にしても「作ってナンボ」と考えているわけです。そうした成果物を使いだしたユーザは使おうと思ったら使えないとか、使い出すとこう変えたいとかいったことが出てくるがもうどうしようもない。というわけで、半数以上のシステムが使うことなく眠ってしまっているのだ。

ユーザにとってのゴールは、当然のようにビジネス上の成果が出ることである。そのために大きな投資をしているのである。ではどうしたら、使って役に立ったというところまできちんと確認して終わりとなるシステム作りができるようになるのでしょうか。もちろん意識の持ち方もあるだろうし、契約の問題もあるでしょうが、大きいのは開発方法とか体制の問題だと思います。

つまり、ウオータフォールのようなフェーズドアプローチだとフェーズ間の受け渡しがうまくいかないとか、できあがりイメージがつかめない中でユーザが要求仕様を出していかなくてはいけないといった問題がどうしてもおきてくるから、そこから変えていく必要があります。

こうした問題を解決するには、いきつ戻りつでき、早い段階である程度動くものをみせていく反復型のやり方にするとともに、そこにユーザが参画してIT技術者と一体になって進めていくのが必須になってきます。こうすれば、ユーザーが真に欲しいものが具体的イメージとして出てきてそれをブラッシュアップしていくのでできた時は必ず使いものになるシステムになっているわけです。

こうしたやり方を前提として、使い手側も作り手側も意識を変革し、難しいかもしれませんが、契約形態も受託開発ではなく成功報酬に近いようなものにしていけばよいのではないでしょうか。そのくらいのことをしないとイノベーションを支援することはできないと思います。
  

4回にわたって実際の画面をみながら実装の方法を説明しましたがいかがでしたか。いたって簡単なサンプルにしましたので、情報量が少ないかもしれませんが、大体の感じはつかめたのではいでしょうか、今回は説明していませんでしたが、他にメール通知だとか、アクセス権の設定、レポートといった機能もあります。

何回も言っていますが、kintoneはあくまでWebデータベースですから、プロセス管理、プロセス表現は苦手です。ですから無理やり使っていることは否めません。例えば、BPMSやワークフローシステムだと、エンジンが自動的に進めてくれますが、それがありませんから、人間がステータスを登録するという泥臭いことをしています。

また、最大の問題はプロセスオペレーションという観点から見た場合、あくまでデータの登録、それも一度に入力するという考え方ですから、組織としてチームとしてコラボレイティブな意思決定を連鎖させていく場としては不十分です。しかしながら、コメント欄もあり、リンクによる情報取得もでき、進捗表も表現できたので、何とか実用に供せると思っていますし、既に実績もあります。徐々にバージョンアップもやってくれますので期待したいと思います。

さて、これでこのシリーズは終わります。お金をかけずに、そしてユーザ自身ができてしまうことを狙ったやり方を提示したわけですが、大事なことは、ITシステムを作ることではないということで、まずは自分たちの業務をオペレーションするためのプロセスを設計して、それを手持ちのITでやるとしたらどうなるかを見ることから始めたらどうでしょうか。

そこで、やりたいことができない、あるいは不十分なところはどこか、お金をかけて新たなITシステムを導入する方が得なのか、人間がやっておけばいいかもしれないといった検討を行うことをします。従前のやり方はITありきのようなところがあって、ITがこんなことができます、こういういい機能がありますと言っているからそれを使いましょう、どう使おうかという態度になっている気がします。

このシリーズのタイトルが「kintoneを使いたおす」となっているので誤解してほしくないのですが、「kintone」がこんなことができるからそれを使ってという発想ではありません。最初のエントリーでも書きましたが、本法はまだkintoneがなかったときに実際の行ったもので、「サイボウズデヂエ」というデータベースソフトを用いたものでした。このときもお金がないので新しいソフトを買うわけにもいかないときの工夫の結果として、すでに保有しているものを活用したのです。

つまり、プロセスありき、オペレーション優先のアプローチなのです。既成のソフトウエアやパッケージの機能優先ではありません。このオペレーションではITを使った方がいいから、それに適したソフトウエアを持ってくる、ただコスパが合わないなら手作業でいいといった感じです。コストダウンのために高価なソフトウエアを導入するというばかなことがないようにします。

残念ながら、めざす業務オペレーションをすべて実現してくれるソフトウエアはないので、どうしてもよく言えばベストオブブリード、悪く言えばつぎはぎでやらざるを得ない。これはSOAとかクラウドの出番になってくるわけです。そういう意味で「kintone」は業務プロセスの中核(中核とは何かは、mark-wada Blog書いていきます)に置くのは有効かと考えています。ぜひ、みなさんも使ってみて実感してみたらいかがでしょう。ただし、しつこいようですが、ちゃんと業務プロセスを設計し、オペレーションイメージを持ってからですでよ。おわり。




前回で設定が終わったのでデータの入っていないアプリケーションがkintoneの最初の場面に登録されて出てきます。

kintone4-1.JPG

標準品見積提示プロセスをクリックすると、まずは一覧表が表示されます。まだデータが入っていないので表示はありません。データが登録されてくると、ここの案件ごとの進捗がわかるようになります。

kintone4-2.JPG

ここでツールバーの一番左の「追加」をクリックするとデータの登録画面が出てきます。罫線で区切られたアクティビティが並んだものです。そこへデータを入力していきます。

kintone4-3.JPG

ここは、最初の二つのアクティビティである「見積依頼受付」と「商品選択」です。設定されたフィールにデータを入れていきます。商品はリンクを貼った商品カタログを見ながら選択していきます。

そして、各アクティビティのデータが確定したらステータスを進めて「完了」にし、一旦「保存」を押します。ステータス選択はつぎのアクティビティは仕掛かり中の表示にし、そこから下流は待機中にしておきます。データはまだ入っていない状態です。

次のアクティビティに行くのはツールバーの「編集」をクリックすることでデータの追記を行います。次の画面は「納期確定」「価格決定」の登録のところです。

kintone4-4.JPG

ここで画面の右側を見てください。コメントを書き込むという欄があります。ここで上司や関係者とコミュニケーションを取ることができます。見積価格を最終的にいくらにするのか、上司である営業部長と相談したりします。

データを入れるたびに保存を押していくと、一覧表にステータスが反映されてくるのでプロセスの進捗がわかるようになります。

kintone4-5.JPG

新しく案件が来たら、「追加」で案件を登録していきます。一覧表では絞込みやソートができますので、依頼者別とか担当者別に見るとかも可能です。

Wokspaceの設定が終わり「保存」を押すと次の画面が出てきて一覧表の作成に入ります。

kintone3-1.JPG

ここをクリックすると下のような画面が出てきます。

kintone3-2.JPG


一覧名を登録し(ここでは進捗管理表としておきます)、必要なフィールドを順番に選択しますが、進捗管理の場合は、各アクティビティで登録したステータスを選びます。この進捗管理の一覧表が基本のビューとなります。一覧表は複数作ることができますので、必要に応じて好きなフィールドを選んで作成してください。

kintone3-3.JPG

設定が終わったら「保存」を押すと下記画面になり、ここで右上の「設定完了」を押すとデータ登録画面と一覧表の設定が完了して、いよいよ業務運用(オペレーション)に進んでいきます。
 





前回は、最初アクティビティである「見積依頼受付」のフォーム設定を行いました。しかし、ひとつ忘れているものがあります。それはステータス登録です。プロセス進捗管理については後述しますが、プロセスがどのアクティビティまで進んでいるのかを知るためには、アクティビティ単位でいまどんな状態になっているのかを認識しないといけません。

プロセスエンジンがある場合にはそれは内蔵されていますが、kintoneはあくまでデータベースですからそんなものはありません。ですから、アクティビティごとにステータスを登録することになります。待機中、準備中、仕掛かり中、作成中、済み、完了といったステータス(好きな表現でかまいません)をラジオボタンで選択するようにします。

kintone2-01.JPG

次に、2番目のアクティビティである「商品選択」のフォーム設定を行います。商品はただ商品名だけではなく、その型番とか型式、仕様といったものと数量などが必要になる場合が多くあります。それらを設定しますが、セットでひとつの商品になるので、レコード群をテーブル化できますのでそうします。

また、商品を選択する場合に参照情報として商品カタログを定義しましたので、「ラベル」というパーツでそのリンク先を指定します。

kintone2-02.JPG

そのあと、「納期確定」「価格決定」へと進んでいきます。「価格決定」では、見積価格決定ルールに従って価格を決めていきますので、そのためのルールや仕切価格表などを参照できるようにします。この例のようにWorkSpaceにリッチエディターやラベルで直接書くこともできすし、リンク(Excel表などもWeb化しておきます)で見ることもできます。また、別にDBを作っておいてルックアップで持ってくることもできます。ルールなどは業務ルール集を作っておくとよいでしょう。

価格などの重要な決定は責任者の承認を得ておきます。フィールドごとにアクセス権が設定できますので承認権限者に割り当てます。

kintone2-03.JPG

最後に「見積書作成」と「見積書送付」のアクティビティを設定します。作業の登録データを何にするかがあると思いますが、ここでは記載事項と見積書そのものを添付するようにしてあります。

kintone2-04.JPG

これで、フォームの設定は終わりです。WorkSpaceのレイアウトができたことになります。
 
なお、これあくまで最低限の記述にしてあります。実際には関連する情報やデータを登録しておきたいとか様々な要求があると思います。さらに、お勧めはガイドラインやアドバイス、あるいは入力サンプルなどを書き込んでおくと非常に役にたちます。情報の"程度"を表現することもおもしろいですよ。例えばお客さんの要求の程度が強いのか普通なのか弱いのかといったことです。絵文字で表せたりするとうれしいのですが。

いずれにしろ、設計のところでも言いましたが、今やっている仕事のやり方、業務の流れをそのまま書くということが大事になってきます。書くことでオープンになり、共通化・標準化されていくのです。
  





前回設定された設計情報からkintoneに実装していきます。設計情報というのは、「プロセス概要表」に書かれたものです。

まずは、kintoneを開くと次の画面がでてきます。

kintone01.JPGのサムネール画像のサムネール画像

ここで右上の「アプリを作成する」をクリックすると下の画面が出てきますので、「新規にアプリを作成する」をクリックします。

kintone02.JPG

次の画面で、プロセス名を聞いてきますので「標準品見積提示プロセス」と入力します。

kintone03.JPG

次に一般設定を行います。ここでは、アイコンやデザインを選択することになります。

kintone05.JPG


それが設定されると次は「フォームの設定」となります。順番にナビゲーションしてくれますのでそれに従っていきます。次のようなフォームの設定画面が出てきます。

kintone08.JPG

フォームの設定画面には、フィールド項目を定義するパーツと呼ばれるものが左側に用意されていますので、それをドラッグ&ドロップで右のフィールドに貼り付けていきます。
基本的な構成としては、アクティビティの名前と確定データ項目、付帯情報を割り付けることになります。

サンプルに従って、最初のアクティビティを表現しみましょう。アクティビティ名は「見積依頼受付」ですからその名前を「ラベル」を使って書きます。プロセスの順番があるので番号を前につけ少し大きめの文字にするとよいでしょう。

次に、案件Noですが、「レコード番号」を使えば自動付番されます。案件名、依頼者は「文字列」で、依頼日は「日付」を選択します。それらを好きなようにレイアウトしていきます。そして、アクティビティの区切りとして「罫線」で仕切ります。

kintone09.JPG

とりあえず最初のアクティビティはこんな感じで設定することができます。

さて、これからは実際の設計と実装を行っていきますが、その前にキーポイントとなる業務プロセス設計ついてその作法をおさらいしてみましょう。おさらいというのはブログで何回か紹介していたので繰り返しになるからである。ただ、以前にエントリーしたものより、大幅に簡略化しています。超簡単に作ってしまおうと言っているのに多くの作法があるというのもおかしいわけで、たった3つの作法から成っています。

まずは、前提を確認しておきます。プロセス設計をするのに対象となるプロセスをどうやって特定するのかということがあります。最初から狙いが定まっている場合はよいのだが、そうでない場合、例えば戦略があってそれを実行するためのプロセスといった場合は、ひとつには、ビジネスモデルからプロセス分解していくやり方と参照モデルを使うやり方があります。ここでは、そうした絞り込みが済んでいるという前提にしておきます。

作法その1 「プロセスの始点と終点を決め、プロセス名を付けます」
・顧客接点のプロセスの場合は始点を先に、内部プロセスの場合は終点を先に決めます。
・始点は「依頼を受付ける」ところから始まります。通常「○○依頼受付」が最初のアクティビティとなります。5W1Hをベースに依頼内容を確定しておきます。
・終点は依頼に対して答えるためのアクティビティとなります。報告、提示、納入、情報提供、DB登録などが終点アクティビティとなります。
・プロセス名は終点のアクティビティ名をベースにした表現にします。ただし、○○管理プロセスのような表現は避け、業務活動を表す表現にします。 
・顧客の要求が不明確な場合は、要求の内容を聞き取り、要求内容を明確にし、要求形態を確定するプロセスを前に置いて、要求を依頼に変えてから「依頼受付」に行ってください。

作法その2 「中間となるアクティビティは単位意思決定と作業が主なものになります」
・単位意思決定とは①データを確定すること②判断を行うこと③文書などを完成させることです。
・単位意思決定では原則一つのデータ確定、判断、作成としますが、主データと付帯情報のような場合、意思決定するときの関係者や参照する情報がほぼ同じである場合、データ同士の相関性が強く同時に決めた方がよい場合は、複数のデータを同時に確定してもかまいません。                

作法その3 「コンテを書いてプロセス概要表にまとめる」
・コンテは、業務・仕事のあらすじを表現したもので、業務プロセスの構造で見てきたように要求(起)、依頼受付(承)、意思決定(転)、報告(結)で構成されています。
・映画の絵コンテと同じようにだいたいのストーリーとカット割がわかるものを作ります。紙と鉛筆かホワイトボードでアナログ的に書いた方がよいでしょう。
・プロセス概要表は各アクティビティで意思決定を行う(データ確定、判断、文書作成)ために使う業務ルールや参照情報、さらにロールやメトリクスを表に記入したものです。

たったこれだけで実装できます。え、うそでしょと言われそうですが、本当です。これならITを知らない人でもできますよね、というかむしろ業務側のユーザ自身しか設計できません。ITのところは汎用ソフト(この場合はkintone)にお任せして業務シナリオを書くことに専心しようということなのです。
   

前回、データベースソフトを使うが、データベースアプリケーションを作るわけではないとうこと、プロセスはマンガのようにストーリーがあるのでそれをそのままデータ登録画面に埋め込んだらどうだという話をした。今回は、kintoneを使って具体的にどう記述していくのかを見ていきます。

Kintoneもそうですが一般データベースソフトは基本的にデータ登録は1回で済ませるようになっています。入力するべきデータや情報を手元にもっていてそれを該当するフィールドに入力することをします。ですから、マンガではなくて絵とかイラストみたいなものと考えられます。ではそうした登録画面を使ってプロセスをどう表現したらよいのでしょうか。

簡単に言うと、マンガをそのまま書いてしまうことです。ただ、マンガと言っても4コママンガを章として連鎖させているようなものと理解して下さい。起承転結がはっきりしているものです。それを見やすいように章ごとに罫線を入れ、かつアクティビティの番号と名前を書きます。アクティビティというのは単位意思決定のことですから、その罫線で囲まれたところでどんな意思決定をするのかを明確にするわけです。

ですから、意思決定の数だけ章を配置します。罫線で囲まれたなかには前に書いたように確定データや判断などの登録フィールドとともに付帯情報や参照情報がすぐに見えるようにし、関係者とコミュンケーションができるようにしていきます。これだけで、データベースアプリケーションからプロセスアプリケーションへ変貌することになります。

BPMSならこんなことはすぐにできると思っている方も多いと思いますが、そうはうまくできてはいません。BPMSが登場したころにはもちろんできませんでした。プロセスエンジンでタスクの進捗を自動化するという意識が強かったので、そんな作りになっていました。ただ、最近では、プロセスを階層化できるようにもなり、掲示板のような機能も追加されてきてだいぶよくはなって来ていますが、まだまだコラボ―レーションによるデシジョンチェーンという概念とは違っています。

さて、こうして業務の物語を書いていくのですが、業務プロセスでは、最初はセリフや人物がまだ入ってはいないのです。背景や情況が描かれていて、そこに順番にセリフを入れていくイメージになります。「○○にしよう」とか「こっちがいい」あるいは会話が入ってくるわけです。さらに、物語がうまく進むように、またどう進んでいるのかがわかるような説明文を挿入することができるので誘導されて進行するのです。そのガイドは経験豊富なベテランの人に書いてもらえば、新人の人でもある程度はベテランの人に近い仕事ができるわけです。

Kintoneには「ラベル」とか「リッチエディター」といったパーツがありますので、そこに説明文やガイドを書き、外部の情報にリンクを貼るようにします。今のところ、Web化されたものでないとリンクされないので、普通のファイルを参照してというのができないので若干不便ではあります。例えばExcel表なんかならそれをWeb化して持つとかの工夫が要ります。

さて、kintoneで業務システムをどう実装したらいいのかの概要を説明しましたが、言葉での説明であることもあってイマイチ具体的なイメージがわかなかったかもしれないので、次回からは具体的なサンプル業務を使って、かつ実際にkintoneの画面を作りながら議論していこうと思います。
  

マクロプロセスの記述の話に入る前にしつこいようですが再確認です。標題にある「データベースソフトを使うのだがデータベースアプリケーションを作るのではない」ということを理解できないと意味がなくなりますので非常に大事なところですので繰り返して言っておきます。データベースアプリケーションというのは、基本はデータベースに格納するためのデータを登録するためのものです。

そして、記録されたデータを集計したり、計算、加工したりしてデータ保存状態にします。それは、レポートにしたり、分析したりするために扱いやすいように編集するわけです。そこから、必要なデータを検索して一覧で見えるようにしたり、帳票という形で出力するようになっています。

これはずっと昔から変わらない形です。古い汎用機の仕組みにしても現代のSalesforceの仕組みにしても、かたやグリーンディスプレーキャラクターが並んだものでもWebのかっこいい画面になっても基本的には同じです。画面設計をすると、登録・更新画面、検索画面、一覧表示画面、画面の承認などをすぐに考えますよね。

プロセス中心で業務システムを作ろうとするとき、こうした画面だけでプロセスを表現できるでしょうか。プロセスには、もちろん確定したデータを登録するあるいは判断結果を登録する機能は大事ですが、もっと重要なのはそうしたデータを確定するに至った過程、またどんな根拠で判断したのか、さらにそれらがどういった順番で行われたかがわかるようになっている必要があります。

すなわち、途中経過がシステム上で表現されなくてはいけません。これが業務オペレーションの場ということになります。オペレーションプラットフォーム上で様々なやりとり、そこには人と人というのもありますし、情報とのコンタクトというのもありますが、そうしたコラボレーション、コミュニケーションによって業務が完遂するわけです。

それを単に、データを登録し検索しレポ―ティングするだけではオペレーションプラットフォームとしては不十分であると言わざるをえません。ですから、従来型のデータベースソフトを使ってプロセスアプリケーションを作ろうとするとそれなりの工夫が要ることになります。

もちろんBPMSを使えばできますが、ここでは市販の安価な汎用データベースソフトを使おうというのですから知恵を絞らないといけません。最大の問題は、マクロプロセスの表現とどうオペレーションするのかということになります。ひとつには意思決定の連鎖を見渡すようにしなくてはいけません。また、例えば最初の意思決定をしたら次は何を決めなくてはいけないのかがわかるようになっているのかといった工夫である。

結局、少し飛躍した言い方になりますが、データ登録画面のなかにマンガを入れ込むことがポイントである。プロセスには起承転結があるし、マンガも起承転結で成り立っている。そのストーリーを全部埋め込んでしまえというのがここでの提案である。次回に具体的なやり方を見て行きます。
  

前回は「プロセス進捗ビュー」を一覧表の機能で、そこのフィールドにステータスを表示させることで実現させました。今回は、意思決定の場をどうするかになります。また何度も出てくる話ですが、意思決定を行うプロセスは、情報活動―設計活動―選択活動というサイモンの意思決定プロセスが基本です。

すなわち、意思決定するのに必要情報を収集し、いくつかの案を考え、評価し、その中から現実解を選択します。あくまで"現実解"であり、"最適解"ではありません。サイモンも人間の合理性に限界(限定合理性)があるので一定の評価基準に照らして最も有利な選択を行うという最適化原理に基づく(できるだけ最適に近づける)意思決定にならざるを得ないと言っています。

ついでにサイモンの限定合理性の話をすると、人間はこの限定合理性ゆえに大きな問題に一挙に対処することはできず、複雑な問題の解決にあたる場合、問題を分解して組織の目的の階層化を行うといっています。その組織目的の階層化に併せて組織の意思決定も階層化して、人間の合理性の限界を克服しつつ、組織目的の合理的達成を追求するわけです。

つまり、トップマネジメントの意思決定のレベルとミドルマネジメント、現場担当者の意思決定のレベルは当然違っていて、プロセス的に言うと抽象度の高いハイレベルなプロセスの意思決定はトップがやるし、現場のタスクレベルの単位意思決定は担当者がやるというふうになります。

よく日本の企業は、トップが細かいことまで口を出すとか、現場が強すぎて本来部長がやるべきことを係長がやっているとか揶揄されることがある。これは、組織目的と意思決定の階層化がちゃんとできていないことに起因しているのだが、もっと言うと業務プロセスの階層化ができていないことに帰結する。

ちょっと話がそれてしまったが、意思決定プロセスは現実的には一回で終わることは少なくいくつかの意思決定が連鎖しているのが実際です。つまり、大きな意思決定の流れ(マクロプロセス)とそのなかのアクティビティのひとつずつが小さな意思決定プロセス(ミクロプロセス)となっているわけです。前回はマクロプロセスを一覧表で閲覧する話をしました。

ここでは、ミクロプロセスである単位意思決定をkintoneのデータ登録フォームで行うことを見ていきます。意思決定する場とは、何回も言っていますが、業務ルールや参考となる情報を参照でき、承認者も含めた関係者のコミュニケーションを通してパフォーマンスを守ったオペレーションができることが重要です。先述したように最適解に近づけるために、どれだけ適正なルールや有用な情報を参照できるか、どれだけ有効な知恵を獲得できるかが大事なのです。

意思決定した結果はデータ登録という形でそのフィールドが作られます。登録されるのは、数値データだけとは限りません。判断結果と作成文書などもそれに該当します。可否、要否、有無などの結果はラジオボタンが使われることが多く、作成文書はラベルに張り付けたりリンクといった方法や参照設定で登録されます。

また、業務ルールや参考とする情報の参照はkintoneではラベルかリッチエディターのリンクで引っ張ってくるか、もし同じkintoneのライブラリーにあるものであれば、ルックアップされます。コミュニケーションについては、kintoneでは、登録フォームの右横にコメントを書き込む欄があるのでそこで関係者間の意見交換を行うことができます。とういうことで何とか意思決定の場で必要な機能は装備できます。詳しい設定の仕方などは、設計・実装方法で説明します。さて次回は、マクロプロセスの記述をどうするかを議論します。