チームで何かアプリケーションを作る時にどんなプログラミング言語を使ってどのフレームワークでどういう技術を使って作ろうか？ と話し合いが行われることがある。この意思決定プロセスは技術選定とか呼ばれている。
そこに出てくるフレームワーク、に限らずソフトウェア技術・ツールの選択基準に大きく関わる「どのぐらいこの技術は使われているのか、主流なのか、シェアがあるのか・今後増えていくのか」という要素がある。
そこでは「たくさん使われている・寡占的な技術ほど良い」という価値観が広く共有されている(業界によって枯れた技術にフォーカスしたり、投資対象としての新技術の範囲を限定したりするから単純にユーザー数というわけでもない)。
その背景には
- 開発者の数を増やして規模を拡大する
- 開発者人材の流動性が高い
- 変化を予測しづらいエコシステムの性質
というものがあると思う。
たくさん採用してすぐやめちゃうのでみんなが使える技術が都合がよく、マイナーな技術を選んでしまうと市場にいる候補者が目減りしたくさん採用できないし、習熟していない人がそれを覚えるまで時間がかかるし(学習コストと呼ばれる)、やってみたブログもGoogle検索でヒットしないし、バグを踏んでも直す人がいなくSaaSのSDKも野良ライブラリしかないので対応する時間がかかる(メンテナンスコストと呼ばれる)。こんな風に理解されている。
「弊社では開発開始時にフレームワーク・アレを選んで元気に開発していましたが、数年経ったら後発のフレームワーク・ソレクトとシェアが逆転したので"採用を考えて"アレグラーからは乗り換えます」的な光景はよく見ると思う。
(ただ、少数派ではあるけど非主流の特定の技術を選択してそれを好む開発者を集めるという戦略も、需要と供給次第なので当然あると思う)
これについてはシェアの高さ意外に直接的・間接的に選ぶ理由もあると思うので一概に「シェア高いかどうかで選ぶのはけしからん」とは僕は思っていなくて、みんなどう思っているんですかね？ というのが率直に聞いてみたいところなのです。
ロードマップ思考とエコシステム その後
「3. 変化を予測しづらいエコシステムの性質」というものについて全く説明していなかったので補足すると「ロードマップ指向とエコシステム指向」という界隈でよく引用されがちなポストがあるので一度読んでみて欲しい。
これが書かれたのはNOSQLの期待が高まっていた2014年の話で、そう考えると当ブログの最近の記事で今だにSQLがわからんとかどうだか言って10年近くやってたのかと関心したのだけど、ここに出てくるエコシステム指向のトピックは結構時代の変化があったなと思う。
本記事のスコープであるアプリケーションを作るためのフレームワークやライブラリのエコシステムで見ると、巨大企業が後ろ盾するOSSプロジェクトがエコシステムの中心にいるというのが特徴的だと思う。
自分の中ではアプリケーション開発に使う道具というものは、ライブラリ100個作って公開するロックスターと100人の仲間がいて、パッチを送り合ってカスタマイズして必要なパーツを組み立てていくような世界観から、細分化された1つの目的を達成するためのライブラリをインストールしたら下位の依存関係から無数のパッケージがついてきてそれらを個別にコントロールできる気はもうしない…… という世界に変わってしまった。
学習としては中心を避けツールが持つ課題や哲学に注目し、それらを実践する道具としては予測できないから多数派を進むのが安全。という見方になる。
これを指して、技術選定の時も「巨大企業が後ろ盾して、多数のユーザーがいて、今後の発展する方向が明確なもの」を好むようになっていって、これはなんか見覚えがあるなと思ったら、ロードマップに従って学習する時の傾向そのものだった。
かくして技術の螺旋に戻ってきた俺たちは・・
