update it, Inc.社長のブログ

昨日の「お客様の業務を理解することの重要性」において、お客様の業務を理解しないとパッケージやASPサービスはできないよ、ということを書きました。（当たり前の話ですね）　じゃあどうやったら業務を理解してそれをパッケージやASPサービスとして実現することが出来るようになるのでしょうか？

いくつか案を考えて見ましょう。

１．自社でその商売をやってみる。
２．その商売をやってきた人を採用する。
３．お客さんのところに社員を研修に出して商売を覚えてきてもらう。
４．以前その商売をやって来た人たちでシステム会社を起業する。

最初の案はなかなか実行するのが難しいかもしれません。ある意味業種転換するわけですから。またいきなり新参者として新しい商売を始めてもうまくいかない可能性も高いですし、逆にうまくいったのならその先システムを作る仕事はやめたほうがいいかもしれません。

２の案は（金さえあれば）実行は比較的簡単です。ただし気をつけなければならないのは、そうやって採用した人は通常、システム的なセンスがあるわけではないので、その人自身に設計をさせることは難しい場合が多いということです。なので、「その人」の使い方が難しいのですが、でももし対象業務をシステム化したいという高い志をもった人を採用することができれば、これはかなりうまくいく方法だと思います。

３の案も可能であればお勧めの方法です。システム的な設計のセンスをもった人を期限付きでお客様のところに送り出し、お客様と同じ仕事をして覚えてきてもらえれば、その人は業務ノウハウを理解すると同時にシステム設計のヒントを一杯抱えて戻ってきてくれることになります。非常に良い方法なのですが、問題はこのような提案に乗ってくださるお客様がいるか、ということと、実施に時間がかかること、そして場合によっては送り出した人がその業務に目覚めて帰ってこなくなるリスクがあるということです。

４がもっとも理想ですね。実際こういった形で起業するベンチャーも多いと思います。敢えて問題があるとすれば、その人たち自身はシステムについて十分知っているわけではない場合が多い、ということだと思います。でもその場合にはシステムに詳しい人を仲間として採用すればよいのです。またこういうケースの場合には、最初はシステムに素人でも本人達が問題意識を持って取り組むので、自然にシステム的なセンスを身につける場合が多いということもいえます。

日本でも４のようなケースがもっと増えるといいと思います。

昨日はなぜ受託開発がこんなにも多いのか？というタイトルで書きましたが、今日はその「なぜ」の部分に踏み込んでみたいと思います。ということで、タイトルは「お客様の業務を理解することの重要性」です。

なぜ受託開発がこんなにも多いのか、それは、大半のシステム開発会社はお客様の業務を知らないことに原因があるのではないでしょうか？　業務を知らないからパッケージ化できない、もしくはアプリケーションフレームワーク化したくても、どの部分をどうまとめればよいのかがわからない。そういうことだと私は考えます。

最近オブジェクト指向ばやりで、システム分析にもオブジェクト指向分析を導入するケースが増えています。これは正しいことなのですが、なぜこれが必要かというと、作る側がお客様の業務を理解していないために必要なのです。もし、お客様がやっていることを全部理解していれば、いちいちこんな回り道をしなくてもシステムは作れてしまうのです。（しかもこの場合でもシステムの作りとしてはオブジェクト指向的に「作る」ことはできるんです）

もちろん、作る側のチームにはお客様の業務に精通していない、ジュニアなメンバーがいる場合もあり、そういうメンバー向けには必要だと思いますが、例えばすべての設計者が対象業務に対して十分な知識を持っている場合には本来省いても問題のないことだといえます。

パッケージやASPなどのサービスをしている会社は、自社でそのようなお客様の業務に関するノウハウを持っています。だからシステムとして実現できているのですが、「なんでもやります」的な受託をベースにしている会社の場合、その会社にはお客様の業務を理解している人はいません。だからどう転んでも、この状態では受託開発しかできないんです。

もしシステム開発会社がパッケージやASPなどをサービスする会社に変身したいのであれば、まずはお客様の業務を徹底的に理解しなければなりません。ではどうやったらお客様の業務を徹底的に理解できるようになるのか、それはまた次の機会に書きたいと思います。

この間、あるベンチャー系の展示会の案内を見つけて、その出展企業のリストからITおよび情報通信系の会社をピックアップして見ていたのですが、ひとつ感じたことがあります。それは、受託開発（もしくは人材派遣）を基本としているところがあまりにも多い、ということです。前から感じていたことではあるのですが、調べてみてあらためて強く感じた次第です。

