Akatsuki Hackers Lab | 株式会社アカツキ(Akatsuki Inc.)

Akatsuki Hackers Labは株式会社アカツキが運営しています。

GLSL SandBoxで手軽にレイマーチングで遊ぼう

この記事は Akatsuki Advent Calendar 2018 - Adventar 1日目の記事です。

はじめに

 こんにちは。クライアントエンジニアのRiyaaaaaです。

 皆さんは最近シェーダーを書いていますか? 私はあんまり書いていないですね。
 長らく触れないと、カンが鈍りがちになりますよね。なので、定期的に簡単なものでも書いたり作ったりすることは脳の体操にも効果的です。

 しかし、いざシェーダーを書こう!と思っても、ゲームエンジニアにとってはシェーダーはゲームやレンダラーと密接に結びついていて、手軽に何かを試すというのは難しかったりします。UnityやUnreal Engine4をわざわざ起動するのも億劫ですよね。
 そんな時、GLSL(OpenGL Shading Language)をWeb上でコーディングできるサービスがオススメです。有名なところだとGLSL Sandbox GalleryShadertoy BETAですね。
 
 今回はGLSL Sandbox Galleryを使った、リアルタイムアニメーションCG(デモシーン)の作成の流れを紹介しようと思います。
 この記事で皆さんが手軽にGLSLを触るようになり、レイマーチングをはじめとするリアルタイムレンダリングに興味を持っていただければ幸いです。

GLSL Sandboxの基本

 このサイトは、ピクセルシェーダーをリアルタイムにコーディングできるサイトです。こちら使い方は非常にシンプルで、GLSLを記述するとリアルタイムに変更が背景に反映されます。基本的な仕様は以下となります。
 
 ・gl_FragCoordに現在処理の対象となっているピクセルの座標が二次元ベクトルとして定義されます。 (定義域:(0, 0) ~ (xの解像度、yの解像度))
 ・gl_FragColorにそのピクセルの色をRGBAの4次元ベクトルで設定します。(値域:(0, 0, 0, 0) ~ (1, 1, 1, 1))

 試しに、gl_FragColorにRGB成分が全て0.5のベクトルを代入してみましょう。

// floatの精度を指定します
precision mediump float;

uniform float time;
uniform vec2 resolution;
uniform vec2 mouse;

void main( void ) {
	gl_FragColor = vec4(0.5, 0.5, 0.5, 1.0);
}

 GLSL Sandboxでは3つのuniform変数が使えます。timeは経過時間resolutionはウィンドウの解像度、mouseは現在マウスがフォーカスしている座標です。mouse、resolutionはgl_FragCoordと同じ定義域を持ちます。

 このコードでは座標(gl_FragCoord)に関わらず一様に(0.5, 0.5, 0.5)の色を代入しているので、画面は全て灰色に染まることでしょう。また、数字を変化させるとリアルタイムに背景の色が変わって行くのがわかると思います。

 次に、座標を色で表してみます。ここで、座標(gl_FragCoord)は(0, 0)からresolution.xyの値をとりますが、色は0から1で指定しなくてはならないので、座標を0 ~ 1で正規化しましょう。

// 省略

void main( void ) {
        vec2 p = gl_FragCoord.xy / max(resolution.x, resolution.y);
	gl_FragColor = vec4(p, 0.0, 1.0);
}

 main関数を上記のように書き換えると、こんな画面が描画されることと思います。

f:id:riyaaaaasan:20181122142018p:plain

 R, G成分をX, Y座標に対応させているので、右に行けば行くほど赤く、上に行けば行くほど緑に近づいていきます。(縦横比が違う場合、厳密には短い方は0~1で正規化はできていません)

 GLSL Sandboxの基本的な解説は済んだので、本題のレイマーチングをこのGLSL Sandboxの上で実装してみましょう。

レイマーチングの基本

 レイマーチングとは、広義のレイトレーシングの一つです。カメラからレイを飛ばし、色を決定するところまでは同じですが、レイマーチングではレイの交差判定に距離関数というものを使います。距離関数とは、ある集合の中の二点の距離を定義する関数です。もっとも有名なのはユークリッド距離関数で、一般的な人間の感覚における「距離」を示す関数です。ユークリッド距離関数は距離関数の一つですが、ユークリッド距離関数 ≠ 距離関数であることには注意しましょう。

 つまり、レイマーチングは語弊を恐れずいうならば、全てのピクセルについて、シーン上に存在するオブジェクトを示す距離関数のどれかが0を返すまでレイを飛ばし(もしくは定められた計算数まで)、ヒットしたオブジェクトを描画する手法です。

