👬

手戻りを減らしたくて職種間コミュニケーションハードルを下げる活動をした話

azm

2024/12/11に公開

コミュニケーション

記事投稿コンテスト「今年の最も大きなチャレンジ」

idea

この記事は「🎄レバテック開発部 Advent Calendar 2024🎄」の 11 日目の記事です🤶⭐️

昨日の記事は きょうか さんの「モノリシックなシステムの保守開発のツラミと面白さ」でした🐱🩵
こんにちは、レバテック開発部の小豆畑です。

普段はオウンドメディアの運用や改善を行っています。

 TL;DR「プランナーが考えた要件が降りてきて開発が実装し価値を提供する」という流れの中で、手戻りが発生していました。
それに対して、各々の役割の認識を合わせて、必要なコミュニケーションをとっていこうよという働きかけをしました。
より早い段階でのコミュニケーションが増えて手戻りは減ったと思います
今まで気を遣って言及できなかったところも一緒に改善策を考えられるようになりました！

 チームの状況チーム状況について簡単に紹介します。

主な業務内容
オウンドメディアの運用や改善
改善内容はUI/UXの観点やSEO観点など内容は様々


チーム構成
開発メンバー4人、他部署にPO、ディレクターがいる


開発手法
スクラム開発（開発内でのみスクラムを実施）


価値が提供されるまでのフロー
プランナーが施策を検討
デザイナーがデザインを作成
開発が実装してリリース

職種を跨いだ価値提供のフローの中で手戻りが発生していました。

 価値が提供されるまでのフローフローの詳細を見ていきます。
プランナーがデザイナーとの施策検討会で施策を共有
デザイナーがデザインを作成し、ある程度要件が固まる
プランナーが開発部に施策として共有し、開発部から確認事項があれば確認
優先度順に開発
マーケ、デザイナーの受け入れテスト
リリース
4以降で開発チームが関与しますが、以下のような手戻りが発生していました。
影響範囲の考慮が抜けていてデザインが足りない
条件の考慮が抜けていてデザインが足りない
動的なコンポーネントのパターンが足りない
施策のサイズが適切ではない（意図が異なる変更が混ざっている）
4の工程で開発側からできるだけ疑問点を確認しますが、時間も限られていて、5,6の工程に進んでから考慮漏れが発覚することもあります。追加実装や影響範囲の考慮が発生し、見積もりよりも工数が膨らみました。その結果としてスプリントゴールが達成できない、タスクが逼迫してケアレスミスが発生するなどの影響が出ていました。

 デザイナーが画面設計書を書けたら差し戻しは減る？上にあげたような手戻りが発生しない成果物を作ってもらうにはどうしたら良いか。プランナーやデザイナーが画面設計書を書けるレベルで開発時に考慮すべき条件を洗いだせたら可能だと考えました。ですが、プランナーやデザイナーに画面設計書をかけるようになってもらうのが適切なのか？と考えた時、学習コストもかかりますし、そもそも責任範囲としては相応しくないと思いました。
プランナーやデザイナーだけでは開発時に必要な考慮ができないことは往々にしてある。では、そもそも適切な段階でコミュニケーションが発生していないことが問題なのではないかと考えました。



画面設計書で考慮される粒度の例

引用：基本設計における成果物一覧と書き方（基本設計書サンプルあり）

 心理的背景開発側

「プランナーやデザイナーは別チームの施策も担当していて忙しい」

「コミュニケーションは最低限にしないと...」
プランナー・デザイナー側

「開発共有までに詰めるところは詰めておかないとと、詰められる」

「聞かれたらこちらで答えを出さなければならない」
このような雰囲気が漂っていて、職種同士で分離感があり高いコミュニケーションハードルを感じていました。手戻りが発生する要因は心理的背景が影響して、適切なタイミングでコミュニケーションが取れていないことだと考えました。

 それぞれの役割について考える適切なタイミングでコミュニケーションを取ろうよ！と言っても具体的にどういうケースでコミュニケーションを発生させるべきかわかりにくいので、それぞれの役割を整理することにしました。
システム開発の大きな流れとして、要望→要求→要件→仕様→設計→実装の流れがあります。



（引用：エンジニアのためのドキュメント力基礎講座）
この考え方の中でプランナー、デザイナー、開発がどこのフェーズに関わっているのかを整理しました。
こうしてみた時に、明らかに被っている部分があります。「システム開発の大きな流れ」をみていただいてもわかるように「要件」と「仕様」は人間の世界とシステムの世界のどちらも関連していて、要件を詰めるためには仕様を理解している必要があり、仕様を固めるためには要件の理解が必要です。

 職種を跨いだコミュニケーションは不可避というわけで、プランナーやデザイナーだけで考慮するべき条件を洗い出すのは難しい。かつ、それぞれの役割が被っているフェーズがあることがわかりました。

なので、プランナーとデザイナーだけで無理して要件を詰め切ろうとせず、不明な部分がある場合は開発側に相談して欲しいと伝えることにしました。

 関係者全員を呼び出して演説したミーティングのゴールは以下の二つに設定し上述の内容を伝えました。
コミュニケーションハードルを下げたい！
役割意識を合わせたい！
一方的に伝えるだけなのも微妙なので、ミーティングでは最後にブレイクアウトルームを活用してヒアリングの時間を設けました。このヒアリングの時間が結構良かったと思っていて、ここから次のアクションも生まれました。

 他職種にコミュニケーションについて所感を聞いてみた話を聞いてみてどう思ったかプランナーとデザイナーにヒアリングしました。

要望とか要求とか分ける考え方があるんだよーって話について
知らなかった
知ってはいたけど、文化によって求められるものが違うので、スタンスを把握できてよかった
とにかくコミュニケーションをとるしか擦り合わせる方法はないなって感じた


アイディアや懸念はあるか
なんとなく分け方が分かったけど、相談するハードルを高く感じてしまう
もうちょっと気楽に相談できる場が欲しい

他のチームでは週1でプランナー、デザイナー、開発が参加する相談会のようなものがある
このチームでもやってもいいかも



 そこから始まった取り組み
プランナーとデザイナーと開発で相談会を定期開催
変更要件で仕様を確認したい時に相談が来るようになった
施策にする前に工数感、実現性の確認、調査依頼が来るようになった
施策のサイズを言及することもできる

開発側からの相談もできた
パフォーマンスチューニングの観点で変更したいなどの相談



施策共有会に開発メンバーも任意参加
全員ではないが参加するようになった
施策検討段階で開発側として気になったところを確認できるようになった


オフラインでコミュニケーションをとるようになった
少しずつコミュニケーションハードルが下がり、オフラインでのコミュニケーションも増えた（基本はオンライン）


 まとめ手戻りを減らすためにそれぞれの役割の認識を合わせてコミュニケーションを見直したよという話でした。

実際に話してみて、もっとコミュニケーションとりやすいと嬉しいのにと思っているはお互い様だったのかなと思いました。
タスクの範囲はどこなのか、自チームで解決できることなのかを意識してコミュニケーションを発生させることで手戻りを減らしリードタイムを短縮できると思うので、関係者を巻き込んでそういう意識づくりを進めてみてはいかがでしょうか。
明日は ないとー さんが投稿します🤡

「🎄レバテック開発部 Advent Calendar 2024🎄」をぜひご購読ください！🤶⭐️