トレタ開発者ブログ

飲食店向け予約/顧客台帳サービス「トレタ」、モバイルオーダー「トレタO/X」などを運営するトレタの開発メンバーによるブログです。

優秀なデザイナーが上流工程に加わると開発が捗る話

こんにちは、何がなんでもアドベントカレンダーを埋めようとしている鄧(でん)です。

Data is a precious thing and will last longer than the systems themselves.

-- Tim Berners-Lee

今日はトレタのエンジニアとデザイナーの連携についてお話させてください。

ちょっと前までのトレタでは主にデザイナーが顧客にヒアリングした上でユースケースを整理し、ワイヤーフレームを作ります。そこからよくも悪くもワイヤフレームが仕様書となり、そこからフロントエンドエンジニアに渡され、フロントエンジニアはワイヤーフレームと API の間に板挟みになって、どう API につなげるか、API が足りない場合は DB のどの項目をどう API に反映させるかのすり合わせが始まりますが、お世辞でも効率がいいとは言えません。

そこで新しいサービスとして O/X を設計した際には流れを逆転させ、まずはデザイナーとエンジニア(~= サーバーサイドエンジニア)が長期的な運用を意識しつつ、お客さんの課題を理解し、ソリューションと共通の言語(~= ユビキタス言語を意識している何か)を定義してすり合わせてからフロントエンジニアに渡すやり方をチャレンジしております。

ここ際にユースケースを達成するために保存する、あるいは表示する情報を整理しますが、デザイナーは情報アーキテクチャ(Information Architecture )、エンジニアは ER モデル使います。細かい表現や制約は若干違ったりしますが、本質的には 情報を整理する と言う同じルーツを持っているので、場合によってはペアリングして設計を進めることも可能です。

デザイナーは最終的にワイヤーフレーム、エンジニアはデータモデル(例:ER 図)を作りますが、フロントエンジニアに渡す前にワイヤーフレームとデータモデルをすり合わせて抜け漏れがないかを確認します。(O/X の API は基本データモデルの CRUD が多いのでほぼそのまま適応することが可能です)

f:id:toreta-dev:20211208192455p:plain
デザインに対してのアノテーション例

具体的にはワイヤーフレームに対してデータモデルを被せてレイヤーを分かりやすくしているのですが、トレタでは figma を使うことが多いのでこのように色を使ってデータモデルの境界線を表示した上で、文字でデータモデルの項目とのマッピングを表現しております。

この際にデザイナーと同じく QA もディスカッションに入るので客さんの課題やスースケース、ワイヤーフレーム、設計意図、データモデル、API 仕様など全てを俯瞰的に把握することが可能です。

ここで優秀なデザイナーと優秀なエンジニアの共通点としてはお客さんのペインややりたいことを理解することができ、情報を整理する能力が優れており、それを言語化する能力も優れていると認識しており、そのようなメンバーが集まっているプロジェクトは居心地がいいと感じております。

さて、トレタのデザインプロセスについてエンジニア視点でお話しさせていただきましたがいかがでしょうか?もしご意見、ご指摘などがございましたらぜひお聞かせいただければと思います。

最後に宣伝

トレタでは一緒に飲食店の未来を作るデザイナーを積極募集中です!まずはカジュアルに話を聞きたい方もこちらからご応募いただけます!

corp.toreta.in

優秀な QA メンバーが上流工程に加わると開発が捗る話

こんにちは、なんとか今年のアドベントカレンダーを埋めようとしている鄧(でん)です。

今日は社内での QA メンバーの活動についてお話させてください。

今までのトレタでは 要件定義(ふんわり)→ 設計(ふんわり)→ 実装 → QA の流れでどちらかというとウォーターフォール型の開発が多かったと記憶しております。リリースはできていたのである意味ワークしていたと言えますが、QA の視点からすると

  • この画面や API はどんな課題を解決するためのものか
  • なぜその設計に至ったのか
  • 今の挙動やレスポンスは果たして当初意図した正しものなのか

など、QA メンバーのフィードバックから、コンテキストが正しくバトンタッチされていないことが多いと感じました。

改善内容

サービスの品質や保守容易性(maintainability)を担保するために QA のメンバーにお願いして以下の施策に協力していただきました。

ドキュメント整備

まずは、QA メンバーの協力を得て API シーケンスからエラーコードの整備など、暗黙知だった部分を仕様とドキュメントとして言語化しました。まだまだ、改善の余地は多い(というか伸び代しかない)のですが、API 利用者目線でも全貌が把握しやすくなりましたし、設計意図、動作確認など、テストケースを設計する際にも便利になったと認識しております。

API シーケンス図

f:id:toreta-dev:20211204101829p:plain
API シーケンス図

エラーコード一覧

f:id:toreta-dev:20211204101933p:plain
エラーコード一覧

テスト駆動

一部のサービスではコードを書く前に QA メンバーの協力を得て、テスト内容をコードより先に書く所謂テスト駆動の手法を検証してます。トレタは TypeScript、Ruby on Rails、Golang、Clojure などさまざまな言語やフレームワークを扱っております、それを QA が全て把握するのは現実的ではないと思いますが、仕様を把握した上で日本語として言語化することなら実行可能ですので、それを実際にコードを書く前に仕様書ベースですり合わせ、実装と共に担当エンジニアがテストコードとして翻訳して CI を通してことによって、毎回 QA の手を借りずとも継続的品質を担保しやすくなりました。

情報を俯瞰できる環境づくり

