第10回エンジニア座談会(テーマ:“非エンジニア”とのコミュニケーション)

EDOCODE TuneCore Japan Wano

2017.11.6

技術力・開発力の向上のため、Wanoグループ各社のエンジニアたちが隔週で集まって話し合う、エンジニア座談会。第10回のテーマは「“非エンジニア”とのコミュニケーション」。今回の座談会には“非エンジニア”である営業、ディレクター、デザイナーなども幅広く参加して、コミュニケーション上の課題や解決策について話し合いました。

エンジニア座談会とは?

参加者は、Wanoエンジニアサイドの取締役から、中堅エンジニア、新卒入社のエンジニア、インターン中の学生エンジニアまで、あらゆるレイヤーのメンバー。全員任意で参加しています。

エンジニアたちは普段、音楽流通サービス、映像流通サービス、動画広告プロダクト、ショッピングモールサイト、エンタメ関連アプリなど、携わっている案件がそれぞれ異なります。状況や開発環境も異なる中で、座談会ではそれぞれが抱えている課題や解決方法の事例などを共有し、今後どうすればよいかの意見やアドバイスを出し合い、技術力・開発力の向上に努めています。

今回の座談会テーマは『“非エンジニア”とのコミュニケーション』。デザイナー、ディレクター、営業など、Wanoグループの幅広い職種のメンバーが参加しました。

Slackだけだと、伝わりきらないこともある?

※以下、当日のコミュニケーション内容より一部抜粋

− 非エンジニアとのコミュニケーションで苦労したことは?(エンジニア)

エンジニア 営業さんとかディレクターさんは口頭で伝えたいけど、エンジニアとしては文面に残してほしい。そのような差があって苦労することはありました。文章で伝えてくれたほうが楽なのに。笑

非エンジニア 言葉のほうが強弱が分かりやすいのかもしれません。

エンジニア それなら、文章では文字を太字にしましょう笑 Slackでは顔文字をたくさん入れましょう笑

非エンジニア それはやるべきですね笑 ただ、Slackだと伝わり切らないこともあると思います。私はSlackで概要を伝えて、すぐ口頭で補足するようにしています。エビデンスみたいな意味合いもあります。

エンジニア 口頭もいいですけど、やっぱり書いてほしいです。どこかで聞いたな、どこかに書いてあったかな、それでSlack検索しても出てこない、となると残念です。そういうところに手間がかからないようにしたいです。全部JIRAでやりとりして残したい気もしますが、エンジニア以外がJIRA使うのは辛そうですね。

エンジニア 書くのも話すのも、どっちも大事ってことですね笑

 

− エンジニアが盛り上がるツボが分かりません笑(非エンジニア)

エンジニア エンジニアどうしでも、相手が初めての人だとツボは分かりません。だから相手が普段、何が好きなのか。ゲームなのか、スポーツなのか?探っていって、それでアニメのディープな話をしてみて、大爆死するっていう辛い思いをしたこともありました笑 だから引っかかりそうなところから振っていって、深掘りしていくように気を遣っています。

非エンジニア それってもはやエンジニアだけの話じゃないですね笑

エンジニア 前職で、お互いのことがよく分からない時に飲み会があった時、『実現できるかは置いておいて、今、私たちが何を作れたら楽しいか?』、という話をしたら、けっこう長い時間、盛り上がりましたよ。

仕様書は、書けばいいというわけでもない

※以下、当日のコミュニケーション内容より一部抜粋

− どのように社内でナレッジ共有していますか?(非エンジニア)

エンジニア 最近はGoogleドライブをよく使います。スプレッドシートにタスクが入っています。ドライブに置いてあるテキストファイルやGoogleドキュメントなどのリファレンスへのリンクを貼るようにして。仕様もシートに書いてあります。チームが10人くらいに増えて、役員とも情報共有が必要な中で、何をだれが把握してるか分かりにくい状況になり始めました。そこで情報をすべてドライブに移動して、ドライブを見れば誰しもが分かるようにしています。

 

− 文書化するデメリットって、逆にありますか?(エンジニア)

エンジニア 仕様書は、書けばいいというわけでもないです。前職のSIerで、仕様書を見せてもらったら厚さが1メートルもありそうな資料が出てきて。それは社員数が何万人って会社の案件だったので、極端な例ですけど。そうなってしまうと誰も仕様を見直せなくなってしまいます。だから最初のドキュメントは、軽くするのが大事だと思っています。要点とか大事なところだけを。

エンジニア 資料を残してからメンテされるかどうかも大事ですね。

エンジニア ドキュメントを残すのか、ソースコードにメモを残すのか。どのレベルでそれをするのか、という話もあります。

エンジニア 私は普段、コメント付けない派ですけど、このソース見ても分からないだろうな、というときだけ、コメントをつけておきます。ただしそういうときは、だいたい言い訳ですね笑 納得していないコードだけれど進めるしかない時とか。このクラスとこのメソッドだからこの処理だ、みたいな。

エンジニア 今日のテーマとずれて、非エンジニアが分からない話になってきましたね笑

動きのあるデザインでは齟齬も生まれやすい

※以下、当日のコミュニケーションより一部抜粋

− デザイナーさんが苦労することはありますか?(エンジニア)

非エンジニア UIでは、動きまで考えきれていないことがありました。まず、きれいな面での提案が通って。実際に動きをどうするか検討する段階で、反省点が出てきて。

エンジニア 動きのあるデザインって、大変そうですよね。当初、動きについての説明があっても、それがテキストに残っていないことがよくある。たしかに言ったはずだけど、そういう意図じゃなかったって齟齬が生じたりします。

エンジニア まずはプロトタイプを完成形まで持っていきましょう、がいいかもしれません。実際に動かしてみると、思っていたことと違うことはよくある。だからまず、動かせるところまでもっていって、その後に修正を入れることを予め考慮した上で、工数を組む。やっぱり最初から完成形を出すことは難しくて、後から仕様を変えるなって、バグを出すなって言われているようなものですからね。

グループのナレッジを自らの業務に活かす

・・・以上のやりとりは、当日の内容のごく一部。実際にはより多くの議論がなされ、座談会後には要点が纏まったログが共有されます。Wanoグループのメンバーは、このような座談会(隔週で開催)に自由に参加し、過去のログもすべて確認できて、ナレッジを自らの業務に活かすことができます。

Wanoグループのエンジニアポジションでは、ものづくりが好きな方、新しい技術が好きな方、エンタメ自社サービス開発に携わりたい方、を積極採用中です。ご興味がある方は当サイトの採用情報ページもしくはお問い合わせフォームからぜひご応募ください。お待ちしております。