チーム運営を気配りエンジニアの良心への依存から脱出するために

気配りというと曖昧なスキルでそれが本当にシステムエンジニアにとって必要なスキルかと言われれば、「あった方が好ましい」程度のものです。

ただ、チームで、複数のメンバと協働することを前提として、且つ、お互いの作業が密接に関連しあう役割分担の場合、気配りと言われるスキルがないとチームの中で気配りできるシステムエンジニアだけがストレスフルで疲弊してしまうんですね。これはプロジェクトマネージャの立場からすれば見過ごすことはできないわけです。

なぜなら、気配りするシステムエンジニアが抜けた途端、気配りという潤滑剤に無意識に寄生していた他のメンバとの間に気配りで埋めていた溝が突如現れるからです。

敢えて寄生と言葉を選んでいるのですが、他人の配慮からのリソースに対価を支払わずにtakeばかりしているのは寄生そのものですよね。

気配りを求めることをやめる

とはいえ、実体としては誰かしらがチームの中で良かれと思って気配りをしているのが日本のシステム開発の現場なのではないか、と思うのです。

でも、それを気配りの一言で丸めてしまうと気配りをしているメンバだけがチームの気配りという名のメンバとメンバの間の溝を埋める作業を担うことになってしまう。

プロジェクトマネージャとしては、相応にメンバがリソースを提供することで分担する方がチームの運営としては健全なんですよね。そうでないと、そこがSPOFになってしまうから。

まあ、そうなら「プロジェクトマネージャがやればいいじゃん」という見方もあるし、現実解としてはそれが落とし所なのかもしれませんが、それってお鉢を回しているだけなので根本解決になっていません。

だったら、その気配りをやめてしまうのがいいんです。はい。

先の行動を尋ねる

結果として、気配りとは先々の憂いを想定することで、他のメンバより先に手を回しておく、ということです。

ポイントは、「先々を憂いを想定して」です。気配りできる人とできない人はここが差なんじゃないかな、と仮説を立てます。

であれば、先々を憂いても憂いなくてもどっちでもいいけれど、想定してもらえればいいわけです。

それが実現できるように働きかけます。

・次に何をするかを報告させる
・次が完了したとき、何が起きるかを尋ねる
・何か起きた場合にどのように対応するかを尋ねる
・次が完了したときに、他に起きるケースは何かを尋ねる
・他に起きるケースが起きた場合にどのように対応するかを尋ねる

気配りができない人は３番目で躓きます。ええ、確実に。ただ、尋ねると答えてくれます。でも、４番目を尋ねると考えていないことがわかります。それを尋ね、さらに、起きた場合にとる行動を尋ねることで近い未来に進む世界線は一つではないことを示します。

エンジニアっぽく言えば、何かをしたら結果によってブランチするんだよ。そのあとどうするか、まで考えて今の行動をとっているかを聴くからね、とメッセージするのです。

まあ、メッセージするだけでは続かないのでプロセスに組み込んじゃいましょう。どうせやるんですから。