アイディアがあり、ウェブアプリ・ウェブサービスを提供したいけど、エンジニア不在なので、プロダクトの制作はどうした方が良い？
クライアントからこのような質問をよくいただきますので、この記事を通じて、メリットやデメリットも含め、様々な手段を紹介します。
できれば、「フルスクラッチ開発」や「パッケージ開発」などの専門用語を使わずに、ITに関する知識がゼロの方でも、ググることなしに理解できるように説明していきますので、比喩法をふんだんに使います。
厳密的にはちょっと違うというところもあるでしょうけれども、あくまでも理解してもらうためのイメージであることをご了承ください。
同時に、商材の性質上、無形商品を説明するのに有形商品を例にすると、どうしても当てはまらない部分が出来てくるので、この記事では所々によっては異なる有形商品を例にします。
なお、この記事では、ウェブサービス、ウェブアプリ、ネイティブアプリを問わず、「ウェブ上で何かをする」ことを「ウェブサービス」に統一します。また、ウェブサービスを取り上げていますが、ウェブサイト（ホームページ）も同じことが言えましょう。
また、費用面につきましては、本当に状況によって大きく異なるので、この記事では触れないことにしています。
「フルオーダーと既製品」の間というイメージ
まずはフルオーダースーツと既製品スーツをイメージしてください。
フルオーダースーツは、需要に合わせてゼロから作るのに対して、既製品スーツは既にある商品になります。
ウェブサービスも同様です。
設計に合わせてゼロから作るスタイルと、既に販売されているソフトウェアを使うスタイルがあります。
ただ、詳しくは後述しますが、それぞれにはそれなりのデメリットがあるので、現実的には「フルオーダーと既製品の間」のスタイルを取ることが多いです。
なお、これから、「ウェブサービス」全般を例に、「フルオーダーと既製品の間」というスタイルを説明していきますが、「ウェブサービス」という表現が抽象的過ぎる場合には、「マッチングサイト」を例に説明していきますけど、「オウンドメディア」、「ブログサービス」、「シェアリングサイト」、「ECサイト」など、種類に関わらずオールマイティーな解説であることをご留意ください。
例えば、オウンドメディアを立ち上げたい場合も、
- 1から自前のCMSを開発＝フルオーダー
- 既存のブログサービスを利用＝既製品
- WordPressなど既存のCMSをカスタマイズして利用＝フルオーダーと既製品の間
などのオプションがあるように、全てのウェブサービスに応用できる考え方になります。
フルオーダーでウェブサービスを作る
設計に合わせてゼロから作るフルオーダーの場合は、プロダクトをほぼ100％のアイディア通りに開発することができる反面、時間的コストも含め、費用が結構かさみます（ちなみに、これは「フルスクラッチ開発と呼ばれます」）。
これは、スーツのフルオーダーをイメージすれば分かりやすいでしょう。
ただ、厳密的にはやや違う点があります。
例えばスーツの場合、生地を作ることはあっても、ボタンは既製品を使うことになりますが、
ウェブサービスのフルオーダーは、開発言語そのもの以外は、全てゼロから作ることになります。
スーツの例に戻ると、既製品のボタンではなく、ボタンをも最初から作る、というイメージになります。
これは、無駄であることがわかるでしょう。
ボタンをも最初から作るようなことを、「車輪の再発明」と言います。
Wikipediaによれば、「車輪の再発明」とは、
を指しており、要するに、
「仮に車をゼロから作るにしても、車輪のデザインはともかく、車輪そのものを再発明する必要はないよね」
ということです。
既製品のソフトウェアを購入
既に出来上がったマッチングサイトのソフトウェアを購入すれば、極端な話、購入した時点からサービスを開始することができます。
そのため、リリースまでの時間短縮も含め、初期コストを抑えれられるのが既製品のメリットであるものの、
アイディアとのズレは必ず生じますので、既製品の場合は展開の方向性をプロダクトに合わせるという妥協が必要になります。
例えば、既製品のソフトウェアに絞り込み検索機能を備わっていなければ、そういった機能を実装したくてもできません。
絞り込み検索機能という程度ならアイディアを修正してなくてもよいのですが、機能によっては戦略の修正を余儀なくさせるほど致命的なので、これが「既製品のソフトウェア」を買うことの最大なデメリットであり欠点であります。
本当はこんなデザインのスーツでパーティーに出かけたいけど、予算の問題もあるし、間に合わないので、まぁこの状態で妥協するしかない
というようなイメージです。
ただ、やはり厳密的にはやや違う点があります。
既製品スーツには、たくさんのラインアップがあり、探せばイメージ通りのデザインを見つけることはできます。それに対して、既製品として販売されているウェブサービスのソフトウェアは意外と少ないので、現実的に既製品をそのまま使うことはほとんどないでしょう。
例えば、WordPressでも、そのままデフォルト設定で使う人はいなく、テーマの変更なりプラグインのインストールなり、需要に合わせてカスタマイズすることがほとんどです。これを次で説明します。
改造車のように既製品をカスタマイズする
既製品のカスタマイズというスタイルは、市販されている自動車を自分の好みに合わせてカスタマイズするスタイルになります。
先ほどのWordPressの例でいうと、デザインを変えるためにテーマを変更したり弄ったりして、機能を追加するためにはプラグインをインストールしたり修正したりするので、まさに、自動車を自分の好みに合わせてドレスアップしたり改造したりするというイメージに当てはまります。
ただ、やはり厳密的にはやや違う点があります。
自動車であれば、原理原則となるメカニズムがわかっていれば、どのメーカーの車でも改造できそうですが、ソフトウェアの場合はそう簡単にはいきません。
なぜかというと、自動車メーカーの数は数えられるほどであるのに対して、ソフトウェアベンダーは星の数ほどいるからです。
そのため、それぞれの癖特徴があるので、そのソフトウェアに精通している技術者でなければ、カスタマイズするにも時間とコストが共にかかってしまいます。
例に挙げたWordPressは結構なプレゼンスを獲得しているので、対応できる技術者も多くて情報も豊富ですが、世の中にはそうでないソフトウェアがたくさんあります。とりわけウェブサービスのソフトウェアともなると、なおさらです。
もっと分かりやすい例でいうと、うちが開発した「インフィニティマッチング」というマッチングサイトを素早く立ち上げられるシステムですが、それに精通している技術者はうちにしかいないのでしょう。
セミオーダーするためのフレームワーク
先ほど見た「既製品をカスタマイズする」というスタイルは、既製品そのものに依存してしまうという特徴がありますが、そういった依存性がなく、汎用的なのが「フレームワーク」という概念です。
要は、いろんなパーツがあるから、そこから必要に応じて組み立てるというスタイルとなります。
セミオーダー住宅やセミオーダースーツをイメージしてみると分かりやすいでしょう。
ただ、やはり厳密的にはやや違う点があります。
セミオーダー住宅やセミオーダースーツの場合では全てのパーツを決めれば、残りは組み立てるという作業だけですが、フレームワークだけで全ての必要なパーツを揃うことはありません。
そのため、フレームワークを活用する開発スタイルでも、現実的には「一部のパーツをフレームワークから、その他のパーツを自前で開発する、といった形に落ち着くことが一般的です。
実務的には「自作PC」が一番イメージに合う
冒頭では、「フルオーダーと既製品」の間というイメージと言いましたが、実際にはその範囲をもっと狭めて、「セミオーダーと既製品のカスタマイズ」の間を採用することになります。
イメージとしては「自作PC」が最も適切でしょう。
既製品のPCを買ってから、部品を取り換えたり改造したりするスタイルの「自作PC」（これは自作PCでないという人もいるが）は、既製品のカスタマイズのイメージであり、パーツを買って、自分でPCを組み立てるスタイルの「自作PC」はセミオーダーでありましょう。
すなわち、程度の差はあれ、「既にあるモノも使いながら、自前でも開発するハイブリット型が最も使われます。
一方で、その「程度」がまさに深く検討しなければならないポイントなのです。
言ってみれば、「自前でも開発する」の程度が高ければ、自由度を入手できる代わりにコストがかさむのに対して、「既にあるモノを使う」の程度が高ければ、既製品を利用する時の問題点がより浮き彫りになるのです。
※厳密的に、フレームワークも既製品になります。
既製品には不要な機能も入っている
既製品をそのまま丸々使うことは滅諦にないことを既に説明しましたが、「既製品のカスタマイズ」とうスタイルも、既製品をそのまま丸々使う際のデメリットを継承してしまいます。
まず、不要な機能も入っていることです。
一般的に、既製品は出来るだけ多くのニーズに対応するため、様々な機能が取り込まれていますが、その中には当然に不要な機能も入っています。
有名なWordPressの例でいうと、例えば、「単純にブログを書きたい」場合には、もしかしたらコメント機能も不要ですし、固定ページの編集機能も含め全てが不要になるでしょう。
既製品を修正する時のハードル
そういった機能を削除すればよいのでは？と思うかもしれませんが、そうにはいきません。安易に機能を削除するとほかの機能に影響を及ぼすかもしれないというリスクとともに、実は、機能削除も含め「修正」することは、案外と時間がかかります。
以下の例を読むと、その理由がわかるでしょう。
スマホのウェブサイトの右上や左上によくある3本線のメニューボタンは、通称「ハンバーガーメニュー」と呼ばれています。既製品であれば、ワンボタンで実装できるのに対して、ゼロから作ると数時間はかかるでしょう。
しかし、3本線ではなく、ハードマークにしたい！となったときはどうでしょうか？ゼロから作った技術者は長くても30分程度で対応できるのに対して、既製品を使った技術者は、数時間以上はかかるでしょう。
こういった修正のニーズが、1ヶ月に何度も生じると・・・・・
結局どういう開発スタイルがおススメ？
程度はどうであれ、「既にあるモノも使いながら、自前でも開発するハイブリット型が最も一般的であると分かったところで、その「程度」をどう決めればよいかを知りたいところでしょうが、残念ながら、これとった答えはなく、結局のところ、現実的には「状況に応じる」ことになります。
クライアントに対しては状況をヒアリングの上、アドバイスをしていますが、この記事で全ての状況に言及しきれないので、やや一般化した考え方を紹介するとします。
オウンドメディアやブログならWordPressでも良い
「WordPressでマッチングサイトを立ち上げたい」だと、「ちょっと待って！」にはなりますが、
オウンドメディアやブログなど、単に発信していくだけの目的なら、正直、WordPressでも良いですし、WordPressだけで事足ります。
オウンドメディアやブログの運営に必要な機能はほとんど既に出回っているプラグインで賄えるし、そもそも、そういう目的に作られたWordPressなので、テーマだけ変えればオウンドメディアの運営ができる場合もあります。
修正やカスタマイズもほとんど必要がなく、仮に必要になったとしても、マイナーチェンジでしょうから、クラウドソーシングなどでも簡単に対応できる技術者を安く見つけられるでしょう。
ちなみに、うちは、オウンドメディアのCMSを自前でゼロから開発しましたが、それには理由があります。
うちは最初から「複数のオウンドメディアを運営することになる」ことがわかっていたので、
素早く新しいオウンドメディアを立ち上げられる
その都度にサーバーへインストールしなくても済むように
一つの管理画面で全てのオウンドメディアを管理できる
などのニーズに対応するために自前でゼロから開発しました。
もしも、「一つのオウンドメディアしか運営しない」ともなると、WordPressにしていたと思います。
予算があれば「自前」のウェイトを高めよう
既に「自前開発スタイルは自由度を入手できる代わりにコストがかさむ」と説明しましたが、予算があれば当然によりアイディアを忠実に実現するための自由度を手に入れましょう。
できれば技術者を抱えましょう。
なお、あくまでも「自前のウェイト」を高めるのであって、100％にするのではなく、車輪を再発明することも避けましょう。
顧客価値を実現している機能を見極めよう
結局のところ、更に一般化していくと、
ウェブサービスの場合は、まず
顧客価値を実現している機能を見極める
この考え方が結構重要です。
- 顧客価値を実現している機能はどれか？
- 戦略的に重要な機能はどれか？
- 今後の展開に強く影響しそうな機能はどれか？
これらの問いに対する回答に突き詰めていくと、最もクリティカルな機能が浮かび上がります。
それをもとに、開発体制を決めていければよいでしょう。
