UI/UX担当者の課題は企業によってどう違う？グッドパッチ・ランサーズ・schooが経験を語る！｜ヒカ☆ラボレポート

今やWebサイトやWebサービスを作るうえでかかせない「UI/UX」。

 

とはいえ、フロントエンドエンジニアやUI/UXデザイナーが常に足りない状態の中、ディレクターと兼任したり1～2名の小規模でチームを運営したりと工夫する企業も多いのではないでしょうか。

 

今回のヒカ☆ラボでは、フロントエンド・UI/UXデザイナーが活躍する株式会社グッドパッチ、ランサーズ株式会社、株式会社スクーから、UI/UXまわりの体制や課題を経験を交えてお話していただきました。
さらにイベント後半では、気になる現場のエピソードや体制に関して3社から答えていただくコーナーも！

 

企業が違えば、体制も役割も3者3様。スキル向上のヒントにぜひお役立てください。

 

プロジェクトの炎上を防ぐためにフロントエンジニアとしてできること
株式会社グッドパッチ フロントエンドエンジニア 右寺 隆信氏

プロジェクトの炎上を防ぐためにフロントエンジニアとしてできること

株式会社グッドパッチでフロントエンドエンジニアをやっております、右寺隆信と申します。本日はよろしくお願いします。

これまで、Webサービスの企画、法人営業、Webデザイン、Webディレクター、そしてフロントエンジニアとさまざまなことをやってきました。今はグッドパッチの中でフロントエンドエンジニアの業務を中心にやっております。強みはまあ、「色々できる」ことです。

次に「グッドパッチ」の紹介をさせていただきます。弊社は「UIデザインに特化した制作会社」という形で、いろいろやらせてもらっています。ビジョンは「人々のハートを揺さぶるDesign＆Productを生み出し世界をより良い方向に前進させる」です。
弊社にはデザイナー以外にもディレクターやエンジニアがおりますが、全員が「デザインの力」を信じて色々なものを作っています。

グッドパッチにおけるフロントエンドエンジニアの立ち位置

弊社では、フロントエンドエンジニアとコーダーは兼任でやっています。基本的にデザイナーはコードを書かない状態で…まぁ技術的に書ける人はいっぱいいるんですけどね。その辺、完璧に分かれている感じです。
あとディレクターに関しては、デザイナーやフロントエンジニアがディレクターをやることもあります。

ちなみに、私は基本的にフロントエンドエンジニアなんですが、案件によってはディレクターとしてプロジェクトに入ったりもします。

デスマーチはありとあらゆるものを壊す

仕事をしていれば、案件の炎上してデスマーチに直面することってありますよね。私自身もこれまで、そういう状況に陥ったことがたくさんあります。

デスマーチに突入すると仕事が忙しすぎて「からだを壊す」「家庭を壊す」「人間関係を壊す」「精神を壊す」など、様々な悪影響が出てきます。もうやってられない状態です。

また、エンジニアである以上、「簡潔で」「分かりやすく」「保守性が高く」「堅牢で」「効率が良く」「無駄がない」、そんなスペシャルなコードを書きたいという思いは常々持っています。

しかしながら『デスマーチに突入し、とにかく時間がない』というときは、そんな余裕はありません。『最低限動くものが作れればいい』『とにかく納品できるよう頑張ろう』ということに意識が傾きます。
で、こうなってくるともう最悪です。クソみたいなコードが大量生産されてしまうことになります。

もちろん、自分で「ダメなコードを書いている」って分かっているんですよ。分かっているからこそ精神衛生的に非常に良くない。
それに、こういう状況になってくるとエンジニアとしての成長も難しくなってきます。というのも、仕事をしているときって新しいものをどんどん身につけていく機会が結構あるはずなのですが、こんな状況になるってくるともはや調査に使える時間なんてなく…。ただただ書き上げる状態になってしまいます。デスマーチという過酷な状況の中、数週間・数ヶ月頑張ってもなんの成長にもつながらない。これってかなり最悪な状況ですよね。

ということで、今回は「案件の炎上を避けるための方法」についてお話していきます。

プロジェクトの炎上を防ぐためにフロントエンドエンジニアができる「4つのこと」

プロジェクトが炎上する原因のほとんどは、プロジェクトマネージャーあるいはディレクターにあると、私は個人的に思っています。実際私が昔ディレクターをしていたっていうのもありますが、本当にここは責任が重たいです。

