OSSを使って安く開発？

MOONGIFT.dev @moongift_dev

オープンソースを使うとシステムの価格が上がるという話。なぜか間違った認識が多い、それはオープンソースを使うとシステムが安くできるということ。

MOONGIFT.dev @moongift_dev

これはWebシステムなどを開発する企業に対して言えること。平気でオープンソースを使うからコストが安いとか言ってしまう企業があるのは実に悲しいこと。

MOONGIFT.dev @moongift_dev

オープンソースといっても、大きく分けて二つあると思われる。一つはLinux、FreeBSD、Apache、MySQL、PostgreSQL、Tomcat、PHP、Perl、Rubyといった暗黙ベースのオープンソース。

MOONGIFT.dev @moongift_dev

暗黙ベースのオープンソースの場合、利用する企業がコアに手を入れることはまずない。オープンソースと言いつつ、ブラックボックスのまま使っているレベル。これはこれで良くないと思うけれど。

MOONGIFT.dev @moongift_dev

場合によってはRailsやPEARレベルでも暗黙ベースになっていたりすることがある。スクリプト言語だったらコンパイルされずにソースが見られるのだから、追求できるだろうに。

MOONGIFT.dev @moongift_dev

暗黙ベースの場合、利用することで価格が下がるというのは主にライセンスコストに関わる所。Windows Server、SQL Server、Oracle、DB2、IISといったライセンス料がオープンソースなら無用ということ。

MOONGIFT.dev @moongift_dev

次は理解できるオープンソース。例えばWordPress、MovableType OSS、Xoops、Redmine、phpBBその他いわゆるフロント系のオープンソース。場合によってはこれでも暗黙ベースになっていることもある。WordPressとか。

MOONGIFT.dev @moongift_dev

問題は理解可能レベルなオープンソースを使うことによってコストが下がると言ってしまうこと。コスト=コーディング量でしか見ていない。

MOONGIFT.dev @moongift_dev

顧客にとって重要なのは、自分たちのニーズが「早く」て「適切な価格」で「問題なく」実現することにある。オープンソースの利用はこの内、「早く」と「問題なく」を解決してくれる可能性があるが、「適切な価格」は保証しない。

池田＠無名なほう @ikeda

あるある。。OSS使って安くして！って依頼も結構。。^^; RT @moongift 問題は理解可能レベルなオープンソースを使うことによってコストが下がると言ってしまうこと。コスト=コーディング量でしか見ていない。

MOONGIFT.dev @moongift_dev

ビジネスレベルで考えた場合、スクラッチで開発しようが基盤となるOSSを持ってこようが大した違いはない（ライセンスに関するリスクは今は無視）。できることが同じであれば価値は同じ。なのに開発会社は自分たちで価値を下げしまう。これはOSS自体の価値も下げる、残念な行為。

MOONGIFT.dev @moongift_dev

次に期間で考えた場合、スクラッチで開発した場合にかかっていた3ヶ月間がOSSだと数週間で終わるかも知れない。これは機会を増やし、よりビジネスを成功裏に導ける可能性がある。

MOONGIFT.dev @moongift_dev

どうしてもリリース日がはじめから決まっていたとしても、それまではテスト運用ができたり、他の問題を解決するリソースにあてられる。

MOONGIFT.dev @moongift_dev

むしろビジネスチャンスを増やす分、OSSを利用することによるシステム価値は向上していると言える。スクラッチで構築するのに比べて工数を減らしつつ、価値を引き上げることに成功する。

池田＠無名なほう @ikeda

@moongift 当初OSSをカスタマイズして、、って、仕様に合うものがなくて、解析とカスタムの工数考えるとスクラッチの方が楽だった、ってパターンは結構あります。。

MOONGIFT.dev @moongift_dev

時々見かけるのが、その基盤になるOSSに信頼性がないと言ってしまうケース。低予算で苦しみながらスクラッチで組んだシステムより、テストもされているし、何人もの目が通っているし、期間もかかっているのでよっぽども信頼性が高い。

MOONGIFT.dev @moongift_dev

少なくともこれからゼロから組むシステムよりも見えるものがある分まし。

れいな@底なし沼の魔女 @MegaBlackLabel

激しく同意。オレオレFWはねぇ RT @moongift: 時々見かけるのが、その基盤になるOSSに信頼性がないと言ってしまうケース。低予算で苦しみながらスクラッチで組んだシステムより、テストもされているし、何人もの目が通っているし、期間もかかっているのでよっぽども信頼性が高い。

瀬良 @shela_

前提として使う部分をよく知っている人が開発することですよね。知らなければ変わらないか、かえって増加するかもしれない。 RT: @moongift: 次に期間で考えた場合、スクラッチで開発した場合にかかっていた3ヶ月間がOSSだと数週間で終わるかも知れない。

close_yutori @kimukou2628

@moongift Railsのjava版 grails にしてもソースは見れますが GPLの問題があるのでリスク回避＆ソース開示の話が難(顧客資産になるのでベンダが判断不可) ただ、どうしてもまずいのは、こっそりパッチっていうのはありますね。OSSの思想的には良くないですけど

MOONGIFT.dev @moongift_dev

とは言え、暗黙的に導入するのもまた思慮が浅すぎる。開発にかける予定だった工数の半分で良いからテスト工数に当てて欲しい。テストは手作業も必要だけれど、ユニットテストやブラウザレベルのテストを行うコードを書いて実行して欲しい。

MOONGIFT.dev @moongift_dev

その結果バグがあればフィックスしてコミュニティに還元して欲しい。それがオープンソースコミュニティとの付き合い方ではないだろうか。

MOONGIFT.dev @moongift_dev

バグフィックスを担当することで内部のシステムも理解できてカスタマイズも容易になる。バグの少ないシステムを納品すれば顧客満足度もあがるし、手離れも良くなる。納期が守れたりむしろ早まればビジネスチャンスも拡大する。

MOONGIFT.dev @moongift_dev

次に大事なのは各個別のプロジェクトにおいてどのOSSが最適であるかを把握すること。自分たちが知っているからといって、何でもかんでもWordPressを使えば良いという訳ではない。顧客ニーズに合わせた選定を適切に行うためには日頃からの情報収集および比較、検証が重要になる。

MOONGIFT.dev @moongift_dev

PHPとPythonとJava、Ruby、C/C++、Perlのどれが向いているのか（予算や規模感、要求レベルによって変わるだろう）、さらにどのフレームワークを選定するべきか、どのアーキテクチャで行くかなど。