f:id:riyaaaaasan:20181122160329p:plain

 実際に書いてみましょう。

// 球の距離函数
float sphere_d(vec3 p) {
	const vec3 sphere_pos = vec3(0.0, 0.0, 3.0);
	const float r = 1.0;
	return length(p - sphere_pos) - r;
}

struct Ray {
	vec3 pos;
	vec3 dir;
};

void main( void ) {
   // 画面座標の正規化。中心が(0, 0)の方が都合がいいため-1 ~ 1で正規化する
	vec2 pos = (gl_FragCoord.xy * 2.0 - resolution) / max(resolution.x, resolution.y);
	
        // カメラの位置。中心から後方にあるイメージ
	vec3 camera_pos = vec3(0.0, 0.0, -4.0);
        // カメラの上方向の姿勢を定めるベクトル この場合水平
	vec3 camera_up = normalize(vec3(0.0, 1.0, 0.0));
        //  カメラの向いている方向 
	vec3 camera_dir = normalize(vec3(0.0, 0.0, 1.0));
        // camera_upとcamera_dirの外積から定まるカメラの横方向のベクトル 
	vec3 camera_side = normalize(cross(camera_up, camera_dir));
	
        // レイの位置、飛ぶ方向を定義する
	Ray ray;
	ray.pos = camera_pos;
	ray.dir = normalize(pos.x * camera_side + pos.y * camera_up + camera_dir);
	
	float t = 0.0, d;
        // レイを飛ばす (計算回数は最大64回まで)
	for (int i = 0; i < 64; i++) {
		d = sphere_d(ray.pos);
                // ヒットした
		if (d < 0.001) {
			break;
		}
                // 次のレイは最小距離d * ray.dirの分だけ進める(効率化)
		t += d;
		ray.pos = camera_pos + t * ray.dir;
	}

	if (d < 0.001) {
                // ヒットしていれば白
		gl_FragColor = vec4(1);	
	} else {
		gl_FragColor = vec4(0);	
	}
}


 スフィア一個を配置し、カメラを画面後方に設定しました。位置関係を図で表すと以下のような感じです。


f:id:riyaaaaasan:20181128155827p:plain


 そして、以下のように描画されます。
 

f:id:riyaaaaasan:20181122163232p:plain


 これで最も基本的なレイマーチング は実装できました。しかし、せっかく3Dでやっているのに平べったく見えてしまいます。
 次はライティングをしてみましょう。

レイマーチングにおけるライティング表現

 今回はディレクショナルライトによるライティングを行います。必要なのは、光源ベクトルと、ライティング対象の法線ベクトルです。
 一般的な3Dのレンダリングにおいては、法線ベクトルは頂点データから与えられますが、レイマーチング の場合は距離函数による衝突判定を行っているため、同じの手法は使えません。
 ここで、数学的なアプローチにより、「陰関数の勾配ベクトルは法線ベクトルとなる」という性質を使って、法線ベクトルを求めてみたいと思います。
 勾配ベクトルとは、各成分の偏微分を並べたベクトルを指します。陰関数とは \boldsymbol{R}(x, y, z....) = 0の形で表される関数のことを指し、距離函数も陰関数表示の一つです。

 つまり、距離函数を使って任意の座標の法線ベクトルを求めるためには
  \boldsymbol{t} = (\frac{∂f}{∂x}, \frac{∂f}{∂y}, \frac{∂f}{∂z})を求める必要があります。xの偏微分の定義は以下。

 \frac{∂f(x, y, z)}{∂x} := \lim_{h \to 0}\frac{∂f(x + h, y, z) - ∂f(x, y, z)}{h}
 y, zの偏微分についても同様のことが言えます。

 数値計算的に求めてみましょう。

