超零細ソフトウェア会社が生き残るには？
仕事をする能力はあるのに、仕事がない。よく聞く話です。何が打つ手は無いのでしょうか？
もっと良い製品・サービスを作る？もっと安く売る？ごもっとも。大企業が、資本にモノを言わせてやるような事です。じゃあ、ウチのように数人でやっている超零細のソフトウェア会社には、何ができるのでしょうか？
いろいろ考えてみましたが、やっぱり出した答えは、「もっと良い製品・サービスを作る」「もっと安く売る」。あれれ？大企業がやるような事と同じですね。ただし、結果は同じでも、やり方は違います。
いかにして製品が作られ、ユーザーに価値をもたらすか。
全体に注意を配る事が、よい製品への道となる。
超零細のソフトウェア会社がやるべき事は・・・
「製品やサービスをうまく作れるだけじゃダメ！最終的なユーザーメリットを増すように、あの手この手を考えないと！」
うん！なんだかもっともらしい気がする！でも何の事だかさっぱり分からない！とお思いの事でしょう。ですから、もう少し詳しく見て行きましょう。
（ご注意：今回の記事は、ごくごく個人的な意見です。くれぐれも真に受けないで下さい！！）
「加工」って何の事？
ヒト、モノ、カネを投入して、何か製品を作ったり、あるいはサービスを提供したりする事を、「加工」と呼ぶ事にします。
ウチの場合、（株）NEATさん経由で、愛知県の自動車メーカーさん、部品メーカーさんからモデルベース関連の仕事をいただいています。
お客様：「「こんな感じのソフトウェアを作って欲しいんだけど？」
ウチ：「（こちらで作成した仕様書を見せながら）こんな感じにしましょうか？」
お客様：「オッケー。じゃあそれでよろしく！」
こうして仕様が決まったら、あとは人件費をかけて言われた通りのツールを作るだけ。最終的にお客様のメリットになろうがなるまいが、とにかく言われた通りの事をすれば、お金がいただけます。これを「加工」と呼びます。
超零細のソフトウェア会社が生き残るには、まずこの「加工」段階における企業努力が必須です。
「加工」における企業努力
「加工」における企業努力をひとことであらわすと、「コストダウン」という事になるでしょう。
コストダウンすれば、「製品単価を下げる」
「お値段据え置きで量を増やす」などの事が出来る
さて、ソフトウェア会社がコストダウンを実現するには、いくつか方法があります。
・人件費削減１ ⇒ 社員にサービス残業を押し付ける （違法ですが良くある話）
・人件費削減２ ⇒ より単価の安い外注さんを、よりうまく使いこなす （派遣社員、オフショア開発など）
・加工の効率化１ ⇒ ノウハウやツールを利用して効率を上げる （勉強する、研究する、ツールを買う）
・加工の効率化２ ⇒ 工程にあるムダを削減する （この会議、意味ないよね？もうやめない？）
しかし超零細のソフトウェア会社は、基本的に研究開発のための資金なんてありません。だから、お手軽に実施できてそれなりに成果の上がる事をしないといけません。次の章で、ウチの取り組みをご紹介します。
企業努力：ウチの場合
ウチでの重点は、加工の効率化です。本を読みあさったり、ツールを買いあさったりして、なんとか今いるエンジニアの開発効率を最大化するように努力しています。
その中で、格別効果があったと思うものを並べて行きます。
プロジェクトマネジメント
・CCPMという管理手法
・FogBUGZというバグトラッキング＆プロジェクト管理ツール
CCPMとは、ややこしい管理をしなくてもプロジェクト管理をしっかり行える、まさに超零細ソフトウェア会社のためのような手法です。
やり方は簡単です。まずプロジェクトの頭で作業時間の見積もりを行う時、あえてキツ目で行います。だいたいイケるかイケないか５０％くらいの時間で見積もっておおくのです。そうすると当然、全体でみると間に合いません。そこで、プロジェクト全体としてバッファ（余裕）を持たせておきます。あとは、バッファの残り量を監視するだけです。
各作業はキツ目に見積もっているわけですから、当然バッファを食っていく事になります。するとバッファが切れた＝プロジェクトは間に合わない、と分かります。万が一そうなっても、早め早めに手が打てるため、納期の朝になって「やっぱり出来ませんでした」というような事は無くなります。詳しい話は、この本がすごくお勧めです。（アフィリエイトじゃないですよ。この本が売れても、私には１円も入りません）
FogBugzには、エンジニアの作業時間を測定する機能があります。面白いのは、作業前に見積もる機能がついている事です。たとえば、私が「この作業は２時間で終わる！」とFogBugzに申告したとしますよね。でも実際には４時間かかりました、と。そういう事が続くと、FogBugz側で「ん？吉武が２時間で終わるって申告してる？じゃあ２倍して４時間ってのが妥当な所だね」と計算してくれます。こんな感じで、実際の所どれくらいの時間かかりそうなのか、その確率分布をグラフ化してくれます。
CCPMとFogBugz、両方ともユーザーにかかる負荷は殆どなく、使い方を覚えるのも簡単です。
このように、CCPMと、FogBugzのプロジェクトマネジメント機能とはちょっと似た思想で作られていて、相性がバツグンです。（詳しく書くとキリが無いので、詳細はまたの機会に。）
開発ツール・ノウハウ
ハードウェアとしては、次のような物が有用でした。
・デジタルオシロ（RIGOLの製品を買いましたが、値段の割によく出来ています）
・ロジアナ（ポケットロジアナです）
・通信モニタ（LINEEYEのこちらの製品です）
ソフトウェアとしては、次のような物が有用でした。
・VisualStudio （Eclipseでも代用は可能ですが、正直、作業効率はVSのがダンゼン上です）
・単体試験ツールC++test
・マルチプラットフォームライブラリ Qt
・パフォーマンス解析ツール VTune
・インストーラ作成ツール Install Shield
サーバー製品としては、次のような物が有用でした。
・バージョン管理システム（ Subversion＋TortoiseSVN ）
・ノウハウ蓄積用サーバー（ DekiWikiのフリー版 ）
・VMWare Server
特にお気に入りはC++testです。とても簡単に単体試験が作れる上に、コードカバレッジ測定機能もついています。そのおかげで、かなりコード品質が安定するようになりました。
これらのツールをベースに、ジョエルテストを満足する方針でカスタマイズを行っています。
このように努力し続けた結果、ここ１～２年は納期も安定し、開発効率も良くなりました。（昔のお客様、ほんとうにごめんなさい！）
ただし、これらのツールに、商売上必要なMATLABとオプション製品を加えると、５００万くらいになりました。５００万ってかなり痛いですよね？超零細の話なのに、なんでそんな大金かけてるんだ！と思われる事でしょう。しかしこれは、試行錯誤する中で色々買い集めたからにすぎません。
もしも今から、最小限の費用で開発効率を上げようとするなら、次のツール構成にするでしょう。
・CCPMを導入（薄い本を１冊読むだけで出来る）
・Subversion＋TortoiseSVN （フリー＋フリー）
・DekiWiki （フリー）
・FogBugzによるプロジェクトマネジメントシステム （一人頭、たった数万）
さらに余裕があればC++test（あるいは、これのJava用や.NET用）が欲しいところです。CppUnitのようなツールですが、単体テストが遥かに楽に、しかも高品質になります。C++testでみっちりテストしたモジュールからは、（結合段階以降にて）プログラムミスが見つかった事はありません。
ひょっとしたら、あなたの方がもっと良い方法をご存じなのかも分かりませんね。もしも宜しければ、こっそりと教えて下さい。
ただし、このような企業努力には、常駐案件を請けられない、という重大な欠点があります。次の章で、その理由について説明します。
常駐案件をお断りしている理由
今年、「客先常駐で制御モデルを作ってほしい」というよう案件を２件ほど振っていただきましたが、全てお断りしました。ウチは常駐案件は基本的に受けない（超短期の場合のみ例外）というポリシーがあるため、どんなに良い単価の案件でも、お断りしています。
理由は、上に書いたような「加工の効率化」による企業努力がしにくいからです。
・プロジェクト管理手法の改善
・ノウハウの蓄積（データベース化）
・開発ツールチェーンの最適化
これらを、客先で行うのはムリです。
特に一番痛いのが、仕事中にノウハウを蓄積する事が出来ないという点。普段から、仕事中に使えそうなノウハウが得られたときは、解説をつけて積極的にWikiに登録するようにしています。これが、どれほど開発効率の向上に寄与したか、測り知れません。
常駐してしまうとこれらの企業努力が出来なくなります。すると、結局できる企業努力といえば、人件費削減しかありません。お客様からさらなるコストダウンを要求された場合、給料を下げるしか手が無くなってしまいます。そんなのイヤですよね？
ですからウチは、持ち帰り案件だけを少し緩めに請けています。案件と案件の間のスキマ時間には、自社製品を作りこむか、より開発効率をアップさせるための実験をする事にしています。
さて、かなり長い記事になってしまいました。しかし、本当に重要なのはここからです。
これでは不十分。徹底的に不十分。
さて、上記のような企業努力をすると、コストダウンは実現できます。そのため、給料を下げずに「より安く売る」事が出来るようになります。（ソフトウェア会社であれば、他社と同じ人月をかけて、他社よりも多く生産する、という形になります。）
では、そのような努力をしてきたウチは、すごく儲かっているのでしょうか？
私の計画では、いまごろ社員１００人くらい抱えて名古屋ルーセントタワーの最上階フロアを占拠していたはずです。用事があれば、ヘリポートから専用ヘリでびゅーんとひとっ飛び。渋滞なんて関係ナシ！そんな予定だったのですが・・・残念ながら、さっぱりそんな事はありません。ものすごい田舎に、ちっちゃい事務所を構え、細々とやっています。
これまでの「加工」に関する努力はムダだったのかというと、決してそんなことはありません。でも、足りないんです。何か重要なピースが足りない。なんだか、思いっきりアクセル踏んでるのに、トロトロとしか走れない。むむむ！ギア―がローに入ってるぞ！？そんな気分です。
これから、その「重要なピース」について説明します。
「活用」とは？
お客様が、製品、サービスを購入したとします。しかし、それがすなわち最終的なユーザーメリット（楽しさを増す、苦痛を減らす、コストダウン等）になるわけではありません。
購入された製品・サービスは、うまく「活用」される事で
はじめてユーザーメリットへと変換される
「活用」とは、エンドユーザーが製品を購入したあと、それをどう使っていくのか？という話です。
ちょっとまえに iPod shuffle という極小のミュージックプレイヤーを購入しました。実は、健康のためにウォーキングをしているのですが、その時間が退屈だったんです。そこで、ウォーキング中にiPodで音楽を聴く事にしました。
ただ iPodが転がっているだけではなんのメリットもありません。しかし、こういう風に「活用」したときに初めてユーザーメリットが生まれます。私が買ったのは、iPodという製品ではありません。ウォーキング中の楽しい時間を買ったのです。
私がこれまで怠ってきたのは、この「活用」領域における企業努力でした。ですから、超零細ソフトウェア会社にも出来そうな企業努力を考えないといけません。次の章で、詳しく考察してみます。
「活用」における企業努力
たぶんコツはただ１つ。とにかく「最終的なユーザーメリットを増すように、あの手この手を考える事！」。いくつか例を見てみましょう。
お客様との商談シーン（自社製品の販売）
「加工」ベースの会社： 弊社の製品には、こんな特徴があって、こんな機能があります。しかも、こんなに低価格ですよ。
「活用」ベースの会社： 弊社の製品は、こんな風に活用している方も居ますし、あんな風に活用している方も居ます。いろんなメリットがあるのですが、何かご興味のあるお話はありましたか？
解説：製品が売れればそれでいいんじゃありません。製品を購入したとして、本当にこのお客さんにメリットをもたらす事ができるだろうか？意識を集中するべきはこの１点です。
お客様との商談シーン（システム開発の提案）
「加工」ベースの会社： 弊社には、こんなエンジニアが居て、こんな技術を持っています。しかも、こんなに低価格ですよ。
「活用」ベースの会社： 弊社は、こんな技術を持っていて、こんな風にお客様のコスト削減に貢献したり、あんな風にお客様の売り上げ向上に貢献したりしてきました。ご興味があれば詳しくお話しますよ？
製品企画シーン（開発ツールを作っている場合）
「加工」ベースの会社： この機能はすごいから売れるかな。こんな機能までつければ、もうバカ売れ間違いなし！
「活用」ベースの会社： 今のお客さんは、こんな風に開発作業をしている。その工程を、こんな感じに変えられれば、とてもメリットがあるはずだ！
解説：活用ベースの会社になるには、狙っているお客さんがどんな感じで仕事をしているのか、ひたすら営業を掛けて話を聞きだすなどして、つぶさに調査をする必要があります。営業する際には、活用領域での話題を心がけるようにします。
アフターフォロー（メールベース）
「加工」ベースの会社： なにか質問があった時にだけ、返事をする
「活用」ベースの会社： システムの活用方法、その他お客様の役に立ちそうな情報を、定期的にニュースレターで流す
アフターフォロー（訪問ベース）
「加工」ベースの会社： この前お納めしたシステムは、問題なく動いていますか？そうですか、それは良かったです。では失礼します。
「活用」ベースの会社： この前お収めしたシステムは、十分お役に立っていますか？そうですか。もしも差し支えなければ、概要だけでもかまいません。御社の活用事例を他にご紹介しても構いませんでしょうか？あと、似たようなシステムを、こんな感じで活用していらっしゃる会社もあって、とても効果を上げているみたいですよ！
解説：役に立っていないようであれば、一緒に原因と対策を考える。もっとよい活用方法がありそうなら、提案してみる。このように、ユーザーメリットを実現してもらうために、あの手この手を打つ必要があります。
反省
ウチの場合は、このレベルでの企業努力を完全に怠っていました。上の例の「加工」ベースの会社は、すべてウチの話です。
それでもなんとかやってこれたのは、NEATさんの営業力のおかげです。今までもこうやってきましたし、たぶんこれからも、普通に食べてはいけるはずです。
だからといって、ウチが企業努力を怠って良い理由にはなりません。それに商売をしているからには、いずれルーセントタワーの最上階を占拠したいですよね！？そのためには、最終的にお客様のメリットを増やすよう努力しなければいけません。
まぁ、ルーセントの話は冗談です。さておき、ソフトウェアはこれから、どんどん海外の安い労働力との競争にさらされるのは明白です。まともに勝負しても勝ち目はなさそうですが、実は彼らには弱点があります。
それは、彼らは徹底的に「加工」ベースである傾向が強い、と言う事です。言われた通りには作る。しかし、ユーザーメリットが生まれるかどうかは気にしない。その点、日本の会社のがまだマシです。お客様のクレームに対して、仕様書に書いてなかった！そんなのウチの責任範囲じゃない！なんてあまり言いませんから。
（あくまで傾向の話です。外国の会社で、安くて、なおかつお客様のために考えて行動できるような会社も実際に知っています。）
たまに、「付加価値が大事だよね！すごい独自技術を開発して、それで収益を確保しよう」というような話を聞きますが、経営的にはすごく危険な考えだと思います。すごい技術を作るにはすごいキャッシュが必要です。それに見合うだけの「お客様のメリット増大」が見込めればOKです。しかし、なかなかそういうネタは転がっていないというのが現状です。
それでもキャッシュリッチな大企業であれば、なにか最新鋭のシステムを開発することも出来るでしょう。開発した技術は、きっと何かには使えますから。しかし、超零細ソフトウェア会社にそれはムリですし、そんな事をする必要もありません。あんまり難しい事をしなくっても、「お客様がちゃんとメリットを得られているかな？」と、常に気を配るだけでも全然違ってくるはずです。
さて、本当に言いたい事はひとまず終了です。ですが後半ちょっと抽象的な話が多かったですね。ですから、イメージをつかみやすいよう、２つの具体的な事例について取り上げます。
HILSシステムの場合
今はもう、ほとんど関与していないのですが、昔はとあるHILSシステムのサポートをやっていました。ちょうどHILSバブルとでも呼べる時期で、とにかくポンポンとHILSが売れた時代でした。
モノを右から左に受け流せばよいのであれば良かったのですが、世の中そんなに甘くありません。たいがい何らかのカスタム要素が含まれるため、「まともに動くようにする」だけでものすごく大変でした。それ以外にもいろんな要因が重なって、とにかくすごくすごく大変でした。
そうすると当然、いかにうまく「加工」（＝HILSシステムを作り上げる）するかに目が行きます。その結果、いかにうまく「活用」（＝HILSシステムを活用して、品質向上や工数削減を行う）するかについては、まったく考慮に入れられていませんでした。
HILSというのは、むしろ買ってからの方が大変。
この部分の手当てをおざなりにしてしまったばっかりに、
販売したHILSが市場を制覇する事は無かった
一方、とてもうまくいっているHILSベンダーのやり方を見ていると、共通点があります。それは、単にHILSシステムを売るだけではなく、それを活用した業務改善までも請け負っている点です。
とくに、HILSシステムを売ると同時に常駐人員を派遣するやり方は強力です。もはやHILSの販売ではなく、検査業務の請負といってもいいでしょう。
いずれにせよ、HILSを売るだけでなく、HILSによる成果を上げさせる事に成功した会社が、勝ち組になりました。
このブログの場合
このブログのアクセス傾向を見てみると、「HILSとは？」という検索ワードで入ってきて、HILSとは？というページだけを見て、すぐに離脱する。というパターンが目立ちます。
実際にHILSのハブページを見ていただくと分かるのですが、HILSはどういう風に出来ているのか？という話ばっかりで、具体的にHILSの何が嬉しいのか？という情報が一切ありません。要するに「加工」段階の話はあっても、「活用」段階の話が無い。それが、離脱の原因ではないかと考えています。
ただし、具体的な活用事例なんかは、基本的に企業秘密です。いくらWebを彷徨っても表面的な情報しか無いでしょう。わたしもいくつか詳しい話をしっていますが、こんな所では書けません。
でも、HILSとは？というキーワードで本当に人が見たいのは、「HILSを使うと、自分の仕事をどう楽にしてくれるの？」という事のはずです。そこで始めたのがFreeHILSプロジェクトです。
HILSを作る所まではたんなる前座です。前々から、HILSなんて誰でも作れるじゃん？と思っていたので、せっかくだから作ってみよう、というだけのものです。
重要なのは、そこからHILSをどのように製品検査に活かそうか？という所です。FreeHILSが完成したら、物理モデリングを行い、システム同定を行った上で、マイコンの制御プログラムに対する製品検査を行う、という記事を書く予定です。これこそが「活用」であり、このブログを見ていただく人が実は一番見たいところではないかと思っています。
ネタとしては、倒立振子の原理で自立するロボットをあつかう予定です。これは、コードファイン・テクノロジー株式会社の高井さんからヒントをいただきました。（高井さんには、仕事上のヒントをいただいたり、飲みにつれていっていただいたりと、普段から大変可愛がっていただいています。感謝！）
FreeHILSはタダですから、教育用にいいんじゃないかな？とも思っています。そこで、HILS構築のためのノウハウ一式をパッケージ化して、HILSによる製品検査入門！なんていう教育サービスを作ると面白いんじゃないかと考えています。
もちろん、ノウハウなどの情報は、全てこのブログ上で公開します。しかし、やっぱり読んでいるだけではダメで、実際に手を動かしてみないと、実感が湧きません。そこで、演習をいっぱいこなして本当の意味で身につけたい！という方向けの教育サービスを作ったらいいのかな・・・などと考えています。
まとめ
ウチのような超零細のソフトウェア会社は、「いかにうまくソフトウェアを作るか？」にまでは気が回っても、そこから先には気が回りにくい環境にあります。
しかし、あえて意図的に、「いかにお客さんに活用してもらうか？」の努力も行わなくてはいけません。
・納入システムの活用方法について提案したり、どうやっているのかを教えていただいたりする。それをニュースレターのような形で流す
・納入後のシステムをお客さんがうまく使えているか？をフォローする （フォローの手厚さ次第で、費用の有無は変えて良いと思います）
といった事にも力を入れていく事が、これから先の生き残りには必須でしょう。
以前、研究委託のお仕事をいただいた、自動車メーカーの研究開発部門の方がよくおっしゃっていました。いろんなツールを売りこみに来るんだけど、ごくごく限られたケースでしか使えない物が多い。本当にまちがいなく有効であると認められて、仕事に必要なものであるならば、どんなに苦しくても買う、と。
本当の本当にメリットがある、ということはとても大切な事です。