nikolog

自分の中でモバイルアプリ/Webサービスのデザインすること = 母親が家族皆に美味しいごはんを作ってあげることだという世界観をもってたりする。今回は「良いチームで良いデザインを作ること」を、「幸せな家庭を築きながらいかに美味しい食事を家族に提供できるか」に置き換えて妄想してみよう。

家族設定

■母(=デザイナー)
皆の話をよく聞いてあげる
世話焼きで優しい、たまに注意してくる

■父(=ビジネス)
前例や数字を気にする
しっかり稼いでくれる

■娘(=ユーザー)
自由気まぐれで流行好き
文句愚痴はよく言う、とりあえずシェアしたい

■息子(=エンジニア)
俺の世界観ある職人っぽい
怠け者にみえるけど実は真面目

ごはんを作るときのポイント(デザインを作るときの注意点)

メニュー/素材やキッチン性能(=サービスの企画/コンテンツの質や開発環境/メンバー)が良ければ美味しいものにはなる可能性が高いけど、いつも最高級品とは限らないので、テクニックや味付けを工夫して今キッチンにあるもので美味しく料理をしていく。
例えば娘がカニ食べたいって言ったら、とりあえずカニカマ使ってでもなんとかアレンジしまくって旨いものを作る。ちょっとした仕込みや調味料で(=情報設計やアイコン/ボタンなどで)めちゃくちゃクオリティ良くなったりするのでそれはもう可能な限り時間をかけたり、経験値や知識でなんとか補ってみる。

他には以下のポイントを気をつけながら作っていく。

■季節(=流行)
時期によって美味しい魚や買えない野菜があるように、時期によってトレンドやユーザーの好みは変わる。GoogleやAppleのガイドライン変更に振り回されてちょっと面倒くさいときがある。まあ本当に旨いものはいつ食べても旨い。

■地域(=ターゲット)
関西関東ではダシが違うように、ターゲットユーザーによって配色やサイズ感などを最適化しないといけない。ちなみに私は関西出身なので関東の蕎麦つゆは苦手。

■盛り付け(=UI設計)
そーめんにはガラス食器が合うように、メニューに合わせて皿の形やフォーク＆スプーンなどの形状は変える。サービスの内容に合わせて、レイアウトやナビゲーション/ボタンは変える。食べやすいように(=使いやすいように)、それぞれの食材の配置(=画像/テキストコンテンツの見せ方)、おしゃれなランチョンマットひいたり音楽かけたりとした外部的な雰囲気づくり(=ガイドライン対応など)はいい感じにしておく。

■味見(=プロトタイプ)
どこまで大根に味が染み込んだか食べてみないと判断できないように、実際に作って動かしてみないと分からないことが出てくる。ざっくりワイヤー/デザイン作って、プロトタイプツールで画面遷移まで確認する。ちょっと塩や水足して味を微調整するように、プロトタイプを作っては壊しの繰り返しで徐々にブラッシュアップする。あくまで味見なので食べ過ぎ注意(=作り込み過ぎ注意)！

