ソフトウェア

2017/05/05

ソフトウェアの複雑性は本質的な性質であって偶有的なものではない

「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」を気軽に読んでいたら、ブルックスの人月の神話の一節が書かれていて、今頃になって、すごく腑に落ちたのでメモ。
ブルックスの人月の神話の文章のうち、自分が理解できたことを、ラフなメモ書き。
以下は書きかけ。

【参考】
第0回:人月の神話とはなんなのか?(解説編)|本気で読み解く”人月の神話” | GiXo Ltd.

第2回:銀の弾は無いけど、”銃”はあるよね|本気で読み解く”人月の神話”(第16章) | GiXo Ltd.

ソフトウェア開発とは、現実世界の複雑さをプログラムコードの難しさに置き換える作業だ - セカイノカタチ

ソフトウェア開発でよく言われる「銀の弾丸など無い」とはどういう意味なのか本を読んでみた。 - 感謝のプログラミング 10000時間

【1】ソフトウェアの複雑性は本質的な性質であって偶有的なものではない。

「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」の内容自体は10年以上前のWebやIT業界の話が多く、内容も古くなっているので、新たな知見が得られるという感覚はしない。
しかし、「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」の中に、「ソフトウェアの複雑性は本質的な性質であって偶有的なものではない」という言葉があって、すごくしびれた。

(引用開始)
ソフトウェアの複雑性は本質的な性質であって偶有的なものではない。
したがって、複雑性を取り去ったソフトウェアの実体の記述は、しばしばその本質も取り去ることになる。
数学や物理学は、複雑な現象を単純化したモデルを構成し、そのモデルからある性質を引き出し、実験的にその性質を証明することで、3世紀にわたって偉大な進歩を遂げた。
この方法でうまくいったのは、モデルで無視された複雑性が現象の本質的な性質ではなかったからだ。
複雑性が本質である場合には、この方法は使えない。
(引用終了)

上記の内容は、ブルックスの「人月の神話」の一節そのまま。
なぜ自分がすごく衝撃を受けたのか、考えてみると、ソフトウェア開発の本質に触れているものだから。
たぶん、僕の心のなかにある、ソフトウェアに対する楽しさだけでなく、ソフトウェアへの憎しみというか、なぜこう思い通りにソフトウェア開発をコントロール出来ないのか、という腹立たしさに触れている気がしたから。

「偶有的」という言葉も引っかかる。
この言葉は、古代ギリシャのアリストテレスの哲学から引用したものらしい。

(引用開始)
アリストテレスに従って、難しさを本質的なものと偶有的なものに分けて考えてみよう。
ここで、本質的な複雑さとは、ソフトウェアの性質に固有な困難のことであり、偶有的難しさとは、目下の生産にはつきまとうが本来備わっているものではない困難のことである。
(引用終了)

自然科学、特に数学や物理学では、できるだけ単純なモデルを作り、そこから演繹される性質や定理を証明することで、自然現象を多面的に分析しようとする。
複雑なものを複雑なまま捉えるのではなく、理想的な単純なモデルに純粋化して、人間の思考に耐えられるレベルにして、数多くの観点で徹底的に分析するのが自然科学のやり方。
シンプルなモデルを「徹底的に」分析し尽くして、全ての特徴を洗い出し、全てを因果関係や演繹でまとめ上げて一つの理論体系にするのが自然科学のやり方。

すると、シンプルなモデルをどのように事前設定するか、どのパラメータを重視して選択しておくか、というのが重要になる。
その部分が、科学者の腕の見せ所。

たとえば、物理学では、理想気体みたいに、現実から離れるけれど、シンプルなモデルを設定することで、計算や実験を扱いやすくするモデル作りは一般的だ。
熱力学、相対性理論、量子力学など、色んな分野の物理学でもその手法を用いている。

物理学は一つの認識論: プログラマの思索

数学でも、一流の数学者は、自分で理論を打ち立てたい時、最も組合せの少ない公理や公準を直感的に選んで、そこから矛盾が生じないように設定しておく。
そこから、「誰々の定理」のような重要な結果を導き出す。
一流の数学者がすごいのは、最も組合せの少ない公理を直感的に把握できること、そして、重要な定理を導く時に、ロジックの穴になりそうな難しい場所を事前に察知して、それをくぐり抜けるために、あらかじめ「誰々の補題」みたいな補助的な公式を用意しておくのが上手い点。

技術の背後に数学の理論があると廃れない: プログラマの思索

数学や物理は背景にある思想を知らなければ理解できない: プログラマの思索

このやり方がすごく成果を上げているので、人文科学や社会科学でもそのやり方を真似ているように思える。
特に、経済学は典型的だろう。
マクロ経済学やミクロ経済学みたいに、人間は合理的に行動する、とか、市場の価格は恣意的な手段で決めても長続きせず、神の手(つまりは市場原理)で決まる、みたいに、現実とかけ離れた仮定をおいて、数多くの経済モデルを作り、そこから重要な経済学の定理を導き出す。
単純な経済モデルから得られた経済学の定理で現実に通用する場面が過去にあったから、経済のグローバル化が世間に言われ始めてから、世の中の経済事象は、市場原理で決まる、いや決めるべきだ、みたいな論調が多い気がする。

経済数学の直観的方法の感想: プログラマの思索

「推計学のすすめ」「経済数学の直観的方法~確率統計編」の感想: プログラマの思索

しかし、ブルックスの「人月の神話」では、ソフトウェアにはそのやり方が通用しない、という指摘をしている。
「ソフトウェアの複雑性は本質的な性質であって偶有的なものではない」からだ。
つまり、複雑性を排除したソフトウェアは、ソフトウェアの本質を意味しないからだ。

【2】ソフトウェアの本質的な複雑さと、偶有的な複雑さの違いは何か?
ソフトウェアの本質的な複雑さは、リーマンの法則そのものを指すと思う。

リーマンの法則~ソフトウェアもエントロピー増大の法則を避けられない: プログラマの思索

リーマンの第1法則
 使われるシステムは変化する。
リーマンの第2法則
 進化するシステムは複雑性を減らす取り組みをしない限り、システムの複雑性が増す。
リーマンの第3法則
 システムの進化はフィードバックプロセスによって決まる。

(引用開始)
レーマンとベラディは、大規模なオペレーティングシステムのリリースについて、継続してその変遷を研究してきた。
そこで分かったことは、モジュールの総数はリリース番号とともに線形に増加するのに対し、影響を受けるモジュールの数はリリース番号に対し指数的に増加するということだ。
(中略)
システムプログラムの作成は、エントロピーを減らす仮定だから、本来は準安定なものである。
他方、プログラムメンテナンスはエントロピーが増加する過程であり、どんなに器用に行なっても、できるのはシステムが修正不能な陳腐化へと沈んでいくのを遅らせることだけである。
(引用終了)

