アプリデザイン総合演習のすゝめ
Outline
和歌山大学屈指の難関授業、アプリデザイン総合演習への向き合い方をまとめた備忘録です。
これ is 何
この記事は一介の学生が制作したものであり、内容の正確性などは一切保証できません。あくまで参考程度に楽しんでください。
- 和歌山大学のシステム工学部3年に存在する難関授業、アプリデザイン総合演習への向き合い方を雑然とまとめた備忘録です。
- 想定する読者は受講を決めた、または迷っている学生の皆さんです。そうでない方はわりとチンプンカンプンかも。
- して良かったこと、した方が良かったこと、使って便利だったツールなどが記事のメインですが、ところどころに愚痴も混ざります。
本題の前にちょっと自慢
アプリデザイン総合演習の最終プレゼンで、なんと 1位を獲得できました! 嬉しい!
また、制作物を 第14回e-ZUKAスマートアプリコンテスト2025 に応募したところ、株式会社TRIART様よりTRIART賞を受賞しました! すごく嬉しい!
僕一人では到底なしえなかった快挙だと思っています。携わってくれた全ての人、特に企画から実装、発表に至るまで、僕のおんぶに抱っこを支えてくれた宇都宮くんと山﨑くんには感謝しかありません。本当にありがとう…!!!
アプデザってどんな感じ?
ここから本題です。
アプリデザイン総合演習(以下、アプデザ)は一言で言うならば、「修行」です。
従来の授業とはまるで比較にならないレベルで授業時間外のリソースを割かなければいけませんし、めちゃくちゃがんばった果てに得られるのはたったの2単位です。
…正直な話、タイムパフォーマンスといった観点からすると最悪の授業です。なので、とにかく楽して単位を取りたい人には全くお勧めできません。避けるべきです。
ですが、複数人で一つのプロダクトを企画・実装・プレゼンまで一気通貫に体験できる機会はそうありませんし、せっかく和歌山大学システム工学部に入ったなら受講するべき授業だと思います。特に、やる気のある学生の方や、将来SEやUI/UXデザインを志望する人にとっては最高の授業だと思います。
授業のざっくりした流れ
シラバスを見ればわかる話ではあるのですが、改めてざっくりとした流れを置いておきます。ただし、年度ごとに微妙な揺れがあるかも知れません。2025年度はこんな感じだったんだな〜程度に見てください。
① 個人企画書の作成
- 初回の授業でいきなり、「来週までに作りたいアプリのアイデアをA4で1枚にまとめてプレゼンできる状態にしておいてね!」と言われます。
- いわゆるピッチと呼ばれる手法で、ハッカソンなんかではよくある形式です。
- ここでのアイデアは仮のものなので、完璧である必要はありません。
- …が、本当にいきなりなのでかなり焦ります。あらかじめ心構えと準備をしておくといいと思います。
② 個人企画書の発表と大グループ決め
- それぞれの発表を聞き、自分がいいな〜と思った人の元に集結して大グループを作ります。
- もちろんアイデアに自信のある人/人たちは「我/我らの元に集え!」もできます。
- 割とグダりやすいので、あらかじめメンバーは目星をつけておくといいかも。
③ アイデア出しと発表
- 大グループができたらその中でアイデアをブラッシュアップします。
- ここで全体的な方向性を決めるイメージです。
- 決まったイメージを動画にし、発表します。
- ぶっちゃけここでは最低限、小綺麗ぐらいのクオリティでOKです。
④ グループ分割
- ついに大グループを2~3つに再分割し、実装用のチームに分かれます。
- グループ分割の際には、個々人のスキルに気を配ってバランスよく分けると後がやりやすいです。
⑤ 企画書を全力で通す
- 実は一番しんどいかもしれない工程です…。
- 指導教員/TAの半数以上からGOサインをもらう必要があります。
- 一発通過はまず不可能なので、そのつもりで挑むとダメージが少なく済みます。
- 切り抜けるためのコツは、後の「企画書を通すための工夫」にまとめています!
⑥ 企画書に基づいて実装する
- ここまで来れば手を動かすのみです。
- ひたすら授業最終盤まで手を動かし続けることになると思います。
⑦ プレゼン用の資料を作る
- 最終発表用のプレゼンを作ります。
- どれだけいいものを作っても、発表が地味だとなかなか評価されない傾向にあります。
- 内容はセールス全開にした方がウケがいいです。
具体例(サンプル: 僕)
つらつらと内容を文字だけで書かれてもいまいちイメージしにくいと思うので、見せられる範囲で僕がどんなものを作ったかをお見せします。
個人企画書
- 企画をどうしても通したかったので、ここは頑張りました。
- ぶっちゃけると、内容よりもインパクト優先です。
企画書(草案)
- 清書の前にチームのみんなで作成した草案です。
- これを元にして清書を作っていきました。
企画書(清書)
- 草案をもとに作成した清書です。内容はチーム全員で考え、それを元に僕がデザインをしました。
- 指導教員の方々が僕たちのチームの主張をすぐに理解できるよう、メリハリに気をつけて作りました。
- 実は一度リテイクを食らっており、ほぼ同じ主張にも関わらずイチから作り直しています…。何のための草案だ…。
最終プレゼン用動画
- チームメンバーが本当に頑張ってくれたおかげでとっても良いものができたので(助けられてばかりでした…)、何としても良い結果を残したい!とここも頑張りました。
- AppleやNotionのプレゼンテーション動画を参考に動画を構成しました。
- ここは内容もインパクトもどっちも欲張って作りました。こういう動画は詰め込みすぎってぐらいがちょうどいい気がします。
企画書を通すための工夫
アプデザ最初にして最大の難関が、企画書の作成です。
…この工程は、一旦すべての担当教員とTAのことが嫌いになります。でもこれは仕方のないことです。
あくまで参考程度ですが、以下に僕がいたチームが実施して効果的だったアプローチを紹介します。
アイデアの組み合わせで新しさを出す
- 思いつく単一のアイデアのほぼ100%はすでに誰かが実現しています。
- なので、それらの新しい組み合わせで新規性を出すとやりやすいと思います。
- ただし、「〇〇×AI」みたいな、AI使ってより便利に!的なアイデアは思いつきがちですが、実装の時に地獄を見がちので慎重に…。
一旦、複数人に草案を見せる
- 完成した企画書を教員に見せても、最初はほぼ100%却下されます。
- そこで、草案段階で複数の先生に一旦見せた方がいいです。
- そこでもらったフィードバックをもとに手を入れて、清書を完成させるのが結局一番早い気がします。
ターゲットとなる教員を絞る
- アプデザの担当教員の方々はそれぞれスタンスに若干のブレがあります。
- 草案を見せた時の感触をもとに「この人で勝負する!」「この人は諦める」を決めておくと案外すんなりいきます。
- また、授業が進むと各班の進捗状況が一覧になっているエクセルシートがチラ見できるのですが、そこで基準が甘い教員/厳しい教員をチラ見するという手もあります。
セールスにならないようにする
- 企画書という字面に引っ張られて、つい「このプロダクトはすごいんです!」みたいなことを書きがちですが、そう書くと「いやそうじゃない」とリテイクになります(なりました)。
- イメージとしては普段のレポートの方が近いです。「こういう問題がある、我々はそれをこう解決する」というお決まりのパターンのやつです。
実装時の心構え
晴れて企画が通れば実装です。が、なかなかこれが一筋縄ではいきません。僕の屍を踏み越えてもらうべく、自戒を兼ねて注意すべき点を以下にまとめました。
工程計画表は飾りになる
- 企画書と同時に作成する、全体のスケジュール管理のための工程計画表ですが、ほぼ確実に飾りになります。
- そして大体はバグや時間のなさで計画が後ろに倒れます。
- 最初から当てにせず、後述する GitHub Project などでアジャイル開発を管理したほうが良いです。
Gitは最初に勉強すべし
- ほぼどの班でも採用することになるであろうGitですが、多分みんなわかっていません(僕もそうでした…)。
- 最初にGit(+GitHub)の導入をめんどくさがると、後から確実に地獄を見る or 作業負担が不均衡になって人間関係に悪影響をきたすこととなります。これはほぼ確実です。
- お互いが干渉せずに快適に作業に取り組めるよう、最初に勉強会を開くなどして全員が理解している状態にすることを強くお勧めします。
AIは便利だが、頼り切ると裏切られる
- 最近のAIは凄まじく、かなり強力な助っ人となり得ます。
- が、それにかまけて頼り切ると、普通にバグを埋め込んできてどうにもならなくなります。
- 普通に自分で書いた方が早いケースも多く(終盤は特にそう)、勉強はやはり必須です。
コメントは必ず残すようにする
- 複数人で作業をしていると、前の人の作業を引き継ぐことが普通に出てきます。
- 他人のコードは読みにくいことがほとんどです。
- せめて機能単位でコメントを残しておいた方が絶対にいいです。
使って便利だったツール・サービス
授業を進める上で、使って便利だったツールやサービスを紹介します。
Miro
- マインドマップを複数人で簡単に編集できるサービスです。
- 文字はもちろん、画像・URL・ファイルも貼れるので、企画段階で活躍しました。
Notion
- チーム間で共有しておきたい情報をちゃんとまとめる時や、企画書の下書きなど、さまざまな場面で重宝しました。
- データベース機能が特に強力で、使いこなせれば非常に有用ですが、学習コストがやや高いのがネックではあります。
GitHub
- チーム開発するならほぼ確実に使うことになるはずです。
- 他の選択肢として GitLab などもありますが、特にこだわりがない限りGitHubでいいと思います。
- 特にGitHub Projectが素晴らしく、これを用いてタスク管理をすると効率的です。
- GitやGitHub、Projectの使い方は 公式が日本語で丁寧に解説を用意してくれている ので、かなり心強いです!
GitGraph
- Gitの操作履歴をVSCode上でいい感じにツリー表示してくれるVSCode用拡張機能です。
- 似たような拡張機能としては GitLens も有名ですが、GitGraphの方がシンプルで扱いやすいと思います。
- またGitの各種操作をGUIで操作できるようにもなります。便利!
Bun
ここまでの四つとは異なり、Bunは必要に迫られるユーザが極めて限定的です。
- Node.jsを過去のものにする、高速なJavaScriptランタイムです。
- Node.jsでやっていたことはほとんどできて、それでいて圧倒的に高速です。
- 使わない手はない!
Adobe CC
- IllustratorやPhotoshop、XD、Premiere Proなど、主にプレゼン素材の作成にAdobe CCのソフト群は大活躍しました。
- が、有料ソフトウェアなのでハードルは高いです。
- 学術情報センターに行けばこれらのソフト群が使える(らしい)ので、デザインをガチりたい方は一考の余地あり。
その他、ちょっと思ったこと
グループのメンバーが9割?
- グループワークの授業なので、メンバーがものすごく大事。
- ここさえクリアしたらあとはどうにでもなる節があったり、なかったり…。
- なので受講時には気心の知れた友人が自分含め3人以上いると安心できると思います。
スマホアプリの開発は想像よりもめんどくさい
- 授業名からアプリ開発に引っ張られがちですが、多分想像以上にめんどくさいと思います。
- なぜなら正攻法でiPhone向けアプリを開発しようとすると、Macがほぼ必須だからです。
- これを回避する方法はもちろんある(Flutter や React Native など)が、ちょっとクセはあります。
- なのでスマホで何か動かしたいならWebアプリも検討するべきだと思います。
想像以上にガチ指摘が飛んでくる
- 熱心な指導の一環とは理解しているのですが、それでもちょっとびっくりするかも知れません。
- 僕は某先生にリテイク前の仕様書を見せた時、開口一番「気持ち悪い!」と言われました(ここまでのはレアケースですが)。
- でも最終的には「文句なし!」と言われたのですから、その時の嬉しさたるや。
もうちょっと単位をくれたっていい
- これは愚痴です。
- これと教養が同じ2単位とは…ちょっと信じがたい部分があります。
- …せめて4単位は欲しい。
終わりに
長々と書きましたが、1%でも後輩の皆さんのお役に立てたら幸いです。 この記事はいくらでもぶん回してもらって構いませんので、どんどん共有してください。僕が喜びます。
アプデザは、個人的には非常に有意義でやりがいのある授業だと思うので、後輩の皆さんには臆さず楽しく受講して欲しいと思っています。
それでは。