奥多摩日本語学校のプロジェクトを中心とした授業では、自分たちのアイデアを形にしてプレゼンするという活動を通して、日本語の習得を目指しています。今まで「自分たちのアイデアを形にする」ことを、「プロトタイプを製作する」という表現を使って説明していました。しかし、エンジニアにとってわかりやすいと思っていたこの「プロトタイプ」という言葉は、人によってイメージするものがかなり違うということもわかってきました。
そこで、今回の記事では、授業の中で「プロトタイプ」をどのように扱ったのかについて、書いてみたいと思います。授業の中での扱いについて説明していますので、実際のプロダクト開発とは異なる点があるかと思います。エンジニア視点でお読みいただき、「これ、違うなー」など、ご意見がありましたら、ぜひコメントをお願いします！
授業の枠組み
今期の授業では、「アイデアを形にする＝プロトタイプの製作」→「アウトプット」→「フィードバック」→「プロトタイプの再検討」というサイクルを繰り返しながら、自分たちのプロダクトを開発するという枠組みを取り入れました。このとき、どんなものを「プロトタイプ」としてアウトプットするのかということが重要になると考えました。この段階をしっかり示していけば、初めて本格的なプロダクト開発に携わる学生でも、段階を追って、開発が進められるのではないかと考えたからです。
授業は下図の枠組み1 のように行いました。
「プロトタイプ」って何？
しかし、「プロトタイプを製作しよう」といっても、どのような「プロトタイプ」を示せばいいのか、非エンジニアである私には、感覚的によくわかりません。授業の枠組みを考えるときに参考にした「デザイン思考」では「プロトタイピング」が重要視されているということは認識していましたが、「プロトタイプ」の説明を読んでも漠然としているように感じました。いろいろと調べてみたのですが、プロトタイプの種類について、段階的に示しているものはなかなか見つかりませんでした。そんな時に出会ったのが下記の本です。
東京工業大学エンジニアリングデザインプロジェクト, 斉藤滋規, 坂本啓, 竹田陽子, 角征典（2017）『エンジニアのためのデザイン思考入門』（翔泳社）
出版社 翔泳社の本著紹介ページはこちら
著者の一人 角征典さんの本著紹介ページはこちら
東京工業大学エンジニアリングデザインプロジェクト（以下、EDP）は、同校で開講されているPBL(Project-based learning）型の授業です。考え方のベースに、「デザイン思考」が適用され、授業の実例を具体的に紹介しながら、「いかにして新しい価値を生み出すのか」が詳しく説明されています。この実践内容にも非常に共感できたのですが、著書で紹介されている「プロトタイプの種類」が非常にわかりやすく、今までのもやもやがストンと晴れたように思いました。そこで、本著で紹介されている「プロトタイプの種類」を採用し、授業に導入することにしました。
プロトタイプの種類
ここでは、上記の著書をもとに、プロトタイプの種類について紹介します。本著では、プロトタイプについて、下記の7種類が紹介されていました。
なお、下記の「プロトタイプ」については、EDPのWebサイトでも、紹介されています。
「プロトタイプであそぼう」 角征典
1. CEP：Critical Experience Prototype（重要体験プロトタイプ）
2. CFP：Critical Function Prototype（重要機能プロトタイプ）
3. DHP：Dark Horse Prototype（ダークホースプロトタイプ）
4. FKP：FunKtional Prototype（ファンキープロトタイプ）
5. FCP：Functional Prototype
6. XFP：X-is-Finished Prototype（中心機能完成プロトタイプ）
7. VFP：Validated Final Prototype（検証済み最終プロトタイプ）
当校の今期（11月〜12月）までの2ヶ月間では、FKPを目標としました2。
「デザイン思考」の「プロトタイプ製作」では、アイデアをわかりやすく伝えるために、雑でいいから「目に見えるものを作る」ことが重要視されています。しかし、当校のようなプログラマーを中心としたITエンジニアが作る「プロトタイプ」は、必ずしも、ユーザーに対して「目に見えるもの」であるとは限りません。この部分をどのように提示すればよいのか非常に悩みました。
そこで、「プロトタイプの種類」については、著書の説明文をほぼ引用しましたが、プレゼンテーションのポイントを付け加え、アプリケーションのプロトタイプでも、イメージしやすくなるように工夫しました。
学生には、実際に下記のように提示しました。
プロトタイプの段階を示した意義
実際にこのような段階を示してプロトタイプの製作を行い、定期的に「アウトプット→フィードバック」という段階を経たことには、授業を進める上で非常に意義があったと感じています。有効だった点を以下に箇条書きにします。
- どこにポイントをおいて考え、開発を行えばいいのかわかりやすくなった
- 開発時に軽視しがちな「ユーザー」や「課題」について熟考することができた
- どの点に注意してフィードバックを行えばいいのか明確になった
- ポイントを絞ったフィードバックが得やすくなった
このように、開発する側、フィードバックを与える側の双方にとって、意義があったと考えています。が、まだまだ練らなければならない点もありそうです。
以下に、実際に運用してみて感じた課題をまとめます。
ターゲットユーザーに焦点を当てることの難しさ
「デザイン思考」では、まず、ユーザーを理解し、ユーザーのおかれた環境や状況を調査し、「共感する」ことから出発します。実際にユーザーインタビューなどの調査が徹底的に行われるようです。しかし、当校の枠組みでは、自分たちの「開発したいもの」が出発点になっています。それゆえ、なかなかユーザーの目線に立てないことが大きな課題でした。実際に、CEPやCFPの製作がいちばん難航しました。非エンジニアの私から見ると、どんなに技術的にすばらしいものであったとしても、ユーザーが使いたいと思わなかったら、意味がないのではないかと思うのですが、どうしても技術面に焦点が当たってしまうようでした。
また、「ターゲットユーザー」の捉え方にも理解に幅があったようです。どんな人のどんな課題を解決したいのかという意図で「ターゲットユーザー」はだれかを問うのですが、開発したプロダクトを使うことができる人という意味で「ターゲットユーザー」を考えてしまう傾向があるように思いました。「使いやすい」＝「どんな人でも使える」＝「幅広い対象者」という発想があるのではないかと感じました。「ユーザーフレンドリー」という言葉もありますが、この「ユーザー」とはだれかというのは、引き続き、考えていく必要がありそうです。
課題とは何か
「ターゲットユーザー」にも関係してくるのですが、解決すべき「課題」とは何かを考えることも難しいようでした。例えば、ゲームを作りたいと考えたとき、そこにどんな課題があるのかというのは、そもそも、問いとして成り立たないのではないかと思うこともありました。
徹底的にユーザーの調査をし、そこから課題を見出す「デザイン思考」と違い、その過程をスキップしているので、この点を求めるのは無理があったのではと、授業の枠組み自体を、もう一度、練り直す必要があるのではないかとも思いました。調査期間をもっと多く取ってもいいのではないかと思います。
エンジニアにどこまで求めるのか
当校は、厳密には、エンジニア養成学校ではなく、「日本語学校」です。ですから、もっと「人」に注目し、多くの人と言葉を交わしながら言語を学んでいくことに意義があると考えています。そのような意図があって、より「ユーザー」に焦点を置いた授業の枠組みを考えました。私の考えでは、「ユーザー」の気持ちや視点を考えられるエンジニアになってほしいと思っています。
しかし、この点を強調すると、手を動かすよりも、頭で考えることが多くなってしまうように思いました。非エンジニアの私が「エンジニアって最高！」と思わせる授業の枠組みを考えることの難しさも感じました。私がなんと言おうと、ゴリゴリ手を動かして、「どうだ！」と言わせるものを開発してほしいですけどね。
最後に
なんだか課題ばかりですが、実際に「プロトタイプ」の製作を中心とした授業を行ってみて、感じたこと、考えたことをまとめました。実際、エンジニアの視点からみて、授業の方針やプロトタイプの示し方など、ぜひご意見を伺いたいです。コメント、お待ちしております。
最後までお読みいただきありがとうござました！