Photo by Amtec Photos
こんにちは。倉内です。
自社開発の企業では、エンジニアはデザイナーやディレクター、営業・企画などエンジニア以外の人と一緒に仕事をすることも多いと思いますが、「無駄なやり取りが多い…」「なに考えてるか分からない…」とモヤモヤすることってありませんか？
「いいサービスをユーザーに提供しよう！」という気持ちは同じはずなのに、すれ違いが起きてストレスになってしまうのってつらいですよね。
ただ、コミュニケーションがうまくいっていないのかもという漠然とした課題感はあっても、具体的な対策をとるというのは結構難しいものです。
paiza（ギノ）でもやはりそういった状態になることはあって、試行錯誤しながらではありますが少し前からいろいろな取り組みを始めているところです。
そこで今回はエンジニアと非エンジニアが円滑に仕事を進めていくための具体策について考えてみたいと思います。
すれ違いの原因は何か？
そもそもの前提知識が違っている
当たり前ですが同じ会社で働いているとはいえ、部署や職種が違うと専門領域や日々の業務はまったく違います。
エンジニアでない人は開発に関しての知識はほとんどないですし、もちろん逆もしかりです（弊社は元エンジニアという人も多いのですが）。それを思うとお互い何もせずスムーズにいくのは難しそうだというのが分かりますよね。
SIerにいたころは開発依頼元であるお客さまは「お金を出す側」で、自分たちSE（開発）は常に「お金をもらう側」だったので、「お客さまの言うことは絶対！」という逆らいようのない前提がありました。
なのである意味そこは自社開発のほうが柔軟にやれる反面、絶対的な立場の上下がないので大変だなぁ…と感じたりします。
目に見えないところの理解は難しい
最終的な目標は「利益を上げる」ことだとしても、それを達成するためのやり方はそれぞれ違いますよね。
特に営業や事業運営の部署は売上直結の仕事をしていることが多いので、開発チームに開発依頼するときはどうしても「サービスに直結する機能の開発を優先してほしい」という気持ちになります。
非エンジニアにとって以下を（何の説明もないままで）理解するのは難しいです。
- 技術的な取り組みの大変さ
たとえば、大規模システムで利用しているフレームワークのアップデート、扱うデータが増えてきてレスポンスが遅くなった機能の改善など。「そんなに時間かかるの？ なんで？」と思っている。
- 保守の大変さと大切さ
スピードをトレードオフしてでも保守性や拡張性に優れた綺麗なコードを書きたい、スタートアップ企業で初期に蓄積してしまった技術的負債を返したいなど。「それって必要なの？」と思っている。
- 開発やバグ対応の難易度
一見簡単そうに見える追加機能が既存機能にめちゃくちゃ影響を及ぼすことがある、逆に「こんなの直せないよね…」と言われて聞いてみると簡単なものだったなど。
なんとなくコミュニケーションの取りづらさ感じる
多分どちらか一方がという話ではなく、お互いになんとなく積極的に話しかけるのに勇気がいるというか心理的ハードルがあるというか…。
エンジニアは「どうせ言っても理解できないだろうから話したくない…」と思っていて、非エンジニアは「エンジニアってなんか怖そう……理解してくれなさそう…」と思っている、みたいなの、心当たりはありませんか？
ただ、勇気を出して相談してみると一気に問題が解決するなんてケースもあって、相談するタイミングが遅れると結局解決するのも遅くなるため、コミュニケーション不足で発生する損失って結構ありそうだなぁと思います。
お互いが歩み寄るには？
「なにもしない」とどうなるか
「別に仕事に著しく支障があるわけではないし」と思って放っておくと……
- コミュニケーションが減って人間関係がギスギスした組織になってくる
- 溝が徐々に深まり結果的に仕事に支障が出てくる
- エンジニアが辞めていく
開発依頼には優先度や緊急度があると思うのですが、それについて相談できない（相談されない）状態になると結果的にはサービスの質に影響してきます。分かりやすい例で言うと、ユーザーがサービスの利用を継続できないレベルのバグが発生してるけど対応が遅いとかですかね。
また、機能追加や画面改修など事業運営側から依頼された開発だけを黙々とやっていると、保守系のタスクは後回しにされて技術的負債はどんどん積み上がります。
そして想定しうる最も避けたいパターンであるエンジニアが辞めていくという事態に発展していくのです…。
このブログでもよく言っていますが、現在エンジニアは非常に採用難易度が高く、しかも辞めた人と同じくらいのスキルの人を探そうと思うとかなり厳しいのが現状です…。人数が減ると対応できるタスクの数ももちろん減ります。
具体的な対策を考えよう
これまで述べてきたようなすれ違いは時間が解決してくれるというものではないので、具体的な取り組みで解決していく必要があります。
例として、弊社で実施していい結果が出たものをいくつか紹介させていただきます。
「ここに書いてあるようなことはうちの会社はとっくの昔にやってるぜ」という方は、他にもいい施策があったらぜひコメントで教えてください！
①バグやエラー発生時の依頼ルールを策定
これまではたとえばpaizaのサービス利用ユーザーから「なんかボタン押したらエラーになるんだけど」といった連絡があると、受けた人によってエンジニアへの依頼の仕方がバラバラでした。
Slackで個別にDMすることもあれば、オープンなチャンネルに投げて誰かが反応してくれるのを待つこともある…といった感じです。
個別にやり取りしてしまうと他のユーザーからも同じ問い合わせが来たときに情報共有しづらいですし（直ったあともしかり）、不特定多数に投げると誰も見てないor優先度低い？と思われて後回しにされることもありえます。
そこでエンジニアが以下のように「こうやって依頼するとエンジニアが対応しやすいかもしれない」フォーマットの提示と報告専用のSlackチャンネルを作ってくれました。
エンジニアから提案してくれたことで、どういった情報があれば調査しやすいか・再現しやすいかなどエンジニア以外では分かりにくかった点がクリアになりました。
エンジニアが対応しやすくなったことはもちろんですが、これまでは「情報足りない」「再現できない」と言われてちょっと怖いと感じていた依頼側が、何をどこに投げたら対応してもらえるのかが明確になったことで心理的ハードルがかなり下がりました。
②保守系のタスクの重要性を周知
弊社では「負債返済DAY」と呼んでいるのですが、エンジニアチームが月に1日必ず技術的負債を返済する日にあてることにしています。
ただ、非エンジニアのチームにとっては「負債返済とは…？」「エンジニア全員が月に1回必ずやるほどのものなの？」「その間にあのタスクを進めてくれたらいいのに…」なんて思ってしまうとすれ違いの予感しかありません。
そこで、エンジニア内だけでなく全社的に「なぜそれをやる必要があるのか」を理解して、納得するためにエンジニアのリーダーが説明を実施してくれました。
たとえば、今どのくらい負債がたまっているか（一覧を見せてくれたので「こ、こんなに…！」とみんなが認識）、どのくらいのスピードで増える／片付けられているのか（「なかなか減らすの大変なんだな…」とみんなが認識）といった内容です。
「負債返済DAY」だけに限らず、エンジニア以外にはちょっと理解が難しいことや馴染みがないことを背景含めて共有するのは大切なことだと感じました。
③社内勉強会を開催
以前SQLの勉強会を開催して非エンジニアもSQLが書けるようになったので、これまで毎回エンジニアに依頼していたデータ抽出がある程度自分でできるようになったと紹介したことがありました。
もっと小さい単位では、営業にエンジニアがついてスキルチェックの問題をみっちりマンツーマンで教えるといった勉強会もやってたりします。
最近では「HTML・CSS勉強会」をエンジニア主導で開催しました。メインの目的はエンジニアとデザイナーの認識合わせ（概念的なところからコーディングまで広く）でしたが、勉強会にはディレクター、ライター、CS（カスタマー・サクセス）チームなども参加しました。
エンジニアがスライドを使って説明しています。
内容はもちろんですが、エンジニアが普段どういったことを考えて＆大切にして開発しているのかを知る機会って、同じ会社にいても意外とないのでそこを知れたのもよかったなと感じました。
paizaのサイトもデザイン面の課題はまだまだあるので……これからよくしていくためにもこの勉強会は今後も継続予定です。
paizaトップページを見ながら。みんな真剣です。
④エンジニアリーダーが何でも質問に答える会を開催
つい先日ですが、エンジニアリーダーがなんでも質問に答えるよSlackチャンネルを開設して、1時間ひたすら質問に答えてくれる会を開いてくれました。
「どうやら社内で"エンジニアがなに考えてるかよく分からん"っていう噂があるらしい」ということでエンジニア側からの発案で開催。非エンジニア側からすると、「いや、そんなことはないはず……」と思っていたのですが、確かに質疑応答を見ると「ここは全然分かってなかったな～」「こんなことを考えてるのか～」と新発見ばかりでした。
「開発チームで今課題だと感じていることってある？」「エンジニアもっと採用したい？」といったことから、「リモートワークとか副業って興味ある？」「事務局のほうで電話対応が多いとフロアが賑やかになるけどエンジニア的にはどう思ってるん？」「てかなんでエンジニアになったんです？」などなど…活発に質疑応答が飛び交いました。
今度は他の職種の人も「Webディレクターだけどなんか質問ある？」といった形で開催を計画しています。
どちらから歩み寄るべきか問題
弊社はありがたいことにエンジニアのほうからいろいろと「こうするとよさそう～」というのを考えて提示してくれるので、取り組みとしてはそれに乗っかることが多いです。
ただ、paizaというサービスの性質上、全社員がエンジニアやプログラミングへの理解を深めて損はないので、営業がプログラミングを学習してスキルチェック問題を解いたり（こちらの記事参照）、SQLを書けるようになったりっていうのも大事にしています。
おそらく多くの場合は、エンジニアから非エンジニアに歩み寄ったほうがうまくいきやすいのかなという気もしますが（もちろん企業によりけりだと思います）、そればっかりでエンジニアに甘えてしまうとあまり意味がないので、お互いのことを理解する気持ちというのは必要ですね。
まとめ
エンジニアと非エンジニアのすれ違いとその対策についてお話してきました。
今回はエンジニアとそれ以外の職種の人のコミュニケーションのすれ違いを取り上げましたが、どのような職種・役割でも起こりうることではあります。
この記事を書くにあたって、弊社のエンジニアに「どうしてこういう取り組みを提案してくれたんですか？」と聞いてみたところ、第一声は「できるだけ楽したいから」と返ってきましたが（エンジニアっぽくていいですね）、もう少し聞いてみると「元々のやり方だと緊急度の高いものでも手が空いてる人がいないと放置になってしまったり、何かあってエンジニアが減ってしまったときに破綻してしまうと思って」とのことでした。
確かに組織はずっと同じ状態で居続けるわけではないので、このようにルールや仕組みを作ることでコミュニケーション不全による損失を防ぐことができると思います。
paiza転職は、転職時のミスマッチをなくし、エンジニアがより技術面にフォーカスしたやりがいある仕事を探せる転職サービスです。プログラミングスキルチェック（コーディングのテスト）を受けて、スコアが一定基準を超えれば、書類選考なしで複数の会社へ応募ができます。
まずはスキルチェックだけ、という使い方もできます。すぐには転職を考えていない方でも、自分のプログラミングスキルを客観的に知ることができますので、興味がある方はぜひ一度ご覧ください。
