見出し画像

非エンジニアが「開発PJのリーダー」をやってみて①

入社4年目にさしかかる手前。非エンジニアなのに開発プロジェクトのリーダーを任されてしまった私が、プロジェクト進行を通して思ったことを書いていこうと思います。
プロジェクトの中心メンバーになったこと自体が初体験だったので「こういうこともあるんだな」と今後の教訓にできればと思います。私が!


1.タスクの認識合わせが難しい

今回のプロジェクトでは、社内エンジニアと社外エンジニアを繋いで、尚且つ非機能要件などを作成するという形で進行しました。
最初はスムーズに進んでいたのですが、途中から歪が出てきたのがこの部分。

社内エンジニアの認識と、社外エンジニアの認識のズレ。

社内外のエンジニア同士、そして社内のエンジニアと非エンジニア間の、スケジュールやタスク共有というか調整が難しかったです。

例えば社内エンジニアが工程A~Cにそれぞれタスクがあり、以下のような開始条件があるとします。

例1.タスク

工程Bは、工程Aが終わっていないと完了できません。
工程Cは、工程Bが終わっていないと絶対に取り組めません。

というわけで、一旦以下のスケジュールにしました。

例2.仮スケジュール

そして、エンジニアにスケジュールを見せて「この期間で各工程担当者が対応できるか」を確認しました。
結果、オッケー!
というわけで、確認内容に照らし合わせつつタスク内容を細分化したわけです。(ざっくりすぎますが、以下のような感じです)

例3.決定スケジュール

エンジニアそれぞれから合意を取ったので、完全に油断していたのですが、この時点で以下のようなことが起きていたのだと後から発覚しました。

例4.認識のズレ

スケジュール上は工程Aが3/25~3/31には終わり、工程Bは4/1から開始の想定です。
しかし、工程Aの担当者は「自分が工程Aの①~④を進めている間に、工程Bの①~③が進んでいるはず」と思っていたのです。
そのため、4/1までに工程Aが終わってなくとも、工程Bの④に取り掛かる5/6までに渡せば良いと判断していたそうです。

なんでだよ??

とは思いましたが、ベテランさんだったのでそういう判断になったのでしょう……たぶん。

そして、スケジュール上の4/1時点でこうなりました。

例5.悲劇の発覚
例6.上がPJスケジュール、下が工程A担当の認識

私が「工程Aが終わらないと工程Bが始まらないこと」あるいは「工程Aが終わるまでに進められそうなところは進めてほしいこと」のどちらかを伝えられるだけの知識があれば良かったのかもしれません。

スケジュールは遅れても大丈夫なようにバッファを確保!までは頭にあったのですが、エンジニアさん同士の認識相違までは頭が回りませんでした。そこはちょっと、反省点ですね。

2.共有情報のバランスが難しい

社外エンジニアには「そちらの状況が見えないから、情報はすべてくれ」と言われ、社内エンジニアからは「全ての情報は渡すな(社外秘扱いだ)」と言われ……。

社内エンジニアと社外エンジニアの間に入ると、専門用語がわからなかったり前提知識がなかったりで話が進みにくいので、直接やりとりをしてもらったのですが、

エンジニア同士で話が拗れると、全てこちらに持って来られる……!

わかっています。リーダーですもの。当たり前ですよね、わかっています。

しかし、こちらは非エンジニア。
どちらの主張が正しいのやら、手順が正しいのやら、全くもって分かりません。分かろうと思って話を聞きはするのですが、完全に素人判断になります。

プロジェクトの内容と人員が特殊だったのかもしれませんが、
これがまためちゃくちゃしんどい。

非エンジニアとしてプロジェクトリーダーをやってみての教訓は

エンジニア特有の言い回しに慣れる必要があること
エンジニアの縄張り意識(といって良いのか)を考えること
エンジニアごとの専門分野と担当領域を把握する必要があること

でした!
ご参考までに!

パート②はこちら!


いいなと思ったら応援しよう!

この記事が参加している募集