5000164 is here
2014-03-26

変えられないエンジニア

「君は変えられるエンジニアか?変えられないエンジニアか?」

下記リンクから引用

PHPerのためのJenkins | アライドアーキテクツ エンジニアブログ

私は変えられないエンジニアだった。
そして逃げ出してしまった。
逃げ出した判断は間違っていなかったと今でも思う。
ただ、何も変えられなかったことを後悔している。
今でも、中途半端に干渉しては無力感を感じている。

私はなぜ変えられないエンジニアだったのか

原因がわからなければ対策もできない。
全員が必ず変えられるエンジニアになる必要はないが、私は変えられるエンジニアになりたい。
そのために変えられなかった原因を考える。

自分では「良い」と思ってるこの「良さ」を共有できていない

改善はなぜ存在するのか。
そこに問題があるからである。
問題からストレスが生まれ、このストレスを消すために改善する。
この「ストレスを消す」ことが良さである。
しかし、ストレスが共有できなかった。
ストレスが共有できなければ、消すもなにもない。
はじめから存在しないのだ。
改善するためには、ストレスを共有しなければならない。
ストレスを共有するためには、より良い状態を提示するしかない。

結果が出ていないのに周りを巻き込んだ

より良い状態を提示できないまま、周りに改善を強要した。
ストレスを感じていない状態では、解消するストレスも存在しないので理解してもらえない。
当然の結果である。
人は損得勘定で動く。
私はストレスを消せるなら得すると思って動いた。
存在しないストレスを解消するのは、コストだけかかりメリットがない。
損すると思ったら誰も動かない。

問題の共有ができなかった

この1点につきる。
ここをもっと突き詰められていれば、結果はもう少し変わっていたかも知れない。

改善を共有するのではなく、問題を共有すれば、自ずと改善に向かう

自分の中で「悪い」と感じていることが、他人の中では「悪くない」ということは往々にして起こりうる。
その時に大事なことは、自分の悪いを改善するための行動を共有するのではなく、悪いを共有するのである。
悪いが共有できたら、あとは一緒に改善していける。

問題を共有して改善するために、まずは改善結果を出す

では問題を共有するためにはどうすればいいのか。

最も説得力があるものは、改善結果を提示することである。

まずは自分が改善する。

そして結果を作る。

結果からどこが悪くて、改善するとどうなるのか示す。

早まってはいけない。

共有するのは結果を出したあとだ。

結果を出したら隣の人から巻き込む

まずは隣の人から巻き込もう。
隣の人とも共有できない問題であるならば、全員と共有できるはずがない。
とにかく1番近くの人に話してみよう。
人目をはばかるなら直接ではなくてもいい。
大事なことは問題を理解してもらうことである。

近くの人から幸せにする

考えだした改善策は、実行した人を幸せにするものか?
その幸せを共有したいと思えるか?
幸せを共有したいなら近くの人からだ。
隣の人を幸せにできたなら、次は反対隣の人だ。
次は正面の人。
急いてはいけない。

変えられるエンジニアに意味はあるのか?

環境を移せばいいだけではないのか?
たしかにそれもある。
だが、誰かを幸せにできるならそこに意味はある。