vec3 sphere_normal(vec3 pos) {
  float delta = 0.001;
  return normalize(vec3(
    sphere_d(pos + vec3(delta, 0.0, 0.0)) - sphere_d(pos),
    sphere_d(pos + vec3(0.0, delta, 0.0)) - sphere_d(pos),
    sphere_d(pos + vec3(0.0, 0.0, delta)) - sphere_d(pos)
  ));
}

 これで法線ベクトルを求めることができます。
 次に光源ベクトルをLとして、頂点の輝度を求めましょう。ここではシンプルにランバート反射を使います。

vec3 L = vec3(0.0, 0.0, 1.0); // 光源ベクトル
vec3 N = sphere_normal(ray.pos); // 法線ベクトル
vec3 LColor = vec3(1.0, 1.0, 1.0); // 光の色
vec3 I = dot(N, L) * LColor; // 輝度

 これらを先ほどの実装に組み込むと、このようにライティングされます。

f:id:riyaaaaasan:20181128164303p:plain

 ソースコードが長くなってしまったので、フルバージョンはgistにアップしています。
raymarching-sphere-lighting · GitHub

 光源ベクトルが(0.0, 0.0, 1.0)なので、球の正面に光を当てていることになりますね。光の方向を変えてみると光の当たり方が変わります。(必ずその際は光源ベクトルを正規化をしてください)

 他にも、距離函数にmod関数(剰余)をかますことで、レイの値域を制限し、あたかもオブジェクトが複製されているように見せかけるテクニックがあります。

float sphere_d(vec3 p) {
	const float r = 1.0;
	return length(mod(p, 4.0) - 2.0) - r;
}

 f:id:riyaaaaasan:20181128174155p:plain

 さて、ここまで基本を抑えてしまえばあとはなんでもありです。
 超かっこいいエフェクト(ブルームや走査線など)を好き放題追加するのもありですし、面白い距離函数を実装してみるのもいいかもしれません。

 最後に、パーリンノイズを使ったレイマーチング によるテライン描画をやってみましょう。

パーリンノイズを使ったレイマーチングによるテライン表現

 パーリンノイズは、テクスチャの表現によく使われる、とても自然に感じる(?)擬似乱数を生成するアルゴリズムです。話すと長くなるのでここでは端折って、解説や実装を引用したいと思います。

The Book of Shaders: Noise

 今回はこの中にあるパーリンノイズをさらに改良したシンプレックスノイズというのを使いましょう。このシンプレックスノイズを、距離函数として応用してレイマーチングに使用します。

 試しにまず、このシンプレックスノイズをテクスチャとして描画してみましょう。

void main( void ) {
	vec2 pos = (gl_FragCoord.xy * 2.0 - resolution) / max(resolution.x, resolution.y);
        // snoiseは上記文献で示されているシンプレックスノイズ関数
	float c = snoise(pos * 5.0);
        gl_FragColor = vec4(c, c, c, 1.0);	
}

f:id:riyaaaaasan:20181128175015p:plain

 この時、シンプレックスノイズ関数は、 y = f(x, z)という二変数関数で示される曲面であると解釈できます。(数学でよく表す空間と、GLSLの空間ではzとyが逆転していることに注意してください)
 つまり、レイの座標を(Rx, Ry, Rz)とすると、 f(Rx, Rz) - Ry = 0 を満たすとき、レイはこのシンプレックスノイズ曲面上にある(衝突した)と考えることができます!

 

float map(vec3 v) {
        // 地面のオフセット
        const float GROUND_BASE = 1.2;
	return v.y - snoise(v.xz * .4) + GROUND_BASE;
}

vec3 map_normal(vec3 v) {
	float delta = 0.01;
	return normalize(vec3(map(v + vec3(delta, 0.0, 0.0)) - map(v), 
			      map(v + vec3(0.0, delta, 0.0)) - map(v), 
			      map(v + vec3(0.0, 0.0, delta)) - map(v)));
}

 謎のマジックナンバーが出てきていますが、これは自由に変えることが可能なパラメータです。試しにいじってみるのもいいでしょう。

 さて、このmap関数をスフィアの距離函数の代わりに使い描画してみると...
 raymarching-terrain-sample · GitHub


 f:id:riyaaaaasan:20181128180017p:plain

 見事テラインが描画されました! 今回は、カメラの座標にtimeを加えているので、リアルタイムにテラインが動いていくのがわかると思います。