ただですね、
「プロジェクトが炎上したのはディレクターの責任だ！」
といっても、実際に苦労するのは手を動かす自分（フロントエンドエンジニア）です。

となればもう、自分の身は自分で守るしかありません。
そのためにできることは、次の4つです。

1.契約内容を確認しておこう

「契約内容の確認こそプロマネやディレクターの仕事じゃん！」って思うかもしれないですが、ここは本当に大事です。
契約書・見積書・発注書は必ず確認しておきましょう。それらがない場合でも、何かしらちゃんと文面で残しておいたほうがいいです。それが一番の安全策だと自分は思っています。

で、その際、クライアントが「成果物を期日までに納品すること」と「プロジェクトを進める上での人月」どちらにお金を支払っているのか？ということを事前に確認しておきましょう。
よくある話ですが「最高の成果物を追い求め過ぎたせいで仕様がふくらんでしまって、納期に間に合わない！」となったとき、後者のような契約形態でスクラム方式でスプリントを回していくような案件であれば、事前に合意が取れていることが前提ですが「まぁ問題ない」と言えると。

逆に納期重視の契約の場合、このような状況を作ってしまうと本当に最悪です。「休日返上で深夜までずっとやるしかない」っていう状況になってしまいますから。

プロジェクトの最初の段階で「クライアントが支払っているお金って、何に対するものか？」ということを理解しておけば、こういったケースは防げるのかなと考えております。

2.対応範囲を明確にしておこう

クライアントから「Webサービス作りましょう」とか「Webサイト作りましょう」と案件がきたとしましょう。

そのとき、こっちとしては「デザインを起こして、HTMLとCSSとJSでモック作って納品するんだな」と考えて作ります。でも、クライアントは「フロント側でAPIまでつなぎこんでルーティングまでしてくれるだろう」と思っていた…。

これ、実際にあった話です。
なぜ、こういうことが起こるのでしょう？

個人的には、ちょうど1年前のこの時期ぐらいから言われている「フロントエンドエンジニアやること多すぎ問題」の一種だと考えています。実際、JSでいろんなことができるようになり、フロントエンドでできることも増えてきました。これはとても喜ばしいことです。超楽しいです。
たからこそ、フロントエンジニアは新しいことをどんどん勉強します。マジで頑張っても追いつけないくらい新しいことが次から次へと出てくるわけです。

ただ、ディレクターはそうはいきません。現場で必死にがんばっても追いつかないくらいのフロントエンドの業務を全て理解してくれという方が無理です。こういう状態ではクライアントとディレクターとの会話で齟齬が出てくることは避けられないと思います。
ただ、その中でも、モダンなサイト構築において「どのあたりに気をつければ良いか？」ということだけでも事前にディレクターと共有するだけでも随分違うと思います。
可能であれば、実際に自分もミーティングに参加して「ここまでを対応します」と話をすることです。もし、色々な理由でミーティングに参加できないのであれば、ディレクターがプロジェクトを持ち帰った段階で、「対応範囲はここまでですね！」と明確に確認しておくことが大事です。

「どこまでうちでするのか？」「向こうはどんな感じでやるのか？」っていうところは、本当にちゃんと突っ込んで聞いておいたほうがいいでしょう。

3.技術選定は最初に合意をとろう

最近、便利なフレームワークやツール、メタ言語などが出てきました。
「よし。この辺使いこなして、効率的に案件を進めていくぞ！」と思いますよね？
でも、ちょっと待って！そのツールを使うこと、クライアントに合意を取っていますか？

・某社であった悲劇 その1
「最近いつもJade使ってるし連携も楽なんで、この案件でもJadeでサクサク作ったる！」と思って作ったら、クライアントから「サーバーサイドはRuby on Railsで書いている。実装するのでslimでやってほしいんだけど」みたいな話がきました。
「え？これ全部書き直すの？…死ぬ」みたいな。本当に辛いです。

・某社であった悲劇 その2
「最近流行ってるし便利そうだし、AngularJS使ってゴリゴリ作っていくぞ！」と思って作ったら、クライアントから
「すいません。うちの会社AngularJS分かる人いないのでやめて欲しいです」
と言われた上に
「一番最初にディレクターさんと会ったとき、SEO大事って話しましたよね？AngularJSでSEO対策するのって、コストかかって面倒くさいと思うんですけど、その辺考えてもらってますか？」
って話になって…
「どうしよう…書き直す？イヤ無理でしょ！」と。本当に悲惨です。

