要素技術を決定する際の意思決定パターン

要素技術を決定する際のチャート

  • やりたいことを実現するためのキーワードで Google
  • 既存の技術らしい
    • 既存のライブラリ・フレームワークがある
    • 通常は複数の候補が出てくるのでリストを作る
    • Google Trends でリストをグラフにする
      • => それが現在1位かつ右肩上がりであればそれを選択する
    • 現在1位が踊り場 or/and 右肩下がりである
      • => 二番手以降の右肩上がりのそれを選択する
    • 既存のライブラリ・フレームワークがない
    • => 内製する
  • 新技術らしい
    • => 内製する

背景

  • サービス開発コストは人件費が多くを占める。学習コストを圧縮するために Google 検索が必須である。
  • ライブラリ・フレームワークは、通常、拡張可能にできる仕組みを提供している。ユーザーベースが大きいライブラリ・フレームワークを選定するとこの拡張の恩恵を受けることができ、開発コストを圧縮できる。
  • 近年では個人ではなく企業に所属しつつ専属でライブラリ・フレームワークを開発し続ける例が増えていおり、流行しているライブラリ・フレームワークであればあるほど大きく投資を受けて開発しており、開発停止の憂き目にさらされるリスクが低くなる傾向がある。
  • ライブラリ・フレームワークを選定する際にそれ自体のパフォーマンスを比較する例をよく見かけるが、多くの場合において間違った判断を誘発するので避けるべきである。これは、コンピューティング環境は日々進化しており、現時点において 100ms かかる処理が 1.5 年後には 50ms で処理できるようになること、および、人件費・開発費と比較してスケールアウト / スケールアップによる少額コストで解決できる問題だからである。
    • ※これの例外は、スケールアウト / スケールアップできないプラットフォーム(ゲーム, 組み込みシステム関連)で、CPU/GPU/Memory が固定あるいは並列数を増やせない環境である。
  • ライブラリ・フレームワークを選定する際にそれ自体の機能、ネーミング、シンタックス、セマンティックスを比較する例をよく見かけるが、(以下同文)

Share this post:
Child pages:

Comments