はじめに
この話は数年前(かなり前⁈)のことです。
ある日、上司から「次の案件で業務向けWebアプリの技術選定をやってみないか？」と言われ、
私「はい、よろこんで！」と即答。
(案件チームは5人で納期は短めの小規模のもので、筆者(当時入社一年目)は初めての技術選定)
当時、私の会社では、フロントエンドでよく用いられる技術はjQuery95%、Vanillaのjavascript5%といった感じだったので、
私は、せっかく任せてもらったので今まで案件で採用していない技術を採用してみようと思い、
ライブラリの豊富さと公式ドキュメントの読みやすさ、パフォーマンスなどの点からReactに挑戦することにしました。
いざ、PGのコーディングフェーズがスタートすると、、
思いのほか、進捗が上がらず、学習コストがかかってしまっていた。
(私とリーダーは経験者、その他のメンバーは未経験)
納期も短めのこともあり、みんなで協力プレーでどうにか乗り切った。
(予定納期より若干遅延した🙇♂️)
失敗と学び
技術選定の理由が身勝手すぎた。
「今まで案件で採用していない技術」、「モダン」だからはあまりにも身勝手な理由だった。
(当時React、Vueが盛り上がっていて、正直なところ、実務経験を積みたかった。)
ユーザー視点で考える
ユーザーには、レガシィ、モダン、難しい、簡単、な技術を用いたかどうかは関係ない。
ただモダンや、最新技術だから、使ってみたいから、でなく、ユーザーにとってどんなメリットがあるのかを考えて
選定すべきだった。
チームメンバーの特徴の把握
メンバーみんなの学習速度は同じではないし、プライベートで学習できる人もいれば、育児や介護などに追われ、学習できない人もいる。
私は「プロダクトや技術」が好きだから、趣味で技術的な学習は楽しいが、
IT企業に勤めているからといってみんなが「プロダクトや技術」が好きではないと思っている。(会社規模や雰囲気にもよるかも)
なので、フレームワークなどの学習コストがかかりがちな技術を新たに導入する際は、
チームメンバーの構成や特徴の考えて、
業務中で学習が完結するかどうかなども加味して、学習コストを考慮するようにしている。
おわりに
今考えてみると、どれも当たり前のことが出来てなくて
当時の自分に喝を入れたいぐらいだが、
失敗から学んだおかげで、今があると思うので
同じ過ちを繰り返さないよう、常に気を引き締めていきたい。