バナーデザインに最適なイメージ・ブレストとは!?（バナーレース竹葉亭うな重カップ）

――――都内某所アスタミューゼ会議室。

マーケtng：「突然ですが、みなさん『イメージ・ブレスト』というのをご存じですか？」

部長srk＆デザイナーkrt：「イメージ・ブレスト!?」
デザイナーkrt：（なにそれ。めんどそう。。）
部長srk：「なんすか、それ？」
マーケtng：「ご存じないですか（まあ、さっき俺が思いついたやつだし）。では説明しましょう」

イメージ・ブレストとは？

みなさん、ブレストは知ってますよね？そう、みんなで意見出し合って他人の意見に乗っかって新しいアイデアどんどん出してくアレです。平たく言うとアレを「言葉」ではなく、「クリエイティブ」でやろうってのが『イメージ・ブレスト』です。てことで、さっそくルールを説明します。

1. まず、テーマ・目的を説明して一旦解散！
2. 共有フォルダに作ったクリエイティブをどんどん入れてく（途中でもいいから。ローカルで作業しない！）
3. 他人のクリエイティブをパクってもいい！（てゆーかむしろパクろう。訴求をパクって別のクリエイティブとか、クリエイティブをパクって別の訴求とか）
4. 定期的に集まって自分のクリエイティブを説明。言葉でも軽くブレスト。で、また解散！
5. これを繰り返してとにかくクリエイティブをいっぱい出す！

マーケtng：「つまり、デザイナーなら言葉じゃなく、クリエイティブでブレストしようってことです！」(｀^´) ﾄﾞﾔｯ!
部長srk：（お前デザイナーじゃねーじゃん）
デザイナーkrt：（やっぱめんどそう。。）
マーケtng：「今回はマンガを使ったバナー制作なんで、バナーレースも開催します！」
部長srk＆デザイナーkrt：「……（なにそれ？）」

バナーレースとは？

1. みなさんが作ったバナーから、配信したいバナー（無記名）を広告ディレクターhtnが選びます。

2. 実際に配信してみて、最も成績のよかったバナーを制作した人に部長が銀座竹葉亭のうな重をご馳走します！

部長srk：「はぁ!?（聞いてねーし）」
デザイナーkrt：（うな重…!?）
マーケtng：「てことで、みなさんよろしくです！」
部長srk：「俺が勝ったらどーすんだよ!?」
マーケtng＆デザイナーkrt：（独りで食えばいーじゃん）
マーケtng：「では一旦解散！」

こんな感じでただの思い付きから始まったイメージ・ブレストのバナーレース（竹葉亭うな重カップ）。果たしてどうなることやら……

エントリーはこちら！

★ぜひ、誰が勝つか予想しながら読み進めてください！

コンテンツ理解度100% × デザインセンス0%　マーケtng
予想：〇（手堅い）	オッズ：1.4倍
本企画の立案者でランディング先の設計もしてることから、理解度は間違いなく断トツ！絶望的なデザインセンスを除けばおそらく順当に勝ち上がってくることでしょう。
低血圧系無気力ガール　デザイナーkrt
予想：△（やる気次第）	オッズ：5.5倍
朝から晩までテンション寝起き状態で間違いなく今回もやる気はない。ただし、未確認情報でマンガ大好き腐女子との噂も…
俺には他にやるべきことがある！　部長srk
予想：▲（流れ次第で大穴）	オッズ：11.0倍
そもそもバナーなんて作ってていいのか？もっと大事な仕事があるだろうに。時間がなくて作ってこないと予想されるが、いいクリエイティブが集まらない場合は部門長の責任感で仕上げてくる可能性もある大穴。

ところが、このレースで誰も予想しなかったことが起きる――――

第一回イメージ・ブレスト（第１コーナー）

――――早くも迎えた第一回ミーティング。で、集まったのがこれ。 ※大きな画像を見たい方はこちらよりご応募ください。

