見出し画像

モックを作る時、依頼する時に、心の隅においておきたいこと

PARTY

PARTYでテクニカルディレクターをやっている梶原です。今回は「モック制作」についてです。

モックとは何か？

モックとは、モックアップ。試作品のことですね。プロトタイプという言い方をされたりもしますが、プロトタイプのさらに手前の、荒削り全開な「実際に動いて触れるもの」という感じでしょうか。


なぜモックを作るのか？

みんなが思っている以上に、人間の想像力は豊かではありません。それは、PARTYの様なデジタル・テクニカル畑のクリエイティブディレクターやプロデューサーやディレクターも、なんならエンジニアだって同様です。
みんな、「実際に動くもの」を見て、初めて色々な想像力が働くものです。
なので、まだ形になっていないし、実際どうやって動作するかも想像の段階のことに関して、あれやこれや議論をする時間があるくらいなら、モックを作ってしまう方がよほど素早くアイデアのイテレーションができますし、ブラッシュアップもできるわけです。
エンジニアがそういうアイデアの火種だったり触媒を用意することで、チーム全体のアイデアをドライブさせることができます。


モックのポジな部分


● 提案時の必勝パターン
モックがあると勝率が爆上がりします。
特に前例が少ないアイデアの提案の時ほど決め手になります。
どれだけ言葉を尽くしても、実際動くものがあるという説得力には敵わないものです。

● フィジビリティ確認が迅速になる
何ができて何ができないのか？をいち早く理解しておくことでバックアッププランも用意しやすくなります。
同時に、提案時に懸念が出た際に先回りして別の切り口での提案を用意しておくことが可能です。

● 新しい機材を買う理由になる
だってモック作るのに必要だから。
結果、他社にはない提案や手法の引き出しが増えます。だってみんな無駄な出費は避けたがるから。結果、新しい技術を使った施策が提案できる。
つまり、実装がチャレンジングで、たのしい案件になります。
そして、手を動かす人が楽しみながらできた成果物は、それに触れた人を感動させられる確率も高いものです（僕の経験的に、ですが）。
なので、この部分に関しては是非お金を出す層（プロデューサーや経営陣ですかね？）の皆様の心に刻んでいただけると嬉しいですね。

● エンジニアとしての引き出しが増える
新しい機材で新しい開発環境を試し、未知のエラーやネットに情報のない未踏の世界を開拓していくスキルや（エンジニアに最も大事な！）勘が身につきます。
未知の技術のデバッグや開拓は想像以上にエンジニアとしての勘を研ぎ澄ませ、危機回避能力を高めてくれるので、特に様々な技術領域を横断した知見をもつ必要のあるテクニカルディレクター系の職能の人にとってはむしろ必須の経験値となります。

● ブログ記事のネタになる
失敗してもうまく行っても、みんなの知見に役に立つ記事が量産できます。


と、いいことだらけです。
が、デメリットもあります。

モックのネガな部分

● 効率とは真逆の行為である
ひどく完成度の低い駄作を作ったり、無駄な手を動かしたり。直接的にはとても非効率な作業です。
なので、プログラミングで試行錯誤するのを楽しめる、いわゆるものづくりが「手段」でなく「目的」な人でないと苦痛なシーンが多い様に見受けられます。

● 時間がかかる
そう、思ったより時間がかかります。実際、ささっとできるほど簡単なものではありません。
エンジニア自身が思っていたよりも時間と精神的コストがかかることが多いですし、非エンジニアが思うよりずっとずっと時間や精神的コストがかかるものです。

● はやければ半年後には無用の長物になる
機能が改善され、SDKが改善され、別の製品が出現していくので、モックで頑張ったもの・無理やりハックしたものなど、具体的な知識や手法が長い期間そのまま使えることは稀です。


この様なデメリットが故に、一見非常に高コストな行為に思われがちで、多くのベンダーや開発者はモックを面倒くさがってあまりやりません。だって売り上げに直接繋がらないですし。


モックづくりの心構え


実際にモックを作ってみようという時に、心の隅においておくといい心構え的なものを、僕の経験値からいくつか挙げておきます。
モックの手法は色々あるので、あくまで一例として参考までに。

● 自分が本当に興味あることに絞る
シンプルだけど、とても大事なことです。楽しいは正義。

● 自分の領域に引き込む
モック対象はさまざまな領域に及びます。
しかし、Exampleをビルドするだけではモックアップとはいえません。
世にでた新しいデバイスやSDK、手法を、自分の得意な領域に統合しましょう。
そうすることで、「実用的な」知識が得られます。
iOSが得意ならiOSの機能として統合する。C++が得意ならC++の領域に。ゲームエンジンならゲームエンジンで使えるようにしてみるなど。
自分の扱えるプラットフォームが少ない場合、

それを広げる
自分の領域でつかえるモックに絞る

を検討しましょう。

