見出し画像

「I」ではなく「We」でソフトウェアを作っていく楽しさ

新卒面接で「事業会社だと運用のイメージがあるのですが、やりがいはなんですか?」と聞かれる事が多いのでその回答を書いてみました。

以前、UI/UXデザイナーを目指す若手に知っておいて欲しいことを書いたけど、事業会社はサービスを育てていくのが仕事で、最近はUI/UXではなくソフトウェアデザインと表現してます。

※主に新卒〜若手向けでわかりやすく抽象度の高い表現を使ってます。

事業会社でデザインする楽しさとはなんなのか

こんなつぶやきをしましたが、僕は今39歳で年齢もそこそこなので、自社サービス・外部パートナーとしての様々な環境でデザインワークをしてきました。

自社サービスの仕事に帰ってきたのは、中の人として責任を持った状態で意思決定する必要が事業会社では必要と思ったのが1つ目。

経営メンバーやdelyメンバーを尊敬して一緒のバスに乗ってサービスを育てて行きたいと思ったのが2つ目です。入社当時CTOのたけさんと話した当時の心境記事はこちらです。

最近ジョインした @ymdsko も制作会社と事業会社の違いについて記事を書いてくれてます。

UIデザイナーが制作会社から事業会社のdelyへ転職した話https://note.com/skymd/n/n177ce5084e1a

「I」ではなく「We」でソフトウェアを作っていく楽しさ

事業会社の楽しさはみんなでサービスと会社を育てていく所だと思います。

「We」はデザイナー+デザイナーではなく、デザイナー×全職種であり、総合格闘技の如くデザイン、コンテンツ、アルゴリズム、組織作りなど様々な技術を駆使して統合的に取り組むのが大事になりました。

便宜上、UIデザイナーやエンジニアなどと職種を分けてますが、昨今ユーザーからはテクノロジー×デザイン×ビジネスがかけ合わさっている品質のサービスが求められていて、それらを継続していく行動こそが事業会社のデザインワークだと思います。

画像8

先日、弊社社長がSlackでこんなつぶやきをしてました。

スクリーンショット 2020-11-02 17.08.40

冒頭で外部パートナーからの限界点と表現したけど「テクノロジー×デザイン」など掛け合わせで実現していくコミュニケーション密度の濃さが中の人だとぜんぜん違うんですね。

良いユーザー体験を作る為ならバチバチ仕様を話すし、必要なら組織を変えて、ダメだったらまた作り直す。それを繰り返すためには、信頼関係も大事で、密度の濃い会話を繰り返すプロセスで脳みそのアップデートされ、ソフトに反映していく感覚が醍醐味だと思います。

ソフトウェアデザインの目を鍛える楽しさ

『デザインを見る目を養う』と表現されますが、鍛えるポイントが少し変わってきたように思います。例えば従来は、配色ロジック、絶対フォント感、カーニングやGUI表現の美しさ、ピクセルパーフェクトなどでしょうか。

カーニングの採点ドットが図形の真ん中にあるか判断するトレーニングサイトも多く、学校や先輩デザイナーに習った人も多いと思います。

一方でソフトウェアデザインについては、それらと異なる目を鍛えることもデザインスキルアップのコツだと思います。

高速で多種多様なテストを繰り返すグローバルサービスの進化を観測したり、A/Bテストの実施結果から推測してデザインの引き出しにしていきます。

例えば、Twitterでアップデートに関するエゴサーチするとこんな感じでキャプチャを張ってつぶやいている人たちが見つかるので自分との差分でA/Bテストか判断して観測します。

GAFA系サービスはかなり高速でテストを回していて、施策が数日後にしれっと消えてたりもします。N%の被験者で実施してると思いますがこれらのテストを繰り返して、数カ月後に正規機能に昇格するモノもあれば、消えていくモノもあります。

英語圏の方が進化が早く、英語でエゴサーチするのもありです。

ソフトウェアデザインの目は、今のデザインを切り出すのではなく、これらの進化過程を継続的に追って推測する事で鍛えられると思います。

僕は、アプリの変化に気が付いたらキャプチャを撮ってメモしたり、変化の背景を推測したりするので、スマホの写真フォルダはスクリーンショットで埋まってます。

例えば、YouTubeの評価UIも細かいチューニングしてますね。

画像9

AとBの吹き出し向きの変化はデザイン上の細かいチューニングですが、更に前の分岐として、Aの顔文字、Cは星で評価させることでレビュー変化の集計テストを実施しているの事がわかります。


noteは、スキが増えると書き手のモチベーションがあがり記事数が増え、見る人も増えるサイクルだと思いますが、スキ数を増やすための進化がみられます。

画像10

最近このようなテキストに変化したような気がしますが、記事下部にスクロールしていくとコーチマークが強制表示されます。ログインなしでとテキストで表示した事で、非会員でもスキができる事を伝えてスキ数を増やすのが狙いと推測できます。