さあ迎えた第１コーナー！
マーケtng、大きくリード！
デザイナーkrt、建前程度に1コ。
部長srk、責任感で作ろうとしたけど直前で断念！

やっぱこうなるか。まぁいいや、やろう。てことで各々軽く自分のクリエイティブを説明。 ところが、デザイナーkrtが作ったクリエイティブの視点が意外とよかったんで、「こうすればいいんじゃない？」とか、「こうゆうのもアリじゃない？」など、第一回ミーティングは思ったより盛り上がりました。最後にもう一度、「他人のクリエイティブをもっとパクってとにかくアイデアを出しましょう」と念押しして会議を閉じました。

これがウォーミングアップになったのか、第二回ミーティングでは予想外の展開に――――

第二回イメージ・ブレスト（第２コーナー）

第二回ミーティングで集まったクリエイティブがまさかのこれ。 ※大きな画像を見たい方はこちらよりご応募ください。

第2コーナーを回って、
マーケtng、第１コーナーの優位にあぐらをかいたか伸び悩み。
デザイナーkrt、マーケtngをおさえてまさかのトップ！
部長srk、やはり脱落コースか!?

パクり合って新しいクリエイティブも生まれています。例えばこんな感じ。 ※もっと見たい方はこちらよりご応募ください。

おお～なんかほんとにブレストっぽくなってる（自分でもびっくり）。
て、喜んでる場合じゃない。
正直、相手は時間ない部長とやる気ないデザイナーなんで、うな重余裕だと思ってたのに、ちょっとピンチです。
（デザイナーkrt、まさかうな重で釣れた!?）

こうして迎えた選考会で、再び衝撃が走る――――

配信バナー選考会（最終コーナー）

――――選考会当日。何も知らない広告ディレクターhtnが選んだのはこちら。 ※大きな画像を見たい方はこちらよりご応募ください。

さあ、いよいよ迎えた最終コーナー！
マーケtng、再び大きくリード！
デザイナーkrt、ここでスタミナ切れか!?
部長srk、やっぱダメなのか!?

最終コーナーでなんとかリードは守れたけど、まさか全員生き残るなんて……
（選考会でみんな締め出そうと思ってた）
ここで、カンのいい読者はエントリーにあったオッズの意味に気づいたかもしれません。
そう、バナーレースの本番はここからです！

この中で最も効果のあったバナーはどれか!?
果たして部長srkはプライドにかけて追い上げることができるのか!?
このあと、配信直後にあるバナーがまさかの快進撃をみせる。
銀座竹葉亭うな重は誰の手に――――!?

配信結果発表

――――選考会で選ばれたバナーを配信して1ヵ月が経ちました。

ある程度結果が予想できたバナーも、やってみるまで誰にも予想できなかったバナーも、様々なクリエイティブを試すことができました。
そしてその中でCPAやCV数などから、優位性のある1枚のクリエイティブが決まりました。

みなさんは誰を予想しましたか？
バナーレースは、アスタミューゼ社内でも予想外の劇的な結末を迎えました。

結果を知りたい方は、ぜひ、
アスタミューゼの募集要項からご応募いただき、
「バナーレースの結果を教えてください」とお伝えください。

みなさまのご応募、心よりお待ちしております m(_ _)m

そうだAsta4dでWebアプリケーションを作ろう(第4回)

Handlerの役割と使い方

Hanlerの話です。
Handlerの役割については色々ありますが、詳しくはJavaフレームワークAsta4Dの話に書いてますのでご覧ください。

今回はコードレベルでどのような形で書けば良いかという観点で書いてます。
動的URLに対して適したHTMLを表示させるというお題をもって説明いこうと思います。

今回のURLルール

package com.astamuse.blog_sample.rules;

import static com.astamuse.asta4d.web.dispatch.HttpMethod.GET;

import com.astamuse.asta4d.web.dispatch.mapping.UrlMappingRuleInitializer;
import com.astamuse.asta4d.web.dispatch.mapping.ext.UrlMappingRuleHelper;

