僕はもともとWebデザイナーとして受託業務を行っていましたが、ご縁があり、とあるサービスを運営するベンチャー企業にフリーランスとして参画させていただいています。つまり、インハウスデザイナーになりました。

そこで今までの働き方・考え方と、インハウスデザイナーとして携わっている今の現場の間に生じたトラブル・ギャップなどと対策としての考えを書き連ねていこうと思います。

注意：
表題の通り、僕という人間が受託→インハウスデザイナーになって起こったことに対する説明と考えについての記事です。サービスや、各手法について説明をするための記事ではありません。内容についてより理解を深めたい方はリンク等をご参照ください。理解に誤りがある場合はコメント等でご教示お願いします。

進行方法の違いでオーバーワークした

今までの経験では、いわゆるウォーターフォール形式で進行していました。

例えば、

案件のプレゼンが終わって受注確定→ミーティングなど→いろいろ相談しつつデザイン→出来上がったものをみせてフィードバック→実装…

など、ひとつひとつを大きなまとまりで進めていき、各フェーズでドカドカやり合う感じです。制作会社でよくある進行のかたちでしょうか。

滝のように、上の水流は天候で変わって、激流が下に落ちてくることもよくありました。滝だから上れません。（そもそもの定義としてはそうではないみたいですが

それとは違い、新しい現場ではスクラムでの開発（柔軟に少し崩しているが）を行っています。

今までのやり方と違い、「細かく検証、失敗して、改善」というようなMVP（Minimal Variable Product）開発です。

### 何が起こったか

「サイトデザインの改善案を考えてほしい」「それをもとに議論できるようなもの」

じゃあ、今までのユーザーインタビュー資料やPdMの作った企画書を読み、ペインを拾い上げるような仮説を立てサイトデザインの改善案を作ろう。

そう思って完成したものをもってミーティングに参加したのですが、結果、やりすぎでした

期待されていたものは、ペーパープロトタイプや、手書きワイヤーフレーム程度でよかったのです。

### どうすべきか？

なぜこれがいけないのか？それは、デザインを作ってしまっていることで、決めつけすぎているから。そもそも議論がしたいのに、プレゼンをしてほしいわけではなかったのです。

数人のチームでフラットな立場で全員がアイディアを出し、全員がいわばデザイナーでもある。
とにかく「足並みをそろえる」「考えはオープンであり透明性を持つ」という意識が大切だと感じました。

誰が何の決定権を持つか理解してなかったため、無駄な依頼をしてしまった

例えば少人数の制作会社 / チームで、自分がデザイナーだとしたら、お客様と連絡を取っているディレクターにすべての確認を取ればいいでしょう。

しかし、スクラム開発においては各分野のスペシャリストがアサインされているはずなので、誰が何を担当しているか把握しておく必要があります。しかし、必ずしもSlackのチャンネルにそのメンバーだけとは限りません。

### 何が起こったか

入社してサービス改善チームで働き始めたばかりのとき、誰に何を依頼していいか理解していませんでした。

htmlのレビューを依頼するとき、チームのエンジニアに依頼すべきか？チャンネルに参加しているCTOか？僕は決定権があると判断し単純に後者を選びました。

しかしチーム内ではその分野のスペシャリストとしてアサインされているエンジニアの方がいるので、それまで介入してなかったCTOにレビューを依頼するのはまさに「的外れ」でした。

状況を把握してない方に依頼をすることで、説明のコストがかかることや、必要以上のフィードバックをしてしまう可能性もあります。
無駄なタスクを振りまくことになりかねません。

### どうすべきか？

しっかりと最初に決定権とチームの在り方については確認しておくべきでしょう。
自分がわからないなら、そもそもその前に確認を取るなどして未然に事故を防ぎましょう。

「ドメイン知識」の至らない点により、アイディアが空回りした

ドメイン知識という言葉をそもそも使ったことがありませんでした。「.com」などの話ではありません。これは広く言うと「事業・競合（≒いわば業界）の知識」ということです。

用語、問題のとらえ方、システムやデザインの構造、作り方。「問題のとらえ方」というのはかなり重要だと思います。

今までの受託業務では、限られた期間の”案件に対し”「メッセージを体現できていて・美しく・機能的で・なおかつ意図をもったクリエイティブである」ことが望ましい形の一つでした。（チームや、人によるでしょう）なので、ドメイン知識があればプラスですが、知らなくてもマイナスを回避することはできました。

しかし、インハウスデザイナーとして事業の成長に携わる場合、限られた期間でもなければ、案件の単位でもないでしょう。所属する限り、生涯向き合わなくてはいけません。つまり、ドメイン知識があるのがデフォルト、知らないのはマイナスであり、回避することはかなり難しいでしょう。

### 何が起こったか

ドメイン知識が欠けていることで、イマイチなデザインが出来上がりました。サービスサイト内で体現しているメッセージ、サービスのUSPや存在意義などが表現できませんでした。

