以下の記事やその反応を見聞きして、前職で技術選定時にあった色々を思い出したので書きました。ただの愚痴。
TypeScript の型定義に凝りすぎじゃね？ - Neo's World
アンサー： なぜTypeScriptの型定義に凝るのか - Qiita
要約
- 前職で Typescript 入れたい私と JavaScript 派の先輩で対立した
- その争いはただの派閥争いに発展したし、良くなかったと思っている
- 私はこう失敗した、という振り返りをするだけで何も答えは持ち合わせていない
- [問い] 技術選定で対立したときどういう態度で解決までもっていけばいいんでしょうね？
思い出話
前職で、書いた人が居なくなり焦げついてしまっていたweb管理画面があり、それを一から作り直そうというプロジェクトがありました。
そこで Typescript 導入したい派の私と、JavaScript 派の先輩で意見が対立したのでした。
対立の解決に失敗した
先輩の意見はおおむね以下のような感じでした。
先輩の意見
- 早く書けない
- 先輩自身はちょっと書いたけどタイプ数大いし面倒に思った、らしい
- 無駄に複雑になるだけ
- 学習コストに見合うだけの恩恵がない
- というソースもある、という主張
先輩の反論は上記のようなもので、それに対して私は以下のような反論をしました。（後に反省を書くが、これは本当に良くなかった）
私の反論
- 早く書けないというのは慣れの問題では
- 採用すれば慣れるだろうし、タイプ数の多い言語でも利用人数が多く安定している言語はあるから、その観点で TypeScript を採用しないというのはデメリットとしては弱いのでは
- その複雑性（というのが適切かは分からないが、型情報などの TypeScript がもつ JavaScript より拡張している部分）の恩恵を感じるという意見もあるわけだし、それが「無駄」な複雑性かどうかは仕事としてちゃんと書いてみないとわからないのでは
これは本当によくなくて、この話が進んだ結果「新しい技術にチャレンジしたい派」と「枯れているものを信用する派」の対立になってしまって、チームが二分されてしまったのでした。本当によくなかった。
今の私目線での反省
上記の話より後になってから私のポリシーになった概念があって、「意見の対立と利害の対立は違う」という概念なのですけど、これは「意見が違う人のことを自分とは求めるものが違う人なんだということにしないで、奥底の利害が一致しているのかしていないかを重視しよう」みたいな感じのものです。
（私の心のなかから生まれたものなので、あまり洗練されていないとは思います。）
そういう考えになった今の私で上記のケースについて考えますと、先輩とは結局のところ「特定の言語を採用することでよい開発をしたい」「この会社ではいろいろあって書きなおしたりリプレースすることはあまり考えられないので、できるだけ良い選択がしたい」みたいな気持ちだったことは想像できて、そこは私もおおむね同意で（退職してから思うのは、いや焦げ付く前に定期的に書きなおせることも大事ではという気もする）、そこから「私たちは本質的に何を求めていて、何が最適なのでしょうか」という話が出来たらよかったのだろうと思う。
その頃の私は正直「この人はもう新しい言語について勉強したくないだけなんだろうな」と思ってしまっていたし、私と先輩は求めるものが違う、という気持ちになっていた。本当に良くない同僚だったと思う。反省している。
今の私ならこうした
ところで、新しい職場では Typescript を書いているのですけど、今の私は TypeScript すごく好き。少なくとも、単なる JavaScript を書いていた頃よりは確実に楽になった体感がある。そのあたりの話は私が私の言葉で語るより、記事上部にも貼っている
アンサー： なぜTypeScriptの型定義に凝るのか - Qiita
とかを読んだ方が有益なので詳細を語らないけれど、とにかく思った。「前職で採用する採用しないとかの話の前に、今くらい TypeScript の良さを知ってたら、もっと効果的に推せたよな」と……。
なので、今の私としては
- この技術を選択する理由を、自分の言葉で語れるようになる程度の時間をください
というのが誠実な態度なのかな、という気がしている。
結局、技術採用した後も「その技術の良さ、悪さが自分の言葉で語れる程度」にはその技術について習得する必要があるだろうし、習得していない状況は信頼できない開発者だと自分の今の状況を鑑みると思う訳である。
（ちなみに、そういう基準だと、今の私は体感として少々 TypeScript いいなという気持ちはあるし、具体的に助かるケースを挙げることは出来るが、では上記の Qiita のような内容を自分の言葉で語れるかというと非常に怪しいので、まだ TypeScript を推す資格は不十分なのである）（でもまあ、私が具体的に助かるケースを述べることで私より強いチームメンバーが TypeScript に興味を持ってくれるかもしれないし、過去の私は実際に書いてみて推すのが今考えられるより良い選択かな、という気がする）
でも結局何が正解かはよくわからない
でも私がマネージャだったら、プログラマに早く実のあるコードを書いてほしいのに「技術選定のためにAとBについて自分の言葉で語れるようになりたいので時間をください」って言われたら「それっていつまで？」「どこまでやったら自分の言葉で語れるようになるわけ？」「もうAでいいから早く書けないわけ？」みたいなこと思う気がするし、前職でもそんな感じの話になったのでつらいよなあ、という感じがある。
今の私は「それっていつまで？」と言われても「わかりません……心で理解できたと思うまでです……」としか言えないし、たぶんそこはそこでモメるんだろうなと思う。
だからまあ、私は技術選定の議論にいないほうがいい人間な気がするし、「そういうシチュエーションになってしまっているのがそもそもの事故であって、すでに自分の言葉で語れる人に判断を仰いじゃうとか、エイヤで決めちゃう」とかが現実的なのかなという気もする。正解は分からない。誰かこっそり教えて。
