update it, Inc.社長のブログ

最近内部統制まわりの勉強中です。『これでわかる会社の「見える化」と攻めの内部統制 – 平松　徹著　週間住宅新聞社』という本を読んでいたら、ISOのマネジメントシステム関連の認証を取るケースで、良いISOと悪いISOがあるという話が載っていました。

この悪いISOのケースとして、ISO認証を取るためにドキュメントを2重管理している例を挙げています。ISO認証を取るためには業務プロセスのドキュメント化が必須ですが、その際に実際に使っているドキュメントとは別に、ISO認証を取るための別のドキュメント類を構築して両方を維持している場合がある。そうするとドキュメントの2重管理となってしまいコストが余計にかかってしまい、ISO認証は負担が大きいということで認証を返上するケースが相次いでいる、という話です。

業務設計する際に、システムによりデータを一元化するのは基本中の基本だと思うのですが、この手の作業を現場に任せてしまうとなかなか徹底されず、結局例外だらけで効率の悪い体系になってしまう場合があります。といって、外部コンサルタントに丸投げしてしまっては、結局現場では使い物にならないISO認証専用のドキュメントが出来上がり、現場で使い続けられるドキュメントとISO認証のためのドキュメントの2重管理になってしまう場合がある、ということなのでしょう。

いずれにせよ、実際に業務をしている人達が、自分達でその業務を効率的にまわすにはどうすべきなのかを一生懸命考え、その結果を１つのドキュメントとして反映させていくのが正しい姿なのだと思います。そして重要なのは、そういった、現場サイドにおける細かな改善をどんどんドキュメントに反映させていき、より良いプロセスに改善していくということではないでしょうか？

ドキュメントは一元化、そして現場での改善を吸い上げることが出来る仕組み、こういったあたりが成功へのキーワードではないかと思いました。

私はどうも日々の業務に忙殺されがちです。なんせ小さな会社なので、なんでも自分でこなさなければなりません。でもそんなことばかりやっていると、一番重要な、大切なことが抜け落ちてしまいます。そこで会社の関係者の方のアドバイスに基づき、中期アクションプランを作成することにしました。

要はプロジェクト・マネジメントと同じで、WBSに落とし込んでスケジュール化する、というだけなのですが、難しいのは比較的プロセスが明確なシステム開発プロジェクトとは異なり、状況に応じていろいろな「パス」が発生しうるという点です。その都度書き換えていけばよいのだと思いますが、そうは言っても想定しうるパスについては書いておきたいもの。

そうなると、ガンチャート的なスケジュールには不向き？のように思えます。何か良い方法はないものでしょうか？

会社を起業するときとか、他の人に自分のビジネスモデルを説明する際には、事業計画書が必要になります。金融機関からお金を借りる場合には当然ですが、そうではない場合でも事業計画書を作っておけば、自分の考えを整理し、事前にビジネスのリスクを分析しておき、早め早めに手を打つことが可能になります。

そして、会社を起こした後でも事業計画書は適宜更新していくと良いようです。そうすることで当初の予定と現在の状態を比較し、見直すいい機会になります。

実は今、まさにその事業計画書を現状に合わせてアップデート中なのですが、当初の事業計画と比較すると、リリース予定が1ヶ月半延びたのを再度認識しました。

見積もりが甘い、ということなのですが、そもそもやろうとしていることが大きすぎて、通常のやり方では現状のupdate it, Inc.の陣容では出来る内容ではありませんでした。crossnoteを作り上げるというのはProject X的なプロジェクトだったので、はじめからこのようなブレは想定済で、良くここまでたどり着けたな、と思っています。

なんとか「もの」は出来てきたのですが、この事業計画書のストーリーの中では、これはちょうど折り返し点に来たに過ぎません。気を引き締めて、後半戦に臨みたいと思います。

SaaSが進展してくると、システム開発会社からシステム提供会社への転換が起きる、という話を以前書きましたが、システム開発会社の進むべきもうひとつの道として、ファブレス化というのがあると思います。ファブレスとは設計やマーケティングに特化した、製造を持たない会社形態を指します。システム開発会社にもこういった、製造を行わないという方向に進むという選択肢があると思います。

つまり、上流工程に特化して、要求定義から仕様設計までを担当するような会社です。製造は製造に特化した会社=ファンドリに任せる、という考え方です。SaaSの世界ではファンドリに相当するのがシステム提供会社となると思います。

ファブレス型のシステム開発会社というのは実は既に存在しています。対象分野が特定の専門領域に特化していると、このようなファブレス化というのが行いやすいのだと思います。

ファブレス型のシステム開発会社の問題点として、仕様設計ばかりに特化してしまうと技術面が弱くなってしまいがちだ、という面があります。いわゆる「丸投げ」体質になってしまう、ということです。

しかしファブレス型だからといって技術面が劣ってよいわけはありません。ファンドリの能力を吟味しなければならないわけで、むしろファンドリよりも優れた技術能力や知識が要求されるはずです。