おわりに

 レイマーチングは解説した通りレイトレーシングの交差判定に距離函数を使うだけのシンプルなアルゴリズムです。一方で、その応用範囲は無限大です。距離函数はその特性上、幾何的なオブジェクトの描画に向いていますが、組み合わせや微調整を繰り返すことで、生き物のようなオブジェクトを描画することだって可能です。ボリュームレンダリングという3次元的な広がりのあるデータの描画に応用して雲などを描画することもできます(こちらは、実際に多くのゲームへの採用例があります)。
 他にも、パーリンノイズによるテライン表現を応用すると、グランドキャニオンのような光景や、リアルな水面でさえも描画することができます。
 このように、レイマーチング等を用いたデモシーンは、様々な工夫や自分の考えた最強の関数などを好き放題盛り込んで一つの作品を作る面白い分野です。ぜひ遊んで、あなただけの作品を作ってみてください。

 
 
 

Akatsuki Game JAM 開催レポート

こんにちは、エンジニア採用担当の花田です。

去る9月8日(土)〜9日(日)に2020年新卒エンジニア向けインターンシップ「Akatsuki Game JAM」を開催いたしました。今年で第4回となるその様子を「Server Sonic 2018(通称:サバソニ)」に続き、紹介させていただきます。

「Akatsuki Game JAM」とは・・・

2日間を通して、ゲームアイデアの企画から開発までを行い、その制作物の結果を競い合うという内容です。今回は、アカツキで大切にしている「つながり」「Shine(輝く)」という2つの言葉をテーマにUnityでのチーム開発を行います。参加者は17人、5チームです。

 ▼詳細はこちら

https://aktsk.jp/recruit/new_recruit2020/gamejam2018/

#なぜこのようなインターンシップアカツキが実施するのか

私たちは本気で「ゲーム開発を通して、世の中をワクワクさせるようなプロダクトづくりを体験をしてもらいたい!」という想いを持っているからです。

もちろん、参加者の中にはこれまでにもハッカソン参加の経験や、サークルなどでのチーム開発を経験している参加者も多くいました。一方で、多くの学生とお話をする中で、プロのエンジニアから近い距離でアドバイスをもらいながら、開発を進める経験をしたことがある学生は少なく、その機会を創出したいと思い開催しています。今年で4回目になりますが、毎年パワーアップしております。

#昨年から何を変えたのか

このインターンシップでは、アカツキの組織文化も一緒に体現できるインターンシップにしたいと考えました。そのため、従来の1日開催から2日間に期間を拡大し、更にアカツキのエンジニアが各チームの専任メンターとしてつくことで、より濃密なコミュニケーションが取れる様に変更を加えました。
併せて期間拡大により時間的余裕が生まれたことで、ワクワクするアイデアを生み出すためのアイデアソンの充実化や、オフィス見学、各チームの制作物の試遊会、アカツキの振り返りの文化も体験してもらう事ができました。

#当日の様子

春から多くの学生との面談や面接を実施して、いよいよ開催当日を迎えます。

インターンシップでも恒例となった「Good & New」(24時間以内にあった「よかった事」「新しい気づき」の共有)でアイスブレイクをし、早速開発ゲームのアイデアソンへと移ります。

▼Good & New

f:id:kenji-hanada:20180912163252j:plain▼アイデアソンの説明

f:id:kenji-hanada:20180912163255j:plain今回この段階では、アイデアは全参加者のものという考えのもと、全チームのゲーム企画を共有し、発想を拡げた後に、各チームがブラッシュアップするという方法をとりました。チーム戦ではあるものの、より多くのアイデアに触れることで、企画が磨かれていくのを感じました。

▼アイデアを張り出し、全チームに公開

f:id:kenji-hanada:20180912163259j:plainゲーム企画が決まったところで、いよいよ開発開始です。2日間の開発スケジュールや役割分担を決め、本番が始まるこの瞬間に、会場の雰囲気も一層熱を帯びた様に感じました。今回、各チームを専任メンターが担当し、参加者からの質問対応や、適宜アドバイスと、交流も積極的に。VRゲームを開発するチームに対し、Oculus Goを貸与した為、初めて触るメンバーは環境構築に手こずりながらも、奮闘していました。