受託開発が悪いというつもりはないのですが、私には受託開発は受身の商売のように思えます。基本的なスタンスはお客様の希望するとおりのシステムを作ることなのですが、もしそのお客様の商売が良くわかっているのであればその商売をサポートする仕組みをパッケージやASP、SaaSなどといった形態で提供することができるはずです。また完全なパッケージ化が難しい場合でも、業務ノウハウ部分をアプリケーション・フレームワーク化して様々なオーダーメイド的な要求にも耐えうる、セミ・パッケージ化はできると思います。

特定の商売をサポートするパッケージやフレームワークを持つほうが会社としてのプレゼンスや利益率が大きく改善すると思うのですが、いろいろなITおよび情報通信系の会社案内を見てみた感想は、受託開発を基本に「なんでもやります」的な会社があまりにも多いな、ということでした。

ここ数年は景気回復の恩恵を受けてどの会社もそれなりに仕事が受注しやすい環境といえます。でもこの状態がいつまでも続くとは限りません。そうしたときに、この「なんでもやります」的な会社が競争に打ち勝つには価格で競争せざるを得なくなると思うのです。

今後は今以上に中国、インドなどのIT系企業との競争も激しくなるでしょうし、そうなると国内で受託開発を基本にしている会社の場合、価格以外の面で競争できる柱がないと太刀打ちできなくなると考えらないでしょうか？　そして、その価格以外の面での柱とは、特定の商売をサポートするパッケージやフレームワークを持ち、それでブランドを確立することだと私は考えます。

update it, Inc.の設立日は2006年9月1日です。今月で設立１周年を迎えました。

普通の会社の場合、１周年目にはそれなりに会社が回っているのだと思いますが、update it, Inc.の場合、この１年間はずーっと研究開発のみの日々でした。１周年といいつつ、これからが始まりです。

crossnoteの開発は最終段階に入り、営業開始に向けた準備作業を進めているところです。サービス・インは１１月頭を予定しており、９月の末頃から徐々にデモをお披露目していきたいと考えています。このブログを見ていただいている皆さんには、ぜひ一番最初にお披露目したいと思います。

最初は小さな一歩に過ぎないかもしれませんが、ゆくゆくは日本、そして世界を代表するシステム・サービスとなれるよう、精一杯がんばりたいと思います。

これからも、どうぞよろしくお願いいたします。

私がいつも髪を切ってもらっているヘアサロンは、いつも客でいっぱいです。実は私が住んでいるところはヘアサロンの激戦区で、同一商圏内に数多くのヘアサロンがひしめき合っています。私が通っているヘアサロンの前後５０ｍ以内にも、少なくとも３件のヘアサロンが軒を連ねています。商圏内の人口はそんなに多いわけではないので、すべての店舗について商売が成り立つにはかなり厳しい状況になっていると思うのですが、一方で、それにも関わらず次々と新しいヘアサロンが新規参入している状況です。私が通っているヘアサロンはその中ではもうだいぶ古株で、できてから１０年以上たっているらしいのですが、移ろいやすい（と勝手に思う）女性客から長年多くの支持を受けているらしく、いつも夜遅くまでお客さんが絶えません。ちなみに男性客も多いです。

そこの社長さんがなかなか面白い方で、髪を切ってもらっている間、いろいろと話をしていただいています。で、その社長さんは、店の経営手法について、「うちは少数精鋭でそろえてますから」と話していました。実際、そういうのもよくわかります。その店の店員はなかなかのイケメンぞろいで、また社長以下、みんな気さくで感じのよい人たちばかりです。そしてみんな、すごくよく働いています。社長さんは「うちは軍隊です」と言い切るだけのことはあり、なかなかハードな環境のようですが、でもその中で、社長さんの考えに共鳴し、おそらく他の店よりは厳しい条件にも関わらずがんばって働いている店員の方が大勢いることが、その店が１０年間、人気店であり続けている理由なのだと思います。

少数精鋭とするということは、そこには適さない人も多くいるということを意味しています。実際入っても耐えられなくてすぐ辞めていく人もいるそうです。それを耐え抜いた店員こそが本当の少数精鋭の店員となれるわけです。

少数精鋭とすると、一人当たりの仕事量が大幅に増えます。でも一人当たりに払ってあげる給与もそれなりに高くしてあげることもできます。またそうやって厳しい仕事を覚えることは、その人にとって、将来独り立ちしてお店を持った時に非常によい経験として生かされるのだと思います。

