最近は、SEO対策に大きな変化があり、ますます被リンク重視の対策からコンテンツ自体の意味的な情報量やユーザビリティに重点を置いた対策のウエイトが強くなっています。今回は、内部SEOをかけるときに気になる、結果がどれくらいの期間でどのように反映されていくかをデータから推測してみようと思います。

■結論から言えば、3週間から1カ月

　下の図は、筆者が管理するWebサイトに構造化データの第1弾としてパンくずリストを導入した時の認識されていく様子です。

　筆者がこの施策を行ったのは、2013年5月14日です。この図から見ると、大体、反映に3週間から1カ月くらいかかっています。インデックスされているページ数は約130ページです。このとき、反映され方としては、ガツンと一発で反映のされるのではなく、少しずつ段階的に反映されています。

■なぜ、調査対象に構造化データを選んだか

　ここで、なぜ、内部対策の反映のされ方の調査に構造化データを選んだかということを説明します。構造化データはコンテンツの意味的なものを含むため、コンテンツのテーマ分析など意味解析を行っているので、インデックスされるタイミングではなく意味解析が反映されるタイミングに最も近いと判断したからです。

■テーマ・意味的分析されたインデックス評価と速報インデックス評価

　サーチエンジンのインデックスの評価され方としては、テーマや言葉の意味まで解析されたものと、全文検索的にチェックされただけで速報的に新しいページにのみ適用される評価の2種類あることが、次のことから予想されます。

　よく、タイトルを変えたり、コンテンツの内容を変えてGoogleのWebmasterツールのFetch as Googleでインデックスされるようリクエストを送られる方もいると思いますが、それは、あくまでもフレッシュな情報に対しての速報的なインデックスのされ方に有効と考えられます。理由としては、タイトルをすべて変えて送信すると、1～2日後にインデックスされ狙ったキーワードの順位は一時的に上がるからです。しかし、翌日かその次の日くらいになると下がります。そして、じわじわと上がっていくというケースが筆者がSEO対策をかけているときには一般的な動きとして観測されています。

■どのくらいで効果が出るかの目星があることは重要

　SEO対策は、ある意味、我慢比べ的なところがあります。継続することがとても大事です。しかし、戦略なき継続は何も生み出さないので、現在行っている戦略が正しいのか正しくないのかはきちんと把握する必要があります。もし、戦略が間違っていれば、気付いた段階で方向転換が必要です。

　そのような意味で、どのくらいで戦略を変更すべきかを判断する指標として、ある程度の参考指標があると、気分的にずいぶん違うと思います。

■今後もSEO対策は必要か？

　Googleが被リンクより内部リンクを意識する方向に舵を切り、Yahoo検索がGoogleに統合され、一見、SEO対策がビジネスとして終わったような雰囲気になっていますが、SEO対策自体はますます今後、重要度を上げていくと考えられます。終わったのは、被リンクを用意するのが中心の業者の視点で見たときのみです。

　世の中の人々は、常に、情報インテリジェンスを要求しています。情報インテリジェンスというのは、一次情報を正しい分析方法で分析し、今までになかった視点を与えてくれる知的なパワーです。現代のサーチエンジンは、「被リンクを受けた」という実績重視の評価から、「サイトコンテンツの整理され方と、サイトのテーマに関して含んでいる情報量」という将来性重視の提案に力を注ぎ始めたということです。

　多くの人が新しい一次データに触れる機会を作りだし、社会における情報の伝搬しかたを根本から変える新しい時代の幕開けです。社会の中で「情報を評価する」という活動を行う権利があまねく誰にも平等に訪れ、その分析結果を情報発信し、分析能力が平等に評価され、その中で上位に立つ者がアクセスを集められるということを意味しています。

　最近は、個人のブログでも月間数十万や100万アクセス越えのものがちらほら出てきましたが、ますます、今後は非常にアクセスが多いブログが増えていくと考えられます。

■IT技術者の起業はドキュメントコンテンツを利用したSEOからがおすすめ

　ですから、技術者の方で、ベンチャーを始める方は、まずはHPを作って、有効なドキュメントコンテンツを作成し、内部のコンテンツ重視のSEO対策から始められることをおすすめします。

　最低限必要な被リンクは、プレスリリースで一発で確保できます。これは、スタート時には貧弱で取り上げてくれるメディアがなくても、発信したプレスリリースをすべて載せてくれるサイトがあるので、そういうところで被リンクの最低限の部分はOKです。

　あとは、ドキュメントを1ページ1ページ濃い内容で作っていき、その情報発信に情報インテリジェンスがあれば、きちんとした営業活動になります。今後、サーチエンジンが情報インテリジェンスの発掘の方向に力を入れれば入れるほど、さまざまな人にとってチャンスがある社会になっていくと思うと、とてもワクワクします。

■さまざまな仕事をすると見えてくる共通点

　筆者は、根本となる仕事は、開発のフレームワークや言語の開発など、IT関連のデベロッパーです。しかし、それだけでは起業はできないため、マーケティングや営業活動、業務用ソフトウェアの仕様決定や要件定義など、幅広い仕事を行っています。

　そうした中で、非常に感じるのは、営業でさえ、プログラムを作るのと頭の使い方は同じなのではないかということです。そして、その共通点こそが「調査能力」と「分析能力」だと感じるようになりました。

■調査分析に必要な論理的思考は感情との戦い

　一見、論理的思考というと、感情や精神論とは無関係に思えるかもしれませんが、実はそうではありません。むしろ、精神論が中心なのではないかと思えるくらいです。

　論理的思考というのは、むしろ、誰もが持っているベーシックな頭脳の働きです。感情と無関係な機能です。そして逆に、まっさらな機能の上に感情が入ってきて本来の動きを阻害してしまうという方が多く、その感情による副作用をいかにに抑えられるかが論理的思考の能力だと思います。

　人間は、自分に都合のよいものを見て都合の悪いものは見て見ぬふりをしたがる性質があります。これは、本当に根深いものです。論理的思考の追求は、常にこの性質との戦いです。

■なぜ、思考を途中でやめてしまうかを人工知能から考える

　なぜ、このような性質があるかというと、それは、われわれ人間にとって必要だからです。人工知能では、勉強した経験がある方ならば、ポピュラーなことなのでご存じだと思いますが、α-β法というものがあります。これは、思考のツリーで、考えなくても良いと思った枝をカットしていく手法です。

　思考というのは、将棋や碁をイメージしてもらうと分かりやすいですが、ツリー構造を取っています。最初の一手があり数パターンあります。そして、最初の一手の先の二手目がまた、それぞれの一手目の先に数パターンあり、三手目というように、ツリー構造がどんどん指数関数的に広がっていきます。

　コンピュータも人間もすべてのパターンを考えることはコスト（＝計算の手間）がかかりすぎてできませんから、いかに効率よく「考えなくて良いもの」を判断し、そこから先の枝葉は切り捨てるといったことが必要なのです。しかし、ときにはこれが副作用になってしまうのです。

■頭で分かっていても体が動かない

　何かを身に付けようとしたときに、頭で分かっていても体が動かない、または、やるべきことに気付けないということは多々あると思います。特に後者の方が深刻で、むしろ自分の弱点に気付くことさえできません。したがって、スキルアップが難しく、どんどん泥沼に陥り、都合のいいように使われるだけになってしまいます。

　特に、新しいことを行う際には非常に大きな抵抗があります。新しいこと、知らないことは自然界の動物にとって、危険なことですから、本当に必要な時以外は生き延びるために、後回しにして、既存の成功例があるところを無難に組み合わせてなんとかしようとするのは、動物として自然なことです。

　しかし、人間の世界はもう、自然ではありません。社会はインターネットの発達などによってグローバル化し、競争も激化していますが、それ以上に、自分に対する脅威が自然と違って直感的に分かりにくいものになってきています。ビジネスで負けても、肉食動物に襲われたのと違い、別にすぐに死ぬわけではなく、徐々に分かりにくい形で追い詰められていくのです。

　論理的思考は、われわれ人間が、実際に現実の世界で自分の運命を切り開くためのツールです。現実の行動に思考が結びつかなければ、思考の意味がありません。そして、うまく、思考ツリーの枝切りの方法をチューニングして、動物の限界を突破することが必要です。

■一番よい方法はリラックスして目的を持つこと

　論理的思考を鍛えるのに、一番よい方法は気楽になることです。気楽になれば、自分の弱点も素直に受け入れて、どうやったら、あたらしい方法に気づけるかということをゲーム感覚で考えられるようになります。　逆に、「私はこれだけ勉強しているんだから、これが出来ないとおかしい」などど、先に無理やり結果を定義してしまって、ある種の根拠なきプライドを持ってしまうと、自分の弱点が心理的な盲点になってしまいますから、これは、一番の逆効果です。

　そして、目的を持つことが大事です。何かを勉強するときには、目的がないとやはりやる気になれません。しかし、目的の達成をあまりにシビアにとらえすぎると、副作用で「できなければ終わりだ」的な「無理やりな結果の脳内定義」が行動や思考より先に発生してしまうので、リラックスが必要です。

