事例ばかりを知りたがるエンジニアは目的を達成することはできない

技術部門のお兄ちゃんのエンジニアと会話していたときのこと。

「ときどき、開発部の方からタスクをexcelとかMS Project以外で管理するツールを紹介して欲しいと訊かれるんですヨ。」
「ふう〜ん。」
「で、使ってもらっているtracを紹介するんです。」
「それで?」
「ひととおり紹介すると必ず決まって出てくるフレーズがあるんです。」
「どんなこと?」
「『いいツールだと思うけれど、“うちの開発プロジェクトでは”使えない。』って。」
「なんで?」
「タスクの状態が違うって。」
「はっ?」
「デフォルトのチケットの項目のラベルの名称とか選択する状態とか違うって。」
「なんだって?」
「『svnディレクトリのテンプレがないから。』だって。」
「そんな人の相手しなくていいよ。」


そのお兄ちゃんはロール上、相手をしないといけないのでワタシが言い放ったようにはできないんですけど、それでも同じエンジニアとして

“ツールが自分達にフィットしていないから使えない”


なんて真顔で答える人の顔を見てみたい。いや、そんな人の顔を見る価値なんてないか。
しかし、エンジニアに限らないことだけどエンジニアの話が中心なのでそれにフォーカスするけれど、ツールに何を求めているんだろう。ツールから見ず知らずの自分達のやり方や文化に寄り添ってくれると思っているのだろうか。


未体験のことへの不安はその先駆者に訊く
知らないコト、それは未体験なことです。だから、知っている人に訊く、と言う行為は自然だし、理に適っていると思うんだ。すべてのことを自分自身で体験するには私たちエンジニアには時間が限られている。その観点から言えば、

“未体験のことへの不安はその先駆者に訊く”


という行為は妥当だと思う。書籍があれば書籍に、適当な書籍が見つからないなら先駆者に尋ねる。それはどのようなもので美味しいのか、と。


では、どうして人は尋ねるのだろう。ツールの話をベースにするなら、

  • そのツールは彼らのシステム開発のプロジェクトで
  • 関心を持つタスク管理において
  • 少しでも効果的な仕組みで
  • タスクをコントロールしたい


ではないだろうか。そう想像する。なぜそのように想像するのかと言えば、ワタシがtracを入れようと探したとき、従来と違うやり方で“タスクコントロールをしたい”と思ったから。今までと同じやり方ではそれを徹底するだけであれば確かにタスクをコントロールできたかもしれないけれど、その目的を実現できる可能性は少ないと思ったから。


では、彼らも同じようにタスクをコントロールしたいと思っていたと彼らの目的を導いでよいのではないかな。そう思うんですけど、なら、なんでそんな=彼らのスタイルと違うなどと表面上の違いだけでリジェクトするんだろう。


彼らに欠けているものが一つあると思うんだ。それは、目的を達成するためには、“しくみ”も変える必要があるのだということなんだ。本当に目的を達成したいとき、今のしくみの中で結果が出ていないなら、しくみから変えないと何一つ変わらない。そう思うよ。そう考えると、彼らには目的を達成しようなんて本心から願っているわけじゃないとしかワタシには見えない。


彼らは自らがやらなければならないことをツールが実現してくれると思っているのではないか、そんなことに思い当たってしまったんだけど強ち間違っていないかもしれないなぁ、と。自分達の困っていることは“自分の組織外の”だったり、“余所から持ってきたツール”が解決してくれるのだと。


ねぇ、どんだけITリテラシのない人達なんだい?ソフトウェアは何をしたいか、業務を実装しないと期待する結果を出さないものだよ。スクラッチなりエンタープライズミドルウェアなら業務ロジックは顧客に訊いて実装するんだもの。出来合いのパッケージはその業務ロジックを自ら組み込むか、業務ロジックを自分の操作でやる他実現する手立てはないんだよ。


誰も彼らの真の目的は解決してくれないんだ。彼らが真の目的に気付いているならこんな言い方はしなかっただろう、と思うんだ。


貴方は、事例を知りたいと思うか、それとも概念を知りたいと思うか、選択せよ
どちらですか。

  1. 事例を知りたいと思う
  2. それより概念やしくみを知りたい


ワタシも以前は事例の方を沢山知りたい時期がありました。以前までなら。でも、今は、しくみ、概念の方を知りたいんです。何故かって?


それはワタシの問題はワタシがそのしくみを適用して解決できるか判断をしたいから。事例は参考になる情報が少し含まれていると思うんです。工夫したかった背景、苦労した理由とか。概念やしくみは原理だけだから、汎化されているのでそれを実際に使った人がどう変えて使ったかは、自分が自分の解釈をして、自分のしくみとして実装して行き詰ったとき、ブレークスルーする試行錯誤のきっかけになる可能性があるんだと思うんですね。


でもそれだけ。その人のやってきたことはワタシには適用できない。なぜなら、そのツールを導入する目的が違うから。そのツールを運用するエンジニアが違うから。


だから、事例そのものより、概念やしくみを知る方への関心度合いが強いんです。事例も面白いには面白んですけどネ。


事例を欲しがる人は、結果的に自分でしなければならない、自分の目的を達成することへの過程の意思決定を他人がしてきた結果を持ってきて自らの判断する行為をすり替えているのではないか、なんて思うんですが言い過ぎかな。


でも、そうでなければ、概念やしくみを知ることが出来れば、あとは自分で自分の目的に合わせてカスタマイズして運用しようと思うでしょうに。そう思うから、他人の焦れは他人の事情と意思決定であって、自分の目標達成にはまったく貢献しないんだと知っていると思うんだけれど。