🤩

早期に失敗して、変更を歓迎する

に公開

法人・団体専用のパーティー会場検索サイト「会場ベストサーチ」を運用する株式会社アイデアログの取締役CTOの松川と申します。

前回(初回)「会場ベストサーチ開発チームのテックブログはじめます」というタイトルで、僕たちのチームの紹介を致しました。
色々な人の反響・・は始めたばかりなので当然ないのですが、社内の別プロダクトのチームからの反響がよくて、自分のところでもやってみたい!との声が聞こえてきたのは期待していなかった嬉しい反響でした。

前回の記事の中で、僕たちの「開発チームのMVV」を紹介させていただいたのですが、その中で社内で評判がよく、開発チームのみんなも、私自身も気に入っているバリュー(大事にしたい価値観)を掘り下げて紹介したいと思います。

「早期に検証して、早期に失敗して、変更を歓迎する」というバリューはなぜ生まれたのか

背景

2024年に僕たちは新しいプロダクトを生み出す必要がありました。僕たちが日々開発・運用する「会場ベストサーチ」は宴会場・会議室を利用したいユーザー様が、当社サイトに掲載いただいている施設様を検索し、希望条件を入力して問合せができるサイトです。
他のレストラン予約サイトと異なる点は大人数の利用が多く、それに伴い利用金額も大きくなる傾向にあります。また、イベント開催にあたり設備や当日の進行などの打合せが伴う場合があり、サイト上でぽちっと即時予約・決済するには適さないケースが少なくありません。
解決されるべき課題はいくつかあり、その1つとしては繁忙期で施設様がフル稼働の日程に、当社サイトからお問い合わせが届くことにより、そのご対応をお願いすることで施設様側の事務対応の負担を上げてしまっている問題がありました。
「宴会業界をDXする」というミッションを事業として掲げているのですが、何とかこの状況を改善する必要があったわけです。

そこで当業界では前例のない、大規模宴会場を想定した稼働状況管理(予約台帳システム)とWebサイトで稼働状況を公開表示する新プロダクトを開発することになります。
既に予約台帳を導入済みのお客様やシステム未導入のお客様など様々なユースケースが想定される中で、システム要件として正解が見えづらい状況で開発プロジェクトをスタートする必要がありました。

誕生のエピソード

そのような状況で成功確率を上げるために僕たちはスクラム開発の手法を導入することにしました。

結論から申し上げますと、この取り組みが僕たちにはうまくフィットして、「動くもの」でレビューを重ね、ああでもない、こうでもないという議論を繰り返しながら評価版の完成に至りました。

完成した評価版は一部のお客様のご協力も頂き、試験運用を重ねブラッシュアップを行い、現在では広くお客様に導入のご提案ができるようになりました。

この一連のプロジェクトの進行時に、開発メンバーで当時テックリードを担当していたメンバーから

  • 開発要件提示して開発依頼する人も動いているもので見ないと気づけないことがある

  • その一方で一生懸命に開発したものが作り直しとなることは気持ちのいいことではない
    という開発を経験した方であればおそらくは経験したことがあるのではないかというジレンマというかストレスのようなものを指し示したうえで、

  • 動くものを見て「やっぱり・・」という指摘や要望は「プロダクトが良い方向に1歩進んだ」ということになるので、喜ばしいことと考えましょう!声に出して「ありがとうございます!」と言う様にしよう

という提案をしてくれました。私にはない発想だったのでかなり衝撃を受けたのは記憶していますが、面白い、と思ったので提案を採用してチームのルールにしてみることにしました。

実際に運用してみてわかったこと

早速次のスプリントレビューの際に依頼者(当社の社長)から「ここは実際に画面を見てみて気づいたけど、こういう風にしたほうが使いやすそう。私が作った資料と違って申し訳ないですけど・・」(詳細は覚えていませんw)という意見がでました。
一般的には「えーマジでー?」「依頼の段階でちゃんと検討してくれてたの?」「作り直すにはこれくらい工数がかかりまして・・」といった方向になりやすいシーンです。

そこで出た第一声が「ありがとうございます!」

となりました。

正直なところ、最初は少し無理して言っている様子も見られましたが、この一言で「そうか、先日こういうルールになってたな」という雰囲気が生まれ、場が和んで変更に前向きな論調で会議が進みました。

言葉って大事なんだな、と思いました。

「少し違和感がある」という印象も初めはありましたが、今ではこの取り組みを導入してよかったと実感しています。日々の業務の中で、つい「また変更ですか」といった反応をしそうになることもありますが、その都度自分自身の姿勢を見直すきっかけにもなっています。

今後の展望

このような取り組みが社内でも評判になってくれて、昨年は社内で表彰される結果となりました。この時はうれしかったです。

また、現場の開発体験から生まれた一つの価値観となったので、「バリュー」の1つとして正式に掲げることにしました。

僕たちの進めるスクラム開発はその理論から外れているところもあり、丸っと型にはまっているわけでもありません。完全に型にはまるのがよいのか、自分たちなりにカスタムするのか、とは言っても手戻りを最小にする努力はすべきだし、であれば、シーンによって使い分けるのがいいのかなどなど・・
日々迷いや悩みは尽きません。立ち止まっても答えが出ないようなので、走りながら改善していきたいと思っています。

この記事を書いた人

この記事を書いた人 アイデアログ 取締役CTO 松川徹

Discussion