エンジニアの情熱と暴走モード | A Day In The Boy's Life

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

若いエンジニアに仕事を頼むと、時にやりすぎなところがあったりして悩むときがあったりします。

それはあらぬ方向に突っ走られるというよりは、頼んだ以上のことを実装したりするといったシーンです。

それって別にいいことなんじゃないの?って思われるときもあるのですが、プロジェクトを管理しているとそこに時間を割くのではなく他に手を回したい、でも作ったものはそれはそれで素敵な機能なんで叱るに叱れないといった状況に悩んだりするわけです。



うまく暴走させてあげるのに大事なレール


特に経験の浅いエンジニアは作る楽しさを覚えて間もなかったりもしますから、予想以上に工数かかっているなって確認してみると想像で突っ走ったりしてとんでもないものを作ろうとしていることはしばしばあります。

ちゃんと仕様を伝えていないこちらも悪いところがあるのですが、あまり細かく管理していくのもエンジニア自身の成長の妨げになりますし、自分もそうやって自由に作ることでスキルを磨いてこれたりしたものですから、自分の言うものだけを作れというのはあまりよくないなと考えていたりします。


視点が狭いというかどうしても技術よりな観点になってしまうのもうなずけるのですが、何を作るのかというよりはどう実装するかという観点に考えがよりがちです。

ドアを作ってくれと頼むと自動ドアを作ろうとしていたりするのですが、こっちとしてはそもそも人を通すための出入り口があればよいわけで最悪不恰好な穴でもあけてくれればいいわけですが、職人気質が働くのか立派なドアを一生懸命に作ろうとするわけです。

何でここにドアを作らないといけないのかという視点ではなく、とにかくドアを作らないといけない、どうやってどんなドアを作ろうかということに偏向してしまっているのをよく見かけたりします。

こういったことは自分自身にも当然経験があるわけで、視点を広げるというのはある程度の経験を経てじゃないとなかなか難しいことではありますから、上がきちんと間違った方向に進んでいないかコントロールしてあげる必要はあるなと感じています。


もう一つありがちなのが、与えた仕事から飛びついてしまうという点です。

今、しかかり中のものがあるにもかかわらず「Aくん、この件ちょっと相談したいんだけどクライアントからの要望でこういう機能を作ってくれない?」というと、言われたことだからすぐにやらないといけないというバイアスが働くのか、優先度の付け方がうまくできずにLIFO形式にタスクをこなしてしまったりします。

ですので、こういった事にならないようにあえて情報を渡さないというような管理も必要になってきたりします。

そんなに優先度の高くない仕事であれば、たとえ内容がまとまっていても本人に伝えずに温存しておくというか。

優先度の管理というものを引き取ってしまった方が本人的にも目の前のことに集中できますし、こちらとしても複数のタスクを同時並行的に見る必要も無いのでスケジュールの進捗が見えやすかったりします。


ただ、先に書いたようにこと細かい管理というのはエンジニア自身のモチベーションを下げることにもなりますし、こちらもそんな細かく管理するだけの余力もありません。

きちんとゴール設定をしてあげ、マイルストンごとに成果物を確認していくようにしてベクトルが違う方向にむき出したら都度修正していくというような形で踏み外さないレールを敷いておくというのは必要かなと思うわけです。



暴走の果ての成果を無駄にしない


エンジニアの情熱というのは、そのシステムを組み上げる原動力の1つです。

ですから、例え突っ走ってしまって自分の想像の斜め上をいくものができたとしても頭ごなしに否定して叱るというのはよくないと思います。

むしろ、その成果物をどう使うかという方が本人のモチベーションを下げないですし、自動ドアができたらできたで使い道は全然あるわけです。


もし、通常は使わないような機能が実装されてしまったとしても、オプションとして扱ってしまえば便利機能の一つということで片付けられたりもしますから成果を無駄にせずにうまく活かす方法を探した方が賢明です。

そういった成果は独りよがりで作ってしまったものだったりもしますので、機能の目的として論点がずれてたりするものが多かったりもするのですが、要らないと捨てるよりもいっそのこと、その機能をより拡張していく方向に進めてしまえば結果的に正しい方向に突っ走ったことにしてしまうこともできます。


こういったエンジニアの暴走を目の当たりにしてしまうと「何でそんなことに時間を割いているんだ」という気分にもなってしまうこともあるのですが、よくよく考えてみると管理する立場の人がその人の能力であったり、プロジェクトのスケジュールやタスクの優先度を鑑みて設定した仕様であり、その仕様を超えるような成果であれば怒る理由もありません。

意外とそこまでの機能は要らないと思っているのは自分だけであったりして、クライアントに見せると喜ばれたりもします。

まぁ、元々単なるドアを作る想定で工数を積んでいたものが、その期間で自動ドアができたんなら万々歳って気分になるのはわかるんですが、管理する立場としてその暴走を見て気が気じゃないのは単に自分の決めた枠にはまらず行動しているというエゴなのかもしれません。


コミュニケーションミスで全く逆方向のものを作り上げられたらそれは大問題だったりもしますが、とりあえず前に進んでいるのであれば、こういったエンジニアの情熱をうまく活かして正しい暴走をさせてあげるのが重要なんだなと思います。

暴走するほどの情熱を削ぐのは管理者として正しくないでしょうし、そのパワーって他に変えがたく与えようとしてもなかなか与えられないわけですから、右往左往しながらも前へ前へ推し進めていくマネジメントが必要なんだなと感じています。