これからは、ファンドリ側にはSOAアーキテクチャでシステムを提供してもらい、それをファブレスのシステム開発会社側で「マッシュアップ」して提供する、という選択肢もあると思います。このやり方であればうまくコンポーネント単位での水平分業が進みますし、ファブレスはファブレスらしい付加価値を提供できるのではないでしょうか？

現在crossnoteに関してマーケティング活動をしているのですが、いろいろと勉強になります。そもそも私自身は今までマーケティングなんてことは今まであまりやってきていないので、手探りでやっている感じです。でも、いろいろな方からアドバイスを頂きながら、なんとか進めています。

最近１つ勉強させていただいたこととして、言葉の大切さがあります。たった一言で相手にこれが何なのか、を伝えることができる言葉の大切さです。

今までcrossnoteを説明してきた人に聞いた意見として、私の説明の仕方が下手というのもあるかもしれませんが、結局のところ、何なのかがわからないという方が多くいらっしゃいました。いろいろ機能を説明しても、じゃあ結局何なのか、がよくわからない。やはりこの「結局何なのか」に相当する部分にぴったりする言葉が必要なのだということを、最近ある方から教わりました。

crossnote を一言で表す言葉はまだ模索中です。今現在、１つ思いついたのは「共同作業のためのワープロ」です。ワープロといえばワープロなんだけど、どこが違うかといわれれば、共同作業のための仕組みがあるのが違う、ということになります。

もし皆さんのなかで、crossnoteのことを一言で表すいい言葉が浮かんだ方がいらっしゃいましたら、教えてください。よろしくお願いいたします。

先日、会社と社員の関係ってどんなものなんだろう、と考えさせられる体験をしました。あまり詳しくは述べませんが、ある商品を買う際に感じたことです。

個人用のある商品を購入した際、その商品の営業マンの不手際のために、ちょっとしたドタバタがあったんです。その営業マンの方自身は良くやってくださっていたのですが、如何せん、手際が悪かったのですね。その上、基本的な部分で間違いをしていて、そのために何度も契約しなおす羽目になったり、あちこちに確認の電話を入れる羽目になったり、時間を食われたり、となってしまったのです。

ちなみにその営業マンはまだ新人さんのようでした。

結果としてはその営業マンを責める話かもしれないのですが、そこでふと思ったのは、そういう事態をその会社は、会社として予めリスクとして認識し、うまくコントロールすべきだったのではないか？　ということです。

その営業マンの人は自分のミスをなんとか自分の中だけで処理しようとしていたようなのです。しかし、やっぱりミスは個人の責任ではなく、会社の責任として処理するような仕組みにしておかなければならないはずです。

つまり、こういう事態が発生したら必ずエスカレーションすること、などといった規則を予め決めておいて、問題が発生したら必ず上司に連絡を入れ、皆で問題をシェアし、解決策を確認する。非常に当たり前のことなのですが、この教育がきちんと出来ていないことが問題だと思ったのです。

昔はビジネスマンになったら最初に「ホウレンソウ（報告、連絡、相談）」の原則を習ったと思うのですが、今はどうなんでしょうか？　今一度、噛み締めてみると良い言葉ではないでしょうか？

昨日ご紹介した渡邉美樹さんが書いた、「もう、国には頼らない。」（日経BP社）の中に、学校の先生を360度評価するという話が載っています。先生にも切磋琢磨してもらうために、その評価基準として自分および上司だけでなく、同僚、部下、PTAの親、さらには生徒にもアンケートを取り、評価を行うということです。（ちなみに本人評価は自分に甘くなりがちであること、および校長を除く上司や部下による評価は結局年功序列的な結果となってしまうということで、途中から評価基準から外すように「改善」したそうです）

生徒からの評価というと、生徒に媚びる先生が高評価になるのではないかという疑問が出ると思いますが、生徒側が選ぶのは結局は尊敬できる先生を選ぶようです。先生は生徒から尊敬されるようにがんばる、ということになります。これは非常に自然なことだと思いました。

生徒というのは学校から見た場合の「お客様」に相当します。もちろん一般のサービス業における「お客様」の定義とはだいぶ異なるのですが、やはり学校というサービスとして考えた場合のお客様であることには間違いはありません。生徒からの評価を聞くというのは、エンドユーザにアンケートを行うというのと同じ話なのですよね。

さて、システムの開発現場でこの360度評価を取り入れるとしたら、どんな感じになるのでしょうか？　つまり上司だけでなく、同僚や部下、さらにはユーザや協力会社の社員など、プロジェクトの関係者に幅広く評価に参加してもらうということです。

プロジェクトが営業的にはうまくいったものの、プロジェクト・メンバーは疲弊しまくり、結局は大量の退職者を出してしまった、なんてことを避けるためには非常に良い方法かもしれません。また影に隠れて、ユーザからの評価に寄与していた人物が浮かび上がるかもしれません。プロジェクト内のコミュニケーションに大きく寄与していた人物がはっきりするかもしれません。

少しでも客観的な評価に近づくためには非常に有用な手法ではないでしょうか？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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