▼いよいよ開発開始、メンターからのアドバイス

f:id:kenji-hanada:20180912163302j:plain2日間に拡大したものの、開発時間はあっという間に過ぎ、成果物のプレゼンテーションへ。

各チーム、そのゲームのこだわりポイントや面白み、また当初想定していた機能が時間が足りずに実装に至らなかった悔しさを口にしながらも、全力で取り組んだこの2日間をアピールしました。

▼プレゼンテーションの様子

f:id:kenji-hanada:20180912163312j:plain発表に対しては、アカツキメンバーと参加者から様々な質問が飛びました。質問は「実装にはどんな技術を使用したのか」「盛り込めなかった機能が実装されれば、どのように面白みが拡がるか」「コンセプトが尖っているが、どのような発想から生まれたのか」など、時に会場は笑いにつつまれながら、発表を終えました。
アカツキメンバーからの質問タイム

f:id:kenji-hanada:20180912163316j:plain発表後には、各チームのゲームを体験できる試遊会を実施。自分たちのゲームを他チームに説明、体験する側ものめり込んでプレイする姿が印象的でした。2日間に拡大したことで、参加者が全力を注ぎ込んだプロダクトに触れる時間を設けることができ、お互いの健闘を称える良い時間となりました。

▼試遊会

f:id:kenji-hanada:20180912163306j:plainそして、いよいよ緊張の結果発表へ。

まずは準優勝チームを表彰。「地下アイドルの守護神」というキャッチーなタイトルとアイドルに襲いかかる悪質なファンをサイリウムを投げて撃退するというコンセプトに会場は興味津々でした。このゲームはOculus Goを使用して、コントローラーを振りかざすとサイリウムを投げられるという仕組み。時間の都合上、一部実装が間に合わない部分があり、悔しさを見せていましたが、堂々の準優勝。結果発表の際には喜びの息もぴったりで、チームワークの良さが表れていました。

▼喜ぶ準優勝チーム

f:id:kenji-hanada:20180912163319j:plainそして、栄えある優勝は「Doki☆Doki☆Dungeon」というダンジョン探索ゲームを開発したチームでした!暗闇のダンジョンにそれぞれ特性を持った3色のライトを配置することで、迫り来る敵を避けながら宝を集めるという内容です。2日間でゲームとして仕上げたこと、Joy-Conを使用することで、振動によって敵や宝との距離を察知する機能まで実装し、見事優勝に選ばれました!

▼優勝チーム

f:id:kenji-hanada:20180912163322j:plain#最後に、運営側としての感想

2日間という非常に短期間ではありましたが、世の中をワクワクさせる様なゲーム開発に全力で取り組むみなさんのキラキラした姿を見れて感無量でした。中には今回開発したゲーム開発を継続したいという声もあり、非常に嬉しいです。是非、今回のインターンシップが一つの学びとなり、みなさんの次なる挑戦に繋がれば幸いです!

▼参加者のみなさん、本当にお疲れ様でした!

f:id:kenji-hanada:20180912163329j:plain

Server Sonic 2018 開催レポート

こんにちは、エンジニア採用担当の花田です。
この度8月25日(土)〜26日(日)に今年で第2回目の開催となる新卒エンジニア向けインターンシップ「Server Sonic 2018(通称:サバソニ)」を開催いたしました。その様子を紹介させていただきます。

「Server Sonic 2018(通称:サバソニ)」とは・・・

2日間を通して、ゲームサーバーアプリケーションの性能改善方法を学び、Akatsuki x KADOKAWAが贈る青春体験型野球ゲーム「八月のシンデレラナイン」(ハチナイ)の性能改善に2人1組で取り組み、結果を競い合うという内容です。

▼詳細はこちら https://aktsk.jp/recruit/new_recruit2020/serversonic2018/

#なぜこのようなインターンシップアカツキが実施するのか
一言で言うと「ワクワクする体験を通して、学びを得てもらいたい!」という気持ちからです。

エンジニア職を目指す学生とお会いする中で、多くの学生から「個人やサークル規模では体験できないインターンシップに参加したい」という声を聞いていました。

