ismのないエンジニアに世界は残酷に出来ている

ism。イズムを知ったのはPMBOKのPMPの受験項目にismが含まれていると知ってそれなら試験勉強の範囲にしなくてはと思って読んだときが初めてだったので2002年頃のことです。

Code of Ethics & Professional Conduct - PMI

まだ若かった、とは言え30代前半でしたけれどもこれを読んでプロフェッショナルのあり方、仕事の念持の軸を据えられた、と言っても嘘ではないかと。

なので自分なりの仕事の品質の設定はこれが基準となっていて、もちろん、仕事後に決められてる品質があるならそれに準じるし、なくてプロジェクトのリーダとして作らなくてはならないのであれば、要求品質を充足し、過剰にならない＝説明に十分以上にはrソースを掛けないラインで作業プロセスをデザインするようにしているのです。

自分にそうした軸があるからかもしれないし、一緒に働いているエンジニアのそうしたイズムが見えないからかもしれませんが、それはないだろうと思えるような仕事のレベルを見るたびに、このエンジニアにはismはあるのかないか、疑念を持ってしまうことがしばしばなのです。

イズムはそれ自身、可視化出来ない対象であることを理解していれば、イズムを持っているかどうかを振る舞いから判断すること自体が馬鹿げていることは当たり前なのですが、作業品質が決められている中で評価軸をグラグラと揺さぶるよう発言をしたり、結果のバラツキが多いいとやエビデンスとして事実を積み重ねることでそう思ってしまうことは仕方がないかもしれないと思わざるを得ないのではないのかもしれない。

こうしたイズムがないエンジニアの仕事は例え推進力があっても結果が報われないことが多い。

軸となるイズムがないからステークホルダの発言が強力だったり、多種多様でそれを修練させようとしてもソフトランディングをさせようと思ってもそれを実現できることは難度が高すぎてそのエンジニアは持て余して途方に暮れるしかない。

（（イズム）作業品質）

イズムと作業品質をあえて図式化するならイズムは入れ子になっている核である。核であるから、外郭で行う行為に対して影響を与え続ける。では、核であるイズムは確固としていて変わらないものなのかと言えば、変えて良いのである。なぜなら、イズムそれ自体がエンジニアにとって様々な経験と知識から汎化し凝縮したものだからである。無からはなにも作れない。エンジニアは一つのものを分解すること複数のものを一つにすることとしか出来ないからである。

話を戻して、イズムを持たないエンジニアのアウトプットは品質特性のバラツキが大きすぎるためにあれこれ口を出さざるを得ないし、そう言ったことが多いエンジニアには重点的に管理をしようと力学が働くため管理サイドのターンが続き、その影響はそのエンジニアの評価に帰結してしまう。

残酷だとは思わないか。誰もそう言ったことを教えてくれない。口出しされるのはアウトプットでの評価をそのエンジニアにぶつけるだけだ。

さて、あなたにはイズムがあるか。あるならそれを教えて欲しい。ないなら、育てていこう。それがプロフェッショナルなのだと思っている。