ushironoko.me

企業的な技術投資について

2021/01/15 ⏳ 3 min read

技術投資は必ずしも企業の利益に直接的に結びつくことはないため、行動のリターンを見積もることが難しいと言える。例えば新機能の開発のためのタスクは単純に納期があるため、タスクごとにポイントを振って合算したものからリリース日を計算することができ、その工数と予測されるインパクトを比較して優先度付けを行える。一方「VuexをTS化する」とか「mixinsをComposition APIに置き換える」とか、そういったものは持続可能な開発現場を作るための未来への投資であり、顧客へ間接的に価値を与えるものになる(開発スピードの維持やバグ取りなどいわゆるスケーラビリティ)。そういったことからしばしばコストセンター的な仕事と表されることもあって、主にこの作業を推進している部署にいる身としては存在している理由くらいはほしいと常に思っていたりする。

とくにここ数年間このコストセンターと向き合った結果、自分は他の開発メンバーへの投資をしているという感覚になってきた。新しい言語機能やライブラリを先行して調べたり実践投入して踏み荒らすことで将来スケーラビリティに影響しそうな設計や思想を体験し、さらに得た知見をトレーニングやドキュメンテーションによって共有する。実質的に自分の努力によって企業に入るお金は0円とも言えるのでまさにコストセンターな仕事だが、本来開発中に出るはずだった疑問やハマりなどはすでに学習済みなのでより素早く正確に開発できるはず。つまり一人が先に賢くなっておき、メンバーへ拡散させ全体のレベルを同じところまで引き上げる、というのをやっていけば少ないコストで技術投資をできるだろうという考え方。これは身近なメンバーだけでなく他部署にも機能することがあり、とくにドキュメントにしておくことで無限に人を助けることができてお得である。技術投資をするなら企業へ還元するところまで考えた方が、やっている側としても自己を肯定しやすい。

ただしこの仕事に多くの人員を割くのは間違っており、2人くらいでやるのが現実的なペイするラインだろうと思う(2人いないとレビューできないので)。感謝される立場ではあるもののお金をリアルタイムには生み出しておらず技術投資に投資しすぎると組織全体のパフォーマンスが下がってしまう。またできるならメンバーは固定化せず流動的にアサインできると良い。固定化してしまうと顧客に近いラインで開発する感覚を忘れていってしまうため、サービス志向を維持できなくなる(実際経験した)。企業に所属し社員として働く以上我々の書くコードは顧客が存在しないと無価値なもの、というのは常に意識として持っておくべきで、技術投資を行う時でも最終的なプロセスとして顧客のためになる、まで考えられると良い(mixinsをcomposition apiへ移行する → より関心事でロジックをまとめたコードになる → テストが関心事で書かれるようになる → ユーザーの操作に近いテストが書きやすくなる 等)。

とはいえこの作業はOSSのバグを踏んだり自身の理想を実現したくなったりで予想よりも時間を浪費してしまうことが多く、前述のようにROI的な思考から離れることもしばしばあった。特に自分は一度理想に気づく体験をするとそれが目の前に現れるまで没頭してしまうきらいがあって、区切りを付ければできたことがたくさんあり申し訳ない気持ちになる。2人でやっていればお互いが注意できるが、何度も同じ目に合わないようにしくみとして何かやっておくと良かったりする。

ソフトウェアを書くときは見積もりよりも予算が大事

事前に予算を決めてスクラムであればデイリーなどで都度確認して予算内に収まりそうか、溢れる場合どこを落とし所にするかなど細かく調整していく必要がある。そしてそれによって想定よりも企業(開発組織)へ還元できることが少なそうであれば、それはインパクトが少ないということであり優先度が下がる。結局はフィーチャー開発の手法と変わらないということかもしれない。

余談

composition apiへの投資は今の時期優先度が高いと言える。Nuxt3のリリースにはVue3対応やcomposition apiに基づいた最適化が多数含まれていることが考えられ、現時点で知見をためておくことでスムーズに移行できたり恩恵を受けられる部分が増えるはず。逆に投資をサボると移行への障壁としてcomposition apiの対応がしんどいなぁよくわからんし、になるためできることはさっさとやっておくと良い。エコシステムも徐々にVue3を前提にしたものが出てくるはずだし、取り残されるかより進化するかならみんな後者を選ぶはず。