それはグラフィックの話以前に、コンポーネントやタイポグラフィ、それらのマージンなどでも構成されており、そこを感じ取れてないことも原因でした。

### どうすべきか？

要求や要件どおりに作るにしても、「なんか違うな」の違和感がクオリティの低さとして現れるので、やはりいちど自分の中でデザインの言語化をすると良いのではないかと感じました。

あとは単純に、商品知識などがゼロだと、要点をくみ上げることができません。まず組織に入った時点でデザインうんぬん以上に原体験につながる知識は入れておく**よう気を付けたいところです。

具体性のある問いかけができてなかった

「確認お願いします！」

この言葉、よく使っていませんか。僕はよく使っています。

今までは、各ディレクターに、このように言えば、案件についてすでに前提条件が整ったうえでデザインフェーズに移っているので、善し悪しの判断が比較的しやすい状況だったかと思います。最終的にエンドクライアントが決定権を握っているのですが。

しかしチーム開発において、前提条件は整っていたとしても、必ずしも確認を取るべき人間は1人ではありません。また、その方々も、常に1つ以上のタスクを行っているでしょう。情報の微差は生まれているのです。

### 何が起こったか

「確認をお願いいたします」とチームメンバーにメンションしたところ、
いつ、何を確認すべきかわからない。デザイン全体なのか、写真なのか、文章なのか。
そもそももっと外側の問題なのか。

これにより、メンバー全員がデザインレビューをしなくてはいけないなど、役割分担がかぶり、非効率となりかねませんでした。

### どうすべきか？

今どうなっていて、なぜこうなっているのか。誰が、何を確認するか。

人数が多いほど、明示的に、ていねいにすべきでしょう。先にコミュニケーションコストを減らすと、後にツケが回ってきます。

質問や共有を後回しにしたことで、タスクが煩雑になった

今までのWebサイトの受託制作のスタイルでは、デザイン開始の流れになったあとは、ひたすら作りこむフェーズに入っていました。
もちろん、わからないことは都度質問しますが、だいたい形になったものを見せて話をするスタイルです。
要するに「没頭する時間」を作っていました。

別に没頭することが悪いとは思っていないのですが、フットワークが軽い・重い以前にフットがワークしなくてもよい、ひとりよがりな状況を作っていたと解釈することもできます。

### 何が起こったか

進めていくうえで、出来上がったものに対し「やっぱ先に聞いとけばよかったな」という出来事が、たびたび起こります。

### どうすべきか？

大きな支障はなくとも、もう少しスムーズに進められたことは明白なのに、調整に余計な時間がかかってしまいます。そもそも小さな検証・改善を繰り返していくはずなのに、必要以上の工数はかけないほうが健やかでしょう。

なにより、フットがワークしなくていい、というのはコミュニケーションを重んじてフラットな立場で開発を進めるチームにおいて致命的な癖だと感じました。

気軽に話しかけられる人間であると同時に、自分からも気軽に話しかけに行く「仲間」であることが、よいモチベーションと関係性につながるでしょう。

ドメイン知識、コミュニケーション（など）が足りないことで語彙力が減少する

### 何が起こったか

語彙力がないことで、認識合わせがスムーズにいきません。もやもやすることが増えます。

また、納得のある提案にもつながらない原因となるでしょう。

### どうすべきか？

語彙力は武器です。言葉にできることで、自分自身の気づきも増えます。

デザインの言語化、競合の調査、社内資料を見る、小さいことでも話しかけに行く…とにかく言葉の材料を溜めておくことがよいでしょう。

チーム内でエンジニアとの連携に慣れてなかったことでGitでトラブルが起こる

ひとりGit（多くても2～3人）の経験しかなかった僕は、エンジニアの方との連携やPull Requestで起こったトラブルへの対応がスムーズにいかず躓きました。ひとりGitに限界はある。

### 何が起こったか

「File changed」を見てないことで、異常に気付けませんでした。それと、コンフリクトに気づかなかった。程度が低いですが、それを気に掛ける経験すらもなかったので、起こるべくして起こったミスでした。とはいえ、これが原因でサービス壊滅の恐れもあるのです。

### どうすべきか？

これから開発チームに入る場合は、仲の良いエンジニアの方に少しGitの運用について聞いておくと良いかもしれません。ひとりGitに限界はある。

さいごに

日々切磋琢磨してる方からすると、当たり前だろ？と思う点ばかりでしょう。
仮に僕のように受託業務からベンチャー企業のインハウスデザイナーになった方だとしても、ここまでのミスはしないかもしれません。

ただ、環境が変わるとそれまでのやり方・考え方はアップデートしなくてはいけないという、身を持った良い気付きになりました。

非常に考え方も合理的で感服することが多いので、いまは良い環境だと感じています。美しいデザインや愛されるサービスを作るためには、手ばかりを動かしているだけでは厳しいのではないか、と危機感を覚えました。

キャリアパスを描くのも大事ですが、描く先での人とのかかわり方は、常にイメージしておきたいところです。