はじめに

こんにちは、デザイナーの金子です。Ancarに来て3ヶ月が経ちました。

私の仕事はエンジニアチームとCSチームと会話してユーザーストーリーを作って優先順位を決めたり、開発出力を最大化するため課題の改善をしていたり、組織を強くするための採用を進めたりしています。

今は主にAncarのサービスのリニューアルを進めているのですが、今まで失敗したことの共有と、それに対して改善したことを実体験を元にお話できればと思います。何かのお役に立てれば幸いです。

リニューアルプロジェクトの発端

まずはじめにAncarというサービスについて少し紹介させてください。

海外では一般的な「車の個人間売買」。 しかし日本では、売りたい人→買取業者→オークション→販売店→買いたい人の流通が一般的。同じ車でも中間業者のマージンが上乗せされている状態です。

• 売りたい人は愛車を安く買い叩かれ
• 買いたい人は高く買わざるを得ない
• 車の状態は既存の流通を通すと引き継がれない

Ancarはこの負のサイクルを合理化し、中古車売買体験の健全化を目的とした個人間売買サービスです。

リニューアルは下記のような理由でエンジニアから声が上がって始まりました。

• 自分たちが掲げたミッションやビジョンにデータベースがついていけなくなったこと
• 求められる改善スピードに対応できなくなっていったこと

最初は機能や見た目は変えず、コードを変更するリファクタプロジェクトでした。

リニューアルプロジェクトでの失敗

1. 目的や経緯の説明を怠ったため、“チーム”ではなくなった

もともとエンジニアから始まったリファクタプロジェクトですが、時間が経ち介在するメンバーが増えるに連れ「ここのフローも改善したほうが良い」「どうせなら見た目も変更しよう」という意見が入り、目的が大きくなり、ぼやけていきました。

そしてそのタイミングでそれぞれのメンバーに経緯の説明をすることもなく、ズルズルとそのまま続けてしまったため、「何のためにリニューアルをするの？」に対しての答えが各々ズレ始めました。

エンジニアからしてみたら、「事業に貢献するために自分たちが改善しやすい状況を作る」という自分ごと化できる目的から「なんかよく分かんないけど上から降ってきた仕事」になってしまいました。

麻野耕司さんの著書である「THE TEAM 5つの法則」にはグループとチームの違いについてこのように書かれています。

このような単に2人以上の人間が集まって活動するだけの集団は「グループ」と呼びます。
では、グループはどうすればチームになるのか？
チームをチームたらしめる必要条件は「共通の目的」です。
~中略〜
チームという語は「tug（引っ張る）」が変化してteamになったと言われていますが、メンバーたちを引っ張る「共通の目的」があって初めてチームだと言えるでしょう。

引用: THE TEAM 5つの法則

今回このリニューアルにおいて、デザイナーやエンジニアは共通の目的を見失い、“チーム”ではなく、“グループ”になってしまいました。それは後々設計やコードで露見することになります。

2. 理想⇔現実を行き来する仕組みがなかったため、コストパフォーマンスの悪い機能を作ってしまった

私がAncarに入る前は社内にデザイナーがおらず、外部のデザイナーの方にワイヤーとデザインを起こしてデザインファイルを納品してもらい、それを元にエンジニアが開発するというフローでした。

実際開発する段階になって、実現が難しい表現や工数がかかる機能が出てきました。しかし、外部のデザイナーさんはすでにおらず、要件を詰めたメンバーも中途半端な状態で別のプロジェクトに移動してしまいました。

私は質がスピードの軸がなければ測れないように、価値はコストの軸がなければ測れないと思っています。絶対的に価値が高いと思っていても、それに対するコストが高ければ、そこそこの価値でコストが低い方が重要だったりします。つまり重要なのはコストパフォーマンスです。

要件や表現を考えるときは、いわば制約のない理想論を語ることができます。ただエンジニアが対峙するのは現実です。私はどちらも大切で、両方を行き来しながら一つの価値を作るのがコストパフォーマンスが良い機能を作れると考えています。

その行き来する仕組みがなかったため、エンジニアはデザインファイルを受け入れるしかなく、結果論としてコストパフォーマンスの悪い機能を作ってしまいました。

3. 画面単位で担当を振ってしまったことでの合流の遅れ、そしてバグと呼ばれる

そんなこんなでデザインファイルを元に開発を進めることになりました。デザインファイルは画面ごとに作られていました。当然のように画面ごとに実装の担当を振っていくことになります。そこでの大きな失敗は、ユーザーが見る画面とCSチームが操作する管理画面でチームを分けたことです。

チームを分けると限定合理性が発生し、管理画面チームとユーザー側チームはそれぞれ別々の優先順位を持つことになります。例えば管理画面のフラグを立てるとユーザー側のある機能が使えるようになるという機能を考えたときに、管理画面チームとユーザー側画面チームの優先順位がずれるといつまで経っても機能として成り立ちません。また管理画面チームとユーザー側画面チームのコミュニケーションも不十分なままでした。

人間は他人が言っていることを100%同じように理解することはできません。「認識違い」が発生するのは当たり前です。本質は同じはずなのにその発見が遅れると「バグ」と呼ばれるものになります。合流したタイミングではコミュニケーションを取れてなかった分「バグ」という形になって返ってきました。

改善のアクション

1. 目的の共有の実施

まずチームとしてワークするためには、共通の目的が必要です。

そこで、まず目的を揃えるためにエンジニアとCSチームや社内のメンバーでビジョンやミッションを元に現状の課題やプロダクトに関する要望を話し合う会を実施しました。

そこで発散した話などを簡単にコンセプトに落とし込み、その情報をいつでも参照できる場所においておきました。

▼コンセプト例

またエンジニアチーム内で1週間ごとの振り返りをするようにしました。目的は1週間の成果を皆で称え合うことと、目的に対して改善アクションを打てるようにすることです。

KPT法でやっているのですが、Problemについてはチームで解決できるものにフォーカスして上げてもらうようにしました。自分たちのコントロールが効く範囲での改善を重ねたことにより、よりチームとしてワークするようになったと思います。

実際にProblemで上がった「実装の属人化」という問題について、ペアプロを行うというTryを実施しました。

2. エンジニアと話す仕組みを作る

エンジニアと、要件を決めるビジネスサイドでコミュニケーションを取る機会がなかったため、要件を詰めるときにエンジニアに見積もりと実現可能性を相談する時間を設けることにしました。

そこで「なぜ作るのか？」をエンジニアに共有し、また「何を作るのか？」に関してエンジニアから提案してもらうこともありました。そこで決まった内容をissueにまとめておきました。

3. 週次で開発した機能の共有

早く「認識の違い」を出すために、週次で開発した機能を社内で共有をするようにしました。今まではデザインファイルだけで判断していたことが実際に動くものを見ることによって、「認識の違い」を早めに見つけ出すことができます。

また開発した機能を共有してFBをもらうことで、エンジニアチームのモチベーションアップに繋がったのではないかと思います。

今後は機能（価値）ごとにユーザーストーリーを作り、職種を超えて一つの価値を作るようなプロセスに変更していきたいと考えています。

さいごに

お気づきいただけたと思いますが、今でもリニューアルプロジェクトは続いており、日々チームで戦っています。今後は一旦体制を立て直し、「チームとして強くなる」 かつ 「なるべく早くユーザーに価値を届ける」両方を取れるようなプロセスや体制を検討していきたいと思っています。
そんな経緯から一緒に戦ってくれる仲間を探しています。まだまだ未熟なチームですが、一歩一歩進化していきます。

興味がある方いたら、ぜひ気軽に遊びに来てください〜！