【汎用ソフトスキル】技術選定のやり方
この記事の目的
ここ最近「技術選定」と呼ばれることをちょくちょくやるようになってきたので、その際に考えたよしなしごとを書き留めておきたくなった
この記事の想定読者
- 仕事として初めて技術選定をやることになった人
- 「この案件、技術何つかうか決めるところからやって〜」と言われた人
- 特に以下の場合(私の経験が大体これ)
- チームが5人程度
- 既存プロダクトがある状態での新規開発や規模大きめの追加機能開発
- エンジニア組織がすでにある程度社内にある
- 「技術選定ってどんなことしているんだ？」と気になった人
この記事の想定読者ではない人
- 一定規模のエンジニア組織の基盤となっている技術について選定する人
- 大規模開発の技術選定のやり方が知りたい人
- そんな経験は無いのでむしろ教えてほしいです(ブログ書いてほしい)
- 個人開発の技術選定について考えている人
- 基本的には会社での開発を前提に書いています
- 個人なら好きな技術つかえばええんや
はじめに ~技術選定のイメージとギャップ~
技術選定、いい響きですよね。伝説の剣を石の台座から引き抜く！ みたいな感じがしてかっちょいいです。
「仕事で技術選定やりました」というと、エンジニアとしてある種一定のキャリアを積んだ感がでてステキです。
- 検討に検討を重ねる
- 数多の選択肢の中から最もいいものを選ぶ
- 決定した技術に長く責任を負う
みたいなイメージがあり、初めて明確に「技術選定をやる」という話になったときは随分緊張したものです。
しかし、実際にはそんな厳かで華やかなものではありませんでした。
実際にやってみた技術選定は
- 検討に検討を重ねる時間はない
- たくさんの選択肢すべてを比較する知識は(少なくともぼくには)ない
- でも責任は負う
といったものでした。
伝説の剣というより角材選びに近く、納期が襲ってきたから手元にある角材の中から最も良さそうなものを掴んで殴る、といった感じです。
どうすれば取り回しが良くて威力が出やすい角材を選べるのか、みたいな泥臭いノウハウについて、時系列順に綴ってみたのがこの記事です。(比喩の治安が悪い)
技術選定のすすめかた
さて、それでは実際にどのように私が技術選定を進めるか(あるいは、すすめるべきだと思っていあるか)について、時系列順に語っていこうと思います。
その1 前提条件を整理する
まず最初にすべきことは前提条件の整理です。いわゆる要件定義ですね。
私はdesign docのフォーマットを参照に作成することが多いです。(詳しい紹介は以下の素晴らしい記事に譲ります)
design docだと漏れる内容で技術選定に必要なものもあるので、それについても簡単にまとめます。私は以下についても整理しました。
- スケジュール
- いつまでにサービスインしている必要があるか
- その時期は調整が可能か
- バッファはどれくらい見るか
- スケジュール内に完了しなくて良い仕様はあるか
- いつまでにサービスインしている必要があるか
- プロダクトの現状の整理
- チームメンバー(自分を含む)は誰か？
- メンバーの技術スタックは？
- メンバーのモチベーションは？
- 手元にあるものは再利用できるか？
- 既存のプロダクトに似たものはあるか？
- チームメンバー(自分を含む)は誰か？
その2 新しいことをやる必要があるかを選定する
ここで一つ残念な話があります。それは、技術選定はこの時点で終わっていることが多いということです。
なぜなら、ほとんどの場合でもっとも有効な手段は現在と可能な限り同一の技術スタックで実装することになるからです。
- チームメンバーが使い慣れた技術のほうが開発速度が出る
- 社内の信頼性の高い既存の実装の使いまわしができる
- 保守フェーズに入ったとき、技術スタックが揃っているほうが情報収集や採用がやりやすい
- 稟議や反社チェックなどの社内手続きをせずに済む
などという、当たり前ながらつまらない話です。
これを乗り越えて新しい技術を使う必要があるケースは
- 外部仕様の時点で組織に知見が無いことをやる必要があることが確定している
- XaaSの導入で既存の実装をアウトソース化する
- エンジニア組織の技術力向上のための投資/リプレイス
などでしょうか。ちなみに私は3のパターンは今の所経験したことがないです。
おそらくレアなケースで、実際は「合理的な理由があるか微妙なんだけど新しい技術でサービス作っていいよ」みたいな話として発生するんじゃないかと思っています。あまり好きな言葉ではありませんが、いわゆる「信頼預金」の残高が高い状態で、いままでの仕事の報酬の一環として発生するパターンですね。
エンジニアとしては「今ある技術スタックでやったほうがリスクが低い」という真摯な提案をしたくなりますが、「リスクはあるが新しい技術にチャレンジしたほうがよい」という提案をするほうがあなたやチームメンバーのためになることが多く、回り回ってそれが会社のためになったりもします。 (もちろんケースバイケースですが)
その3 新しい技術を選定する
ここまでたどり着いた方は非常にラッキーです。見事「技術選定をやる」という機会を手に入れました。
存分にやっていきましょう。「なんの技術を選ぶのか」によってやり方は変わると思いますが、私が意識した(あるいは、意識すべきだったと反省した)ポイントを以下に書き連ねてみます。
スケジュールを設定する
段取り命。あらゆる仕事に納期があるのと同じで、技術選定にも納期があります。まずはスケジュールを作り込みましょう。
新しい技術を導入する以上すべての選択肢の中から最も優れたものを選びたい！ と思うのは人情ですが、残念ながらそれは現実的ではありません。
選定する技術について、調査する範囲/対象と、どの程度の時間がかけられるのかについて合意をしておきましょう。プロダクトの納期が一定であれば、技術選定に時間をかけるほど、実装にかけられる時間は短くなります。最良の技術で1日で作られたプロダクトより、次点である技術で1週間かけて作られたプロダクトのほうが品質は高くなることは想像に難くないでしょう。
候補を探す
まずは第一候補をまず見つけましょう。
これはどんなやり方でもいいです。あなたが知っている技術が今回の要件に適合すればそれで良いです。全く知らない内容なら、ググって一番上に出てくるもので構いません。
第一候補を見つけたら、その対抗候補をいくつかピックアップしましょう。
- 「vs」などのキーワードで検索する
- nodeだったらnpm trendsなどで比較対象を探す
- 詳しい人に聞く
- 同僚
- 友人
- SaaSのサポートや営業
などが手段としてはあげられるでしょうか。
この際、ここで見つけられなかった技術については今後一旦考えなくて良いです。
すぐにと見つからない時点で、それを今のメンバーが使いこなせる確率はかなり低いからです。繰り返しますが、時間は有限です。まずは見える範囲から調査を始めましょう。
候補情報を集めて比較検討する
集めた情報を整理して、第一候補となる技術を一つに決めましょう。
私が比較する際に気にするのは以下のようなポイントです。
- そもそも要件を満たすことができる技術か
- 既存技術との相性はどうか
- ex) react-nativeなら専用のライブラリがあるかなど
- 社内の技術スタックが離れすぎではないか
- ランニングコストはどれくらいか
- SaaSの場合、サービスそのもののの「価格」ではなく、実装工数などを含めた総合的なもの
- 多少単価が高くても、開発やメンテナンスにかかる人件費を考えると割安になることも多いため
- トレンド / 活動頻度。これからその技術は成長しそうか、急なEOLを迎えないか
- OSS(非商用ソフトウェア)の場合
- github上の活動はどの程度活発か
- 他社の導入実績があるか
- 商用ソフトウェアの場合
- ベンダーが力を入れているサービスか
- サポートが終了しなさそうか
- 自社の入っている or 入れる商用サポートの範囲はどの程度か
- OSS(非商用ソフトウェア)の場合
- エンジニアのモチベーションをあげられるか
- 「エンジニアが使いたい技術である」ことにも正当性がある
- 興味から事前情報を得ているので効率が上がる
- 社外から優秀なエンジニアの採用ができるようになる
- 好きな技術でものを作っている時のエンジニアは作業効率が倍くらい(体感)違うため最終的なアウトプットがよくなる
- などなど
- 逆に言うと、どれだけ条件にマッチした技術でも、あなたやあなたの同僚が仕事をやめるようになる技術選定はダメです
- 実装や保守をする人がいなくなっては本末転倒です
プロトタイピングを開始する
「これが良さそうだ」という候補が定まったら、プロトタイピングを開始しましょう。果たして、選んだ技術で無事作りたいものは完成するのか。試練の時の始まりです。
ここでも大切なことはスケジュールです。「プロトタイプ」といいつつも、大抵の場合プロトタイプとして作ったものはそのままプロダクトに採用されます。「プロトタイプの製造」という工数を投資したことになるので、そのリターンを得ようとするのは至極当然のことともいえます。
プロジェクトの最後になって「現在のプロトタイプで採用した技術ではどうしても要件を満たせなかった」ということにならないよう、なるべく一番複雑度が高い、難しい箇所から作ることを意識しましょう。初めて使う技術だと習熟のために簡単な部分をやった方がいいこともありますが、可能な限り困難は前倒しにしましょう。
スケジュールのどこかに「帰還不能点」を定めておくといいかもしれません。「帰還不能点」とは、飛行機が一定以上の燃料を使ってしまって、出発した空港に戻れなくなるポイントのことです。プロトタイピングには、「プロトタイプとして破棄して別の技術を選び直すことができる限界のタイミング」があります。
どれだけ技術を精査しても、第二候補以降の技術の方が良さそうに見えてくることがあります。プロトタイピングの初期段階ならそれを廃棄した方が効率がよくなることもありますが、プロジェクトの後半になるとそれは「迷い」でしかなくなります。大抵の場合、第一候補の技術の理解度を上げた方が効率的です。「もう戻れない点」を設定し、それ以降は一旦第二候補以降の技術のことは頭から締め出しましょう。
（オプション）チームメンバーを巻き込む
あなたが2人以上のエンジニアがいる組織でこの技術選定をしているようだったら、可能な限り早い段階で同僚を巻き込みましょう。同僚はあなたが触っている自分の知らない技術に興味があります。純粋にその技術が好きかもしれないし、未知の技術に対して不安になっているかもしれません。
ペアプロやモブプロを活用して人を巻き込みましょう。自分以外の視点の介入は、技術の習熟を助け、プロトタイプをより良いものにしてくれます。
プロダクトを仕上げる
ここから先は、いつもの仕事と同じです。
手元にある技術で、QCDのバランスをとりながら少しでも良いプロダクトを作り上げましょう。
おわりに / 技術選定の成功と失敗
さて、こんな感じで私が「技術選定」の際にきにしていることはだいたいしゃべりつくしました。
「偉そうに書いたけど、私自身も出来ていないことが多いなぁ」と色々よい振り返りになりました。
技術選定というイベントはこれで一区切りですが、何度かやりきって学んだことが一つあります。
それは、選定した技術はいつか不適当な技術になる ということです。
エンジニアが触る技術というのは、それ自身が日進月歩で成長します。未来永劫、絶対的な正解となる技術を選ぼうとすることはナンセンスです。
(特にWebフロントエンド界隈はその傾向が顕著です。2015~17年頃にflowtypeとtypescriptを比較検討して、typescriptを選んだ会社は少ないと思っています)
そして何より、技術を使うエンジニア側も変化します。ある時点では最適だった技術スタックも、メンバーの成長(あるいは離脱や入れ替わり)で不適切となってしまうことも十分ありえます。
大切なことは、一度選定を終えた技術でも、それが本当に正しいのかの棚卸を定期的に行うことです。
「プロダクトに問題のある技術を使用していること」は技術選定の失敗ではありません。どれだけコストを掛けて検討された技術でも、ときが経てば技術自身がフィットしなくなることは構造上仕方のないことです。技術選定の失敗とは、むしろそれを認めず、不適当な技術に拘って改善できなくなることにほかなりません。
(自社ライブラリや、エッジの効いた技術の採用などが往々にしてこの現象を引き起こします)
冒頭でも話しましたが、プロダクトに採用されている技術は伝説の剣ではなく角材です。
別の角材に持ち替えることは困難が伴いますが、それでもいつかはそうしなければならないタイミングがやってきます。(ライブラリのEOLなどがその一番わかり易い例です)
技術選定を続けましょう。いつか来るその時に、使い慣れた角材を伝説の剣だと勘違いしないために。
続けれられるかどうかが、技術選定の成否の一番大きなポイントだと私は考えています。
Discussion