もっとオープンソースしたいと社長に言われたら～ OSS利用の成熟プロセス試案

Estación del Norte

IT企業なのに、
「オープンソースにしたら、売り上げは上がるのか」
「オープンソースにしたら、優れたエンジニアを採用できるのか」
「オレの若いころは・・・」
みたいなことを、まわりの上司や社長に聞かれたことはありませんか。

そんなことを聞く人ほど、オープンソースについて誤解していたり、いまだ偏見をもっていたり、自分ではまったくオープンソースソフトウェア(OSS)を使っていなかったり、使っていたとしてもOSSだと気づいていなかったり。中小・中堅のシステム開発会社みたいなところを想定しているんですが、IT技術を売りにする企業として、オープンソースに対する理解が、今どきそれはまずいだろうという感じです。そんな上司や社長は、まだまだ少なくありません。

そこで、本稿では、そんな上司や社長がいるIT企業に勤めている人のために、OSSの利用や、オープンソースプロジェクトへの参画について、どんなふうにすればいいのか整理してみました。

IT技術にたずさわる人たちが、上司や社長とオープンソースのビジネス利用について話をするとき、いくばくかの参考になれば良いのですが。

OSS成熟度

カーネル読書会などオープンソース系の各種勉強会で活躍する吉岡 弘隆さん(hyoshiok)は、OSS成熟度というのを2013年に提案しました。OSSを利用するユーザー企業が、従業員個人ではなく、組織として、どのような段階を経て、企業競争力の向上に役立てていくのか、その物差しとして提案しています。

吉岡さんが提案するOSS成熟度は、次の4段階になっています。

  1. 発見(find)
  2. 利用(use)
  3. 参加(participate)
  4. 革新(innovate)

OSSは無料なので取りあえず使ってみたというフェーズ（発見）から、導入にはそこそこ手間暇・コストがかかるということを発見し、それでも、メリットがあるので本格的に導入（利用）し、利用を続けていると、意図をしたわけじゃなくても問題を解決しフィードバックを行ったり（参加）する。最終的には、OSSの特徴を生かし、組織の競争優位性を確保するために活用する（革新）。
OSSそのものをビジネスとしているベンダー企業側の観点ではなく、ユーザ企業視点でまとめてみた。
未来のいつか/hyoshiokの日記：OSS利用の成熟度
http://d.hatena.ne.jp/hyoshiok/20131229/p1

使用から参加へ、つまりインプットからアウトプットへ、徐々に軸足が移っていくという感じですかね。短い記事なので直接読んでもらうといいと思います。

とはいえ、このOSS成熟度では、ちょっと大雑把すぎると感じました。参加から革新が、一段階とか。ユーザー企業を対象に想定しているけれど、企業の競争力の源泉がOSSになる企業なんて、どれだけあるのか、とか。ユーザー企業とはいえ、GoogleやFacebookや楽天とか、それ確実にIT企業だろ、みたいな。

冒頭のIT企業の社長さんに対して、これで話が通じるかというと、ちょっと個人的には想像がつかない。

そこで、中堅・中小のIT企業を対象にして、OSSの利用について、もう少し具体的な話をするための指針を考えたい。

CMMI：能力成熟度モデル統合

では、違う方向から考えて見ましょう。OSS利用ではありませんが、ITシステムの開発プロジェクトマネジメントには、CMMIというのがあります。

能力成熟度モデル統合 のうりょくせいじゅくどモデルとうごう – Wikipedia
英: Capability Maturity Model Integration, CMMI

組織がプロセスをより適切に管理できるようになることを目的として遵守するべき指針を体系化したもの
評価の対象となる領域は、さまざまであり次のようなものがある。

  • ソフトウェア開発
  • システム開発
  • プロジェクト管理
  • リスク管理
  • システム調達、情報技術 (IT) サービス
  • パーソナルマネジメント

http://ja.wikipedia.org/wiki/%E8%83%BD%E5%8A%9B%E6%88%90%E7%86%9F%E5%BA%A6%E3%83%A2%E3%83%87%E3%83%AB%E7%B5%B1%E5%90%88

CMMIには、5つの成熟度レベルがあって、具体的には、こんな感じになっています。

