「なぜ」を知るエンジニアと知ることができないエンジニア

エンジニアにも「なぜ」を知ることができるエンジニアと「なぜ」を知ることができないエンジニアがいるのです。

以前、アーキテクトと雑談をしているときにこんな話をしてくれました。

「あるプロジェクトが相談したいと言ってきたから話を聞きに行ってきたんですよ。リリースを早くするにはどうしたらいいかということだったんですけど」
「リリースねぇ」
「今ならアジャイルとかテスト自動化とか色々手段があるじゃないですか。だから、そうした手段を使えばリリースを早くする方法は取れますよ、って情報提供をしたのですけど」
「けど」
「どうもツールを導入すればリリースを早くできると早ガッテンしてしまったみたいで」
「そんなバカが今時いるなんて信じられないけどね。ほんとなの」
「実話です。じ・つ・わ」
「ご苦労なことでしたね」

まだまだ続きます。

「まだあるんですよ。ツールだっていろいろあるのでどうしてリリースを早くする必要があるか参考までに教えて欲しいって説明をお願いしたんですよ」
「まあね。ビジネスニーズなのか開発プロセスの課題なのかでどこまでやればいいとか、運用をどう変えないといけないとか考えないといけないからね」
「そうなんです。それです。要求を実現するための道具なんですから、使う目的がはっきりしないと導入した後の効果も測定できないですし」 

 誰の「なぜ」は「何」か

「なぜ」それをしなければならないか。

なぜには誰かの要件があるものです。誰かが実現したいという要件を持っているから、それを実現してくれる、実現する役割を持っている人に要求するのです。その要求は顧客かもしれないし、自らの要求かもしれない。いづれにしても、誰かが実現したいことがそれを実装できる役割に伝わってくるのです。

要求を受けた人は、なぜを知る必要があります。知らなければ実現したい要件を現実にすることはできないのですから。

「なぜ」の当事者になれるか

話はさらに続いたのでした。

「でですね、わかっていると思いますけどとわざと前置きしてこう言ったんですよ」
「ふーん」
「なんかあまり興味がないようですね」
「だって学びがなさそうだもん」
「もうちょっと付き合ってください」
「いいけど」
「わかっていると思いますけど、ツールですから運用に耐えられるように設定しなければならないし、ツールに合わせて運用も変えなければなりません」
「そりゃそうだ」
「でしょう。それでそれはプロジェクトで考えて、やらないといけませんよっって」
「普通だよね。それ以上でもそれ以下でもない」
「そうしたら、『え、そうなの。そんなんじゃウチでは使えない』ですって」
「それで」
「説明が済んだので退席しました」

「なぜ」を知ったら、次はそれを実現しなければならないのです。それがあなたの役割なのであれば。

要件が増えればそれを実現する手立てが必要になりますし、場合によっては現状のプロセスを捨てて新たに設計してチームにインストールしなければならないかもしれないのです。

それでも、実現しなければならない要件があるなら、実現する役割を負わなければなりません。役割を負うということは当事者になるということです。実現するために必要なことは全てに関わらなければならないのです。

見方を変えれば、「なぜ」を知ることができるエンジニアは当事者であろうとするし、「なぜ」を知ることができないエンジニアは他人事なのです。だから、要件を実現するためにプロアクティブに動けないのです。