(引用開始)
ソフトウェア製品開発に関する古典的問題の多くは、その本質的な複雑性と、ソフトウェアの大きさに従ってその複雑性が非線形に増大することに由来している。
(引用終了)

この文章を読んで思い出すのは、ケント・ベックがXPを生み出した経緯のことだ。
ケント・ベックは、ソフトウェア工学の授業で習った、リリース総数が増大するにつれてソフトウェアの複雑度や変更コストが増大していく経験則に対して、異議を唱えた。
時間が進むに連れて、この曲線を頭打ちにできるような開発プロセスはないのか、と。

- eXtreme Programmingの魅力を探る オブジェクト倶楽部

(引用開始)
「変化ヲ抱擁セヨ」
この呪文めいた言葉は,Kent Beck による本の副題として掲げられている. 時間を横軸に,ソフトウェアの変更にかかるコストを縦軸にプロットする.
この「時間-変更コスト」曲線は極端な右上がりになると信じられて来た(図左).
すなわち,要求分析,設計,実装,テスト,保守,と時間が進むにつれ, 変更にかかるコストが増大するというのだ.
現在までのソフトウェア開発プロセスは,この仮定上の議論が多数 だったのである.
XP はこの曲線を平坦にできるのではないか, また,そうできたとしたら,全く違った方針でプロジェクトに立ち 向かえるのではないか,という挑戦をしている(図右)
(引用終了)

こういう素朴な問題意識はすごく重要だと思う。
XPがその理想を本当に実現したのかどうか、は検証がいると思うが、そういう背景を元にアジャイル開発のプラクティスが生まれたことは、アジャイル開発が従来のソフトウェア工学と対立しがちに見える傾向を示唆しているように思える。

ちなみに、上記の第1版の「XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法」に、上記の「従来のソフトウェア工学が提唱しているソフトウェア複雑性へのXPの果敢な挑戦」の文章と図はあるのに、第2版の「エクストリームプログラミング」から削られていることだ。
とても残念。
この部分がXPにとって一番重要な主張なのに。

【3】コードクローンと再利用性。

(引用開始)
ソフトウェア実体の本質とは、データセットやデータ項目間の関係、アルゴリズムや機能呼び出しなどが組み合わさったコンセプトで構成されたものである。
この本質は、同じ概念構造体が多くの異なる表現で表されるという点で抽象的である。
それにもかかわらず、非常に正確で十分に詳細なものである。
(引用終了)

コードクローンとは、同一アルゴリズムを各プログラマが別々の実装したプログラムのことだ。
上記は、ソフトウェアの複雑性が増大しがちな理由の一つは、コードクローンが大量に発生しがちである、と言う点を示唆していると思う。

ソフトウェア工学の論文を見ていると、コードクローンのメトリクス採取の記事が割と多い。
その理由は、コードクローンを減らす方がソフトウェアの複雑性が減るので、良い、という主張が隠れているのではないか。

では、なぜコードクローンは良くないのか?

(引用開始)
ソフトウェア実体は、どの2つの部分をとっても似ることがないので、大きさの割にはおそらく他のどの人工構造物よりも複雑なものだ。
似通っている部分があれば、2つの類似部分を1つにする。
この点において、ソフトウェアシステムは、重複要素(部品)が豊富なコンピュータやビルあるいは自動車などとは全く異なっている。
(引用終了)

その理由は、ソフトウェアの再利用が進まないからだ。
たとえば、自動車やパソコン、スマートフォンのような工業製品は、再利用可能な汎用部品を組み立てる手法と大量生産することを組合せることで、規模の経済を生かし、経験曲線効果を生かして、1個当りの製造コストを劇的に減らす。
しかし、この「規模の経済」「経験曲線効果」というコストメリットを享受しうる生産手法がソフトウェア開発には全くといっていいほど通用しない。

ソフトウェアを部品化して、スマートフォンみたいに部品を組み立てるように製造したい、と考えて、CORBAとかEJBのようなコンポーネント駆動開発、製品ファミリー群の製品開発手法であるソフトウェアプロダクトラインとか色々考えられたけれど、どれも実用的ではない。

ソフトウェア部品化の幻想: プログラマの思索

ソフトウェアプロダクトラインが解決しようとするもの~品質と再利用: プログラマの思索

だから、多額の資金を設備投資に投入して、最新の機械で汎用部品を組合せて大量生産する生産手法がソフトウェア開発には馴染まない。
ソフトウェア開発は徹頭徹尾、経験曲線効果すらも有効でない労働集約的な生産手法に似ているように思える。

【4】ソフトウェアの本質的な複雑性とは、同調性、可変性、不可視性。

【4-1】同調性は、リーマンの言う組み込まれた(Embeded)プログラム、を連想する。

「ソフトウェア・グラフィティ」の感想: プログラマの思索

(引用開始)
支配しなければならない複雑性の多くは気まぐれによるものだ。
インターフェイスを人間の社会制度やシステムに適合させるべく、いわば是非もなくそれらによって強制されているからである。
(引用終了)

最近、業務システムとかERPに僕自身が少し興味をなくしているのは、システム化したい業務そのものが元々複雑過ぎて、それを整理しようと言うよりも、現実の業務をいかに忠実にシステム化するかに注力する案件の方が多いからだ。
元々の業務が、日本的な複雑な組織体制を元に作られていれば、複雑なのは当たり前であり、それを忠実にシステム化するなら、複雑怪奇なままだ。
日本では、ERPをBPRとして捉えるよりも、自分達の業務中心に考えすぎているために、システムも複雑怪奇になりやすいような気がしている。

【4-2】可変性は、ソフトウェア品質の移植性や保守性を連想する。

アジャイル開発が重視する品質特性~保守性と移植性: プログラマの思索

(引用開始)
ソフトウェア実体は、つねに変更という圧力にさらされている。
(引用終了)

XPの言う「変化を抱擁せよ」と同じ。
ソフトウェアにとって、VerUpは宿命であり、常に変化が内在している。
ソフトウェアは変化しない固体として存在し得ない。

(引用開始)
純粋な思考の産物であってきわめて融通性に富んでいるので、ソフトウェアがより簡単に変更できるということもある。
ビルも現実には変更されるものだが、だれもが了解しているように、変更コストの高さが思いつきで変更しようとする者の気をくじく働きをしている。
(引用終了)

ソフトウェアに、仕様変更という名の保守はつきものだ。
それは簡単にできるように思えるから、簡単にソフトウェアに手を入れて、潜在バクを埋め込んでしまう。
ソフトウェア品質特性のうちの保守性を連想させる。

