update it, Inc.社長のブログ

今日の日経ITProの記者のつぶやき「学生とIT業界トップの公開対談で胸を衝かれたこと???IT産業を呪縛する“変われない日本” 」がおもしろかったというか、ああ、そうだな、と思いました。

変わらないことへの強い指向。これは日本の社会に今深く根付いているように思います。上記の記事では「私塾のすすめ――ここから創造が生まれる」（ちくま新書）という本から次のような内容を抜粋して紹介しています。

—
『時代の変化』への鈍感さ，これまでの慣習や価値観を信じる『迷いのなさ』，社会構造が大きく変化することへの想像力の欠如，『未来は創造し得る』という希望の対極にある現実前提の安定志向，昨日と今日と明日は同じだと決め付ける知的怠惰と無気力と諦め，若者に対する『出る杭は打つ』的な接し方
—

なんかここだけ読むと絶望的になりますね。でも確かに今日本の社会には変化しないことを指向する何かが根付いているように思います。ある意味で日本は一旦頂点を極め、それを過ぎてしまった、ということを経験しているために、没落していくのではないかという危機感から、自然に「変化しないこと」を指向しているのではないか、と私には思えます。

この記事の中で、「起業しよう，と呼びかけるIT産業のトップたち」と紹介していますが、でも今の日本には、米国式の起業ができるような受け皿がありません。日本のVCはStartupの企業にはほとんど出資することがないんです。この事実を理解しないまま、起業をあおるのは少し無責任ではないか？と思います。

もちろん、じゃあ米国式の起業をサポートできる受け皿を整備しよう、という建設的な意見は大賛成ですよ。  😀

アメリカのベンチャーが資金調達する際、このElevator Pitchというのをよくやるそうです。これは資金提供をしてくれそうな人と一緒にエレベーターにのって、そのエレベーターが目的階につくまでのわずか３０秒ぐらいで自分のビジネスプランを説明するということを指しています。エレベーターを使わなくても、ベンチャーがビジネスプランを発表する際には良く使われる手法のようです。

アメリカでは資金提供者側ではできるだけ大量のベンチャーと会って、そのなかから将来性のありそうなものをスクリーニングしなければなりません。できるだけ大量のベンチャーに会う、という意味で、このElevator Pitchというのはとても役に立つのだと思います。

振り返って考えてみると、私も自分のビジネスプランを話す機会があった場合に、短時間に印象的に話せていない場合が多かったと思います。これは事前に良く内容を練って、普段から練習しておかなければならないことなのでしょう。

幸福の女神は前髪しかない、とよく言われます。ビジネスの世界ではやはりこのような練習を「事前に」やって、いつでも備えておなければならないのだと思います。

このブログを開始して今日がちょうど1周年です。月日がたつのは早いものです。ちなみに1年前の開始したときのブログがこれです。

このブログを立ち上げた当時はまだホームページも用意していませんでした。ちなみに1年前のこのころはcrossnoteの開発真っ最中で、差分抽出のロジックやエディタの基本部分などを作っていました。私自身もバリバリ作っていましたよ。（最近私自身がコーディングするのはを止められていますが）　crossnoteという名前はまだ無く、APISというコードネームで呼んでいました。

以前のブログを振り返るといろいろ写真が入っていたことに気づきます。これらの写真は社員の人が撮ってくれたのを載せていたのですが、最近忙しかったのと寒かったということで、昨年の秋ごろを最後に撮っていませんでした。そろそろいい季節になってきたので、写真も入ってくることでしょう > 担当者さん

このブログを見てくださっている方々、本当にありがとうございます。また、ぜひ気軽にいろいろとコメントをいただけるとうれしいです。これからもよろしくお願いいたします。

最近内部統制まわりの勉強中です。『これでわかる会社の「見える化」と攻めの内部統制 – 平松　徹著　週間住宅新聞社』という本を読んでいたら、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度評価を取り入れるとしたら、どんな感じになるのでしょうか？　つまり上司だけでなく、同僚や部下、さらにはユーザや協力会社の社員など、プロジェクトの関係者に幅広く評価に参加してもらうということです。

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

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