Shape Up導入でエンジニアとラフにユーザーの話をする機会が増えた
こんにちは、Shippioのプロダクトデザイナーの新行内（@singularity8888）です。
普段、コストの少ない方法で価値を出したいと思って要件やUIを考えていますが、そのためには実装してくれるエンジニアの皆さんと事前に議論できることが大切だと思っています。
最近Shippioでは1週間スプリントのスクラムをやめ、6週間の開発＋2週間のクールダウン期間（エンジニアがリファクタリングや技術研究を行う期間）という新しい開発サイクルを取り入れました。これはBasecampのShape Upという手法です。これにあたり、デザイナーとエンジニアのコミュニケーションが変化したので、今日はそれについて書いてみたいと思います。
1週間スプリント
1週間スプリントでは、エンジニアが作業に入る前に仕様書を完成させていました。仕様書はデザイナーやプロダクトマネージャーが書くもので、ユーザー側から見た機能要件やUI仕様が記述されます。
開発に入る1~2週間ほど前に仕様を作り、エンジニアとレビューをして完成させ、1週間単位の作業に分割して開発を開始します。エンジニア側でシステム構成の検討等が必要な場合も、スプリントの中で行われるケースが多かったと思います。
Shape Up
6週間の開発サイクルの中では、大きく前半がアップヒル、後半がダウンヒルと呼ばれるフェーズになります。アップヒルではエンジニアはあまりコードを書かず、既存のコードを調べて実装方法を検討したり、システム構成を決めます。デザイナーはこの時に同時進行で仕様書を書き、Figmaで画面仕様を作成します。後半のダウンヒルでは実装とQAを行い、リリースします。
6週間の開発期間に入る前には、要件やその機能が必要とされる背景をドキュメントにまとめ（ピッチと呼ばれます）、エンジニアを含むチームメンバーやマネージャーと合意をとります。
Shape Upのやり方では、この段階では「太いペンで描いたスケッチ」が良いとされているので、私たちは手書きのスケッチや表示したい情報の一覧、テキストでの説明で実現したい内容を記述しています。また、ピッチを作成する時点で6週間でリリースできそうかを検討するため、エンジニアと要件を議論したり、スコーピングを行います。
例えば先日、「シップメントをラベリングできる機能」を6週間で実装・リリースしたのですが、その時は既存のシップメント一覧に手描きで新機能部分を書き足しました。
シップメントというのは、Shippioで扱う輸入や輸出の案件のことで、ユーザーはシップメントごとに貨物の状況をトラッキングできたり、貿易書類を管理したりします。シップメントによっては他のものより重要度が高かったり、特に注視する必要があるため、このラベリング機能によって一覧の中でそういった特別なシップメントを区別できるようにしました。
（※この時点では「フラグ」と呼んでいたので、スケッチ上ではFlagと記載されています）
また、実現したい要件をテキストで説明しています。
実現したい要件は元々ユーザーストーリーの形で記述しているのですが、いくつかやりたいユーザーストーリーを挙げた上で優先度をつけています。
何がしたいのか、抽象的な状態でエンジニアと話せるようになった
Shape Upはエンジニアチームの要望で導入されたもので、1週間スプリントで「エンジニアが黙々とチケットを消費するだけになっている」「リファクタリングのような作業をやるタイミングがない」といった課題を解決する目的があります。しかし、その結果デザイナーとエンジニアのコミュニケーションにも変化がありました。
まず、要件定義の段階でエンジニアとの会話が増えたことです。1週間スプリントを行っていた時は、仕様のレビューで初めてエンジニアにやることを共有するといったケースも多かったのですが、Shape Upでは6週間で何かしらリリースすることを目指すため、エンジニアと入念に要件を確認し、スコーピングしていく必要があります。これによって仕様として固まる前の議論が増え、エンジニアに顧客やユーザーの状況を多く共有するようになりました。
また、1週間スプリントでの仕様レビューでは、綺麗に作ったFigmaの絵を見ながら説明・議論していましたが、手描きスケッチやテキストでの説明を使うことで、抽象的な状態でエンジニアと機能の優先度やコストの低い実装方法について議論できるようになりました。
実はShippioにはワイヤーフレームやスケッチを描く習慣がしばらくありませんでした。これは良くも悪くもFigmaのデザインデータがちゃんとあるからで、テンプレートやコンポーネントも用意されているので、新しい画面の絵を作る場合でもあまり時間がかからないのです。（どこの会社もたぶんそうですよね）
ですが、エンジニアからすると、たとえ細部が雑であっても綺麗な画面の絵は完成に見えるので、決まったものとして受け取るだけになってしまったり、逆に議論が細部に行きすぎてしまったりします。
ラフな段階から共有することで、エンジニア側から
なぜこの機能が必要か
ここがこうなっている必要はあるか
といった話がしやすくなったように思いますし、実際にそう感じてもらえているようです。元々Shippioのエンジニアはユーザーや事業に興味のある人が多く、そのような会話も多いのですが、よりやりやすくなったと思います。
事前にアイデア出しやトレードオフの検討は進めておく
上記のようなやり方でスムーズに進めるためには、エンジニア側の作業と同時進行で仕様・画面イメージを作成する前に、
どんなUIパターンがありうるか
トレードオフは何か
といったことを整理しておくと良いと思います。
エンジニアとの作業が始まった後は、できるだけスムーズにエンジニアと議論し、仕様を決定していく必要があります。この時にデザイナーの手が止まったり、リサーチやアイデア出しの議論をすると、不必要にエンジニアの開発期間が減ってしまうからです。
例えば、前述の「シップメントにラベリングできる機能」の検討時には、すでに情報量が多いシップメント一覧に新しい機能を追加していくことになるため、
一覧項目の情報の優先度
シップメント一覧の設計意図
を事前に確認しておきました。どちらも大したことではないのですが、今回は自分がシップメント一覧を変更するのが初めてだったので、確認しておいてよかったです。
また、新機能を追加する場所もいくつかのパターンを出して事前に少し検討しておきました。これらの準備によって、6週間の開発期間のスタートダッシュを速くできたと思います。
まとめ
開発サイクルが変わったことで、エンジニアとのコミュニケーションの仕方が変わり、最低限のコスト・機能でユーザーにとって役に立つものを作りやすくなりました。
この進め方はまだ取り入れたばかりで日々試行錯誤していますが、ラフな段階で共有すること、また見た目にも議論の余地があることがわかるようにしておくことの重要性を改めて実感しました。また、いつも話に付き合ってくれるエンジニアの皆さんにはいつも感謝しています。これからも話しやすい環境づくりは模索していきたいです。
Shippio ではプロダクトデザイナーを募集中です！記事を読んでご興味をお持ちいただいた方は以下の求人から詳細をご確認の上、ご応募ください！
この記事が気に入ったらサポートをしてみませんか？