コミュニケーションでプロダクトを前へ。 アジャイル開発の現場から #1: フロントエンドエンジニア & デザイナー編

SEEDS COMPANYは新プロダクト x:eee を先日公式リリースしました。
（ニュースリリース：https://www.persol-pt.co.jp/news/2019/10/29/3977/）

x:eeeは、アルバイト・パート採用の煩雑な業務をスマートフォンで
カンタンに行うことができる、業界初のスマホ特化型のスマート採用支援ツール。登録無料で、飲食店の店長様などがスキマ時間にスマホのブラウザで利用することができます。

x:eeeの開発はアジャイルで行っており、エンジニアだけでなく、デザイナーや企画職も、ひとつのアジャイルチームとしてプロダクト開発を行っています。
x:eeeリリース記念として、wantedlyにて開発現場のリアルをお伝えします。
使いやすいUI・UXを実現するために、またスピード感ある開発をすすめるために、エンジニアとデザイナーの関係性はどうあるべきか。
今回は、フロントエンドエンジニアとデザイナーによる座談会の様子をお伝えします。

福田 康夫(写真右) : x:eee フロントエンドエンジニアのリーダーとして、React.jsの設計・実装とチームマネジメントを担当。
比企 真知子(写真中央) : x:eeeのデザイナーとして、主にプロダクトのUIデザインを担当。
松本 綾香(写真左) : x:eeeのデザイナーとして、主にプロダクトの要件定義を担当。

みんなでチェックして、ツッコミが入ったらもう一度

皆さんのプロダクト開発のすすめ方を教えて下さい。

松本:
私たちが要件を決めるにあたっての流れは2つあります。

ひとつは、プロダクトオーナーの「事業をこうしたい」という想いを要件としてまとめるというもの。

もうひとつは、ユーザーの声を拾うというもの。まずユーザーインタビューを通じて仮説をつくります。次に、再度ユーザーインタビューをして仮説検証し、整理した結果でプロダクトオーナーと合意形成して、仕様に落としていきます。

デザインシステム(プロダクトで使う、ボタンなどのデザインコンポーネントを定義したもの)が2019年4月にできて、コンポーネントを組み合わせてプロトタイプやワイヤーフレームをかんたんに作れるようになりました。要件を決めるときは、ドキュメントとワイヤーフレームをプロダクトオーナー・企画・デザイナー・エンジニアのみんなで見ながら話し合いを重ね、要件を固めていきます。ドキュメントとワイヤーフレームが完成したら、UIデザイナーに渡すという流れです。

比企:
私は、松本さんから流れてきた要件をデザインしながら、足りないコンポーネント追加したり、調整したり、遷移が問題ないか考えたり、「もっと最適なUIないんだっけ?」と検討したりして、最終形にまとめます。
UIデザインも、プロダクトオーナー・企画・デザイナー・エンジニアのみんなでチェックして、ツッコミが入ったらもう一度、という流れです。みんなの合意形成ができたタイミングで、UI指示書をフロントエンドエンジニアに流していきます。

福田:
デザインの合意形成は私も参加しています。フロントエンドエンジニアの観点で「これはすごい実装が大変だ」「前に実装したアレとちょっと違うけれど、同じでは?」といったレビューをしています。

合意形成がとれて、UI指示書が流れてきたら、それをもとに実装します。動きや状態遷移は松本さんが作った要件を見て、整合性を確認しながら、デザインとあわせて作っていきます。

今知りたいことはすぐ聞いて対応できる、柔軟にできるチーム

比企:
でも、完璧じゃないんですよね、毎回(笑)

福田:
そうですね。「この要件で問題ないか」「このデザイン指示で合ってるのか」っていうのは。

比企:
「これ検討漏れですよね」という指摘がフロントエンドから戻ってきて「あれごめんごめん」と。 そういうのがわりとフランクに言える、仲良しチーム(笑)

福田:
それが言いづらいと、すごいやりづらいので。今知りたいことは、すぐ聞いて対応できるし、柔軟にできるチームだと感じます。デザインレビューではわからなかったけれど、実装してみて「やっぱりおかしいんじゃない?」というのが、どうしても出てくる。そのときにならないとわからないので、都度柔軟にやることができています。

比企:
以前は「要件定義の段階で完璧にしなければいけないんだ」という勝手な思い込みがあって。詳細な要件まで詰めるのに、すごく時間をかけていたんです。でも今は「詳細まで詰める必要はないな」と。結局検討漏れはどうしても出てくるので、「ざっくり作って、検討漏れがあったら戻す」という方法にシフトしています。