(引用開始)
大当たりしたソフトウェアはまずたいてい、すべて変更される。
あるソフトウェア製品が役立つと分かると、人々はもともと処理対象としていた領域ぎりぎりもしくはその領域を越えるような新しい使い方を試してみようとする。
主として、拡張機能のために変更して欲しいという圧力は、基本機能が気に入っていて新しい使い方を考えだす利用者から出される。
(引用終了)

これは、たとえば、Redmineが当初のバグ管理の使い方から、タスク管理、そして、アジャイル開発やWF型開発、さらには、事務処理ワークフロー、ハードウェア資産管理システムへ使い道がどんどん広がっていった事例を連想させる。
本来想定しなかった使い方が一般的になってしまい、その使い方をさらに使いやすくしたり、機能改善することで、ソフトウェアの複雑性がどんどん膨張する。
あらゆるソフトウェアは機能追加という変化にさらされている。

(引用開始)
大当たりしたソフトウェアは最初に書かれた対象である機械機器の通常の寿命よりも長く使用され続ける。
要するに、ソフトウェア製品はアプリケーションや利用者、慣習および機械機器といった文化的マトリックスにすっかりはめこまれているのだ。
そしてそれらは絶えず変化し続けるものであり、その経kながソフトウェア製品に容赦なく変更を強制するのである。
(引用終了)

たとえば、OSやDBやミドルウェアのバージョンアップとか。
あるいは、サーバー本体のリプレースとか。
たとえば、WindowsXP廃棄対応、WindowsServerのリプレース、OracleのVerUp、RailsのVerUpとか、iOSやAndroidOSのVerUpとか、色々思い出す。
つまり、ソフトウェア品質特性の移植性を連想させる。

こういうミドルウェアやOSのVerUpに伴うプログラム変更作業は、とてもしんどいものだ、と開発者なら誰でも知っている。
こういうつまらない開発基盤のVerUp作業は、ソフトウェアの外にある外部環境の変化によって生じるものであり、避けることは出来ない。

【4-3】不可視性は、ソフトウェア設計の難しさを連想する。

(引用開始)
ソフトウェアの構造を制限したり単純化したりすることは進歩したにもかかわらず、その構造は本質的に視覚化できないままになっている。
そのため強力な概念上のツールを作る意欲を阻害している。
その欠落は1人の人間の頭の中のデザインプロセスを妨げるばかりでなく、複数の人間の間でのコミュニケーションもひどく妨害する。
(引用終了)

UMLやDOAは、ソフトウェア構造を視覚化する問題を解決しようと試みていた。
SySMLもその流れだろう。

複雑性をコントロールするための設計技法は、歴史上いくつか考えれてきた。

たとえば、Nティア設計。
つまり、レイヤ化。

another level of indirection
「もう一段の間接参照」を導入すると、コンピュータのほとんどの問題は解決できる。

NFuji's Café: 「Beautiful Code」を読む(中)

ポインタを制する者はプログラミングを制する: プログラマの思索

MVCモデル、通信プロトコルの7層モデルもそういう考え方だろう。

他に、渡部幸三さんの観点でのDOAでは、業務・機能・データの3層構造の業務システムにおいて、業務レイヤとデータモデルのレイヤに複雑性を押しこんで、機能レイヤは複雑性をできるだけ減らす設計が良い、と提唱していた。
すなわち、機能レイヤはまさにプログラミングレベルなので、その部分の複雑性はできるだけ減らして保守性を高めようとする考え方。
つまり、複雑性というエントロピーは一定で変わらないと仮定した場合、人が携わる業務レイヤと、データモデルのレイヤに複雑性を落としこんで、複雑性をコントロールしようとするわけだ。

だが、これらの手法で、ソフトウェア本来の複雑性が本質的に解決されたのか、と問うてみると、正直分からない。

【5】一方、ソフトウェアの偶有的な複雑さは個別撃破している。

「高水準言語」は、たとえば、VBよりもRuby。
たとえば、VBはListやHashなどの基本ライブラリのAPIが非常に不足していて使いにくい。
たとえば、Rubyなら、そういう低レベルなライブラリは非常にAPIが揃っていて、VBよりも1行で書ける。
つまり、複雑性を軽減している。

「タイムシェアリング」は、たとえば、コンパイラ言語よりもインタプリタ言語、継続的ビルド管理、構成管理を指すのかな。

(引用開始)
考えていた内容をすっかりというわけではないが些細な点でどうしても忘れてしまう。
(引用終了)

この部分は、まさにソース管理、構成管理を連想させる。
たとえば、CVS、Subversion、Gitに至るまでの構成管理ツールの歴史を振り返れば、ソフトウェア開発プロセスにおけるブランチ管理、マージなどの作業の複雑性は軽減されている。

「統一されたプログラミング環境」はたとえば、VisualStudioやEclipse、IntelliJとか。

つまり、ソフトウェアを開発する作業そのものが生じる複雑性は、今までの歴史で生み出された技術によって、多少は軽減されてきた。
しかし、だからと言って、ソフトウェアの本質的な複雑性を攻略できたわけではない。
あくまでも、以前よりも大きい複雑なソフトウェアをコントロールできるようになった、というだけだ。

| | コメント (0)

2017/01/14

オープンソースのコミュニティの存在意義と知的財産権

OSSコミュニティの継続性の記事がとても素晴らしいので、自分の心の琴線に惹かれた部分だけ引用しておく。
以下、ラフなメモ書き。
特に主張はなし。

【参考】
OSSコミュニティの継続性

ほころびていくコミュニティとなかなかできない世代交代、そしてさよならアドベントカレンダー - Qiita

ゾンビOSSが危ない - [1]オープンソースソフトウエアにも寿命がある:ITpro

【1-1】(引用開始)
日経コンピュータがゾンビOSSと表現した記事を2014年に出している。
ここで根底にあるOSSに対する考え方は「無料で使えるソフトウェア資産」なのだと思う。
それを支える開発者コミュニティへの認知が欠落していて、そこには有用性を見出していないようだ。
(引用終了)

【1-2】(引用開始)
日本では開発者のコミュニティに直接参画しようという動きは少ないように思う。
また、「あるOSSプロジェクトを中心にゆるく連帯した開発者の集団が継続的に存在していること」は、市場における人材育成の点で非常の大きな効果があるという点は、あまり認識されていないように感じる。
(中略)

ソフトウェア技術者の人材流動性が非常に高い米国のような場所では、OSSプロジェクトを開発者資源として活用することで成果をあげている例が多い。
特にうまくOSSを活用しているのはAppleだ。
彼らは社内のビジネスに必要なソフトウェアを、OSSプロジェクトを支援することで得るという手法に長けている。