最後に、QA メンバーには要件定義段階から会話に参加頂き、開題と設計意図などの情報をキャッチしやすくしました。これによって QA メンバーは基本的に事後出来上がったものを渡されて「テスト作業」する作業員ではなく、課題を理解し、方針や設計などにも参加しやすくなったと考えております。

たまにはライオンの威を借りて品質の重要性、テスト容易性などに注目するように意識喚起することもあります。

f:id:toreta-dev:20211204102657p:plain
品質の重要性

最後に宣伝

トレタでは一緒に飲食店の未来を作る QA エンジニアを積極募集中です!まずはカジュアルに話を聞きたい方もこちらからご応募いただけます!

corp.toreta.in

参考資料

リモート環境下でのコミュニケーション改善へ取り組んだこと

こんにちは。エンジニアのkitagawaです。 こちらはトレタアドベントカレンダー2021 2日めの記事です。

今年はまだまだ立ち上げ時期のトレタO/Xプロジェクトでマネージャーとして、エンジニアが開発に専念できる環境づくりを多くやっていました。

今となっては全員フルリモートで働くの当たり前の状況となりましたが、 まだまだコミュニケーションが不足していたり、まだまだリモート環境とのつきあいかたを模索しているような状況です。 そんな中でコミュニケーション改善に向けて取り組んでみたことを紹介しようと思います。

決定事項を流す「決めた」チャンネル

リモート環境でのコミュニケーションは基本的にSlackとGoogle Meetで行っています。 その環境の中で課題の一つに、「共有事項がどこまでの人に伝わってるかがわからない」 という状況がありました。

よくあるケースは、

  • スレッドで議論された結論が要約されることなくふんわり終わる
  • 見逃さないようにスレッドをウォッチしているとスレッドの長さが100件を超え出してツラくなる
  • 別チャンネルで似たような議論がされている
  • Meetで話した結果が議事録として残っていない

そこでSlack新しくに「決めた」チャンネルを作りました。

このチャンネルは議論の結論をサマリーした内容を投稿するためのチャンネルです。 すべてのメンバーはとりあえずここのチャンネルを見ておけば、様々な場所で議論された結果を把握することができます。

f:id:mkitagawa-312:20211202104959p:plain

投稿フォームをワークフローで作っていますが、特定のチャンネルで「決めた」のリアクションをすると決めたチャンネルに転記する仕組みも入れているので、よりここに書き込みやすくなっています。

特に「あの時話したあれって結果どうなったんだっけ」がとても探しやすくなりました。

全体共有会を設ける

O/Xプロジェクトはそれなりの人数が関わっていて、いくつものWeekly定例であったりスタンドアップが行われています。 ただ、プロダクトオーナーから各開発メンバーまで関わる全メンバーが集まる会というのがなかったので新しく設けました。

実際に会の中で行うことは、

  • ビジネス側からの1ヶ月の振り返りと今後の営業スケジュール
  • 開発側からのリリース報告や障害報告と、今後の開発スケジュール
  • プロダクトオーナーから一言

という構成です。

この会を設けた狙いとしては、「全メンバーの目線合わせ」と「メンバーのモチベーション維持」の2つです。

  • 自分が行っているタスクはどこに寄与し、どんな効果を産むのかを理解する
  • 達成したことをメンバーのみんなで祝い労う
  • 顧客からの声やフィードバックを共有し、良かった/悪かったこと含めてメンバーに伝える

f:id:mkitagawa-312:20211202111706p:plain

開発メンバーは日々のタスクをこなしていると、新機能リリースを行ってもすぐに次のタスクに追われてしまい、 目前のタスクだけを見ていて視野が狭まったり、徐々にモチベーションが下がったりしてしまうものです。 メンバーの上から下までそれぞれがやってきたことをちゃんと皆で振り返る、というのはとても効果があったと感じています。

オンラインランチ会を開催

リモート環境でよく聞く問題として、雑談が減ったというのがあると思います。 トレタでもリモートになる前までは会社にカウンターがあり、そこで行われた雑談からいろいろなアイデアがでたり部署をまたいだコミュニケーションが行われていました。 雑談が減ったことで、特に問題だと思ったのが新入社員へのケアです。

新入社員には大体の場合メンターがつくのですが、メンターとのコミュニケーションはあっても、同じチーム以外の人や定例で会う人以外は接点があまりないです。 雑談の会を今までいろいろと試してみましたが、

  • 雑談する時間を業務中にとっても、業務の方を優先してしまう
  • いざ雑談するとなってもかしこまってしまう

という理由でなかなか定着しませんでした。 そこで今回はランチ休憩の時間を使って、オンラインでみんなでランチを行う取り組みを行いました。 そもそも出社していた時代では新入社員が入った時は社内にいる人たちでランチに行くのが恒例だったのでそこからの着想です。

やることはシンプルで、決まった時間にバーチャルオフィスに集まって、ご飯食べながら雑談するだけのスタイルです。 f:id:mkitagawa-312:20211202112322p:plain

開催ごとに参加人数は減ってきてはいますが、ある程度の人数が定着したので成功だったかなと思います。 技術的な話だったり、最近何買ったとか、やっぱり他愛もない会話する時間って楽しいですよね。

詳細についてはこちらでも記事にしていただきました。 note.com

さいごに宣伝

トレタではエンジニアを積極募集中です!まずはカジュアルに話を聞きたい方もこちらからご応募いただけます! www.wantedly.com

© Toreta, Inc.

Powered by Hatena Blog