　真剣に目的を持つこととリラックスする事は相反することなのですが、この2つの要素を頭の中に同居させることが、調査能力や分析能力をつける上で必要です。

■まわりの人の心理的盲点をマーケティングに活用しよう

　世の中は、自分も含めて「頭ではわかってはいるけど、実際は違う」というようなことばかりです。これは、やはり、根本的な人間の性質からくることだと思います。むしろ、できないことのほうが普通なのです。そういう意味では、人間は、まだまだ動物なのです。

　ですから、調査、分析能力に関しては、何か一つでも克服して周りの人が気付けないようなことに気付けるようになれば、それは非常に大きな進歩です。この、気付きが重要です。調査・分析で結果を出すということを、より、感覚的に分かりやすい言葉で表現するならば、それは、「気付く」という言葉になります。

　気付くというのは、勉強や知識を得る系のキーワードの中では一番ハードルが高く、一番高価が大きいものではないでしょうか？「売り方に気付く」「売れるものが何か気付く」、これだけでも非常に大きな前身があり、起業に具体的に結びつくものです。　そして、周りの人が気付いていないけれど、自分は気付いているという情報を蓄積していけば、それは、確実に売れる商品に結び付いていきます。

　きっと、われわれのまわりにはいろいろな起業のネタが本当はあるのです。多くの人が気付いていないだけです。どうやったら、そういうネタをキャッチできる脳みそ自分の中に育成できるか考えるのもなかなか夢のある話だと思いませんか？

　皆さんは、システムを開発したときに、そのシステムのパフォーマンスをきちんと計測してチューニングしていますか？ 筆者は最近、この部分にかなりこだわっています。

　やはり、ソフトウェアのパフォーマンスは非常に重要です。筆者が扱っているソフトウェアは物流やECサイト関連のソフトウェアなのですが、やはり、この分野はソフトウェアの処理速度は非常に重要です。

■Javaを選んだ理由

　筆者は、開発には主にJavaを利用しています。もっと言うと、Java上で動く、Webとデータベースに特化した「Alinous-Core」というドメイン特化型開発言語で開発しています。言語も、自分用ですが、開発環境もEclipseベースで自分で作って、最近はかなり快適に開発ができています。

　Javaは、とても良くできた言語です。どういう視点で良くできているかというと、言語とVMの仕様がソフトウェアの検証をとてもやりやすくしています。特に、継続的な開発をする場合、どの部分を変更したら、どの部分が変更が必要かを、エラーなどで教えてくれます。　また、JDK 6 Update 7以上に含まれる管理ツール「Visual VM」を利用することによって、動いているJavaのVMの中の状態を検証でき、非常に重宝します。

■Javaは、コードを増やすより「成果物を評価するための言語」

　海外でJavaの人気が非常に高いのは、このように、作成したソフトウェアを継続的に検証する仕組みがあるからと筆者は考えます。海外では、テストエンジニアの単価が一番高く、開発者よりも上だったりするので、エンジニアの評価基準が、「作れること」よりも「作ったものを検証できること」の方が圧倒的に優勢なのです（※1）。

　本音を言ってしまえば、自分でどう動くか理解できていないプログラムに価値があるかと言えば疑問です。日本でも、作業量よりもアウトプットの評価に対してきちんと社会的に評価してもらえる基盤ができてほしいものだと切に思います。

（※1）
・シリコンバレーのプログラマー（Programmer）のサラリー指標（Salary index）http://www.indeed.com/salary?q1=programmer&l1=Silicon+Valley%2C+CA
→昔（2011年4月ころ）は高かったが、今は下落傾向。

・シリコンバレーのテストエンジニア（Test Engineer）のサラリー指標http://www.indeed.com/salary/q-Test-Engineer-l-Silicon-Valley,-CA.html
→昔（2011年4月ころ）から上昇傾向。今後はもっと高くなるだろう。

■VMの中身をのぞいてみよう

　したの写真は、実際に筆者がパフォーマンスの検証で使っているものの一部分です。

　どのメソッド（関数）がどのくらいの割合で実行されているか分かるため、ボトルネックがすぐ分かります。これは、とても重要なことです。ボトルネックが分からない状態で、勘でパフォーマンスアップをさせるのは、やはり限界があります。

　この例は、スレッドの並列処理のパフォーマンスチェックを行っている部分です。キューを処理してスレッドプールに待機しているスレッドを起動（launch）したり、処理が終わったものを待機させたりする部分と、実行している部分の比率を見ることで、並列実行の有効性を確認しています。

■自分の言語も「検証重視」で作る

　筆者は、自分でも開発環境を作っているのですが、やはり、実務で使って一番うれしいのは、ソフトウェアの検証をするのが楽になることです。検証がしっかりできていれば、不安な気持ちや暗い気持ちになることがありません。　やはり、自分が作った成果が自分に返ってくる場合には、この「検証」の価値がとてもよく分かります。

　しかし、ソフトウェアは、もともと形がとらえにくいものですが、「検証する」こと、さらに形をとらえにくいものです。SIビジネスになると、検証に対価が発生したりするかどうかという話になり、「分からない人に分かってもらう」という不可能なタスクが生まれます。

　そうならないように考えて、エンドユーザーに理解できる形のパッケージソフトウェアを販売する会社を思いついたのですが、自分としては、今の自分の本業は、「開発効率化のためのツール開発」だと思っています。　今後も、ソフトウェアの開発効率だけではなく、検証力に力を入れて開発をしていこうと思います。

　クラウドというのは、もともとはインフラの話だと思うのですが、最近では一人歩きしてソフトウェアの機能提供などの意味も含んできています。なぜそうなるのかというと、それはそれだけ期待も大きく、さらに、実際にも非常に威力があるからだと考えられます。

■少数精鋭の限界をクラウドがカバー

　今まで、設備投資がいらないIT業界といえども、大規模なソフトウェアは少人数では無理で、ある程度大きな組織が必要だとされてきました。しかし、これは、過去の話になりつつあります。特に、クラウドが存在しないときには、インフラの保守コストが非常に大きく、人が24時間監視していなければサーバが落ちたときに対応できないなどのリスクがあり、大規模な会社でなければ大規模なソフトウェアは作れないと思われてきました。しかし、クラウドでは、アマゾンのAWSなどのクラウド提供会社がインフラの監視などを代わりに行ってくれます。

　また、ネットワーク構成を変えたり、サーバを新しく調達する作業などがブラウザやコマンドで行えてしまうので、かなりの構成を短時間に組めてしまいます。そうすると、サーバが万が一落ちたときに、人間が行う復旧作業をクラウドに組んでおけば、人間がはりついて監視しているのとほぼ同じだけの運用ができてしまいます。

■クラウドだけではカバーできない残りの部分は？

　クラウドだけでカバーできない残りの部分は、

• ソフトウェアのテスト
• クラウドだけではできないデータベース負荷分散対策

の2つです。

■テストはテスト自動化ツールが有効

　テストに関しては、テスト自動化ツールが本当に有効です。テスト作業がプログラムとして蓄積されていき、好きなタイミングでボタン一つでテストを実行してくれるので、品質保証にとても役に立ちます。実際に、筆者の自社プロダクトでも、非常に大規模なソフトウェアなのですが、データベースの仕様が変わるような大きな変更があっても、ボタン一つでテストができるため、変更に関わる対応を見逃した部分がすぐに分かります。

　テスト自動化がないと、この辺を人力でやっていたらどうなるのだろうと、本当に恐ろしくなります。

■データベース負荷分散対策

　データベースに関しては、データが一元管理されていないといけないので、Webのフロントのエンジンのように、負荷が増えたらどんどんサーバを増やしていけばパフォーマンスが上がるというわけにはいきません。このようなときには、データベースのテーブルをネットワーク上に分散させることによって負荷分散が可能です。MySQLのストレージエンジンのようなアーキテクチャをとっていれば、負荷分散がしやすくなります。

　今、筆者が非常に注目しているのは、PostgreSQLの9.1以降で実装されている「外部データラッパー」と言う機能です。この機能は、データベースエンジンで、他のサーバになるテーブルをローカルなテーブルと同様に扱える機能です。この機能があれば、特別アクセスが多いテーブルを外部の高性能サーバに移すことでボトルネックを解消できます。

　また、複数台でレプリケーションを組んでおけば、データの移行もスムーズになります。レプリケーションと外部データラッパーを組み合わせた負荷対策の運用が今後はメジャーになっていくのではないかと思っています。

■究極的には一人でエンタープライズシステムが管理できるかも

　このような新しい技術がどんどん出てきて、さらに、ツールが進化してくれば、将来は一人でさまざまなシステムを管理できる時代がくるかもしれません。

　昔、グーグルが「検索エンジンの結果に人の手は介さない」と言ったことを今でもよく覚えていますが、当時は「さすがに無理だろう」と思っていました。でも、今になって、人ではなくサーチエンジンが自動で検索結果を作成するのが主流になっています。