CMMモデルの特性
(Wikipediaの英語版に図解があったので、日本語版を作ってみました)

  • 成熟度レベル1 初期（Initial）：多くの場合、プロセスは場当たり的で、組織は安定した環境を提供しない
  • 成熟度レベル2 管理された（Managed）：何らかの基本的なプロジェクト管理を(個別に)行い、費用と予定を管理している
  • 成熟度レベル3 定義された（Defined）：組織の標準プロセスが確立しており、時が経つにつれ標準プロセスは改善される
  • 成熟度レベル4 定量的に管理された（Quantitatively Managed）：ソフトウェア開発プロセスやソフトウェア保守などのための定量的な品質の目標を設定する
  • 成熟度レベル5 最適化している（Optimizing）：段階的および革新的な技術的進歩を通じた継続的なプロセスの有効性の改善を重視する。 組織にとっての定量的なプロセス改善の複数の目標が定められる。

ちょっと抽象的な内容なので、私なりに解釈すると、こんな感じでしょうか。

CMM_continue.ja

「レベル１：初期」では、ほったらかしの開発プロジェクトが、「レベル２：管理された」では、プロジェクトごとチームごとのローカルルールで運営されるようになり、「レベル３：定義された」では、全社の共通ルールとして定義されるようになります。作業日報を付けるとか、そういう定性的な活動とかですね。で、「レベル４：定量的な管理」で、数値に基づいて管理するようになる。ただ作業日報を出すのではなく、何らかの方法で作業進捗度を測定して報告するという具合でしょうか。そして「レベル５：最適化している」では、それらの測定結果に基づいて、PDCAサイクルをまわして継続的改善することがルール化されて実行されている。

レベル２からレベル３という組織全体の適用を飛ばして、ローカルルールのまま、定量的に継続改善している場合もあるかもしれませんが、CMMIでは組織の成熟度をテーマにしていて、手法の成熟度ではないってことでしょうか。

このようなCMMIモデルなら、ITシステムの開発プロジェクトが対象なので、IT企業の共通言語として理解してもらえそうです。オープンソースの活用の場合でも、このCMMIを枠組みにしたら、IT企業の社長さんにもハラ落ちしやすいかも。

知財戦略の枠組み

知財戦略の共通言語といえば、コンサルティング会社のPwC(プライスウォータハウスクーパース)が、次のようなIP戦略の成熟度モデルを公開しています。

知財戦略 成熟度
IPマネジメント
http://www.pwc.com/p1/ja/industries/technology/research-and-development/ip-management.jhtml

これなんかも、「野放し」→「ローカルルール」→「共通ルール」→「全体戦略」と進んでいくところは、CMMIモデルとよく似ています。また、こういう知財戦略であれば、企業の法務担当者には、共通言語として理解してもらえるかも知れませんね。

しかし一般的に、中堅・中小IT企業の法務部門は、さほど強力とは思えません。また、知財を企業戦略の中心にすえるほど、IPを抱えていません。せいぜい自社開発ソフトウェアのライセンスくらいで、特許や商標を活用するところまでは、ちょっと遠いのが実状ではないでしょうか。

それと、これまでの知財戦略が対象にしてきたのは、IPの囲い込みやライセンシングモデルなので、オープンソースやオープンイノベーションといったオープン戦略とはちょっと相容れないところもあるでしょう。いきなり、こんな話をされても、法務部門の人たちには、ピンと来るんでしょうか。このあたりをもうちょっと精緻に整理する必要があるかもね。

あと、ソフトウェアを自社開発すると、資産として会計処理しなければいけないとか財務戦略的なネタがあるんですが、これをオープンソースに適用するとどーなるんだとか、よく分からないので誰か解説してください。

IT企業は知っておきたいソフトウェアの会計処理の４の知識
http://kigyou-no1.com/webservice-accounting-126

閑話休題

OSS利用の成熟プロセス

さて、それではOSS利用の成熟プロセスを考えて見ましょう。

まず、使用と参加つまりインプットとアウトプットという2つのプロセスがあるので、インプットから。