現在のmacOSの基盤になったRhapsodyが公開されたのは1997年のWWDCだった。Mach 3とFreeBSD 5系のコードを組み合わせてモノリシックカーネルにしたもので、ユーザランドのコンポーネントにもOSSが多く使われていた。現在もツールチェインとしてLLVM/Clangを使う、認証基盤としてHeimdal Kerberosを取り込むなど、開発に非常に大きな労力がかかる部分にOSSプロジェクトの成果を使っている。

また、彼らは単にコードを使うだけでなく、開発者コミュニティにいる開発者を雇用したり金銭的な援助を行なったりして、コミュニティを育てる努力を怠っていない。
OSSプロジェクトが持つソフトウェア資産だけでなく、開発者を資産として認識しているからだ。
差別化が必要な部分は社内で開発し、重要だが開発者コミュニティが存在するソフトウェアはそこに投資することで成果物を利用するという2つの方法のバランスをとって、開発を迅速に進めるとともにコストを低く抑えることに成功したわけだ。
(引用終了)

【1-3】(引用開始)
利用者のコミュニティの継続性は、開発者コミュニティに継続性が前提になっている。
開発者のコミュニティに継続性が欲しいなら、話は単純だ。何らかの形で支援すれば良い。少なくともOSSを理解している個人や企業は、みんなすでにそうしている。
「OSSプロジェクトのソフトウェア資産だけを使い、サポート会社にお金を払う」という関わり方は、開発者コミュニティの継続性に寄与しない。
(引用終了)

日本では、OSSを無料のソフトウェアとみなす考え方が強い。
だから、保守サポートを受けたければ、サポートのある会社に有償でお願いしたほうが安全だ、という方向へ行きやすい。
保守契約や請負契約を結べば、リスクを業者に転嫁できるから。

一方、AppleがOSSとOSSコミュニティを上手く利用している、という意見はとても参考になる。
OSSは単なる無料のツールではなく、優秀な開発者資源の集まりである、という考え方がある。
OSSコミュニティにいる優秀な開発者は、重要な資産なのだ。

コミッタを雇用することで、優秀な開発者を自社に取り込むこともできる。
コミッタを金銭的に援助することで、OSSのツールの継続性を後押しできる。

一点気になるのは、ベンダーという営利企業のステークホルダーがOSSコミュニティに関わることで、OSSの発展の方向性がベンダーの意のままになるリスクは無いのか、という点だ。
詳細は知らないが、Linuxのように、多数のベンダーが入り込んでいるOSSでは、そのようなリスクをどのように排除して、Linuxを発展させようとしているのか、調べてみたい。

【2】オープンソースに関わる内容として、もう一つ気になる点は、知的財産権との絡みだ。
オープンソースのライセンスはGNUが有名でよく使われている。
すると、営利企業のソースライセンスとオープンソースのライセンスの違いが気になってくる。

この辺りの情報もまとめたい。

【3】IT技術者にとって、オープンソースのコミュニティに関わるメリットは、とても大きいと感じている。
製造業の技術者に比べると、IT技術者は、アイデアや成果物の利用について、とても自由度が高い。
その分、活発な活動が行われている、と感じる。

技術士として、他の製造業の話を聞くと、メーカーの技術者は自分の能力をアピールする場が少ないと感じる。
彼らは、論文発表するか、特許や意匠、商標などの知的財産権を取得するか、どちらかを採用している。

特許を取れば、普通は職務発明になるから、会社が専用実施権を持つ場合が多いように見える。
会社の戦略としては、ライセンス戦略になる。
つまり、自分たちの技術を他者が使う場合、ライセンス供与によってライセンス料を得るわけだ。

メーカー技術者は、代わりに「相当の利益」として、金銭やストックオプションとか、他のもので代用する。
しかし、それは嬉しいのだろうか?
自分のアイデア、自分が作った成果物と実質上は言えるが、外向けには会社の知的財産権であり、公の場で詳細な技術の議論はしにくいはずだ。
その代わりに、学会で論文発表することで、意見交換しているみたい。

一方、特許ではなく営業秘密として技術を保持するとなると、公開不可になる。
不正競争防止法で規制される対象になる。
すると、自分のアイデア、自分の成果物を世の中に公表することすら認められない。
会社の戦略としては、いわゆるブラックボックス戦略を取るわけだ。
たとえば、コカ・コーラ、天一など。

技術者にとって、お金も重要だろうが、むしろ、自分のアイデアを世に出して、色んな人達のフィードバックを得たり、技術者と知的議論をしていく方が重要だ、と思うはずだ。
そうでなければ、一発ものの技術で終わってしまうから。

でも、メーカーの技術者は、特許や営業秘密というツールで自分のアイデアや成果物が縛られやすい。
何となく可哀想な気もする。

一方、IT技術者はオープンソースで、自分の成果物を公開することで、他ユーザのフィードバックを得たり、他の技術者からプルリクエストで改善要望をもらえたり、自分の能力をアピールできたりする。
つまり、IT技術者はかなり自由だ。
むしろ、自分の成果物をクローズドにするのはあまり価値がない。
沢山の人に知ってもらい、使ってもらう方が価値が上がる。

「GitHubでソーシャルコーディング」という言葉は、たぶんそんな意味が込められていると思う。

すると、会社の経営戦略としては、プラットフォーム戦略になる。
つまり、ネットワークの経済の概念。
たくさんの人に使ってもらうことで、自分たちの技術をデファクトスタンダード化し、マーケットシェアを上げる。

その戦略を取り続ける場合、Appleの話のように、企業はOSSコミュニティを支援する場合が多くなるのだろう。
OSSコミュニティは、OSS利用者の多いマーケットだけでなく、優秀な開発者という資源がある場所、と捉えるわけだ。
それによって、OSSが長持ちする。

その場合、コミュニティの活発度がOSSが生きている証になる。
普通、ソフトウェアの活発度合いは、バージョンアップの頻度として現れる。
バージョンアップされないソフトウェアは死んだも同じだ。

数多くの利用ユーザのフィードバック、優秀な開発者によるセキュリティパッチや機能改善パッチの迅速なマージなどで、OSSソフトウェアは進化していく。

【4】そんなことを考えてしまったのは、Redmineもそういう意見がチラホラ見受けられるからだ。
Redmineコミュニティもちょっとずつ変わろうとしているのかもしれない。

akipiiさんのツイート: "Mischa The Evilのコメントを読むと、僕も同じような意識を持っている。Redmineはもはや単なる無料のツールではなく、OSSのコミュニティとして大きな影響力を持ち始めている。だからこそ永続的な開発の基盤を求めている。https://t.co/0wmfbPNu4V"

| | コメント (0)

2016/09/25

「ソフトウェアが世界を飲み込む理由」「ソフトウエア、それが問題だ」の記事のメモ

「ソフトウェアが世界を飲み込む理由」「ソフトウエア、それが問題だ」の記事をメモ。
特に主張はなし。

