スターフェスティバル株式会社 の バックエンドエンジニアの @ikkitang です。
先日、弊社のプロダクト開発部で Win Sessionが行われました。Win Sessionというのは、以下の記事で紹介されています。
要約すると、各チームからは自チームの試行錯誤・取り組みをアウトプットして、また参加者からは全力でそれを褒め称えるという自己肯定感バク上がりの社内イベントです。
今回は私(と後もう一人)がチーム代表として発表をしたのですが、その時に発表した内容をブログにも書いてみます。
自チームの取り組みの前提共有
とはいえ、自チームが何をやっているかを紹介しないとコンテキストの共有がされないので、我々のチームがどういうことをミッションとしているかについて触れておきます。
現在、自分達のチームは弊社の全業務を支えてきたアプリケーション基盤に対してのリプレイスプロジェクトとその中でも特に弊社ビジネスパートナーへの管理画面の提供を担っています。アプリケーションの"リプレイスプロジェクト"というのは"コードリファクタリング"などとは違っていて、プロジェクトの目的として現在の運用フローやデータモデリングなどの見直しまでもが含まれています。
「何のためにシステムリプレイスをするのか」ということは、以前発表にて話をているので、詳しくはこちらをご参照ください。
では、以下より本題に入っていきます。
ステークホルダーが沢山いる中でプロダクトをリリースするにあたってチームで気をつけていること
（既存の運用フローの変更など）沢山のチームにまたがったプロジェクトを前に進めていると、どうしてもリリース後に想定外の運用パターンが出がちです。そういった状況はお互いに悲しいですし、なるべく避けたいことです。我々のチームは今のチーム体制になって大体9ヶ月経っていて、リリース毎に振り返りをしているのですが、その中でチームとして意識しているリリースまでのフローが固まってきたので紹介していきます。
1: 新しく定義したモデルを日常的に使うこと
我々のチームは、既存の運用フローにも手をいれることもあれば、既存の概念を刷新した新しい概念を作ることもあります。この行為はリモデリングと呼んでいて、ヒアリングを経た上でよりしっくりくる概念を作り直感的で使いやすいシステムを作ることを目的としてやっています。このリモデリングの概念は新しい管理画面内でも使っていくので、予め慣れて頂くことでスムーズに運用へ入っていけると考えています。
そのため、開発初期にリモデリングの用語の説明を図や文字起こしなどで説明する時間を取っています。また、一度用語の説明をしたら積極的に今後のMTGでもその用語を使ってコミュニケーションを取るなども実践しています。初回は「"〇〇"、これは既存のXXXのことですが」みたいな手段を使いながら(笑)、徐々に移行していってます。カスタマーサポートの方達がSlackで普通にリモデリングした概念で会話をされ始めたら、とても嬉しいです。
2: 動くものをベースに会話すること
開発において、自チームは慎重でありつつ大胆に物事を決めていますが、ヒアリングにも重きをおいています。（この辺りは、チームのプロジェクトリーダーの記事 プロジェクトリーダーってなんだ#物腰は優雅に、行動は力強く とか読むと背景がより明るくなりそうです）
とはいえ、中々「新しい運用はどうなるのか」とかのイメージが湧ききっていない中で懸念点などのヒアリングを行うには限度があります。なので、開発の中で「動くもの」をとても大事にしています。
実践していることは、開発のマイルストーンの中に開発期間の要所要所でデモをすることを含めていることです。デモは必ずしもフロントエンド・バックエンドをつなぎこんだ状態じゃなくても良くって、動く状態であればデモとして成り立つというチームの認識があります。例えば、バックエンドはMockで良いですし、何なら画面の構成要素とかだけ出しておいてデザインもあたってなくても良かったりします。
その他にもリリース前週にシナリオテストを実践しています。これは実運用をベースにシナリオを作り、実際に機能を触る人たちとエンジニアチームとPdMの皆でロールプレイ的に画面を触っていくテストです。これをすることで実運用時のイメージを固めることが期待できます。
3: リリース日は早めに決めること
これは一番勇気がいることなのですが、開発マイルストーンを引くタイミングでリリース日もすり合わせをして確定するようにしています。これには背景があって、我々のチームが開発をするものは、社内のチームの日々の運用に対して影響を与えるものになりがちです。 そのため、「移行時期はいつからなのか」というのはとても気にされることですし、運用移行のための共有会もあるので「開発終わったのでリリースします」というわけにも中々いきません。
そのため、開発完了目安に受け入れ期間、先述のシナリオテストや社内共有会などのスケジュールを考慮した上でリリース日を早めに目安日としてチームで明言するようにしました。
一人のエンジニアとしては、「何かあるに決まっているので、3月下旬ぐらいです」と言いたい気持ちはあるんですが、あくまで目安日を決めてそれに向かって皆で動いていくという点でチーム目標として捉えています。また、このリリース日を決めることは、リリースまでに何が発生するのかという視点が増えるので、視点が「開発完了させる」に終始しなくてよいなというメリットがあると最近感じています。（例えば、この期間に社内周知のための仕様書を書いたりできますね）
まとめ
上記をまとめると、以下の図になります。
Win Sessionで発表したことでチームの Ryosuke Kida さんからも「今日の朝回でデモさせてもらっていいですか〜！」という動きがありました。デモ駆動は「動いている！！」「良いですね」とポジティブなフィードバックになるので、開発チームの雰囲気も良さそうです。
できることをしっかりやって、開発をスムーズにまわしていきたいですね。
採用PR
弊社は、現在採用活動を頑張っております。
もしこの記事を読んで「一緒に働いてみたい」や「他のチームの話も聞いてみたい」などありましたら、カジュアル面談からやっておりますので、下のリンクからご応募ください！
（私もエンジニア兼採用担当としてやっていますので、希望があればカジュアル面談、私でもお受けできますw）
それではご一読くださりありがとうございました。
Discussion