インフラエンジニアの私がプロダクトのデザインに初めて携わって得た知見まとめ
こんにちは、AWS事業本部のShirotaです。
▲ ｯﾀｧｰﾝ!(Enterキー)
メカニカルキーボードデビューを果たしたのですが、文字を打つのがとても快適で楽しいです！
陽気な青軸音に乗せて、早速本題に参りましょう。
ANGEL Dojoに参加しています
現在、同じ部のメンバー計5人でAWS主催の「ANGEL Dojo」というプロジェクトに参加しています。
今回は、そのプロジェクトでの話をする予定なのですが、ANGEL Dojoとはなんぞや？についてが気になる方も多いと思うので、簡単にお話しさせてもらおうと思います。
ANGEL Dojoについて
AWSの公式サイトに記載されている、ANGEL Dojoについての説明を以下に引用します。
ANGEL Dojoでは次世代を担うAPNの若手のエンジニアの方々に、擬似プロジェクトを通じてアジャイル、DevOps、モダンなアプリケーション開発などのクラウドネイティブな手法と、様々なInnovationを作ってきたAmazonの文化と考え方を体験いただくことで、お客様にクラウドの価値を100%届けるための基礎的なスキルを実践を通して身につけていただきます。参加者の皆様はここで培ったスキルと、各パートナーの皆様がお持ちのそれぞれの強みを活かすことでお客様のビジネスを成功に導き、日本のITや経済をさらに成長させる主役、すなわち「APN Next Generation Engineer Leader」になっていただきます。
より詳しい紹介については、以下リンクをご覧下さい。
「日本を元気にする」APN Next Generation Engineer Leaders(ANGEL) Dojo のご紹介
端的にまとめると、 「日本を元気にする」為に色々考えて行動する中で自身のエンジニアとしてのスキルも成長できる 、そんな幕の内弁当のような企画に参加しています。
クラスメソッドチームと私について
今回弊社で若手エンジニア枠に当てはまり、参加したメンバーの傾向の内訳は
- 開発経験が豊富: 2人
- インフラ経験が豊富: 3人(私はこちら)
となっていました。
(それぞれのメンバーのブログは、以下シリーズのリンクから飛べます！是非ご覧下さい)
AWS：ANGEL Dojo ｜ シリーズ ｜ Developers.IO
開発側の二人がコアな機能を作ってくれている間、インフラ側のメンバーもプロダクト周りについての作業を進めています。
私は、その中でもプロダクトのデザインに関する作業を担当する事になりました。
何故担当する事になったかというと、 経験があったとか知見があるとかそういった事は特に無いです。 絵を描く事は元々好きでしたが。
ただただ「 やってみたい！ 」の気持ちで手を上げて、やらせてもらう事になりました。
やる事になった。が、たかを括っていた
「やりたい！」の気持ちは大事だと思っています。
やりたい仕事がやれるのが一番ですよね。
ただし、 やり切るところまでが仕事です。
とりあえず、デザイン周りでやる事になるタスクを切り出してissueを作成し、チームで使っているGitHubのIssueに書き出してみました。
▲ 一応粒度もそれなりに気を付けたつもりだった
基本的にはチームでの話し合いで生じたデザイン関係のタスクをGitHubのIssueにあげて管理し、やり方を自分なりに調べて課題を解決させていくスタイルで進めています。
やり始めた当初は「絵を描いたり使うものを作成するタスクは 基本個人で動くものだし 、今回くらいの規模感のプロジェクトなら 優先度もそこまで高くないし 、 良い感じにまとめておけば後で困らないくらいのものは出せるでしょ 」と、完全に死亡フラグのような思考で課題を立てて作業を進めていたのですが、完全に甘い見立て だった事は作業していくうちに身に沁みて痛いほど分かりました。
一級フラグ建築士の腕前が衰えていなかったようです。
ここからはチーム開発未経験の私が「難しかった」事と、今回問題解決の為にやった事についてお話ししたいと思います。
現在ラストスパートに入ったANJEL Dojoですが、ここまででも得られたものは多々ありました。
私視点の物語を読むようなつもりで読んで頂けますと幸いです。
やり始めて分かる、難しさを感じた事
実際、やり始めてから「難しいな！」と感じた事をまとめたいと思います。
言語で出されたオーダーを画像化する事が難しい
普段から絵を描く機会が個人的に多く、自分の中では絵を完成させるまでのメソッドがある程度完成しているので、「こんなものが欲しい」と言われた場合にはそこまで工数をかけず作業を完了させる事ができるだろうなと思っていました。
ヒアリングさえ済んでしまえば 基本個人で動くもの だと考えてもいました。
ですが、プロダクトで利用するものとなると話が別です。
自分が普段描くものとプロダクト(今回はWebサービスを作成しています)との乖離を合わせる必要や、プロダクトで利用する為の画像サイズや拡張し、dpiと言ったお作法も守る必要があります。
自分一人かつ独学でやってきた身としては、どの粒度でヒアリングするかも、どれだけの候補となる成果物を用意しておくのかも難しかったです。
デザインのいろはを学習する必要性が発生して、完全ゼロからのスタートが難しい
実際にWebサービスとして色々な人が触る可能性のあるサービスを作成する場合、「デザインのいろは」を把握しておく必要性に気付きました。
具体的には、「マテリアルデザイン」や「配色理論」と言った、デザインをする上で根底となる考え方や手法です。
「 良い感じにまとめておけば 」……と初めは考えていたのですが、服を選ぶセンスが悪い事に定評のある私としては、自分が今まで行ってきた事が実に感覚に基づいたもので、一般に受け入れられるものではない事をしていたなと考え直す良いキッカケとなったように思えます。
デザインは想像していたよりも優先度が低いものではなかった為、難しさが増した
デザインは最悪欠けてもプロダクトが良い感じに動けば何とかなるだろうし、正直コアとなる部分からは遠くて優先度も低いし ……と思っていた時期が私にもありました。
ANGEL Dojoでプロダクトに関する中間発表があったり、発表前に社内の人たちにレビューをお願いする中で自分含めメンバーたちが考えた事に、「地味めだがしっかりしているサービスをアプローチする際にビジュアル面は結構大事」だという事がありました。
私たちが現在作成しているプロダクトについては、弊社 Kyoが実際に発表した中間発表に関するブログを見て頂くと分かりやすいかと思います。
ANGEL Dojo中間発表で「問題とミニブログで技術を学ぶ エンジニア向け学習サービス Loop I/O」について話しました ｜ Developers.IO
プロダクトの良さを伝える為には、ファーストインパクトをできればプラスに持っていく事が大事だと思います。
例えば、同じ機能が備わっているアプリケーションやWebサービスが並んでいる場合の選ぶ基準はどうしていますか？
私は内部のUIの操作感などを知る前に、まずは「アイコンの見た目」や「LP(ランディングページ)」を見て「このサービス今っぽいな」「シュッとしていて分かりやすいな」と言った基準で各サービスに点数をつけてものを見ているなと今回プロジェクトに携わっていく中で感じました。
そうした時に、やはりデザインは「優先度が決して低くない」ものになりました。
かつ、みんなで作るプロダクトに組み込むものは特に全体のイメージがちぐはぐになってはいけません。
服を組み合わせてダサいと思われるのは自分の自由ですが、みんなのプロダクトで勝手な組み合わせをしてダサいと思われたくはありません。
こういった様々な「難しい」を感じながら、私は自分ができるデザインを考え、実装を進めていく事になりました。
今回デザイン周りでやった事
実質の実装期間は「一ヶ月」程度しかないANGEL Dojo。
また、平日はみんな普段通り業務に携わっており、まとまったワークデイも週1〜2回しか取る事ができません。
限られた期間の中で、私がやった事や身につけた事、その時便利だったものも併せて紹介します。
プロダクトのロゴを作成する
プロダクトの顔となる、ロゴを作成しました。
その際に意識した事を、以下にまとめました。
- 既存のものに酷似しない
- 一目でサービスの雰囲気が伝わりやすいもの
- シンプルなデザインを心がける
みんなで日々脳をすり減らし話し合ったサービス名やサービスのコンセプトを図に落とし込む為に、まずは手を動かしました。
▲ サービス名が今と違った時のイメージ出し
▲ イメージまで落とし込む過程で大爆発する思考
普段はPC + ペンタブレットと CLIP STUDIO PAINT で絵を描く事が多いのですが、今回は話し合いながらデザインイメージを描いたりする事が多かったので、iPad Pro + MediBangPaint for iPad で手書きのデザイン出しの作業をしました。
元々使い慣れていたツールなので、紙とペンでデザインをするのと同じかそれ以上のパフォーマンスを出せてとても捗りました。
実際にロゴを作成する際には、Webサービスでも利用する為にベクターファイルであるsvgファイルで作成する必要がありました。
ベクターアプリを触った事が無かったので、様々なアプリの情報を調べ、実際にいくつか触ってみました。
その際、初めてでも操作が直感的に分かりやすく、使いやすかったのが Affinity Designer です。
私はこれで、実際にロゴを作成しました。
▲ サービスのイメージをロゴにするの、難しい
プレゼン資料に使うデザインを作成する
プレゼン資料に使うイラストを作成しました。
この中で、はじめに作成したイラストがあったのですが、プレゼン資料と実際のサービスに乗るLPで用いるかもしれない場合とでイメージの乖離が激しかったので、色を使わず、かつデザイン作成の時間短縮の為にマテリアルデザインのアイコンを用いてイラストを作成しました。
はじめ、プレゼン資料で使った際の画像は MediBangPaint for iPad で、その後改めて方針を変えた画像は Affinity Designer で作成しています。
▲ プレゼン資料に合わせて配色を一旦変えている
▲ マテリアルデザインのアイコンを漁りまくった
Webページの配色を編集する
元々、開発を先導してくれていたメンバーが一旦配色をやってくれていたので、そのソースコードを見ながらローカル環境で試行錯誤配色をやっていました。
まず、開発が進むまではイメージの共有がし易く、実際に実装する時の差異が少ないプロトタイプを作成する為に Adobe XD を触りました。
初めて触ったXDだったのですが、チュートリアルも丁寧かつ操作でストレスを感じる事がほぼ無く、快適にプロトタイプを作成する事ができました。
▲ プロトタイプが楽しくて、アニメーションをつけたりして遊んでいた
実際にプロトタイプを作成した後にCSSを出力する事もでき、メインのプロダクトに活かせる可能性があるところも良かったと思います。
また、上記のような配色を決める為にはMaterial-UIの Color tool が大変役に立ちました。
今回プロダクトでReactを利用し、マテリアルデザインを組み込む際にコンポーネントとしてMaterial-UIを利用したので、実際に配色を組み込む際にとても上記サイトが役立ちました。
▲ 組み込む際に便利すぎる
また、そもそもの配色のコツは偶然(！)弊社のデザイナーの方が社内向けに開催してくれた色彩学の勉強会で学べ、実際選んだ色がアクセシビリティの配慮ができているかを確認する為に Color Tester を利用して、背景画像や文字色の調整を行いました。
▲ どの大きさも文字でも見易くなるようにした
デザインはとても大事。学習すればするほど奥が深い！
はじめの認識を見事ひっくり返された私が今回、ANGEL Dojoのプロダクトで手を出したデザイン周りの事は、まとめてみるとこんな感じでした。
実際、知識が無い状態でできる事は予想以上に少なく、実際に勉強して手をつけ始めると学ばないといけない知識は予想以上に大量でした。
開発周りに触れる機会も少ない……と思っていたらそんな事はなく、GitHub慣れしていない為に色々調べながらブランチを切ったりマスターを切り替えたりした事も、少なからず自身の今後の血肉になったのではないかと思っています。
今回のプロジェクトは後少しで終わってしまうのですが、今回広げられた視野を今後も深掘りしていきたいと思います。
また、もっと役に立てるような立ち回り、成果物の作成ができるようになれるよう精進していきます！
オマケ
今回勉強用に見たサイトや本を以下に載せておきます。
