事務職の私が、エンジニアとのコミュニケーションの失敗と学びをシェアします

はじめに

Ateam Lifestyle Advent Calendar 2020の20日目は、株式会社エイチームライフスタイルの @mdge27 が担当します。

この記事は、いわゆる事務職の私が、エンジニアと仕事をしていくなかで沢山失敗しながら、一緒にWebサービスの管理画面を作った経験とそこからの学びをシェアする記事です。

あくまで私の個人的な見解にはなりますが、「これからエンジニアの方と一緒に仕事をする予定の人」「非エンジニアとのコミュニケーションに苦戦しているエンジニアの方」の参考になれば幸いです。

この記事を書くにあたり、一緒に管理画面を作った3名のエンジニアに、私に対するFBをいただきました。皆さんからのFBと私自身の振り返りを照らし合わせて、この記事を完成させることができました。
（Sさん、Wさん、Hさん、暖かいFB、本当にありがとうございました！）

自己紹介

2017年5月に営業事務として中途入社し、これまでラッキーにも社内の3つの事業に携わってきました。
現在は営業サポートやバックオフィス業務をメインに、CS対応や関連する施策の実施など、幅広い業務をしています。

入社前の私のITスキルはかなり乏しいものでした。
HTMLで簡単なホームページを作ったことがあり、タグやWebサイトの基本的な構造が分かる程度でした。
今でも「技術的な事は良くわかりません」な私ですが、エンジニアとストレスなく一緒に仕事ができていることは、成長した部分かと自負しています。

各事業部での私の役割と学び

私が経験した3つの事業部での学びを段階形式で紹介します。

ー1つ目の事業部「issueと優先度の重要性」ー

この事業部では、サービスサイト上や管理画面の細かな仕様の修正を担当しており、開発依頼をする初めての機会をいただきました。
初めの頃はissueを書くのにも抵抗があり、「書くのも時間かかるし、とりあえず開発は必要だしなぁ」と苦手意識が強かったです。それが失敗だと気づかずに、、、

issueを丁寧に書かないせいで、いざ実装となった際に確認事項が沢山発生してしまったり、エンジニアのリソースを無駄に奪ってしまっていたのです。

エンジニアは魔法のようにプロダクトを作りますが、限られたリソースで最大限の成果を出すことをいつも考えてくれています。
そんなエンジニアの貴重な時間を奪わない為、Issueを的確・丁寧に書くことでその先の工数を一気に減らすことができます。
また実際に優先度を決める会議に参加するようになり、issueの「背景・目的・効果」を並べて「事業にとって効果が高いものは何か？」を判断する場面を目の当たりにして、初めてその重要性がわかりました。
入社後すぐは、その意義が全然分からなかったのです。

issueを書くうえで特に気をつけているポイントとしては、以下の通りです。

・誰が見ても分かるように書く　

（解釈による齟齬がなるべく起きないようにする）

・定量的な効果を記載する

　（例えば工数削減であれば削減時間が分かるようにする「○時間/月 = ○min. × ○回(1日)」）

ー2つ目の事業部「目的と背景の共有に責任をもつ」ー

新規事業に携わることとなり、サイトローンチの少し前からチームにジョインしました。
BtoBtoCのサービスですが、この事業では社内用の管理画面、事業者に使っていただく管理画面の改修にがっつり関わることになります。
社内管理の効率化・事業者の管理画面利用満足度を上げることが私のミッションです。

自分が一番よく使うプロダクトになるので、こだわりたくなる部分も多く「ここをこうして欲しい」という相談の仕方をしていたのですが、これが２つめの失敗です。

この伝え方だと、エンジニアは「何を解決・達成したいのか？」目的が分からないからです。
詳細をヒアリングしていただき、結果「その目的ならこっちの方法の方が良いよね」となった場合、MTGで話を聞いていただいた時間や、詳細な仕様まで考えた時間が無意味になってしまいます。

この学びから、目的/やりたいことの共有に責任を持ちつつ「どうやってやるかは、いちばん良い方法を一緒に考えてもらう」というスタンスに、自分が変わっていきました。

ー3つ目の事業部「認識をスムーズに揃える為に」ー

この事業部もBtoBtoCのサービスではありますが、特にユーザー向けアプローチが重要になる事業で、CSに注力するフェーズでのジョインでした。

CS管理画面は存在したのですが、既存のシステムでは補えない課題が増えてきて刷新することになりました。
事業者向けの管理画面も新しく作ることになり、前事業での経験が活かせそうなので任せていただくことになりました。

今回は営業・事業者・CS担当者・デザイナー・エンジニアと多くの関係者がいるPJです。まずこのPJのゴール：達成したいことの認識をチーム内で合わせること、そしてそれが本当にユーザーニーズに沿っていて成果になるのか？の議論からのスタートでした。しかし関係者が多いこともあり、擦り合わせになかなかの時間を要しました。

ここでは、一緒にPJを推進してくださっているエンジニアのHさんから受けた学びをシェアします。

Hさんは新卒2年目の若手ですがしっかり者で、物事を整理するのがとても上手です。
MTGの際には、議題になる事象・課題や業務フローなどを、事前に図解にして用意してくださることが多いです。
そのおかげで、前提の情報の認識が揃った状態から話し合いをスタートさせることができています。

そういえば、前のサービスの仕様決めの時も、よく紙に書いて説明し合ったなぁとふと思い出し、紙が１枚あるだけで、情報の整理と可視化が実現し、認識合わせがスムーズになるという学びを発見しました。これは、エンジニア⇔非エンジニアのコミュニケーションに留まらず言えることかもしれません。

まとめ

実際にプロダクトを作る過程で、お互いの意見が食い違ったり、ミスコミュニケーションがあったりもしたと思います。ですが、良いものを作りたいという同じ目的のもとに、相互理解を深め、お互いを認め合い必要とし合うことで、MTGの生産性がどんどん上がっていくのを私は目の当たりにしました。
私の経験からにはなりますが、 エンジニアと非エンジニアが気持ちよく仕事をするために知っておくと良いことを以下にまとめました。

For 非エンジニア
・エンジニアは、限られたリソースで最大限の成果を出すことをいつも考えてくれている
・目的/やりたいこと/効果の共有には私たちが責任を持つ
・そしてどうやってやるのが良いか？は自分で決めつけず、エンジニアと一緒に考える

For エンジニア
・非エンジニアは、優先度付け「背景・目的・効果」の共有の重要性が分からないので、丁寧に丁寧に伝える
・紙とペンをコミュニケーションツールにしてあげると、認識合わせがとても早くなる
・これらを意識すると、開発のためのコミュニケーションの生産性がぐっと上がります。

偉そうなことを書きましたが、正直に言いますと、私自身もここに書いたことが完璧にできている訳ではなく、まだまだ至らない所ばかりです。
私よりもよっぽどPJを引っ張ってくださっているHさんには、いつも頭が上がらないです。
ただ、ある時ふと「@madgeさんなしでは管理画面を作れなかった」と言ってくださった時は、自分の存在意義を見出せて、本当に嬉しかったです！

感情のシェアまでしてしまいましたが、この記事がどなたかの参考になりましたら幸いです。