エンジニアリングマネージャー目線で見るライブラリ技術選定の勘所

エンジニア

技術選定、してますか？

こんにちは！エンジニアリングマネージャーの佐藤（@unsoluble_sugar）です！

今回は開発関連のライブラリやアセットを導入する際に、個人的に見ている技術選定過程のポイントについて書き残してみることにしました。

エンジニアであれば様々な場面で技術選定の判断を求められるかと思います。フロントエンドやサーバサイド、ネットワーク・インフラ構築、CI/CDといった開発領域。OS、言語、フレームワーク、開発ツール、SaaS、プラットフォームetc...

挙げだすとキリがないですよね。

f:id:unsoluble_sugar:20200105164117j:plain

個人開発等でユーザーの母数が小さかったり、運用期間が短く影響範囲が軽微な場合はそれほど気にしなくて良いかもしれません。一方で、企業としてシステム・アプリ開発をする上では、開発して終わりではなく中長期での運用保守が前提となりますので、サービス継続のための様々な点に注意しなければなりません。

対象プラットフォームや開発規模に応じて見るべきポイントは変わるでしょうが、本記事ではライブラリやアセットといった粒度にフォーカスを絞ることにしました。事例を交えつつ、ある程度汎用的に使えそうな技術選定の勘所をまとめています。

「実務経験が浅く、正直どの技術を使えば良いかわからない」といった若手エンジニアさんや「なぜその技術を選んだのか？と問われた際にきちんと説明できるようにしておきたい」という方に、技術選定における指標のひとつとして参考にしていただければ幸いです。

技術選定で見るべき観点

技術選定で見るべき観点として、大枠以下のような要素が挙げられるかと思います。

  • 要件の整理
  • 評価基準の明確化
  • 候補のリストアップ
  • 技術選定
    • 機能面
      • 要求を満たしているか
      • 拡張性
      • 制限事項
    • 導入
      • 実績（導入事例）
        • ネット情報数≒利用者数
      • 継続性
      • イニシャルコスト（学習コスト）
        • サンプルプログラムの質
        • ドキュメントの充実性
        • 扱いやすさ
    • 運用・保守
      • 第三者評価
      • 問い合わせ窓口
      • GitHubリポジトリがあるなら
        • ライセンス形態
        • 開発者のバックグラウンド確認
        • コントリビューター数、スター数
        • 更新頻度
        • issue、プルリク対応の様子
      • セキュリティ
        • メンテナンス、アップデート体制
      • ランニングコスト
        • サブスクリプション型
          • 月額・年額費用の算出
        • 従量課金制の場合
          • APIなら時間帯位でのcall数やトラフィック量
          • SaaSならストレージ使用容量、セッション数、インスタンス起動時間など
      • スイッチングコスト
        • 依存関係
        • 類似ライブラリの候補も挙げておく
          • できれば定期的にウォッチ

これらの要素についてザッと見ていきましょう。

カテゴライズが曖昧だったり話の順序が前後したりしてますが…まぁ大目にみてやってください（予防線

要件の整理

大前提として「何を実現したいか」「何が達成できれば良いのか」を明確にしておく必要があります。システム開発における「要件定義書」にあたる情報がまとまっていると、技術選定も比較的進めやすいですね。

最近ですと、Design Docを採用している組織も多いでしょうか。

www.flywheel.jp

shimo5.me

atmarkit.itmedia.co.jp

キッチリと固まった段階でなくとも、技術選定と並行してこのようなドキュメントを整備していけば、判断基準も自然に定まっていくと思います。

評価基準の明確化

社内リソースで対応する場合であれば、担当メンバーの技術スタック（スキル・前提知識の有無・相談相手が居るか等）、キャッチアップ速度、学習コストをもとに技術選定を進めることが多いでしょうか。

開発期間や予算感によっては、外注できるか否かも判断基準のひとつになりますね。イニシャルコスト、ランニングコストに加えて、スイッチングコストも考慮する必要があります。