こういったことって結局、案件が始まる前にクライアント側のエンジニアさんと話して、利用するツールの確認をしておけば防げるんですよね。最近ツールが増え、それらを安易に使ってしまいがちなので、皆さん気をつけてください。私も気をつけます。

4.スケジューリングは必ず関わろう

ディレクターさんとクライアントの間だけで、スケジュールが勝手に決められていることってありませんか？

「こんなの工数的に絶対無理じゃん！」ってことでディレクターさんと揉めるものの「もう決まったことだから」で片付けられ、そのままデスマに突入するみたいな….

こういったことを防ぐには、もうこれしかないです。
「作業に対して工数を厳格に見積もりましょう」。

スケジューリングの時点で「無理だ」と分かっているときは「本当に無理です！」と言っておかないと、良いものはできないと私は考えています。
社内のPMやディレクターとうまく協力して、ステキなプロジェクトを作っていきたいものですね。

以上、私の話は終わりです。
どうもありがとうございました。

 

 

「デザイナーとディレクターのイイ関係の作り方」
ランサーズ株式会社 システム開発部デザインチーフ 竹中 哲氏

80人いるスタッフのうち、デザイナーは竹中氏ただ一人

ランサーズの竹中と申します。
元々は役所で公園の設計をしたり、ポータル関連の会社でデザイン業務を行ったりしていました。現在は、ランサーズでチーフデザイナーをやっております。
今日は「デザイナーとディレクターのイイ関係の作り方～DtoDのGive＆Take～」と題し、説明をさせていただきたいと思います。

企業とクリエイターをつなぐマッチングサイト「ランサーズ」を運営している弊社には現在、約80名のスタッフがおります。その中でデザイナーは何人いると思いますか？
実は、自分一人だけです。
まぁ、何とか元気にやっております。

デザイナーの人材不足は深刻な問題に

弊社のデザイナーは、デザインコーディングを主にやっています。まぁ、場合によっては画面の設計をしたり、ワイヤーを描いてみたり、実装をやるようなこともあります。

業務フローは、プロダクトオーナーが要件をおろし、ディレクターが話をまとめ、それからデザインチームに落としてくるって感じですね。基本的に、アートディレクションを考える人が世界観を決めて、デザイナーとフロントエンドにそれぞれ業務を割り振って、最終的にはエンジニアにサポートしてもらいリリースする、みたいな。

…と、話だけきくとすごく整った体制に見えるかもしれないですけど、実際デザイナーチームは2名しかいない。しかもデザイナーは僕だけっていうことで、業務の調整が死活問題です。
ということで、スケジュールを握っているプロデューサーやディレクターと仲良くやっていくことが大切なのです。

 

デザイナー不足をカバーするためにできる4つのこと

1. デザインはフリーランスと作る

基本的にリソースが足りません。なので、フリーランスの方に社内の案件をふるようにフローをちょっと変えています。
「ランサーズに登録いただいている方と一緒に作っていく」
という感じですね。

「フリーランスの方に作ってもらったら、クオリティが落ちるのでは？」
と、すごく聞かれます。
でも、クオリティには当然責任を持っていますし、リリースまでしっかりとやっていますので、その辺の心配はありません。
おかげさまで、まとめサイトみたいなものに掲載いただき、外部評価も得ています。

2. ディレクションも始めてみました

フリーランスの方にデザインコーディングをやっていただくようになってから、ディレクターがディレクションをする部分が増えました。
すると「ディレクターの確認待ち」っていう状況が増えてきたんですね。
「待っているくらいなら、自分でディレクションやろう！」
と思って、今かなり手を伸ばしてやっております。手を挙げればやらせてもらえる環境なのが、幸いしました。

で、その結果、全然待たなくて良くなりました。
「5秒でOKでました～！」みたいなことがどんどん増えて、会社のサイクルがまた一段と早くなりました。

あと先日「gulp」を使いたくて、エンジニアの人に相談したんです。すると、みんな色々と資料を見つけてきてくれました。で、実際やってみたところ良かったので、ちゃんと結果をまとめてコンセンサスストーリーにしました。

