開発者としてステージが上がると、技術選定をする機会が増えます。
- Markdown形式のドキュメントを使うことになったので、ライブラリを選ぶか自作するか考える
- チャートを描画しないといけないので、ライブラリを選ぶか自作するか考える
- 新しいシステム開発を行うことになったので、アーキテクチャを選ぶ
- 新しいシステム開発を行うことになってので、プログラミング言語を選ぶ
- 新しい（省略）、フレームワークを選ぶ、ライブラリを選ぶ
技術選定をするときに考えるべき基準をこの章では書き記します。
開発を行うときに、技術というのはあくまで手段です。何かしらの問題を解決するための開発にせよ、何かしらの研究を行うにせよ、なぜ「それ」を選ぶのか？というのには根拠を持って選ばなければなりません。
新しいシステムを開発するときに、アーキテクチャの選択をミスすれば、工数にも大きく影響することでしょう。同様に開発手法、言語、フレームワーク、ライブラリなどは、大なり小なり、大きくその後に響くものです。
普通は思いつく限りの選択肢に対して、いわゆる pros/cons （良し悪し）を列挙し、どれを選んだときにはどういう利点と欠点があるかを比較します。技術には大体において一長一短あり、どれが最善手であるか？はなかなか分からないものです1。
また、技術を選んだ理由、つまり先ほど述べたような pros/cons などをドキュメントに残すことも重要です。個人でアプリを開発する場合は最悪残さなくても大丈夫でしょう。しかしその場合でもなるべくならドキュメントに残した方がいいでしょう2。
これには明確な理由があります。何かしら開発をしていると、ソースコードは git なりのバージョン管理システムで管理されることで、最低限 How は記録されます。ちゃんとした開発をしている場合 What もです。しかし、Why は意識的に残さない限り、記録されず、忘却の彼方に消えていくでしょう。
あなたがもし保守運用など、誰かのソースコードを引き継いだとき、それなりの確率で「どういう理由でこれをしたのか」が分からないケースがあります。そしてそれはまたも、かなりの確率で「別のやり方の方がいいんだけどな」と思うことでしょう。当時の技術的・組織的な制約などにより、その当時としては最善を尽くしたが、その後の技術革新や人の変化によって、よりよい手段が生まれていることも少なくありません。こういったものは大体オーパーツになって、誰も正しくメンテナンスできずアンタッチャブルにあり、その組織に対するダメージを継続的に生み出すことになりかねません。
これがもし選択基準など、Why を大切に記録する文化があれば、ここまでひどいことにはなっていない可能性が高いでしょう。Why が記録・管理されているのであれば、その組織に残っている技術的なものは、作り直す・取り替える・捨てる、と言った新たな意思決定を行いやすいためです。
TBD: 書く
技術には、いくつかの指標があります。
- その技術についての情報が豊富
- その技術の使いやすさ
- その技術の中身
- その技術を扱える人材はどれくらいいるか？
- その技術の、今の人気、将来の人気
- その技術はn年後進化しているか？メンテナンスされているか？
- その技術の独自性はどれくらいある？代替案はある？
こういった指標がありますが、これらは対立することもあり、どの項目を優先するか悩むことも多いでしょう。
おそらくこの項目を検討する人は多いでしょう。
情報が豊富であれば、よくハマりがちな問題は大体誰かが解決していることを期待できますし、自分が遭遇するいろいろな事例に対して、すでに答えがあることを期待できるでしょう。
ただし、それらが本当に正しいとは限らず見せかけだけの場合もあります。情報がいっぱい出てきても大半は「やってみた」程度のもので、深く踏み込んだ詳細な情報が無いというケースもあり得ます。とはいえ、情報が多ければ、その分有用なものに出会える可能性は高いかもしれません。
情報が豊富なときの利点は、その情報に到達する人が多いということでもあります。つまり、その技術を使える人材が豊富かもしれません。
使いやすさの基準は、その技術の使い方が分かりやすいこと、その技術がシンプルだったりイージーだったりすること、検索すれば情報が出てくること、ドキュメントや事例が豊富なことなどが挙げられるでしょう。情報が豊富という項目は前述の通りなので置いておきますが、大体連動することが多いでしょう。
使い方が分かりやすいかどうかは、作り手のセンスが表れます。例えばライブラリであれば、その言語のセオリーやエコシステム、あるいはプログラミング全般におけるセオリーと矛盾が少ないか？扱う上で面倒が少ないか？などです。矛盾が少ないということは直感的に扱いやすいはずです。
また、シンプルな技術や、イージーな技術も好まれがちです。あるライブラリを使うときに、やたらと手順が必要なものが好まれないことは自明です。
インストールのしやすさ、設定項目の少なさなんかも影響するでしょう。最近はゼロコンフィグと呼ばれるような設定しなくても大体いい感じにしてくれる技術が人気です。
プログラミングの原則に開放/閉鎖原則というものがあります。簡単にいうと拡張しやすく、修正をしなくていいようにするという原則です。ライブラリでいえばプラグインの仕組みやコールバック関数など拡張するための方法が用意されているなど、ライブラリの中に踏み込まなくても自由度が高いというのが理想的です。
使いやすくても、その後メンテナンスしづらくなることもあります。たとえば、拡張性が低い場合、拡張するために無理矢理いろいろなものをねじ曲げる事例もあります。そういったコードは、最初は良かったのに後で苦労するという典型例です。
シンプルとは、複雑ではなく、筋の通った分かりやすいロジックで成り立っているもののことです。
イージーとは、複雑かもしれないが、使い手にとって、簡単なことです。
もちろん、シンプルなコア技術の上にイージーを構築することはできます。それがおそらく理想型です。
一概にいえるわけではありませがん、イージーな技術は「最初は良かったのに後で苦労する」ケースがあるかもしれません。
このシンプル vs イージー問題は割と根深く、プログラミングの歴史においては何度も繰り返し登場している問題です。
技術選定をするときには少しだけ、この観点について敏感になった方が良いでしょう。
使いやすさは、技術を利用する側の視点ですが、技術の中身が重要なこともあります。
あるいは、もしあなたがその技術のバグを見つけても、対処ができないかもしれません。理想型は、あなたが利用する技術は、あなた自身がパッチを当てられることです。あるいは、あなたが使っている技術のソースコードを追いかけられることです。
あなたが中身についてソースコードを追いかけたら実は思っていたことと違うこともあります。ドキュメントが間違っていた、読み間違えていた、バグがあったなどです。
ではあなた自身の力が及ばず、中身なんてさっぱりだわという場合、この観点は無視してもいいのでしょうか？そうではありません。たとえば中身があまりにも複雑怪奇な職人芸の場合、拡張性や将来のメンテナンスを期待できないかもしれません。つまり、その技術に未来が無いかもしれないのです。
場合によっては、あなたが理解できたとして貢献を絶対に受け付けないような偏屈な人・集団で開発されていません。どういった性質のコミュニティなのか？も見極めるべきポイントです。
最低限、その技術にどれくらい未来があるか？位は判定できるだけの力は身につけておくべきでしょう。
いま、現在その技術を扱える人はどれくらいいるでしょうか？そしてその扱える人たちの技術力の分布はどのようなものでしょうか？素人に毛が生えたような人ばかりいても戦力になるとは限りません。職人芸を持った人たちばかりだと雇うのにも苦労するかもしれません。
あなたの組織、お金、文化、そういったものと適合しているか？はとても重要です。
たとえばあなた自身が使い慣れていて、生産性が高い技術があったとします。それ自体はとても素晴らしいことですが、他の人にとって扱いづらい・知らない・習得しづらい・将来性が無いものであれば、あなたしかメンテナンスできる人がいないということもあり得ます。あなたが責任を持ってそれをメンテナンスするのであれば問題はありませんが、突然の家庭の事情で組織を去ることだって絶対無いとは言えません。また、あなた自身が責任のある立場になり、そういった細々した作業をしていられないということも往々にしてあり得ます。
また、いま現在、その技術を使える人が多くても、5年後、あるいは10年後はどうでしょうか？
あなたはどれくらいはやり廃りを予測できますか？
スマートフォンが世界を席巻したのは2010年代です。たとえばiPhoneが日本に上陸した2008年、あなたはそれを予見できましたか？
クラウドが当たり前の現代です。2006年にAWSが登場しました。2000年代にクラウド全盛になることを予見できましたか？
JavaScriptが当たり前の時代です。JS/TSは人気もシェアもとても高い言語です。ウェブ開発において無視できない存在です。たとえば2010年代前半までにそれを予見できましたか？
Dockerなどコンテナ技術が当たり前の時代です。Dockerが登場したのは2014年です。それから数年でコンテナが当たり前になることをあなたは予見できましたか？
こうやって見ると、今当たり前とされている技術が登場してから、ある分野を完全に制覇するまでにかかる時間は、思ったよりもとても短いと感じませんか？10年スパンでの技術の隆盛を予測するのはなかなか難しいということが実感できたのではないでしょうか。
これはさきほどの
また、いま現在、人が多くても、5年後、あるいは10年後はどうでしょうか？
あなたはどれくらいはやり廃りを予測できますか？
ということと完全につながっている話です。
はやり廃りが激しいため、あなたが触っている技術が5年後、10年後にちゃんとメンテナンスされているか？というのはそれなりに難しく、それでいて簡単に致命傷になりうる問題です。
メンテナが飽きて放置されているかもしれません。どこかの企業が作ったものだけど中の人がメンテナンスを諦めて負債になっているケースも珍しくはありません。
2021年 Apache Log4j2 という、Java 向けで世界中で多いなシェアを占めるロガーライブラリに致命的な脆弱性が発見されました。その脆弱性は事実上なんでも実行できてしまうという最もクリティカルなものです。この脆弱性はじつに数年もの間、ずっと誰にも発見されずにいたのです。この脆弱性はあまりにも影響が大きかったため、NHKでも報道され、またアメリカ政府が民間企業に対しアップデートしろという命令を出すほどのものでした。
とても有名な OSS ですらメンテナンスが適切かどうかはわかりません。Log4j をメンテナンスしている人たちは、Log4j をメンテナンスすることで富を生み出しているわけではありません。彼らを責めることはできません。
別の事例を挙げましょう。faker.js という、住所・氏名・電話番号など個人情報のダミーを生成するライブラリがあります。大規模なシステム運用をしていればDBにダミーデータを入れて、大規模レコードの試験を行うこともあるでしょう。ユニットテスト・結合テスト様々なレイヤーで、このダミーデータを生成するライブラリがとても有益であることは誰も疑いない事実です。ところがある日 faker.js のバージョン6.6.6が公開されたのですが、これが完全に壊れたバージョンで、faker.js を使うあらゆるシステムがバージョンアップによって動作が壊れるという自体が生じました。このタイミングで faker.js の作者の人は GitHubリポジトリその他すべてを初期化し、全世界で大量に使われている faker.js は作者の手によって破壊されたのです。
作者は、2020年に住んでいる住居が火事で全財産を失ったのだそうです。
Respectfully, I am no longer going to support Fortune 500s (and other smaller sized companies) with my free work.
Ther is'nt much else to say.
Take this as an oppotunity to send me a six figure yearly contract or fork the project and have someone else work on it.
筆者は彼の悲痛な叫びに凄く心が締め付けられる思いです。
彼は他にも color.js というこれまた色々なところで当たり前のように使われている OSS も破壊しました。
彼の行いをテロ行為だ考える人もいます。確かに彼の行為は決して認められるべきものではありません。しかし、当たり前のようにただ乗り（フリーライド）するという今の OSS 文化も見直すべき時が来たと考えています。
2022年1月時点では、この問題に対して明確な解決はされていません。
いくつか私的サービスとして作者に寄付をする仕組みはありますし、アメリカではOSSのメンテナンスに関して官民が協力して強く支援していくべきだという動きになっているようです。日本はどうするのでしょうか？この本を皆様の手にとどくとき、この問題が解決されていることを筆者は願います。
なお、faker.jsもcolor.jsも今は復旧されています。
技術に対するセンサーを磨けば5年程度の予測は十分可能です。10年後の未来は諦めて5年後リプレイスできるような仕掛けを施しておくという選択肢もあるでしょう。
技術の基礎というのは陳腐化しづらいものです。とにかく陳腐化しづらい技術だけ先に決めておいて、フレームワーク選定などはなるべく先延ばしにしつつ、なるべく依存しないという考え方があります。
TBD: クリーンアーキテクチャ本を引用する