はじめに
最初にはっきり言っておきます。この記事は失敗をもとに書いたものです。
同じ失敗を繰り返さないように、あえて失敗例を書き残します。
参考にしてはいけない部分もあれば、0から作るプロジェクトの全体の流れなど、参考になる部分もあると思います。
それを理解したうえで、どこが失敗の原因か意識しながら読んでいただけると面白いと思います。
かなり長い活動記録になりますが「こんなことやったら当然失敗するって！」「私だったらこうする…」「ど素人が！」など様々なことを思いながら読んでみてください
私について
タイトルにもあるように「ある部活でアプリのUIデザインをメインのタスクとする大学２年生」です。
アプリデザインは昨年（2018年）の夏ごろから勉強し始め、今回のプロジェクトが３回目のデザインでした。
デザインの知識は、頻繁に用いられる基本的な法則などを知っている程度で、経験は上記の通りほとんどありません。
さらに、「デザインのトレースの経験」と「その結果の素材群」も私にはありませんでした。
お恥ずかしながらデザイン初心者というわけです。
さらに、モバイルアプリのプログラミングに関しては経験ゼロでした（プログラミング全体で言えば、Javaを少し学習した程度です）
さらにさらに、グループ開発の経験は2回目で、開発の進め方に関してもど素人です。
やるからにはプロとしての意識を持ってやるべき
というアドバイスをとある方から頂いたので、初心者だからという言い訳などできる環境ではありません
このような状況で、周りにデザインをメインで行う方がいない中、暗中模索で壁に何度もぶつかりながら進んできた過程を書き記します。
ちなみに、私はWindowsユーザーなのでSketchは使えず、デザインはAdobe XDを用いて行っています。（私はAdobeCCのユーザーですが、Adobe XDはそこまで大きな制約なしで無料で使うことができます）
プロジェクトについて
私が所属している部活動では、部員をいくつかのプロジェクトチームに分け、チームごとにテーマを決めてアプリを作成するという活動があります。つまり、締め切りが決まっている状態で企画を決めるということです。企画を成し遂げるための期間を設定するのではなく、期間中に実現できる企画を考えるのです。
私たちのプロジェクトは、大学３年生１名、大学２年生５名の、計６名により構成されました。後に、大学３年生の方が一人参加し、最終的には７人のプロジェクトチームになりました。
人数が少ないので、プロジェクトマネージャとプロジェクトリーダーを、最初からプロジェクトメンバーだった3年生の先輩が兼任しました。
活動記録
以上の条件の下で私がどのような活動を行ってきたかを以下に示します
1. 企画決定
まずは、プロジェクトで作成するものを決めなくてはなりません。
６名で様々な案を出し合い、最終的には多数決により、私たちはある企業に協力を依頼し、その企業の活動を支援するSNSアプリを作成することにしました。
条件は、
- 企業側が設定する締め切りまでに、企業側が使えると判断するアプリを作れた場合はリリースする
- 私たちが作りたいものではなく、企業側に必要とされるものを作る
- 締め切りが部活の活動期間とずれ、短くなる
- 企業側からはPRなどを通してコードレビューをするメンターのような人を付ける
というものです
私たちと企業側（メンター含む）との連絡はSlackを通して行い、完全リモートでの作業になりました
先に言っておきます。
リリースはできませんでした。
2. 具体化
こちらも６人のメンバー全員で話し合いを行いました。
より具体的に方針を決めると同時に、全員の認識を統一するためでもありました。
また、このタイミングでiOS、Androidのアプリ作成をすることを決定し、メンバーの役割を
- iOS：１名
- Android：２名
- サーバー：２名
- デザイン：１名（私）
のように決めました。
後に、デザイン担当の私は、未経験ながらiOSに少しだけ参加することになります。
また、後で加入するメンバーはサーバーに配属されます。
ターゲットの決定
今回はある企業の活動支援ということで、ある程度ターゲットが絞れていましたが、このタイミングでは「企業が提供するサービスのユーザー」をターゲットとしました。また、具体的には書きませんが、アプリのユーザーとする人たちの性別、年齢、職種、経歴などを確認しました。
ターゲットによって、アプリ（機能）の複雑度、デザインの方向性などが自然に決まります。
このターゲット決定には、「企業側が用いているログインサービスを使える」という前提がありました。企業側にも伝達し、使わせていただけるか、否か、は未定というお返事いただきました。
しかし何を思ったのか、このときの私たちは「もし使わせてもらえなかったら？」を考えませんでした。（企画決定に時間をかけすぎたため、慌てていたのかもしれません）
ネタバレになりますが、「このタイミングでは」とあるように、後にターゲット変更が待っています。
搭載機能の決定
SNSといっても、一方的に発信するものもあれば、DMのようなものもあります。どのような機能をメインとするSNSアプリで、サブの機能は何を搭載するか？ということを決めていきました。
話し合いの結果、「アプリユーザー全体に向けた発信とそれに対する返信、賛同、お気に入り」に加え、「詳細なプロフィール」「企業が開催するイベントの宣伝」の機能を搭載することにしました。
この機能を企業側に伝えたところ、メンターの方から、SNSのアプリをリリースするにあたっての注意点を伺いました。通報機能などの管理システムが搭載されていないSNSアプリはリリースできない可能性が高いようなのです。
各OSのアプリガイドラインを読みながら再度、機能を確認し、最終的には、企業側からもOKを頂きました。
3. ワイヤーフレームの作成
ここからは、デザインの仕事ということで、基本的に私ひとりで行いました。
他の役割の方は、機能の工数見積もりをしたり、サーバー言語（Go）の習得をしたりしていました。（このあたりで、7人目のプロジェクトメンバーが加入し、サーバーを担当することになりました）
アプリが搭載する機能をデザインを含まない状態で視覚化したものをワイヤーフレームといいます。
人によってワイヤーフレームの度合いはかなり違うのですが、私の場合は、完成画面から画像（アイコン）、色を抜いたものを作成しました。自分自身では、具体度が高すぎる気がしましたが、企業側に早い段階でアプリに仕様全体を伝えるには高い具体度のワイヤーフレームを作るしかありませんでした。
この段階で、ワイヤーフレームの作成に必要な情報である、アプリの仕様を総確認するとともに、不確定な事項をプロジェクトメンバーに相談し確定させていきました。
また、工数確認をしているモバイルアプリ担当のメンバーから意見（Androidだと厳しい、iOSだとこの方が楽など）も参考に、実装しやすい配置のアプリデザインを心がけていました。
今思えば、デザインをする者として、「ユーザの目線を失う」という大失態を犯していたと思います。デザイナーは最後までユーザーの味方でなくてはならないのです。
この時、私は最新のワイヤーとアプリの仕様をAdobe XDを用いて、プロジェクトメンバーに伝えていました。私の伝え方に問題があったのだと思いますが、度重なる変更によって、いつしか最新の情報を完全に把握していたのは私だけになっていました。会議を開くたびに、少し古い情報が出てきて「そこはこうなった」という話になっていたのです。
ワイヤーフレームも完成し、企業側からのOKも何度かの修正の果てにいただけました。
4. 方針の転換
ワイヤーの作成が終わったころでしょうか。企業側から「企業側が用いているログインシステムを使えるか否か」という質問の回答が返ってきました。答えは「使えない」ということでした。私たちの前提は崩壊しました。
セブンペイの事件で個人情報管理への警戒心が高まり、使用許可が出せないとのことでした。
企業側がサービスに用いているログインシステムが使えないということは、SNSアプリがクローズドコミュニティではなく、オープンコミュニティになるということと同義でした。要は、ターゲットとアプリの目的を変えなくてはいけないということです。
このタイミングで、アプリの全容を把握できているメンバーは私で、いつの間にかアプリの仕様を管理する立場になっていた私は、方針転換の対応策を考えることになりました。
結論としては、ターゲットを企業が提供するサービスのユーザーの条件に合致する人、アプリの目的を企業が提供するサービスの宣伝と入り口にするということになりました。
ここまでは特に問題なかったのです。問題はここからです。
まず、ログイン方法の変更。オープンなSNSなのですから、発言の責任のためにアカウントの作成は必要です。そこでTwitterなどの外部サービスを用いたログインをすることに決定…すると同時にプロジェクトを通して最大の問題が発生しました。
Sign in with Appleの要求です。詳しい説明はここでは省きますが、要は「独自のログインシステム以外のログインサービス（Twitterやファイスブックの認証）を使う場合、Sign in with AppleがないとiOSはリリースできない」ということなのです。
モバイルアプリの実装班も対応を強いられ、プロジェクト全体でかなり混乱しました。
さらに、ログイン要求のタイミングの変更。ヒヤリングで、「アプリを起動してすぐにユーザー登録を要求されるアプリではユーザーを獲得できない」という意見がありました。クローズドコミュニティではなくなり、ユーザーの確保が必要になった私たちは、ログイン要求のタイミングを変えることに踏みきりました。
ログインせずとも、他人の投稿の閲覧だけならできるように変更し、アプリをすぐにアンインストールされないようにしました。
5. モックアップ兼プロトタイプの作成
モックアップは「各画面の完成図」、プロトタイプは「遷移なども含めたアプリ全体の完成形」のイメージです。
私がデザインで用いたAdobe XDは、当時（今はアップデートでかなり変わっています）モックアップとプロトタイプが同じ役割を果たしていました。モックアップを作成し、そこに画面遷移を埋め込むことで、実際のアプリのようにボタンをタップすることで遷移させることができたのです。
これを用いて、完成予想を作成し、共有しました。ワイヤーフレームがかなり具体的だったので、ワイヤーフレームを作る時よりは苦労せずにモックアップは作成できました。（経験が少ない私なのでそれでもかなり苦労しましたが…）
手元で完成したのは9月13日（アプリのリリース判断は11月末）だったと記憶しています。（モックアップ締め切りの寸前で追い込まれた私が悲惨なことを引き起こしたので完成日が記憶に残っています。ちなみに、この事件を発端に私のモチベーションは異常なほど低下します）
その後、企業側からさまざまな変更要求があり、最終的な確定はかなり遅れました。というのも、ワイヤーフレームの段階でもらっていたOKがひっくり返ったためです。どう考えてもワイヤーフレームの段階でしっかりと確認を取らなかった私に責任がありました。
（この時、ほかのプロジェクトメンバーは、アーキテクチャの方針を固めたり、API仕様書をまとめていました）
6. iOSのAPI層
モックアップが完成したので、私の仕事は完了し一時的に手が空きました。
そこで、モックアップの作成と並列し、別のプロジェクトで学んでいたSwift（iOS用の言語）を活かし、このプロジェクトのiOSにも参加することになりました。初めてのiOSアプリ作成でした。
私はAPI層を書くことになり、初めて見るAPI仕様書とにらめっこしながらなんとか書いていきました。といっても、私の先生のコードを参考にしながら、ほぼコピペだったのですが…
不慣れでいろいろな苦労はありましたが、特に難しかったのは、すでにiOSを書いていた方との協力です。度重なるAPI仕様書の変更に対応しきっていない状態で止まっていたため、最新の状態にしようとAPI層を迂闊に変更すると、View側との整合性が取れず、ビルドすら通らなくなってしまうのです。私は本来残すべきコードをコメントアウトするなどして、自分の書くべきところを書き上げ、あとは先任の方に任せるしかありませんでした。
7. その他の雑務
自由に動けることができたので、デザイン、iOS以外にもいくつか作業を行っていました。
アプリの利用規約
企業が提供しているサービスの利用規約や類似サービスの利用規約を参考に、SNSアプリの利用規約を考えました。複数の類似サービスの利用規約を読み、企業の既存の利用規約に追加したり、不要な部分を削除する作業でした。
アプリアイコン
アプリを起動する際にタップするアイコンのことです。
ちなみにUIデザインが多少できても、アイコンが自作できるとは限りません。（イラストを描ける人が似顔絵が得意とは限らないという事実に似ているでしょうか）
私のアイコン作成の経験はUIデザイン以下で作り方を勉強するところから始めました。最終的にはAdobe illustratorを使い、企業の既存サービスのアイコンをアレンジしたものを案として提出しました。（OKも確認できず、どこにも使われることはありませんでしたが）
まとめ
私はこのような流れでタスクを処理してきました。
反省点はたくさんありますが、ほとんどが「経験不足」の一言で片付くのでここには書かないでおきます。ここまで読んでくださった方ならもっと具体的に改善すべき点を見つけていると思いますし…
皆様がプロジェクトを行う際に（教師としてでも、反面教師としてでも）参考になれば…と思います。
皆様のプロジェクトが成功しますように。
最後に宣伝
私と同じプロジェクトグループの方が書いた記事
- プロジェクトマネージャー兼プロジェクトリーダー
- Android 1
- Android 2 は 12月21日公開です
- iOS は 12月19日公開です
- サーバー 1
- サーバー 2