December 2012 Archives

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

ITをサービスという観点で眺めていくと、サービスとは人間がITを使って生み出されるものであり、またITと人の合わせ技でビジネスサービスを使うというアプローチになるのです。ですから、ケースバイケースでITに任せる部分、人が関与する部分の割合が変わるのは当然で、道具との相性も含めて本来の目的を忘れずに柔軟に対応できるようにするのが大事になるのです。
 
■モックアップツール
業務システムのエリアでは設計というとおおかたは紙に書いたもの、つまり設計書という形式に落とすことがやられてきました。ドキュメントをちゃんと残しましょうという掛け声で一生懸命書いたものです。ところが、がんばって残した割にはあまり役立っていないと思っている人もけっこういるのではないでしょうか。

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

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

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

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

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

kintoneでフォーム設計した例を下に示します。
 
モックmitumori.JPG


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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