岩切さんがITエンジニア本大賞の募集をしていました。技術書とビジネス書の2カテゴリがあるんですが、それぞれのカテゴリで、2015年に出会った本で、「やばい、これは10年以上待ち望んでた次の時代の道標になる本だ」というものがあったのですが、清き平等な一票ではこの気持ちは伝わらないと思い、筆を執った次第です。
一応僕のことをあまり知らない人も多いと思うので一応説明しておくと、学生のころに日本XPユーザグループの設立準備から関わっていて、アジャイルという言葉が出る前から「仕様書通りにしかコーディングできない世界つまらなそうだし、XPなんか面白そうだな！」と思っていて、イベント運営をしてみたり、C++やらPythonやらRuby(とちぎ)やらのコミュニティに参加したり、ドキュメントツールのSphinxのユーザグループを設立してみたり、いろいろ趣味で検索エンジンやら自然言語処理関連やらGUIフレームワークやらのOSS開発をしています。本も、アジャイル系の本の執筆や翻訳もするし、言語系の本の執筆や翻訳もしてます。昨年はWebのMVCのMithrilの本も出して、損益分岐点は超えたらしいので、ホッとしているところです。そんなバックグラウンドがある人間が推薦していると思ってこの駄文を読んでいただけたら、と思っています。逆に研究的な観点とか大規模分散とかDevOpsみたいなのは弾幕薄め(経験少なめ)です。
技術書大賞に推薦したい本はこちら！
技術書大賞に推薦したい本はUnreal Engine 4で極めるゲーム開発です。もうこれはあらゆる面で圧倒的でした。
ゲーム開発系の人はもうこの本の背景とかは説明せずともいいと思うので、ゲーム畑以外の人向けにこの本の技術面での凄さを伝えたいと思っています。凄さは大きく２つに分かれていて、この本がターゲットとしているUnreal Engineそのものの凄さと、懇切丁寧なまでにそれを伝える著者の凄さの両面があります。
SI系の人たちがずっと待ち望んできた世界を(10年前から)実現してしまっていたUnreal Engineの解説
中学時代からCマガジンとかDDJを読んでいましたが、IBMとかRationalとかMicrosoftとかSunとか、20世紀にITの世界を大きく動かしていた会社の人たち、および日本の大手SIerとかがずっと望んできたものの、普及に至らなかったものが、「MDA(モデル駆動開発)」「動く仕様書」だったりします。Executable UMLってどのぐらい動くんですかね・・・そんな中、UMLとは違いますが、ビジュアル言語を世に送り出し、しかもビジネスとしてきちんとお金を稼ぐことができていて、なおかつ最近は他社どころかアマチュアのプログラマでも比較的自由に触れるものとして、Unreal Engineがあります。UE3ではKismetという名前でしたが、UE4ではBlueprintと呼ばれています。
Blueprintはビジュアル言語といっても、コードジェネレータでクラスの枠組みだけ作ってくれて後はJavaとかC++で書かなければいけないような2000年代初頭のUML系のCASEツールとは違って、それ単体でゲームを作りこむことができる「プログラミング言語」です。アーティストが1人で1ヶ月間でゲーム1本作ってみたの記事でも書かれているように一本Blueprintだけでゲームが作れます。なお、Blueprintは言語ですが、その言語だけで実現しているわけではなく、ウェブ開発でサーバ言語と、HTMLテンプレートとクライアントのJavaScriptなど複数のレイヤーに分けて書きますが、Blueprintでも、レベルデザイナー、レベルBlueprint、クラスBlueprint、アニメーションのツール、状態遷移、ビヘイビアツリー、ビジュアルなシェーダー、ビジュアルなオーディオ設計ツールなど、多層化されたビジュアル環境が折り重なって１つのゲームになっていきます。Unreal Engineの話は4-5年前に元同僚の@shima11endli9さんから聞いて、「そんな世界がもうあったんだ」と衝撃を受けたのを今でも覚えています。
そんなBlueprintの世界を、「実際にゲームを作るプロセス」の中で体感できるのが本書です。他書でも良い本はあるのですが、本書はUE3のころから知っている人たちの手によって書かれた本で、「ここが勘所！」みたいなところが丁寧に書かれている印象があります。特に印象深いのが、ビジュアルな要素を見ながらコーディングしていく時に、必ずテストしやすい「テストステージ」を作ってから機能を作りこんで、それをゲームに入れていくというステップになっています。アジャイルでもなんでも、小さいゴールの見える化が、開発を前に進めていく原動力になるし、進捗の見える化はとても大切なところですが、そういう「実践的なコツ」が本書の中に散りばめられているところが良いです。やはり本は「先人の偉大な経験をてっとり速く学べる手段」であることを実感できます。
今後、ゲーム以外でもビジュアル言語はいろいろ出てくると思いますが、UE4が実現した世界と、本書で説明されているステップは、１つのベンチマークになるんじゃないかと思います。
プログラマを苦しめてきた非同期・分散プログラミングの決定的なソリューション
非同期プログラミングを効率よく書く方法というのはなかなか難しいものです。特にJavaScriptの人たちはこの非同期のコーディングの変化に今敏感になっている所でしょう。コールバック、async.js、Promise、Stream、async/await、リアクティブファンクショナルなんとかとか、ここ数年でトレンドがどんどん変わったり、選択肢が広がったりしています。非同期のソリューションは基本的に「同期的に書ける」というのを売りにしているものが多く、逆説的な見方をすれば「やっぱり非同期ってわかりにくかったんだ」ということですよね。
「お前またBlueprintの話しようとしているな」と思っている人は1/2は正解です。Blueprintの世界ではDelayなどの「フレームをまたぐ処理」も、同期的に行われる処理も同じように書いていくことができます。イベントが発生したときのコールバックなども見た目はまったく差がなく書けます。実行ピンでつなぐ白い太い線がこのポイントです。
実行ピン以外にカラフルな細い線も登場します。これは実行フローではなくて、データのフローを表します。細い線だけでつないでいくパスも重要です。関数型プログラミング的に言えば、この線は副作用がない線だからです。つまり実行順序を意識しなくていい線です。この実行の線とデータの線が使い分けられているところが、ビジュアル言語のBlueprintとしての革命的なところだと思います。さまざまなビジュアル言語を調べたことがあるんですが、これと同じことをしているものはありません。そうすると線がこんがらがって可読性が1/10以下になります。Blueprintの前身のKismetですら「後から見るとメンテが大変になりやすい(UE4極本著者の湊さんのUnreal Fesの発表より)」状態だったようです。
非同期の文脈で語られるもう１つ「難しい分野」とされるのがマルチスレッドや分散です。前書きにも書きましたが、AWSで1000台みたいな分散ではなくて数台レベルの話なのであしからず。dRubyによる分散・Webプログラミングの中で、Ruby関係なくおすすめの章は、さまざまなマルチスレッドのパターンをRubyで紹介する話です。僕はとちぎRubyで咳さんから直々に話を聞くことができた幸運なメンバーの１人ですが、「これはNEWS OSのカーネルで使われていたパターン」みたいな説明がさらっと補足されたりして「おおー」と唸ったものです。最近名前をよく聞くのErlang OTPのアクターや、Golangのチャンネルなども、非同期を扱いやすくするための手法です。Blueprintでも、基本イベント駆動モデルでアクター的な動作をするので、複数のスレッドの存在などを特に意識することなくできる気はしています(細かく並列処理の文脈でまとまった資料がないので推測です)。
Blueprint以外の非同期のソリューションとしてすごいのが、Unreal Engineのランタイム&処理系です。この内容は本書の内容からは外れるのですが、Unreal Fes 2015の中村 匡彦さんの発表が面白かったので入れちゃいます。
初めて見ると何がなんだか、という感じなのですが、ようするに1本のソースコードをビルドすると、クライアント用のプログラムとサーバ用のプログラムができるらしいのです。一部は「もし権限があれば(サーバなら)」「権限がなければ(クライアントなら)」という条件分岐を入れる必要はありますが、一人用のシューティングゲームを作り、少し手を加えると、それだけでマルチプレーヤー対応のゲームになってしまうという。イベント駆動の仕組みがそのままネットワーク越しに作用するだけではなく、データのレプリケーション(複製)をして、他のノードとのデータのやりとりをしたり、仲間を見つける(Xbox LiveとかPSNとかSteamとか)仕組みがラッピングされていたりとか、もうなにがなんだか、という感じです。ただしこれはUnreal Engineの名前の由来にもなっているUnrealような、FPS的な8人とか16人とかの同期対戦の話であって、MMOとかはまた別のソリューションが必要です。制約があるとはいえ、これも十分すごいですよね。これがBlueprint以外の、非同期プログラミングのUE4のすごい点です。
今後も非同期プログラミングに関してはいろいろ出てくると思いますが、UE4が実現した世界は、１つのベンチマークになるんじゃないかと思います。
書籍の丁寧さがすごい
この書籍はかなり分厚い本です。中身はフルカラー。で、この本を通じて一本のゲームを作っていきます。「なんだ一本だけかよ」と思う方もいると思います。他の本ではこれより少ないページ数(といってもそんなには変わらない)で、何種類かのゲームの作り方を紹介している本もあります。ただしこれは書籍が説明しようとしている対象が異なるからです。他の本は他の本でもちろん価値があります。Unreal Engine 4でどんなゲームが作れるか、ゲームの作り方をいろんなサンプルを通じて教えてくれます。本書は「チームでゲームを作る方法論」を紹介する本だと言えます。
この本の特徴的なところは、章ごとに「これはプログラマー向けです」「レベルデザイナー向けです」「これはテクニカルアーティスト向けです」みたいな、読むべき人がアイコンで表示されている点です。湊さん、一体強くてニューゲームでゲーム開発者人生を何周回っているんだ、と疑問が浮かんでくるレベル。単なる使い方ではなく、最初のところでも紹介したように、Unreal Engineを通じて実際にゲームを作ってきた人の重い言葉が含まれています。経験といっても、うまくいかなかった経験もいろいろあったようです。資料は公開されていないのが残念ですが、Unreal Fesの湊さんの発表ではその失敗側の経験も色々語られていました。発表のレポートにその一部が書かれています。まず最初の丁寧さが、人生何周回っているのか分からないレベルの経験値の高さを感じるクオリティの高さです。
次に紹介する丁寧さは、説明の丁寧さです。ハンズオン形式だと、どうしても途中で繰り返し出てくる操作などは説明を省略したくなるところです。紙面だって限りがありますし。説明したい内容はたくさんあります。書きおろしで本を書くと、だいたい書きたい内容が本の企画の予定ページ数の2-3倍になってどれを削るか悩むことになります。ただ、ハンズオン形式の場合中途半端に削ってしまうと容易に迷子になります。特にGUIの操作の場合、どこに何があるか迷ったりします。読者だってフルタイムでぶっ続けで読んでいるわけではなく、週末だけで読み進めたりもするかもしれません。僕もGolangでベクターグラフィックスのライブラリとかGUIフレームワークを途中で作り始めて一ヶ月ブランクを開けてしまいました。
ブランクを空けつつ読んでも、本書はハンズオンの説明がすごく丁寧で、迷子になることはほとんどありませんでした。多少あったとしても、改訂版では修正済みだったり(僕がAmazonで買ったのは少し古いバージョンだった)。また、少し前の章で説明した内容に触れる時も「迷った方は◯◯章を読み返してみてください」とガイドがきちんと入っています。何度も繰り返し読み返したり、丁寧なレビューがあったんだろうな、と想像に難くないです。
で、その丁寧さで増えたページ数はどうなったかというと、書籍のページで5章分まるまる追加コンテンツとして提供されています。おまけという体裁ですが、しっかりと書籍の一部。それだけではなくて、本書の全内容について、ハンズオン動画まで用意されているレベル。さらに、本書で作るゲームのゲームブック版まで載っているとかもうね。
最後に紹介したい「おもてなし」は、著者の湊さんです。ちょっと詰まった内容をツイッターに書いたら著者の湊さんがフォローしてくださって、とても助かりました。↓は僕以外の方へのフォローですが、僕も何度か助けていただきました。
@minahito まさか著者の方からご返信頂けるとは思っておらず、ありがとうございます。リンク先ブログに記載されていた通り、Cut & Pasteで解決致しました。いまは12章の途中です！
— Hirofumi Seo (@HirofumiSeo) September 10, 2015僕も少し恩返ししなくちゃ、と書籍で触れているバージョンと、新しいバージョンの差分をUE4のアドベントカレンダーで書かせてもらいました。
今後もゲームに限らずたくさんの技術書が発行されていくと思いますが、本書のようなクオリティがベンチマークになると・・・書くのが辛すぎますね。この本のクオリティの高さは真似しろと言われると厳しいです。すべての本が村上春樹並に売れるなら実現可能だとは思いますが・・・
IT系ビジネス書大賞に推薦したい本はこちら！
IT系ビジネス書大賞に推薦したい本はUnreal Engine 4で極めるゲーム開発です。もうこれはあらゆる面で圧倒的でした。
ゲーム開発系の人はもうこの本の背景とかは説明せずともいいと思うので、ゲーム畑以外の人向けにこの本のビジネス面での凄さを伝えたいと思っています。凄さは大きく２つに分かれていて、この本がターゲットとしているUnreal Engineそのものの凄さと、懇切丁寧なまでにそれを伝える著者の凄さの両面があります。
スケールする(人材の可用性も含めて)開発プロセスUnreal Wayの実例
ソフトウェア開発は、始まる前に人材リソースの確保がうまくいくかどうかで成否が大きく左右されます。で、うまく集まらなかったからといって「じゃあ失敗ですね」というわけにはいきませんので、さまざまな方法論を駆使して、うまく弾みをつけたり、足りない戦力をお互いに補いあったりします。古くは分析設計と開発の分担訳ですね。超優秀な小数の人をヘッドに据えて、下々の者がそれに従うと。ハイスペックを100人揃えるのは難しくても、ハイスペック10人と普通の人90人を揃えられる可能性は高いです。組織の生存確率は上がります。
アジャイルソフトウェア開発は、「人間は不完全なものである」という所から出発して、教育しあってお互いのレベルアップをしようという観点を入れた点が当時としては新しかったのだと思っています。そんなことは明文化はされてはないのですが、イテレーションに区切って少しずつゴールを目指していくのも「完全な未来を予測できる人間はいない」という「人間の不完全さ」を受け入れた結果だと思うんですよね。制約理論(TOC)は、「全体の生産性はボトルネックに支配される」「ボトルネックを生かすことが生産性最大化のコツ」と説明しています。人間の不完全さを理解した上で、不完全さを補っていく視点を入れたプロセスが最強ということになります。
とはいえ、「学習で伸びる伸びしろ」には限界があります。僕は大学で合唱を4年ほどやりましたけど、まあ音楽的な才能はそんなにはないな、というのは分かりました。努力で補えるところは補ったつもりですが。ソフトウェア開発も、多くのドメインを相手にする必要があります。それを100%理解するのは難しいですよね。セキュリティの一面だけだって手に負えない人が多いはず。ゲームは総合芸術なので、プログラマー以外にもユーザ体験を考える人、音楽を作る人、2Dの絵を作る人、3Dの絵を作る人、動きをつける人、ストーリーを考える人など多くのスキルが必要になります。全部のスキルがすべて☆5な人材が集められればいいのですが、そういうわけには行かないでしょう。アサシンクリードのスタッフロールは長すぎて、途中で戦闘シーンが入ったり、もう読ませる気ないな、という感じでしたが、最新作のシンジケートはとうとうエンディングからスタッフロールが外されてオプションメニューに移動されました。見てみたら、今はヨーロッパのスペイン語以外に南米のスペイン語バージョンも別に作られているんですね・・・多言語化の対応も恐ろしいレベル。数えられないけど数百人、ヘタすると4桁いるんじゃないかという。当然、全部ができる人をそんな人数揃えるのは不可能ですし、ゲーム開発は多様なスキルを１つにまとめる最前線にいることは間違いないと思います。
Unreal Engineは、そのように大規模化するゲーム開発において、フレームワークができるサポートをきっちりと形にして実装しています。Unreal Engineはビジュアル言語を高度なプログラミングというよりも共通言語としての価値を前面に押し出しています。といっても、一本ゲームが作れちゃうレベルなので、中途半端なスクリプト言語やグルー言語というわけでもない能力も持っています。もちろん、音楽が得意なメンバーなど、それぞれの得意不得意はありますが、全メンバーが「おもしろさ」にコミットメントする平等な責任がある、というのがUnreal Engineが実現したいビジョンです。ちょっとした修正は全員ができる。で、まずは提供されている素材(UE3時代はGears of Warのアセットが提供されていたらしい)を使って、ゲームのメカニズムそのものを作りこんでいく。そして「これは面白い！」という形ができてきたら、自分たちの用意した素材に１つずつ置き換えてゲームを作るという流れです。
本書の4章がまるごとそのような開発文化についての説明に使われています。ここはまずは立ち読みでいいから多くの人に読んでもらいたいと思っています。そして本屋で読んだら、レジに持って行って、帰りの電車でも読むべき。Unreal Fesの湊さんの発表はこの文化のところを重点的にフォローした内容でした。さまざまな多様性を持った人が、それぞれ改善のイテレーションを高速に回すことの大切さを紹介していました。例えば音楽の組み込みがプログラマーの仕事だとすると、どうしても音楽を実機で聞いて確認するのにプログラマーの作業待ちが発生してしまいます。それではダメなので、待ちを発生させないためにフレームワークができることは何か？という問いに答えてくれるのがUnreal Engineだったというわけです。
Unreal Wayの話は4-5年前に元同僚の@shima11endli9さんから聞いて、「そんな世界がもうあったんだ」と衝撃を受けたのを今でも覚えています。
ウェブデザイナーとテンプレートとCSSの話題はここ数年尽きなかったり、「人手をまたぐ大変さ」を実感している人は多いと思いますが、UE4が実現した世界は１つのベンチマークになるんじゃないかと思います。
ますます高度化するプログラムと、それを支えるフレームワークビジネスの最前線としてのUE4
Xbox 360が出てきたころから、HDRなどの技術が一般化し、「どっちが実写か分からん」みたいなスクショと写真の比較が出てくるようになりました。3Dグラフィックスは数学の塊です。僕もある程度は理解していますが、ついていけない分野も多いです。アジャイルは「お互いに教育しあう」と説明しましたが、ビジネスの競争があればどんどん技術は狭く深くなっていくと思うんですよね。キャッチアップすぐできるレベルでは勝負にならない、と。これは下記のエントリーでも書きました。
狭く深くなれば、多くのことを達成するのに、より多くの人を雇う必要があります。でも、２倍高度なことを達成したからといって、売上が２倍にはなりません。同じ市場で高いクオリティのものが競い合うので、２倍リソースを突っ込んでも売上は維持、もしくはマイナスということもありえます。モバイルのゲーム開発なんかはそういう勝負に入ってしまっていて、デレマスなんて開発費何億かかったのか、気になります。
そのような高度なアウトプットが求め続けられる市場にあって、存在感を増しているのがゲームエンジンです。最初にモバイル市場で圧倒的な存在感を見せたのがUnity 3Dです。Unreal Engine 4もモバイル対応は進めていますが、実績や人材、書籍の数ではまだまだ発展途上です。逆に言えば、まだまだ名前を売るチャンスがあるところと言えます。とはいえ、コンソールやPC、アーケードゲームなどのハイエンドゲームでは着々と実績をどんどん出しています。しかも、それとまったく同じものを、趣味プログラマーでも無料で触ることができるというのがすごい所です。
ソフトウェアでどのように生活費を稼ぐのか、という問題はソフトウェア開発の歴史と同じ期間の長い付き合いになります。Unreal Engineはその中の１つのモデルであることは間違いありません。ゲームエンジンやフレームワークを使うことで、難しい部分をある程度丸投げすることができて自分のビジネス価値にフォーカスすることができるようになります。ウェブ系の開発などはOSSの比重は高まっていますが、でも開発環境はVisual StudioやIntelliJを買うとか、OSSじゃないところにきちんと投資する人も数多くいます。また、OSSでもサポートを売るビジネスをしているところは数多くあります。Unreal Engineは、イニシャルコストはフリーですが、レベニューシェアという形でビジネスにしています。
開発期間が伸びていて高度化しつつあり、コンシューマ向けなので当たるかどうかリスクがそれなりにあるというゲーム開発においては、レベニューシェアでイニシャル無料のライセンスは理にかなっています。リリースするまでは費用がかからず、ヒットするまではコストが抑えられるからです。もし開発中もお金がかかるモデルであれば、数百人の開発者を抱えると、リリースまでの期間のコストも大きくなります。ただし、月あたり億単位で売上があるのを見越して作るのであれば、やっぱりUnityの方が安い、みたいなこともありますし、モバイルの場合はビジネス判断でどちらが良いかが分かれるところかなと思います。
ゲーム以外の領域でも、「自前でキャッチアップするのが困難」というレベルまで行けば似たような状況が発生する可能性があります。そういう意味で、OSSでもなんともしがたいレベルになってきたらUE4自体のビジネスも、１つのベンチマークになるんじゃないかと思います。
ちなみにUnreal Engineはソースコードは公開されていますが、改変したものもレベニューシェアのライセンスの影響を受けます。自由に再利用できるわけではないので、ストールマンの認めるフリーウェアではありません。とはいえストールマン vs プロプライエタリのエピソードとして有名なプリンタドライバ的な問題はなくて、公開されているコードにパッチを当てて自分で動かすことは可能です。
もちろん、モバイルゲームの場合はまだ自前開発でも勝負できる世界は残っていて、僕は開発には関わってないですが、バンナムさんと弊社の開発しているスーパーガンダムロワイヤルなんかは動きがすごい軽快で、これはこれでいい差別化だなぁ、と思っています。LOADINGなんか出さなくてもいいのにって思うレベル。
まとめ
もうまとめなくてもいいと思いますが、自分がいろいろ関わってきたさまざまな分野のそれぞれの未来の姿が、この本とUE4の先に見えてしまって、もう白旗以外出しようがない、というのが本書を読んだ時の感想です。また、ツールの使い方に留まらず、人づてに聞いていたUnreal Wayがとても丁寧に解説されているのもとても良いです。「Unreal Wayというスケーラビリティの高いソフトウェア開発の方法論の本に、その方法論のよくできたサンプルとしてゲーム開発の実例が載っている」と考えても書籍代元が取れてパソコン買っちゃっても得したなと思えるレベルです。
SI系の会社の人たちも、スタバでMacBookを広げているような人たちも、とりあえずこれのゴールドモデルかプラチナモデルと本書を今すぐ買って、Unreal Engine 4を触ってみるのをおすすめしたいです。僕はゴールドのCore i7モデルにSSD 追加したのを買いました。このハードならオマケで今話題のOculas Riftだって動くスペックあるし一石二鳥ですよ。
余談ですが、僕がMithrilが良いな！と思って本を書いた理由は「変化が少ないから」です。なぜ変化が少ないのがいいかと言えば、変化を追い掛けるのに労力を使う必要がないからです。Mithril本を書いていた時はこの本には出会ってませんでしたが、Unreal Engine 4はちょこちょこ触っていて「こんなすごい未来を感じるものがタダで触れるのに、JavaScriptの寿命の短いツールやトランスパイラやフレームワークごときに消耗しているのは人生の損だな！大手の会社の稟議スタンプラリーで消耗するのと同じじゃん」と思っていました。基本、そんなトゲトゲしい言葉はPySpaコミュニティのチャットの中ぐらいでしか言わないことにしているのですが、本書に出会って、やっぱりその考えは間違ってなかったな、と思いを新たにしました。
気持ちがあふれるままに文章にしたら、長くなりすぎてしまったけど、削るのもめんどいのでそのまま公開しちゃいます。なんのために書いてたんだっけ？ああ、ITエンジニア本大賞だった。