19歳で転職した私が気づいた、すれ違わないチーム開発をするために必要なこと

こんにちは！！！スマートキャンプ、エンジニアの吉永です。

私は8月にスマートキャンプに中途入社し、今月で3ヶ月目となります。前職では受託開発を主にした小さな企業に未経験で入社し、そこで一年間フロントエンド、バックエンド問わず開発したり、テックリードのような業務も行ったりしていました。

小さな会社なので部署というような区切りはほぼ無く、社長含め全てのメンバーがエンジニアといったようなエンジニア集団の環境で、日々開発タスクをこなしていました。

しかしある時期をきっかけに、外部の方と協力する機会が増え、エンジニアだけがいる環境から様々な人間が関わる環境へと変わっていき、とあるプロジェクトを進めている最中、私達エンジニアサイドと、企画サイド、デザイナーサイドでうまく噛み合わず、スケジュールが大幅に遅れてしまいました。そして、このことをきっかけに私自身がエンジニア以外の人間に対して苦手意識を持ってしまい、なかなか克服することができずにいました。

この記事では、スマートキャンプが転職後の私に対してどのような意識の変化をもたらしたのか、どう克服したのかを書きたいと思います。

注 : 前職での失敗例などが出てきますが、今でも交流のある大好きな会社ですし、disりたい訳ではないです。噛み合わなかったことには理由があると考えており、今後に反省が活きれば良いと感じています。

失敗を振り返る

まずは苦手意識を持つまでの流れを少し振り返ってみたいと思います。

この時のチーム構成

エンジニア(4人)
企画(3 ~ 4人)
デザイナー(1人)

といったようなメンバー構成でした。

この時の言い分

エンジニア
- 僕達は悪くない
- デザイン確定後もXDが無言で変更されている
- Atomic designを採用しろと言われたが、XDで上がっているボタンやモーダルのサイズが尽く違う
- 知らされていない仕様や当初からわかっていた厳しめスケジュールで追い詰められていた
企画(3 ~ 4人)
- 僕達は悪くない
- スケジュールはこれで行けると思っていた
- 仕様など考慮が足りない部分は申し訳ないが、既存の機能を踏襲していたりしてどうしても変更が難しかった
デザイナー(1人)
- 僕は悪くない
- しっかりパーツ作って欲しかったのに1 ~ 3pxズレてるんだけど...
- 僕の中ではこの部品はこういう動作をする予定だったんだけど...

という感じで、各役割ごとに言い分があり、それぞれの部署で他の部署に対する共有していない要望や考えを持ち合わせていました。

では、具体的に何が悪かったのかを自分なりに説明してみたいと思います。

噛み合わなかった原因

暗黙知の部分を形式知だと思い込んでいた
開発は開発、デザインはデザイン、企画は企画という意識が邪魔をして、お互いにお互いのことを指摘できなかった
その割には誰が何を決めるという部分が不明確で、仕様とデザインで一体となったものにならなかった

プロジェクトを進める上で、各個人には何かしらのここだけは譲れないポイントがあるのは当然のことです。

しかし、それは自分だけの世界で常識だと思い込んでいる部分もあり、相手にとってそれが常識とは限りません。

エンジニアとデザイナーの間で起きた問題

エンジニア
- なんか12.6みたいなよくわからん幅のパーツあるけど、13でええやろ！w
- なんかXDがデザイン決定後も大量に更新されてるけどどれが正解なんだろ...自分は最新版にしておこう。(結果メンバーごとに持っているXDのデザインバージョンが違う)
- ここ、実装上かなり難しいぞ...こんなところに時間とってる暇ないんだけどな...
デザイナー(1人)
- 急いで作ったけど、ピクセルのズレとか無いよね...?このパーツは全部12で揃えたいな！
- ここのパーツの幅が思ってたよりも広いな...ちょっとだけだし修正しちゃおう！
- これ機能にはあまり関係ないけど、こちらの方が視認性が良いしこういうデザインにしておこう！

といったような、各々の心の中で完結してしまっていた問題がかなりありました。

これは単にコミュニケーションが不足していたことで起きた問題で、適度に自分の思いを共有していれば防げた問題でした。

また、エンジニアという立場ながらデザイン的に疑問に思ったことなどが多々ありましたが、自分の管轄外だと思っていたことにより指摘をせず、結果余計な工数がかかってしまったり、「実装してみたけどやっぱり微妙だったね」といった結果を産んでしまうことになりました。

企画サイドとデザイナーサイドの間で起きた問題

仕様などを決めていた企画サイド、デザイナーサイドでも同じようにコミュニケーション不足による齟齬を生み、結果エンジニア、デザイナー、企画でそれぞれ違う仕様に対する理解をしてしまっていました。

全体で起きていた問題

一番の理由となったのは、各自が自分達はあまり悪くないという態度を取ってしまったことが原因だったように思います。

振り返ってみると各サイドごとに出来ていた部分、出来ていなかった部分は可視化されていますが、当時はそれを考えることすらせず、僕たちはしっかりやったけどあっちの対応は甘かったというように感じてしまっていました。