【参考1】
『ソフトウェアが世界を飲み込む理由』 - 渡部薫 ジークラウド CEO - 経歴・略歴 - Kaoru Watanabe, Profile, Career

M・アンドリーセン氏が考える2012年--「ソフトウェアが世界を飲み込む」 - CNET Japan

次の5年でソフトウェアが世界を食べつくす。 | リーディング&カンパニー株式会社

(引用開始)
コンピュータ革命から60年、マイクロプロセッサーの発明から40年、そして近代インターネットが興隆してから20年、ソフトウェアによって産業を変革するのに必要な技術の全てが、ようやく実用化され、世界規模で広く提供されるようになった。
(中略)

私の意見では、医療と教育が、次にソフトウェアをベースとした根本的な変革が起きる分野である。
私のベンチャー・キャピタル会社は、これら両方の巨大で重要な産業において、積極的なスタートアップ企業を支援している。
私たちは、これら両産業は、歴史的に見て起業家精神に基づいた変化に対しては非常に抵抗を示してきたが、現在、新しい、ソフトウェアを中心に据えた偉大な起業家達によって、臨界点に達する時期にきていると信じている。

(中略)
あらゆる産業において各社は、ソフトウェア革命がやってきていることを想定する必要がある。
これには、今現在ソフトウェア・ベースである産業も含まれる。Oracle社やMicrosoft社など、既存のソフトウェア大企業ですら、Salesforce.comやAndroid(特にGoogle社が大規模ハンドセット製造会社を保有している世界では)といった新しいソフトウェアの出現によって、自社製品が陳腐化してしまうという危機にますます脅かされている。
(引用終了)

池田信夫 blog : ソフトウェアが世界を食う

(引用開始)
第二は、労働や教育が大きく変わることだ。
これから先進国では、コーディングができるかできないかで収入は桁違いに変わる。
ソフトウェアの使えない労働者は、新興国の単純労働者と競争するしかない。
教育も、つまらない教養科目を教えるより、早い時期からプログラミングを教えたほうがいい。

最後に、ソフトウェアの価値を実現する必要がある。
すでにグーグルやフェイスブックは収益を実現したが、他のソフトウェア企業が資本主義の世界で既存の企業をしのぐ存在になるかどうかは今後の問題だ。
そういうビジネスモデルを開発した者が次の時代の勝者になるだろう。
(引用終了)

【参考2】
ソフトウエア、それが問題だ Software Matters - 日本のリーダーはソフトウエアの本質を理解していない:ITpro

ソフトウエア、それが問題だ Software Matters - (2/4)日本のリーダーはソフトウエアの本質を理解していない:ITpro

ソフトウエア、それが問題だ Software Matters - (3/4)日本のリーダーはソフトウエアの本質を理解していない:ITpro

ソフトウエア、それが問題だ Software Matters - (4/4)日本のリーダーはソフトウエアの本質を理解していない:ITpro

(引用開始)
ソフトウエアは物事を変換しうる本質を持つ。
日本のビジネスリーダーはこのことへの理解が遅れていた。
日本の製造業は過去、ソフトウエアの役割を最小化する“ものづくりイデオロギー”によって成功したが、そのことによってソフトウエアをハードウエアのためのものとみなしてしまい、ソフトウエアが新機能、付加価値そして差異化の牽引役であることになかなか気付かない。
(引用終了)

| | コメント (0)

2016/07/17

有効な併買ルールを見つけ出すバスケット分析のアルゴリズムのリンク

有効な併買ルールを見つけ出すバスケット分析についての記事をメモ。
以下、特に主張なし。

【参考】
アップセルとクロスセルで顧客収益性を上げたい!|活用ケース解説|マーケターのためのデータ分析実践入門 Marketing Analyticsゼミナール

バスケット分析とは:何と何が、一緒に買われているのか?を知ろう|データ分析用語を解説 - データビジュアライズで経営を視える化する/graffe グラーフ

リフト値とは:その事象が、どれだけ「持ち上がっているか」を考える指標|データ分析用語を解説 - データビジュアライズで経営を視える化する/graffe グラーフ

Teradata|マーケターのためのデータマイニング・ヒッチハイクガイド:第15回:アソシエーション分析(前編)

第1回 機械学習を実践する前の基礎知識:Mahoutで体感する機械学習の実践|gihyo.jp … 技術評論社

第2回 「ある商品といっしょによく売れる商品は何か?」を見つけるには ~マーケット・バスケット分析の考え方:Mahoutで体感する機械学習の実践|gihyo.jp … 技術評論社

【1】スーパーやコンビニのPOS分析で溜まったデータの分析のうち、バスケット分析が一番有名ではないか。
意外な商品を近くに配置すると、売れ行きが増大する。
有名な例は、アメリカの都市伝説にもなっている、紙おむつとビールの事例だろう。

リテールデータ分析入門」によれば、日本では、ある食品会社が、レトルトカレーと卵がセットで売上が高いので、卵売り場でレトルトカレーを配置してPOP広告で購入を促したら、実際に売れ行きが増大したらしい。
仮説としては、低学年の子供を持つユーザ層が、レトルトカレーと卵を購入しているのではないか、と推測されたらしい。

コンビニを見れば、毎日のように、商品の置き場が変わっているのがよく分かる。
中小企業のスーパーでも、併買分析をすれば、もっと売上が増えるのではないか?
実際、ある診断士の話を聞くと、とある中小企業の小売店では、スパゲッティの麺とパスタソースをセットに配置していなかったので、セットで配置するように指導したら、売上が増えた、という話を聞いたことがある。

プログラムを書くことができるならば、バスケット分析を実際に試してみると、身近の人達にその威力を見せつけられるかもしれない。

【2】バスケット分析のアルゴリズムは、サポート、信頼度、リフトの3つで測定するのが知られている。

支持度(support)=「XかつY」を含むトランザクション数/全トランザクション数

信頼度(confidence)=「XかつY」を含むトランザクション数/Xを含むトランザクション数

リフト=信頼度(X⇒Y)/支持度(Y)

(引用開始)
この式から「リフト値」は、「xが買われたときにyも買われる確率」を「全体でyが買われる確率」で割ったものである、と考えることができます。

つまり、「リフト値が高い」ということは条件Xのときに事象Yが起こりやすいということを示しています。このように一般化すると「リフト値」の考え方は「バスケット分析」以外でも活用できます。
(引用終了)

つまり、リフト値は、ある条件における条件付き確率であることを意味している。

(引用開始)
信頼度は,「条件(パンを買う)が起きた場合に,結論(ミルクを買う)が起きる割合」を表します。これにより,条件(パンを買う)と結論(ミルクを買う)のアソシエーションの強さを表します。

