エンジニアでもビジュアルでコラボレーションせよ　GoodpatchのUXエンジニアが教えるチームの認識を揃える方法

クラウド型ワークスペースの開発に関わるUXエンジニア

黄兪維氏（以下、黄）：今回は「フロントエンド視点からのビジュアルコラボレーション」について共有します。

発表のアジェンダについて。まずは自己紹介。次にGoodpatchによくあるWHYからの理論を説明しつつ、最後に結果とまとめをお伝えします。

それでは自己紹介から。僕の名前は黄兪維と言います。GoodpatchのProduct DivのUXエンジニアです。台湾出身で、前職は台湾のWeb制作会社でインタラクションデザイナーとして働いていました。現在は、Goodpatchのフロントエンジニアとして、Strapというクラウド型ワークスペースの開発をしています。

WHY: どうしてエンジニアもビジュアルコラボレーションするのか

では、WHYのところの説明を。ビジュアルコラボレーションについて「どうしてエンジニアもビジュアルコラボレーションをするのか」、そんな疑問があるかと思います。ビジュアルコラボレーションはデザイナーがする仕事のイメージがありませんか？

まずは、ビジュアルコラボレーションとはいったい何？　というところから説明したいと思います。ビジュアルコラボレーションは、ビジュアルとコラボレーションの2つのワードに分けることが可能です。コラボレーションは目標で、ビジュアルは手段。つまりビジュアルという手段を使って、コラボレーションするという目標を達成します。

コラボレーションとは、複数の人が作業する場所に関係なく協力して、共通のビジネス目標を達成することです。例を出して説明します。Aさん、Bさん、Cさんがいて、各個人の頭の中の認識、メンタルモデルを共有して、全員が合意して作業をすることです。

次に、コラボレーションする際、フロントエンドエンジニアがどう関わっていくか説明します。対象者も多く、QAやPM、デザイナー、もちろん他のエンジニアも含めて、一緒にコラボレーションすることが多いのではないでしょうか。

Strapチームの場合、実はスクラムイベントを使っていて、実装前にきちんと機能についての見積もりをしています。

皆さんは、実装する前に課題が浮き彫りになったりしませんか？　例えば、開発の複雑さを他人に伝えにくい。その見積もりが、できるかどうかの問題だけではなく、自分が実装する機能を詳細に説明できるか。そして開発単位の認識のズレ、チームのメンバーが同じ認識をもっているかなどです。

デザイナーが工数を聞いていて「あれ？　そんなに時間がかかりますか？」、PMからは「機能についての全体像が見えないので、スケジュール的に大丈夫か？」みたいな心配ですね。実装中の場合は、自分が開発をしていて、その見積もりが漏れたり、ロジックの説明が難しくてレビュアーの負担になることも考えられます。

僕自身も経験があり、開発をしてみて、前の見積もりが漏れたりすることがあって、予想以上の時間がかかる。他にもレビュアーはロジックを理解することが難しく、レビューにすごく時間をかけてしまったこともありました。

実装が終わった時点で、開発のナレッジを溜められておらず、どこにあるのかわからない。新規機能を追加するのは、前の開発のロジックが残っていないので継続しにくい。など皆さんも経験があるのではないでしょうか。実際の開発現場では、自分が開発したものを他のエンジニアに引き継いで新機能を追加しますが、なんでこう書いたのか、データだけを見てもあまりわからない、というシーンがあります。

そして他のエンジニアだけでなく、10年後など、未来の自分が改めて見て「あれ？　誰が書いたっけ？」、GitHubのBlameを見ると「あれ？　自分か作業したのか」と気づき、自分でもなんでこう書いたのかあまりわからないこともあります。

これについては、認識のズレが問題かなと思います。自分はその機能について目標をきちんと理解している。しかし本当は、他のチームメンバーや他のエンジニアも含めて、同じ認識をもって進むことが重要かなと思います。

HOW: どうやって解決するのか

ではその課題をどう解決するのか。認識のズレなので、まずはお互いの認識を合わせることが大事です。Strapチームの認識の合わせ方は、見積もりや開発のリスクを早い段階で減らすために開発のプランニングをしっかりと行っています。例えば大きい規模や必要な要件を深く理解する必要がある場合。その際は、見積もりの精度が上げられるプランニングを実施しています。

Strapチームはスクラムを使っているので、スパイクという方法でチームメンバーとプランニングすることが多いです。

では開発のプランニングをどうするのかと言いますと、今回共有した「ビジュアルコラボレーション」というやり方を使います。先ほど説明した通り、ビジュアルという手段で、コラボレーションを達成する。「ビジュアルじゃなくてテキストでも大丈夫」と考える方もいるでしょう。今まで多くのエンジニアは、テキストでコラボレーションすることが多かったと思いますが、今回はビジュアルのやり方をオススメします。

なぜかと言いますと、人の脳でビジュアルを処理する速さは、テキストより60,000倍も速いからです。自分がそのロジックを整理するだけでなく、他の人も自分のロジックを簡単に理解できます。しかし、ビジュアルを整理する作業は、デザイナーの人たちに比べて、エンジニアにはちょっと難しいかもしれません。

ここで、ビジュアルコラボレーションを簡単にする方法を紹介します。CMになるかもしれませんが、非デザイナーでもきれいに簡単に整理できるワークスペースStrapがサポートしています。ぜひ使ってみてください。

WHAT: 実際にビジュアルコラボレーションをどのように活用したのか

ビジュアルコラボレーションで開発すると、実際にどう解決できるのか。「実際にビジュアルコラボレーションをどのように活用したのか」を説明させてください。

Strapはフローチャートに重きを置いて開発をしていて、フローチャートにはコネクター機能が入っています。