そこで、社内のエンジニアチームとどうすれば、「個人やサークル規模では体験できないインターンシップ」を開催できるかを話し合い、実際にリリースされている大規模プロダクトのソースコードに触れることができるインターンシップを企画しました。昨年も同様の思いから、第1回を実施しましたが「難易度が高い」「単なる高速化ではなく、プロダクトとして良質なコードを書きたい」という意見から、1日開催から2日間の開催へと変更し、講義パートの比重を大きく変更しコンテスト自体にゲーム性を加える事で、参加者がワクワクし、のめりこめるような内容を企画いたしました。

数ヶ月に渡る準備期間を経て、 いよいよ開催当日。

▼会場入口

f:id:kenji-hanada:20180829195000p:plain
会場の入口にはハチナイメンバーが勢揃いし、参加者を迎え入れる

まずは、アカツキの文化として根付いている「Good & New」(24時間以内にあった「よかった事」「新しい気づき」の共有)でアイスブレイク。他社のインターンなどで顔を合わせていたり、まさかの同じサークルに所属しているメンバーもいたりと、朝から話が弾み、笑いが生まれる和やかな雰囲気でスタート。

▼Good & New

f:id:kenji-hanada:20180829195005p:plain

その後、アカツキメンバーから性能改善に関する講義を入門編&応用編と二部構成にて実施。特に応用編は難易度の高い内容でしたが、参加者からも質問が飛び、積極的に吸収し、午後の開発に向け知識を蓄えている姿が印象的でした。

▼性能改善に関する講義

f:id:kenji-hanada:20180829195009p:plain

講義を終えたところで、いよいよ開発開始。

各チーム、それぞれの得意領域から役割分担をし、開発を進めます。ゲーム構成のどの部分を改善すると結果が得られそうか、仮説を立てながら取り組んでいました。

▼いよいよ開発開始

f:id:kenji-hanada:20180829195014p:plain

 開発中にはアカツキのメンターが、参加者の質問に答え、開発をサポート。Slack上での質問や、画面を眺めながらの対応と、2日間を通し活発なコミュニケーションを取っていました。

 ▼参加者の質問にはメンターがサポート

f:id:kenji-hanada:20180829195019p:plain
また今回、CI(継続的インテグレーション)を回すことで、改善結果がポイントとして表示される仕組みを構築したため、参加者はテスト実施の度に、ワクワクしたり、時には思う様に結果が得られず落ち込んだりと開発そのものに含まれたゲーム性を楽しんでいました!

 ▼テストを試す度にポイントを表示

f:id:kenji-hanada:20180829195024p:plain

このポイントは、途中経過としてチーム名を伏せて、参加者に公開し、自分たちが今、何番手に位置しているのかということを把握することで、終盤は熱いデッドヒートが繰り広げられました。

あっという間に開発時間が過ぎ、いよいよ結果発表へ!緊張高まる中、順位が発表され、優勝チームは両手を高らかにハイタッチをして喜びを噛み締めていました^^

今回、準優勝チームにはアカツキオリジナルパーカーを、優勝チームにはSwitch、PS4 Pro、Kinesisなどの豪華賞品から希望のものを贈りました。

 ▼優勝・準優勝チーム

f:id:kenji-hanada:20180829195027p:plain

その後、CTOの田中から、順位に限らず参加者からの優れたコミットの発表(優秀コード部門、ネタ部門など)があり、そのコードを書いた参加者が意図を話して、2日間を振り返りました。

▼CTO田中からの優れたコミットを発表

f:id:kenji-hanada:20180829195031p:plain

インターンシップの締めくくりは、懇親会。アカツキの子会社であるアカツキライブエンターテイメントが提供するgoodyというケータリングを囲み、参加者とメンターが和気藹々と交流しました。

▼懇親会の様子

f:id:kenji-hanada:20180829195035p:plain

#最後に、運営側としての感想

至らぬ点もあったかと思いますが「ワクワクする体験を通して、学びを得てもらいたい」という思いは幸運にも参加者のみんなに伝わったと感じています!結果を残せて喜んでいるメンバーや、自分の力不足に悔しさを見せるメンバー、それぞれの表情を見ながら、みなさんの今後の成長と活躍がとても楽しみになりました。参加者のみなさん、今回の振り返りを経て得た学びを、是非次なるステージに繋げていただければと思います^^

▼参加者のみなさん、本当にお疲れ様でした!

