Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ！』
こんにちは、谷口です。
ディレクターやプロジェクトマネージャー、営業といった職種の方々は、企画やプロジェクトを進めるために、エンジニアとのコミュニケーションが必須です。そんな中で、エンジニアとのコミュニケーションに難しさやギャップを感じた経験がある方も多いのではないでしょうか。
実際、エンジニアには口下手な人やコミュニケーションが苦手な人もいます。加えて、不満やコミュニケーションエラーが積み重なったとき、彼らの大半は黙って辞めていきます。
辞めていく人たちは、いちいち「何が不満だったのか」なんて教えてくれません。しかし、非エンジニア職としては「どこが悪かったのかわからない」ままですから、また次のプロジェクトで同じパターンが繰り返される…といったことも起こりがちです。
paizaはエンジニア向けの転職サービスを運営していますが、応募者の方々にお話を聞いていると、そういった「ディレクターやプロジェクトマネージャー、営業などの方への不満」が非常に多く出てきます。
そこで今回は、ディレクターやプロジェクトマネージャー、営業などの非エンジニア職の方々へ向けて、エンジニアと仕事する時にやってはいけない・言ってはいけないことについてお話ししていきたいと思います。
■エンジニアを不幸にするディレクターやPM、営業に多い言動
◆「お客さんに言われたから」で急な機能追加
Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ！』
これは受託開発の場合、どうしようもないケースもあるかとは思います……が、こういう時にしわ寄せを受けるのは開発する側です。
エンジニアは黙りながら「いや客に言われたからってホイホイOKしないでよ！」と思っています。既に要件定義や設計・実装が進んでいれば、なおさらです。それなりの工程を経て固めてきたスケジュールや要件が覆ったり、やり直しや手戻りが発生してしまうのは、本当に最悪です。本来、要件や期間を決め終えた後で「やっぱりどうしても何かを追加したい」のであれば、そのぶん何かを捨てる必要があるはずです。
お客さんの思いつきで振り回された経験があるエンジニアは少なくありません。しかし、そもそもPMなどが契約内容を把握したうえでお客さんの要望を聞き、「今回の契約ではここまでです」「この機能は来期のプロジェクトに回しても大丈夫ですよね」といった調整をしていれば、現場が振り回されたり、急な変更・追加で疲弊してしまうのを防げたケースも多いはずです。（もちろん、それでもどうしようもない時もありますが…）
ですから、PMの方はお客さんがシステムを「どんな目的のもとにどうやって運用するのか」を把握する、契約内容を把握する、その上でお客さんの要望と要件を調整するといった仕事をきっちりこなす必要があります。「お客さん（や営業）に言われたからとにかくやるんだよ！」と言うだけでは、エンジニアからの信頼を失ってしまいます。PMはただの伝言係ではありません。
◆プロジェクトが炎上してきても何もしない
プロジェクトが炎上し始めたら、なるべく早く鎮火するために策を講じるのがPMの仕事ですよね。もっと言えば、小さな火種を見つけたら大きく炎上する前に防ぐのが重要な仕事です。（逆にプロジェクトがスケジュール通りに問題なく進んでいる状態であれば、マネジメントは特に必要ないはずです）
特に大手のSIerなどの場合、最低限の開発プロセスが決まっていて、それを守っていれば最後の方で急に大炎上！とはならないようなプロセスが完成しているはずです。しかし、上層部やお客さんに「スムーズに進んでいる」と見せかけるために、マズそうな部分を放置したり、うまくいっているように見せかけていると、そのプロセスが崩れてしまいます。
スケジュール通りに進んでいないのに、上には「問題ない」と言って見せかけるとか、上位管理職やお客さんに言われたことを全部OKして全部現場にやらせるとか、炎上し出したら人員を増やしてもらってあとは放置とかでは、繰り返しになりますがエンジニアからの信頼を完全に失ってしまいます。
◆「前はもっと早くできたじゃん」「他のチームはもっと早くできてるじゃん」
Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ！』
こういうことを言う人は、ほとんどが内部機能などについてきちんと理解できていないかと思います。
例えば工数を見積もる際は、前提条件や他の機能への影響など、調査や検討を重ねてから見積もる必要があります。しかし、仕様が固まり切っていない、調査する時間もない…といったケースでは、見積もりは多めに取らざるを得ません（そして現実にはこういうケースが多い…）。
実装が始まってからも、思ったより開発ペースが上がらなくて、「前はもっと早くできた」「他のチームはもっと早くできてる」と言いたくなる場合もあるかと思います。しかし、そもそも「条件が全て同じプロジェクト」など、この世に存在しません。
たとえ似たような機能を作っていたとしても、前のプロジェクトや隣のプロジェクトとは、ベースとなるシステムの仕様、影響の出る機能、開発環境、工程、進め方、メンバー構成、メンバーのスキルなどなど、さまざまな要素が異なっています。
技術知識のない人の場合、例えば「画面の入力項目を一つ追加するだけなんだから、簡単にすぐできるでしょ」みたいに考えがちです。しかしシステムの裏側では、入力項目一つに対しても、データベースや項目情報をもとに動作する機能などが紐づいているため、少しの追加・変更でも多くの機能に影響を及ぼす可能性があります。
それなのに「前はもっと早くできた」「他のチームはもっと早くできてる」などと言ってしまうと、エンジニアに「こんなに技術に理解がない人と一緒に働くのは嫌だ…」と思われても仕方ありません。
◆企画の目的、マストな部分、譲れる部分などが不明瞭なまま作らせる
技術やシステムについてわからないからといって、全てをエンジニア任せにして「いい感じに作っといてよ」というのも問題です。そんな感じで丸投げをする人に限って、後から「思ってたのと違う」とか言って大幅な手戻りを発生させ、エンジニアに勢いよく嫌われていきます。
まず、企画を進めるにあたっては「サービスの利用率を上げるため」「ユーザーの不便を解決するため」などの目的が必ずあります。もっと分解すると、それを踏まえた上で、「この機能は絶対必要」「この日までには絶対リリースしたい」「この部分はすぐにできそうならほしいけど、時間がかかりそうならなしでもいい」といった感じに、仕様とスケジュール感における優先度もありますよね。
エンジニアと企画を進めるなら、上記のような目的と優先度を早い段階から共有したほうがよいでしょう。ディレクターだけで完全に要件を固めようとしても、後から技術的な問題が見つかったりしますし、全面的にエンジニアに任せてしまうと、企画の目的や軸が行方不明になりがちです。
ディレクター側はビジネスニーズとしてマストな部分を明らかにしたうえで、エンジニアには技術的な部分や必要工数について検討してもらって、企画要件の落としどころを決めていく…というのがいいかと思います。
◆メンバー間の揉め事を解決しようとしない
エンジニア同士なら考え方も似ていて仲良く仕事するだろう、と思われるかもしれませんが、決してそんなことはありません。エンジニアも同じ人間ですから、どうしても相性の悪い組み合わせはあります。他にも、エンジニアとデザイナーなど、周辺領域の職種の人同士でもめてしまうケースもあります。
デザインとしてはこうしたいんだ、いや実装としてはああしたいんだ、といった感じで意見が割れだした場合は、落としどころを決めるのはディレクターです。ここでも、さきほどの「いかに企画の目的や軸を理解し、共有できているか」が問われます。それを踏まえて今回の企画ではデザインをどこまで重視するのかとか、実装的にはどこまで必要なのか…とかへ落とし込んでいく必要があります。
加えてディレクターの仕事で重要なのが、「揉めている本人同士で直接やり取りさせず、伝達が発生する場合は間に立つ」ことです。別に学校ではないので、当人たちに解決させる必要はありません。必要なのはみんながパフォーマンスを発揮しやすい環境です。
もちろんチーム編成の段階で、先に相性の悪そうな組み合わせがわかっているなら、避けたほうがいいでしょう。
◆開発と関係ない業務を大量に任せる
優秀なエンジニアほど、チームマネジメントやドキュメント作成など、開発と関係ない業務を任せたくなるかと思います。
しかし、エンジニアというのは基本的に開発がしたい人たちです。開発に集中できない環境に置き続けると、高確率で「辞めたい」と思われてしまいます。
特に遅れが発生している場合などは、無駄な会議を省く、メンバー間の進捗報告は、PM自身が個別に確認して個々の工数をなるべく浪費しないようにする、巻き取れそうな業務は巻き取る、といった感じで、開発に集中してもらったほうがよいでしょう。エンジニアに開発以外の仕事を任せ続けるよりは、プロジェクトもよほどスムーズに進むはずです。
◆懸念点や課題感などを聞かない
新しい企画や機能追加などに対し、エンジニアが「やらないほうがいいんじゃない？」と言い出したら、「やりたくないの？」「面倒くさいの？」と思ってしまうかもしれませんが、そうではありません。ほとんどの場合、その裏には「技術的に難易度が高いから時間がかかりすぎるのでは」とか「そもそも目的からズレているのでは」といった理由が隠れています。
これがベテランエンジニアであれば「こういう理由でやらないほうがいい」とはっきり説明してくれる場合もありますが、若手エンジニアだと「うまく説明できないけど懸念点がある…」という状態のときもあります（特にその要因が複数の場合）。実際に制作するエンジニアからの意見や懸念点は、しっかり聞いてみたほうがいいでしょう。
こんな時に、よく「明確な理由や代替案を出すこと」を要求する人がいます。が、代替案は必須ではないかと思います。何でもかんでも否定だけする人も問題ですが、代替案を必須にしてしまうと「思うところはあるけど代替案が思いつかない…」といった場合は、結局何も言えなくなってしまいます。そのほうがまずいのではないでしょうか。
「代替案もないのに否定的な意見を言うな」「流れを止めるな、文句を言うな」といった空気が醸成されてしまうと、チームとしてもよくありません。そういったプロジェクトは「このタスクちょっと遅れてるけど黙っとこ…」と隠し事の温床になってしまい、最後のほうになって結局それが発覚して大炎上…ということにもなりかねません。
逆に、不安や課題感を気兼ねせず言えるようにしておけば、誰かが「それはここでカバーできるから大丈夫ですよ」「それはこういう代替案がいいんじゃないかな」と、解決策を持っているかもしれません。最初に洗い出しておけば、対策を考えながら開発をすることもできます。
■まとめ
ディレクターやPMは、広くプロジェクトやチーム全体を見渡す必要がありますが、エンジニアの場合は「これをどうやって作るか」を集中して考えるのが必要なため、それぞれ仕事で見ているところが異なります。そのため、コミュニケーションにおいてもギャップが生じがちです。
ただ、プロジェクトの中ではどちらの仕事も密接に関連しているのですから、「企画や要件を決める人」「それをコーディングして作り上げる人」と分断されすぎていると、あまりうまくいかないかと思います。
エンジニアと非エンジニア職が、いい意味でお互いを巻き込み合える状態のほうが、プロジェクトもスムーズに進んでいくのではないでしょうか。
チームでのシステムの開発をスムーズに進めるためには、上記のようなことを少し気にかけられるといいでしょう。
ちょいちょい出てきた画像の漫画はこちら
paiza転職は、転職時のミスマッチをなくし、エンジニアがより技術面にフォーカスしたやりがいある仕事を探せる転職サービスです。プログラミングスキルチェック（コーディングのテスト）を受けて、スコアが一定基準を超えれば、書類選考なしで複数の会社へ応募ができます。
詳しくはこちら
まずはスキルチェックだけ、という使い方もできます。すぐには転職を考えていない方でも、自分のプログラミングスキルを客観的に知ることができますので、興味がある方はぜひ一度ご覧ください。
詳しくはこちら
