技術選定を行う前にまず、どのような開発組織にしたいのか、どのように事業を進めていきたいのか、そこを整理しないと上手くいかない。
そんなことを最近考えていたので、ブログに書いておく。自分は書くことで思考を整理していくので。
この記事では、「技術選定」そのものについて書いていく。
そのため、個別のライブラリの良し悪しを判断する手法などについては扱わない。もっと抽象度の高い、どのような考え方や態度で技術選定に臨むべきか、というようなことを書いていく。
また、作りたいものを作れるか、仕様を満たせるか、セキュリティ上の問題はないか、などの当然の前提は省く。
そういった「最低条件」を満たした技術が複数あったときにどうやって選ぶのか、という意味での「技術選定」を扱う。
お互いの「納得感」のためにもまずは軸を明確にする
技術選定について考えたり誰かと議論したりする際には、「自分たちは今、どういう観点を基準にして技術を選ぼうとしているのか」を明確にすることが大事だと思う。
そうしないと、思考が迷走したり、議論が噛み合わなかったりする。
社内にノウハウが蓄積されていることを理由に技術Aを推している開発者がいる一方で、今後の人員の増加のためにBを推している別の開発者がいるとする。
このときに議論すべきなのは、「AとBのどちらが適切か」ということではなく、「自分たちはどういう観点で技術を選ぶのか」ということだと思う。そこの認識を合わせる前に具体的な技術の話をしても、上手くいかない。
既存の開発者と相性のよい技術を選ぶのか、それとも、人員を増やすために採用活動に有利な技術を選ぶのか。どちらの観点をどの程度優先するのか。ここの擦り合わせを行っておかないと、議論は平行線を辿る。一人で技術選定を行う場合も、どういう観点で判断すべきなのか自覚的であったほうがいい。
転職活動においてまずは「企業選びの軸」を決めるように、技術選定においてもまずは軸を明確にしないといけない。
特に複数人で技術選定を行う場合は、納得感を醸成するためにもしっかりと考え方について合意を取っておいたほうがいい。絶対的な答えが存在しない中で、自分たちは相対的に何を重視して何を妥協するのか。また、妥協するにしても、譲れない最低ラインをどこに引くのか。こういったことを明確にしないまま技術選定を行ってしまうと、納得感は生まれにくく、不満が残りかねない。
最終的には事業戦略や組織戦略の話になる
技術選定の観点は、先程の例の他にも様々なものが存在する。
短期的な生産性を重視したいのか、時間を掛けてでも堅牢なシステムを作りたいのか。安定性のために十分に枯れている技術を使いたいのか、開発者のモチベーションや技術的な優位性のために最先端の技術を積極的に取り入れていきたいのか。
様々な観点があり得るし、どの観点を重視すべきなのかは、状況によって変わる。つまり、「どのような観点で技術を選ぶのか」についても、前段の議論に依存する。ここでいう「前段の議論」とは、事業や組織に対する基本的な考え方や戦略のことである。
とにかくスケールさせて時価総額を高めることや上場することを目指している組織と、人を増やすことに慎重で少数精鋭のまま経営していくことを意図している組織とでは、当然、技術の選び方にも違いが出てくる。
事業内容によっても違う。可能な限り長く運営していくことを意図しているウェブサービスの開発と、納品や出荷をすれば終わりというプロダクトの開発とでは、技術の選び方はかなり変わってくるだろう。前者では常にメンテナンス性を意識することになるが、後者は必ずしもそうではない。少なくとも優先度は変わってくる。
また、既に売上を稼いでいる主力サービスなのか、それとも実験的なプロダクトなのか、といったように、プロジェクトの立ち位置によっても変わってくる。
まとめると、まず事業や組織の戦略について整理する。そして、その戦略を実現するためにはどのような観点で技術を選ぶべきなのか、考える。そしてその観点に従って、具体的な技術選定を適宜行っていくことになる。
現場のニーズに応えられる技術か
このように、「現場のニーズ」から、どの技術を選ぶべきなのかが決まってくる。具体的な状況を想定しない「技術選定」は存在し得ないと思う。この記事では事業における技術選定を扱っているが、個人開発や OSS の現場でも、やはり何からのニーズがある。「仕事で使っていない技術に触りたい」というのも、立派なニーズだ。そこから、「仕事ではいつも React を触っているから Elm をやってみるか」などの技術選定が行われる。
まずはニーズがあって、じゃあそれに最もよく応えてくれる技術はどれか、という論の運び方になる。
そこから分かるのは「最強の技術」などはないということだ。
いついかなる時も選ぶべき「決定版」のような技術など存在しない。
守備範囲が広くて多くのケースに応えられるから採用されやすい技術、というものはあるかもしれないが、それでも、常にその技術が正しいというわけではない。
そしてこのことは、技術に対して単純に優劣をつけることは難しい、ということも意味する。ある特定の観点や尺度において優劣をつけることは出来るかもしれないが、別の観点を持ち込めば結果はまた変わってくる。
長期にわたって広い人気を獲得している技術は、他の技術よりも優れているから人気を獲得したわけではなく、多くの現場のニーズに上手く応えられたから人気を得たのではないだろうか。
もちろん、人気というのは色んな要因で決まるから、そう単純な話ではないが。
それでもやはり、一時的なブームではなく安定的な人気を得るためには、多くの現場のニーズに応えていることが必要条件になると思う。逆に言えば、技術的に高度であったり、先進的なことをしていたりすることは、人気を得る上ではあまり関係ない。
そう考えると、ある技術が人気なのは、それが「優れているから」ではなく、多くの現場のニーズに応えているからに過ぎない。そのため、人気のある技術だからといって、自分たちの現場のニーズに上手く応えてくれるとは限らない。人気という意味では後塵を拝しているような技術のほうが、自分たちの状況に上手くハマる可能性は十分にある。
ライブラリの盛衰
そして、「最適な技術」は時間の経過によって変化していく。
なぜなら、現場のニーズは変化していくから。創業期と拡大期では、事業の戦略や進め方は変わってくる。市場の変化によってビジネスモデルそのものが変わることもあるかもしれない。
同様に、技術の立ち位置も変化していく。より便利な後発の技術が出てくるかもしれないし、利用事例が増えることで「実務に耐えられる」と見做されて採用されやすくなることもあるだろう。
定期的に「XXX（任意のライブラリやフレームワークなど）はオワコン」のような言説が出回る。大半は読む価値のないものだが、中には（表現はともかく）鋭い指摘をしているものもある。
それまでは「多数派のニーズ」に上手く応えておりそれゆえに人気のあった技術が、変化した「多数派のニーズ」に上手く応えられなかったとき、あるいはもっと上手く応える別の技術が出てきたときに、「衰退」が始まるのかもしれない。個人的にはそんな風に思う。
とはいえ、それはあくまでも「人気」の話であり、「優劣」ではない。
もちろん「人気」も重要な尺度ではある。「開発者のモチベーション」「開発者の集めやすさ」「エコシステムの充実性」などの理由で「人気」の技術を選ぶことは十分にあり得る。だがそれは、尺度のひとつに過ぎない。
それ以外の尺度を重視している組織にとっては、「衰退」した技術が上手くマッチすることもあり得る。