まず、やりたいことは宣言するっていうのが大事ですね。
結局、gulp導入は、わずか2週間でできました。

3. 分析しました

デザイナーがデザインするときの根拠って色々ありますよね。
例えば、表面的なデザインだったり、フローから考えるデザインだったり、コミュニケーションしやすいデザインだったり、ほんと色々です。
ただ、やはりサービスを作り上げる人間としては、データをちゃんと調べた上でデザインするっていうのが大事かなと思います。
とりあえず「自分でデータをみて、色々分析して、仮説を立てる」ところまでやってください。例えば「どのページが見られている」とか「どこのクリック率がいい」とか、そういったことを分析していく感じですね。

その結果、自分の「勝ちパターン」が分かってきます。

とはいえ「一人でやっているのにそこまで手が回らない」「数字分析は苦手」というデザイナーさんは多いと思います。僕もそうでした。
それなら、得意な人に聞けば良いだけの話です。

「ディレクターを味方につける」っていうのが、ここで大事になってきますね。
私の場合は、数字が見れる人にお願いし、「デザインした結果が良かったのか？それとも悪かったのか？」「実際どのくらいの数字になったのか？」みたいなところを毎回共有してもらうようにしています。
この共有のおかげで「自分が手がけたデザインは数字に結びつく」という自信を持てるようになりました。

4. 孤独をやめた

「ベンチャーで、一人でデザイナーをやっている」という人は少なくないと思います。デカイ会社でも「チーム内でデザイナーは一人だけ」なんてことはザラにあるでしょう。
そういうデザイナーさんに言いたいこと、それは「一人で抱え込まない」です。

では「一人で抱え込まないためにどうすればいいか？」というところですよね。
僕の場合、声をかけることを始めました。

新しい人が入ってきたときもそうですね。一番目に声をかけるのは大体僕です。
急成長中の会社において、相手に自分の存在を知ってもらうため、とにかく声をかけています。そして、自分の存在に気付いてもらったら、さらにその人に「仲間」だと認識してもらえるよう、極力その人のヘルプをするようにします。相手がディレクターの場合は特にですね。

するとですね、今まで孤独だった自分が孤独じゃなくなるんですよ。ちゃんと仲間ができるんです。で、仲間になるとみんな勝手にデザイン業務を手伝ってくれるようになるんです、不思議と。
もし、やり方が間違っていたら後で教えてあげればいいだけの話。自分でやってくれる人にはやってもらえば良い。その人は必ず成長しますから。

ディレクターとイイ関係を作れば、チームはもっと強くなる！

「デザインが間に合わない」「ディレクションが間に合わない」「分析できない」「孤独だ」
と、否定的に思うのはもうやめましょう。
足りないものを嘆くのではなく、足りないものを補うためにディレクターとイイ関係を作っていけばいいのです。そうすればかならず強いチームになれると思います.

 

ちょっと待って！UXを考えるその前に
株式会社スクー 執行役員 上羽 智文氏

執行役員とデザイン部門責任者の2つの顔を持つ上羽氏。schooでは、サービスデザインとUXデザインを担当

はじめまして。上羽智文と申します。スクーの3人目のメンバーとしてジョインしました。仕事は、執行役員兼デザイン部門責任者ということでやっています。主に、サービスデザインとUXデザインをやっています。

スクーは無料オンライン学習サイト「schoo WEB-campus」を運営している会社です。今年は「仕事に活きる」をテーマに社会人のための授業を展開、動画でお届けしています。

ディレクター不在のschoo。メンバーは幅広い領域を担当することに

弊社のサービス作りは「サービス開発部門」で行われます。4人のメンバーで構成されており、僕を除いてデザイナーが1名、フロントエンドが2名、そしてバックエンドが1名です。

でですね、うちの会社、ディレクターがいないんです。開発メンバーが企画に立ち、ディレクターを兼務するって感じでやっています。なので、かなり幅広い仕事をする環境になっております。

例えば、弊社のデザイナーはですね、画面設計やビジュアル、HTMLといったところもやっています。JavaScriptを半分書いたり、PHPを半分書いたりってこともありますね。

デザイナーの担当領域が広がったことで生まれた「デザイナー足りてない問題」

