update it, Inc.社長のブログ

今、居酒屋で有名なワタミの社長をしてらっしゃる渡邉美樹さんが書いた、「もう、国には頼らない。」（日経BP社）を読んでいます。まだ読みかけなのですが、非常に共感・感銘できる内容で、夢中で読んでいます。

市場主義とは消費者が選ぶ直接民主主義の1形態であり、競争の原理を公のサービスにも導入することにより、大幅にサービスを改善することができること、そして本来「官」に求められるべき機能とは、フェアであることを監視する機能と、セーフティ・ネット（弱者保護）に絞られるべきである、という主張は非常に明快で、痛快ですらあります。

渡邉美樹さんの言う市場主義とは、あぶく銭を掠め取ることではなく、お金という投票用紙を用いた直接民主主義を用いて切磋琢磨しながら正しく経営、つまりマネジメントすることを指します。こういったノウハウを持っているのは、民間企業です。

つまり、結果として今まで公=官と考えられてきた分野でも、実は民間が行ったほうが効率的にサービスを改善できるということになります。そういえば最近郵便局が民営化されましたが、先日近所の郵便局に行ったらそれまでと対応が一挙に変わって銀行窓口並みにサービスに気を配るようになっていてびっくりしたのですが、こういったことも上記のことを立証する１つの事例かもしれません。

よく「お役所仕事」と揶揄されることとして、役人はプロセスに則ったことを淡々とこなしているだけ、という批判があります。プロセスにさえ合致していれば責任を取らされることはないので、それ以上「改善」しようと努力をしない、という話です。組織が巨大化してくるとある程度プロセスは重要になってきます。しかしだからといって、競争のない世界で同じことだけを繰り返していては組織は硬直化し、活力が失われ、金が無駄に使われ、ユーザが受けるサービスが最低になっていくことは、皆さんも百も承知の話だと思います。

これって、プロジェクトでも同じことが言えますね。重要なのはプロセス通りに進めることではなく、競争を意識した「マネージメント力」だと思うのです。

もし、自分の仕事にどこか「官僚的」なものを感じるのであれば、何かのヒントとして、ぜひ読んでみてください。読んで損はしない本だと思います。

昨日のブログではパッケージ化のためにはマーケット分析が重要だよ、と書きました。これって実は、普通の会社が普通にやっていることだと思いませんか？　つまり、自分のところで売るものを何にするか、マーケットを良く分析して決めるということです。でも受託開発をベースにしている会社の場合、マーケット分析をして売り物を定めるということをやっているところはどのくらいあるのでしょうか？　まずはこれから着手するだけでも他社との差別化が図れるのではないかと思います。

さて、パッケージ化を行う際に難しい問題として、そのパッケージのノウハウのアイデアは誰のものか、ということがあります。ノウハウは当然ただではありません。もしパッケージ化を行うにしても、肝心なノウハウの部分が他社から提供されている場合には、せっかくパッケージ化したとしても、おいしい部分を持っていかれ、自分はリスクだけを抱えるといったうれしくない状態になりがちです。これはできるだけ避けるべき事態です。

そうは言っても、これを避けるためには、実際に業務をしているお客様の会社よりもシステムを開発している側が商売のノウハウをより多く持っている必要があります。果たしてそんなことができるのでしょうか？　できるわけがない？　　いや、できるのです。

なぜならば、お客様の会社のほうは自分のところの業務ノウハウはありますが、同業他社のノウハウまでは知りません。システムをパッケージ展開できているところは、複数の会社に接しているので、その中から次のビジネスの種をいち早く察知して、それをサポートするためのパッケージを開発することが可能です。もちろんお客様側のノウハウをいろいろと頂くことになる部分もあると思いますが、一方で提供する側にもなるのです。このGive and Takeの関係ならば、一方的にノウハウ料を吸い取られることにはならないのです。

もしこのブログを見て、皆さんにとって何かのヒントになることがあれば、私は最高に幸せです。日本のソフトウェア会社が変わっていくことを切に願っています。

先週のブログで受託開発からの脱皮をテーマに３回ほど書きましたが、今回は脱<<受託開発>>を考える上での問題点として、「パッケージに向くもの、向かないもの」について触れておこうと思います。なおここでいうパッケージ化とはいわゆるパッケージソフトだけでなく、ASPやSaaSなど、広い意味で特定の業務をサポートするソフトウェアやサービスを提供することを意味するものと捉えてください。

いくらソフトウェアの世界はパッケージによる展開が魅力的だとしても、なんでもかんでもパッケージ化が可能なわけではないのは皆さん百も承知の事実です。パッケージ化が可能なのは同じものを複数のお客様に売る（もしくはサービスする）ことができる場合であって、そのような見込みのないものであればパッケージ化する意味はありません。

今まで日本のソフトウェア開発に受託開発が圧倒的に多かったのは、パッケージによる展開をやろうにも、個別のお客様専用のソフトウェアのためパッケージ化が出来なかった、というように主張される方もいらっしゃると思います。確かにこれはもっともな主張のように聞こえます。

でも実はこれも大部分のケースは、開発する側がお客様の業務を理解していないために必然的にそうなってしまっているに過ぎないのではないかと私は思っています。

お客様の業務を深い部分で理解していれば、お客様からの要求仕様をそのまま鵜呑みにするのではなく、より深いレベルでの抽象化が可能なはずです。つまり、業務を理解していないがために適切な抽象化ができないので、様々なお客様に対するニーズにこたえられるようなシステムとして設計できないのではないか、ということです。

パッケージ化を阻害するより現実的な問題としては、上記のような抽象化を適切に行えるようになるにはかなりのノウハウの蓄積が必要で、将来売上げの見込みが立つかわからないものに対してそのようなノウハウ蓄積のために必要なコストを現時点で払うことができない、ということがあります。また商売として考えたときに、たとえすばらしいパッケージソフトが出来たとしてもそれが売れるかどうかは別問題ということもあります。これらのビジネス的な要因でパッケージ化をあきらめるのは当然、正しい選択だと思います。

ということは、（当然のことですが）パッケージ化を行うためにはマーケット分析がとても重要です。今後、対象の業務についてのニーズがどれだけ増えるのか、正しく予測することが必要だということです。

業務がわかっていれば、対象業務領域についてのマーケット分析もより確実にできると思います。もしそれが将来的に有望な市場で対象業務について確実に拡大が望めるのであれば、パッケージ化をぜひ検討すべきだと思います。

昨日の「お客様の業務を理解することの重要性」において、お客様の業務を理解しないとパッケージや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データのこの試みがぜひ成功して欲しいと、強く願ってやみません。