Blogこの広告は、90日以上更新していないブログに表示しています。2022-03-14エンジニアリングマネージャー目線で見るライブラリ技術選定の勘所エンジニア技術選定、してますか?こんにちは!エンジニアリングマネージャーの佐藤(@unsoluble_sugar)です!今回は開発関連のライブラリやアセットを導入する際に、個人的に見ている技術選定過程のポイントについて書き残してみることにしました。エンジニアであれば様々な場面で技術選定の判断を求められるかと思います。フロントエンドやサーバサイド、ネットワーク・インフラ構築、CI/CDといった開発領域。OS、言語、フレームワーク、開発ツール、SaaS、プラットフォームetc...挙げだすとキリがないですよね。個人開発等でユーザーの母数が小さかったり、運用期間が短く影響範囲が軽微な場合はそれほど気にしなくて良いかもしれません。一方で、企業としてシステム・アプリ開発をする上では、開発して終わりではなく中長期での運用保守が前提となりますので、サービス継続のための様々な点に注意しなければなりません。対象プラットフォームや開発規模に応じて見るべきポイントは変わるでしょうが、本記事ではライブラリやアセットといった粒度にフォーカスを絞ることにしました。事例を交えつつ、ある程度汎用的に使えそうな技術選定の勘所をまとめています。「実務経験が浅く、正直どの技術を使えば良いかわからない」といった若手エンジニアさんや「なぜその技術を選んだのか?と問われた際にきちんと説明できるようにしておきたい」という方に、技術選定における指標のひとつとして参考にしていただければ幸いです。技術選定で見るべき観点として、大枠以下のような要素が挙げられるかと思います。類似ライブラリの候補も挙げておくできれば定期的にウォッチこれらの要素についてザッと見ていきましょう。大前提として「何を実現したいか」「何が達成できれば良いのか」を明確にしておく必要があります。システム開発における「要件定義書」にあたる情報がまとまっていると、技術選定も比較的進めやすいですね。Docを採用している組織も多いでしょうか。www.flywheel.jpshimo5.meatmarkit.itmedia.co.jpキッチリと固まった段階でなくとも、技術選定と並行してこのようなドキュメントを整備していけば、判断基準も自然に定まっていくと思います。社内リソースで対応する場合であれば、担当メンバーの技術スタック(スキル・前提知識の有無・相談相手が居るか等)、キャッチアップ速度、学習コストをもとに技術選定を進めることが多いでしょうか。開発期間や予算感によっては、外注できるか否かも判断基準のひとつになりますね。イニシャルコスト、ランニングコストに加えて、スイッチングコストも考慮する必要があります。利用しているライブラリのサポートが、OSのバージョンアップに追従できず途絶えてしまったり、機能改修が困難になりプラットフォームやサービスそのものがクローズしてしまうといった場合は、否応なく乗り換えが迫られます。いったリスクに対する余力はあるか?突発で対応依頼できるプールはあるか?開発速度と安定性のバランスはどう見るべきか?開発チームに留まらず、経営層・ステークホルダー含めて中長期目線での判断基準を持っておくべきでしょう。候補のリストアップ要件を整理し、ある程度の判断基準を設けたら、ざっくり粒度で良いので関連領域においてどのようなライブラリが存在するか情報収集します。いくつかのキーワードの組み合わせでググって、検索上位に出てくる情報数多めなものをリストアップしておけば一旦大丈夫です。続く技術選定の部分で詳細を辿っていくので、もしここで挙げた候補が見当外れであれば、改めて別のアプローチでリストアップし直せば良いだけですからね。前述の内容と重複する部分もありますが、候補がリストアップできたらライブラリのドキュメントを眺めたり実際に触ってみて、果たして本当に使えるものか見定める段階に入ります。社内にノウハウや前提知識がない領域では「正直触ってみないとなんも分からん」状態で見積もりが出しづらいため、技術選定には一定の調査期間を設けて取り組むのが無難です。規模感次第ではありますが、2,3日で終わるものもあれば1ヶ月~数ヶ月要することもあるでしょう。いえ仮の期間を設けて注力すれば、「わりとサクッと出来ちゃいそう」「もう少し時間必要かも」「他チームのあのメンバーにも協力して欲しい」とか何となく肌感が掴めます。100%技術調査に時間をかけられるなんてことは稀ですので、そのあたりも鑑みて今後の方針どうするかの議論を進めていくのが建設的ですね。CTO、テックリード、エンジニアリングマネージャーといった役割を担う立場であれば「なぜその技術を選んだのか?」という説明責任を果たす必要があります。エンジニアメンバーからの提案に対しても、よくヒアリングし、気になる点があればディスカッションを重ねた上で慎重に検討していきましょう。機能面どの程度要件を満たしているか。パフォーマンスは十分か。要件の整理工程で洗い出した条件のマッチ具合を見ていきましょう。β版や新しくリリースされたばかりのライブラリは、機能も絶賛開発中で不具合に悩まされることもあります。不足分は別のライブラリを使用すれば埋められるのか?自作でカバーできる範囲なのか?一定の実務経験を積めば、過去の開発事例から注意を払わなければならないポイントも見えてきますが、比較的若いエンジニアメンバーで構成された組織ではこのあたり見落としがちです(自分もよく苦労しました)。流行りに乗って新しいライブラリを導入してみたが、サンプルプログラムの質が微妙だったりドキュメントが整備されていなかったりと「想像以上に学習コストが高かった...」なんてケースもありえます。大体新しい技術を素早くキャッチアップしてアウトプットしている組織は、レベルの高いエンジニアが居るからこそ実現できているのです。成熟しきっていない技術は導入事例が少なく、参考情報も無く開発が難航することも多々あるでしょう。一時は熱狂的な盛り上がりを見せていたライブラリが、1,2年後にひっそりと消えてたなんてことはザラにあります。仮に新しいライブラリを導入する際は、担当メンバーや組織にそれ相応の胆力があるかどうかも重要です。忘れてはならないのがライセンスの話です。OSSに関してはここ数年で体系的に学べる書籍が出ているので、開発組織で購入したり社内勉強会等の場で知見共有すると、エンジニアメンバー間での認識も深まることでしょう。技術が好きなエンジニアであれば「最新技術を触ってみたい!」と思うのは至極当然の欲求です。ことビジネスの場においては、ある程度枯れた技術の方が最適な場合もあります。新しい技術に興味を持って「やってみたい」という人は一定数居る反面、運用保守フェーズに入っているシステムでは即戦力が求められます。何か問題が起きた際の対応に関しては、前提知識がなければトラブルシューティングをこなすことが難しいケースも多いでしょう。仮に「社内リソースで抱えきれないため外注に出す」という方針になっても、そもそもの母数がなければお願いする相手が居ないという状況が容易に発生します。メインの開発メンバーが離脱してしまうといった場合にも、その穴を埋めるための人員確保が必要です。技術選定においては、その技術を扱える人材の流動性も考慮しなければなりません。最悪の場合、サービス運用面では至極健全にもかかわらず、開発人員が確保できないためクローズせざるを得ないといった事態に陥るでしょう。そのような観点では、ライブラリの更新頻度やコントリビューター数、issue、プルリク対応の様子などをしっかり見定めることも大事です。アセットやフレームワークに内包されたライブラリに脆弱性が見つかった際、すぐに対応が施されアップデートで事なきを得られれば「信頼性が高いライブラリ」と言えるでしょう。逆にいつまで経っても対応の気配が見られず、対象部分がブラックボックス化されており自力での差し替えも難しいといった状況では、セキュリティリスクに晒され続けることになります。最近はSlackやDiscord上でQ&Aのやり取りが交わされているケースもありますから、コミュニティに飛び込んで活発度を俯瞰するのもアリですね。事例紹介ここまでフワッとした持論を展開してきましたが、最後に事例紹介を挙げてお開きとさせていただきます。先日社内のWebAR関連の技術調査の一環として、Unityで使えそうなARライブラリを調べていました。いくつか候補が挙げられていた中で、自分が調査担当となっていたARWTについての情報を転記しておきます。github.comデモ動画だけ見ると「めっちゃ良さげやん」ってなるやつです。youtu.be結果的には採用するに至らなかったライブラリとなりますが、技術選定の過程として具体的にどのような部分を見て判断を下したのか、少しでも参考になれば幸いです。ARWT調査メモ以下、調査しながら箇条書きで書き残したメモです。GitHub結論:普通にしんどそうこんな感じで情報収集し、今回は深入りしないことにしました。Wallも見てくれていました。買収されたというニュースが飛び込んできて驚きましたね。大手企業の後ろ盾があると、開発基盤やサポートまわりも確固たるものとなるでしょう。このような最新情報のキャッチアップも、技術選定をする上では欠かせませんね。まとめ少数精鋭のスタートアップやベンチャーですと、わりとこの手の判断が個人依存の暗黙知となっていることも多く、開発が佳境に迫った頃に「実は肝心な部分を見落としていた」なんてことも珍しい話ではないでしょう。そんな悲しい事件を防ぐためにも、エンジニア組織内でこういったノウハウを可視化、テンプレ化しておくとメンバー入れ替えが起きても一定の担保が得られるのではないかと思います。できれば複数人のメンバー目線の意見を突き合わせて、納得感のある技術選定をしていきたいですね。これ以上の粒度で事細かに書いていくとキリがなさそうだったので、今回は要点を絞って書き連ねてみました。「こんなところも見た方が良いのでは?」というアドバイスや「この観点の抜け漏れで詰んだ...」等のエピソードがあれば、ぜひコメントやSNSシェア経由で教えていただけると嬉しいです。最後に本テックブログやnote記事のお知らせは、Synamon公式Twitterで発信しています。弊社の取り組みに興味を持っていただけましたらぜひフォローお願いします!twitter.comカジュアル面談も実施しているので「詳しく話を聞いてみたい!」という方は、こちらもチェックいただけると嬉しいです。読者になる広告を非表示にする関連記事2023-06-13Unity公式のLoggingパッケージが使い勝手が良さそうこんにちは、エンジニアの渡辺(@mochi_neko_7)です。5はてなブログをはじめよう!Synamonさんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。