支持度は,条件(パンを買う)と結論(ミルクを買う)が同時に起こる場合が全トランザクションに占める割合を表します。

支持度が低い組み合わせは,あまり買う人がいない組み合わせであることを示します。そのため,たとえ信頼度が高くても,支持度が低い組み合わせは,アソシーエション分析では有用な答えではないと考えます。

次に,結論(ミルクを買う)が条件(パンを買う)と無関係に起こっていないかどうかを計算します。先ほどのコンビニエンスストアにおけるジュースのように,よく売れる商品はどの商品から見てもよくいっしょに売れる商品になってしまう可能性があるためです。

そういった現象が起こる度合いの低さを表すのが「リフト値」です。

有効なアソシエーションルールであるためには,一般的にリフト値が1より大きい必要があります。

このように,アソシエーション分析では,信頼度,支持度,リフト値の3つの値を求めます。そしてこれら3つの値でアソシエーションルールの強さと有効性を判断します。
(引用終了)

【3】実際の計算方法は、いくつかあるらしい。
一つは、「リテールデータ分析入門」に記載されていた、R言語を使う方法。
もう一つは、第2回 「ある商品といっしょによく売れる商品は何か?」を見つけるには ~マーケット・バスケット分析の考え方:Mahoutで体感する機械学習の実践|gihyo.jp … 技術評論社のように、Mahout+Hadoopを使う方法。

この辺りの技術は、今は戦国時代みたいで、色々あって面白い。
他にもまとめてみる。

| | コメント (0)

2016/07/15

ツールの使い方に関するノウハウをデザインパターンにまとめる事例

DataSpiderというパッケージ製品の記事を見ていたら、ツールの使い方に関するノウハウをデザインパターンにまとめる事例があったのでメモ。

【参考】
DataSpiderデザインパターンβ 序章 「DataSpider デザインパターンβとは」コメントを投稿する DataSpiderデザインパターンβ|DataSpider Technical Network

RedmineのチケットをExcel形式でレポートしてみたコメントを投稿する |DataSpider Technical Network

あるソフトウェア製品を使いこなしていくと、それに関するノウハウが色々溜まってくる。
そのノウハウは、ある利用シーンに対する効果的な使い方もあるし、製品の制約によって、こういう使い方しかできない、という場合もある。
そんな時に、製品のノウハウをパターンカタログで表現する、という方法は面白い。

実際、下記のような記事で紹介されている。

(引用開始)
ソフトウェア開発・設計・運用の現場でよく話題となる「デザインパターン」と呼ばれるものがあります。デザインパターンとは、過去に発生してきた多種多様な課題、およびそれに対する解決方法を分類して抽象化し、他の現場でも再利用できる形で一覧化したものです。デザインパターンを知ることにより、システム開発の担当者は、より効率的に課題に対する解決策を発見することができます。

「DataSpiderデザインパターンβ」は、このような「デザインパターン」をDataSpiderにおいても作成し、今後のDataSpiderを使用した開発・システム設計・運用に役立つものを作ろうとする試みです。

これにより、DataSpiderを用いたデータ連携システム開発の効率化に役立てていただくと共に、DataSpider技術者同士のコミュニケーションの円滑化、また既に稼働しているシステムのより良い改善等に役立つものになれば、と考えています。

DataSpiderのベンダーであるアプレッソは、2001年6月にDataSpider 1.0をリリースしてから十数年の間、DataSpider自体の開発はもちろん、多くのDataSpiderの開発・利用シーンを提案・支援してきた実績があります。そこでまずは、これまでの経験を下敷きに、叩き台として「DataSpider デザインパターン β」を提示しようと思います。
(引用終了)

(引用開始)
DataSpiderを使ったデータ連携システムの開発の中でも、さまざまなフェーズで何がベストプラクティスなのか悩むことがあると思います。
例えば、Mapperの効率的な使用方法といったスクリプト開発の時点や、既存システムとDataSpiderをどう連繋させるかといったアーキテクチャのレイヤー、またテスト環境から本番環境への移行をどのように行うかという運用のフェーズなど、さまざまな場面においてデザインパターンを考えることができます。
(引用終了)

(引用開始)
また、1つ1つのパターンの中では、以下の項目でパターンを提示していく予定です。

1 課題
パターンによって解決しようとしている課題を表します。

2 解決方法
解決の方法を示します。

3 説明
具体的な使用方法を説明します。

4 メリット
このパターンを使うことによって享受できるメリットを説明します。

5 注意点
パターンを使用するにあたってデメリットや注意することがある場合、ここに示します。

6 関連事項
他のパターンと密接な関係を持っている場合や、参考ドキュメントがある場合など、関連する事項をここに記述します。
(引用終了)

パターンで表現する最大のメリットは、分かりやすいことだ。

どんなシーンで、パターンが有効なのか?
パターンを使うと、どんな効果が出て、その効果が得られる範囲はどこまでなのか?
そういうことが一目で分かる点は良い。

逆にデメリットは、パターンカタログで全てを網羅できているか不安であること、重複したり粒度にばらつきが出たりする場合があることだろう。
そして、パターンを作っていく時に迷ってしまうのは、パターンを一つのストーリーにまとめることができるかどうか、にかかっている点だろうと思う。

パターン地図、ナビゲーションマップみたいに、パターンの関係を一つのストーリーや地図にまとめて、体系づけて理解したい。
そうすれば、パターンをより一層深く理解できるはず。

たとえば、上記の記事では、製品の使い方や設計のパターンを「スクリプト開発パターン」「連携システム設計パターン」「運用パターン」にまとめている。
おそらく、スクリプトで開発した→システム連携のモデルに当てはめる→実際に運用してみる、みたいな流れになるのかな、と想像する。

そういう事例を見ると、Redmineでも同様のパターンカタログを作ってみたくなってくる。
以前、@akahane92さんが、ITSガイドラインを作ってみたいね、とツイートされていたが、その心は、Redmineの利用に関するパターンカタログを作ってみたいことに行き着くと思う。

この辺りの発想もまとめてみたいと思う。

| | コメント (0)

2016/01/12

Rails製次世代型CRMのFat Free CRM

Rails製次世代型CRMと記載されていた「Fat Free CRM」のリンクをメモ。

【参考】
Rails製、次世代型CRM・Fat Free CRM MOONGIFT

fatfreecrm/fat_free_crm ・ GitHub

Rails Hub情報局: いま読みたいRuby on Rails3アプリ 10選

Fat Free CRM - Ruby On Rails-based open source CRM platform

日本Cloud Foundryグループ ブログ: Fat Free CRM を Cloud Foundry で動かす

どんな中小企業でも、個人事業主でも、営業していたら、見込客や既存顧客の状態を管理したくなってくる。
そこで、CRMに見込み客や既存顧客を登録しておき、営業で見つけた情報や引合の情報を登録して、後で精査したい。

