update it, Inc.社長のブログ

最近なかなか手を付けられないでいるのですが、私はSwingUnitという、JavaのGUIアプリケーションのテストツールを個人的に作っています。（今のところ会社としての仕事ではありません）　JavaにはSwingというGUI構築用のライブラリーがあり、Swingを使って組み立てられたアプリケーションを自動的にシナリオに沿って動作させる仕組みで、JUnitなどと組み合わせるとリグレッション・テストなどを自動化することが可能です。

SwingUnitの開発を始めたのは2004年の秋ごろです。その当時、オープンソースの開発や、さらにそれを使ったビジネスモデルの話を聞くたびに、面白そうと思い始め、じゃあ自分でもやってみようかと考えてはじめた次第です。ただ最初から公開する自信はなかったので、約半年間は手元で開発し、2005年の5月、ある程度そろったと判断してjava.netで公開に踏み切りました。

ちなみにこのSwingUnitで2005年のJavaOne nightに出場させていただいたので、そのときにお会いした方もいるかもしれませんね。

あまり偉そうなことは言えないのですが、実際やってみて感じたことは、正直なところボランティアベースではなかなか十分な時間を確保するのが難しいな、ということでした。作るのは本当に楽しいのですが、仕事をやりながらということになると、実際にSwingUnitのために割ける時間というと休日ぐらいになってしまいます。その休日は家族サービスもしなければなりません。会社を立ち上げてからはその休日の時間も全くとれなくなってしまいました。（一応バグFIXはやっていますが）

格言に「Time is money（時は金なり）」というのがありますが、それを実感する今日この頃です。

もうそろそろ、終わりですね。

花見がしたかったです。

プロジェクトを確実に破綻させる方法の第4弾は、「聞いていない」です。これ、プロジェクトの中ではよく起こりませんか？

聞き手が聞き漏らしていた場合もありますし、本当に聞かされていなかった、ということもあるでしょう。でもどちらにしろ、プロジェクトの中で、「聞いていない」ことが自分の知らないところでいつの間にか決まっていた、ということがたびたび起こった場合、相互に不信感が募ることになります。

「聞いていない」ことによる問題は、それによって何か大きな抜けが発生するといった直接的な面もありますが、それ以上に心理的にネガティブになってしまう問題のほうが大きいでしょう。自分が蚊帳の外に置かれたと一旦感じてしまうと、その人の積極性が失われてしまい、Aクラスのスタープレーヤーだった人がとたんにCクラスの他の人の足を引っ張る人になってしまったりします。

プロジェクトマネージャーやサブリーダーの人は、自分が担当するメンバーに対し、直接関係がないと思った情報でもなんらかの形で伝達するように努めるべきだと思います。プロジェクトマネージャやサブリーダーが知っていることと、プロジェクトメンバーの知っていることには何が特別な理由がない限り、差をつけるべきではありません。何が伝えられないことがある場合には、どういったことは伝達できて、逆にどういったことは伝達できないのかを予め明確に示しておくことも重要です。そうやってみんなに全部さらけ出しているんだよ、とプロジェクトメンバーにアピールすることで、各メンバー一人ひとりのプロジェクトへの帰属意識を高めることができるのではないでしょうか？

入学式の季節ですね。今年はちょうど桜が満開でいい感じです。

ちなみに以前、もう葉桜になってしまったと紹介したのがありましたが、あれば別の種類なのでしょうか？

4月2日のブログプロジェクトを確実に破綻させる方法　その３として「曖昧プロセス」について書きましたが、では逆にうまく回すにはどうすべきなのか？　について述べます。

私はそのためにはプロセスの定義をできるだけシンプルにすべきと考えています。理由は簡単。人間そんなに複雑なものには対処できません。完璧な定義よりも、プロジェクトにかかわるチームメンバー全員が、きちっとを守り続けられることのほうが重要なのです。特定の人しか理解していないような複雑なプロセスは、結局オペレーションできません。一貫性をもって、同じ呪文を繰り返すことが品質を向上させるには重要なのです。定義の完璧さが重要なのではなく、きちっとオペレーションすることが大切だから、できるだけシンプルであるべきだと考えているのです。

