スターフェスティバル スターフェスティバル Advent Calendar 2022の 8 日目の記事です 🚀🚀
昨日の k1rnt さんによる Google OSS にマージされた話、なかなかチャンスに気づくことも実行することもないのでいい経験ですよね！面白かったので是非読んでみてください！
改めましてこんにちは！スターフェスティバル株式会社のバックエンドエンジニアをしています釣り 🐟 大好き"たーさん"こと内山です。
はじめに
この記事では、
事業会社のプロダクト開発って、事業側と開発側が分離して動いてて色んな問題あるよね〜 って一般的によくある課題に対する解決策をお話したいと思います。
エンジニア（以降、開発側 と称します）と、エンジニアではなくサービスを利用する/提供する側（営業・オペレーションなど。以降、事業側 と称します）との関わり方についてです。
スターフェスティバルに来てから、そこへの垣根が無くて、そもそも事業をみんなで作り上げる意識が醸成されている環境だなぁと感じていますが、多くの会社でなぜ分離が起きるのか、それを解決するためどんなアクションができるのか、実例を踏まえて取り上げたいと思います。
内容は斬新なものでもないですが、ぜひエンジニアのみなさんだけでなく、事業側の方も読んでいただけると有り難いです！
自社プロダクト開発も課題いっぱい
そもそも、事業会社の開発チームって企業のビジョンを体現するために活動していると思いますが、意外と目標が明確じゃなくてなんとなく組織が動いていたり、よく吟味されない改善要望に追われて、気づいたら 社内受託？ みたいな状況に陥ることってあると思います。
私はエンジニアとしていくつか事業会社で自社プロダクト開発をしてきましたが、社内運用システムでも、外部向け Saas を自社開発しても、よく起こる課題ってこういうものがありますね。
- 事業側から頻繁に機能追加の開発依頼がくる
- 開発優先度の軸がないので、入ってくるものを消化するサイクルになってる
- これやったら誰がハッピーになるの？
- リリースしたけど、ぜんぜん使ってくれてない
- 限られたリソースでやることいっぱい...
- プロダクトがキメラ化してるし、リファクタの余裕もない...うううううっ
そんな状況になるのを防ぐには
開発側と事業側の壁を無くし、目を揃えて同じゴールを追う
シンプルに言うとこれだけ必要だと感じます。
相互が目を揃える
ここで 目を揃える とは、開発側と事業側が相互理解をし、同じ言語で、同じ目標を目指す状態にすることです。
冒頭に列挙した課題って、相互のメンタルモデルを理解しきれずポジショントークになっていて、且つ事業側側だけ or 開発側だけで思考し動いてしまうことが大きな要因だと思ってます。
では、目を揃える ためのアクションを考えてみましょう。
1.相互ができるだけ接点を持つ
やってみよう 1 ： Daily 定例
コミュニケーションの重要性は言わずもがなです。ですが、「あまり頻繁に話すこと無いし..」とか「PM に任せてるし..」で疎かになってませんか？
話すこと無くてよし！とにかく顔合わせて（オンラインで OK）、先週と変化がない進捗の共有したり、雑談になってもいいので、毎日（最低週１）で事業側とエンジニアが話せる機会を作るといいですね。それによってお互いの動向や、思考方法、インサイトが相手に伝わって信頼関係もでき、踏み込んだ話もだんだんし易くなってきます。
プロジェクトのコミッターが多すぎると難しさも感じますが、話をしやすくなる 10 人くらいまでに分割できるといいかもしれませんね。
私のいるプロジェクトでは、毎日 30 分の定例を設けていて、疑問提起、進捗報告、レビュー会なんかをやってます。
やってみよう 2 ： チームビルディング
さらに事業側と開発側が、業務の話を抜きにお互いを知るチームビルディングしてみたりもしました。
その際は各自の得意なこと、苦手なこと、今後やりたいことを発表したり、
mgramを使って、みんなどういう人？を知ることで、より相互理解が進み、同じ目標に向かって動いてるんだ！とモチベーションが上がる体験ができました！こういうのは普段、同じ職種同士でやることが多いですが、プロジェクト内の他職種同士でやってみるって斬新ですよね！でも新たな発見が多かったです。
だんだんと垣根が無くなってきませんか？
2.相手に伝わる言葉で話すこと
ホント常に意識しないといけないですが、エンジニアの使ってる言葉で話すと理解してもらってないことあります。
プルダウン/オプション、モーダル、データモデル、デプロイ...使う時は気をつけましょう。具体的に画面で指し示しながら用る工夫をしたり、技術的細かい事は隠蔽して、結果的に誰が、いつ、どう操作すると何が起こるかなどと、システムの実操作を起点に話をするといいかもしれません。
また、スターフェスティバルではプロジェクトの初期からプロジェクトに関わる全部署が一緒に「用語集」を作り、用語の抽象度を均して下げるよう心がけています。ドメイン駆動開発をするにあたっては一般的な手法です。
たとえば、業務ごとに「アカウント」の意味が異なる事ってよくありますよね。こういった用語の意味を揃えていきます。
- A さん・・・ユーザーアカウントと顧客アカウント、どちらもアカウントと呼んでる
- B さん・・・ユーザーアカウントのみを指す
- C さん・・・顧客アカウントのみを指す
3.できるだけビジュアルで伝える
要件定義や仕様を詰めるにあたって、文字よりまずビジュアルで認識合わせすることを、とても早い段階からするといいですね。
まず同じコンテキストで話ができてない場合、
画面イメージ、シーケンス図、フローチャート、なんて言葉を使うと認識はズレます。なので何でもいいので絵で表現して擦り合せるようにしていきましょう。
私のいるプロジェクトでは、Figma,Whimsical,googleスライド,手書きの図をスクショした画像とか何でもアリで活用しています。
いやぁぁ、絵の効果は絶大です！
4.事業目標と、そこへの施策の意図を全員が理解する
事業の成長を測るうえで昨対の色々な数値目標などがあると思います。そして目標達成のための施策を計画しているかと思いますが、それらはエンジニアまで具体性もって届いてますか？
エンジニアにも 「やってることの意義」 は重要なモチベーション要素です。
スターフェスティバルで私のいるプロジェクトでは、
⭐ お弁当の売上を伸ばす
↑ 取扱商品数を増やすことで購入者様にサービスの魅力を感じてもらう
↑ お弁当製造者様が容易に商品を登録できる
↑ 商品管理機能の実装 ← 今やってること
と、事業目標や、あしもとで取り組んでいることの意義を明確に言語化していて、エンジニアメンバー各自の目標設定に組み込んでる仕組みになっています。
KPI を実行可能なアクションに分解するのって本当大変なんですが、そこを手を抜かず取り組むことって大切ですよね。
そしてこの軸がブレてないと、課題の優先度がつけ易い、やるやらの判断がし易い、メリットはたくさん出てきます。
5.これらを継続したサイクルへ
お気づきですか、前述の 1〜4 は要件定義をする上でとても重要ですよね。また、事業計画のブラッシュアップにも繋がっていきます。
課題を解決するために事業側とエンジニアが足並み揃えて動ければ、ユーザーまでも Happy な Win-Win−Win しか待ってないですね！
大事なのは、これらを継続したサイクルで回すことです。
- 半期に一度でもプロジェクト（事業）目標の目線合わせを行う
- 毎日定例ミーティング で話す時間をつくる
- 週１で優先度を見直す など
まとめ & その先に何を手に入れるか
以上のような取り組みを意識的に行うことで、こんな声が聞こえてきます
- "この改修すれば、ユーザーの利用率が 20%上がるだろうなぁ。だと売上も伸びるな"
- "これ、今優先的にやることじゃないね。リソース使う割には費用対効果低そう"
- "仕様の勘違いで手戻りが発生するようなシーンが無くなった"
- "コードの見通しが良くて機能追加が楽だ。テストも書きやすい！"
冒頭の課題がほとんど改善されていきそう！！まぁ、これだけで全て上手くいくわけではないですが、事業会社あるあるな弱点は減らせると思います。
誰が推進するかは、会社文化やプロジェクト、チームの組織形態に依ってプロダクトオーナーやプロジェクトマネージャーがメインになるかもしれませんが、メンバーエンジニアでもファシリテートしてもらってもいいですよね！
こんな文化になれば、プロジェクトに関わる全ての職種みんなで、もっと価値あるプロダクトを産めるのではないでしょうか！
以上、ありがとうございました〜 🐟
採用頑張っております
という事で、今採用活動頑張っております。
雰囲気もこの辺で感じてもらえそうです！
Discussion