oss_input_process

  • レベル0. 混乱・無理解
    • よく分からなくて使えない
    • 調べる能力がない。評価する能力がない
    • 情報は共有されていない。メリットは評価されない
    • ⇒ エンジニアや委託先が勝手に使っている。Webからソースが混入
  • レベル1. 無料ソフト
    • とりあえず使っている
    • 個々のOSSのコスト・品質・性能を享受
    • 使用に関するルールはない
    • ⇒ チーム・プロジェクト単位で、使えるよう誰かが取り組む
  • レベル2. 部門で使用
    • オープンソースをわかっている人がいて、部門やチーム個別に対応
    • 全体へは浸透していかない
    • ⇒ 全社の共通ルール(使用と参加)を策定
  • レベル3. 全社で使用
    • OSS利用が、事業に取り込まれている
    • 戦略的に使って、使っていないところより競争力を向上

続いて、アウトプットの側

oss_output_process

  • レベル1.個別アウトプット
    • エンジニアが個別にパッチ・ソースを公開
    • エンジニアが個人として公開したソースを、シゴトとして社内利用
    • エンジニアが個人で、ブログや勉強会で発表
  • レベル2.全体アウトプット
    • 自社のナレッジを公開（公式のエンジニアBlog）
    • 自社開発ツールやライブラリなどをオープンソース公開
  • レベル3.コミュニティ支援
    • 社外にあるコミュニティ活動を支援（モノ・ヒト・カネ）
    • コミュニティの成果を、積極的に社内に取り込む
  • レベル4.コミュニティ主導、標準化を主導
    • OSS開発に関わるエンジニアがコミュニティで主導的な役割を果たす
    • 自社製品のOSS版を提供。社外からの貢献が自社製品の品質を上げる

インプット側のプロセスの後に、アウトプット側があるのではありません。両方のプロセスが平行していると考えています。だから、インプット側で部門側で使っているエンジニアが、アウトプット側で個別アウトプットしている、なんて場合もあるでしょう。全社で戦略的にOSSに取り組んでいる企業が、OSSコミュニティの活動を強力に支援している場合もあるでしょう。

2つのプロセスを並べると、こんな感じになります。

oss_io_process

インプットの「部門利用」とアウトプットの「個別アウトプット」が対応しています。また、「全社で使用」の先は、社外での使用になっていくので、「コミュニティ支援」や「コミュニティ主導」にも対応します。

どんなふうに関わるのか

では、このような成熟プロセスに対して、企業はどのように関わればいいのでしょうか。

まずは、自社のレベルを見極めて、その次のステップを目指すというのが良いと思います。理想は高く持つべきかも知れませんが、実際的には一段ずつ進んでいく必要があるでしょう。

いちおう、中堅・中小のIT企業を想定しています。大きな企業は、全社で戦略的に取り組むには、規模が大きすぎたり、すでにそれなりの人が中にいてバリバリ活動していることも多いので、いろいろなレベルが混在しているんだと思います。

通常、企業の法務部門の人たちが関係するのは、インプット側のレベル３のところだけ。レベル１-２のところは、全社的には捕捉されていませんし、アウトプット側には法務部門の仕事がない(アウトプットさせないという仕事だけ)。だから、この全体の関わりを考えるのは法務部門には荷が重いはず。

あと、アウトプット側に企業が関わったり、そこから優秀なエンジニアを引っ張ってこようと思ったら、やはり自分たちがそこに飛び込んでみる以外の方法がないと思います。なぜなら、すでにそこにいるエンジニアは、その外側で仕事をしようと普通は思わないから。

特に、Web系やクラウド関係は、オープンソースのほうが商用プロダクトより技術的に進んでいる場合も少なくないので、そこにカンが働かない企業というのは、もうそれだけで技術的に遅れていると評価されてもおかしくないでしょう。

という訳で、企業が、こういう方針や戦略の全体像を考えるには、社長やマネジメントが自分から飛び込んでみる以外にないと思います。

最近は、オープンソース系の勉強会やイベントが、いたるところで頻繁に開催されているので、億劫がらずに出かけてみると良いと思います。

なお、本稿は、個人的な経験や見聞きしたことや、私自身の膨大な妄想からできているので、大いに間違っている可能性があります。こういうふうにレベルを分けたほうがいいとか、異論反論など、コメントをお寄せいただければ幸いです。

クリエイティブ・コモンズ・ライセンス
この 作品 は クリエイティブ・コモンズ 表示 4.0 国際 ライセンスの下に提供されています。

このエントリーをはてなブックマークに追加