技術選定についてちゃんと考えてみた。
こんにちは。@inase17000です。
この記事は ユアマイスター Advent Calendar 2020 1日目の記事です。
初日というのは何度やっても緊張するもんで、ブログを書くのも結構久しぶりだったりするのでさらに緊張感を持っています。
さて、今回何について話そうかと考えたところ、僕が働くユアマイスターのことと最近のライフワークになりつつあるポッドキャストのことを絡めていきたいと考えたところ、ふとテーマが決まりました。
それは、ユアマイスターの技術選定の考え方です。実際にぼくが考えていったプロセスを追いながら、順を追って説明していきたいと思います。
技術選定とは
普段の開発業務を進める中で毎日でくわすテーマではないものの、ソフトウェアエンジニアや、インフラやミドルウェアをいじるSREも、それぞれのレイヤーで技術選定が必要な時が必ずやってきます。
アーキテクチャーに関わるような大きな規模での技術選定だと、「経験年数が少ないうちは任せてもらえないでしょう」なんて思うことがあるかもしれませんが、コードレベルでライブラリの利用やクラス設計レベルでの選択も様々なデザインパターンから適性に応じてどれを選ぶかという点では技術選定の一種であるとも言えます。
つまり、遠いものではなく、とても身近なものです。偉い人がやるものではない、１エンジニアができるようになっておかないといけないことなんです。
とはいえ、本当のゼロベースからのスタートアップでは実際問題こんなこと気にしてる場合ではないと思います。とにかくいち早くMVPを世に届け、価値があるのか確認することに重きがおかれるので、あんまり大事にはされません。それもひとつの選択。
しかしながら、数年やってきた中で辛かったこともありました。
・全く新規の構成にチャレンジしたアプリケーション。長期間の開発の後にやっとリリース。その構成について知ってる人が少なすぎて、一人しかデプロイ作業ができない。
・未来を想定して新しい言語とフレームワークを選んだ。会社のメインの言語とフレームワークとは違うから掛け持ちがつらくなり、なかなか開発が進まない。
他にも不都合な真実はいくつもあるのですが、結局はある技術を選ぶときにしっかりとした根拠を持って議論を行い、準備に時間をあてないと後々苦労するというよくある問題をどうやって解決していくか、というよくある話なわけです。
技術選定のルールを作る目的
ユアマイスター では、
HAPPY TRIANGLE
FEEDBACK is GIFT
SPEED with QUALITY
FAMILY FIRST
GRIT! GRIT!! GRIT!!!
という行動指針をベースに日々の業務を遂行しています。（行動指針についての詳細はこちらの記事がオススメです）
これらを技術選定で体現しようとすると、以下のような考えに分解することができます。（5つある中3つしか使ってない）
技術をプロダクト・お客様のために最大限活用する（HAPPY TRIANGLE）
→手段と目的を間違えず、技術を使って課題を解決する
開発スピード・効率を犠牲にしない（SPEED with QUALITY）
→生産性を落とさず、生産効率をあげていく
選ぶ責任＝使い続ける責任（GRIT! GRIT!! GRIT!!!）
→選ぶ理由を説明できるか、導入実績に満足していないか、改善する仕組みがあるか
目的意識をもち、説明責任を果たせる、継続的な開発に寄与する技術選定ができるようにこの方針をチームの合意事項として進めていこうと考えました。
技術選定の対象
まずは技術選定の対象をどのように決めるかについて考えてみましょう。
技術スタックのスタンダード（以下、技術スタンダード）を定義し、フェーズや規模にそぐわないとなった場合、必要に応じてアップデートを許容するものとして運用します。
技術スタンダード(2020/09/09現在) ※一部抜粋
言語：PHP, JavaScript, TypeScript, Ruby, Swift, Kotlin, Dart, Google App Scripts
フレームワーク：CakePHP, Vue.js, Flutter, jQuery
ミドルウェア：Apache, Nginx, Express(Node.js), Wordpress
このベースがあることによって、エンジニアが技術選定を発案するときに検討するスコープを狭めることができるのと、新しくジョインしていく人も早く共通認識を持つことができる、という効果があります。社内ではこれをConfluenceページに定義を記載し、常時閲覧可能にしています。
技術選定の評価軸
対象が決まったところで、次に考えるのは検討材料です。
技術選定においては、下記の評価軸を使って、比較または議論、意思決定を行います。あらかじめその技術の特性を調査し、提案を行ってもらうことで、複数の観点から審議を行うことができるようになっています。
目的の実現度
・対象の技術の得意不得意を理解し、適合している説明ができるか
・サービスレベルがユアマイスターのサービスレベルに合っているか
・技術利用のリードタイムが目的に対して、適合しているか
・対象の技術を他のシステムに適応した場合のメリットがあるか
情報
・公式ドキュメントが充実しているか
・コミュニティが存在し、活発活動が行われているか
・セキュリティ対応を含む、定期更新がされるか
・ライセンスポリシーに適合するか
将来性
・世間の技術トレンドに沿った選択であることを説明できるか
・対象の技術と競合するはは技術と比較して優位な点があるか
費用対効果
・導入にあたりイニシャルコスト、ランニングコストを見積もることができるか
・導入しない場合に比べ、導入した場合の生産性向上度合いを定量的に説明できるか
この４つの評価軸を（多少無理やりに）分類すると以下のような関係性になると思っています。
社外で流行っているからといって必ずしも、目的の実現のために最短の方法ではないことが多いですし、費用対効果がよいからといって明らかに独自な方法をとっていては、世間には情報が流通しないオレオレフレームワークを採用し続けることになりえます。
もちろん検討の中で全部が完璧に満たされる事ばかりではないと思っています。その時は検討を尽くしたあとで、最終的にそれを使い始め、その後もメンテナンスし続けるというエンジニアの覚悟の上に成り立つものだと思っています。
どんな選択もメリットデメリットあるわけですし、一番確率が高そうなものに賭けた上で、なんとか形にする力もエンジニアリングの一部だと思っています。（過去に出会ってきたつよつよエンジニアは、基礎の土台の上に、そういったなんとかする力がありました）
未来を予言することができなくても、現状を把握することはできます。明確な評価軸を設け、誰でも必ずチェックをすることができる基準を設けることで、エンジニアが新たな技術選定をどんどん提案できるような体制を築いていきます。
最後に
改めて思うこととしては、
・技術をプロダクト・お客様のために最大限活用する
・開発スピード・効率を犠牲にしない
・選ぶ責任＝使い続ける責任
ということで、選ぶことが目的にはなってはいけないし、使うことが目的になってもいけないのです。
あくまでプロダクトの課題を解決するための最適な方法を選び、それを使い続けて本来の目的を果たす行為の一環として大事なことなんだなと感じました。
以上、ユアマイスターでの技術選定の考え方を公開させてもらいました。
ユアマイスターではエンジニアを積極採用中です。
ご興味ありましたらお気軽にご連絡ください！
P.S. ポッドキャストの宣伝もさせてもらいます。もしよろしければこちらもあわせてご鑑賞ください。
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか？