当社が提供する「そうぞくドットコム不動産」のWeb画面は、9月の初旬のリリースでUIをリニューアルし、UXを大きく向上させました。

今回の記事では、当社の開発チームがどんなふうに働いているか知っていただくために、このプロジェクトをどう進めてきたかを振り返っていきます。

• なぜ今、UI/UXの大改修に投資したのか？
• 副業エンジニア、副業デザイナーさんと視座を合わせる工夫とは？

など、このプロジェクトを通して得られた知見を詰めましたので、ぜひ最後までお付き合いください。特に、同じようなフェーズで戦っているエンジニア、デザイナー、PjM/PdMの皆さんに楽しんでいただけたら幸いです。

きっと「もっとうまいことやれるよ」と思う箇所があるでしょう。そんな方は、是非私たちと一緒にもっとうまく仕事をしていきましょう。

なぜ今やることにしたの？

これからの拡張に備えるUIリニューアル

「xxリニューアル」系のプロジェクトは往々にして要件が爆発しがちです。
そのリスクを負ってまで、私たちがこのタイミングでUIリニューアルを進めたのには、いくつかの理由があります。

開発チームの急拡大を前に、滑り込みで掃除ができるのは今だけ

シリーズAの資金調達を終え、私たちの開発チームはこれから今までにないペースで拡大する事が確定していました。それにも関わらず私たちのプロダクトには、何度も大きなドメイン知識のアップデートと大規模なリファクタリングが繰り返されてきたため、設計方針が一貫しておらず読み解きにくい箇所が発生し始めていました。

この事を根拠に、今後も生産性を保てるようサービスの全体像を見直し、コードリーディングの障害を取り除く必要があると判断しました。

プロダクトの急拡大を前に、このままでは余白が足りなかった

これまでの私たちのプロダクト開発の優先順位は、何よりもまずお客様に使っていただける機能をリリースすることでした。そしてその哲学に従ってプロジェクトを選んできた結果、非常に拡張性に乏しいUI設計がまかり通ってしまっていました。
たとえば、ほとんどすべての画面は不動産手続き用に特化されていました。もしこのまま他手続きに対応することになれば、かなり大規模な修正が必要になったでしょう。

これは明らかに、シード期の意思決定のトレードオフです。しかしシリーズAを迎え、相続手続き市場の様々な課題を解決するプロダクトを投下していく予定の私たちにとっては、この負債は今後クリティカルな課題になると予想されました。

ストイックなMinimum Viable Productでありすぎた

私たちは「PMFを迎えるまでは最小工数で進める」と意思決定していたため、フルコミットで関わるデザイナーも不在の状態でサービス開発を進めていました。その結果、私たちのプロダクトは普通のWebシステムなら当然あるような機能さえ整っていませんでした。
たとえば、同じ一覧系の画面でもボタンの位置がバラバラだったり、画面によってはメニューが表示されなかったりしていたのです。

市場に自分たちのプロダクトの要否を問うフェーズであれば、そんな事は些細な問題です。しかし、お客様の数もオペレーション組織も拡大していく今の段階でも、このような負債を引きずり続けることは、社内外にとって、プロダクトの学習コストを膨らませ続けてしまいます。

どうやって進めたの？

プロジェクトは、私と新納さんの2名の創業メンバーを中心に、副業エンジニア2名、副業デザイナー2名の6名チームで進めました。小さなプロダクトとはいえ、大きめの改修にチャレンジし、開発チームを成熟させる良い機会になりました。

プロジェクトは大きく

1. ゴールの整理
2. ワイヤーフレームの作成
3. UIデザイン
4. 実装
5. オンボーディングとリリース

という流れで進めました。これ自体は比較的よくある進め方だと思います。しかしメンバー構成や会社の状況から、様々な知見を得ながら進行することができました。
ここからは、プロジェクトを通して得た学びを整理していきます。

業務理解度の差を埋めるコツ

シード期のスタートアップではよくある事ですが、CEOの塩原さん含め創業メンバーは全員、お客様からの問い合わせ対応や郵便局での発送業務など、プロダクトのすべての業務フローを自分たちで回してきた経験があります。全員が細かなロジックを体で理解しているため、「一を聞いて十を知る」が当たり前に実践されてしまっていました。
その結果、このプロジェクトを始めた時点で私たちの手元には、業務フローが分かるドキュメントはおろか、画面一覧やデータモデルの設計書も一切存在しませんでした。

一方で副業メンバーは、もちろんプロフェッショナルではありますが、フルリモートで本業の傍ら私たちをサポートしてくれる人です。あらかじめいくつかの小粒な改修に取り組んでシステムに慣れてもらってはいましたが、創業メンバーとの間には非常に大きな業務理解度のギャップがありました。

私たちは、この課題を解決するために2つのことに意識して取り組みました。

1点目は、オンボーディングのPDCAを回すことです。

新たなチームメンバーと視座を合わせる上でまず大切だったことは「一度で伝えきることができる」という幻想を捨てることでした。そして行ったのが、時間を置いて何度もインタラクティブにオンボーディングを重ねることです。