例えば利用しているライブラリのサポートが、OSのバージョンアップに追従できず途絶えてしまったり、機能改修が困難になりプラットフォームやサービスそのものがクローズしてしまうといった場合は、否応なく乗り換えが迫られます。

こういったリスクに対する余力はあるか？突発で対応依頼できるプールはあるか？開発速度と安定性のバランスはどう見るべきか？

開発チームに留まらず、経営層・ステークホルダー含めて中長期目線での判断基準を持っておくべきでしょう。

候補のリストアップ

要件を整理し、ある程度の判断基準を設けたら、ざっくり粒度で良いので関連領域においてどのようなライブラリが存在するか情報収集します。いくつかのキーワードの組み合わせでググって、検索上位に出てくる情報数多めなものをリストアップしておけば一旦大丈夫です。

続く技術選定の部分で詳細を辿っていくので、もしここで挙げた候補が見当外れであれば、改めて別のアプローチでリストアップし直せば良いだけですからね。

技術選定

前述の内容と重複する部分もありますが、候補がリストアップできたらライブラリのドキュメントを眺めたり実際に触ってみて、果たして本当に使えるものか見定める段階に入ります。

社内にノウハウや前提知識がない領域では「正直触ってみないとなんも分からん」状態で見積もりが出しづらいため、技術選定には一定の調査期間を設けて取り組むのが無難です。

規模感次第ではありますが、2,3日で終わるものもあれば1ヶ月～数ヶ月要することもあるでしょう。とはいえ仮の期間を設けて注力すれば、「わりとサクッと出来ちゃいそう」「もう少し時間必要かも」「他チームのあのメンバーにも協力して欲しい」とか何となく肌感が掴めます。100%技術調査に時間をかけられるなんてことは稀ですので、そのあたりも鑑みて今後の方針どうするかの議論を進めていくのが建設的ですね。

特にCTO、テックリード、エンジニアリングマネージャーといった役割を担う立場であれば「なぜその技術を選んだのか？」という説明責任を果たす必要があります。エンジニアメンバーからの提案に対しても、よくヒアリングし、気になる点があればディスカッションを重ねた上で慎重に検討していきましょう。

機能面

どの程度要件を満たしているか。パフォーマンスは十分か。拡張性はあるのか。要件の整理工程で洗い出した条件のマッチ具合を見ていきましょう。β版や新しくリリースされたばかりのライブラリは、機能も絶賛開発中で不具合に悩まされることもあります。

不足分は別のライブラリを使用すれば埋められるのか？自作でカバーできる範囲なのか？

一定の実務経験を積めば、過去の開発事例から注意を払わなければならないポイントも見えてきますが、比較的若いエンジニアメンバーで構成された組織ではこのあたり見落としがちです（自分もよく苦労しました）。

導入

流行りに乗って新しいライブラリを導入してみたが、サンプルプログラムの質が微妙だったりドキュメントが整備されていなかったりと「想像以上に学習コストが高かった…」なんてケースもありえます。

大体新しい技術を素早くキャッチアップしてアウトプットしている組織は、レベルの高いエンジニアが居るからこそ実現できているのです。成熟しきっていない技術は導入事例が少なく、参考情報も無く開発が難航することも多々あるでしょう。

一時は熱狂的な盛り上がりを見せていたライブラリが、1,2年後にひっそりと消えてたなんてことはザラにあります。仮に新しいライブラリを導入する際は、担当メンバーや組織にそれ相応の胆力があるかどうかも重要です。

また、忘れてはならないのがライセンスの話です。OSSに関してはここ数年で体系的に学べる書籍が出ているので、開発組織で購入したり社内勉強会等の場で知見共有すると、エンジニアメンバー間での認識も深まることでしょう。

OSSライセンスを正しく理解するための本

OSSライセンスを正しく理解するための本

Amazon

OSSライセンスの教科書

OSSライセンスの教科書

Amazon

運用保守

技術が好きなエンジニアであれば「最新技術を触ってみたい！」と思うのは至極当然の欲求です。しかしながら、ことビジネスの場においては、ある程度枯れた技術の方が最適な場合もあります。