フリーのCRMと言えば、SugarCRMやvTigerCRMが有名だろう。
でも、Railsアプリと言えば、RedmineやGitlabが有名だろうが、Rails製CRMがないか、探していた。
そんな時に見つけたのが、Fat Free CRM。

(引用開始)
今回紹介するオープンソース・ソフトウェアはFat Free CRM、次世代型のCRMを標榜するソフトウェアだ。

Fat Free CRMはRuby on Railsで作られたソフトウェアで、SQLite3やMySQLで利用できる。ごく手軽に導入できるのが利点だ。インタフェースは非常に見やすい。ラベルが色分けされているだけで随分見やすさが変わってくることが実感してもらえるはずだ。

主な機能はタスク、キャンペーン、顧客情報、案件のステータスなどを一元的に管理できる。顧客に対してタスクを紐づけることで、どの顧客が工数が多くなっているのか等も分かる。検索は各アクションに沿ってフィルタリングが可能で、細かく検索できるようになっている。
(中略)
一般的なCRMというと入力項目がとても多く、面倒な感じがしていたがFat Free CRMについてはすっきりとしたインタフェースも手伝ってそんな印象はない。また、スケジュール管理とかぶる機能が多いのも一般的なCRMでは多かったが、Fat Free CRMではタスクくらいだ。次世代型にふさわしい、進化したCRMと言えそうだ。
(引用終了)

パッケージ製品のCRMは、どうしてもUIが使いにくいし、見栄えも良くない。
一方、Rails製のCRMの方がUIも先進的だし、最新の技術も反映しやすいはず。
Fat Free CRMの画面キャプチャや概要を読むと、使いやすそうに見える。

DBに顧客情報や問合せ情報が登録されていれば、そのDBを直接参照することで、他システムとも連携しやすくなるはず。
個人的には、CRMにおけるサポートデスクの問合せ管理はRedmineの方が使いやすいと思うので、Fat Free CRMとRedmineが相互連携できるといいなあと思ったりする。
色々調査してみたい。

| | コメント (0)

2015/12/20

機械学習に関するメモ

機械学習に関するメモ。
特に主張はなし。

機械学習をこれから始める人に押さえておいてほしいこと - Qiita

最近流行の機械学習、高度な統計処理との違いはどこにあるのか - ZDNet Japan

はじめに ? 機械学習の Python との出会い

初心者が効率良く機械学習を勉強する方法 - quantyのブログ

文系でも機械学習がわかるようになる教科書 - EchizenBlog-Zwei

科学計算における均質化、あるいはなぜPythonが着実に他言語のシェアを奪っているか | once upon a time,跡地

(引用開始)
最近、何故科学計算でPythonがほぼ一人勝ちなのか気になっていたのですが、TAL YARKONI氏による、THE HOMOGENIZATION OF SCIENTIFIC COMPUTING, OR WHY PYTHON IS STEADILY EATING OTHER LANGUAGES’ LUNCHという記事が、その答えに近づける鍵なのかもしれないと思い、試訳をしてみました。
彼は心理学とニューロイメージングを専門とする研究者であり、元々Rを中心に様々な言語を利用していたのですが、最近ではPythonばかり使うようになってきたとのことです。
(引用終了)

(引用開始)
ここ2年で、私の科学計算のツールボックスが着実に均質化している。
2010,2011年くらいは、私のツールボックスは以下のものを使っていた。

Ruby: テキスト処理や雑多なscripting
Ruby on Rails/JavaScript: Web開発
Python/Numpy(たまにMATLAB): 数値計算
MATLAB: ニューロイメージング1データの解析
R: 統計的分析
R: プロット、可視化
それ以外のもののために、他の言語/環境の開拓

2013年には、こうなっている

Python: テキスト処理や雑多なscripting
Ruby on Rails/JavaScript: Web開発。DjangoやFlask(Pythonのフレームワーク)もたまに使う
Python (Numpy/SciPy): 数値計算
Python (Neurosynth, NiPyなど): ニューロイメージングデータの解析
Python (Numpy/SciPy/pandas/statsmodels): 統計的分析
Python (MatPlotLib): プロット、可視化(Webベースの可視化にはJavaScriptのd3.jsを使う)
Python (scikit-learn): 機械学習

他言語の開拓は顕著に減った
(引用終了)

RubyKaigi 2015(3日目) - ただのにっき(2015-12-13)

(引用開始)
ところで今回のRubyKaigiで「あ、これはまずいな」と思ったことに「機械学習系の発表がひとつもなかった」点がある。
昨日のパーティでも話題にあげてみたところ、危機感を抱いている人は少なからずいた印象だけど、根っこをたどると数値演算ライブラリの整備をずーっと放置してきたことがあるだろう。
気がつくと数値演算方面ではPythonに大きく水をあけられていて、いまやその応用である機械学習では(LLの中では)Pythonの独壇場だ。
Webアプリケーションの分野で一世を風靡した気になってる間に、いま一番ホットな領域がまったく話題にならない言語になってしまった。
今日は学生無料デーだったのにほとんど来た学生がいなかったらしいし、若い人に見向きもされない言語になってるんじゃあるまいか。
(引用終了)

昨今の技術の流れは、Webやスマフォから、IoTやビッグデータなどの機械学習に流れていると言えるのではないか。
自動運転、ドローン、AIとか、まさに機械学習のスキル、統計のスキルがエンジニアに今後必要になってくる技術ではないか?

その中でも、Pythonが非常に気になる。
Rubyも、BioRubyとか、データ分析に特化したライブラリとかあったのに、今はどうなっているのかな?

| | コメント (0)

2015/05/31

GitBookのメモ

GitBookのリンクをメモ。

GitBook・Markdownで書いて電子書籍/HTMLを生成 MOONGIFT

Gitbookで学生向け講座の資料を作った話 - モノクロタイム

Yukaary Craft: gitbook試してみる

GitHubのMarkdownで文書を書くのが最近は普通になった。
Markdownでテキストを残しておけば、Pandocなどの変換ツールで、epub・HTML・PDF・Docなど多種多様なファイルに出力できるメリットがある。

出力フォーマットが多彩であれば、Webで公開したり、スライド資料で使ったり、Office文書で配布したり、スマフォで見たり、紙に印刷したり、色んな用途に使える。

GitBookはGitHubのMarkdownに特化したepub変換ツールらしい。
今度試してみる。

| | コメント (0)

2015/04/04

教育学は人工知能の研究者によるデータ主導で置き換えられつつある

教育学は人工知能の研究者によるデータ主導で置き換えられつつある記事が面白かったのでメモ。

【参考】
1000年変わらなかった教育業界が、今熱い! | GLOBIS 知見録