　技術の進化とは恐ろしいものです。

　自分は、もともとは、大規模開発に関わるSEでした。そして、ソフトウェアをチームで開発する時には、必ず会議が必要になります。

　もう、10年近くも前のことなので、時効だと思い、打ち明けてしまいますが、会議のたびにいつも思っていました。「これ、11人とか2人で作った方が早くできるのではないか？」と。

■会議が無駄過ぎる

　とにかく、会議というものが無駄の塊でした。それぞれが、連携の仕方についての議論をして、それで各役割などを決め、持ち帰って検証して、また会議にかけます。この繰り返しです。

　当然、毎回、議論をしていくわけですが、全体を把握している人がいないので、前回決まったことがどんどんまたひっくり返り、また、元に戻っていくわけです。

■会議から生まれる無駄

　毎回ころころ仕様が変わることによってものすごい無駄が生まれます。皆さんもご存じのとおり一度作成したソフトウェアの仕様が変わる度に再テストです。しかも、「これ、またテストしてもまた変わるんだろうなあ」と思いながらの再開発は、本当に苦痛でした。

　それならば、「テストは仕様が決まってからにすればよいではないか」と思うかもしれませんが、進捗管理上、根拠のないスケジュールが敷かれているのでやらないわけにはいかないのです。

■理想は会議がいらない人数での開発

　この時から思っていたのですが、理想は、会議が必要ない人数での開発だと思っていました。そうすることによって、無駄な繰り返しが少なくなります。分からないことが発生しても、次の会議までまとめる必要もなく、その場で聞けばいいですし、一人が把握している部分が大きくなるので、全体が把握しやすくなります。

　しかし、人数が少ないと人海戦術が行えなくなるというデメリットもありますので、そこを補わなくてはいけません。

■コードを書くのに人海戦術はいらないがテストに工夫が必要

　人海戦術が必要なのは、ソフトウェアのテストの部分です。コードを書く部分は人海戦術は必要ありません。

　自分の例になってしまいますが、自分が開発したAlinous-Coreは、本体のサーバもeclipseプラグインとしての部分も自分一人で開発をしていますし、Alinous-Coreで開発したECサイト構築から配送センター業務まで対応している大規模ソフトウェアも、零細企業である弊社だけで作りました。

　ただし、これらのソフトウェアを作る上での大きな壁が一つありました。それは、ソフトウェアテストです。こればっかりは、手動で行っていたら人海戦術が必要になります。

　しかし、近年は、seleniumという自動テスト化支援ソフトウェアがあり、ブラウザを意のままに操れるので非常にテストが自動化しやすく、大変に重宝しています。これがなければ、今の開発はできていないと思うくらい役に立っています。

■一度作っておくと楽

　seleniumで筆者はJavaでテストプログラムを書いています。最初は、本当に大変で面倒くさくて心が折れそうになりましたが、コツをつかむととてもスムーズです。

　特に、大規模ソフトウェアの場合、データベースの中の状態で、再現できる事象が違うため、その状態をボタン一発で作ってくれるというメリットは本当に大きいです。大規模になると、昔自分で作ったプログラムの仕様を時々忘れてしまうので、たまには自分でチェックのために手動で使いやすさなどをチェックする事も大事です。

　seleniumでソフトウェアを書くときのコツは、各機能ごとの画面の流れについて、ライブラリを丁寧に一度作ってしまうことです。

　例えば、筆者のソフトウェアの場合、配送センターへの入庫の機能があったら、そこに登場する画面操作に対して一式のライブラリをセットで作ってしまうことです。

　そうすることによって、後でテストするときは、テストケースでそのライブラリを呼び出すだけで様々な業務パターンが検証でき、画面を変更した時にも、ライブラリの共通部分を直せば、他のテストケースもスムーズに動くようになります。

■これからはクラウドの時代

　今後、クラウドというインフラがどんどん普及していくと、どんどん、大規模なハードウェアなども必要なくなり、われわれのような零細企業も大規模ソフトウェアのビジネスを行うチャンスが大いに出てきます。

　そんな中、自分が注目しているのは、PostgreSQLの外部データラッパと言う機能です。この機能では、データベースのテーブルを、テーブルごとにネットワーク上の他のサーバ上のリソースに分散できます。更新系がまだのようですが、これも近い将来できるようになる可能性が高いです。

　クラウドを利用すれば、簡単にサーバが用意できますから、パフォーマンス面でのスケーラビリティをサーバ構成で容易に出すことができます。

　これからの大規模開発がどうなっていくか、非常に楽しみです。

　ですから、勉強をあまりしなくていいように考えて作ったのですが、かえって、それを作るのにたくさん勉強や作業をことになってしまいました。

　結論から言えば、勉強する総量を減らすためにフレームワークや開発言語を作るわけですが、それには最初にまとまった時間と作業の投資が必要です。

　でも、最終的にはいろいろ時間と作業を投資して良かったと思っています。筆者の場合は言語を自作する場合には、次のことが主なハードルになりました。

■「ドメイン特化型言語」を作るハードル

　自分にとっては、オブジェクト指向はすごく複雑で、なかなか馴染めませんでした（といいつつも、Alinous-Core本体やEclipseのエディタやデバッガなどはオブジェクト思考で書かれています）。

　そもそも、やることが多いのです。いろんなBeanを作るのが面倒だったり、あとで変更がやりにくくなったり、動的なものを作るのに特別な工夫が必要だったりします。むしろ、普通にWeb-DBアプリケーションを開発する上では、そういう工夫から解き放たれたいと思うことがとても多かったのを覚えています。

　また、自分にしか分からないような、複雑な仕様にしても分かりにくいので、JavaScriptとSQLとHTMLさえ分かれば、あとは適当に書ける言語を目指しました。

　が、しかし、このためにとんでもなく勉強や作業をすることになってしまいました。HTMLは、普通にHTMLなのでいいのですが、JavaScriptとSQLという性質の違う言語が同じスクリプト上に出てくると、普通にコンパイラ生成用のJavaCCを使うだけでなく、一部、JavaCCの中身も変えないといけなくなりました。

■チューニング系の自動化のハードル

　よく、JavaでJDBCを利用してSQLを発行すると、プリコンパイルして実行するか、普通にSQLを発行して実行するかで書くコードが違うのが面倒だと思っていました。また、データベースのコネクションなどは、フレームワークでうまく書かれていると、とじ忘れなどがないように考えなくてよいのですが、むしろ、コネクションなどという存在を忘れ去ってしまいたいと思っていました。

　が、しかし、これもまた大変で、コネクションプールとセットでプリコンパイルしたオブジェクトを管理し、自分で書いたコンパイラでコンパイルしたSQLから判別してプリコンパイルでやれるかどうか判断したり大変です。

　特に、この部分はコケてしまうとサーバが止まってしまうこともあるので、テストがとても大変でしたが、ソフトウェアテストの基礎知識が非常に豊かになります。

■結局、苦労するんだから最初にやってしまおう

　何事もそうですが、結局、サボろうとすると勉強するハメになります。勉強してみて分かったのですが、本当に楽をしようと思ったら基礎的なことを勉強するハメになります。

　しかし、基礎的なことはどこでも使え、一度身につけてしまえば一生ものですから、勉強や苦労の総量はかなり減るというのは確実です。

■Alinous-Coreの今後は

　Alinous-Coreは、今後もメンテナンスしていこうと考えています。本業のECサイト構築パッケージもこれで作られていますので、本業のソフトウェアの成長とともに必要な機能が付加されてどんどん良いものになってきています。

　今後の一大テーマとしては、本業で受注、出荷や顧客に関するビッグデータを扱うことがあると思いますので、メインで使っているPostgreSQL 9.2以降の機能に併走する形で並列実行などの機能を簡単に使えるようにしていこうと思っています。

　これらも、一度作ってしまえば、後々楽ができるので、どこかのタイミングで気合を入れて実装する予定です。

　一般論として、MBAを取るようなビジネスエリートと、自分で小さなところからビジネスを始めてそこから1つ1つ売上を立てて頑張っている叩き上げの事業家はソリが合わないことが多いと思います。しかし、これはごく自然なことだと思います。そして、どちらが優れているとか劣っているとかそういう問題でもありません。なぜならば、基本になる考え方が違うからです。

■共通点としては、どちらも厳しい「第三者評価」を乗り越えてきている

　まず、1つ言えることは、2者とも共通点はあるということです。どちらも、厳しく、第三者的な評価は受けています。その過程は、どちらも同じくらい厳しいのではないでしょうか。

　僕は、ビジネスエリートではないのですが、本当にエリートの人は優秀だと思います。特に、プレゼンテーションや議論などは、周りをあっと言わせるような雰囲気を作れて、うらやましいです。ここまでやるには、生半可に練習するのではなく、自分の仕事として本気で取り組むような努力をしないとだめだろうなあと思ってしまいます。

