エンジニアとして開発手法やツールを変えたいと不満を言うより確実に変えるために

エンジニアが所属する組織の中で、特にプロジェクトの開発手法、ツールなどにおいて、あれこれと思うところを場面場面で意見だったり愚痴だったりを言っている光景を見かけることがあるのですが、そうした行為、つまり、意見や愚痴がどれだけ実現に向けて進むかと言えば、ほとんど実現しないのではないか、と思うのです。特に、愚痴の類は。

担当エンジニアができること

担当エンジニアができることは自分の裁量の中で、です。

チームのプロセスや手法を変えるためには、影響と、リスクと、見通しの裏付けが現状取られているコストに対して優位性が必要です。

不満に思っていることが、現状を変えるコストを投下し、且つ、リスクをテイクしてまでチームを動かす判断に至るかどうか、と考えることです。

チームのプロセスや手法を変えるために、自分の裁量の中で実績を作り、それを口コミで広めフォロワーを増やすことでチームのデファクトにしてしまうというアプローチもあります。

リーダエンジニアができること

リーダになると何らかのロールを一任されるので裁量の範囲が広く重くなります。ロールを一任されるということは、プロジェクトマネージャの権限を一部ですが権限移譲されてるということですから、担当する領域に限り、プロジェクトマネージャと握れれば好きにできます。

担当エンジニアとリーダエンジニアの違いはロールの範囲、つまり、負う責任に伴う権限の有無です。

プロジェクトマネージャができること

プロジェクトマネージャになるとそのプロジェクト全般の推進に係る範囲において責務と引き換えに権限を持つことになります。

プロジェクト内についてはヒラエルキーの頂点に立つ（現実は、開発責任者やプロジェクトオーナーがいるので中間管理職ですが）のでプロジェクトに向かう場合は最高権限を持っていることになります。

持論から言えば、チームの存在意義はプロジェクトの目的を達成するために存在するのであり、プロジェクトの開発手法やツールはプロジェクト最適化で選択されなければなりません。

ただ、負う責任の範囲において、裁量を持っているのでプロジェクトに対してプロジェクトマネージャの嗜好やプロジェクト内でのLabを試すことができます。

マネージャができること

マネージャができること。組織の中で担当するビジネスをキャリーする立場です。担当するビジネスに対して結果を出すことが大前提なので、結果に到達するオペレーションであればどのような開発手法もツールもプロジェクトチームに対して影響力を行使することができます。

ここまでロールで分けてそのロールの立場から開発プロセス、開発手法、若しくは、ツールにおいて変えたいとか改善したいと思うとき、愚痴をいうことがどれだけ無駄かがはっきりしたのではないか、と思うのです。

エンジニアにおいても組織のメンバである以上、組織を巻き込んでまで負う責任とひもづく（はずの）権限がなければ変えることはできません。

現行の開発プロセス、開発手法又はツールを変えることによる効果の実績がなければ。

逆に言えば、権限を持ち合わせれば、その権限に応じて変えていくことができます。

つまり、組織の中で自分自身を超えた範疇まで影響を及ぼすようなシステム開発をしたければ、影響を及ぼしたいポジションにつくことが必須なのです。

影響力の武器[第三版]: なぜ、人は動かされるのか