はじめに
前回に続き、ソフトウェアファーストの第2版を読んで思ったことを書き連ねていきます。
第6章は「各人材に求められる変革」です。
プロダクト志向
理想のプロダクトとは何か、誰の何の問題を解決したいのか。
HPなどで、モヤっとした内容だけ書かれていることがよくあります。
ビルドトラップに陥らないためにも、こういったことについて、定期的に話をする場があると良さそうです。
成果で評価
「組織のルールを変える」の中で、厳格な勤怠管理に依存する人材評価より、仕事の成果で評価しましょう。との趣旨がありました。
基本的には賛成なのですが、ソフトウェア開発は一人一人が異なる役割、異なる量・難易度のタスクを受け持っているため、成果での評価というのは、かなり難しいのではないかと思います。
難易度の高い仕事をしているから評価が上がるのであれば、誰も単純作業をやりたがらなくなります。
ミスが多いと評価が下がるのであれば、簡単な仕事ばかり取り組んだほうが得をすることになってしまいます。
テレアポのアウトバウンドのように、全員が同じ条件で、同じ性質の仕事をしていて、結果（成約件数）の差が明確に表れるものは、成果主義で問題ないでしょう。
なので、個人的には、勤怠や勤続（経験）年数での評価というのは、ある程度は納得感のあるものかなと思います。
同意しないがコミットする
結構大事な考えですね。プロジェクトを進めていると、自分と合わない考えで物事が進められることはどうしても出てしまいますが、ある程度は許容していかないと、全く進まなくなってしまいます。
昨今は、ダイバーシティ（多様性）を持った組織をつくろうとの風潮がありますが、全員が完全に同意するというのは、より難しくなってきますね。
W型人材とπ型人材
T型人材に、専門性をさらに一つ加えて、π型人材と呼ぶというのは広く知られている用語ですが、W型人材という言葉は初めて聞きました。
π型との違いがよくわからなかったのですが、π型は、ITという範囲の中で、複数の専門性を持ち、W型はITとそれ以外の専門性を持つという事でしょうかね。
変革
という言葉が随所に登場しますが、本当にそれが必要かどうかについて、よく考えたいものです。
勉強熱心な技術者は、よく新しいバズワード（マイクロサービスや、XX駆動開発など）を試したがるものです。
「変革」という旗印を掲げて、強引に導入したものの、うまく機能しないこともあります。
うまく機能しない理由は、マイクロサービスや、XX駆動開発そのものが間違っているわけでなく、その現場のやり方では合わなかったかなと思います。
なので、状況に応じて、押すと引くをうまく使い分ける必要がありますね。