新しい手法を上手にインストールする人は手法の名前を敢えて言わない

エンジニアなら、仕事で試してみたい手法や言語やアプローチや環境など、いくらでもあると思う。自分の時間を使って、自分のバジェットでやる分には、誰にも口を挟まれることはない。手法や言語は、自分の時間で試してみる。所謂、ドッグフーディングをときどきやっていることだろう。

そういった手段にはだいたい名前がついている。

自分で食べてみて、いい感じだ、期待する効果を得られたと感触を得られたら、スケーリングしたくなる。自己研鑽であれば、自分の成長のステップになるから、そこで終わりでよく、次のステージ上がればいい。

それをやった動機が仕事にあった場合、例えば、チーム内での意思伝達がとか、開発スピードをあげないとリリースがとか、作ってみないとわからないのに仕様をかっちりと決めたがるとか、何かしら課題意識を持っているときには、現状を変えたいと思うのは異質なことではない。

そこで自分でドッグフーディングした手法を持ち込もうとする。唐突に○○やりませんか、的な。このアプローチは、バズワードに弱い経営者や役付がやる専売特許である。中身はよく知らないが○○がいいらしい。どこそこの知り合いがとか、日経hogehogeとかセミナーで調査会社がとか、まだソース元をバラしてくれるなら調べようもあるが、いきなり降ってくると逃げようがない。言い出しっぺは役付だから予算は持っている（といっても現有のリソースでやれと言うケースが多い）から、形だけやってよかったですなんて言おうものならそのまま本格展開しかねないので退路は確保しつつ魂が組織のバリューに合うかどうか真剣に見定めなければならない。

話を戻すと、エンジニアも同じようなことをする。○○がいい。自分でやっていると殊更良い面がクローズアップして見える。役付のバズワードをいきなり降ろしてくるよりは幾分かましであるが、それを受け止めるチームメンバが受ける唐突感は同じである。

であるから、何かいい感じの手法を導入したいときには、改善的なニュアンスで、その導入したい手法の魂を、あくまでも改善として取り込むことが吉である。別にその手法の名前をつけて導入しても、それを仕事でやりたいエンジニアにいくばくかの収入を手に入れられるわけではないだろう。

であれば、改善なりで実を得た方がその先々がよくなっているので、好ましい状態になる。

手法を上手に取りれている目先の利くエンジニアの方は、そんなことをやられている。目的が課題解決や現状の改善であることをよく理解しているし、第一、やってみたらうまくいかないことだって十二分にある。それは手法が合わないのかもしれないし、チームにはまだ早すぎたのかもしれないからだ。

ここで失敗をすると、次に本当に必要になったとき、失敗した、合わない手法としてラベリングされているので土台にも上がれなくなってしまう。

それは将来のチームの選択肢を自ら失うことである。

それは避けよう。

手法の名前なんて上手くいってから、言えばいい。