「タスクの重さ軽さ」の感覚が全然違うから、すごい話していきたいなって

デザインのときにはわからなかった非機能面(アニメーションやサクサク感など)の要件が出てくると思います。非機能要件に対応するために工夫している点はありますか?

福田:
エンジニア同士でレビューしているので、その時に直すこともあります。ただ、すり抜けちゃうこともあるんです。人なので。

そこからはもう、いったん作りきってから、ですね。テストで触ってもらって、動作がカクカクしているんだったら、ソースコードベースで確認して直していく。よくあるパフォーマンスチューニングのプロセスと同じだと思っています。

松本:
最近は、スケジュールとスコープの制約がきつかったので、UX的にそこまで快適さにこだわるレベルまでは突き詰められていないです。今は最低限なのかなって。

UX的な快適さは、ユーザーの声が上がってきにくいところ。特にUXの細かいところをどこまで完璧な状態にするのか、気持ちいい状態にまでするのか、その作業優先度をどうするのかみたいなところは、何かとの戦いになりそうな……

今できることとしてやっているのは、たとえば動作が重い・遅い部分があったとき。ユーザーはエラーが起きているのか、何も起きていないのかわからないことがある。でも、動作速度を改善するのは、実装に時間がかかる、というケースですね。その場合は、くるくる(スピナー)を出すだけでユーザビリティが変わるので「(実装タスクとして)軽いならば、暫定対応としてやってください」とお願いしています。

比企:
デザイナーとフロントエンドエンジニアの間で「タスクの重さ軽さ」の感覚が全然違うから、すごい話していきたいなって思っています。デザインだと、スライダーをつけるのは5秒でできる。でも実装する大変さは違う。感覚が全然違うので、会話して理解していっています。

松本:
話し合って、一回「重いよ」って言われたら、「あ、実装重いんだ」って学習していく。「これはこれくらいかかるのね」「くるくる出すくらいだったらすぐにできるのね」と、一個一個お互い学習して。

松本:
「これだと重いけどこれだったらできるよ」とエンジニアから提案してくれたりするので「じゃあとりあえずそれでいきますか」って。

福田:
どんなものが大変な実装になるのかは、エンジニアじゃないとわからないので。相談して進めていっています。

ひっくり返ったとしても、開発まで影響しないように

デザインやフロントエンドは、プロダクトオーナーからの「ちゃぶ台返し」が起こりやすい領域だと思います。どう対応されていますか?

比企:
そうですね......まず、ちゃぶ台の上に載ってるものを、あまり見せない。

全員: (爆笑)

比企:
「なにも載ってないですよ」って。「ああ、まだ何も載ってないんだ」って。で、気づいたら全てセットされてる。 「これひっくり返しますか、どうですか? 大変なことが起きますけど」みたいな(笑)

福田:
フロントエンドは、ひっくり返されたら作り直すしかないですけど......

比企:
フロントまで影響することは少ないですね。ちゃぶ台返しがあるのは、要件と、デザインセンスの領域。x:eeeのプロダクトオーナーは、事業責任者と、アートディレクターの二面性を持っていて。

松本:
だからチームメンバーで、「これは事業の話だから、やらなきゃいけない」「個人の好みの話だから、耳をふさごう」と選り分けて。「それやるんだったら開発でこれくらい工数かかっちゃうから、どうします?どっちか、選んでください」といった交渉をしています。

比企:
エンジニアに「リソース的に厳しい」「開発がものすごく遅延する」と言ってもらえる形にしたり「一度出してみてユーザーの声を聞いて、やっぱよくないんだったらすぐ変えることにしましょう」と先送りにする感じ。
でも、正しいことを言われることもあるので、そこは素直に聞く。

昔は企画も交えてちゃぶ台の前に集って、ひっくり返されるのをみんなでおとなしく見てる、みたいなプロセスもあったなあ......(苦笑)
今は、必要最低限のメンバーで、合意形成をとりに行っています。なので、ひっくり返ったとしても、開発まで影響しないようにしています。

近日公開予定の第二回では、デザインツールやフレームワークにスポットをあてていきます。エンジニアとデザイナーのコミュニケーションを支えるツールの使い方とは。スピード感あるデザイン実現のための開発の工夫とは。3人の話を通じて掘り下げていきたいと思います。

=========================================================================
＼SEEDS COMPANYについてもっと知りたい！／
SEEDS COMPANYについてもっと知りたい方は、こちらからお気軽にお問い合わせください。=========================================================================