　一方、マンションの一室からスタートして、気が付いたら自社プロダクトを持って、そのプロダクトに出資を受けてどんどん規模を拡大するソフトウェアメーカーも世の中にあります。自分もソフトウェアメーカーのはしくれなので、自分でソフトウェアを作って、売れるように機能やマーケティング戦略を考える大変さは、本当に身に染みてよく分かります。

　両者を見ていて、どちらも成功している人はすごいと思います。自分も見習わなくてはならない点がたくさんあり、それに気付こうと、日々頑張っています。

■違いは、「結果の評価され方」から

　両者の違いは、筆者は、結果の評価され方にあるのではないかと思います。まず、1つ目の違いとして、「誰に評価されるのか」という点がです。

　エリートと呼ばれる人は、教員やコンテストの審査員などの人に評価されます。一方、叩き上げの事業家は、実際にお金を払ってくれるお客さんから評価されます。

　この違いは大変に大きいです。エリート側の人は、すでに「誰に評価されるか」が決まっていますが、叩き上げ側の人たちは、「評価してもらえるかどうか」というところから始まります。ですから、特徴として、エリート側の人たちは、「誰にでも分かりやすく」という長所があり、短所としては、「浅く広すぎて、現実にお金を払うターゲットからみると魅力が物足りない」というものがあります。

　一方、叩き上げ側の人たちは、「ターゲット顧客に絞り込んで、他にない魅力を若干マニアックに伝え、お金を払ってもらえるレベルの魅力を伝える」ということが得意です。一方、短所としては、「一般には受けない」ということです。

■目標設定と期間にも違いがある

　目標設定も違います。エリート側の人たちは、短期間に優れた結論を出すことが求められます。そして、短期間に結果を出すためには、「今知っていること」の比重を大きくして結論を導くような思考パターンになっていきます。そして、結果の評価は、実際に入ってくるお金とは、（叩き上げ側と比べれば）あまりリンクしていません。

　一方、叩き上げ側の人たちは、売上が上がることが目標であり評価です。そして、極端な短期間で成果を挙げることは求められていません。そのかわり、正しい試行錯誤ができなければタイムオーバーになってしまいます。

　ですから、正しく経験から学べることを受け止め、次の学べる経験を選択し、試行錯誤を続けながら結論に向かっていきます。そのため、即座には結論を出さず、物事の評価を1つ1つ実験で確かめていくという思考パターンになります。

　このように、2者は正反対の思考パターンを持っているので、お互いが厳しい評価をクリアしているという自信から、お互い譲らなくなってしまうと、本当にソリがあわなくなってしまいます。

■叩き上げがエリートを見習うべきところ

　筆者は、「起業する」「新しいビジネスを立ち上げる」という観点からすれば、やはり、叩き上げ側の人たちに分があるとおもいます。ただし、エリートの方々から見習うところがあります。

　それは、インターネットを利用して情報を広く伝搬させたいときに、もうちょっと、ターゲットをゆるめて一般の人にも分かりやすい表現を使うという手段も併せ持つということです。そうすることによって、より、特化したターゲットに確実に魅力を売り込むという機会も増えます。

■最後に

　自分も、今、ECサイト構築と通信販売向け物流のソフトウェアのHPをいろいろと工夫しながら作っていますが、分かりやすい表現ができる人が本当にうらやましいと思うこのごろです。

　日々、いろいろと事業の戦略などについて考えているのですが、それらについても今後、続けて書いていこうと思います。

　その中で、「独立という意味で」近いのが、フリーランスと起業家という2つのスタイルだと思います。

　このスタイルは、実際にやってみると、実は、現場系リーダーが得意だというような技術者にすごく向いているスタイルで、やっていることも、技術者として難しい問題を解決しているときと非常に似ていると感じるこのごろです。

前回の記事「技術者が起業時の営業をWebでうまいことなんとかする方法」の結論になぜ筆者が至ったか、その経緯を今回は書こうと思います。

■コネあり起業とコネなし起業を同一に見てはいけない

　コネがあって、もうすでに、最初に営業やマーケティングをしなくても仕事があって、自分自身でビジネスを作り出さなくていい場合と、自分自身でビジネスを作り出さなくてはいけない場合では、まったくルールが違います。

　今回は、コネなしのゼロからビジネスを作ることを前提とした内容で書きます。

　また、コネあり起業が悪いわけでもなく、起業は有利にできたほうがいいので、コネは最大限活用すべきだと思います。

　ただ、ベースがしっかりしていたら、今度は「さらに飛躍するぞ」と考えると思うので、そのときにはコネなし起業と同様に、自力でビジネスを作らなくてはいけません。

■コネなし起業家候補が起業に踏み出せない原因は「思い込み」が多い

　「安定なんてどこにもないこんなご時世だし、将来的には自力で立つのが一番の安定だ」と思いつつ、情報収集なども一生懸命やり、それでも、つい、行動に起こすのが延期になってしまう方も多いのではないでしょうか。

　また、フリーランスの方で、営業を自分でもなんとかしたいと思い悩みつつも、つい、人任せになってしまう方も多いのではないでしょうか？

　そういう方は、なぜ、そうなってしまうのかと考えることをお勧めします。

　なぜ、そうなってしまうか？

　それは、独立して仕事を取ってきて、仕事をこなし収益を上げ、次につなげるというサイクルの中の仕事をとってくるという部分で、何から始めたらよいか分からないという理由がほとんどだと思います。

■「仕事をとる」のではなく、「欲しいものをを提供する」という視点

　「仕事をとる」という言葉は、あまりIT業界では適していない言い方かもしれません。

　なぜならば、商品やサービスの魅力などはともかくとして、情熱とごり押しでなんとか仕事を発注してもらうというスタンスがイメージとして思い浮かぶからです。

　しかし、この方法は次の2つの問題があります。

• 営業にコストがかかりすぎて、制作や開発・サポートへの予算が極端に少なくなる
• 発注してもらえる可能性が低い

ということです。

　「ここさえうまくいけば、他は全部うまくいく」というポイントではこの方法は有効だと思いますが、そういう機会自体が少ないのと、「安定する」という目標を考えるならばこれ以外の方法も用意すべきです。

　そして、この仕事をとるという部分のイメージがどうしても、このようなコストのかかる営業方法だと思い込んでしまうとどうしても、最初の一歩が踏み出せないという理由にもなっているケースが多いのではないかと思います。

■「情報伝搬」と「商品の魅力」のバランスを考える

　ベースが技術者で、営業経験がない方は、どうしても、「情報伝搬」と「商品の魅力」のどちらがどれだけビジネスに貢献するかという部分で、「隣の芝生は青く見える」式の考え方をしてしまうと、「情報伝搬さえできればうまくいくけれど、それができないからビジネスをスタートできない」と考えることがほとんどです。

　しかし、筆者もそうなのですが、実は、技術者の思い込みバグで最も致命的で早く解決しなくてはいけないものは、まさにこれだったりします。

■「営業の限界」を検証することでバグに気付く

　営業を本職にしている人の感覚とその限界を知ることで、実は、この「情報伝搬」と「商品の魅力」のバランスに気付けます。

　いくら、（商品の魅力が関係ない部分の）営業力があるからといって、営業マンは必ず商品を本気になれば売ってくるかというと、やっぱり売れません。

　しかし、商品が良ければ営業マンは特別な販売技術がなくても売れ、そういうスタイルで成功している会社はあるわけですから、「情報伝搬」は方法を知っているかどうかの問題であり、技術者の上流工程の技術や設計技術のような一朝一夕ではなかなか身に付かないスキルが必要ではないことが分かります。

■考えるより「やってみよう」

　自分の場合は、「やりさえすれば、取りあえずの目的を達成できるけれどどうしたらよいか分からない」という場合は、とにかく、今まで「これはダメだ」と勝手に決めつけて行わなかったことを積極的にやってみました。

　今まで自分が間違った常識を勝手に作って「ダメだ」と決めつけてきたことを挙げてみます。

• 自社Webから問い合わせは来ないと思っていた
• 企業のお問い合わせフォームは見ていないと思っていた
• プレスリリースを出しても小さな会社では意味がないと思っていた
• 自分の商品に関してサーチエンジン経由でHPに問い合わせが来ないと思っていた
• 小さな会社に中規模以上の案件を発注するところはないと考えていた

　これらは、全部根拠がないことです。

　「小さな会社に中規模以上の案件を発注するところはない」というものでさえ、これも思い込みです。他の人ができないようなことをしなければいけませんが、工夫によっていくらでも、どうにでもなります。

　弊社の場合、特に功を奏したのは、自社webの作成とプレスリリース、そしてサーチエンジン対策でした、これにより、きちんと問い合わせをもらえる状態まで持ち込めました。

　また、企業のお問い合わせフォームへの投稿も、きちんと相手側の状態を考えて提案をすれば、「会えるべき人にはきちんと会える」ということも分かってきました。

■「情報の伝搬力」の射程距離は「提案力」で決まる

