エンジニアならツールに拘るのではなくツールで実現できるか見極める力が必要なんでしょ


大分前に退職した元上司で矢鱈とゴルフクラブを買い替えるオジサンがいて周りから「道具じゃないでしょ。」って毎度のネタのように突っ込まれていたの思い出した。


ツールを使うのはそれを使わないと作りたいものを作れないとか、そのツールを使うと楽チンになるとかそういった効能があるからだよね。その目的の実現だけであれば、誰もが同じ目的を実現しようとするなら同じツールを選ぶと思うんだけど、例えばエディタのように、まぁ、その効能以外の官能的な好みの部分が作者も利用者も個別に持っているので、結果的に好みとして数多のツールから選り好みをするわけで。


ダメなエンジニアというか“仕事をした気になっている”って言った方が良いのかもしれないけれど、とにかくそういったツール推しをするエンジニアは理想論や机上の空論をこねくり回すだけで何もアウトプットを出さないから、みんなdisるんじゃないのかな。


例えば、システム開発方法論としてのウォーターフォールアジャイルスクラムやカンバンがあったとき、どちらかと言えばアジャイラーの方がその気があると感じている。特に去年まではそれ=ツール推しを強く感じた。


ウォーターフォールの悪い所ばかり立て並べ、滝の画像を写し、ウォーターフォールをdisる一つのパターンにすることが勉強会や祭りで盛り上がる手法のように。でも、今年から少し風向きが変わったような印象を受けた。去年までのようなdisり大会なんてすっかり忘れたようで、そんなことよりアジャイルスクラムやカンバンで結果を出そう、とそんな風に、兎に角、ワタシの目には映った。


やっと、アジャイルも本物になったんじゃないかな、と。


ツールの話なので、ウォーターフォールだってツールとしてメリット、デメリットがあるんですよ。それはアジャイルスクラムやカンバンだって同じこと。ツールにはそれぞれに良し悪しがあるんだってことです。だから、ツールは組み合わせて使うんですよ。システム開発方法論としてだって同じことです。


まして、マネージャやプロジェクトマネージャなら、そのポジションで大事に思っている単位、マネージャならプログラム(=複数のプロジェクト)、プロジェクトマネージャなら担当するプロジェクトで最適化を考えて、一番おいしい所だけを寄せ集めてゴールに駆け込みたいんですよ。関心事はそれだけ。だって、ビジネスだからね。


じゃあ、エンジニアは?ってことです。


顧客の要件をシステムという“しくみ”で実現するのがエンジニアなのだから、品質、コスト、納期より少しでも少なく早く届けられればいいわけで、言わばそれがエンジニアの目標なんでしかないんですよね。たったそれだけ。


ツールに対して「あーだ、こーだ。」と言っていいのは、顧客の要件を実現してくれるエンジニアだけ、です。文句をたれるエンジニアの官能的な好みには一切権限何てないんですよ。顧客の要件を実現できるかどうか、その一点のみだけでエンジニアは発言していいんです。どうしても好みを言いたいなら、一番最後、もし時間があったら、です。


そこにはエンジニアとして顧客の要件を実現できるかどうか、ゴールまでそこそこの確度で見通せる力が必要なんですよ。いま、あなたが、ワタシが言おうとしていることは、一個人の好みを顧客の要件とすり替えて言っていないか、その一点に立っているか、一歩下がって考え直した方が良い。いや、そう考えなさい。


エンジニアは顧客の要件をツールの助けを得て実現する専門家なんですから。