数年前までのデザイナーって、UIデザインとマークアップをすれば良いって感じでした。でも今は違います。UXデザインだったりサービスデザインだったり、チームビルディングだったり…とにかくやらなきゃいけないことが広がりまくっています。

そうなってくると、当然いつかはデザイナーが抱えるタスクが爆発するわけです。
とてもUXなんて考える余裕はない。
結局、場当たり的な施策・改修をするしかなくなり、サービスはグロースしないまま。で、タスクはさらに積もっていく…
負の連鎖が永遠に続くわけです。

そろそろ、負の連鎖を断ち切りましょう！
…ということで、今日言いたいのは
「UXを考える前に、まずリソースの確保をしましょう」
ということです。

では、どうやってリソースを確保するのか？
人を増やせばすぐに解決できることではあるのですが、そもそも増やすための人がいないのでどうしようもできない。
となると「無駄をなくす」しかないのです。
無駄に時間がかかることをやめられたら、その分リソースを確保することができます。

コミュニケーションロスを減らすことで、リソースを確保

コーディングやデザインといった実作業の工数を減らすことはなかなか難しいですよね。でも「コミュニケーションロスを減らし、リソースを確保する」ことは、やろうと思えばすぐにでもできます。ここからはコミュニケーションロス削減のために自分が実際にやってきたことについて、紹介していきたいと思います。

1. メンバーのコンセンサスを取るための工夫 ～企画段階編～

デザイナーだったら「メンバーのコンセンサスをとる」という仕事がありますよね。
そのときに、「これはやってはいかんな」ってことがあります。

・資料を用意して展開する
普通はするんですよ？普通は。ただ、今日は「時間をかけちゃダメ！」って話なんで、これはダメです。

・ミーティングを重ねて丸め込む
時間がかかる上に雰囲気も悪くなるので、ダメです。

・エンジニアを無視して自分勝手に進める
誰も幸せになりません。ダメです。

反対に、やってよかったことは
・メンバー自身にロールプレイングしてもらう（ユーザーになりきってサイトを使ってもらう）
です。
ロールプレイングのやり方について、実際行ったロールプレイングを例に出して説明しましょう。

まずは、メンバーの二人に役を与えます。
一人は就活中の大学1年生、もう一人は部活の後輩、という感じ。
次に、僕からお題を出します。お題の内容はこうです。
「schooの会員登録をしたあとに、就活関連の授業を受講するっていうところまでをやってみてください」

これ、5分かけてやりました。
結果、会員登録した後10クリックくらいしないと、就活関連の授業にたどり着けませんでした。しかも、ふとしたときに違うページに遷移してしまい、そこから戻ることができなくなり、そのままゲームオーバー。

実は僕、このロールプレイングを行ったとき、会員登録後の導線に課題を感じておりまして。その課題をみんなにわかってもらうために、このお題を出しました。結果、みんなが課題について納得できた会となりました。

このロールプレイングの手法は、データや資料がなくてもできるので、私はもちろん参加する方も楽です。しかも、たった10分でコンセンサスを取ることができます。さらに、チームとしての一体感も生まれるので、やってみる価値は十分にあると思います。
これ明日にでもやってみてください。すごく楽しいです。

2. メンバーのコンセンサスをとる ～UIデザイン編～

「サイトを大改修する必要がある」とあなたが感じたとしましょう。そうなれば当然、導線を再設定したいですよね。でも、導線を変えるとなると裏側も変えないといけなくなるのでエンジニアは乗り気じゃない、と。
そこをどうコンセンサスをとっていくか？

自分が考えた方法は「可視化」、つまり「見える化」です。
僕は、画面遷移図を描くことにより、ヤバイと感じる部分を素直に伝えることにしました。

具体的なやり方をお話します。
まず競合を比較対象におきます。日本のサイトにはあまりスクーの競合がないので、米国のlyndaっていう動画学習サイトと比較することにしました。実際に見ていただくと分かるんですけど、lyndaの導線はすごくシンプルです。
では、我々のスクーの導線はどうなっているかと言いますと…。
実はめちゃくちゃページが多い。導線が複雑なのが一目で分かります。
メンバーも可視化することで現状の課題に気付き、そして、自分で直したくなる気持ちになるのです。

3-1.ビジュアル担当者が作業しやすい体制を整える ～マークアップ編その1～

