オルタナティブ・ブログ > エンタープライズ系エンジニアの小話 >

ここ数年は何かしらのサービスの立ち上げをやっています。技術者の視点だけでなく経営者などの視点を織り交ぜながら色々とお届けします!

パッケージ、オープンソース、スクラッチ開発をQCDの観点で比較

»

前回はどのような業務システムがオープンソースとして存在しているのかご紹介させていただきました。

今回はQ(品質)C(コスト)D(納期)の観点でパッケージ、オープンソース、(セミ)スクラッチ開発でそれぞれの特徴をお届けします。

また、QCDの観点の中で何を持ってどのシステムが優位として導入を進めていくのか、その辺りのヒントになればと思います。

言葉の定義

今回の「スクラッチ開発」はkintoneやforce.comを利用した「セミスクラッチ開発」として記載しています。フルスクラッチ開発が必要な場合は特殊な事情が重なり、このような形で比較しても意味がありません。

また、「パッケージは」オンプレミス(自社サーバ等にインストールして利用する形態)だけでなく、SaaS(サービスとして提供され、ネットワーク経由で利用する形態)も含まれます。一言で表すと「商用の製品を方法を問わず提供しているもの」をここではパッケージと記載しています。

パッケージ、オープンソース、セミスクラッチの比較一覧

パッケージオープンソースセミスクラッチ開発
品質(Q)
コスト(C)
納期(D)

まずは特徴の結論です。全てがこれに該当するわけではありませんが、上記のような傾向があります。以下で詳しく解説します。

品質(Q)

・機能
・使い勝手
・デザイン(見た目)

私がエンジニアだからかもしれませんが、品質と言われると不具合の量や安定稼働を思い浮かべてしまいます。

しかし、これらは蓋を開けてみないとわかりません。新機能の追加やバージョンアップしたらいきなり不安定になることもあります。よほど過去の実績が悪くない限り考慮する必要はありません。

そのため、ここでは目的を達成するための機能や使い勝手などがどの程度満たされるのかが重要です。

・パッケージ ◎

汎用性が高く、機能が充実している傾向があります。また、見た目や使い勝手に関しても工夫を凝らしていることが多く、業務フローの見直しなどと組み合わせれば要件を十分に満たすことが可能です。

・オープンソース ◯

こちらも汎用性が高い傾向があります。しかし、機能を必要最低限しか取り揃えていないことや見た目などがパッケージと比べて劣るケースが多々あります。

・セミスクラッチ開発 △

多くの場合が要件定義で決まった内容の機能しかありません。また、予算の都合等により見た目への考慮がされないケースがあることや、使い勝手を落として一部の機能を要件から削ってしまうこともあります。

コスト(C)

・導入費用(イニシャル)
・運用費用(ランニング)
・3年間の上記合計費用

手元現金がない、あるいは減らしたくないために導入費用を抑えたいのか、今後に備えて固定費を上げないようにしたいのか、会社によって都合があります。どちらにしても導入してすぐに辞めることは想定しないと思いますので、初期費用と運用費用だけでなく3年程度のトータルコストも含めてご判断されるのがよろしいかと思います。

また、成長軌道にうまく乗っていない企業は、人件費の削減、売上/利益を増やすための仕組みを作れるなどの投資対効果が期待できなければ本当に必要であるか考え直すことをお勧めします。

・パッケージ △

買取型のライセンス形態か、月額利用料の2つのパターンがあります。3年間のトータルコストで考えると、どちらもそれなりに高額になるケースが多く見受けられます。また、利用人数と費用がほぼ比例するため、コストが上昇しやすい特徴があります。

・オープンソース ◎

社内にITエンジニアがいればほぼ無料で使うことができます。社内にITエンジニアがいないことや社内リソースを消費したくない場合は外注することも可能です。外注費はパッケージの導入、運用費用と比較すると安価になる傾向があることや、人数が増えてもインフラ費用以外はあまり変わらないためコストが変わりにくい特徴があります。

・セミスクラッチ開発 ◯

大規模が大きくなればなるほど初期費用が高価になります。また、kintoneやforce.comなどの基盤を利用するとそれの利用費用が毎月掛かってきます。さらに保守として構築したベンダーとの契約も必要となり、オープンソースと比較するとトータルコストが上昇しやすい傾向があります。また、些細な変更でも費用が発生することが多々あり、保守費用以外にもコストが掛かりやすい傾向があります。ただし、知恵を絞ればパッケージよりも安価に出来ることもあります。

納期(D)

・納品までのリードタイム

まず、導入したいシステムを「今すぐ必要」、「もうすぐ必要」、「いずれ必要」で分類しましょう。「いずれ必要」であれば「もうすぐ必要」になるまで考え直してください。「いずれ必要」のままであれば導入を見直してください。本当に「いずれ必要」であれば誰も使われないお荷物になり、「もうすぐ必要」に変わった時にはもっと良いものが出てきています。

話がそれましたが、「今すぐ必要」であればこの観点の重要度が上がります。「もうすぐ必要」であればその他の観点と比べて重要度を下げて考えてください。

・パッケージ ◎

申し込んですぐに使い始めることが可能です。CRMやSFA、ERPなどの複雑なシステムになると業務にマッチする形に設定を変更する必要があります。しかし、多くの場合がすぐに利用可能です。

・オープンソース ◯

社内にITエンジニアがいればすぐに使い始めることが可能です。ただし、パッケージよりもひと手間掛かるイメージです。また、業務とフィットしない部分に関してカスタマイズを加えるなどやり始めるとリードタイムが長くなってきます。

・セミスクラッチ開発 △

要件定義から必ず始まるため、上記2つよりもリードタイムが長くなる傾向があります。また、開発規模によっては2ヶ月、3ヶ月とリードタイムが拡大していきます。

まとめ

パッケージ、オープンソース、スクラッチは手段であって、それが目的ではありません。導入の目的を定め、それに従った観点で検討していただければと思います。

例えば、「売上アップ、営業力強化」が目的であればソフトブレーン・サービス株式会社の営業マン育成コンサルティングとソフトブレーン株式会社のeセールスマネージャーの組み合わせが効果が高いので、それを採用するという形です。

あるいは「某社CRMが高すぎるのでコストをとにかく下げたい」のが目的であれば、当社が管理するオープンソースF-RevoCRMとカスタマイズサービスを組み合わせれば、コストを下げつつ業務にフィットしたものを作ることができるでしょう。

また、上記は「傾向」を表していますので、「これは絶対に採用しない!」という話ではありません。お付き合いするベンダーの能力などとも密接に関わりがありますので、まずは目的に合わせたベンダーに声をかけて、QCDの観点で絞り込みをしていくような検討をお勧めします。

Comment(0)