非エンジニア経営者（予備軍）のためのウェブサービス構築実践のススメ

本稿は俗にいう「能書きは要らない」の能書きにあたる文章であり、以下のようなノートを公開するに至った背景事情の説明です。

典型的な失敗例

サービスを立ち上げたら思いのほか話題となりアクセスが集中。サーバが落ちてしまい、当初の勢いは持続せず。そうこうしているうちに大手ベンチャーから類似サービスがリリースされ、VCと交渉していた資金調達も失敗。手詰まり。

本シリーズの狙い

まず、インターネット黎明期であればともかく、解決手段がいくらでもある現在においても上記のような事例が後を絶たないことに対しての個人的苛立ちがあります。

経営者も技術者も愚昧であった場合、上記のような事例に対して同情の余地はありません。しかしながら、当たるサービスを企画できる経営者のレベルに技術者のレベルが追いついていないというケースも多いのではないでしょうか。

現在、ヤフーに取り上げられようが、テレビで取り上げられようが、ほぼ落ちないサービスを構築することは容易です。しかしながら、ネットで検索して得られる情報は分散しており、分かりにくく、また、紹介される方法も複雑かつ高度な技術的知見を必要とし、高コストにつくものばかりです。

特に非エンジニアの経営者やこれから経営者を志す人にとっては、取り付く島もないという印象が先立つことでしょう。

本シリーズでは、極めて容易に実践する手段を提示することで、地頭のよい経営者が単独で高可用のサービスを構築・運用する可能性を獲得すること、また、経営上の技術戦略や人材を含むリソース配分の観点での技術的サービスデザインの基本コンセプトを体感して習得することを目的としています。

本シリーズの想定する読者像

・地頭がよい。むしろよすぎるという人。理解と実行のためにそれなりの知性が必要です。また、地頭がそこそこの人はこんなことを実践してみる必要はなく、普通にチームアップしていけばいいという理由もあります。

・経営者として一定の成功を収めている人。もしくは、これから経営者になりたいと考えている人。経営者として技術者の在り方に疑問を持った経験がある、あるいはこれから起業するにあたって、技術戦略に不安を持つというような方にも好適かと思います。

・年齢的な上限下限はなし。40歳以上の人や高校生以下の人に実行してもらえると面白いかもしれません。環境さえ揃っていれば小学生でも実行できる内容です。

・IT以外の市場をターゲットにしている人。情報発信のためのウェブサイトなど、カネを稼いでくる仕組みでない部分こそ無駄な投資や機会損失を防ぐべきであり、経営者が実践に基づいた知識を持っているか否かとでは大きく差がでるのではないかと思われます。

ミクロの課題

・経営者と技術者との地頭ギャップ。会社を経営していて、技術者に対して「ググレカス」と思った経験をお持ちの非技術者の経営者の方は少なくないかと思います。自分がベストと思う方法を取れない歯がゆさ。もちろん、CEOとしての役割の中には優れた技術者を採用するということも含まれますが、人材市場の環境やそれこそ「縁」のようなコントロール不能な投機的な要素も含まれてくるので、泣く泣く手持ちの技術者で妥協するという方法しか取れないという状況も発生しえます。

・誰と組んでよいかが分からない。技術を習得するにしても何をすればよいか分からない。Y Combinatorの創始者であるポール・グレアムは『スタートアップを殺す18の誤り』と題された文中で6. まずいプログラマを雇う、7. 不適切なプラットフォームの選択と技術関連の二つの誤りを挙げていますが、そもそも、まずくないプログラマや適切なプラットフォームというものの定義が分からないかと思われます。

マクロの課題

・市場全体の潜在的な起業における成功率や成長性を損ねている。上記にて優れた技術者を連れてくることもCEOの仕事と書きました。実際、全ての成功企業が創業時に優れた技術者を有しているわけではなく、多くの場合、調達した資金により優れた技術者を連れてくることで、あるいは技術的には拙いまま営業力や資金調達により注力することで、その成功を掴んでいます。ただし、会社経営の中でも特に難易度が高い段階である、高い能力の人材を獲得出来るだけの資金を調達するまでの間に間違った技術戦略を採ることで沈んでいく企業もまた多くあります。

解決へのアプローチ

・自分で解決できる力を持つ。『スタートアップを殺す18の誤り』でも第一の誤りに「創業者が1人」とも挙げているように基本的には悪手となります。しかしながら、他の収入源を断ったり、外部の投資家からの資金調達を受けるなどのリスクを抱える前のサービスモデルをスクラップビルドで試すというような段階であれば、悪手とは限らないのではないでしょうか。チームアップするにしてもホットモックがある方が円滑に話が進むかと思います。

・技術の要点を知る。非エンジニアに対して「レンタルサーバ上でのLAMP」環境構築・運用を勧める記事をよく見かけます。各々の技術要素を批判するつもりはないのですが、構成要素が一体化していることに問題があります。正解としてはサービスをさらに細かいサービスに分割し、機能ごとのモジュールに分け、各々を疎結合で結んで構築することが要諦となります。前者のような思想を「マイクロサービス」と呼ぶこともあります。

モジュール構成を取ることにより、各要素ごとのコスト構造が明らかとなり、リソース配置の意思決定がより明確となります。このあたりはIT系スタートアップの経営者であれば、今後必須のスキルとも言えます。

ただし、モジュールが分散されすぎることはコントロールが難しいリスクとなりますので、別記事にて紹介するGoogle App Engineのように機能モジュール群が一体化したサービスを用いることも、本ノートの主旨的には重要なポイントとなります。

具体的に書けば、大規模の会社であれば、データベースやネットワーク、それらを配備・運用するDevOpsなど、サービス・機能のマトリクス毎に優秀なエンジニアを割り当てることが定石となっていますが、一人でそのような構成を採ることは無理がありますので、Google App Engineのような、それらの機能を統合的に管理できるサービスを用いる必要があるというような話です。

展開オプション

・優れた技術者との出会いを待ち、技術面は全面的に改訂。前項で述べたような、きちんとモジュール（マイクロサービス）化されたサービスは、優秀な技術者であれば、サービスを稼働させたまま、比較的容易に他の環境に移行させることが可能です。また、データの保管先をGoogle Datastoreのように事実上無限にスケール可能でデータ構造も追加変更可能なサービスを選択しておけば、最も手間がかかり、リスクもある、データ移行という問題も避けることが可能です。

・クラウドソーシングサービスを用い、そのまま、サービスやシステムを拡張。筆者の場合、主にクラウドワークスやUpworkを用いて、開発業務を分散・大規模化しています。
クラウドソーシングサービスを上手く利用すれば、モジュールごとに開発を委託し、それらを結合することで、極めて短期間に高度なサービスを構築することも可能です。この場合、一人であっても、それなりの規模のサービスの運営は可能かと思われます。

まとめ

実践を伴う技術的知識を身に付けることは経営者個人にとって実行力というリアル・オプションとなるほか、経営の重要な要素であるリソースマネジメントをより精緻に行う基本となります。

また、このような知見を身につけた経営者や経営者予備軍が増えることで、スタートアップ市場全体の効率が向上する可能性もありますので、是非、トライしてみてはいかがでしょうか。