例えば「カンプの1pxのこだわりが伝わらない」「なぜかいつもシャドウが無視される」
といった経験、ありませんか？
こういったとき、私は仕様書を作りません。赤入れもしません。そのかわりビジュアル担当である自分が作業をやります。

どういうことかと言いますと、gitを導入しステージングの環境を整えることで、デザイナーもステージングをできるようにしたんです。すると、ビジュアル担当者が自分でこだわりを形にできるようになりました。

3-2.UIガイドライン/スニペットを作ることでCSSを直す手間を省く ～マークアップ編その2～

CSSを毎回デザイナーが直していくのは面倒です。弊社では、CSS設計の教科書を参考にしつつUIガイドライン/スニペットを作り、エンジニアも自由にそれを使えるようにしました。結果、コーダーはより複雑な制作作業に専念できるようになりましたし、デザイナーももはや手を離してもいいくらいの感じです。これはすごく良かったなと思っています.

4.Xcodeのストーリーボードを使うことで、カンプ1pxの「こだわり」を解決 ～対エンジニア編～

iPhoneアプリを作るときって、エンジニアさんになかなかカンプの1pxのこだわりが伝わらないんですよね。
そういうとき、どうするか？
弊社では、Xcodeのストーリーボードを使えるようにすることで、ビジュアル担当者でも簡単に変更ができるようにしました。

できる領域を広げることで、今まで以上に仕事へフォーカスできる

結論はこれです。
「資料より対話。変な気を遣わない。」

エンジニアとして一番イヤなのは「なんで1px1px言われなきゃいけないんだ！」ってことでしょう。
もう言わなくていいんです。言わない代わりにやれば良いのです。
そう、デザイナーは気を遣わなくていいのです。
HTMLやXcodeによりできる領域を広げることで、逆に「仕事にフォーカスできる」という、「良い意味での皮肉がある」と思っています。

地味の積み重ねで、リソースの確保ができ始めました。
そしてようやくUXを考える時間が取れました。
このあとに、UXのセミナーがあれば完璧ですけどね。
ではみなさん。
無駄をなくして、クリエイティブな仕事をしていきましょう。

ご清聴ありがとうございました。

 

3社合同トークセッション

 

「経験したからこそ伝えられる、UI/UX担当として職能を上げるためのコツ」がテーマの今回のヒカ☆ラボ。イベント後半では、リアルな現場でのエピソードやそれぞれの企業の良い点・改善点をグッドパッチ右寺氏、ランサーズ竹中氏、スクー上羽氏の3者にそれぞれ伺いました。

Q.本当にあった恐怖体験は？
Q.現在の体制 良い点・悪い点は？

現場で3人を襲った恐怖体験とは…？

1. グッドパッチ右寺氏の場合
「契約内容があいまいで、どこに責任があるのか分からない！」

右寺：「本当にこれは勘弁して！」って思ったのは、やはり契約内容についての認識のズレですね。

ある案件で、自分はフロントエンジニアとしてその案件に入る予定だったんですけど、ちょっと人手が足りないってことで、ディレクター的役割も引き継ぐこととなりました。
契約を取ってきた人から「こういう案件だから」と話を受けて「あぁ分かりました」って感じで、そのときは引き受けました。
それから、クライアントさんと色々話しながらプロジェクトを進めていってたんですけど、途中あることでちょっと揉めたんですね。

そうなったときに、じゃあ契約書の内容を見返そうと思ったら、契約書がなくて、今起きている問題の責任の所在がどちらにあるか全く分からない状態だった、と。
これ、本当に取り返しようがないんですよ。
言った言わないっていう話になるともうどうしようもない。結局どっちかが折れるしかないんです。そのときは「両者痛み分け」って感じで終わりましたが、本当にきつかったですね。

それ以来「契約周りは本当にちゃんとしよう」と思うようになりました。

2. ランサーズ竹中氏の場合
「お客様が突然会社に乗り込んできた！」

竹中：サービスってところでいうと、そうですね。1回、お客さんが会社に乗り込んできたことがありました。

会社の内線が鳴って出たら「お客さんがお見えです」と。
うちの会社、一応サポート担当の人間がいるので対応はその人たちにお任せしました。

