エンジニアがチームの○○力を上げたいときに取るちょっとした工夫

チームに「○○力」が足らないことに気付いたとき
プロジェクトを担当のエンジニアとして参画するとき、そのプロジェクトを始める上で前提として必要な仕組み、技術、設計や技能が実際のチームで備わっていないことがあることに気付いたらどうすべきだろうか。
自分の立場が一担当としてのエンジニアのロールであっても、開発チームのゴールは顧客の要求する品質をdeliveryすることだから、チームに備わっていないことに気付いたら開発チーム全員でシェアしなくては、あとはデスマーチが待っているだけだ。予見される不幸をエンジニアとしては見過ごすことはできないし、何かすることでついでに自分の成長が得られるなら一夕二鳥だ。

一番大切なことを聴こう
自分がマネージャ若しくはプロジェクトマネージャであれば、開発チームにお願いすれば良いだけだ。ところが、一担当ならそう簡単には行かないから、やはりプロジェクトマネージャに予見されるチームに必要な前提条件を認識しているか、何らか対策をしているのか“できる限り早い時期”に確認しておく必要がある。直接、マネージャ若しくはプロジェクトマネージャに聴こう。

「このプロジェクトを成功させたいと思っている。だから開発チームで日頃から共有したいので『プロジェクトマネージャが一番大切だと思うこと』を一つ上げてほしい」

そこから得られる回答に、そのプロジェクトマネージャの価値観がわかるから、それを使う。

「その一番大切なものを脅かすと思われることに気付いたが、識別して対策しているか」、と。もし、識別も対策もしていなければ、その一番大切なことの対策案を具体的に話そう。仮に、何らか対策されていてもそれが有効であるとは限らないから、相手の対策を認めたうえで、それを補強するように自分の対策案を話そう。やんわりとしたゴリ押しは必要なことだ。

お膳立てをする
気付いてしまったら、そして開発チームに備わっていないことに自分が興味を持っているなら自分の成長も伸張させるチャンスと捕らえよう。面倒なことのほうが得られる経験が多いものだ。簡単なことの経験では経験値を上げられない。大変だったくらいが丁度良い。でもデスマーチは勘弁して欲しい。ならば、選択しよう。

開発チームであれば、何らかdeliverablesをアウトプットするわけだから、それを作る段取り、手順の中でその不足を補うプロセスを組み入れてしまえばよい。開発チームのコーディングの経験にバラツキがあるのであれば、“実質的な”ペアプロミングをプロセスに組み入れればよい。
開発チームが寄せ集めであればコミュニケーションに問題が出るだろうから、デイリースクラムを組み入れればよい。それも、“デイリースクラム”と呼ばず、単純に“朝会”でいい。ただし、中身はデイリースクラムの3つのポイント、昨日やったこと、今日やること、困っていることを共有できるような仕組みとしてしまえばよい。
また、設計力であれば、上流設計ならプロジェクト外の組織の中で人づてでレビューアに入ってもらえるようにネゴしてしまえばよい。