10周年のSPコンテンツ!

OSSを使って安く開発?

良く聞くのがOSSを使って開発を行うと安くシステムが開発できます、という話。これが誤りであることの説明になります。途中脱線しているところもありますが。 OSSとはノウハウであり、開発会社は専門家としてどのOSSが最適解であるか(またはスクラッチが良いのか)を見極める必要があります。
開発 オープンソース
26
MOONGIFT @moongift
オープンソースを使うとシステムの価格が上がるという話。なぜか間違った認識が多い、それはオープンソースを使うとシステムが安くできるということ。
MOONGIFT @moongift
これはWebシステムなどを開発する企業に対して言えること。平気でオープンソースを使うからコストが安いとか言ってしまう企業があるのは実に悲しいこと。
MOONGIFT @moongift
オープンソースといっても、大きく分けて二つあると思われる。一つはLinux、FreeBSD、Apache、MySQL、PostgreSQL、Tomcat、PHP、Perl、Rubyといった暗黙ベースのオープンソース。
MOONGIFT @moongift
暗黙ベースのオープンソースの場合、利用する企業がコアに手を入れることはまずない。オープンソースと言いつつ、ブラックボックスのまま使っているレベル。これはこれで良くないと思うけれど。
MOONGIFT @moongift
場合によってはRailsやPEARレベルでも暗黙ベースになっていたりすることがある。スクリプト言語だったらコンパイルされずにソースが見られるのだから、追求できるだろうに。
MOONGIFT @moongift
暗黙ベースの場合、利用することで価格が下がるというのは主にライセンスコストに関わる所。Windows Server、SQL Server、Oracle、DB2、IISといったライセンス料がオープンソースなら無用ということ。
MOONGIFT @moongift
次は理解できるオープンソース。例えばWordPress、MovableType OSS、Xoops、Redmine、phpBBその他いわゆるフロント系のオープンソース。場合によってはこれでも暗黙ベースになっていることもある。WordPressとか。
MOONGIFT @moongift
問題は理解可能レベルなオープンソースを使うことによってコストが下がると言ってしまうこと。コスト=コーディング量でしか見ていない。
MOONGIFT @moongift
顧客にとって重要なのは、自分たちのニーズが「早く」て「適切な価格」で「問題なく」実現することにある。オープンソースの利用はこの内、「早く」と「問題なく」を解決してくれる可能性があるが、「適切な価格」は保証しない。
池田@無名なほう @ikeda
あるある。。OSS使って安くして!って依頼も結構。。^^; RT @moongift 問題は理解可能レベルなオープンソースを使うことによってコストが下がると言ってしまうこと。コスト=コーディング量でしか見ていない。
MOONGIFT @moongift
ビジネスレベルで考えた場合、スクラッチで開発しようが基盤となるOSSを持ってこようが大した違いはない(ライセンスに関するリスクは今は無視)。できることが同じであれば価値は同じ。なのに開発会社は自分たちで価値を下げしまう。これはOSS自体の価値も下げる、残念な行為。
MOONGIFT @moongift
次に期間で考えた場合、スクラッチで開発した場合にかかっていた3ヶ月間がOSSだと数週間で終わるかも知れない。これは機会を増やし、よりビジネスを成功裏に導ける可能性がある。
MOONGIFT @moongift
どうしてもリリース日がはじめから決まっていたとしても、それまではテスト運用ができたり、他の問題を解決するリソースにあてられる。
MOONGIFT @moongift
むしろビジネスチャンスを増やす分、OSSを利用することによるシステム価値は向上していると言える。スクラッチで構築するのに比べて工数を減らしつつ、価値を引き上げることに成功する。
池田@無名なほう @ikeda
@moongift 当初OSSをカスタマイズして、、って、仕様に合うものがなくて、解析とカスタムの工数考えるとスクラッチの方が楽だった、ってパターンは結構あります。。
MOONGIFT @moongift
時々見かけるのが、その基盤になるOSSに信頼性がないと言ってしまうケース。低予算で苦しみながらスクラッチで組んだシステムより、テストもされているし、何人もの目が通っているし、期間もかかっているのでよっぽども信頼性が高い。
MOONGIFT @moongift
少なくともこれからゼロから組むシステムよりも見えるものがある分まし。
れいな@底なし沼の魔女 @MegaBlackLabel
激しく同意。オレオレFWはねぇ RT @moongift: 時々見かけるのが、その基盤になるOSSに信頼性がないと言ってしまうケース。低予算で苦しみながらスクラッチで組んだシステムより、テストもされているし、何人もの目が通っているし、期間もかかっているのでよっぽども信頼性が高い。
瀬良 @shela_
前提として使う部分をよく知っている人が開発することですよね。知らなければ変わらないか、かえって増加するかもしれない。 RT: @moongift: 次に期間で考えた場合、スクラッチで開発した場合にかかっていた3ヶ月間がOSSだと数週間で終わるかも知れない。
close_yutori @kimukou2628
@moongift Railsのjava版 grails にしてもソースは見れますが GPLの問題があるのでリスク回避&ソース開示の話が難(顧客資産になるのでベンダが判断不可) ただ、どうしてもまずいのは、こっそりパッチっていうのはありますね。OSSの思想的には良くないですけど
MOONGIFT @moongift
とは言え、暗黙的に導入するのもまた思慮が浅すぎる。開発にかける予定だった工数の半分で良いからテスト工数に当てて欲しい。テストは手作業も必要だけれど、ユニットテストやブラウザレベルのテストを行うコードを書いて実行して欲しい。
MOONGIFT @moongift
その結果バグがあればフィックスしてコミュニティに還元して欲しい。それがオープンソースコミュニティとの付き合い方ではないだろうか。
MOONGIFT @moongift
バグフィックスを担当することで内部のシステムも理解できてカスタマイズも容易になる。バグの少ないシステムを納品すれば顧客満足度もあがるし、手離れも良くなる。納期が守れたりむしろ早まればビジネスチャンスも拡大する。
MOONGIFT @moongift
次に大事なのは各個別のプロジェクトにおいてどのOSSが最適であるかを把握すること。自分たちが知っているからといって、何でもかんでもWordPressを使えば良いという訳ではない。顧客ニーズに合わせた選定を適切に行うためには日頃からの情報収集および比較、検証が重要になる。
MOONGIFT @moongift
PHPとPythonとJava、Ruby、C/C++、Perlのどれが向いているのか(予算や規模感、要求レベルによって変わるだろう)、さらにどのフレームワークを選定するべきか、どのアーキテクチャで行くかなど。
残りを読む(54)

コメント

flat/京山和将@昼夢堂:ゲムマ秋土曜Q10 @flat_ff 2010年9月15日
オレオレフレームワークも悪くない。ただし自己学習において。 特定アプリ専用のつもりで組んだときが一番勉強になったけど、そのフレームを他で使おうとすると破綻しました。 それもそれでいい経験だったけどね。
倉瀬美都 @clausemitz 2010年9月16日
OSSで安くなるは幻想に同意。ITドカタ時代に所属していた会社で、とあるOSSのクラスライブラリを使おうとしたらドキュメントがしょぼくて、ソースコードを解読しないと使えないということになって、こんなものを解読するよりも自分らで作ったほうが早いという結論になったことがあったようなw 
ログインして広告を非表示にする
ログインして広告を非表示にする