ここででてくるのが、ブログ私の履歴書で書いたセブン・イレブン流の話です。私がセブン・イレブンの話を聞いたときに一番感銘を受けたのが、パートやアルバイトまで巻き込んで全社的に一貫して「仮説・検証」していてるという点でした。

シンプルだけと、一貫性のある、強力な呪文をみんなで唱えると強くなれるって、まるで何かのゲームみたいですが、if文の嵐のような大量のプロセス定義よりもよっぽど実効性があるのではないでしょうか？

昨日のシステム開発会社は製造業？サービス業？の続きです。もうひとつの製造業とサービス業の違いとして、相手に提供する成果が一過性のものか、継続的に提供するものか、ということがあります。製造業では製造物（成果物）を買ってもらいます。基本的には買ってもらえばおしまいです。一方のサービス業では、継続的にサービスを提供することが重要です。

少し前からオープンソースの製品を無償で提供しつつ、そのサポートを生業とする企業が出てきていますが、彼らはまさにサービス業といえます。サポートというのは「相手方の時間および手間を肩代わりする」行為であり、継続的に行うことが可能です。製品そのものを売るのではなく、サポート、つまりサービスを商売にしているわけです。

もちろん彼らも裏では一生懸命、製品のバージョンアップをしているわけですが、製造したものを売ってはいるわけではないのです。

このサポートサービスというのはライセンスによる商売の一種とも考えることができます。しかし単なるライセンス商売とは違い、顧客を継続的にサポートし続けること、そしてライセンスの代金は製品そのものに対する代金ではなく、それをサポートすることに対する代金であること、などが特徴となります。

なお、ここでいうサポートって保守のことだと決め付けないでください。実は非常に広範囲のことが、サービスとして提供可能なのです。また製品がオープンソースでなければならない、ということもないと思います。要は製造物を売る商売ではなく、継続的なサービスを提供する商売になっていれば良いのです。

こうしたサービスは、高い技術力やオペレーション能力がないと実現できません。単なる人出しの商売とはまったく異なる業種になります。これこそが今後システム開発会社の進む道だと私は考えます。

会社の目の前を流れる「滝」です。ジャングルクルーズではありません。

昨日の「私の履歴書」の中で、「私の持論は、システム開発会社は製造業ではなく、サービス業であるべきだと考えています」と述べました。今日はこの意図するところを述べたいと思います。

普通に考えればシステム開発会社は製造業っぽいと思います。ちなみにウィキペディアによれば、製造業とは「原材料などを加工することによって製品を生産・提供する産業で、鉱業・建設業とともに第二次産業を構成する一大分野である」だそうです。大規模なシステム開発を行うSI会社の人達が少し自嘲気味に、「うちの仕事はゼネコンと同じだ」というのを聞くことがありますが、もしやっていることが建設業と似ているとすると、それはやはり製造業なのかもしれません。

一方のサービス業とは、同じくウィキペディアによると「サービスを取り扱う産業」で、そのサービスとは「取引の対象となりうる無形の商品のこと。役務(えきむ)。相手方の時間および手間を肩代わりする概念」となっています。また第三次産業と同義と捉える場合もあり、その定義によると情報通信業などの情報や知識を取り扱う産業もサービス業として扱われています。

ただ私が「システム開発会社は製造業ではなく、サービス業であるべき」という言い方をしているのは厳密な定義の話をしているのではなく、どうあるべきか、というか目指すべき方向性の話をしたいのです。ですので、ここから先は製造業のイメージとサービス業のイメージの対比として話を聞いてください。（ちょっと説得力がないですね。）

