製品採用の時期を見計らう
主に、ライブラリ、フレームワーク、ミドルウェア等の製品を採用する時期についての、おいらの場合についてのメモです。
勃興期と淘汰期
おいら的には、あるカテゴリのプロダクトを選択するにあたって、勃興の時期と淘汰の時期を見計らうようにしています。あるカテゴリのプロダクト群の勃興から淘汰には、以下のようなフェーズがあると考えています。
勃興前
各個人や組織が、いろいろなアイデアや製品を、それぞれ関連のない（もしくは薄い）ものとして発表している状態。
勃興期
勃興期は、業界内の各個人の暗黙知*1が表出化*2により業界内の形式知*3となり、業界内の形式知同士の連結化*4の連鎖が発散と収束を繰り返し、ある特定の形式知が業界内で広く認知されることにより始まります。この段階では、新たにカテゴライズされた技術体系が生まれ、ある製品がその技術カテゴリに属している（もしくは近い）と判断することが可能です。この段階では、共通の用語や、共通の仕様が生まれたりします。
淘汰期
業界内で共通の用語が定着し、代表的な製品が数種類に絞り込まれ、それらすべてが実用に足る段階です。
しかし、これらのフェーズは、過去を振り返って初めて認識できるものなので、今がどのフェーズなのかはわかりません。おいらはどうしているかというと、下記のように対応しています。
おいら的対応
勃興前
勃興前であればカテゴリを認識できるはずもなく、しかしカテゴリを認識できないからといって勃興前とは限らない。ということで、対応しません。（っていうかできません）
勃興期
業界が一番にぎやかな時期です。さまざまな製品が現れては消え、ブログエントリや情報サイトの解説記事が賑わい、集団浅慮を患った技術者集団が他の技術集団に対して非建設的な中傷*5を行いますｗ。祭りです。お祭り好きの人は Now's the Time です。でも、おいらはハウスな人なのでスルーします。おいらは、利害関係者全員に利益を与えるソフトウェア開発という地味な理想を基本的な軸にしているので、多くの場合この段階の製品採用や製品評価*6はおいらにとってメリットよりもデメリットのほうが大きい*7のです。しかし、ユーザーとしての技術者という視点では意識的にウォッチしています。つまり、内部実装はあまり気にしないけど、コンセプトや外部仕様は気にしてます。
淘汰期
この段階の入り口を見極め*8、そのタイミングで製品評価をはじめるのが理想です。主な理由は以下のようなものです。
-
- ある程度有力製品が絞られているので評価対象が少なくてすむ。
- 多くの情報が流通しているので評価対象を絞るのが楽。
- どの製品をメインターゲットとして選択しても致命的な問題を引き起こす可能性が勃興期よりは小さい。
- 勃興期よりもソースが読みやすくなっていることが多い。
- リリースの頻度（特に機能変更）が小さくなっている。
- メインのターゲットを変更しても、基本的な機能が重複しているため、影響が小さい。（たとえば、Hibernate から EclipseLink に乗り換えるとか）
もちろん、すべての製品が大なり小なりの問題を抱えていて、通常はワークアラウンドが必要になります。そのために、この淘汰期のなるべく早い段階*9でユーザーとして参入しようとしているわけです。
おしえて、偉い人。（こんな名前のコーナーがウゴウゴルーガにあったなぁ）
特定技術および製品のライフサイクルについては、おいらが考えるまでもなく学問的に論じられていると思いますが（たとえば、Disruptive technologyとかは、勃興期の開始の１つのきっかけになりうるとか、もっと大きな枠組みの話とか）、論文とか書籍とか知っている人がいたら、ぜひコメントお願いします。
m(_ _)m
*5:当然、本人たちは建設的だと思っている。おいら的には、議論の参加者全員からコンテキストのコンセンサスが得られない限りは、論理的に正しいかどうかにかかわらず、劣っているという指摘は単なる中傷だと思いますし、建設的ではないと思っています（たとえば、一方的に価格の安さというコンテキストを設定して、「トヨタさん、お宅のレ●サスは、弊社のチロ●チョコには製品単価では太刀打ちできません。つまり、チロ●チョコのほうがレ●サスより優れているのです」という理論を構築し、それが集団浅慮にかかるとその理論が一般的なコンテキストでも成り立つことになってしまう。おいら的には、正しいかどうかや優劣を語るよりも、具体的に誰（具体的な人名。自分でもよい。）にとってメリットがあるかを論じたほうが (゜Д゜)ウマー なことが多いと思っています。もしその具体的な誰かがみつからない場合、議論に決着がついても、その結果をどう活かしていいのかわかりません（少なくともおいらには）。
*6:単純に使ってみるとかマニュアルを一通り読むというレベルではなく、プロダクションに適応できるかどうかのフィージビリティーテストです。計画にも実行にもスゲー時間と工数がかかり、責任も重大です。
*7:利害関係者全員に利益を与えるソフトウェア開発という視点では、多くの利害関係者にとって言語やライブラリなどどうでもいい問題なのです。もちろん利害関係者の中に開発者も含まれますが、開発者にとっても、ライブラリの選択時期を遅らせたために具体的な不利益がでるケースは少ないのです（新しい物好きの開発者のメンタルケアの問題くらいですかね）。だって、多少コード量が増えたりめんどくさくなったとしても、通常は他の枯れたものを使用するという選択肢があるのですから。逆に、評価時期が早すぎるのは問題です。コストや品質や納期その他甚大な被害を与えます。
*8:以下が当てはまるのであれば淘汰期と認識するようにしています。
*9:早いのはいいことなのですが、早過ぎるデメリットによる被害は甚大なので、時期が遅くなっても確実に淘汰期のメリットを見極ように注意しています。
