これはフロントエンドエンジニア Advent Calendar 2016 21日目の記事です。
エンジニア・デザイナー間の協業の話は、2016年に盛り上がる話題のうちの１つだったと思いますが、フロントエンドエンジニアのAdventCalendarなのでそれに習って自分の考えをまとめてみました！
こんな分業体制でプロジェクトに臨めたら、開発は効率化されないかなぁ〜！という妄想が多分に含まれます。
ただ必要なスキルセットはきっと高めなので、実践できる環境は選ぶかも…？ いや、やりましょう・・・！
フロントエンドエンジニア
プロトタイプ構築
フロントエンドエンジニアの強みの一つは、とにかく「すぐに動かせること」。
これはプロトタイプ駆動においてはとても重要なことかと思います。
コードの品質なんてとりあえず後回しでいいから、とにかく動くものを今すぐつくろう！早さは武器だ！
ビルド設計
綺麗なモジュール化がされていれば、後から手を加えるのは簡単です。
色んな方面・要素からの要望を聞き入れる必要がある、Webフロントエンドではここも重要な項目の１つです。
なるべくロジカルな解決法で設計しましょう。
コンポーネント組み込み
デザイナーが作成したコンポーネントを実際のアプリケーションへ組み込みます。
このタイミングで、コンポーネントへいろいろなイベントを付加していきます。
ただし一度フロントエンドエンジニアが手を入れてしまったコンポーネントが、デザイナーが触れなくならないように気をつけること。
なるべく難しい処理は隠蔽したり、キチンと外部メソッド化することでコードの読みやすさの維持に努めましょう。フロントエンドエンジニアの腕の見せ所です。
サーバサイド・インフラエンジニアとCIを構築
とにかくコミットしたコードを素早く提供する仕組みづくりに徹すること。
デプロイサーバなどの環境に依存する話もでてくるため、そちらのエンジニアと密な連携をとります。
少しでも必要な手順を減らすこと。
テストコードが走ることが、最低条件です。
デザイナー
プロトタイプ設計
「なにをプロトタイプとしてつくるのか」「一番最初に抑えるべきことはなにか」
デザイナーは、エンジニアに比べて抽象的な部分をみる必要があります。
また、このプロトタイプによって何を得て、何を次のプロトタイプへ活かすかも考えましょう。
カラー設計
これは単純です。
サービスやアプリケーションに使う色を決めます。
当たり前の話ですが、どの色を使うかはすべて理論的に説明できること。そして、無闇に色を増やすことは無能なデザイナーであることです。
意見は必ずデザイナー以外にも求めましょう。
その意見を取り入れるかどうかは、デザイナーが判断しましょう。
コンポーネント構築
これはコーディングを指します。
デザイナーがReactやVueの「コンポーネント」という概念を理解することは、アプリケーションの品質向上に大きく寄与します。
サービスの寿命を延ばし、デプロイサイクルを高め、デザイナーのやりたい事を実現させやすい環境になります。
怖がらなくていいです。あなたが作ったコンポーネントは、プロがケツを持ちます。
レイアウト
つくったコンポーネントを、どういう風にレイアウトするかを決めます。
つまりコレを見越したコンポーネントをつくる必要があるということです。
「自分が考えたユーザーインターフェイスを、どういう文脈で使うか」というクエスチョンに対する答えを出します。
マーケターと分析設計について構築
作成したものをより良くしていくために、判断するための材料を常に仕入れる必要があります。
リリースされる前は仮説でしか取り組めなかったことが、確かな数値結果をもとにできるなんて最高ですよね。
価値あるデザインを提供し続けるために、必要なものをプロと決めましょう。
協力すること
これはエンジニア・デザイナーだけに限った話ではありませんが、一つの「チーム」を形成する「メンバー」として、意識していきたいです。
チーム文化の形成
チーム文化は良いプロダクトをつくる上で、最も重要なことです。
これは、特定のセクションだけが意識的に動いているだけでは実現しません。
プロダクトマネージャーと綿密なステートメント構築
プロダクトマネージャーはメンバーを導くためのビジョンを形成します。
それは全員に納得感があるべきです。そのための労力は惜しみません。
メンバー同士が100％理解しあうのは無理なので、90％理解しあうのを目指す
職種が違うのであれば過去の経験も違うことが大半です。
やはり人間ですし、完全なる相互理解は難しいです。
ですが、そこで諦めずに出来る限りお互いに歩み寄る意識が大切になります。
Googleの生産性向上に関する研究である「プロジェクト・アリストテレス」にあるように、心理的安全性を高めることが重要になります。
ネガティブサイクルから脱出し、気持ちの面から改善を目指しましょう。
グーグルが突きとめた！社員の「生産性」を高める唯一の方法はこうだ
やってはいけないこと
エンジニアはコードだけを書く。デザイナーは絵だけをつくる。
線引きする行為は一見キレイな分業に見えて効率的に思えますが、実際はいくつかの業務が宙に浮いてしまいます。
お互いに望まない業務を生んでしまう原因です。
自分の持つスキルで、チームにどんなメリットをもたらすことができるかを考えましょう。
プロダクトマネージャーに頼りっきり
マネジメントをしてくれる人は、自分より偉いと思いがちです。
ですが良いプロダクトマネージャーは、メンバーと対等です。
最終的な判断を下すのは自分ではないかもしれませんが、物事を判断する土俵に持っていけるのはあなただけです。
事業の判断には、開発者の考えが介入されるべきです。
まとめ
- 全員が楽しく開発ができるように、全員が手を取り合うこと
- 物事を良くするために、専門外の知識をつけるべきだということ
- すべては繋がっているということを強く認識すること
明日は @daiend さんです。