こんにちは！！！スマートキャンプでエンジニアをしている吉永です！
私は現在、スマートキャンプの主力サービスであるBOXILの開発にフロントエンド、バックエンド問わず携わっています。
私が入社した去年の8月からしばらくは週一で出社していましたが、今年にかけてはコロナの状況が悪化していたためほぼフルリモートの環境でやり取りをすることが増えました。
BOXIL開発部の特徴として、社内のプロダクトの中でもステークホルダーとなる人物・部署が多く、開発をするにあたってエンジニア以外の社内メンバーとのやり取りが多く発生することがあります。
私は以前から部署間のコミュニケーション改善について興味を持っており、入社当初に弊社で取っているコミュニケーション施策の数々に感銘を受け、一年前のテックブログでもそのような内容の記事を書いています。
はじめに
先日、いつものようにTwitterを眺めていると、このツイートがバズっているのを目にしました
プログラマにすごく気を遣うのが「◯◯ってできますかね？」みたいに質問した際に、しばらくして「実装しました」と実装して返事が返ってくる事が経験上多くて。
— ぽこぺん (@pokopen_cg) 2021年8月12日
このツイートには「できるかどうかの調査を進めた結果、完成形に近くなってしまっていることがよくある」といった依頼された側の目線に立ったリプライや、「目的や意思がうまく伝わっていないのではないか」というようなコミュニケーションのあり方について言及するようなリプライがついており、エンジニア、非エンジニア問わず多くの方から意見が寄せられていました。
コロナ禍でリモートワークを取り入れた会社などでも、上記のような事例にかかわらず他の部署が関わるやり取りでのコミュニケーションがより複雑になってしまっているのではないかと思います。
今回の記事では一作目の執筆から一年が経ち、まだオフラインのコミュニケーションも視野に入っていた頃からフルリモートに変わった時に、弊社で取り入れた「なるべく気を使わない」ためのコミュニケーション施策を紹介したいと思います。
完成形が返されることによるデメリット
まず、上記ツイートのようなコミュニケーションにおける問題点について考えてみました。
上記のツイートにある「できますか？」→「実装しました」のフローにおいて、エンジニアの立場からすると先述のような「調査がてら実装していたらそれが完成形に近いものだった」というのはよくある話かと思います。
エンジニアからすれば「作ってみないとわからない」といった状況だったり、「仮で実装した結果を踏まえて、再度プランニングをする」と言った考えもあるのではないでしょうか。
しかし、ツイートにもある通り本来依頼側がやって欲しかったのは実現可能かの調査であり、結果的に実装されてしまった物に対して負い目を感じてしまったり、気を遣ってしまうのは双方にとって勿体無いコミュニケーションのありかただと感じました。
なので、上記ツイートに対して私が感じた問題はエンジニアが調査依頼に対して結果的に実装を終えてしまった部分ではなく、実装をしてしまったことに周りが驚いてしまっている、更にそれに対して依頼者が気を遣ってしまう結果になっていることだと感じました。
勿体無いコミュニケーションの弊害
お互いの意図が伝わらないまま進んでしまい、勿体無いコミュニケーションが続いてしまうと
- 本来はカジュアルに進められるやり取りに気を使ってしまう
- 不要な手戻りが発生してしまう恐れがある
- 依頼者と実装者がお互いに何を考えているかを把握できない
など本来懸念しなくていいリスクを負う可能性があると考えました。
また、私がこの件に関してブログを書きたいと弊社Slackに投稿したところ、実際にデザイナー・企画をやっている方から以下のような意見をいただきました。
実装できる場合に考慮したいことや、追加でやりたいことなど細かいコミュニケーションが疎かになってしまうことにより、後出しで出てくる要望に対するエンジニア側の混乱などもありえない話ではないのかなと感じました。
弊社で行っている施策
ここからは、上記の考えを踏まえた上で弊社で実際に取られている依頼から実装までの流れや、お互いに気を遣うことを減らすために最近始めた新しいコミュニケーション施策を紹介します。
タスクの依頼フローの整備
まず紹介するのは弊社メンバーが開発チームに依頼する時に制定しているフローについてです。
図解すると基本は以下のようになっています。
他部署からの依頼は、基本的にProduct Requestという名前のSlackチャンネルに投稿され、規模が大きいものは翌日に各チーム(エンジニア、デザイナー、企画)のリーダー陣が揃った会議で揉まれます。
そして、Asanaというタスク管理ツールのTodoに積まれ、スクラム開発の手法に則った方法で、メンバー全員の稼働時間に合わせたポイント分の課題を次のスプリントのタスクとして積んでいくことになります。
この時、リーダーが実装者にタスクの説明や、実装方針の設計をするプランニングという作業が行われますが、弊社ではこのプランニング時に
- 出来るだけ細かい単位でのサブタスクの切り出し
- 参照する可能性が高いファイルや関数の洗い出し
- 説明された上で、煮詰まり切っていないと感じた考慮事項などの洗い出し
などを行います。こうすることにより、実装時の関連ファイルの調査時間の短縮や、考慮漏れのカバー、実装時に着手しているタスクを他メンバーに引き継ぐ際に、ある程度の粒度で引き継げるなどの恩恵があります。
タスク開始後の相談・報告チャンネル
タスク開始後、エンジニアが外部とのやり取りに使うチャンネルは主に3つあります。
1つ目は、先ほども紹介したProduct Requestという部屋です。 この部屋の役割は、多部署メンバーからの質問や、気がついたバグの共有、追加機能の依頼などを集約する目的の部屋になっており、タスクがはじまった後、そこにリクエストを書き込んだ対応者と直接やりとりができる部屋になっています。
上記の例ではバグ修正になっていますが、依頼に対しての実装可否や、機能追加などの際には「この動作をしたときはこうなって良いですか？」といった質問のやりとりをスレッド上ですることになります。
対応時期の相談などもここで行われるため、「あの時依頼したもの、いつ対応してくれるんだろう...」と言ったような不安も解消することができます。
逆に、急ぎではないけどいつか対応してほしいといったような温度感が低い依頼なども来るため、納期や工数と相談しながらスケジュールを組むことができます。
また、全ての投稿に必ずBOXILチームに所属するエンジニアや企画メンバーが答えてくれるため、チャンネルの乱立や「この会話ってどこでしてたっけ...」といったリスクも防ぎつつ、カジュアルな相談をしたり、お互いの部署の考えや施策を共有する場としても一役買っています。
着手中のタスクのデザイン・仕様に関する質問・報告チャンネル
上記のProduct Request部屋とは別に、着手中のタスクのデザインや仕様に関する質問をするboxil_dev_困という名前の部屋があります。
この部屋では、主にタスクを進める上で疑問に感じたことや、調査タスクの結果の報告、追加の要望などをリーダー陣や企画(デザイン)メンバーにヒアリングできる部屋になっています。
上の画像のタスクは、とある外部サービスをBOXILに埋め込むことができるのかという文脈から発生した物でした。
埋め込めるかどうかを調査した上で、可能だった場合は既に上がっているデザインのもので実装してほしいといった内容のものでしたが、実際に埋め込んでみると以下のような問題がありました。
- 外部サービスの縦幅が想定より長い
- 長かった結果下に大幅なスペースができてしまった
- デザインに使い道のわからないボタンが載っていた
その為、調査の結果埋め込めることを伝えた上で、上記の問題を細かく報告し、工数に見合った追加対応ができるかどうかを話し合いました。
こうした細かいコミュニケーションを繰り返すことにより、出来上がった物に対する認識の齟齬や、遠慮せずにまずは提案してみる空気感を作ることができています。
リリース後の報告チャンネル
BOXILチームではリリースした内容を関係する各部署のメンバーに共有する部屋があります。
リリースしたコンテンツは、毎週金曜日に行われているSprintReviewという場所でも発表されることになりますが、このチャンネルではその速報を流しているといった運用になっています。
速報で流す理由としては、
- 新機能などの認知のため
- スタイル修正などで意図して変更したものがバグだと誤認されないため
- 逆にバグっていた際に、非エンジニアでもおかしいかもと気がつけるようにするため
など、些細なことでも正確な情報を共有することにより、誤認により生じる不要なコミュニケーションを防いだり外部部署との連携を取りやすくしています。
また、新メンバーが初リリースをした際にはそれを報告したり、待望の機能がリリースされた際には様々なリアクションがついたりと、開発モチベーションの維持にもつながっています。
まとめ
上記の施策を通してわかるように、基本非同期的になってしまうオンラインでのコミュニケーションをよりオープンにしつつ、やりとりを密にすることで認識の齟齬を回避するようにしています。
この施策の成果として、外部からはわかりにくいエンジニアリソースや進捗がわかりやすくなり、依頼をする際にどこまでをやって欲しいのか、どこまでは考慮できてないから相談したいのかなど、依頼者の目的や意図、温度感などに合わせた柔軟でカジュアルな対応を実現することができています。
エンジニアからしても外部からの依頼に対する温度感がわかることは、今後の開発スケジュールの作成や毎週のスプリントの構築に不可欠であり、認識齟齬が減ることによる手戻りリスクなども減らすことができるため、安心した開発ができているかと思います。
また、このようなフランクなやりとりをするためには、普段からのメンバーに対する理解があってこそだと感じています。
最後に面白い取り組みを紹介すると、
某若手エンジニアが自画自賛をしていたことから始まったこの「オレがエラい」という企画は、毎週金曜日になるとデザイナーの方が毎週違う画像を貼ったスレッドを作ってくれて、そこに今週やった自分が誇れる内容を開発チームメンバーが書けるようになっており、エンジニア・デザイナー内での相互理解も積極的に進めています。
オンラインでの働き方が認められつつある今、この記事がチーム内 or 会社全体でのコミュニケーション不足に悩んでいるという方々や、タスクを進めるにあたって認識の齟齬が目立ってきたと感じる方々の助けになれば幸いです。