TwitterアプリのURLからnote記事に飛んだ場合、Webviewだとログインしてない事も多く一手間減らしてスキ数を増やす対策かもしれません。


次は、Netflixをみてみましょう。

画像11

Netflixが、作品毎に単一のサムネイルではなく複数のサムネイルを生成し、パーソナライズ化する事で、ユーザーに興味を持ってもらいやすくする施策をしてるのは有名だと思います。

Artwork Personalization at Netflix
https://netflixtechblog.com/artwork-personalization-c589f074ad76

Netflixのサムネイルって人によってかなり違うのはなぜ?
https://jp.voicetube.com/v3/videos/71802

ここまでコストを掛ける理由として、Netflixはサブスプリクションサービスのため、月額課金を支払ってるユーザーの継続率が売上に影響してきます。

当然、映画より連続ドラマ・アニメを観てもらう方が、視聴期間が長くなり継続率が高まる想像ができます。視聴を続ける1本のドラマに出会えた場合、仮に60分×12エピソード = 最大720分視聴の価値があるため、コンテンツに興味を持ってもらうアプローチとしてこれらの投資が見合うと考えられます。


別角度の例をあげると、昨今のソフトウェアは、iOSやAndroidのライブラリ、ログインなど何からしらのプラットフォームの仕様に乗っている機能も多く、プラットフォーマーの仕様変更に敏感になっておく必要があります。

画像12

これは、とあるサービスがFacebookログインによる新規登録を廃止したアップデートですが、意思決定の背景を推測する事で市場動向を推測したり、ユーザーの反応をみておきます。

直近では、iOS14のモバイルエコシステムにおける広告のターゲティングに影響を与える仕様変更は業界を賑わせました。

ソフトウェアデザインといっても、設計や意匠だけはなく、このようなデータやプラットフォーム動向を考える視点も重要だと覚えていくと良いかもしれません。

普段みているサービスの進化プロセスを追って、ロジックの仮説を考え、A/Bテストとサービス反映結果から推測し、パターンの引き出しを増やしていくことで、デザインを見る目を養っていくとデザインが更に面白くなると思います。

サービスを育てていく楽しさ

「サービスを育てていく」と表現してますが、コンテンツが100件・10万件・1000万件などデータ量次第でUI設計は異なるので、コンテンツ量と調達スピードに応じてアウトプットを変化させていく必要があります。

当然ユーザー数も変化していくため、コンテンツやユーザー数の変化に合わえた最適化を考えていく楽しさがあります。

コンテンツ提供手法の歴史はざっくりこういう変化で、昨今YouTubeなどのレコメンド能力の高さは1ユーザーとしても感じると思います。

・キーワード型(Google):言語化できるキーワードでコンテンツを探す。課題解決したら完了。

 ↓

・フォロー型(Twitter / Pinterest):好きなジャンルや人をフォローして自分好みのコンテンツをタイムラインに表示させる。能動的行動(フォロー)によって自分で表示コンテンツをアジャストする。

 ↓

・レコメンド型(YouTube / Netflix / TikTok):協調フィルタリングによって、ノーフォローで関心度の高いコンテンツが流れてくる。受動的にコンテンツが受け取る。

とはいえ、自社サービスでレコメンドを実現の機械学習に投資すれば必ず成果がでるわけでもありません。

画像12

自社のコンテンツ調達方針や量に応じてデザイン / クラアント / サーバー(データ基盤) どのパラメータを強化して実現するか、ユーザー数に応じて拡張するロードマップ設計もソフトウェアデザインのやりがいだと思います。

ちょうど田川さんがつぶやいてた、BTCモデルを引用しますが自分の職域スキルアプローチで勝負するのではなく、統合的取り組める人の価値は高くなります。

今後10年単位で考えるとDXの流れで大企業のデジタル化、ソフトウェアの内製化は加速し、その時にこの統合スキルが確実に必要になるからです。

画像6

「ビジネス」「テクノロジー」「デザイン」の三要素の結合からイノベーションが生まれる
https://industry-co-creation.com/icc-salon/74

データやユーザーの反応をみてデザインする楽しさ

データとユーザーの声からフィードバックを得られる環境だと、アウトプットの良し悪しがリアルタイムでわかる環境なので、経験値があがっていく感覚が強く持てて楽しいです。

デザインの数値化にアレルギー反応を起こす方も居ますが、デザイナーだけでデザインの数値化は難しく、証明不可能な環境で回答を求められて苦手意識が強くなった人も少なくないと思います。

僕もデータ開発のコツが徐々にわかってきましたが、デザイナーがUI成果を後出しで数値化するのではなく、施策ごとの目標(ファネル)を可視化する、データドリブンな環境を作る、定性意見を集められる開発チームの仕組み化が大事になってきます。