MITの苦渋の決断がMOOCへの流れを作った | GLOBIS 知見録

MOOC前夜: カーンアカデミーの衝撃 | GLOBIS 知見録

異才セバスチャン・スランのMoonshots | GLOBIS 知見録

人工知能が支える「10万人教室」 | GLOBIS 知見録

教育の新たな可能性が見えてきた! | GLOBIS 知見録

知的誠実さの大切さ~Moodleが持つ教育のイノベーションの可能性: プログラマの思索

Mooldeの基本的な概念: プログラマの思索

教育学は、人間はどのように成長していくか、という根本問題を抱えている。
今までは、仮説に基いて思索するぐらいしかなかった。

でも、今では、MOOCに集められた大量のデータを元に、人はどのようにして知能を身につけるのか、を研究することができる。
MOOCを編み出した人達が皆、人工知能(AI)の研究者である背景を持つのも面白い。
自動運転、人工知能、機会学習、ビッグデータ、みたいなバズワードを連想させる。

教育学や心理学のような人文科学は、人工知能と統計学による研究結果でどんどん置き換えられていくのではないか。
古くて既に理論が確立されていると思われている学問に対して、新しい技術を用いて、新たな知見を見出して挑戦するのはすごく面白そうに思う。
多分、このような事象を破壊的イノベーションと呼ぶのだろう。

| | コメント (0)

2015/04/03

オープンソースソフトウエアを支えるビジネスモデル

「オープンソースソフトウエアがゾンビ化する事情」の記事が参考になったのでメモ。
以下、主張のないラフなメモ書き。

【元ネタ】
ゾンビOSSが危ない - [2]オープンソースソフトウエアがゾンビ化する事情:ITpro

ゾンビOSSが危ない - [1]オープンソースソフトウエアにも寿命がある:ITpro

ゾンビOSSが危ない - [3]オープンソースソフトウエアの「ゾンビ化」を避ける心得:ITpro

(引用開始)
1)リスク高:新機能追求型

 既存の商用ソフトにはない新機能の実現を目指して開発された「新機能追求型」のOSSは、ゾンビ化するリスクが最も高い。
 ゾンビ化するパターンは大きく三つある。(1)新機能が他のソフトでも実現可能になることで、そのOSSの存在意義が無くなるパターン、(2)新機能を実現するOSSが乱立した結果、競争に敗北するパターン、(3)新機能を追求するあまり旧バージョンのサポートがおろそかになるパターンである。
(引用終了)

(引用開始)
2)リスク並:サポートビジネス型

 サポートビジネス型OSSとは、ディストリビューションや有償サポートを販売するベンダーが開発を支えているOSSのことだ。OSS事情に詳しいNRIの高橋雅人OSS推進グループマネージャーは、このようなOSSを「商用OSS」と表現する。
(引用終了)

(引用開始)
3)リスク並:マーケティング型

 マーケティング型のOSSとは、ベンチャー企業が販売・サポート収入を目的に開発したソフトを、世間にアピールするためにオープンソース化したものである。販売・サポート収入を前提にしているので、ゾンビ化リスクはサポートビジネス型と同程度である。
(引用終了)
(引用開始)
4)リスク低:呉越同舟型

 呉越同舟型OSSとは、ライバル関係にある企業が「呉越同舟」で協調して開発するソフトを指す。SDN(ソフトウエア・デファインド・ネットワーク)ツール「OpenDaylight」やIaaS構築ソフトOpenStack、Dockerコンテナの運用管理ツール「Kubernetes」など、先端的なOSSの開発が大手ベンダーによる呉越同舟で進むケースが増えている(図5)。
(引用終了)

(引用開始)
5)リスク高:特殊事情型

 きわめて特殊な事情でOSSが生まれることもある。その一例は、米InfiniDBが開発したデータウエアハウス(DWH)ソフト「InfiniDB」だ。
(引用終了)

【1】現代のソフトウェア開発では、オープンソースを上手く使ってスクラッチ開発する場合は多い。
特に、フレームワークなどの開発基盤、DBやWebサーバなどのミドルウェア、サーバーやインフラの監視ツールなどが思いつく。

個人的には、オープンソースをベースとした開発は好きだ。
2000年代前半までは、ベンダー主導のフレームワークやパッケージ製品で開発する方法が多かったが、開発者としては苦痛で仕方なかった。
俺様フレームワークに付き合わされるのは嫌だったし、すぐに技術が陳腐化するのに、パッチやバージョンアップの対応が遅かったから。
また、オープンソースに慣れている方が、そのスキルは他の職場でも通用するし、GitHubのように最新の開発プロセスも身につく。

しかし、オープンソースにも落とし穴はある。
コミッタとコミュニティが活発に活動しなければ、環境に応じてバージョンアップして、時代に追随できないリスクがある。
オープンソースのツールのコミッタは、普通は無償で趣味でやっているだろうから、その仕事量が増えてくると、多分持ちこたえられなくなる。

【2】上記の記事で興味深いのは「新機能追求型」と「サポートビジネス型」だ。

【2-1】「新機能追求型」のオープンソースで破綻するケースは確かにある。

一番怖いのは、後方互換性を考慮しないバージョンアップを行うオープンソースだろうと思う。
安易にバージョンアップしてしまうと、OSやブラウザごとに乱立してしまい、逆に保守コストが上がってしまう。
特に、新機能の追加を優先した場合に起きやすいと思う。


【2-2】オープンソースが開発者にとっても経営者にとっても、安定したビジネスモデルになるのは、「サポートビジネス型」だろう。
ソースを公開するのは著作権放棄と思われるかもしれない。
でも、逆に、開発者やユーザからたくさんのフィードバックをもらえることで、機能や品質の改善につながる。
また、ソースの公開によって、知名度が上がる利点もあるだろう。
その方向性を突き進めると「マーケティング型」になるだろう。

「サポートビジネス型」で重要な点は、オープンソースのツールを中心としたエコシステムを作り出すことだろう。

開発チーム、熱心な利用ユーザ、バグ修正のパッチを送ってくれる熱心な開発者の三者が一つのコミュニティを形成できれば、製品の方向性を事前に示すこともでき、それによってユーザも安心感を持てる。
定期的なバージョンアップをロードマップとして事前に告知できれば、セキュリティパッチやメジャーバージョンアップを区別してリリースすることもできる。

オープンソースを長続きさせるには、開発よりも保守が重要。
保守し続けたい、と思わせるパワーが必要。
そのためには、開発チーム・利用ユーザと開発者のコミュニティとエコシステムが必要だろうと思う。

この辺りのオープンソースのビジネスモデルも整理して、その特徴や方向性、焦点を明確にしてみたい。

| | コメント (0)

より以前の記事一覧