　情報を伝搬させる」ということは、自社ができる提案能力、すなわち、商品の魅力と柔軟性でリーチが決まってくるということが理解できるようになりました。

　「技術者の価値は変化への対応力で決まる」と筆者は書き続けていますが、変化をとらえることによって、誰もまだリーチしていないニッチなマーケティングを発見でき、技術的対応力で競合他社が入ってこれない領域での商品をつくれれば、営業は自然と仕組みができてきます。

　技術者が起業するには、やっぱり、技術を使った商品と提案がすべてです。情報伝搬にいろいろとコストをかける前に、他社で売れているものがどのくらい営業にコストをかけているか具体的に調査をして、本当に「情報伝搬より売り物勝負」という実感を持って、そこに集中できれば起業はわりと高い確率で成功できると思います。

　今回は、どのようにすれば、この営業に関してどうにかなるかを、自社商品を作って起業をしようとしている技術者視点で検証してみようと思います。

■営業に困るのは技術者だけではない

　実は、なにを隠そう、営業で困っているのは技術者だけではないのです。むしろ、大手の営業も困っています。

　とくに、すでにパイプがある大口顧客や資本関係のある顧客がいる場合、そのような顧客に対してアプローチをするのはたしかに大手や中堅企業の場合は非常に有利です。しかし、その企業の営業の方の視点に立つと、社内では「ちゃんと新規の顧客もとってきてくれ」というふうにプレッシャーをかけられて困っていることが非常に多いのです。

　「となりの芝生は青く見える」とはよくいったもので、筆者も以前は、「営業は売るスキルがあって、本当にうらやましい」と思っていましたが、よくよく考えてみると、営業の立場に立つと、「技術者は商品が売れないものの場合、どうやったら売れるか分かれば対策を打てるから羨ましい」と思うものです。

■売れないものはやっぱり売れない

　今の時代、売れないものはやっぱり売れないのです。そして、筆者がよくいう「売れないものを売ってくるのが営業だ」というのは、半分当たっていて、半分間違っています。

　正しくいうならば、「売れなさそうなものを売ってくるのが営業だ」となります。

　この、「売れない」というのと「売れなさそう」はまったく違います。「売れなさそう」というのは、販売をする方から見た時の視点で「売れなさそう」であって、商品を買う顧客から見たら「欲しいもの」なのです。

　「売れない」というのは、商品を買う立場の人から見て欲しくないものです。なので、売る立場の人間が、「これは売れる」と思って販促にものすごいコストと時間を費やして、たくさん人が集まり、「これは売れるに違いない！」と思っても、集客した顧客が商品は欲しくなくて、おまけの情報提供や名刺交換の機会が欲しいだけの場合は、やっぱり売れません。

　営業や販売の経験が少ないうちは、「人が集まる」＝「売れる」と勘違いしてしまうことが多いのですが、それは、本来の販売とは別の要因で集まっているケースがかなり多いです。商品が「お金を払ってまで欲しい」と思ってくれる人以外は、余程の理由がなければ購入にはいたりません。

■営業がうまいひとたちが力を入れているポイント

　IT業界に限らず、販売がとてもうまい人というのが世の中にいます。もし、出会ったことがなければ、硬派な異業種交流会などに行ってみればすぐに出会えるでしょう。

　そのような人は、「技術者が苦手な販促活動」がすごくうまいのかと、技術者で営業経験がない人は思うかもしれませんが、実はそうではありません。どちらかといえばというよりも、完全に商品を発掘したり仕入れをする方に力を入れています。

　彼らが欲しがる商品は、次の条件を満たすものです。

• 商品にライバルがいないもの
• 圧倒的に良いもの
• 価格が顧客の予算内で費用対効果で競合より安く、なるべく高いもの

　このような商品を発掘するための情報収集を日々、血眼で行っているのです。

　なぜならば、売れる商品は他の営業のライバルも欲しがるので、簡単に見つかるものではないからです。そして、彼らがどのように商品を探しているかを分析すれば、そういう方に出会うのは簡単です。

■営業のプロの行動パターンとインターネットの影響

　営業のプロの方は、市場調査、とくにマーケティングに力を入れています。情報発信力は、今の時代、インターネットのせいであまり差がつかなくなっていためです。

　販売は、ライバルとの競争です。だから、今すでに売れているものでは今の時代、なかなか販売できません。そのためには、「先見性」をもって、時代の変化と共に需要がどのように変化し、まだ、新しく現れた需要のどの部分を競合がアプローチできていないかを必死で見極めるのです。

　この見極めには、扱う商品に関する非常に濃厚な現場レベルの知識が必要になります。

　つまり、「薄く広くなんでも売ります」というスタンスでは、市場に現れた新しい需用にリーチできません。

　だから、業界知識がない人から見ると、そういう商品は「売れそうにない商品」であり、それを売ってくる人を実際に見ると、からくりをしらない人から見ると「売れないものを売ってくるのが営業だ」ということになる。

　そして、「できる営業系の人は新しものが好きだ」というのもこのあたりの行動原理から来ている。

■起業家の営業を強力にサポートしてくれる方はこういう人

　技術系の起業家にとって、最も必要な活動はR&D(Research and Development)である。そして、「売れる商品」を作るための市場調査をし、それをリアルに作ることがミッションだ。

　R&Dの起業家も営業の方と同じように、時代背景や最新の情報収集も日々行う必要がある。そうでなければ売れないものを作ってしまう可能性がある。

　では、営業の人に何を期待すればいいのか？

　それは、情報収集です。R&Dのチームは、開発のウェイトがやはり高いので情報収集に費やす時間はどうしても開発作業の分減ってしまいます。そして、この情報収集は、やってやり過ぎることはありません。

　これは個人的な意見ですが、IT企業が売上の棒線のグラフを書いて営業同士競わせるというのは、もう時代遅れだと思います。

　「売上」というのは、「売れるもの」を作れば自然に達成できるものであり、それを作るのはR&Dチームと営業チームの共同作業で成し得た結果であり、売れないのは営業のせいではありません。営業のせいにするのは単なる責任転嫁です。

　技術力が他社より圧倒的に優れている技術者が中心の企業であれば、一番大変なのは「売れるもの」が何なのかを見極め、情報収集で裏付けを取る部分であり、この部分で協力できないようであれば、新しいビジネスの開拓に挑戦することは不可能です。

■技術起業家は自社サイトとその内容に力を入れよう

　技術系で営業マンといわれる人もいないまま起業する場合には、自社サイトが非常に大事になってきます。

　そして、ここで非常に大事なのは、「誰に読んで欲しいか？」です。それがきちんと固まれば、ぶれることがなくなってくるはずです。筆者が考えるに、

• エンドユーザー
• 商品を探している営業担当者

をターゲットにすればいいと思います。

　これらは、「顧客」と「パートナー」という位置付けですが、「パートナー」に関しては、実際に「売ってくる営業」「新規開拓を本気に考えている営業」を対象にすれば、実は自社サイトでアピールする内容は、どちらも同じようになってくるのです。

　作る内容としては、以下のものが重要になります。

1. 時代の変化によって必要になってきたことや発生する問題への共感
2. 問題への対応をしているということ
3. ダウンロード形式の資料請求フォーム

　最も重要なのは、時代が変化したからこそ起きている問題に対して、きちんと認識していますという内容が非常に大事です。

　なぜならば、この問題に関して、自社サイトにアクセスしてくれている顧客側の視点に立つと、唯一もしくは数少ない解決策の1つになっている可能性が高いからです。

　そういう状況では、資料請求をしてくれる可能性も高く、そして、資料請求をしてくれた顧客に対してアプローチをすれば、話ができる機会を作れる可能性も高くなります。

　そして、その顧客との接触こそが最高の情報収集になります。

■集客ははじめは広めのターゲットで

　「集客のターゲットをどこにするか？」というのも実は重要な問題だが、これは、考えるよりも実際にやってみるのがいいでしょう。

　一番にやってはいけないことは、「わたしの仮説は正しい！なぜならば、これで人がたくさん集まるからだ」といって、実際の顧客がどのような人や企業になるのかを検証されていない段階でターゲットを絞りすぎてしまうことです。

　これをやってしまうと、ターゲットが外れた場合、商品の購入にはまったく関係なく、その他の理由で集まる人ばかりになってしまいます。そして、ターゲットというのはIT商品の場合には企業規模や業種など点在しており、一発で当てるのはかなり難しいので大抵の場合は外してしまうことが多いです。

　初期の段階では、検索エンジンなどの、現在検証対象のターゲットで商品に興味がありそうな人がわりと幅広く来てくれるものを選ぶべきです。

　そこから、実験しながら費用対効果が良いものに絞ったりしていくことが重要です。

　自社サイトの宣伝に関しては、特化した内容に関してテキストで多めに書いておき、今の時代、プレスリリースのようなサービスで1万円くらいのものがたくさんありますから、そのようなサービスを利用すれば、外部リンクを多く獲得でき、初期のseoで問い合わせが来るレベルまで持っていくことが可能です（自社で検証済み）。

