HOMEコラム今回は少し現実的な話しをします。

コラム Column

コラム

※本コラムの投稿は個人の意見です。従いまして共感を得るか、反論をかうか、皆様の広い御心でお読み頂きお役に立てれば幸いです。

2017年9月29日

今回は少し現実的な話しをします。

ペンネーム:maokit

オープンソース製品(以降OSSと記載)を導入にあたり、考える事の一部として以下3つを挙げます。
・構成要素
・ライフサイクル
・アプリケーション開発

構成要素について

 システムは様々な要素で構成されます。
 仮想化、OS、セキュリティー、データベース、ミドルウェア、フレームワーク、アプリケーション、実行するための前提環境や利用するクライアントサイドの製品などなど。
 すべての要素の組み合わせが保証されている訳ではないので、自社責任で製品選定や検証(単体や組み合わせ)を行います。
 また、各要素はスキルが違うため、各分野でのスペシャリストの雇用や増員が必要となるかもしれません。
 コストダウンを目的として OSS を採用したのに、TCO が増えては意味がありません。

ライフサイクルについて

 OSSはコミュニティーにより開発されています。
必要なシステムはどれくらいの期間利用するかの考慮が必要です。
 長期の利用が想定されるシステムでは、構成要素の一部がバージョンアップを余儀なくされたとき、最悪アプリケーションが動かない場合もあります。
 この様な問題は基本的にはコミュニティーの活動により解決されることが多いです。
 しかし、最悪「運用開始後にコミュニティーによる開発が停止された」という事もありえます。
 製品選定では、コミュニティーの活動が活発か、安定運営されているかも知る必要があります。
 修正パッチの提供が頻繁であったり、情報が豊富であったり、FAQ が運営されていたりなどが材料となります。

アプリケーション開発について

 アプリケーションを開発する際、開発言語の選定は勿論ですが、フレームワークの利用も考慮します。
 OSS のフレームワークにも色々な種類、製品があります。
 サーバーサイドで利用するもの(例:ZendFraemwork)や クライアントサイドで利用するもの(例:AngularJS)など様々なものがあります。
 フレームワークを利用することで開発コストを抑えつつ品質を上げることが可能になります。
 しかし、利用することでコーディングはフレームワークに依存することとなります。 
OSS フレームワークは種類も多く、また移り変わりが激しいため、何をスタンダードとすれば良いかは一概には言えません。
 何を利用するのか、コミュニティーの活動状況は勿論、世間の動向、今後のアプリケーション開発の方針なども考える材料となります。

総じて

 必要とするシステムの利用者への影響度、規模、収益性などが大きいほど慎重に考える必要があります。
 製品により、ディストリビューターから導入/開発/運用などのサポートが有償で提供されるものもあります。これらを自社で行うのか、アウトソースするかの選択が可能です。

 「なんだか大変そうだな」そんな言葉が聞こえてきそうですね。
 ですが「無意識に利用されている」程、メリットは非常に大きいのです。
 では、どうすれば良いのか、この続きは次のコラムをご期待ください。