新しい技術に興味を持って「やってみたい」という人は一定数居る反面、運用保守フェーズに入っているシステムでは即戦力が求められます。何か問題が起きた際の対応に関しては、前提知識がなければトラブルシューティングをこなすことが難しいケースも多いでしょう。

仮に「社内リソースで抱えきれないため外注に出す」という方針になっても、そもそもの母数がなければお願いする相手が居ないという状況が容易に発生します。メインの開発メンバーが離脱してしまうといった場合にも、その穴を埋めるための人員確保が必要です。

技術選定においては、その技術を扱える人材の流動性も考慮しなければなりません。最悪の場合、サービス運用面では至極健全にもかかわらず、開発人員が確保できないためクローズせざるを得ないといった事態に陥るでしょう。

そのような観点では、ライブラリの更新頻度やコントリビューター数、issue、プルリク対応の様子などをしっかり見定めることも大事です。例えばアセットやフレームワークに内包されたライブラリに脆弱性が見つかった際、すぐに対応が施されアップデートで事なきを得られれば「信頼性が高いライブラリ」と言えるでしょう。

逆にいつまで経っても対応の気配が見られず、対象部分がブラックボックス化されており自力での差し替えも難しいといった状況では、セキュリティリスクに晒され続けることになります。

最近はSlackやDiscord上でQ&Aのやり取りが交わされているケースもありますから、コミュニティに飛び込んで活発度を俯瞰するのもアリですね。

事例紹介

ここまでフワッとした持論を展開してきましたが、最後に事例紹介を挙げてお開きとさせていただきます。

先日社内のWebAR関連の技術調査の一環として、Unityで使えそうなARライブラリを調べていました。いくつか候補が挙げられていた中で、自分が調査担当となっていたARWTについての情報を転記しておきます。

github.com

デモ動画だけ見ると「めっちゃ良さげやん」ってなるやつです。

youtu.be

結果的には採用するに至らなかったライブラリとなりますが、技術選定の過程として具体的にどのような部分を見て判断を下したのか、少しでも参考になれば幸いです。

ARWT調査メモ

以下、調査しながら箇条書きで書き残したメモです。

こんな感じで情報収集し、今回は深入りしないことにしました。

蛇足

ちなみにARWT以外の候補として、他メンバーがPlayCanvasや8th Wallも見てくれていました。特に8th Wallは、直近でNiantic に買収されたというニュースが飛び込んできて驚きましたね。

大手企業の後ろ盾があると、開発基盤やサポートまわりも確固たるものとなるでしょう。このような最新情報のキャッチアップも、技術選定をする上では欠かせませんね。

まとめ

少数精鋭のスタートアップやベンチャーですと、わりとこの手の判断が個人依存の暗黙知となっていることも多く、開発が佳境に迫った頃に「実は肝心な部分を見落としていた」なんてことも珍しい話ではないでしょう。

そんな悲しい事件を防ぐためにも、エンジニア組織内でこういったノウハウを可視化、テンプレ化しておくとメンバー入れ替えが起きても一定の担保が得られるのではないかと思います。できれば複数人のメンバー目線の意見を突き合わせて、納得感のある技術選定をしていきたいですね。

これ以上の粒度で事細かに書いていくとキリがなさそうだったので、今回は要点を絞って書き連ねてみました。

「こんなところも見た方が良いのでは？」というアドバイスや「この観点の抜け漏れで詰んだ…」等のエピソードがあれば、ぜひコメントやSNSシェア経由で教えていただけると嬉しいです。

最後に

本テックブログやnote記事のお知らせは、Synamon公式Twitterで発信しています。弊社の取り組みに興味を持っていただけましたらぜひフォローお願いします！

twitter.com

カジュアル面談も実施しているので「詳しく話を聞いてみたい！」という方は、こちらもチェックいただけると嬉しいです。

▼カジュアル面談はMeetyから   meety.net  

▼エントリーはこちら   herp.careers