f:id:kenji-hanada:20180829195040p:plain

新規事業担当者の陥りがちな心理と対策

こんにちは、ライブエクスペリエンス事業部のポリック (id: poric_ries) です。

 
本ブログは、

リーン・スタートアップはもう古い?企業内新規事業でよみがえるLeanな事業立ち上げ

をテーマに、新規事業開発現場の”実践録”をシリーズで配信しています。

 

▼配信済
#0.はじめに 
#1.走り出す前の準備
#2.やってはいけない!新規事業チームの最悪な1週間の過ごし方
#3.新規事業担当者の陥りがちな心理と対策 ← 今回はここ

▼配信予定
#4.新たな企画での再スタート!ダーティー&セクシーな検証
#5.to be determined

 

 

今回は、LEAN&SPRINT実践手法から少し離れ、企業内で新規事業を企画する際に担当者が陥りがちな心理とその対策について書きます。見ようによっては、やや後ろ向きな内容で書くかどうか迷ったのですが、企業内新規事業が盛んな昨今、同じ立場で同じ悩みを抱えている方はいるんじゃないかと思い、思い切って配信することにします。

 

f:id:poric_ries:20180509103953p:plain

 

 

  • 新規事業担当者が陥りがちな、望ましくない心理とは?
    • なぜ、この心理に陥ってしまうのか?
    • これに陥ってしまうと・・・
    • (私の場合)チームの貴重な"2週間”をロス!
  • どうすれば、望ましくない心理に打ち勝つことができるか?
    • 望まない心理に陥っていないかセルフチェック
  • 心機一転、再スタート
  • [宣伝] ”デートのマンネリ化”にお困りの方は必見!!!

 

続きを読む

やってはいけない!新規事業チームの最悪な1週間の過ごし方

こんにちは、ライブエクスペリエンス事業部のポリック (id: poric_ries) です。

 

僕らのチームでは、Running LeanやSPRINTなどのメソッドを実際に導入し、僕らなりにカスタマイズしながら、新サービス「JOYMO(ジョイモ)」を作っています。

joymo.herokuapp.com

 

本ブログは、

「リーン・スタートアップはもう古い?企業内新規事業でよみがえるLeanな事業立ち上げ」

をテーマに、新規事業開発現場の”実践録”をシリーズで配信しています。

 

▼配信済
#0.はじめに 
#1.走り出す前の準備
#2.やってはいけない!新規事業チームの最悪な1週間の過ごし方 ← 今回はここ

▼配信予定
#3.方法論をチューニングしながら走る!
#4.走り慣れてきた!案外すぐにゴールできるんじゃね!と思ったら...
#5.ターゲットを変えて再スタート!
#6.ダーティー&セクシーな検証
#7.to be determined

 

 

今回はいよいよSPRINT開始!1周目の実践録を配信します。

f:id:poric_ries:20180331150258j:plain

 

教科書通りに実践してわかった”本と実際の違い”や”躓きポイント”など、このブログを読んで実際にやってみようと思った方に役立つことを中心に話します。

  • [前提] チームのミッションと3ヶ月の過ごし方
    • 1.チームのミッション
    • 2.あらためて「SPRINT」とは
      • 参考:「SPRINT」を詳しく知るための書籍&サイト
    • 3.三ヶ月の過ごし方
  • [結果] 1周目はあえなく失敗!!!
    • 失敗の原因はここだった!
  • [経緯] 1周目を時系列で振り返る
    • 1.スケジュール
    • 2.SPRINT前にやったこと
      • 2-1.三ヶ月で取り組むテーマを決める
      • 2-2.顧客を知る
    • 3.SPRINT開始
      • 3-1.月曜日:目標を決める
      • 失敗ポイント①:ターゲットがあいまい
      • 3-2.火曜日:目標を決める
      • 3-3.水曜日午前:ベストを決める
      • 3-4.水曜日午後:幻想をつくる
      • 3-5.木〜金曜日: テストする
      • 失敗ポイント②:”リアル”さの欠けるプロトタイプ
  • まとめ
    • 教訓
      • 具体的な改善策「ターゲットを明確に定義する」
      • 具体的な改善策「プロトタイプの品質を上げる」
    • 基本動作/スタンス

 

続きを読む