コネクターとはいったい何のことでしょうか。それはエレメントとエレメントをつなぐ線のことです。モノとモノをつなぐだけだと、簡単そうに見えますよね。僕も最初はそう思っていました。

じゃあ実際にどういう機能が入っているのか。実はコネクターには、直線と折れ線の2つのタイプがあります。直線タイプは、ご存知の通りフローチャートを描くのに必要なもの。折れ線タイプは、いろいろな角度でフローチャートが描けるようになります。

さらにコネクターの中にも6つほど機能があります。まずはマウスで自由に描けること。Strapにはツールバーがあって、コネクターを押すことで自由にボードのところに描けるようになります。2つ目は、折れ線タイプの場合は自由に中間点を追加可能です。

そして3つ目は、つないでいるエレメントを移動したらコネクターも付いてくること。例えばエレメントBを動かしたら、移動したところに付いてきます。4つ目は、終点も自由に移動可能なことです。5つ目は、終点を自由に移動したら別のエレメントにつながることです。最後の6つ目は、コネクターのタイプを折れ線タイプと直線タイプ、お互いに切り替えることが可能なことです。

今まではコネクターの機能紹介でしたが、次は実際に実装する方法についてお話しします。Strapの前身、まだOrcaというコードネームの時代に、僕はコネクターの実装を担当していました。当時はホワイトボードで、実装のやり方について、いくつかの質問と答えを図にして描いたんですね。

内容が難しく、最初はあまり理解できていなくて。当時の開発の見積もりが漏れたりとか見えていない部分もあり、その複雑さをきちんとチームのメンバーに伝えられていませんでした。

結果、開発したコネクターは拡張性がすごく悪いもので、今回Strapで改めて開発する際は、メンバー間の認識を合わせて、コラボレーションしてプランニングをしています。

実際に、Strapはエレメントで共通のデータがあります。今回チームメンバーとコラボレーションして、コネクターのかたちはこうなりました。propertiesのところにtypeがあって、折れ線か直線かを入れます。そして終点の1つは、ユーザーに見える終点とか間の中間軸などのデータが入っています。

それだけ聞くと、エンジニアは理解できるかもしれません。ただ、これだけだと、お互いの認識のズレが発生するリスクもあります。また、エンジニア以外がこれだけ見てもわからない可能性もあるので、わかりやすく図にしてみました。

実際にユーザーが見れる終点と本当の終点は図から見ることができます。この間にはy軸、x軸、y軸などの軸があります。これを移動したら、コネクターも付いてきます。でもこれだけだと、コネクターについての理解ができるかもしれませんが、ロジックの複雑さはまだわかりません。

そこで開発ロジックも図化してみました。直線の場合は、propertiesの裏側に最初は相対座標で、その後計算しやすくするために絶対座標に変わりました。そして実際にその線と線をつなぐバーチャル線を計算。これが終わってから、エレメントと線の交差点を計算する流れです。

直線の場合は、バーチャルの中間点をまだサポートしていないので、いったんスキップします。最後に、計算した座標を使って新しいサイズを更新。そして、相対座標に戻す……というのが直線の描き方です。

折れ線の場合は同じく最初は相対座標、そして絶対座標に変わって、このx、yの軸を作ってからバーチャル線を描きます。作ったバーチャル線で交差点を計算して、中間点を計算します。そのあとは直線と同じく、新しいサイズを計算すれば、すべてが相対座標に変わります。この流れを図にしたら、エンジニア以外のメンバーでも簡単にわかると思いますよね。

実際にこの図は、開発のほうにもこのまま使えます。Strapの開発についてはまず、KISSの原則を守っていて、シンプルで愚鈍にする。そして2番目は目的によってその関数の組み合わせがしやすいようにします。

実際にどういう関数が存在するのか？　さっきの流れと同じように、まずコネクターのデータを下にパースして、絶対座標に変えてからもう1回軸を計算します。そして同じくパースしてVisiblePointsを記載する。ここでは交差点のところを計算して、きちんと取ります。そして同じくパースして、サイズを計算して、最後に相対座標に変わります。

これは関数だけですよね。ではどうやって目的によって組み合わせるのか。Strapチームの場合は、composeというやり方を使います。Drawingの場合はconnectorをもらって、下から上まで計算をして、最後に更新したconnectorを戻す。編集も、組み合わせる関数が少し変わったりすることがありますが、エレメントを移動してコネクターと一緒に更新することもできます。

実は、ここの流れと上の流れは1対1です。レビュアーに対してもデザイナーに対しても、簡単でわかりやすくなるのではないでしょうか。

実際にコネクターはどうなるのかデモで動かしてみます。まずはコネクターの線を書く。これだけではなくて、StrapにはSmart Addというボタンがあり、押すとコネクターをつなげることも可能です。そして、エレメントを移動したらコネクターも付いてきます。編集で、タイプを切り替えることも簡単にできます。

ビジュアルコラボレーションで得られる効果

この実装や図化の結果によってどんな効果があるのか？　チーム全体だと開発しているエンジニアだけではなく、QAや他のチームメンバーも、実装に対して目標への理解を揃えることができます。

また、個々に対して思考の整理が簡単にできるので、個人の負担が減らせます。そしてチームに対して開発課題の理解ができ、より認識をすり合わせることができます。他にも組織に対して開発のナレッジを溜められて資産になる。こんな効果もあります。

では、最後にまとめを。僕はビジュアルコラボレーションは、デザイナーだけの仕事とは思っていません。エンジニアも積極的にコラボレーションして、共通の認識を合わせる必要があると思います。リスクを早い段階で減らすために、見積もり精度を上げるには、ビジュアルでの開発プランニングがオススメです。

僕の共有は以上になります。ありがとうございました。