import com.astamuse.blog_sample.Handler;

public class UrlRules implements UrlMappingRuleInitializer{
    public void initUrlMappingRules(UrlMappingRuleHelper rules) {
        rules.add(GET, "/").forward("/html/index.html");
        rules.add(GET, "/part4/{id:[0-9]+}").handler(Handler.class);
    }
}

そんな訳で動的なURLを書いてみました。
前回まで使っていたルールに1行、動的URLを追加してるだけですが。

asta4DのURLルールでは、「{}」内に変数を記載すると動的なURLとして認識され、HandlerやSnippet側でその変数が受け取ることが出来ます。
変数部分には正規表現で変数の内容を縛ることも可能です。
見て分かりますが、今回の場合は数字の場合だけ変数「id」に値が入りURLとして効力が発揮されます。

「/part4/1」「/part4/2」のように「id」の部分が数字の場合はこのURLとして認識されるが、「/part4/a」だと認識されないって感じですね。

で、このURLは今までと違ってforwardする処理が入っていません。
今回は「動的URLに対して適したHTMLを表示させる」ということでfoward先をURLに合わせて変更させなければならないので、Handler内でforward先を指定する実装という形で説明したいと思います。

なお、今回は描画部分のお話ではないのでHTMLやSnippet部分は省略します。

Handlerの実装

package com.astamuse.blog_sample.handler;

import com.astamuse.asta4d.web.annotation.QueryParam;
import com.astamuse.asta4d.web.dispatch.request.RequestHandler;

public class Handler {

    @RequestHandler
    public String handle(Integer id) {
        if(id == null) {
            new RuntimeException();
        }
        return "/html/" + id +".html";
    }
}

ということでHandlerを実装しました。
今回は変数で入ってきたidを元にforward先を決めるだけなので簡易な実装ですね。
実際はもっと複雑と言いたいところですが、複雑な実装になっているHandlerは実使用上でもあまりありません。
基本的にView Firstでは、View以外の実装については複雑にはしないのです。

それでは、1行ずつ見ていきたいと思います。

@RequestHandler
public String handle(Integer id)

@RequestHandlerのアノテーションが記載されたメソッドが最初にコールされます。

引数には、URLルール上に記載された変数を書いておくことで勝手にインジェクションしてくれます。
URLルール以外にも引数に含めておくと勝手にインジェクションしてくれるクラスがあるので、覚えておくと便利です。
HttpServletRequestやHttpServletRequestが該当します(他にもあります)。
リクエストパラメータからなんかしたい場合やレスポンスヘッダを自力でいじりたい場合に使ったりします。

インジェクションされないような変数が引数にあってもエラーにはなりませんが、値には何も入りません。

        if(id == null) {
            new RuntimeException();
        }

ここはNullpo防止対策なので、ノーコメント。

return "/html/" + id +".html";

Handlerの結果を返却します。
Handlerではreturn値に様々な値を設定することが可能となります。
forwardメソッドにはHandlerから返却されたreturn値をもって振り分ける目的のメソッドがあるので、その値を持ってfoward先を決定することも可能です。

そして、今回のようにforward先のhtmlファイルを直接指定することも可能です。
ルール側だとforward先が多岐に渡る場合に困るので、Handler側でhtmlファイルを返却する方法を使ったりした方が良い場合もあります。
まぁ、使い分けですね。

また、RedirectTargetProviderクラスを返却すると強制的に指定されたURLにリダイレクトしてくれます。

void型のHandlerを作成することも出来、その場合はExceptionが発生していなければ次の処理へ遷移します。
今回のケースでそうすると次の処理がないのでエラーになりますが。

Handlerの実使用例

実装の説明と共に、astamuse.comにて実際に使われているケースをざっくり語ることで理解を深めていただければと思います。