　また、それだけでは、こころもとないという場合には、キーワード広告や、自社のサービスに特化したメディアなどを利用してみると効率が良くなります。

■情報収集をする機会が作れるかどうかが鍵

　起業における「営業力」という課題に関しては、この、「情報収集」が非常に重要であり、問題の本質になります。情報収集がきちんとできていれば、技術者の場合は、商品は作れるわけですから、わりとなんとかなるものです。

　何かITで商品を持って起業しようと考えている方は、作る前もしくは作りながら、「どのように情報収集し、売れる方向にもっていくか」という事業計画の柱の部分を計算しながら作業をすすめると、かなり具体的なイメージが湧いてくるでしょう。

　この現実を覆すためには、まずは、自分が立っている土俵について認識し、その前提を覆すという思考が必要です。

■お金は古代から今まで続く強固な仮想化

　人類が誕生した当初にお金があったかというと、なかったと思います。当時は、自給自足から始まり、そして、物々交換という「価値」の交換が誕生します。

　そして、物々交換の不便さを解消するためにお金というシステムが生まれました。

　お金というのは、人間が作ったものです。いわゆる、価値の象徴であるものです。

　しかし、お金は食べられませんし、お金がシステムを作ってくれるわけでもありません。お金は労働力や物などの「実体」に変換することによって初めて価値を発揮します。

　オープンソース化されたソフトウェアは、「無料」という感覚があると思いますが、「無価値」ではありません。よって、価値あるものが生産されるわけですから、オープンソースコミュニティの活動は経済活動だといえると思います。

　また、すべての経済活動は、「価値交換」という原動力が必要です。

　ただし、「価値交換」はお金中心の資本主義だけではありません。そこに注目することで、どこにオープンソースで儲けられるポイントが見えてくると思います。

■オープンソースコミュニティの起源はお金か？

　今、Apache財団やPostgreSQLのユーザーグループなどがきちんと運営されているのを目にしていて、出版などでの資本がからむ経済活動をおこなっていますが、果たして、最初からそうだったのかというと、そうではないと思います。

　オープンソースの起源とは、お金以外の価値で立ち上がったものがほとんどだと思います。

　何でもそうですが、オープンソースの起源も、1人の人から始まります。最初の技術者が、とても困った問題があって、途中までソフトウェアを作りますが、その後に関して成長させたり完成させたりするのに困ります。

　そうしたときに、同じ問題を抱えている次の技術者が、そのソフトウェアを一緒に作る活動に参加します。

　その繰り返しで、どんどんコミュニティが大きくなっていきます。Linuxなどもそのような感じで大きくなったのでしょう。

　ここでは、技術者はまだ、お金をもらって作業をしているわけではなく、それぞれが「解決したい問題」を持っていて、それを解決できるという「価値」が彼らを動かす原動力になっています。

　つまり、金融システムとはまったく関係なく、物々交換に近いような価値交換が原動力となってオープンソースコミュニティは動いているわけです。

■ガラケー向けオープンソースプロダクトがあまり出なかったのが不思議

　日本のオープンソースをとりまく環境は非常に特殊だと思います。海外では、オープンソースを普及させるインフラがあるのですが、日本ではなかなか面白いものがあっても最初の段階で頓挫することが多いと思います。

　また、後述しますが、「最初が厳しいからあえて最初は資本主義に対して妥協する」という選択肢をとってしまった場合には、さまざまな利害関係から本質的な部分に向き合えなくなる危険性があるため、最初のコミュニティの非資本主義的な原動力が維持できなくなる可能性が高くなります。

　今は、スマートフォンにかなりの実効ユーザーが移行しているため、どちらかというとスマートフォン同士の互換性の問題がすり変わってきていますが、当時のガラ携の互換性問題は非常にやっかいな問題だったでしょう。

　しかし、PHPやJavaなどの言語にニュートラルな互換性を担保するプロキシサーバのオープンソースコミュニティで活発なものは筆者が知る限りでは見かけません。

　これは、オープンソースコミュニティを、非資本主義的なアプローチでコミュニティの自由を担保しながらも支援するというビジネスモデル、すなわち、オープンソースの情報インフラがまだ日本では整備されていないことに起因するのではないでしょうか。

　逆に考えれば、これは、非常に大きなビジネスチャンスかもしれません。

■資本主義ルールのお部屋へ上手に入ろう

　ここまでは、非資本主義的な価値交換に注目して書いてきましたが、では、資本主義上でコミュニティに参加している技術者は成功できないのでしょうか？

　筆者は「実はできる」と思っています。

　前回のコラムでオープンソースとビジネスの関係について否定的な見方をしたのは、「資本主義に偏りすぎた視点」しかない状況ではそうなるということです。

　技術者は、技術者である時点ですでにその存在が大きな価値を持っているので、その価値をお金に換える出口を用意すればよく、「現在、自分が立っているのは資本主義の情報空間ではなく、非資本主義のルールで価値が決定している空間で、上手な形で資本主義の空間に入れればよい」と考えればお金も稼げると思います。

■時間と情報がオープンソースコミュニティの最初の利益

　立ち上げ当初のオープンソースコミュニティでは、

• まだ、解決策がないことを解決しようとしている
• コミュニティが小さいうちは、他の人は問題意識が顕在化していない

という状況になっていると思います。

　ということは、誰よりも早く情報を手に入れ、コミュニティの次の展開が読めれば、今後の展開が読みやすくなります。しかも、オープンソースで無料で出すのであれば、先の展開がさらに読みやすくなります。

　「情報が早いだけ？」と思うかもしれませんが、資本主義ルールの世界では、情報が速いというのは決定的なメリットです。

　例えば、価格ドットコム、ぐるナビ、クックパッドなどのサイトが今は巨大システムとしてあり、ビジネスとしても大成功しています。しかし、最初はここまでものすごいシステムではなかったはずです。

　もし、タイムマシンで10年前に今のスキルを持って戻れたらどうでしょうか？ 中には、技術者の方であれば、自分で本当の最初のものであれば、作れてしまう方も読者の中に大勢いるのではないでしょうか。

　また、オープンソースの世界では、PostgreSQLのコミッタたちが起業したEnterpriseDBが注目を浴びています。

　この事例も、PostgreSQLに関する情報が集中している中にあって、データベースの新しいニーズを知り、それと同時にコミッターたちなのでそのニーズに対する変化に対応できる力を持っているという点で、うまく資本主義ルールの中に対してもオープンソースで培った価値を転換しています。

■技術者の価値を最大にする経営とは

　このコラムでも、たびたび「技術者の最大の価値は変化に対応できること」といってきました。そして、この技術者の長所を最大限に発揮するように展開するための経営で一番重要なのは、この「先見性」です。

　先見性と変化への対応が両方そろったとき、まさに、その会社および集団の経営はお互いの能力をフルに発揮できるものになるのです。

　筆者の視点で見て具体的に言うならば、一番のメリットは「営業が楽になる」です。そして、事業がさらに回ると、営業がさらに楽になり、特別なスキルがある営業さんでなくても活動ができるようになるでしょう。

　これが本当の「マーケティング」です。

　技術者の場合は、すでに、変化に対応する力を持っている方が多いと思うので、時代の中で「何が変わっていくのか」に注目し、そこで発生する問題の発見に集中することが重要です。

■資本主義での成立を達成した時点で一時的な成功

　ある程度、コミュニティが大きくなってくると、できることも当然多くなってきます。

　いろいろなことができるようになると、「せっかくこれだけの特技を持った人材があつまったのだから、もっと、目標を高くしていろいろなことをやりたい」というふうにみんなが考えるようになることでしょう。

　そうするためには、円滑な価値交換の仕組みも必要になってきます。

　この必要性が出てきたということが、コミュニティの1つの成功のポイントです。そうしたときには、お金というのが1つの便利なツールになっていくと思います。

　お金で物事が動き出すと、ものすごいスピードで加速度的にコミュニティが発展したり知名度が上がっていきます。

　「そういう瞬間を向かえられたコミュニティは非常に楽しい思いを仲間と共有できて幸せだろうなあ」と、本当に思います。

■継続するのに必要なもの「資本主義にはない価値」

　しかし、お金というのはあくまでもツールにすぎないということは忘れてはいけません。若干乱暴な書き方ですが、

全体の価値 = [目的の価値] * [技術力] * ( 1 + [資本力] )

ではないかと感じています。

　ここで注目すべきは、

• 資本力の影響は、うまくいけば1より非常に大きい数字になり影響は絶大
• 目的と技術力のどちらかが0なら全体は0
• 資本が0でも目的と技術力があれば全体は0にはならない
• 全体が0でなければ原動力が保てるから続けられる

ということです。

　よく、「鶏と卵の問題」という言葉を聞きますが、これは、資本主義上の価値しか見えていない人間の感覚ではないでしょうか。

　上記の数式の資本力のまえにある「1」が見えるかどうかが非常に大事です。資本力の影響が100や1000であれば、1というのはすごく小さな数字で見過ごされてしまうことがほとんどでしょう。

