orangeitems’s diary

クラウドで働くインフラエンジニアの日々の感想です(ほぼ毎日更新)。

揉めるなら、始まる前に

f:id:orangeitems:20210308175649j:plain

 

プロジェクトでも何でも、ふわっと始めて、だんだん煮詰まっていって、最後に大炎上みたいなパターンは体験したときがあります。プロジェクト終盤になっていずれ問題になるだろうということが放置されていた結果、とか、運用開始してやっぱり問題が起こって誰が対応するか決まっていなかったり、とか。

まあ、揉めるというのは、二者間での責任の押し付けというのが率直な表現ではありますが、この二者は揉めるべくして揉めるのです。でも揉めたくないからって、先延ばしにしていった結果、ごまかしもきかなくなってその割には残された時間もなくて、争いながら火に包まれながら、対処していかなければいけないので、痛い思いをすることもしばしば。

冷静に考えれば、揉めるのなら、燃えるものがない序盤にできるだけ揉める要素を見える化して、想像のなかで意見を戦わせ、そこで両者の身を焼き尽くすような「いさかい」になるのならば、もうそのプロジェクト、絶対にやらない方が良いです。やらなければ延焼する要素もないのです。二度とこの二者は一緒にプロジェクトに入ることはないと思いますがそれは周りも察するでしょう。

もし、なあなあにしてプロジェクトが中盤以降、もしくはサービスインして保守フェーズに入った後になって炎上するのが一番怖いのが延焼です。一つの火種が他の要素にもどんどん問題を引き起こし、どんどんスケジュールが無くなっていったり、品質へ影響してしまう。関係悪化は二者の配下のスタッフにもモチベーションの低下をもたらしますし、問題発生部分の放置がボトルネックのすべてになってきます。

だから、揉めるなら、全てが始まる前の方がいいです。むしろ、始まる前に燃えるものを全部燃やしてしまうぐらいの覚悟でプロジェクトに臨み、あとはやるだけ、という状態なのが私は理想に思います。もちろん、初めから最後まで燃えない、実績の塊のようなプロジェクトもたくさんあり、できるならばそういったプロジェクトだけやっていたいのですが、ビジネスの世界だとそうはいきません。ぜひ会社としてはやっておきたい、そんなプロジェクトのエンジンとして指名されてしまったときに、「いや、燃えるやつは嫌なので・・」なんて言ってたら、将来のチャンスを捨てるのと同じです。

始まりの段階で「あれかもしれない」「これかもしれない」って言いだす人は、多分やりにくいなという印象を先に相手に与えるのかもしれないけれど、でも初めに洗うと後の工程ですんなりいく前提を作れるんですよね。言質を早い段階で取っておく。そうするともう勝負は決まっている。始めに揉めた後、スムーズに後段が仕事が流れると、初めの印象よりもだんだん「ああ、いろいろ心配して言ってくれてたんだ」とだんだん関係はプロジェクトの進行に伴って良化してくるので、実は良い事ばかりだと思っています。ダメになるのなら初めにダメになったほうが、実害もありませんから。

この原則、まとめてみると当たり前のように見えるのですが、実際はスタート地点でぶつぶつ言うのって「空気読め」みたいになりがちなので、意識してやった方がいいことです。いや空気読んで、終着点が大炎上とかのほうが嫌よ。辿りつく場所は良き場所でありたい。そのためにも問題は全部俎上に出して、全部解決しないならリスクあるよ、いいの?いいの?。始まりに揉めることは良いことのように思います。