「後輩を指導する」みたいなことを基本的にあまりやらなくてよい立場にいる。誰かを指導する行為には副作用があり、それを被らずに済んでいる事実を appreciate している。

多くの人々が無意識に払っているであろう「教えることの対価」についてそのうち書こうと思っていたが、最近は逆側にある「教えないことの対価」に出くわしがちなので、まずそれについて書く。

隣の席の同僚の書く UI まわりのコードにやや不満がある。性能改善のために UI まわりもさわりたいのだが、変更に弱くバグりがちで困っている。これはもうちょっと MVC とか MVP とかなんか architectural pattern みたいのも考えてくれや Flux にしろとはいわねえからよ・・・という抽象度高めの不満と、それコピペしたり雑に分岐する前にもうちょっと考えて整理してくれや・・・という細部への不満がある。

抽象度高めの方は件の同僚以前に昔からそうなので、これは「なんとかしなかった」the lack of action に対する不満であり、期待値が高いだけと言える。細部のもうちょっとなんとかならんのか感はモバイル専業でやってきたおっさんとかにありがちな症状なのだが、その同僚は割と若い。年齢関係なかったねごめんね・・・。つまり勤務先でモバイルをやってるだけだとこういうコードになってしまう気の毒さ。

おっさんのコーディング傾向に口を挟むのは不可能だと前のチームで学んだ。しかし若者はまだ救えるかもしれない。フィードバックしてあげたい。しかしあまり良いフィードバックをできる気がしない。その同僚は、成果はだしている。本人はコード品質で struggle を感じている様子はない。だから下手に口を挟んでも余計なお世話。コードレビューとかで場当たり的になんか言うことはできるが、もうちょっとこう、あなたのコードはこういう傾向があるからこれ読んで勉強のうえ補正してちょ、きっといいことあるから、みたいな一歩さがったフィードバックを、本人が有用性を感じられる形でできないものか。

こういうの、たとえば自分が昔そうであったように、ランダムな新卒入社メンバーをメンターする、みたいな立場で組織から「新人教育」を期待され続けてきたなら、時間や労を割いて人に何か教える方法を考えるだろう。それを 10 年 20 年と続けていたら、バンとアドバイスの一つもできそうな気がする。そしてその先輩的アドバイスは組織と文化の力で割と聞き届けられがち。昔は先輩面してそういうことを考えていた時期がある。

しかしそういう身分を脱し 10 年ちかくヒラ暮らしをしているので、いざ誰かにアドバイスをしたいと思っても壁を感じる。他人のやり方に口を挟むことに強い抵抗があるし、その抵抗を乗り越えられる説得力ある言説を自分の中に積み上げられていない。

自分はオブジェクト指向なり関数型なりのデザインの本を一定程度読んでいるし、いわゆるプログラミング指南書もいくつか読んできた。ただ基本的には読んで感心して影響を受けて内面化して忘れる、というサイクルで消化しているため、他人のコードの傾向から適切な文献なり文献内の「ベストプラクティス」なりを論拠として引用はできない。

「引用できないなら身についたとはいえない/消化不良なのでは」という批判は、何割かは正しい。一方で他人を説得する必要がないなら、その場で納得して結論を受け入れコードの書き方を変えれば、それは内面化され身につく面もある。これは若干 cargo cult 的な危険を孕んでいる一方、少なくとも読んだ瞬間にはある程度批判的に評価しているはずで、その時点の前提が崩れない限り問題はない。そして問題があれば、それは体感できる・・・こともある。

こうした雑な学習はコストが低いので、かならずしも割は悪くない。人に教えられないのは雑さの対価といえる。逆に言えば、雑なまま前に進んでいけるのが人に教えずに済む強みである。

表題にもどると、人に教えないでいると仕事のプラクティスなどを説得力ある形で言語化できない、かもしれない。その機会が少ないから。結果としてチームメイトなどへの影響力が下がる、かもしれない。

しかしこの隣人のコードをなんとかしないと日々が厳しい。どういうオプションがありうるか。

• 適当にぐぐってでてきたアドバイスを鵜呑みにして伝える。職業倫理的に NG な感。
• いい機会だからと必要文献をばーっと買い集めて読み、整理してみる。これは興味深いプロジェクトな気がする一方「雑なまま進める」という自分の利点を損ねてしまう気もする。時間のない身に割が合うのか。
• 高位のフィードバックは諦め、必要に応じて適当に相手のコードをレビューしたり書き直したりしつつ付き合っていく。とりあえず書き直しても大丈夫な程度には関係性を維持できている、というか相手が不遜じゃないのが幸い。

なんとなく個人をピンポイントで先輩面するのは企業文化的にあわなそう。あと現状のコードのだめさはその同僚のせいだけでもないので、なんか言われると腹も立とう。もうちょっとこう、チームに対してなんかを提案する、プレゼンするのが筋に思える。そしてこれは主張の品質の bar を一層高くするなあ。しかし他人のやりかたに口を挟む以上、この高さは必要なものに思える。

最後のオプションすなわち現状維持で当面はいいとして。コード品質に関するアドバイスたちをレビューし、現時点での妥当解のスナップショットを研究するのは面白そうではある。しかし時間の無駄な気もする。なんかもうちょっといい切り口ないかな。うーむ・・・。