じゃあ「技術選定よろしく！」 ってなったそんなあなたに送る簡易的なメモ。
事業フェーズやドメインによって選定方法も変わるのでよく考える必要がある。
１、ざっくり評価軸
・UX向上
・売り上げ貢献
・開発生産性向上
２、細分化された技術選定の評価軸
サービス要件の担保
経済性
開発生産性
技術信頼性
サービス要件の担保
決済系サービスなど重要。
・セキュリティ要件
・結果整合性（特にストレージ）
・サービスの実現可能性（そもそもこれがないと実現できない的な）
経済性
・サーバー代節約
・人件費節約
・速度改善性
・バグへの遭遇率の抑制
開発生産性
・学習コスト（= 概念のシンプルさ、既存ノウハウとの親和性）
・学習モチベーション
・人数規模への適合性
・メンテナンス性
・人的資源の可用性
技術信頼性
・本番採用数
・開発母体の安定性
・獲得しているスター数
・誕生からの年数
３、ざっくり評価軸２
・要件との合致
・情報
・将来性
・開発効率
・費用対効果
要件を達成できるのか。技術が流行ってるからと言って要件達成できないでは意味がない。
最新すぎて機能が足りない、セキュリティ的にメンテができてない。
情報発信している人の信頼性。
将来標準になるのか、ならないのか。
学習に時間がかかるのか、かからないのか。
チェックリスト
現場に残る人たちが使いこなせるのか？（選定した人が抜けても機能するか？）
ブラックボックス的に使うなら、十分に枯れているか？（10年以上が節目？）
シンプルさや、使用感の統一性、既存技術との乖離性（手続き型と関数型など）などを考慮
高負荷時の動作など大丈夫なものか？（高負荷になるとバグが出たりします。。。）
既存技術と比べて大きな優位性があるのか？
頑張って選んでも、数年後には古いと言われます。。。
影響範囲が狭くて、修正頻度が極端に低いのであれば、とりあえずGoでもおｋかと。
スケールアウト出来るとはいえ、実行速度が速い言語のほうが良いと思います。（プロトタイプ制作なら作りやすいものが良いかもですが。。。）
https://qiita.com/daijinload/items/cab3ed862c08da4c06e8
失敗例
新言語を採用して担当がいなくなった
担当者が新言語を導入したいと願って、導入したは良いが、その担当者が会社辞めてしまって、残ったエンジニアが、メンテ出来ないorしたくなくて、結局別言語でリプレイスされたというのはありました。（残された人たちの恨みが大きかったです。）
https://qiita.com/daijinload/items/cab3ed862c08da4c06e8
ElasticSearchとCloudSearch
初め採用したインフラが本番と違うってことや、要件通りのことができないなどでインフラ切り替え。
本番動いてから切り替えるのは大変ってこともあると思う。
https://qiita.com/yamotuki/items/e3d9e1cec0d3a5a84dfd
選定した技術が1年で死んだ話
Silexってマイクロフレームワークを選定して、ある日サポートが終わった。
スター数だけでなく、フォーク数とコントリビュータ数も非常に大事と感じる。
https://www.sodo-shed.com/archives/12182
https://github.com/silexphp/Silex
言語選定
型があるか、コンパイル型か。
Windowsか。
.Net
モバイルもあるマルチプラットフォームか。
Xamarin, ReactNaitiveとか。
類似プロジェクトでの採用事例
・言語のユーザー数
・Webサービス数
- Java側の主張
構造化言語、オブジェクト指向、手続き型
静的型付け
コンパイラ言語
================
ユーザー数：多い
採用企業数：多い
ライブラリ：多い
日本語資料：多い
プラットフォーム：WEB、モバイル
OS：Windows、Linux、Android
フレームワーク：Struts、JSF、Play、Spring
ScalaやKotlinへパワーアップしたい気持ちも出てくるはず。ライブラリ、フレームワーク側コミットできないなら、危ない橋は渡らない。
Springが柔軟なフレームワーク。ScalaやるならPlay一択。
- PHP側の主張
構造化言語、オブジェクト指向、手続き型
動的型付け
================
ユーザー数：多い
採用企業数：多い
ライブラリ：多い
日本語資料：多い
プラットフォーム：WEB
OS：Windows、Linux
フレームワーク：Laravel、CakePHP
PHPは普通の枯れた言語だが、Laravelが柔軟に対応できるフレームワーク。
- Ruby側の主張
構造化言語、オブジェクト指向、手続き型
動的型付け
================
ユーザー数：日本では多い
採用企業数：日本では多い
ライブラリ：日本では多い
日本語資料：本では多い
プラットフォーム：WEB
OS：Windows、Linux
フレームワーク：Rails、sinatra
ベンチャーに多い。ほぼRails１択。その場合のDDDへの移行が困難という問題がある。
ドメイン駆動設計の比類なきパワーでRailsレガシーコードなど大爆殺したるわあああ！！！
https://qiita.com/MinoDriven/items/3c7db287e2c66f36589a
- GO側の主張
オブジェクト指向、手続き型
コンパイラ言語
静的型付け
================
ユーザー数：増えてる
採用企業数：増えてる
ライブラリ：増えてる
日本語資料：増えてる
プラットフォーム：WEB
OS：Windows、Linux
フレームワーク：
ベンチャー採用が増えてる。k8sなど重要な技術に採用されている言語なので、当分は需要がありそう。
言語選定とかしてみる
https://qiita.com/ugdark/items/de6098c8fee6c4ad8ec8#javakotlin
WEBサービス事例
選択は非常に大事なので、他のサービスの規模や費用対効果やUXなどよく見極めることが大きな影響をもたらす。
《コラム》プロダクトの開発言語ってどうやって選ぶの？
注目スタートアップのCTO 4人に聞きました！
https://gsacademy.tokyo/news/2015/07/000047.html
【46選】あのサービス・アプリのアーキテクチャ・プログラミング言語・フレームワークを大調査！〔2019年始版〕
https://employment.en-japan.com/engineerhub/entry/2019/01/08/103000
2020-03-09 業界を変えた大規模サービスの技術選定 ＃techplay0309
https://note.com/suwash/n/n2e2216db211a
国内のサーバーサイド Kotlin 公開採用事例まとめ
https://qiita.com/ptiringo/items/dd734ab8064f94139294