具体的には、まずはパンフレットなどのお客様に提供している情報を一通り読み込んでもらい、サービス内容について初歩的な知識をつけてもらいました。その上で「なぜやるのか」「何ができればゴールか」といったプロジェクトの概要を伝え、システムの現状を自分で確認してもらいました。
そしてさらに別の日に、調査してもらった現状を踏まえ、業務フローを適当な粗さに分類して共有しました。

しかし、どんなに小さなプロダクトでもこの程度では全体像の理解は進みません。そこで、作業の進捗や成果物の質を随時確認し、課題を見つけ次第追加のオンボーディングを企画し知識の穴を埋める方式を取りました。
これにより、俯瞰した全体像から始まり、作業内容に応じてズームをしていくオンボーディングを行うことができました。

2点目は、オンボーディングする範囲を可能な限り狭めることです。

創業メンバー視点では、良くも悪くもプロダクトが自己と同一化してしまっているので、新しく手伝ってくれるメンバーに対して、何をどの程度の解像度で話せば伝わるのか、わからなくなっていました。その結果、過度に前提を遡ってしまったり、逆に重箱の隅をつつく業務ルールの話をし続けてしまう問題が発生しました。

これを解決したのは、ベタですが既存の機能一覧をスプレッドシートに整理したことでした。機能一覧の本来の用途は「全体像が分かること」や「作業量の見通しが立つこと」だと思いますが、私たちにとって有益だったのは思考のスコープを狭められることでした。
作業を機能ごとに分割することで、メンバーごとにオンボーディングすべき内容を事前に予測でき、情報量と解像度を調整することができました。

思えば自分たちも、今となっては様々な知識が脳内に同居していますが、最初は必要に応じて専門家から学んできました。同じような作業を、意図して新規メンバーに体験してもらう流れを作れたことが、業務理解を促進する鍵になったと考えています。

同期/非同期コミュニケーションの使い分け

チームで取り組むタスクのリスクは、投下した時間に対して得られる成果がどの程度確実かという観点で見積もることができます。
たとえば、一度作ったことのある機能を少しアレンジして別の機能を作るのであれば、かけた時間に対してほぼ確実に一定の成果が得られるでしょう。しかし、そもそも何を作るか決まっていない場合は、時間をかけたからといって成果が得られるとは限りません。
フルリモートで、かつ本業の定時時間外に稼働してくれるメンバーと円滑にタスクを消化していくためには、リスクに応じて適切なコミュニケーション手段を選択することが有効でした。

代表的な例では、最初の1画面をデザインする時には、創業メンバー2名とデザイナー2名が集まって、モブデザインを行いました。関係者が集まって作業を行うことで、要件や成果物の品質がブレるリスクを避け、その後の作業方針への悩みが減りました。
一方で、一度方針が固まってしまえば残りの作業は、かけた時間に対して一定の成果が期待できます。そこで、これらの作業は割当を明確化した上で非同期に進めました。

このように、リスクの高低に合わせてタスクの進め方を変えることで、チームとして成果を出し続けることができました。

ロールをまたぐ兼業を恐れない

チームを拡大していく最中のスタートアップとはいえ、私たちはまだ非常に小さな会社です。プロジェクトの進行を妨げるものはなんであれ、ロールを気にせず解消していく必要があります。
今回のプロジェクトでは、デザイン作業が想定よりも重く予定どおりに進行しないかもしれないという問題が発生しました。

しかし、上述のとおりデザイン作業は創業メンバーもモブデザイン会で体験しています。しかもコンポーネントベースで標準化されたUIデザインが整いつつある状況だったので、一部のUIのデザインはエンジニアである創業メンバーが引き取って進め、後からデザイナーのレビューを受ける形で進めました。
この決定によって、限られた時間で協力してくれている副業デザイナーのメンバーの負荷を下げ、プロジェクトの進捗を改善することができました。

このように、各自のプロフェッションに対する尊敬は持ちつつも、ロールをまたいで動くことで様々な関わり方のメンバーとプロジェクトを完遂することができました。

振り返り会で、関わり方を問わない強いチームへ

FigJamを使って、フルリモートでも活発にKPTを回せました。

このようにプロジェクトを完了した後は、KPTに則った振り返り会を実施しました。
FigJamを使って行い、エンジニアチームからは

• UIのシステムアーキテクチャをレベルアップできた
• 新しいバージョンのReactに対応できた
• ペアプロとソロ作業のバランスが悪く、最適化の余地がありそう

デザイナーチームからは

• エンジニアチームとの適切な議論を踏まえてデザインを進められた
• ペアデザインによって作業スピードを確保できた
• 次からオンボーディングの時間をもっと削減できそう

などを始めとして、多くのフィードバックが得られました！

現在も私たちの開発チームは、新しいUIをベースに各種プロジェクトを進行させ、これらの反省を活かし最適化を続けています。

最後に

AGE technologiesでは今後も、勤務地や契約形態を問わず様々なメンバーに助けてもらいながら、一流のプロダクトを世に提供していきます。

副業からジョインし、結果的に当社への転職を決意してくれるメンバーもいます。少しでも興味を持ってくださった方は、まずは一度私と話しましょう！対話の中で、適切な関係を模索していけたら嬉しいです。