サポートチームがしっかりと対応してくれたのでしょう。
最終的には「たったこれだけの人数でランサーズ運営してたんですか？これからも頑張ってください！」
と言われ、お客様は帰っていかれました。
たぶん、クレームだったんじゃないか…と推測するのですが、このように事なきを得られたのはサポートチームの正しい対応があったおかげです。もし、サポートチームがあの時違う対応をとっていたらどうなっていたのか？考えると背筋が凍ります。

 

3. スクー上羽氏の場合
「メールを飛ばす機能を一個外しただけでPV数が激減！」

上羽：私の方からは、サービスに関する恐怖体験をしましょう。
去年の春過ぎ頃、大きなリニューアルをかけた時期がありまして。
そのとき、2ヶ月くらいの期間、全リソースを投下して作ったんですよ。

で、バーンとリニューアルしたんですけど、なんとPV数がバッコーンと激減しまして。
…マジか、と。

どうしようかと思って色々調査したり改修したりしたんですけど、原因がよく分からない。
で、ひと月程たったときに、アルバイトの子が「最近メール飛んでないですよね」って話をポロッというんですよね。
実は、リニューアルした際に一個だけメールを飛ばす機能を外したんですけど、それ聞いたときに「マジか！」って、もう一回付け直したんですね。
そしたらPV数がガーって上がって元に戻ったんです。

「メール怖っ！」って思いました（笑）
まぁ、おかげでメールマーケティングの大切さが分かった。という良いお話でした。

うちの会社の体制「ここが良い！ここが悪い！」

1.グッドパッチ 右寺氏の場合
【良いこと】ディレクターの経験を通して、デザイナーの視野が広がる
【悪いこと】同じ案件内で、デザイナーがディレクターを兼務するのはやめるべき

右寺：うちの会社で個人的に「いいな」と思っているのは、デザイナーがディレクターの経験を積めるということ。経験した後みんな「自分の視野が広がった、本当に良かった」といいます。

これまで「デザイナー一筋」というような30代40代の人の場合は、そのまま専門性を突き詰めていってもらった方がいいと思うんですけど、若いデザイナーがディレクターをやってみるのはいいですね。ディレクター経験しかないディレクターでは気付かない視点をデザイナー経験のあるディレクターはもっているので新鮮です。色々と共有してもらっています。また、ディレクター経験のあとデザイナーに戻ったとしてもこの経験は確実に活かせると思います。実際、ディレクター経験のあるデザイナーがプロジェクトに入っていると、そのプロジェクトがうまく回っている印象がありますから。

悪いところで言うと、今はもうやってないんですけど、同じプロジェクト内で「デザイナー兼ディレクター」「エンジニア兼ディレクター」っていうのは絶対やっちゃダメだなって思います。何故かというと、デザイナーやエンジニアには「良いものを作る」ということに注力して欲しいからです。
ディレクターだと、どうしても「期日を守らないといけない」「予算を抑えないといけない」など、色々考えることがあるじゃないですか？
これ、一人の頭の中で同時に考えるのって厳しいと思います。

2. ランサーズ 竹中氏の場合
【良いこと】手を挙げる人間に対し裁量権が与えられる
【悪いこと】手を挙げない人間がすねる傾向に

竹中：うちは、制作に関して「これやりたいです」と手を挙げれば、結構な確率で裁量権が与えられます。そういう裁量の大きさっていう部分はいいのかなって思います。

悪いところは、そうですね。手を挙げる人が大勢いる中で、自分が手をあげないと「俺やっていない」「申し訳ない」という気持ちになってしまうことでしょうか？
手を挙げない人間が拗ねちゃう、みたいな事が結構起きがちですね。でも、手を挙げない人のなかには「技術をゴリゴリ書いていきたい」というひとももちろんいるわけで…。
そういう人には「君は技術で行けばいいんだよ！ちゃんと見ているから！」といった感じでフォローするようにしています。

3.スクー上羽氏の場合
【良いこと】広い領域を任せてもらえる
【悪いこと】専門性に課題が残る

上羽：良いところはランサーズさんとほとんど同じですね。うちも裁量権が結構あります。実際、メンバーにも企画やプロジェクト管理などの上流工程を含め幅広い領域を任せています。

悪いところは、広い領域を任せる分、専門領域だけに特化できない。職人気質の人には合わないんですよね。ここはバランス見ながら改善していきたいと考えています。
まぁ、よく言えば自由、悪く言えばやることがたくさんあるって所ですね。