非エンジニアなのに開発プロジェクトのリーダーを任されてしまった私が、プロジェクト進行を通して思ったことを書いていこうの試みパート②です。
ご興味のある方は、パート①からぜひ！

「こういうところを気をつけないといけないんだな」という覚書みたいなものですが、よろしければお付き合いください。

１．用語の定義が必要

プロジェクトリーダーを初めてやってみて、つまづいたのがこの部分でした。

「何のことを言っているんだ？」が多発します。

非エンジニアとエンジニアはもちろん、エンジニア同士でも社内外で連携を取る場合にも発生します。しました……。

このとき、前者は「最初の方はテスト環境で開発を進め、Dの工程まで完了したら、本番環境に切り替えて開発を進め、全体を確認しよう」としています。影響が少ないからその方が効率的だ、という考えです。

対して、後者は「開発は全てテスト環境で行い、そちらで動作確認まで完了したあと、初めて本番環境に繋いで最終の確認をしよう」としています。開発は全てテスト環境で行うべき、という考えです。

この時点でエンジニア同士ですれ違いが起きています。
同じ会社内であれば統一されていたのかもしれませんが、別の会社であることからか、「開発用」「本番用」で示すモノが違っていました。

「この開発用・本番用ってこういう意味ですよね！？」と最初に聞かなかった私の落ち度かなという気持ちと、「いや、そんなの分からんもん」という気持ちがせめぎ合います。

プロジェクト自体の用語定義は最初に実施して資料化していたのですが、エンジニア側の用語まではあまり気にしていませんでした。
こちらも、最初から認識を揃えた方が良かったのでしょう……。

教訓：エンジニア同士だから理解し合っている、という思い込みは捨てましょう。細かいところまで用語定義に入れましょう。

２．報告の基準が必要

これも用語定義と似ている話なのかもしれませんが、
ひとことに「ホウレンソウ（報告・連絡・相談）」といってもどこに基準を置くのかは人によってバラけているのだと知りました。

私としては、「開始時、終了時、問題発生時、そして進捗も共有してくれ」という気持ちでした。

しかし、

• 「終わったら報告する」（問題が起きない限り途中経過は報告しない、終了のみ報告する）

• 「詰まったら報告する」（問題が発生しない限りは特に何も言わない、開始も終了も報告しない）

• 「始まったら報告する」（開始したよということを知らせてくる、途中経過は特にない）

• 「始まりと終わりを報告する」（途中経過は報告しないが、開始と終了は報告する）

• 「全てを報告する」（今から開始するぞ～今ここまで進んだぞ～終わったぞ、まで全て）

というパターンがありました。

私はプロジェクトリーダーなので、進捗を把握しないといけません。しかも、エンジニアのスケジュール上のタスクだけを見て判断することは難しいので、「今どうなってる？」を聞く必要があります。

社内エンジニアであれば、「頼むー、進捗報告してくれー」とお願いすれば割とオッケーでした。とはいえ、それでも抜けるときは抜けます。きちんと定期的な確認が必要です。

社外エンジニアに関しては、「何してるんだ……？」「ねえ、今どうなってるの……？」の状態が結構多くて困りました。
しれっとリスケされていたり、先週中に終わっているはずの作業報告が届かなかったり、金曜日までに確認が必要な提出物が金曜日の午前中に届いたり、15時までに送付すると言っていたはずが15時半になったり、などなど困ったポイントは挙げればキリがないレベル。

確かにエンジニアさんから見れば、非エンジニアへの進捗報告は面倒くさい難しいところがあるのかもしれません。
特に知識の乏しい相手に、こういうことをしています、という報告をする場合にはちょっとした説明も添えないと伝わらないこともあります。それは私も経験したことがあるので、分かります。

分かるけど言ってくれ……という気持ちは飲み込みつつ、

遅延する見込みが発覚した場合、実際にリスケになる場合など、プロジェクト全体のスケジュールに関わる作業の遅れや変更は報告してもらうことにしました。

工程Ａが3/1から3/5までに終わらないといけないとき、各タスクの遅れや進行具合まで報告してもらうことは負担だと考えたからです。

この場合だと、工程Aが3/5までに完了しないと判明した時点で報告してもらうという感じにしました。

そして、「この報告は〇〇のために必要だ」を説明することにしました。

スケジュール上ではバッファがあるので、リスケ自体は問題なく見えます。しかし、社内処理のために、報告のために、掲載準備のために、などさまざまな理由で知らない間にリスケされると困る場合もあります。

なので、「何のためにそれを知りたいのか」を言ってから、「この状況はいつまでに知りたい」「これが発生したらいつまでに報告してほしい」をお願いするようにしました。

ぶっちゃけると、毎回やるのはすごく面倒くさかった大変でした！

３．教訓

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

エンジニア同士だから理解し合っている、わけではない
エンジニア同士でも認識のずれは発生する
・・・だから、プロジェクトに関する用語定義は、細かいところまでカバーする必要がある！

報告の基準が人によってずれている場合もある
知識不足の相手に説明するためのコストは高い
・・・だから、報告してほしいことは何か、何のために知りたいのかを伝える必要がある！

でした！
ご参考までに！