• フォームから送信された内容をDBに保存する
• ページを表示するために必要な最低限のデータが存在しているかのチェック
• ログインが必要なページへのアクセス時のチェック
• 外部サイトからのデータ取得(特許画像の取得や公報PDFの取得)
• URL変更時のリダイレクト処理

起動

接続して思った通り表示されていれば大成功。
htmlファイルを用意してないURLにアクセスした場合はTmplateNotFoundExceptionが起きると思いますが、今回の場合はそれでも問題ありません。
(実際の運用上で起きたらまずいけど・・・)

終わりに

ここまでの回の内容が理解出来ればなんとなくWebアプリケーションを作ることは出来ます。
残り2回はプラスα的な内容をお送りしたいと思ってます。

次回予告

次回は、Handlerについてもう少しつっこんでみようと思います。

関連URL

第1回：環境構築して静的ページを表示するまで
第2回：Snippetを使って動的ページを作ろう
第3回：少し複雑なSnippet
第4回：Handlerの役割と使い方(今ここ)
第5回：Global Handlerとattribute
第6回：Form Flowを使おう

どこまでも迷走を続ける採用サイト【後編】

採用サイト制作が始まってから久しいですが、先日（だいぶ前）ようやく公開の運びとなりました…！！！

recruit.astamuse.co.jp

取りあえずは一区切りついてよかったなぁ。
前2回のエントリでは「採用サイト作る作る詐欺」になっており、非常に心苦しくありました…
ということで、本エントリではそんな心苦しさを織り交ぜつつ、制作過程の振り返り及び今後の改修についてアレコレまとめました。

コンテンツ制作

1. どんなコンテンツを作るべきか？

まず始めに、サイトを構築する上で「アスタミューゼに入社することのメリットは何か？」という観点から最適なコンテンツの洗い出しを行いました。

前々回のエントリでも少し触れましたが、話し合いの結果

• 無理な残業が少ない
• 多用な働き方ができる
• 勉強しやすい環境である

といった事が挙げられました。

また、上記を踏まえ「入社後の自分」をイメージしやすくするにはどうすれば良いか？という点について考えたところ

• 自分の現状と比較できるコンテンツ
• 社内がわかるようなコンテンツ

を作ることで入社後のイメージが具体的になり、より興味をもってもらうきっかけになるのではないかという結論に至りました。

次に「入社後の具体的なイメージ」を持って貰うためにはどのようなコンテンツをべきか？ を検討したところ

• 社員の1日
• 前職との比較
• 社内動画

の3つのコンテンツを作ることに決めました。

2. コンテンツ制作過程

2-1.動画

まず「社内がわかるようなコンテンツ」、といったらもう社内の様子を見て貰うのが一番手っ取り早いしウソがありません（演出されていたら別ですが…）。
社内の様子を見てもらえば出社時間から帰社時間、それぞれの仕事の仕方がわかりますし、イメージがしやすくなるでしょう。

しかしながら、ここで1つ問題が。

えー、まぁ何て言うか、正直な話、

デスク周りがお世辞にも綺麗とは言い難い（引越をしたばかりだったので）。

果たしてこれを世に送り出していいものか？

わたしたちは悩みました。

「もうちょっと片付いてからにしよう」

そう結論づけたために現在はちょっとフィルターを掛けてお送りしています。
今後、美しい感じで撮影できたら差し替えたい。
是非ともそうしたい。

もしイイ感じの動画がはまっていたら「ああ、ようやく片付いたんだなぁ…」と思って下さい。

2-2.社員の1日

弊社のデザイン・開発部はフレックス制ということもあって人によって出社・帰社の時間にかなり差があり、また自分に合ったペースで仕事ができる環境なので働き方も様々です。
なのでこちらのコンテンツを参考にしていただくことで「今後一緒に働く人かもしれない人がどんな働き方をしているのか？」「自分のペースでもやれそうかどうか？」など、イメージがし易くなると思います。

しかしながら、またここで1つ問題が。

数名にアンケートを採ってみたら