　しかし、この「1」こそが、資本主義と非資本主義のインターフェイスだといってもいいと筆者は考えます。

■一般的なビジネスや起業との共通点

　一般的なビジネスでも、「鶏と卵」の問題はよく言われます。そして、これを解決する方法は、オープンソースのコミュニティを成功させる手段とまったく同じです。

　また、先見性と変化への対応がその後を左右するという点もまったく同じです。

　だからこそ、成功するオープンソースのコミュニティ活動の中では、ビジネスに直結するような生の情報が得られるのです。

　逆に、参加するコミュニティを選ぶ際に、ビジネスに結び付けることを目的にしている方は、その情報が得られやすい環境にあるかどうかを参考にしてみると自分も楽しく活動できるし、その活動がコミュニティへの貢献になります。

■デメリット、メリットの両方を考えて

　前回のオープンソースとビジネスに対する否定的な記事と、ここまでこの記事を読んでくださった方は、「オープンソースは1つの方法にすぎず、技術者は大きな可能性を持った存在であり、より視野を広げた社会貢献やビジネスができる」と感じてくださった方も、中にはいらっしゃるのではないかと、筆者は勝手に思っています。

　オープンソースは、素晴らしいカルチャーではありますが、あくまで1つの手段です。目的ではありません。「インターネット」や「お金」が手段であるのと同様です。

　そういう意味で、筆者は、オープンソースのメリットとデメリット、そしてその文化の裏にあるものをきちんと理解して、経営感覚のある独立した技術者がこの日本でもたくさん出てきてくれることを願っています。そして、そのような方々と協業できる日を夢見て日々、精進します。

　しかし、IT業界以外の世の中はどうだろうか？ また、本当にオープンソースがマーケティングに効くといっている人で具体的な根拠を示せる人がいるだろうかと考えると非常に大きな疑問がわきます。

■ビジネスに効くのは本当か？

　オープンソースがビジネスに効くというのであれば、まず、考えるべきは、「誰がオープンソースのメリットを享受するか」です。

　オープンソースの魅力を享受するのは、開発会社です。よって、この開発会社がどのくらい恩恵を受けられるかでビジネスに効くかどうかが分かってきます。

　開発会社がビジネス上で本当に恩恵を受けられるかどうかに関しては、競合の事も考えなくてはなりません。というのは、そのオープンソースのソフトウェアを利用して提供価格を安くできても、他社もその価格で出せたら、ビジネス上、まったく効果がないことになります。

　よって、オープンソースの普及を応援する会社が現れたとしたら、その会社は、オープンソースのプロダクトに対して多少なりとも労力やお金を投資すると思いますが、それが普及すればするほど自分の首を絞める矛盾したモデルになっています。

　案件をこなす効率や技術面では、ビジネスにはほとんど効果がないので、今度はエンドユーザーから案件をとるのに有効かどうかを考えてみます。

■ゲームに例えると分かりやすい

　このコラムを読んでいる方の中にも、ゲームで遊ぶ方はたくさんいらっしゃると思います。そして、エンドユーザーのオープンソースに対する感覚を知るにはこのたとえが一番しっくりくると筆者は思っています。

　次の2つのゲームがあったら、どちらを取るでしょうか？

• 非常に面白い普通のゲーム（非オープンソース）
• あまり面白くないけれどオープンソースなゲーム

　エンドユーザーというのは、ITを利用するのが目的です。よって、ゲームの場合は、我々ITエンジニアであっても遊ぶのが目的であれば、その横にオープンソースという属性がついたとき、どのくらい価値が上がるか分かると思います。

　正直な話、オープンソースであるかないかは関係ないと思います。そのソフトウェアがユーザーにとって使ってどれだけ価値が出せるかどうかしかエンドユーザーに対してマーケティングを行う上では関係ありません。

■デュアルライセンスがオープンソースがビジネスにならない証拠

　GPLと商用ライセンスのデュアルライセンスを定義して、どちらかを選択できるライセンス形態がありますが、これこそが、製作元が「オープンソースはビジネスにならない」といっているようなものです。

　オープンソースではビジネスにならないので、普及させるのにオープンソースライセンスを利用して、商用ソフトウェアで儲けられるところに注目され、そこがこっそり商用ライセンスを採用して分け前をもらうシステムです。

　オープンソースがマーケティングに使えない証拠にもなっていると思います。MySQLなどはこの良い例ですが、エンドユーザーはMySQLが採用されているから買うのではなく、提供されるソフトウェア全体の価値で判断しています。

■怒りからはなにも生まれない

　最近、オープンソースは怒りから生まれたという文章をよく見かけますが、正直、怒りからは何も生まれないと思います。

　目的が、怒りの矛先を破壊したら、それで終了だからです。

　技術者としてものが作れる能力があるのであれば、それをもっと建設的な方向で使うべきです。

■オープンソースのブームは終わろうとしている

　正直、今からオープンソースをウリにしてマーケティングを行うとしたらすでに時代遅れだといってもいいでしょう。

　そもそも、オープンソースのブームは、技術者や技術系の会社の幻から生まれたものだと思います。単純に考えて

• ライセンス費用が無料
• 設計図がオープンだからリスクもなし

といえば、エンドユーザーが飛びつくと考えたのでしょう。また、本当の「マーケティング」ができない企業が、安売りの延長上でたどり着いた究極の答えだともいえると思います。

　しかし、ソフトウェアはそんなに簡単なビジネスではありません。現実はそのようにならないのです。ビジネスは細かい部分まで理解することが必要です。

　どこまで細かくするかといえば、「実行可能」な状態まで細かく分析する必要があります。

　世論というのは、最初は「赤信号、みんなで渡れば怖くない」的なものから始まって、希望的観測や妄想でスタートしますが、徐々に失敗をしていくことによって本質が分かってきます。

　そういう意味で、もうすでに、オープンソースのブームは終わっています。

■オープンソースは技術者の遊びで

　資本力がない初期の段階において、オープンソースとITプロダクトの販売ビジネスは結びつけてはいけません。あくまでも、遊びの範疇でやるべきです。

　オープンソースがビジネスとして成功している例として、EclipseやPostgreSQLなどがありますが、これらは、最初からそもそもビジネスを意識していません。自分らが使うことを意識して、これでお金を稼ぐなどとは考えていないのです。

　だからこそ、膨大な時間と費用がかかっていて、それらを考えたらビジネスとしては魅力がありません。ビジネスを目的とするのであれば、このような投資の仕方はしないとおもいます。

　しかし、社会貢献としては素晴らしい意味があります。つまり、オープンソースはビジネス本体ではなく、社会貢献や福利厚生のカテゴリに入るものだと思います。趣味が合ったもの同士で行く、有志の社員旅行のようなものだと筆者は考えます。

■起業したい技術者は一度オープンソースを忘れるべき

　オープンソースで収益が上がるところまで持っていくのは非常にコストがかかることで、起業初期の鶏と卵を解決するような強力なマーケティングツールにはならないとここまで書きました。

　起業したい技術者の人は、まずは、「誰に何を売るか」という基本に立ち返ってそこに集中してビジネスモデルを考えるべきです。

　オープンソースの利用はとても価値があることだと思いますが、やはり、他の人も同様に利用できるため、それは、ビジネスで勝利する上でのポイントにはならないということはしっかりと考えておかなくてはならないと思います。

■オープンソースを利用したビジネスモデルは？

　オープンソースのビジネスモデルとして有効なのは、求人だと思います。これは、明らかに有効ですし、今後も流行っていくと思います。

　筆者も当初は、「オープンソースを利用したビジネスモデルはベンチャーのプロダクト販売にも有効だ」と思っていました。

　つまり、一部分をオープンソースにして、その追加機能やそれを利用したものを有償にしていくというモデルです。オープンソースの集客力と有償のビジネスの良いとこどりをしようと考えました。

　ところが、実際にやってみると、有償のパッケージの魅力の部分しかマーケティング上は有効ではなく、オープンソースで集まってくる人々は、顧客にはならないということが分かってきました。

　オープンソースでは、知名度を上げたり、HPのアクセスを上げて自己満足するには良いですが、売り上げが上がるかというと非常に謎です。

　「アクセス数＝売上」という式。これも幻です。「正しい方向性のアクセス＝売上」という式は正しいです。

　また、有償部分でビジネスが回りだすと、今度は資金ができて広告などを出せるようになってくるので、むしろ、普及させるにも、もしかしたらひたすら無料で突き進むオープンソースより、しっかりとマーケティングをされた有償の商品の方が強いのではないかと感じています。

　筆者としては、どんなに時代が変わろうとも、「顧客が欲しがっているもので他にはないものは、顧客はお金を払ってでも欲しいと思ってくれる」という不変の原理に忠実にビジネスを行うのが今の時代でも正しいと思っています。

　とは言っても、オープンソースは技術者にとって、とても魅力的な部分がありますので、むしろ「将来的にはオープンソースの活動に本腰をいれて頑張れるようになろう」というのが、技術者にとってはよいのではないかと思います。