まず最初に言いたいのは顧客との距離です。サービス業といった場合、一般に思い浮かべるイメージとして、目の前に、もしくは関係の近い場所に顧客がいると思います。一方の製造業は製品を出荷するまでで、そこから先の顧客まではかなり距離があるのではないでしょうか？　以前のブログ「メニューと値段」で書いた「プレミアム」を得たいならば、この顧客との距離の関係で捉えた場合、製造業よりはサービス業を目指すべきではないか、ということが１つ言えます。

もうひとつは、サービスの定義にある「相手方の時間および手間を肩代わりする概念」というのが、まさにシステムが実現しようとしていることで、システム開発会社は、装置としてのシステムを１から作り上げて提供するという商売から、徐々にシステムによるサービスを提供する商売に移行すべきなのではないか、ということです。

奇しくもSOA（サービス指向アーキテクチャ）という言葉があります。この言葉の本来目指すべきところは、まさにこの「システムによるサービスを提供」するということに尽きるのではないのでしょうか？

なぜ毎回０からシステムを作り上げなければならないのか。それを不思議に思うことから、私は「システム開発会社は製造業ではなく、サービス業であるべき」と考えている、という次第です。

会社ではシエスタを推奨しています。

眠いときにはちょっと寝て、しゃきっと集中して仕事をしたほうが全体の効率はよっぽど高くなるはずだ、と思っております。（はてはの近藤社長の真似でもありますけどね。）

今月の日本経済新聞朝刊の「私の履歴書」はセブン＆アイ・ホールディングス会長の鈴木敏文さんです。私は日経新聞をこの「私の履歴書」を読むために取っているといってもいい程、毎朝この欄を楽しみにしているのですが、今月の鈴木敏文さんの「履歴書」は待ってました！と言いたくなる程うれしい企画です。少なくとも私はコピーをとって永久保存版にします。

最近「見える化」流行りでシステム開発にトヨタ流を導入するという話を良く聞きますが、私はシステム開発会社が見習うべきなのはむしろセブン・イレブンではないかと考えています。もちろんトヨタ流を否定するわけではありません。システム開発を製造業だと捉えるとトヨタ流に学ぶべき点が多いのは事実です。一方セブン・イレブンはコンシューマ向けのサービス業なので、B to Bの形態の多いシステム開発会社の人にセブン・イレブンといっても？という反応をされてしまうのが落ちです。しかし私の持論は、システム開発会社は製造業ではなく、サービス業であるべきだと考えています。もしそうだとすれば、サービス業の１つの頂点の形態として、セブン・イレブンに学ぶべき点は非常に多いのではないでしょうか？

セブン・イレブンの収益性は他のコンビニエンスストアと比較して群を抜いています。同じようなことをしているのに、また同じような人たちがやっているのに、なぜセブン・イレブンだけがこんなに強いのか。その強さのわけは最初に紹介した鈴木敏文さん流のセブン・イレブンの文化にあるといえます。

勝見 明著の本『鈴木敏文の「本当のようなウソを見抜く」』（プレジデント社）では、このセブン・イレブンの文化として、例えばパートやアルバイトまで巻き込んだ、シンプルなプロセス「仮説・検証」を一貫して実践している、とか、顧客の立場に立ってものを考える（顧客の心理を読む）とか、常識を鵜呑みにしないなどといったことが紹介されています。これと連動する形で徹底した単品管理、商品の売れ行き予測、徹底したフランチャイズの教育などが行われています。こういったことをまとめて統計学と心理学をベースにした経営と紹介されるようです。

単純にシステム開発の立場で見てみるとぜんぜん別世界の話のように思えるかもしれませんが、顧客のニーズ、心理を捉え、如何に顧客ロイヤリティーを得るか、また仮説・検証などといった文化を如何に末端まで浸透させるかという観点で考えた場合、重要な示唆がたくさん含まれていると思えるのです。

具体的な内容についてはまた後日ということで。