結果、エンジニア、デザイナー、企画の役割がうまく回らず、スケジュールが遅延した原因だと考えています。

しかしながら、こうした過去の失敗からなかなか抜け出すことができず、私はこうしたエンジニア以外との仕事の仕方について、やりにくさや苦手意識を持つようになってしまいました。

スマートキャンプに入社後、どうなったのか

前職とは違い、スマートキャンプには開発チームの他に、セールスやメディア、マーケティング、人事など数々の部署が存在しています。

しかし、これらの部署間でいがみ合うこともなく、部署間のコミュニケーションがかなり円滑に進んでいることに驚きました。

ここからは、私が入社後に感じた、他部署との連携をうまく取るために必要だった施策を紹介したいと思います。

1. やりたいタスクは、それをやりたい人間が説明する

スマートキャンプのプロダクト部には毎朝、今週から来週あたりにかけてやりたい施策の説明をし、それにかかる期間(ポイント)をエンジニアが決める朝会と呼ばれる会が存在します。

朝会は基本、PdM、エンジニア全員、デザイナー一名、プランナーの方一名で行われます。

この時、細かい連携上発生したタスクや、計測結果から予測した改修タスクを説明するのはPdMが担い、デザインタスクや戦略部内で発生したタスクを説明するのは、朝会に参加している他部署の代表の人が説明します。

そして説明後に、実装するエンジニアと

どのように実装するか
不明点に対する質問
かかりそうな期間と優先順位

などを話し合い、一つの案を実際のタスクへと落とします。

タスクを持ち寄った本人から説明を受けた上でわからないことがあれば都度質問できるため、認識の齟齬の原因となっていた暗黙知の部分を解消することができます。

そして、これにはもう一つ大きな意味があります。

例えばデザインタスクの説明を受けた上で、「やれなくはないかもだけど、かなり難しいよ」という部分があったり、「本来の設計上難しい」などエンジニアのみがこれまでは把握していた知識をデザイナーにも直接共有することができます。

そうすることにより、仕様上実装が難しい部分の早期発見や、「これはできないけど、こうなれば可能」と言った逆提案も起きるようになるため、より活発に議論することができるようになっていました。

2. 疑問点を見つけた時に、本人に直ぐ連絡できるオープンな環境がある

スマートキャンプのslackには、 #boxil_dev_困 という、名前の通り実装上や業務上、困ったときに本人または誰かに質問するチャンネルが設けられています。

f:id:yoshinaga-iwnl:20201108183053p:plain

上の画像は、 #boxil_dev_困 に私が投稿した質問の一つです。

この時、私が聞きたかった内容は以下の通りでした。

パーツのCSS共通化を行いたかった
デザインは同じだがサイズがほんのちょっと違うボタンが複数個あり、それを統一してもいいか。(ボタンサイズの差異は意図的なものか)

ほんの些細なサイズの違いですが、もし意図してこのサイズになっていたとしたら勝手に変えてしまうと、本来デザイン時に目指していたものと、実際リリースされたことに違いが生じてしまいます。

また、意図していないものだとしたら、実装してしまうと後から「やっぱ違うな」と感じてしまい、手戻りが発生してしまうこともあります。

「デザイナーがこう指定してきたから」とか「こういうものを作ってくれと言われたから」という受け身の考え方ではなく、自分が思った当事者としての意見や、指摘を直ぐに共有することができるのが、このチャンネルの強みだと思っています。

どんな些細なことでも質問、指摘し、最終的な完成物の精度を上げていくことで、すれ違いを最低限に減らすことができます。

3. 他の部署が感じたプロダクトへの些細な違和感を、すぐに共有してもらえる環境がある

私は開発をする以上、バグはつきものだと考えています。(無い方が良いですが)

また、どれだけ密接にコミュニケーションを取っていても、当時想定していなかった仕様や実装依頼が来ることもあります。

スマートキャンプのslackにある、 #boxil_product_request というチャンネルは、どこかのタイミングで起こってしまったバグの修正依頼や、追加の対応依頼などを、気がついた人が誰でも依頼できる場所になっています。

f:id:yoshinaga-iwnl:20201108194355p:plain

ここに投稿された依頼は朝会でPdMなどから共有された後ポイントをつけ、タスクに積まれていきます。

実装している私達には、ユーザーの気持ちを直接知ることのできる機会がかなり限られてしまっているため、実装した時点ではイケていると思った実装も、ユーザーにとっては使いにくかったり、コードレビュー段階では気が付けなかったバグが存在していたりします。

その制作物を、第三者視点で見た上で、実際に起きていた違和感に気が付き、いち早く共有してもらえる環境はエンジニアとして実装している私からしたら、ありがたい以外の言葉が見つかりません。

実際に、気がつかなければ大損害を招いていた可能性をある不具合などをいくつか報告していただいている上、「こういう機能がユーザーとしての要望が多いのですがどうでしょう」と言ったような提案を日々していただいており、個人的にはこのチャンネルが一番すれ違わないチーム開発をするための効果を発揮していると思います。