例えばdelyではこんな取り組みを意識しています。

・施策のファネル管理
・UI変化の成果がわかりやすいサイズでのタスク設計
・デイリーでデータを取得して振り返る開発カルチャー
・ユーザーグループ別に出し分けできる開発環境
・結果を振り返って話し合えるチームの維持

下記はサンプルですが、ユーザー意見収集もこのようにサービスに散りばめ、フィードバックを収集してユーザーの気持ちを理解していきます。

スクリーンショット 2020-11-05 15.50.45

ソフトウェアのデザイン現場では、デザインの言語化、説得する力が必要ですが、作ったデザイン = 売上 or DAUに直結させるのはやや乱暴で、KPIツリー、ファネル化する事で、目標を実現していく設計が大事だと思います。

日々のデータやユーザー意見を反映させながら育てていくデザインを覚えると打って響く感覚を持ってデザインできるので楽しいです。

ビジュアルで個性を出したい感情との葛藤

昔は、イケてるポートフォリオを作るのが、デザイナーのアイデンティティで戦闘力だと思ってたけど、ソフトウェアデザインにおけるデザインの定義や価値観は変わってきたように思います。

こんな表現をしましたが、スマホが出現した過渡期ではUIやビジュアルが体系化されてなく差別化や個性が強みの一つでしたが、成熟期になりスマホのUIデザインが標準化されてきました。

Googleはマテリアルデザインのガイドライン、AppleはHuman Interface Guidelines を推奨・推進して整ってきた事や、FigmaなどUIデザインに特化したツールが登場して作りやすくなり、UIデザインに必要なUIテンプレートがシェアされるようになったのも大きいと思います。

僕が、個人でも採用面接でもポートフォリオの見た目に拘らなくなってきたのは、ビジュアル価値が低くなったのではなく、上記で話したそれ以外の価値が高くなったからだと思います。

ソフトウェアデザインは「意匠 × 設計 × データを考える仕事になりました。

・「We」でソフトウェアを作っていくコミュニケーション力
・ソフトウェアデザインに必要な目を鍛えるスキル
・データドリブンなデザイン設計思想
・など

冒頭で「IではなくWeでデザインする」と表現をしましたが、個性も行き過ぎると集団生産性を下げるし、ユーザーに学習コストを求める事にもなるので、ソフトウェアデザインではそのバランスも重要です。

例えば、サンフランシスコのスタートアップ付近で話題になった新しい手法も職種軸では優れているようにみえても、自社のユーザーに適切か今取り入れるかどうかを考えるのもバランス能力の一つです。

ただ、デザイナー界隈で称賛されやすいのは、独自性の高いモノなんですよね。この感情コントロールがとても難しい。僕は個のデザインではなく、サービスを1人格とした一貫性追求を自分のミッションとしてからバランスがとれるようになりました。

デザインが先行するとユーザーファーストではなく、デザインファーストになってしまうので、何事もユーザーが第一優先です。

でも、映えるポートフォリオを作らないとキャリア的に不安が、、、というのもめちゃわかります。例えば、Facebook Product Designer が Facebook Notifications をポートフォリオ化してましたが、このような設計表現もあるので参考になるかもしれません。

ポートフォリオが必要以上に映えてなくても、プロセス設計スキルは会話で表現できます。経営者やプロダクトマネージャーのパートナーとして、上流から巻き込まれるとやりがいも大きく楽しくなってくると思います。

delyでデザインワークをする楽しさ

UIデザイナーとしてクラシル開発が面白いのは、事業フェーズとしてまだ山の2合目位なので、ソフトと組織を育てていく経験が磨ける環境だと考えています。

社長の堀江さんや僕も可能な限り言語化、透明化する努力をしてるので、プレイヤーとしても俯瞰視点の経験を得られやすいと思います。

その例をいくつかあげてみます。

画像3

データドリブンなデザインを実現するために、領域毎にチーム(Squad)をわけた開発体制にシフトしました。

画像4

ピサの斜塔を表現して、長期でサービスを育てるための数値目標や定性目標をすり合わせてソフトウェアの人格一貫性を維持できる努力をしてます。

ハックで局所的に数字が上がっても長期で毀損するし、長期で育てる機能だとしたら、まだ数字目標を求めない領域などを話していきます。

画像5

Squad(チーム)ごとに目標を決めて、具体性の高くデザインを向き合える体制を作っています。デザイン成果の可視化はチームのミッションとして振り替えれるような体制にしています。

こんな感じのデザインに興味があればぜひご連絡ください。

delyの採用ページ
https://join-us.dely.jp/



いいなと思ったら応援しよう!

坪田 朋
よろしければ、サポートお願いいたします! サポート費用は開発チームの料理教室開催費用に充てたいと思います!