Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ！』
高橋です。paizaのクリエイティブディレクターです。
ディレクションやマネジメントなどの仕事をしていると、企画やプロジェクトを進めるのにエンジニアとのコミュニケーションが必ず発生します。
実際にそういった仕事をされていて、コミュニケーションの難しさやギャップを感じた経験がある方も多いのではないでしょうか。
今回は、そんな「エンジニアの考えていることがわからない」「コミュニケーションがうまくいかない」といった方に向けて、私がディレクター業務をする中で体験した、エンジニアとのギャップが生じがちなポイントや、それを解決するためにできること、気をつけたいことなどについて書きます。
【目次】
お前誰やねん
paizaのフロント周りの施策、たとえばLP制作やUI改善などのディレクション業務をしています。
キャリアとしては、漫画家を目指す → 挫折する → グラフィックデザイナー → Web系受託開発企業のディレクター → paizaのディレクターになって一年半弱です。
Webデザインハチョットデキル、プログラミングはpaizaに入社して初めてちゃんと勉強し始めた感じです。
エンジニア⇄ディレクター間のギャップあるある
「簡単にできるよね」問題と情報共有の不足
ちょっとした機能追加やレイアウト修正に見える業務でも、エンジニア的には別の内部機能への影響や連携など、いろいろな条件を調査・考慮しないといけないケースが多くあります。だから、開発せぬ者が簡単と決めつけて依頼してしまうのは絶対にダメです。
あと、何か依頼が発生した背景には「この数値を上げたいからこんな企画を実施したくて、だからこんな機能を追加したい」みたいな、前提条件や情報がありますよね。この共有が省略されがちだと思うんですけど、前提の情報や目的の共有ができていないと、エンジニア側も正しい判断ができないし、「正しい判断ができない＝やるべきではない」となりがちです。
もしくは、依頼する側が強くて「エンジニアは何も考えず依頼されたものを作ってくれればいい」となってしまうのもよくないですよね。社内受託がしたいわけではないので…。
逆にエンジニアの意見を通しすぎちゃう
かといって、エンジニアの意見がいつだって最優先にされる、エンジニアだけが強い組織になってしまうのもよくありません。
そもそも、企画の発端にはビジネスとして達成したい目的があるわけですし。「技術的に難しいですよ」と言われて「そうですか、じゃあこれはやめときましょう」と言うだけの伝書鳩では、ディレクターのいる意味がありません。
企画やプロジェクトのオーナーとして、目的が達成できて、なおかつ技術的にも可能な落としどころやバランスを判断しなければならないですからね。
エンジニアとデザイナーの業務の境界があいまい
私はデザインチームのマネジメントもしているのですが、デザイナーとエンジニアの職域って重なっている部分も多いですよね。
デザイナーがどこまでやって、ここから先はフロントエンドエンジニアがやる…といった線引きはなかなか難しい。どうしたって重なる部分やグレーゾーンは発生します。
で、そういった部分に対してデザイナーが「そこまでこちらが考慮すべきではない」、エンジニアが「これぐらい考慮しとくのが常識やろ」とか思っていたりすると、齟齬が発生してしまう。お互いの知識や情報量、優先順位や目的意識などに差があればなおさらです。
たとえばエンジニアにデザインレビューをしてもらったときに、エンジニアは「なんでこんな作り方してるんだ」と思ってフィードバックするけど、デザイナー側は「なぜそんなフィードバックがくるのかわからない」みたいなパターンも起こりやすくなってしまいます。
きつい言い方をされて対エンジニアに苦手意識が生まれる
ディレクターの中には、顔を合わせてのコミュニケーションが好きな人も多いと思います。
が、エンジニアは開発業務の特性や文化的に、直接のコミュニケーションよりも、チャットでのテキストコミュニケーションを好む人が多いです。テキストコミュニケーションは感情を読み取りづらいですが、エンジニアの場合はさらに最低限の情報だけをストレートに伝えてくれる人も多い印象です。
それに慣れていないと、「あれっ怒ってる？」と思うかもしれないし、それが重なって「エンジニアってなんか怖い…」になってしまうケースもあると思います。
上記事例を経験したディレクターがやってること・考えてること
「対応してもらえる前提」で依頼しない＆前提情報を共有する
先ほども言いましたが、簡単そうに見える依頼でも全然簡単じゃないケースも多いので、間違っても対応前提で依頼してはいけません。
また、情報が足りない状態では、簡単に「できる」と言えないのが当たり前ですから、背景にある目的や意図、数値などの情報を伝える。その上で、「企画部（ほかの部署の場合もあります）的にははこんなことがしたいんですけど、どうでしょう」と聞けば、「ぜひやりましょう」とならない場合でも「それは難しいけど、そういった目的ならこんなのはどうですか？」と代替案を提案してもらえるかもしれません。
エンジニアって、技術的な知識があるだけではなく、サービスやユーザーについてすごく考えてくれていますから。（少なくともうちはそうです）
だからと言って非エンジニア側がへりくだりすぎるのもよくない
事業のメインがWebサービスである以上、エンジニアがいないと何も作れません。それは当然ですが、デザイナーがいないとデザインできないし、企画がいないと企画できないし、営業がいないとお客さんを増やせないし、経理がいないとお金を管理できない。仕事をする上ではみな対等ですし、ここにいる必要があるからここにいるわけです。
誰かが圧倒的に強い、誰かはいつも下手に出る…みたいな構造ができてしまうと、結果として組織における信頼性や心理的安全性に傷がついてしまいます。
そもそも組織にいる人たちはみんな「サービスをよくしていきましょう、いいサービスを提供しましょう」と、同じ目的を持って集まっているはずなですよね。その目的に向かうための建設的な議論は必須であり、避けては通れません。
エンジニアとデザイナーがお互いの考えやナレッジを共有するには、ペアコーディング（ペアデザイン？）とかをしてみると、お互いがものを作るときの思考がわかって、相互理解につながっていいんじゃないでしょうか。うちでも実際にやってみましたが、双方に学びがあって楽しかったそうなので。
あとは、いろいろと社内勉強会を実施したりしています。先週も、エンジニア・デザイナー・ディレクターと希望者の人たちでフロントエンド周りの勉強会を実施しました。
この記事で一番どうでもいい情報ですが、「エンジニアすごいなぁ」と思いながら聞いている私の後ろ姿です。着ているのはpaizaラーニングの動画レッスンで霧島京子としてナレーションをしてくださっている上間江望さん（@uemaemi）のライブTシャツです。週3でヘビロテしているので、社内では全然服を持っていないかわいそうなディレクターだと思われています。
依頼内容は細かく、わかる範囲の情報は明記する
特にレビューをお願いするときなどの話ですね。たとえば仕様チェックを依頼したいときには「どんな観点で見てほしいのか」、こちらがわかる限りの前提条件や制約条件を明記して依頼します。
レイアウト変更によるUI/UX損失について見てほしいのか、追加機能発生による連携機能への影響を重視してほしいのか、もしくはただひたすらにユーザーとしての意見を言ってほしいのか（paizaだとサービスのメインユーザー自体がITエンジニアなので、割とこういうときもあります）。これがわからないと、指摘するときに見るポイントがズレてしまいます。
また、なるべく意図や目的を持ってデザインをして、その上で「ここはこんな狙いがあってこうしてるんですけど、もっとよさげなパターンがあったら教えてくださいね」と説明できるようにしておくのが重要です。わからない部分があれば、隠さず「ここはどうするとよくなるのかわからないので、助けてくれるとうれしいです」と言ったほうがいいと思います。
テキストコミュニケーションに他意はない
ディレクターなどをやっている人は、雑談から生まれるものを大事にしたいとか、温度感を知りたいとか言って、face to faceのコミュニケーションが好き・得意な人も多いんじゃないでしょうか。少なくとも私はそうです。
ただ、前述の通り、エンジニアの中には直接的なコミュニケーションよりもチャットなどによるテキストコミュニケーションを好む場合が多いですし、雑談などを好まない人もいます。それは、開発作業やそれに伴う思考を中断されたくないという業務の特性の違いもありますし、文化の違いもあります。そういったことを理解しておけば、別に怖がる必要はないというか。
弊社はエンジニアの中にSlackで使えるカスタム絵文字職人がいて、ものすごい数の絵文字を作ってくれています。たとえば「ありがとう」「わかる」「わからん」だけでも微妙にニュアンスが違う絵文字がいくつかあります。
こんな感じ。テキストコミュニケーションは感情やニュアンスが読み取りづらいという難点もありますが、これなら気軽なコミュニケーションの促進＆心理的負担を減らすことができます。
「顔を合わせないとわからない！」つって直接のコミュニケーションばかりを重視したりするのではなく、多様なコミュニケーション手法でうまくやれるのが、本当にコミュニケーション力のあるディレクターなんだと思います。
多少はデザインや開発の知識がないとディレクションできない
先ほども言いましたが、私はWebデザインチョットデキル、プログラミングはpaizaに入社して初めてちゃんと勉強し始めた感じです。足りない部分もありますが、全然知識がないディレクターよりはましだと思う、多分…。
Webサービスを作るんですから、技術的な知識もある程度はないと、そもそも間に立ってディレクションや議論をしたり、最終的な決断を下したりできません。
また、多少の知識があるからこそ、エンジニアやデザイナーといった専門的な技術を持っている人たちのすごさがわかるという側面もあると思います。
ディレクターは、自分で手を動かして何かを作れるわけではなく、みんなの力がないと何もできないので、そういったリスペクトを持ち、ちゃんと伝えていくことは忘れないようにしたいです。
まとめ
というわけで私が私がディレクター業務をする中で体験した、エンジニアとのギャップが生じがちなポイントや、それを解決するためにできること、気をつけたいことの話でした。
ディレクターやプロジェクトマネージャーなどのポジションにつくと、広くプロジェクトやチーム全体を見渡さなければなりません。対してエンジニアの業務は「これをどうやって作るか」を集中して考える時間が多く必要なため、それぞれ重視するポイントが異なります。だから、どうしてもギャップが生じてしまう場面はあります。
ただ、双方の仕事は寸断できるものではなく、密接につながっていますし、大きく組織として目指す目標は同じはずです。ってことは、やるべきなのは押し付け合いじゃなくて、目標に向かって協力しあうことです。
いい意味でお互いを巻き込み合って、お互いの立場や仕事を理解＆リスペクトしあっていきたいですね。
ちなみにpaiza(ギノ)では現在もディレクターを絶賛募集中ですので、もし興味を持ってくれた方がいらしたら、ぜひご応募ください↓
en-gage.net
あとエンジニアも絶賛募集中ですので、もし興味を持ってくれた方がいらしたら、ぜひご応募ください↓
【Webエンジニア】Railsによる大規模Webサービスの開発に興味のある方！
paiza転職は、転職時のミスマッチをなくし、エンジニアがより技術面にフォーカスしたやりがいある仕事を探せる転職サービスです。プログラミングスキルチェック（コーディングのテスト）を受けて、スコアが一定基準を超えれば、書類選考なしで複数の会社へ応募ができます。
「paizaラーニング」では、未経験者でもブラウザさえあれば、今すぐプログラミングの基礎が動画で学べるレッスンを多数公開しております。
詳しくはこちら
そしてpaizaでは、Webサービス開発企業などで求められるコーディング力や、テストケースを想定する力などが問われるプログラミングスキルチェック問題も提供しています。
スキルチェックに挑戦した人は、その結果によってS・A・B・C・D・Eの6段階のランクを取得できます。必要なスキルランクを取得すれば、書類選考なしで企業の求人に応募することも可能です。「自分のプログラミングスキルを客観的に知りたい」「スキルを使って転職したい」という方は、ぜひチャレンジしてみてください。
詳しくはこちら
