技術書にかかる費用が増えてきた。

リモート勤務になったことで読む時間が増えたからだと考えていたけど、よく考えるとその前からそれなりに購入している。人から言われてではなく自分が読みたいから購入しているし、仕事で使う内容なので良い投資だとは思っている。

たまに、今はwebで調べられる、無料だし情報の鮮度が違う、本で学ぶ必要はないみたいな主張を見かける。確かに正しい気がするし、であれば自分が本を購入する理由は何なんだろう?とモヤモヤしていたが、ふとした拍子にきっかけを思い出した。

スキル不足チームの炎上プロジェクト

すごく印象に残っているエピソードとして、何個か前に所属していた会社のとあるプロジェクトでの話。

そのチームは、社会人5年目で多少開発経験がある自分と、某コンサルSIer出身でギジュツナンモワカランけど自信たっぷりのPMと、なぜ面接通過したかわからないベテランエンジニアの３名だった。

当時の自分はまだ若くて、良いプロダクトコードを意識はしていたけど説得力があるほどのレベルではなく、かつプロジェクトで扱う技術にふれるのは初めてだった。他の二人はそもそも技術に興味が無くスキルもないのでより上位のエンジニアの意見に流されるだけで、プロジェクトは中々の炎上っぷりを見せた。

PMがあてにならんので自分も色々行動をするのだが、一向にすすめることができなかった。なぜ進められないかというと、合意形成をしようとした時に僕が他の二人を理解できるような説明ができず、理解できないので悪いものだと考えられ、結果現状の延長での活動しか認めないからだった。

ちなみに何か特殊なことを説明したわけではなく、自分が知っている世界線ではエンジニアにとって割と当たり前な話だと思っている。例えばコードに関することだとこんな感じ。

元コード

idx = 0 # 他ではindex。これだけ何故か省略
while true do 
  # 何か色々複雑な処理。頑なにメソッド分割しないのでめちゃくちゃ長い。ネストも深い
  idx = idx + 1 
  if index == 100 then # 100は適当に設定されたマジックナンバー。データが10くらいしかなさそう、という判断らしい。ちなみにindexとtypo
    break;
  end
end

提案内容

items.map do |item| 
  set_categoty(item)
  calc_price(item)
end

これが却下された。少なくとも既にバグっているので直したほうが良いはずだけど、賛成1反対2で多数決となり、Ctrl + zを連打された。mapが理解できないのと、関数に分離したことで見るファイルが増えて大変という理由だった。

他にも要件定義に関する話もしたが、それもコンサル出身のPMが言っていることが正しいはずだとバックグラウンドを理由にされ通らなかった。

自分の力だけで説得できると思わないことにした

おそらく当時は自分が一番まともな開発経験を積んでいて良い判断ができる、だから自分の意見を取り入れるべきだという意識で話していた。開発経験が一番重要な要素で、それが基準で会話していると思っていた。なのでなぜ拒否し続けるのか理解ができなかった。

今にしてみれば、相手は相手で年齢やそれまでの(開発と関係ない)経験が判断軸として重要な要素として信じていて、互いに合意の基準を合わせないまま戦っていたのであんな判断になっていたのだと思う。

あのときは判断基準をきめてから、それに則った理屈で説明すればよかったのかもしれない。判断基準は色々あると思うけど、あのチームメンバーの感じだとより上位の上司か一般的に認められている人の意見に合わせる、というのが良さそう。

そして、上司に根回しすると言うのはその手法に再現性を作りづらいけれど、一般的に認められている人 ≒ 提示できる正しい情報元とすれば、一度書籍で得られた知識はそのまま活かせそう、ということに気づいた。

あらためて、Web vs 書籍

例えば、プログラムを書いている、書き方がわからない、だから調べたいという場合、プログラムが書ければよいので、公式サイトを調べれば良い。これは正しさを判断する主体が自分であり、公式=正しいが自明なのでそれで大丈夫。

一方、先程の例のような人と議論する(できるようになる)ために何か知識を身に着けたいと思ったらちょっと様子が変わりそう。

議論するということは相手の人がいるわけで、その相手に自分の主張のベースとなる知識や意見を理解して貰う必要がある。でも現実問題、理解できない人もいるしそういう人がステークホルダーになっている場合は何かしら判断基準に則った情報を与えないといけない。その時に、〇〇という書籍に書かれている〇〇という意見を参考にしている、と言えるだけで割と説得力が出てくるような気がする。

逆にwebの情報だけだとどのページから調べたのかまで提示しないと情報の正しさを証明しづらいし、相手にもwebで調べたと言われると引き分けになってしまう。その点、技術書だとレビューとかで一般の人の評価もわかりやすいし、何より体系的に整理されているので説明が破綻しているようなこともほとんどなく、間違っている証明が難しい。

そういう理由で、人と関わるタイプの仕事だと書籍も読んでおいたほうが良いんじゃないかなと思っている。

本当にふと思いついて書いたので文章がところどころ変になっていそうだけど、大体の主張はこんな感じ。

※1 別に自分の意見を通したいのではないけれどダメそうな意見をゴリ押しされたときの自衛策みたいな感じ。間違った判断を回避できてさえいれば、プロダクト開発はそれなりに成功するものだと思っている

※2 コード修正の提案は、開発初期でリリースどころかほとんどの機能ができていない状態での話。なので修正範囲とかは気にするフェーズじゃなかった

※3 もちろん、正しい情報のみ選択してそれから知識を得ることもできるけど、そもそもインターネットはたくさんの情報の中に正しい情報もあるというものだと思っているのでフィルタリングや正しい情報の証明が大変。あと、細切れの情報だと論理の破綻に気づきにくかったりする