帰りがみんな揃って定時上がり。

こんな示しを合わせたように定時帰りだと、見ている人にウソだと思われるのでは…？

わたしたちは悩みました。

「でも本当だから仕方ない」

そう結論づけたために現在のコンテンツではみんなは仲良く定時帰りとなっています。
もうちょっとアクロバティックな出退勤の人にアンケートをお願いしてコンテンツを追加したい。
是非ともそうしたい。

コチラのコンテンツは今後もアンケートを採って少しずつ増やしていく予定ですので乞うご期待、です。

2-3.前職との比較

さらにアスタミューゼでの働き方をより具体的にイメージして頂くには、見ている方の現在と弊社を照らし合わせるコンテンツがあると良いのではないかと考えました。
デザイン・開発部の全員を対象にアンケートを採ったのですが、無記名で回答して貰ったので個人を特定されるプレッシャーもない結果だと思います。

しかしながら、またしてもここで1つ問題が、

特になかった。

よかったぁ…

全体の振り返り

今後のために制作を振り返って、良かった点/悪かった点についてまとめました。

良かった点/タメになった点

• 意志決定が早い（方向性が決めやすい・共通認識が持ちやすい）
• 自分たちの裁量で好きなように作れた（いつもと違うことができる）
• 通常業務より広範囲に渡って考えることができる

弊社では通常、デザイン・フロントエンド・開発からそれぞれ1～2人が各プロジェクトに割り振られ、総勢5～7人のチーム体制でサービス運営をしています。
今回の採用サイトの制作・運営はいつもの半分、3人体制でした。
人数が少ない分、スピード感が生まれ、サクサク進められる印象を持ちました。
週に1度のMTGも少人数なので予定を確保しやすく、全体タスクの分量や割り振り、進捗確認もしやすいです。

また、裁量がコチラに任せられているということはモチベーションにも繋がりますし、どうやって流入を増やすか、CVさせるか、どう計測するか、その他諸々、コンテンツを含む全体の流れをより意識した制作ができたと思います。

良くなかった点/苦労した点

• 期限を明確に決められなかった/想定が甘かった
• プロジェクトに対する積極性

やはり期限を明確に決められなかったというのは個人的には痛かったと感じました。
期限もなんとなく、MTGの流れで「これくらいに出来たら(・∀・)ｲｲﾈ!!」くらいの軽さだったのが良くなかったかなぁと今となっては反省です。
また、実際には想定していたよりも実装コストが高かったことと、タスクの兼ね合いでこちらの制作にまで手が回らないメンバーもいたため、途中でスケジュールを組み直して期限を切り直すなどの措置が必要だったと思います。

部長からは「きちんとしたコンテンツを目指すためであれば、多少の遅れはやぶさかではない」とのお達しがあったのですが、それでもあと少しリリースタイミングを意識できれば早めに手を打てたのかも知れない、と思いました。

また、上記と共通する話ではありますが、プロジェクトを進める上で３人のうち３人ともぐいぐいと引っ張るタイプではなかったため、今ひとつ積極性・コミットする力が足りなかったのかもしれないと思い至りました。
なので今後は（一部）ぐいぐいやって行きたいなぁ…となんとなく考えています。

今後の予定

今後の予定としましては、個人的にはPC版のデザインを綺麗にしたいのです。
元々、スマホ版からイイ感じに作っていきましょう、というところから始まったのでちょっとPC版のデザインが今ひとつ。
そこをまずキリッとさせたいな、というのが個人目標。

また、流入経路の確保がまだまだなので、そこら辺が当面の課題です。
ついでに申しますと、弊社Twitterアカウントなどがあるのですが、全然フォローされてない。

astamuse Lab (@astamuseLab) | Twitter

悲しみに暮れています。
これもどうにかした方が良いかなぁって、考えたり、考えなかったり…

もし良い案をお持ちの方、いらっしゃいましたらどうぞコチラからご入社ください。
お待ち申し上げております。