■実食(=UX)
どの具材がどうやって食べられるかは人によって様々で、それ次第ではせっかくの料理が台無しになるかもしれない。誰がどう食べるのか(ペルソナ/カスタマージャーニーマップ）をある程度想定した上で料理作っておこう。食べたときの満足度だけでなく、食前の期待感、そして食後の感想（ユーザーレビュー）も想定した作り方をしよう。本当にサービスに満足してくれればユーザー自身が自発的に他人に薦めてくれる。

気難しいパパ、好き嫌い激しい娘、正直何考えてるかは分からないけどよく手伝ってくれる息子が満足できるように、明るく楽しく円満な家庭を築けるような母親の気持ちでデザイン作れるようにあがいてる。
お母ちゃんになんでも言ってごらん！なんでも作ったげるよ！という母性なる広い精神で各関係者の要望をファシリテートしながらデザインすることを大切にしてるタイプなのかな。

この記事書いてたらお腹減ってきたのでさようなら。カレーを食べよう。

はじめまして、nikokoです。

主にスマホアプリ開発をしてる受託制作会社の中の人でして、ディレクションをやる上で自分なりに大切にしていたポイントをまとめてみました。あくまで受託制作(デザイナー兼任ディレクター）というポジションで属人的な内容かもしれませんが悪しからず。

スマホアプリ開発プロジェクトの流れ

■スケジュール

要件定義→設計→デザイン→開発→テスト→Apple審査(iOSのみ)→公開
ディレクター＆デザイナーが画面設計で忙しい間、エンジニアは難しそうな機能(撮影/API連携など)があればロジックだけ先行して実装しておくなど限られたリソースを有効に使おう。テスト期間で仕様変更が発生しやすいのでなるべくテスト日程は長めに確保しておこう。

■設計

担当者のバックグラウンド＆経験値の差が如実に出てしまうところなので、足りないところはチームメンバー内で補完しあうことを心がけよう。はじめはペーパープロトタイプを作って壊して、徐々にデザインやドキュメントに落とし込んでどんどんブラッシュアップしていこう。

■プロトタイプ

階層が深いパターンの場合ほど、面倒くさがらずドキュメント化しよう。その場のノリで理解したつもりになって、後日また同じ議論をして時間を浪費することを防ごう。
同じひとつの画面でもユーザーの利用状況（エラー/ログアウト/有効期間切れなど）で表示内容が異なる場合があると、１つのプロトタイプだけでは足りなくなるので、ドキュメントやプロトタイプの見せ方を工夫して認識齟齬を減らそう。

■Apple審査

Appleは基本的にユーザーの味方のつもりであって、クライアントの味方ではありません。リジェクトされやすいのは課金やポルノ系だけではなく、万人受けしないニッチな機能がある場合はリジェクトされることがあります（特定ユーザーしか知らないキーワード入力は使えないとか)。問題なのはリジェクトによって大幅な仕様変更が発生してスケジュールに影響することです。設計時にガイドラインに引っかからないかチェックしておきましょう。

・課金：定期購入はユーザーが購入したことを認識しやすいステップ＆選択肢を提供したほうが良い(消耗耗型/非消耗型/自動更新購読/非更新購読/無料購読タイプを仕様によって使い分ける）
・ポイント系：ポイント付与はAppleとは関係ない説明文の明記が必要
・プライバシー：メールアドレス入力など個人情報の利用がある場合は利用規約のチェック表示が必要
・UX：画面遷移のステップが多すぎる場合（webviewなど）は嫌煙される

制作者とのコミュニケーション

ディレクターがどこまで細かく指示するかは正直その制作者の技術レベルに依存します。ある程度経験積んだレベルが高い人だと要点だけ伝えて信頼してまかせちゃったほうが良いと思う。まあでもスケジュールや機能の複雑さにもよるので、そこらへんはバランスよくお互い幸せなやり方をいつも模索してる。

■デザイナーと仲良くしよう

・「良い感じ」に頼りすぎない
デザイナーに依頼するときは、せめて最低限の条件(サービス内容/ユーザー像/イメージカラー/優先サイズ/NG事項）を伝えよう。そもそもの目的が意味不明な状態で丸投げしても、迷いのあるデザインしか作成できません。「良い感じ」を乱用しすぎると悪い感じになるので、どうかお気をつけて。

・ワイヤーフレームはあくまで骨組み
ワイヤーを作り込み過ぎちゃうと単なる色付けた清書みたいなデザインになる時があります。ちゃんとデザイナーに頼む場合は想像力の邪魔にならないように配慮したほうが良いかもしれません。あとアプリの場合は特にOSガイドラインに準じているか互いにチェックしておくべし。

・みんなの反応を共有しよう
デザイナーはあくまで自分の中で「これでベストだ！」と思いながらデザインを作成しています。画面上で自己完結してしまっていて、第３者の反応は大丈夫かと気になっていると思うので、クライアントやユーザーの反応はちゃんと共有しておきましょう。放置すると拗ねるかもしれません。

■エンジニアに頑張ってもらおう

・各タスクのステータスを明確にしておく
実装や修正タスクが増えてくると「今一体何をやればいいんだー！」状態に陥ります。エンジニアにはコードを書くことに集中して欲しいので、朝PCを開いてそのチャット文さえ読めば、各タスクのステータス＆優先度が理解できて、今日はこれをやっておけば良いとエンジニア自身が判断しやすいように整えておくのがディレクターとしての理想だったりします。

例）カテゴリ分類は状況によって使い分ける
・ステータス別：対応済み/実装中/テスト中/未着手(Done/Doing/ToDo)
・優先度別：タスク多すぎる時はHigh/Normal/Lowに分けておく
・担当者別：開発側/クライアント側でざっくり分ける
・スケジュール別：特定の日付までのタスクをリスト化する
・QA待ち：回答や素材提供待ちタスクがある場合別途カテゴリを作っておいて担当者に催促しておく

※受託開発だと見積もりの範囲内に収めないと赤字になるので、細かくタスクで管理しておくと備忘録になって、後々大人の交渉の時に役立つ時があります。あくまでチーム内の進捗共有を円滑にすることが目的なので、タスク整理に時間をかけすぎないようにしておこう。

・実装できるか調査して欲しいとき
難易度の高い/工数がかかる機能を実装するときほど必要性(なぜ対応しないといけないのか理由/対応することで発生するメリット)を議論してから取り組んでもらうようにしよう。議論を十分にせずに決定事項だから実装してという乱暴なコミュニケーションをすると後々仕様変更が発生し悲しい出来事が起こりやすいです。

・バグ修正依頼をするとき
今どんな問題が発生していて、どういう状態に修正して欲しいかを明確にしよう。画像/動画/再現条件/正しい仕様の説明を忘れないようにしよう。

例）修正依頼するとき
・現在：送信ボタンをタップしても何も反応しない
・修正：送信ボタンをタップ→メール送信処理を実行→完了ダイアログを表示

クライアントワークの注意点

クライアント社内に作れる/分かる人がいないから、外注で制作会社に頼むというビジネスモデル上、担当者のリテラシーが低いケースが発生します。制作会社が考える「常識」「当たり前」の次元を下げて丁寧なコミュニケーション(なるべく分かりやすい用語＆画像＆図形多め)を心がけよう。

※会社によってクラウド共有NGの場合もあるので要チェック(プロトタイプツール使えなくてヤバい)

海外オフショアでのマネジメント

■チケット駆動開発(TiDD)

うちの会社の場合、Redmineチケットに記載されているタスクはちゃんと対応してくれます。口頭/チャットで垂れ流されたゆるふわな要望は気遣いでやっといてあげるとかはあんまり通用しないことがあるので、常にタスクは明確に伝えておくべし。

■例外系＆ユーザーテストは期待しすぎない

海外在住だと実際に日本国内でユーザーがどうアプリを使うか想像が難しい場合があります。ユーザーテストのプラスαはクライアントと協力して日本側で担保しておいて、最低限の基本要件はテストケースで品質管理しておこう。

■少し英単語を使おう

カテゴリ名やキーワードは英単語を使うとコミュニケーションが円滑になります。日本人が英語の長文読めと言われたら萎えるように、彼らにタスクを連絡する時は、なるべく簡単な単語と記号などを用いたシンプルな文章で説明することをおすすめします。

例）修正依頼するとき
・Present Bug
step1: 送信ボタンをタップ
step2: 何も反応しない
・Expected Result
step1: 送信ボタンをタップ
step2: メール送信処理を実行
step3: 完了ダイアログを表示

■テンション高めで盛り上げよう

重く圧し潰すような雰囲気は萎えるので、ポジティブな雰囲気づくりは結構大事だと思ってます。一緒にがんばろうぜ！的な陽気なノリで接すると、仲良くなって色々頼みやすくなったりします。

ディレクションする上での心構え

■転送屋NG

自分が全然理解していないことを他人に丸投げしてはダメです。転送は人間じゃなくても機械でもできる動作です。ディレクターは相手にとってわかりやすい内容にして伝えるコミュニケーションをしよう。必要性(なぜ対応しないといけないのか理由/対応することで発生するメリット)を企画者と制作者と一緒に議論し、ニーズの少ない不毛な作業は減らしておこう。

■チームで最大公約数のハッピーを目指そう

・自分に非がある時は素直に認めよう
意固地になって周りに迷惑かけている暇あったら、さっさと予防策考えて過ちを繰り返さないようにしよう。ただし自分を責めすぎてメンタルに響かないようにバランス良く。

・周りの感謝を忘れず自分を甘やかしすぎないようにしよう
どこまで妥協していいのか影響範囲を考えておこう。なので余裕もてるように日頃から根回ししておくの結構大事。タスク詰め込みすぎてテンパると正常な判断力が鈍るでしょう。

・チームメンバーひとりひとりを大切にしよう
誰かだけが無理をして、誰かだけがワガママのままなんてことをしていたら、そのチームは長続きできません。楽しくサービスづくりができるように雰囲気良く、そしてチームメンバーの仕事とプライベートのバランスを大切にできるように心がけよう。効率化できるものはスピーディに、不毛なものはタスクから外して、早くお家に帰ってもらって明日から頑張ってもらおう。

※自分の中でチームの定義は、ユーザー/クライアント(企画者)/制作メンバー全部含めたものだと思ってる。

■作る人を尊敬しよう

よく指示/管理する立場にいると「自分」が回せば作れると奢った勘違いをしてしまいます。自分一人ではできないことを他メンバーが実現してくれているのです。エンジニア＆デザイナーはよく分からない専門ソフトを使ってアイデアを形にしてくれる創造主です。作れないあなたは作る人を尊重し、作ることに集中できる環境を提供できるよう根回しましょう。

まとめ

■シンプルなタスク管理＆コミュニケーションを心がけよう
誰がいつ読んでもわかる進捗報告＆タスク依頼をしてコミュニケーションロスを減らしましょう

■リスクに備えて技術的知識や時間的余裕を持とう
リジェクトや仕様変更に振り回されないように日頃から勉強＆スケジューリングしておきましょう

■チームメンバーを大切にしよう
自己満足にならないようにプロジェクト全体のことを考えて行動しましょう

おわりに

アプリディレクションとはこうすべきと偉そうなことを散々いってきましたが、実は今の制作会社は退職して、次は事業会社のデザイナーとして転職します。元々スライド資料自体は、最終出社日に「いままでこうしておいて良かった」「もっとこうしておけば良かった」という遺言的なノリで社内勉強会向けに作成してました。

受託開発/国内/オフショア→自社サービス/外資/スタートアップになってガラリと環境が変わるので、もうこの記事で自分の中のルールは吐き出して、すっぱりさっぱりリセットしようと思います。

以上！