アーキテクチャをスマートに。

株式会社ネオジニア代表。ITアーキテクトとしてのお仕事や考えていることなどをたまに綴っています。（記事の内容は個人の見解に基づくものであり、所属組織を代表するものではありません）

gumroadのSI業界での適用可能性について考えてみた

考え方

先般、世間がバレンタインデームード一色のころ、「gumroad」というWebサービスが発表されました。
僕がそれを知ったのは発表から１週間以上たってからでした。
gumroad を簡単に説明すると、誰でも簡単にデジタルコンテンツを売買できるサービスです。
そこに写真や動画などのファイルをアップし、そのURLをTwitterやFacebookで広めるだけで世界中に向けてコンテンツを販売することが出来ます。
※gumroadってなに？な人は、記事末尾のリンク集からどうぞ。

なにがスゴイのか？

  • URLリンクひとつで誰でもデジタルコンテンツを販売できる
  • インタフェースががシンプルでわかりやすい
  • 販売コンテンツの承認がいらない
  • 会員登録すら必要ない
  • 手数料は販売価格の5%と破格の安さ

この辺については、Web上のIT記事やブログなど、詳しい解説がすでにあるのでそちらに任せます。
とにかく、これまでにないコンセプトとマインドにあふれており、僕にとって「ものの売り方」ということを考えなおさせてくれました。

管理をしないという発想

楽天にしろヤフオクにしろ、現状のインターネットショップは必ず商品の「管理」をしています。
これはつまり、実店舗がそのまま仮想化され、インターネット上に店舗として存在しているからです。
ショーウインドウがWeb化され、PC画面上に商品が陳列されているのです。
商品のカテゴライズ、在庫管理、決済管理など、実に多くの「管理」が行われているわけです。

だから会員登録が必要となり、仲介手数料もそれなりにかかってしまうのです。


出版業界にしても音楽業界にしても、同じです。
いくらデジタル化が進んでもコンテンツの物流構造は変わりませんでした。
ダウンロード販売に変わったといっても、結局は出版社なりレコード会社なりが間に入っており、本屋がAmazonに、レコードショップがiTunes Storeに変わっただけで、コンテンツクリエータからコンテンツ購入者までの物流構造は、ほとんど変わっていないと思います。


gumroadはここのコンセプトが全く違います。


そこに店舗はありません。ショーウインドウもなく、販売されている商品を検索することも一覧化することもできません。


そんなもの必要ないのです。


gumroadのスタンスは、売る側が、FacebookやTwitterといったソーシャルメディアを通じて、自らの既存ルートを使って宣伝してください、というものです。

まさに、Twitterに写真をアップするのと同じ感覚で、コンテンツ販売ができるというわけです。

なぜ今までなかったのだろうと思ってしまうほど、自然で、直感的な仕組みじゃないですか？



管理なんてないほうがいいに決まっている。


（誤解を招かないよう補足すると、管理を「してない」ことが良いんじゃなくて、管理そのものが「存在しない」ことが良いんです）

ソースコードを売る

ここからはIT屋らしく、gumroadでソースコードを売る、ということについて考えてみました。

それも個人単位での売買ではなく、SI業界でこういうことができないかという切り口で。

もしかしたら既にこういう試みを考えた人がいたかもしれません（おそらくいたでしょう）が、

gumroadにインスパイアされた今の自分なりの発想で考えてみたので、ここにまとめてみます。

SI業界への適用可能性

SI業界の開発現場では、とてつもなく非効率なことが起こっています。

たとえば、いたるところで同じようなプログラムを、繰り返し作りなおしているのです。

もしソースコードを部品単位で購入でき、開発プロジェクトに組み込めるとなると、どうなるでしょう。

  1. コストの大幅削減
    • 求められる機能と似通ったプログラム部品を購入し、イチから作る工数と比較して安くなるのであれば、製造コストを下げられる。
  2. 作った部品を売る
    • 汎用的に使い回しがきくようなプログラム部品であれば、それを販売することで、これまでになかった収益源へと化ける。
  3. 汎用的に作るようになる
    • なるべく汎用的なプログラム部品を作るような設計が行われ、より使い回しがききやすいものづくりが行われる。
    • さらなるコスト削減につながる。


３つ目が実は一番重要なことで、うまく循環するようになれば、

  • 製造コストを削減しながら
  • 新たな収益源の可能性が広がり
  • SI事業としても顧客へのアピール度が高められる、

というスパイラルが考えられます。

それと、プログラム部品の販売をメインの収益源としていないことも重要。
これをメインにしてしまうと、ライセンスやコピーの問題がかなり深刻になってくると思うのです。
なのでメインにしない方がやりやすいと考えています。
（メインにするならそれだけでパッケージ化し、別途事業を起こすべきです）
※ここで言っている「コスト」とは、システムの発注側が支払う価格のことではありません。製造にかかる工数のことです。


本当にこんなことが起これば、スゴイことですね。



まさに革命。



オープンソースとクローズドソースの間の世界が出来上がる。


SI業界でソースコード売買する

プログラムとしてのまとまりの粒度でいうと、

ですが、
ライブラリ以上のものは現在でもありますね。

新しいのは関数（オブジェクト指向言語ではクラスになるかな）という単位だと思います。