● 他人が触れる形にする
他人が触れるようにして、ラップトップに仕込んでおきましょう。
ちょっとしたときに「そういえばこの前モック作ったんで、、、」とラップトップを開くだけで、なんかこいつすごいプログラマだぞ感がでます。なるべく人に（特に身内の別の職能の人たちに）見せるのが大事です。
エンジニア同士よりも、ディレクターやプロデューサー、デザイナーなどに見せると思わぬシナジーが生まれるのでオススメです。

● プロジェクトは小さく、最適化しすぎない
例えば機能は違うが同じ様なコードをつかう場合、どうしても同一プロジェクトでやりたくなったりしますが、いっそプロジェクトごと違うものにした方が後々助かったりします。
一つのモック・プロジェクトは極力小さく、手書きのメモとなるように気をつけましょう。
クラス設計も雑な方が使いまわしやすいです。
大げさなドキュメントもいらないです。ハマりどころをコメントしておけばいいだけ。

● 素早く手を動かし始める
「やったことある人」と「知っている人」との間には天地の差があります。
コードが汚くてもいいし、動作がもっさりしていてもいいし、設計が雑でもいいので、「やってみる」のが大事です。

● ただし、素早く作れる人なんていない
ここ超大事で、モックだからってささっと作れる人なんていません。
しょうもないことでハマるし、とにかく進捗悪いし、自分頭悪すぎるっていう自己嫌悪に襲われまくり、自分の知識やスキルの無さに打ちひしがれるのがモック制作です。
なので「素早く」というのは上記の「素早く手を動かし始める」というこの一点のことを指すというのを心に留めておきましょう。
深さのわからないけど楽しそうな沼に、ノールックで飛び込めるようになると上級者です。

● 手離れ良く。沼が深すぎたら早期撤退。大丈夫。なにも残らなくても意外とその点が線で繋がる瞬間が訪れる。
とはいえ、飛び込んでみたもののにっちもさっちも行かなかったら、近くのエンジニアに聞いてみて、それでもダメそうなら潔く「攻めの撤退」をしましょう。来月には世界の誰かが解決してくれてるハズ。いや、来月の自分もきっとレベルアップしてるハズ。そして、ハマって撤退しても、その点があとで線で繋がる瞬間が結構あります。レベルアップの音が聞こえる最高に気持ちの良い瞬間なので、形にならなくてもトライし、失敗しても未来に向けた成長点を刻んだと思っておきましょう。


Exampleの扱い方


多くの場合Exampleプロジェクトが提供されています。
多くの人がハマりがちなExampleの罠があるので、向き合い方、扱い方のコツも記載しておきます。

● ビルドしただけで満足しない
ビルドするのは大事ですが（そもそもスルッとビルドできる事自体稀）、それだと後にカスタマイズができません。また、スキルの向上にも（そこまで）繋がりません。

● コピペしまくらない
プログラマなら、それがなんのコードかよく知らないのにコピペするなんてやったりしないですよね。
最低限、どんなことやってるのかは解読しておきましょう。わからなければ一つずつ調べればよいのです。そして、それがものすごい勉強になります。

● その機能をテストするのに、最小限のコードで作ったプロジェクトを作成する
これが僕が経験上一番いろんなことに役に立つモックの手法です。
例外処理？いりません。便利なヘルパークラス？いりません。50行以上を一つのファイルに書かない？さくっとまとまるなら500行でもまとめて書いちゃいましょう。
一般的に、提供されるExampleプロジェクトは多くの余分な（Example「製品」としては必要なのですが）コードが記載されています。
それらを除外していって、要は何を書けばその機能が実装できるのか？を解読して、自分でミニマムのコードを書くってのが非常に学習効率が高く、汎用性もたかい手法です。
ミニマムなコードは改変が容易で、様々なプラットフォームに移植ができます。
実際の案件のときに例外処理とか書けばいいのです。

● 時間がない場合？Exampleを改変する
とはいえ、そんなこと言ってらんないときもあります。
そういう時はExampleを改変してモックとせざるを得ないでしょう。しかし、その後のことを考えるとやはりミニマムなコードに分解しておくべきです。


最後に、モックを積み上げて再利用可能な状態にしておく


モックが完成品として日の目を見るには、それを使った内容の提案をするクリエイティブディレクターやプロデューサーといったレイヤーの人の目に留まりやすい場所に置いておく必要があります。
もちろん、エンジニアが直接提案出来れば最高でしょうね。
(＊PARTYはそんな会社なので、是非ジョインしてみてください。未来の体験を社会にインストールすべく、好奇心旺盛なエンジニアはいつでも募集してますよ！)

定期的にモックが製作可能であれば、月一度の「モック見本市」的な、そういうのを用意しておくとより良いかもしれないですね。

▼PARTYの募集職種一覧はこちら


この記事が気に入ったらサポートをしてみませんか？