　しかし、このためには、正しい勉強方法やスキルアップできる環境を用意できなければ、時間ばかり経ってしまいます。

■今の一般的な現場だけでは本当のスキルはつきにくい

　ITにかかわる環境は、日々、ものすごいスピードで変化しています。昔は、ほぼスクラッチでプログラムを書くのが当たり前でしたが、今は、SaaSやオープンソースのパッケージや商用パッケージの利用などで納期が短くなっていると思います。

　しかし、この「納期が短くなっている」というのが幻想である場合が多くあります。それは、発注者側が「パッケージだから」という理由で、実際の現場でどのくらいの考察と作業が発生するかを無視してごりおしをしてしまうことも多いと思います。

　このような環境では、絶対に何かしらひずみが出て、「完全な形で納品」されるということがない場合が多いのではないかと思います。

　また、その現場での政治的なやりとりから発生したスキルの多くは、他の現場では再利用できません。

　一般的に、このようなところでは、「分からない人に対して分かりやすいもの」のみが優先される傾向にあり、「作業を圧倒的に楽にする（変化に対応しつつ工数を減らしてくれる）本当の工夫」は一般的に分かりにくいので、いわゆる「力作業」だけがなし崩し的に強要される現場が多いのではないでしょうか？

■「問題発見」→「分析」→「作業」の順番が守れない現場は何をやってもダメ

　結局のところ、開発現場で守るべきことというのは、「問題発見」→「分析」→「作業」という順番を守ることです。

　この順番を守らなければ、なし崩し的に行われた作業は、上流の仕様変更によって一気に0に回帰します。つまり、蓄積がないのです。

　また、この3つのプロセスで時間をかけるべき部分は「分析」です。しかし、この作業は、非常に分かりにくく、進捗を自分で管理したいけれどもプログラムが作れない人にとっては、「一体何をやっているのか？」ということになります。

　そして、良くできた分析結果ほどシンプルで、ドキュメントもすっきりとまとまってしまうので、「仕事をしているのか？」という話になります。

　この順番を守れるかどうかは、この「分析」の価値が理解できて、そこに対して時間を投資できるかどうかに掛かっていると思います。しかし、海外ではともかく、日本ではここに対する認識が他の国にくらべて弱いような気がします。

　一時期、むりやり、ITバブルでSEを増やしてしまったり、プログラマ35歳定年説などITを実質的に顧客が喜ぶように仕事を達成するよりも、終身雇用的な社内の保身のための仕組みの方が重要視された結果だと思います。

　プログラマ35歳定年説などというものは、開かれた実力主義であるシリコンバレーでは存在しません。

■解決方法は「権利のみ主張する人」の排除

　なぜ、日本ではそのような特殊な文化になってしまっているか？これは、日本古来からの「和を持って尊しとなす」という文化からきていると思います。

　どんなものの考え方も、良い部分、悪い部分があり、結果を出すためにはどのカルチャーがいいのかをきちんと選択することが必要です。

　ITの場合、この「和を持って尊しとなす」は筆者は現場に合っていないと思います。なぜならば、このカルチャーで現場を運営するためには、必ず主従関係を付けなくてはなりません。そして、「正しいこと」よりも「主従関係で上に立つものの意見」が採用されるので、もし、決定的な判断をする人に十分な知識がなければ現場は大変なことになります。

　「意見を採用させる」というのは1つの大きな権限だと思いますが、権限の裏には、「採用した結果に対して自分で責任をとる」ということが付きまといます。この責任を自分では取らずに、他の人や主従関係で下の人間に押し付ければよいと思っている人が上に立ってしまうととても大変です。

　現に、日本ではそのような考えの方がいます。海外では、きちんと。海外では、きちんと権利に加えて裏側にある責任も最初の段階でフェアに話し合われ、リスクも認識したうえで契約が結ばれますので、「自分は現場で何が良いか判断できない」と考える人がその契約を結んで、決定権のあるポジションに就くことは稀です（ただし、利権が絡む場合は同様のことがあると思います）。

　権利と義務がきちんとセットになって議論されている現場では、プロマネがきちんとプロジェクトチームのどこかできちんと下流工程の状況まで調べたり、きちんとした分析がなされる仕組みが整備されます。

　なぜならば、そうしなければ、プロマネの方は自分の責任が果たせないからです。

■プロマネのスキルの本質は経営スキルと同じ

　プロジェクトのマネジャーという仕事は、ある意味、経営者の仕事に似ていると思います。

　ただし、「社長の能力より高い社員はその会社には入らない」というルールが適用されているレベルではなく、「自分が評価的ない分野の高いレベルの人間を評価する仕組みが組織のなかに構成されるように工夫していく」ということができるレベルだと思います。

　筆者は「プロマネはプログラムができないといけないのか？」「プログラマは、一生懸命頑張ってSEになるべき、そしてSEはプロマネを目指すべき」というのは、この観点でいうとまったく方向性が違うのではないかと思います。

　なぜならば、プログラマ（およびアーキテクト）、SE、プロマネはそれぞれ目的が違うからです。そして、どの職種も1つのプロジェクトで必要だからです。

　もし、筆者は、プログラムも要件定義もプロマネも一通り経験があるので、現実的にはどれも自分で評価してしまえばいいかという話になりますが、もし、要件定義をある程度やっていてプロマネをやるならば、

• プログラムのアーキテクチャの責任者
• SE、要件摺合せの責任者

ときちんと分業し、責任範囲を決めて進めると思います。

　また、何人かで協業するとなると、お金の問題が出てきますが、これは、「負った責任」に対してプロジェクトの進行を3者でオープンにし、フェアに分配するといいと思います。

■「正直者」にはスキルが必要

　仕事でシステムを作る場合には、当然ながらお金の問題が発生します。そうすると、完全に経営の問題になってきます。

　「負った責任」に対してプロジェクトの報酬を分配するときには、それぞれ3者が担当する分野においてスキルがある人と組むことが必要です。なぜならば、スキルがない人を入れてしまうと、責任転嫁が始まり、間違ったところで責任を無理やり取らせる方向になっていきます。

　また、プロマネの担当者は、他の担当者が責任転嫁しようとしているのを見逃してはいけません。そこから、モラルの崩壊とプロジェクトの崩壊の大連鎖が起きていきます。

　そういう意味では、プロマネは社長業そのものかもしれません。しかも、その「責任転嫁」を見抜けるくらいはひととおり分かっているジェネラリストでなくてはいけないところが難しいところだと思いますが、これは絶対に必要です。

　結局のところ、それぞれが自分の担当している部分がどこか責任範囲がしっかりしていて、きちんとその部分をしっかりこなせるスキルがあれば、このようなモラル破壊も起きません。なぜならば、きちんとできる人が、責任転嫁をしてプロジェクトを崩壊させても何のメリットもなく、デメリットだけだからです。

　「モラル」や「正義」というのは、それを定義することよりも、「絶対的な正義など存在しない」と割り切ったうえで、「なぜ、それが必要なのか」をお互いの利害関係から考えていけばわりと素直に成り立っていくので、本当に世の中はよくできているなあと思います。

　昔、子供のころ、別に勉強熱心だったわけではないのですが、たまたま放課後に宿題を忘れて居残りで勉強している風景を見られて、用務員のおじさんに「君は、よく勉強して偉いね」と言われたことがありました。

　その当時は、なぜ、勉強をすることが偉いのかが分かりませんでしたが、勉強をして知識やスキルをつけることによって、ずるいことをせずに他人に対して貢献することで食べていけるようになるという意味で偉いのだと大人になってから分かりました。

　大人になってからは、また、さらに「お金」という要素が出てくるので、さらに複雑化しますが、「他の人に対して貢献した対価としてお金をもらえる」というルール自体は変わらないと思います。

　そして、現実の社会で、もし、その利害関係からきちんと成り立たせる「正義」に矛盾があるようであれば、

• なぜ、それぞれが仕事を行っているのか？
• 他の人を幸せにした人がきちんと報われるか？
• 最終的にプロジェクトを発注した顧客のためにもなるか？

を考えて、プロジェクトマネジメントの範囲を超えた本当の意味での「経営」を考えていかなくてはいけないと思います。

■戦略の失敗は戦術では取り返せない

　「戦略の失敗は戦術では取り返せない」というのは、まさに本当だと思います。

　エンジニアとしてこの社会で生きていくためには、ときには、自分の置かれた環境について考えてみることも非常に大事です。筆者はそう考えて起業という道を選びました。

　「ダメなものは何をやってもダメ」というのは、認めるのが難しく、場合によっては周りの空気から「逃げ」ととらえられてしまうかもしれませんが、勇気をもって「ダメ」ということも時に、「結局は」と考えれば一番大事で良心的であることも多いと思います。

　破壊と創造は本当に背中合わせだなあと思いつつ、筆者も今後はこの「ダメという勇気」を今後は大事にしていこうと思います。