この少数精鋭の考え方はIT系の企業経営においても同じ考え方が応用できるのではないかと思いました。少数精鋭によるスーパー・テクニカル・チームから成り立つIT企業です。無駄に規模を追うのではなく、お客様からの絶大なる長期的な信頼をベースに、高収益性を目指す会社です。update it, Inc.はぜひこの路線で行きたい。ちなみに「楽な方がいい」という人には入社をご遠慮いただくことになりますね。

ここのところ、証券市場では新興企業への風向きがあまりよくないようです。確かに今までいろいろありましたからね。いけいけどんどんの頃は皆が選別もなしにIPO銘柄を買い漁っていた時期もありましたが、そういった一種のバブルが崩壊してしまうと、一挙に信用収縮というか、新興企業というだけで相手にしなくなってしまう、といった負の連鎖が始まってしまうのでしょう。今はベンチャーにとって資金調達という面では試練の時期なのかもしれません。

私は、ベンチャーであるというのは、すばらしいことだと思っています。そしてベンチャーであることを誇りに思っています。本当のイノベーションは常にベンチャーから起こると考えているからです。そしてベンチャーには、「普通の会社でなくてもよい」、という特権もあります。ベンチャーが大企業と同じことをやっていたのでは、競争優位性がないのは明らかですから、おそらくすぐに潰れてしまいます。ベンチャーはその存在そのものが、「普通の会社ではない」ことを求められる存在だと思うのです。

私は、update it, Inc.はベンチャーとして、いつまでも「普通の会社ではない」ことを目指さなければならないと考えています。競争優位の源泉としての、「普通の会社ではない」ことにこだわり、唯一であること＝ユニーク性に常に磨きをかけていきたいと思います。

日経ソリューションビジネスの4月15日号の特集ページ「胎動！ IT業界維新」で、NTTデータが「年内に『セル生産方式』のパイロットプロジェクトを走らせる」という記事が載っているようです。（「ようです」と書いたのは、私自身は日経ソリューションビジネスを取っていないので、ITProに公開されている記事の抜粋を読んだだけだから、です。  :grin:）

セル生産方式とはキャノンなどが取り入れて有名になった生産方式で、Wikipediaによると、「1人、または複数人の作業者チームで製品の組み立てを行う。ライン生産方式などの、従来の生産方式と比較して作業者一人が受け持つ範囲が広く、場合によっては最初から最後まで1チームで担当する。」となっています。製造業向けの生産方式の１概念なのですが、NTTデータではそれをシステム開発の現場に適用し、「NTTデータの社員がシステム構築における上流だけではなく、中・下流のソフト開発やテストをパートナーと共同で進める」ことを意味するそうです。

「そんなことはもうやっているよ」っていう会社もあるかもしれませんが、これだけ大手のSI会社が中・下流も自分たちが主体的に絡んでやっていこう、という姿勢が現れているということはとっても良いことだと思います。

このセル生産方式は、作業工程の一人ひとりのスキルの高さを前提に、優れた少人数のエキスパートチームによって製品を作り上げるということがポイントです。少人数のエキスパートチームということであれば、いろいろな雑多で複雑なことを扱うには大組織よりも明らかに向いていますし、中の人達の士気を非常に高く保つことができます。そう、システム開発というのは雑多で複雑なことを扱う、クリエイティブな作業であり、本質的にこのセル生産方式のようなやり方が向いているのです。

またこれを実現するためにはメンバーのスキルを非常に高く保つ必要があります。そのための教育コストは当然高くつくわけですが、結果として、そのコストを軽く補えるほどのリターン、つまりプレミアムが得られるはずです。

NTTデータのこの試みがぜひ成功して欲しいと、強く願ってやみません。

ホームページも作らずに先にBlogを始めてしまっていたのですが、ついに会社のホームページが完成しました。

これです。

ホームページを作るに当たって、「そういえば、我が社はまだ売り物ができていない → 紹介するものがない！」という事実に直面しました。  😀

このままでは中身のないスカスカのホームページになってしまいます。そこで、このままではイカンと考え、こんな企画（見てのお楽しみ）も用意してみました。

皆さんからのご感想、コメントなどはこちらのBlogで受け付けます。ネタなども大歓迎です。ぜひ覗いてみてください。

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

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

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

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

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

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

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

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

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

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

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