SI開発では、顧客業務情報の流出を防ぐため、ソースコードをクローズドにしてきました。
エンジニアは客先に常駐し、
　インターネットにつなぐことも許されず、
　　自分が書いたプログラムをコピーするなんてもってのほか、
　　　当然他の開発現場でプログラムを使い回すなんて出来るはずもなく、
　　　　そもそも使い回しを念頭にプログラムを書いているエンジニアはほとんどいません。
そうするとエンジニアのレベルが下がり、
　品質が下がり、
　　製造コストが増大します。

そんな負のスパイラルに、今のSI業界は陥っているのです。

ところが、関数単位で切り出せるとすればどうか。
業務に特化したような情報が含まれていなければよいのだから、簡単な話だと思います。

業務依存情報をロジックから追い出し、結合度を下げ、より汎用的なロジックとインターフェイスにすることで、容易に切り出すことができます。

インターフェースを明確にする

プログラム部品がショーウインドウに陳列されるとするならば、買う側は何を見て商品を選ぶでしょうか。

最も重要なのは、プログラム部品のインターフェースです。

入出力インタフェース。

つまり、そのプログラムに何を渡せば、何が返ってくるのか？

その渡すデータと返されるデータの仕様を明確にし、インタフェース仕様書としてドキュメント化する必要があります。

インターフェース仕様書といっても、難しく考える必要はないです。

例えばJavaで言えば、Javadocコメントがそれにあたります。

Javadocはソースコード内にコメント形式でドキュメンテーションしていく仕組みで、広く世界に普及しています。

プログラムを読む側も書く側も、Javadocなら一切の抵抗なく、インタフェース仕様として容易に受け入れられます。

※ただし日本語と英語の壁はやっぱり大きく立ちはだかるわけですが、それはまた別の問題ですので、ここでは置いておきます。

品質の確認方法はどうするか？

仕事上で使うなら、一番の問題点は品質でしょう。
つまり買う側にとっての関心ごとは、

  • そのソースコードがどの程度の品質なのか
  • 開発途上なのか、ある程度の完成度なのか
  • バグが残っていなかどうか

といったことだと思います。

これに対する一つの解決策は、例えばテストプログラムの添付です。

要するに、Javaのプログラム部品を売るのであれば、それにJUnitなどの単体テストプログラムをつけておくのです。
単体テストプログラムは予め全ソースコードを見れるようにしておきます。

買う側は、テストコードを見て、そのプログラムがどのような挙動をするのか確認することができます。

テストプログラムは完全網羅していなくてもよいです。

網羅していないということが品質を表すことになり、買う側にとっての判断材料としては十分役目を果たすし、
それでも買う価値があるかどうかは、買う側が判断するのですから。

コピーの問題

先にも少し触れたが、デジタルコンテンツの取り扱いにおいて避けて通れないのが、コピーの問題です。

デジタルデータの世界では、理論上、コピーが簡単につくれてしまい、原本とコピーは全くの同じで区別がつきません。

これまでにも、コピーガードやDRM、アクティベーションなど、涙ぐましい努力によってコピーをさせない仕組みが考えられてきました。

はっきり言ってイタチごっこ。

プログラム部品を売買するにあたっても同じことが起こると思われます。
とりあえずコピーの問題はあとまわしで進められ、市場の規模拡大とともにコピーの問題も取り上げられていくことでしょう。

難しいことを後回しにしているように聞こえるかもしれませんが、
僕のスタンスは「とりあえず気にしない」です。

イタチごっこに根本的対策などない。始まる前に対策を考えるほうが時間の無駄です。無限に続く数列をいくつか飛ばしているだけに過ぎません。

そもそもの目的はシステム開発のコスト削減と効率アップであり、
ソースコード売買市場の展開はそのひとつの手段に過ぎないからです。

他にも、不正なコンテンツや悪意のあるコンテンツなど、考えられる問題はいくつかありますが、どれも同様ですので、これらに対する議論もここでは置いておきます。

ソースコード以外に

ソースコード以外にも、使い回し可能なものであるにも関わらず、それが出来ておらずに効率を下げているものはたくさんありますね。

例えば設定ファイルとか。

フィールドエンジニアの方はよくわかると思いますが、
LinuxサーバのセットアップはLAMPといわれるようにある程度セットアップ内容が共通しています。

それを、顧客ごとに現場へ行っては毎回同じような設定ファイルを
作ってはメンテナンスし、
また同じようなサーバセットアップをする際には
イチから設定ファイルを書きなおしているのです。

この設定ファイルを、顧客業務情報をマスキングするなり取り除いた上で共有化できれば、かなりの効率アップが期待できるのではないでしょうか。
（そもそも設定ファイルに顧客業務情報がそれほど含まれているとは思えませんが）

また、自分が知らないサーバソフトウェアの設定をしなければならない場合に、ある程度希望する設定内容に近い状態の設定ファイルが入手できれば、相当なアドバンテージとなります。
※ただしこの場合は勉強や試行錯誤する時間をとばしてしまい、「手抜き」という表現に近くなるので、現場のエンジニアの観点からすれば一長一短ですね。

それ以外にも応用できる範囲はまだまだあるはずです。

もっと深く掘り下げて、または範囲を広げて議論できる余地がありますね。

gumroadの次の「何か」

ここまで考えてきたことは、gumroadでなくては出来ないことではなく、
むしろ日本のSI産業界の改革を目指すならば、
それに適した形のgumroadの次の「何か」が必要なんだろうと思っています。

日本のSI産業、つまり業務システム開発の産業は、まさに幕末です。

このままでは崩壊の道しかなく、海外勢に全て持って行かれかねません。

一日も早くその「何か」にたどり着き、SI業界の改革のキッカケにできればと
日々考えています。

参考リンク集