CEDEC 2021 のラウンドテーブルの申し込みは 8/6(金)17:00まで!!

CEDEC2021 は参加されますか？

今年は、ラウンドテーブルも実施するという事で、森田さんと一緒に「プロダクションラウンドテーブル2021」を実施させていただくこととなりました。

今年度のラウンドテーブル（とワークショップ）は、事前申し込み制なので、ご注意ください。
具体的には、8/6(金) 17:00 までと、今週のビジネス時間ほぼいっぱいなので、なにとどお申し込みいただければと思います。

ゲーム業界のリモートワークについて

今年の、プロダクションラウンドテーブルは、「リモートワーク」と「雑談」がテーマです。実質的にリモートワークです。それに先立って、ゲーム業界でどのようにリモートワークに取り組まれているか少し調べてみました。

「リモートワーク　ゲーム開発」で調べると、次のような情報が出てきました。

各社の対応

バンダイナムコスタジオ

2020年3月末には社員全員が自宅で作業。出社と在宅ワークを選択。
出社率は5％〜10％程度。
ドタバタしながらも在宅での開発環境を整えた。いざやってみると案外できる。

• コロナ禍の中，ゲーム開発はどう変わったか。バンダイナムコスタジオが語る，これからの働き方とは(4Gamer.net, 2021/05/20)
• 格ゲーメーカーのキーマン集結「第2回 日本格ゲーメーカー連合会」レポート！　コロナ禍で格ゲーシーンはどう変わったか？(アソビモット, 2021/4/22)
• 【TGS2020】基調講演『未来は、まずゲームにやって来る』(2020/09/25)

スクウェア・エニックス

2020年4月から全社員を対象に、暫定的な措置として在宅勤務。
2020年12月、週3日以上在宅で働く「ホームベース」と週3日以上出社する「オフィスベース」という2つの働き方を、社員が選択。
リモートでのワークフロー整備に1カ月くらいかかったが、今のパフォーマンスはほぼ以前通り。現状はメインは在宅で、部署やチームによって出社している。

• テレワーク正式導入のスクエニ、ゲーム開発への影響は？　「ドラクエX」責任者に聞く(ITmedia NEWS, 2021/1/26)
• 【TGS2020】基調講演『未来は、まずゲームにやって来る』(YouTube, 2020/09/25)

コナミ

在宅と出社のハイブリッド。

【TGS2020】基調講演『未来は、まずゲームにやって来る』(2020/09/25)

カプコン

出社率は高い方かもしれない。

【TGS2020】基調講演『未来は、まずゲームにやって来る』(2020/09/25)

サイバーコネクトツー

モントリオールスタジオの現地スタッフは在宅勤務を継続し、日本国内のスタッフにおいては事情により出社が難しい4、5人のスタッフのみが在宅勤務を実施。
（その後）シフト勤務に切り替え。

• クリエイター業界でもテレワークは実現できる？　コロナ禍を在宅勤務で乗り切ったサイバーコネクトツーの場合(STUD/O by ITmedia NEWS, 2020/9/14)
• コロナ禍でゲーム業界はどう変化した？巣ごもり需要で売上アップってホント？ ゲーム会社の社長3人に聞いてみた(電ファミニコゲーマー, 2020/12/28)

ビサイド

リモートワークとオフィスでの作業とを、合わせてやっていく形。「入って2年目までの人は通勤、それ以降の人は自分で選びなさい」

• コロナ禍でゲーム業界はどう変化した？巣ごもり需要で売上アップってホント？ ゲーム会社の社長3人に聞いてみた(電ファミニコゲーマー, 2020/12/28)

トイディア

週に1回から2回は会社に集まりましょう。（社内チェックの前日の火曜日には）必ずビデオもオンで、マイクもオンで、独り言もブツブツ言いながら、リモートで作業する4時間を設定

• コロナ禍でゲーム業界はどう変化した？巣ごもり需要で売上アップってホント？ ゲーム会社の社長3人に聞いてみた(電ファミニコゲーマー, 2020/12/28)

プラチナゲームス

「在宅勤務もしくは自宅待機」

• 近況ご報告（プラチナゲームズ公式ブログ, 2020/5/7）

マーベラス

ほぼ全員が在宅勤務で開発

• 在宅勤務導入！奮闘記　～コンシューマ開発での事例～（マーベラス開発者ブログ, 2020/4/20）

ディンプス

全従業員を対象としたテレワーク環境・体制。
新型コロナウィルスの影響を受けた際に、ノートPC、コミュニケーションツールの導入等で、在宅勤務の環境は整えている。開発機材の関係上完全リモートワークではなく出社と在宅勤務のローテーション。出社と在宅の割合はプロジェクトによって異なる。

• 人気ゲームの開発現場　安全で使いやすいテレワーク環境をゼロトラスト型アクセスで実現(AKAMAI CASE STUDY, 2020/12)
• よくある質問 (Dimps Recruit, 2021/8/1 確認)

ヒストリア

オフィスクローズ＆フルリモート移行

• [新型コロナウイルス感染症対策] ゲーム開発会社のオフィスクローズ＆フルリモート移行の事例紹介 (ヒストリア ブログ, 2020.04.06)

KLab

2020年2月よりリモートワーク（基本在宅勤務体制）を実施

• 【KLab式リモートワーク】vol.2　とある部署のオンライン懇親会の様子 (KLabブログ（広報）, 2021/7/21)

ポノス

現在、全社的にリモートワークを推奨となります。

• ｛キャリア採用｝ゲームプランナー募集要項 (DIGRUIT45°2021/8/1 確認)

ギークス

管理部門など一部を除いて、9割以上の社員がリモートワークを行っている。

• PCデスク購入費用の支給も！自宅で会社PC使ってリモートワーク…IT各社の工夫は？(FNNプライムオンライン, 2020/4/22)

アピリッツ

最初の緊急事態宣言が発令されたあと全社でリモートワークを実施。緊急事態宣言が解除されてからは出社比率を上げていった。

• 「手段が変わったとしてもゲーム開発に関わりたい」 コンテンツデザイン部 部長 大金翔吾インタビュー(Appirits spirits, 2021/1/19)

エスカドラ

全従業員を対象にリモートワークを実施

• 新型コロナウイルス感染拡大に伴うリモートワークの実施について(おしらせ, 2020/3/27)

4qualia

基本的にテレワーク勤務を継続し、必要最低限の出社とする。出社する場合も混み合う時間を避ける。

• 緊急事態宣言解除後の対応について (ニュース, 2020/6/1)

海外

Ubisoft上海

2月初旬には仕事に復帰することが許可され、1週間後にはほとんどのスタッフがスタジオに戻っている。

• 中国のゲーム開発会社がリモートワークから学んだ教訓とCOVID-19の第二の波を防ぐための取り組み(ガメモ, 2020/12/23)

Blizzard

3月からフルタイムの自宅勤務

• 「ハースストーン」開発チームがリモートワークで「魔法学院スクロマンス」をリリースするまで(インサイド BLIZZARD, 2020/8/27)

ゲーム開発業界で働く500人以上のプロフェッショナルにアンケート

ゲームスタジオの多くはリモートワークに移行し、快適な新しい生活様式にも慣れてきた。

• ゲーム開発の現状レポート:2020年以降 (Perforce)

GDC 2020

開発者の約70%が在宅勤務に移行。

• 米国の大多数のゲーム開発者はリモートワークに移行中(TechCrunch Japan, 2020/7/17)

面白い試み

CySphere

業務上必要な機材を全て従業員の自宅へ配送することで日本全国でオフィスワークと遜色ない3DCG制作業務の環境を整え、各地で優秀な人材を登用

• Cygamesがテレワークをベースに3DCGを制作する新子会社「株式会社CySphere」を設立 (funglr Games, 2021/4/28)

サマータイムスタジオ

一般入浴ができる温泉施設を備えたサテライトオフィスを運営

• 沖縄のゲーム会社が大分・九重町に「立ち寄り温泉併設」の支社　新ツーリズムの拠点に(大分経済新聞, 2020/7/6)
• 「芸舞温泉」温泉旅館がゲーム会社のオフィスに（西日本新聞me, 2021/2/17）

まとめ

他にも各社でいろいろな試み・対応が行われていると思います。また、ここに上げた情報は古くなっているかもしれません。そのような話は、CEDECのラウンドテーブルでできたらと思います。是非お申し込みください。

追記：CEDEC 2021でのリモートワークの話

CEDEC 2021では 「リモートワーク」というタグが作られるほど多くのリモートワークのセッションが開かれます。是非とも下記のセッションを合わせてご参加ください。

8月24日(火) 11:20 〜 12:20

ゲーム業界の男性育児休業～職場復帰の実態。リモートワークでの育児両立の難しさと働き方。3社事例紹介。(茂呂　真由美 | 増田 亮 | 竹内 公紀 | 渡邉 吉治 | 佐々木 瞬 | 安部 拓也 | 澤田 唯)

8月24日(火) 11:50 〜 12:15

パンデミックにも負けない！元気なアートチームの作り方～オンラインにおけるナレッジマネジメントと情報透明化～ (吉川真美)

8月24日(火) 13:30 〜 14:30

リモートワークでどうなった？！ワーキングペアレントの働き方と悩み (茂呂　真由美、竹内 公紀、佐々木 瞬)

8月24日(火) 14:50 〜 15:50

プロダクションラウンドテーブル 2021 (森田 和則、今給黎 隆)

8月26日(木) 11:20 〜 12:20

2020年代のゲーム開発のためのクラウドネイティブCI/CDパイプラインの構築 (八重樫 剛史)

8月26日(木) 17:30 〜 18:30

至高のシナリオチームの作り方　〜リモートワークでも導入できる「ライターズルーム」とシナリオ横串チームによるマネージメント〜 (水野 崇志)

広告

産技大・琉大enPiT 成果発表会 2日前だよ!

これは、enPiTアドベントカレンダー17日目の記事です。

老害なお話です。

産技大のenPiTは、明後日の19日に琉球大学と一緒に成果発表会を行います。明後日がどんな感じなるか知らんけど、ひとまずアプリの開発はひと段落させて（ほんと？書いてるのだいぶ前だから、事実は火の車かもしれないよ…）、プレゼンの練習に精をだしています（そうなってること期待してますホントに）！

本年度の産技大のenPiTは、参加校が一校だけで寂しかったでした。昨年の、他の大学と一緒に、お互いに行き来しながら集まってスプリントレビューする機会は、他校が覗けて、とても楽しかったです。今年は、打って変わって、完全オンラインでのチーム開発＆イベントという新境地なのですが、遠隔でのenPiTのうんぬんは、他の方が書いて下さると思うので、そちらに任せましょう。今回は、TAと教員の違いを書いてみたいと思いました。自分は、もともとはゲーム作りの人をしていたのですが、数奇な縁で2014年度から2016年度にPBL外部評価委員としてenPiTに参加させていただきました。その後、ジョブチェンジして大学教員になったので、2019年度と2020年度には、参加校としてゼミの学生を強制的に参加させる悪行に手を染めてきました。教える立場の中で立ち位置が変わった人は他にはいないかな？

で、ここ2年は教員として参加していたのですが、教員は発言しにくい～～～～～～～。ゼミとして参加したので、ゼミの授業としての採点を最終的には付けないといけないのですよ。これ、必修で、落とすと留年する嫌な科目なので、生殺与奪の権を握っちゃってます。「うかつに反発すると、単位もらえないかも！」という暗黙の前提があるので、強く返すのは難しいでしょうし、こちらも逃げれないと思うと厳しくは言えないですし、距離感とりずれー。心理的安全性ねー。という感じでTAやってた時の方が、無責任に発言で来てたなぁと反省することしきりです。

それにしても、教員になって初めて知ったのですが、なんと新入生って毎年いるんですよ。毎年。新入生って、何と驚くことに、昨年、授業でやってたこと知らないんですよ（昨年の授業を受けていないんだから当たり前。何言ってるんでしょうね、この自分）。これは、毎年、チームメンバーがリセットされるということです。アジャイルやってると、メンバーを大きく変えるのが危険なのは基本事項ですよね。それなのに定期的かつ強制的に新人にとっかえられるって、失敗の見本みたいなプロジェクトじゃないですか。教育って怖い。

で、何が起きるかというと、毎年、同じように失敗するんですよ。もちろん、失敗を通して学んでもらうことを想定していますし、失敗を通して学んだからこそ強く身につくという事を狙っているのですが、それにしても、失敗内容は違うにしても、いつもいつも失敗を見るのはつらい。あ、でも、これってアジャイルコーチがいろいろな会社に入って感じることと同じなのか。アジャイルコーチの皆さんどうされていますか？「あー、あるある」みたいなことを心も中に秘めて対応されているのでしょうか。飽きませんか？

閑話休題、短気なので失敗するのをイライラしながら見守っているのですが、それはなんでかなぁと考えてみました。だんだんと老害になってきて、怒りに達するまでの閾値が下がっていることは確実にあると思うのですが、学生に対する想いの強さが違うのかなぁとも思いました。教員になると、学生がきちんと就職できるかとか将来を考えてしまいます。今まで、いくつかの会社を見てきているので、それらの新入社員のようになれるようにと思って、いろいろと教えてはいますが、なかなか難しい。興味を持ってもらえないと立て板に水ですし、同じ教室の学生の中でも身についていることの差が大きいので、なかなか全員に十分に教えるのは厳しく感じる今日この頃（教え方が下手なのもあるので、それは日々改善していく方向で頑張ります）。面白さ優先の授業をしたい気もするのですが、そうすると、みんなが望むような企業に就職するのに十分な力を蓄えるには時間が少なすぎる。実際のところ、早くからやる気をだしてもらって、自分から進んで取り組んでもらうことが一番なんですよねぇ。教員は、学生の背中を押すことぐらいしかできません。やる気スイッチの場所が目に見える能力が欲しい。

それはそうとして、enPiTっていいんですよ（アジャイル系のところだけかもしれませんが）。今どきの開発方法知れるし、TAの方も素敵な企業に勤めているOBの方々なので、ど真ん中に命中させつつも加減をつけてマサカリを投げてくれますし。こんんな環境できちんと学んだら、しっかりした技術を身に着けられるの当たり前ですね。

で、こんな機会はなかなか無いのかなぁと思ってみたのですが、実はそうでもないという事に至りました。小学生って、グループワークが上手だと思います。うちの子も、この前、学校のイベントでキッザニアに行ってきたのですが、同じグループの子とそれぞれの体験したい仕事をうまく調整できていたようです。小学校の先生方の努力もあると思うのですが、子供ってチーム作業が上手です。高校生でも、入試の面接で話を聞くと、いろいろなグループワークやって、コンテストとかに出ています。なので、そもそも学生はチーム開発が得意で、ソフトウェア開発のチームでの開発方法を知らないだけではないかと思いはじめました。

ということで、チーム制作の仕方なんてenPiTのような安心して失敗できる楽園があれば、すぐに覚えらるし、そもそも学生はグループワーク得意だし。チームでの開発ってすぐにできると思うんですよ。でも、そう思うと別の悩みが鎌首をもたげてきます。本当はチーム制作の活動を自主的に行って欲しいんですよねぇ。コミケやオンラインでソフトを販売するための閾値は下がっているので、同人でも、インディーでも、勝手に取り組んで欲しいんですよ。でも、学生は、それをほとんどしない。で、それが何故かと考えてみると、おぜん立てした環境に最適化されてしまっているのかなぁと思いました。学校から、「何々をやってください」と言われて、それをこなすような場ばかりにいて、それ以外のやり方ができない人が多いというか、そのような機会しか与えられていないのだと思いいたりました。部活でもサークルでも、ほとんどの人は既存の部に入るだけで、SOS団を立ち上げるような経験はまずないですよね？自分もそうですし、世の中の人の大半はそうなのだと思います。これは、アントレプトナー教育としろとかプロダクトオーナーを育てろいう事ではないです。テキーラ飲ませて喜んでいるような人がちやほやされる世界が良いわけではなくて、いかにフォーマットから外れた人を作るか・空気を読まない人を作るかという事が、必要じゃないのかなと、この文章を書きながら思いました。

何かに極振りさせてその結果をほめてあげる優しい世界が求められているのかもしれません。周囲の人は、デモを見た後、「やりきったかい？」と聞くだけでいいのかもしれません。もう、enPiTのような確実に価値が積み上げられる世界はいらないのです。えっ、enPiTは今年で終わることが決まってるって？お後がよろしいようで。

でも、アフターenPiTの新たな世界は作っていきたいですね。

という事で、日々悩んできた(いる)enPiTですが、今週末(12/19(土))は琉大と一緒にenPiTの成果発表会を行います。オンラインでどこでも見れますので、お時間がありましたら、ぜひご参加ください。

「東京都立産業技術大学院大学・琉球大学 enPiT2 成果発表会 2020」開催のお知らせ

リアルタイムレンダリング 第4版 (Real Time Rendering Fourth Edition 日本語版) の監修について

リアルタイムレンダリング 第4版 (Real Time Rendering Fourth Edition 日本語版)の監修をさせていただきました。

発売されためでたい時期での話ですが、先に自分の力不足を告白させていただきます。そのつもりはなかったのですが、甘く考えていたようです。ページ数は1100頁を超え、出版もなるべく早く出せるのが良いとスケジュールがタイトになっていたのはわかっていたのですが、なかなか手を進めることができませんでした。また、今回、監修は２名になっているのですが、他にもご協力いただいた方々がいました。貴重な時間を使って協力いただいたのに、お名前を残すような出来にできず、申し訳なく思っております。ということで、残念ながら至る所で間違いが残っております。監修時には下記のように用語をディスカッションしたりもしているのですが、治っていなかったり、他の用語でも間違っていたり通常は使われない用語で記載されている箇所があるかと思います。

しかし、ここは宣伝ブログw！良いところを見ていきましょう。

この本の何よりも良いことは、非常に高い網羅性です。リアルタイムなCGの技術について、余すところなく記されています。最近、ゲームエンジンを使ってビデオゲームを作ることが標準的になってきたので、低レベルな知識に触れる機会は減ってきています。が、細かな問題の原因を探っていくと、低レベルな知識が必要になる場面に必ず突き当たります。その時に、辞書的に情報が得られるのが本書です。特に、第４版になってきて、飛躍的に情報が増しています。紙で出版されることが念頭にある書籍はどうしてもページ数に物理的な制約を受けます（1000ページを超える本はいかにも綴じるのが大変そうです）。本書は版を進むにつれて、内容の説明ということから、情報へのリンクという意味合いが強くなってきました。各項目の内容の説明はさらっと行われ、適切なリンクを示すことで、最新の深いトピックスへたどり着くことができるようになっています。現在の、論文・解説資料の量は膨大です。その中の適切な場所にたどり着くのに、本書は最適な書籍となるでしょう。

この本は、今までも大量のリアルタイムCGに関連する技術書を翻訳されてきた中本さんの翻訳です。翻訳は、「意訳は極力せず、よくわからなかったときは原書の該当箇所がすぐわかるようにしている」という方針で進められているとお聞きしました。ということで、よくわからないときは、英語版の対応する場所にすぐに行きつけるはずなので、いまいちな監修でもなんとかしやすくなっています。

という非常に良い本。私はこの本の日本語版をどうしても出したいと思っていました。それは、同じ研究室の先輩(年下ですが)が、発信していたツイートにあります。

これは、CGの研究者が少ないということに関する他の先生とのやり取りに関するスレッドでのツイートでした。このツイートをひそかに読んで、「ゲーム(のCG)の基礎とは何だろう？」と思ってリストアップしてみました。で、実際に洗い出して感じたのは、「これ、Real-Time Rendering本の内容じゃない？」ということでした。もちろん、Real-Time Renderingに書かれていることがゲームにおけるCGの全てではないですが、本書の内容を把握しておけば、ゲームのグラフィックスにおける基礎は十分に習得できるのではないかと思っています。

そして、もう一つ、どうしてもこの本を出したかった理由が、川西 裕幸さんです。御存じの方も多いと思いますが、前の日本語版の翻訳をされていたマイクロソフトのエバンジェリストの川西 裕幸さんは、書籍の出版やCEDECなどでの登壇・ハンズオンセミナーを通じて、DirectXはじめ、日本でのリアルタイムレンダリング・ゲーム技術の拡散を牽引してくれていました。しかし、残念ながら交通事故で亡くなられてしまいました。川西さんが亡くなられてから、日本では定番かつ本格的な書籍の翻訳がほとんど出てこなくなったように思います。Game Engine GemsやGPU Zenは日本語に翻訳されていてもおかしくないですが、日本語版はありません。この事実にふと気が付くと、川西さんの偉大さを慮ります。誰かに頼まれたのではなく、自ら考えて日本のゲーム業界の発展に尽力されていたんだなぁと、お話として聞いていた新幹線通勤での翻訳作業を想像しながら、良い人から先に逝く悲しさに目が潤んでしまいます。しかし、後に残った我々は先に進まなければなりません。川西さんが点けてくれたこの灯を消さないために、お話を聞いた瞬間に引き受けさせていただく決心をしました。しかしながら、私の力不足を露呈してしまっただけになってしまったかもしれません。川口さんには、空の上から優しい笑顔で「イマギレさん、まだまだですねぇ」と笑ってくれていると救われるなぁと個人的には思っています。

いろいろな想いはございますが、リアルタイムなグラフィックスについて他にはない価値を持つ書籍です。本当に出版されて良かったです。ゲーム会社であれば各社一冊ずつ、できればグラフィックスプログラマ一人に一冊そろえていただきたいです。もちろん、グラフィックスプログラマであれば、会社の本は経費で買ってもらい、自宅用にもう一冊自分で買うのは言うまでもありません。

第4版と共にあらんことを！

ゲームプログラマ・エンジニアを目指してプログラミング言語を覚えた次に学ぶこと

この記事は、ゲーム制作 Advent Calendar 2018 の4日目の記事です。

そして、明日発売される書籍「ゲームプログラミングC++」の宣伝です。

ゲーム業界に入るのは難しい。近年はUnityなど素晴らしいゲームエンジンが出てきて、ゲームが手軽に作れるようになってきました。そう、デジタルゲームは、手を動かしさえすれば、誰でも作れてしまう世の中になったのです。逆にいえば、ゲームが作れるだけではゲーム業界には入れない世界になってしまいました。プログラマーであれば、より深いゲーム制作の知識や人と違った技術の習得が求められるようになってきたのです。と、いう話をゲーム業界の人とすると、「低レベルなメモリ管理ができなければいけない」、「直接3D APIを叩けなければいけない」という話に向かいがちなのですが、おいおい待てよと心に思うわけです。老害世代には、直接ハードをいじれる機会がありました。8bitパソコンのアセンブラ。DMAを直叩きしたPlayStation2。低レベルのプログラミングが機械を支配している万能感を与えてくれました。でも、今そんなのないって。人工知能のプログラミングをするなら手軽で速いPythonを選びますよね？Win32ならC++でプログラミングできるとかって、あなたのOS何ビットですか？Visual Studioでアセンブラを学ぶって言っても環境構築は面倒だし、昔みたいに、それをしないと性能が出しきれない状況にまず出くわさないので、そもそもの実際的な目的がないんですよ。ということで、自発的に低レベルな言語を学ぶ機会がないのが現代ではないでしょうか。そんな時代に老害世代と同じスキルを身に付けないと就職できないとか明らかにおかしい。しかし、そのような人たちが面接官という障壁として待ち構えている可能性高い現状、低レベルな技術を身につける必要があります。という理由だけではないのですが、ゲーム業界に入る前にゲームエンジンの中の知識をある程度は知らないとゲーム業界に就職しにくいというのが今の世の中といえるのではないでしょうか。

ゲームプログラミングを学ぶのは本当に難しいです。ゲームプログラミングを学ぶのに、最初にプログラミング言語を学習する必要があることは直ぐに思いつくかと思います。しかし、次の一歩が難しい。ジェイソン・グレゴリーさんの「ゲームエンジン・アーキテクチャ」は、その次の一歩ですが、この本はソースコードが少ない。頭で考えたことを自在に組み立てられる中級以上のプログラマにはお勧めで、沢山の良い知識を仕入れられるものの、初学者が書かれている事を即座に実装できるものではありません。「ゲームプログラミングパターン」という良書も訳されていますが、パターンを組み合わせてもアーキテクチャが生まれるわけではないので、この本を読んだところでゲームエンジンのような基盤が作れるようになるわけではありません。ということで、コンピュータ言語を学んだ後にゲームプログラミングを学んでいくための方法は悩みが深いのです。が、このミッシングリングを解く存在が「ゲームプログラミングC++」です。本書は、プログラムを少しづつ書き換えながらPongクローンからFPSのゲームエンジンを作っていくことになります。本書のソースコードは、GitHubのgameprogcpp/code に上がっていますので（英語版ですが）、具体的にどのような物を作るのだろうと気にされている方は、ご覧いただくのが良いかと思います。

もちろん、この本は完璧ではありません。今どき物理ベースレンダリングではないし、メモリ管理はSTL頼みだし、マルチスレッドではないし、エフェクト出ないし、ネットワーク扱わないし、バトルシステム作るならもっと作り込み必要だし。文句はいくらでもつけられます。まぁ、「そんなこと言うなら、お前書けよ」というのは最もですが、それは置いといて。本書を読めば実際に使える俺俺ゲームエンジン作れるようになるという事で、現代のゲーム開発者を目指す者・初学書にとって、必携の書籍といえます。

私は、本書の監修を務めさせていただきました。翻訳者の吉川邦夫さんの訳がすばらしかったので、こちらは、「ゲーム開発者はそんなこと言わないですよ」とか、「その意味違っていますよ」とかに集中することができました。で、おかしな点を指摘したら、原著からある間違いということが判明して、原著に訂正の指摘を出す事態に至ってもいます。ということで、英語版よりもある意味正確な日本語版。前半の方が文章がお堅い気もしますが、ぜひお買い求めいただければと思います。

明日のゲーム制作 Advent Calendar 2018 は、eunx32さんです。

大学のゼミでモブプロ中

この記事は、「モブプログラミング Advent Calendar 2018」の12月4日分の記事です。

早いもので、大学の先生をはじめてからもうじき三年になろうとしています。学生を素敵な場所にはばたかせようと思っているのですが、まだまだ試行錯誤の毎日です。そんなじたばたあがいていることに一つにモブプログラミングがあるので、やってみての事を書こうと思っています。

自分とモブプログラミングの関係はまだそれほど深くありません。TDDワイワイ会(TDDyyχ)に参加させていただいたのと、産業技術大学院大学のenPiT2 の「アジャイルチームキャンプ」でお手伝いをさせていただいた程度になります。ただ、ペアプロを以前の職場で導入して、教育に良さそうなことは実感として持っていました。

さて、モブプロを導入しようとしたきっかけは就活です。売り手市場と呼ばれる就職状況でも学生が希望する企業にたやすく就職できるわけではありません。話を聞くと、面接に行く前に落ちている学生も多く、基礎力が足りないのではと考え、プログラミング力の向上について検討していきました。所属している学科は、３年生の４月から各研究室に配属されゼミ活動を行っています。色々な授業でプログラミングの力を向上させることを考えているのですが、少人数での実習科目を受け持っていなかったので、ゼミでモブプロをしてプログラムの機会を増やそうと計画をしました。

今回は、３年生のゼミ生でモブプロをしました。学生の配属が４名だったために、自分を含めた５人でモブプロをしています。実施しているのは、毎週１限の時間で各自が持ち回りでドライバーを務めてプログラミングをしています。メディア的な学科の特性上(?)ゼミ室には65インチのテレビが置いてあるので、そちらにPCを繋いでワイヤレスキーボードでプログラミングをしています。使っているサービスはもろもろの理由で内緒なのですが、オンラインエディタで編集出来て、CIのテストも実装されている物を使っています。テストは、お題に対して既にユニットテストが書かれているものを使っているので、TDDをしているというわけではありません。

やってのところですが、お題的に30分から１時間の課題に取り組んでいるのですが、時間的に想定時間よりも早く終わる場合もあれば、３時間ぐらいかかる場合もありました。どうしてもドライバーがプログラミングをするという意識が強くなってしまい、発言を促しても、それに対して頑張ってくれる人もいれば、他人事のように扱ってしまう人も生じました。あと、何回かやるとプログラミング力の差がどうしても分かってしまいます。それを補うためのペアプロですが、どうしても良くできる人の発言が強くなるように感じました。まぁ、基礎力は上げってきているかな！？

プログラミングの教育としては、すでに組んだソースコードをレビューするということもやった事があるのですが、ある程度できたプログラムというのは、すでに手遅れな場合は多く、良くなるように導くというよりも書き直した方が早く感じたのですが、お題に取り組む場合は、きれいな状態から始められて、より良いパターンを教えるのも、少ない場所だけ指導すれば良いのでやりやすく感じました。

明日のモブプログラミングAdvent Calendarは、tronperidotさんです。

ゲームエンジニア養成読本

今回は、著者様から献本いただいたゲームエンジニア養成読本の感想です。

 

いやー、ダレ得なんですかね、この本？

ビジュアルスクリプトの話があるかと思えば、マルチスレッドジョブコントローラーのソースコードとか載ってるんですよ。頭おかしいでしょ？！（良い意味で）

かなりターゲットが絞られているところがすがすがしくて良いと思います。
これ一冊読めば、ノードベーススクリプトの実装部分が書けるという中身になっていますね。
鬼だ（とても良い意味で）

 

今は、ゲーム作りで先生をしているのですが、日々悩んでいるんですよ。
ゲーム会社のプログラマに、どうすれば学生が業界入れますかねぇとか聞くと、「ゲームエンジンでゲーム作れるだけでは、業界入れない。」とか、「C++ができなければだめだ。Unity使ってるんで触ることないけど。」とか聞く事が多いので、どうすればいいんだよとかよく考えます。「C++でのメモリ管理とか、できると強いんだろうけど、そんなコード書く機会可能性はほとんどないだろうし（どうせ、そういうの書くの好きで得意なおっさんが仕事取っちゃうでしょ）、それを強いるのって老害じゃないかなぁ」と思ってしまうんですよねぇ。

そういう意味では、この本は、スクウェア・エニックスの人たちが書いているだけあって（辞めている人もいるけど）、「現場では、この技術使っているんですよ」と感じられるところがとても良いですね。転職組の人たちが書いているので、「その会社独自の文化でしょ」という印象も薄められている感じも素敵。そして、FFのコーディングルールはこんななんだろうなとか想像するのも楽しい。

閑話及第。読み終わって、この本は、コンシューマゲームプログラマが身に着けておくべきスキルを把握するのに、とても良いように思いました。プログラマ志望者でも結構デバッグの仕方を知らない学生がいるので、「このぐらい覚えておけ」とか提示するのによさそうだなぁと思っています。

ちょうど今、マルチスレッド教えているから、この本の内容を宿題に出そうかなぁ

 

P.S. 参考文献に載っている「ゲームエンジン・アーキテクチャ」もよろしくね

継続的レイトレ合宿

はじめに

このページはレイトレ合宿5‽のアドベントカレンダー2週目の記事です。
べ、別に、怖い人たちが記事を書く前に、さっさと済ませておこうなんてつもりじゃないんだからねっ！

概要

さて、本題に入りますが、レイトレ合宿では、レギュレーションが定められています。
例えば、一枚絵の場合には、次のようなルールになっています。

• 何もインストールしていないまっさらなマシン上で動作するようにしてください。
• 実行ファイルを叩いたら自動で始まるようにしてください。キーボード、マウスの操作を要求する作りにしないでください。
• ネットワーク越しに何かをやるような動作をさせないでください。
• おおよそ30秒毎に、レンダリングの途中経過をbmpかpngで連番(000.png, 001.png, …) で出力してください。
• 4分33秒以内に自動で終了してください
• マシンスペック：AWS(Microsoft Windows Server 2016 Base/Amazon Linux)

もーめんどくさいなぁ。
ルールに準拠するサンプル用意してくださいよ～

と思ってしまうのは、人の常ではないでしょうか？！

と言うことで用意したのが、imagirelab/raytracingcamp5 になります(Amazon Linux AMI 2017.03.1.20170617 x86_64 HVM GP2で動作確認済み)。
同じようなものは以前、用意したのですが、今年は一歩進めてCDですよ、CD。
CDといっても、Compact Disc 出はなくて、Continuous Delivery。そう、継続的デプロイです。
プログラムをGitHubに上げると、ビルドをしてzipして、すぐ配れるんですから。
それだけじゃなくて、プログラムを実行して、実行結果がホームページとして見れてしまうのですよ。

この環境を使えば、ローカルにビルド環境や実行環境がなくてもレイトレ合宿のプログラムができるのですよ。
そう。スマホからレイトレ合宿の開発が可能です！

中身

やっていることは、Travis CI をまわしてるだけです。

ルートに.travis.ymlを置いて、あとは、pushされたときに自動実行していきます。

ビルドと実行に成功した後は、別のリポジトリにpushして、GitHubのgh-pages(リポジトリをホームページにする機能)を使って、公開します。ホームページのHTMLは、あらかじめ静的に用意しておきます。

フォルダ構成

使わないファイルを省くと、リポジトリのファイルは次のようになっています。srcフォルダ内が実際のレイトレのファイルで、sdkフォルダに外部のライブラリを格納しています。static フォルダは、ビルド結果のホームページの静的ファイルで、HTMLファイルを用意しています。ちなみにレイトレ自体は、Shirley御大の In One Weekend （週末レイトレーシング）の内容に少しだけ手を入れたものとなっております。

+--README.md // GitHubのリポジトリアクセス用
+--LICENSE // ライセンス表示
+--.travis.yml // TravisCIの設定ファイル
+--.gitignore // gitの対象ファイルの設定
+--src // レイトレのソースファイル
| +--main.cpp
| +--makefile
| +--my_rand.h
| +--raytracingcamp5.sln
| +--raytracingcamp5.vcxproj
| +--raytracingcamp5.vcxproj.filters
| +--renderer.cpp
| +--renderer.h
| +--RT_struct.h
+--static
| +--index.html// ビルド後のホームページのHTML
+--sdk
 +--stb // nothings/stb(1ファイルヘッダオンリーのライブラリ集)
   +--stb_image.h
   +--stb_image_write.h

.travis.yml

ビルドのかなめは、.travis.yml です。.travis.yml の最初は環境変数の設定になります。

language: cpp
env:
 global:
　- email=imagire@gmail.com
　- username=imagire
　- secure: "v6…（中略）…U="

今回は、C++を使うので、cppのコンテナを呼び出します。また、git用にメールアドレスや、ユーザー名を設定しておきます。

その後の、secureは、GitHubのパスワードを暗号化して書き込んでいます。具体的には、次の様に作ります。この文字列は、後から出てくる${GH_TOKEN}という文字列を実際に使用する際に、複合化されて呼び出されます。この暗号化の手順は次の通り。

• GitHubの自分のプロフィールから、Personal access token を取得
• sudo gem install travis でtravis CI Clientをインストール
• travis encrypt -r (ユーザー名)/(リポジトリ名) GH_TOKEN=(取得したPersonal access tokens) でPersonal access tokenを暗号化
  • 例：travis encrypt -r imagirelab/raytracingcamp5 GH_TOKEN=c45cf01c53cf64b41869b3f070e64e7783d177ed

まぁ、でも、コンソールで行わないといけないので特にWindowsの人は面倒ですよね。travis CIの「setting」-「Environment Variables」で設定するという方法もあります。

.travis.ymlのその次の行からは、実行するコマンドです。「-」をつけて、実行する命令を並べていきます。今回は、gcc を makefile をつかってビルドしています。make dependで依存性を調べた後、makeでビルドします。ビルドファイルはa.outとしています。

実行ファイルができた後（レイトレ合宿5ではzipで提出するので）、実行ファイルをzipで固めた後、実行ファイルを実行しています。

script:
　# gcc のバージョンを確認してみる
　- g++ --version
　# build
　- cd src
　- mkdir bin
　- make clean
　- make depend
　- make
　- ls -lsaR # ファイルがビルドできたか確認
　# 実行
　- cd bin
　- zip -r raytracingcamp.zip ./ #zip を作る
　- ./a.out # プログラムの実行!

ここまでできたら、事後のプロセスということで、GitHubに結果を上げていきます。masterブランチのみの更新を対象として、プルリクでも呼び出しは更新に含めないというのが定番な設定のようなので、その設定を最初に行います。次に、あらかじめホームページ用のHTMLファイルを置いておいた「static」ディレクトリの中身をコピーしてきてから、gitに追加して、GitHubに上げています。GitHubのリポジトリは、ソースコードのリポジトリと別のリポジトリにしています。

after_success: # デプロイ
　- test "$TRAVIS_BRANCH" != "master" && exit 1 # マスターブランチが更新されたのでなければ無視
　- test "$TRAVIS_PULL_REQUEST" = "true" && exit 1 # プルリクで呼ばれた時にはデプロイしない
  # 静的なHTMLファイルを取ってくる　
  - cp ../../static/* . 
　# git に新しくpush
　- git config --global user.email "$email"
　- git config --global user.name "$username"
　- rm -rf .git
　- git init
　- git add --all
　- git commit -m "deploy commit from travis"
　- git push -f https://${GH_TOKEN}@github.com/imagirelab/rtc5.git master

サービス設定

GitHubの設定は、ソースコードが置いてあるリポジトリの設定の、「Integrations & services」でTravis CIを追加します。具体的な設定方法が詳しく知りたい方は、例えばこの記事を書いているのググった結果の一番最初にあった「さくらのナレッジ:GitHubと連携できる継続的インテグレーションツール「Travis CI」入門」などの入門記事がありますので、そちらを読まれると良いでしょう。

また、実行結果の方のリポジトリ(imagirelab/rtc5)は、GitHub Pages の設定を行います。こちらは、GitHubのリポジトリの設定で、ホームページとして公開するブランチを指定すれば、ホームページのURLをもらえ、ブランチが更新されるたびに、ホームページが自動で更新されます。

さいごに

さぁ、このプロジェクトをforkして、srcの中身をあなたのレイトレに書き換えれば、あなたもレイトレ合宿に参加可能です。

諏訪湖で僕と握手！

モダンアジャイルの原則・実践について

Agile Japan 2017 小冊子である、「アジャイルの魂 2017」で執筆させてもらえることになりました。

本年は、ジョシュアさんが基調講演に来られるということで、モダンアジャイルのプラクティスについて書かせていただきました。

おかしなところがありましたら、教えていただけると嬉しいです。

---

はじめに

ここでは、私が勝手に図を訳して公開した、Industrial Logic社の「Modern Agile」の記事に書かれた十二の「モダンアジャイルの原則・実践」について見ていこうと思います。と、思案して何度か推敲したのですが、ジョシュアの言葉をストレートに皆に伝えるのが最も価値が高くなると考え、ブログ記事の部分的な勝手訳となりました。現在のモダンアジャイルは、公式サイト(http://modernagile.org/)で、洗練化されていますが、源流を覗く事で理解が深まれば幸いです。

この後の見出しの頭は、関係する次の原則(元は規律だった！)を表します（先頭が主要な原則）。

• [最高]人々を最高に輝かせる
• [安全]安全を必須条件にする
• [高速]高速に実験＆学習する
• [継続]継続的に価値を届ける

 

[最高・安全]仕事の憲章化(Charter Your Work)

人々を最高に輝かせたいなら、その意味を定義する必要があります。アジャイル憲章は、明確なビジョン、ミッション、テスト可能な成果物を、プロダクトコミュニティが発見し、同じ立場で考えてもらうための軽量なプラクティスです。憲章の設置は、プロジェクトの最初に一度だけ行うものではありません：憲章の設置は継続的な試みです（アジャイル憲章は英語だと “ing”が付いています）。良い憲章はガードレールのようなものです。道を逸れるのを妨きます。 憲章の二人の専門家、エインズレイ・ニースとダイアナ・ラーセンは、著書「Liftoff：Launching Agile Teams＆Projects(リンク先は第2版)」でこの重要なプラクティスについて述べています。

 

[高速・最高・安全]リーン・スタートアップの活用(Leverage Lean Startup)

大規模な組織、小規模なスタートアップ、またはその中間のソフトウェアを開発する場合でも、エリック・リースの古典的な「リーン・スタートアップ」の知識を活用するとよいでしょう。人々を最高に輝かせるために、エリックは、私たちの大部分が「不確実な状況下で活動してしまっている」ことを理解するのを助け、ユーザーが必要とするものを推測する事がいかに安全でないのかを明らかにしてくれます。 彼は、素早く簡素な実験や仮説の迅速な検証・無効化など、精緻なコードを作るための投資をしてしまう前に、何を作るべきなのかを発見するための、さまざまで有用な方法を提案してくれます。 もし、ユーザーが実際にソフトウェアを使用しているかどうか、利益を受けているかどうか、超すげーことになっているかどうかを、あなたが分かってないならDoneの定義を再定義する必要があります。 また、企業内でリーンをスケールするのに苦労しているなら、ジェズ・ハンブル、ジョアンヌ・モレスキー、バリー・オライリーの「リーンエンタープライズ――イノベーションを実現する創発的な組織づくり」を勉強するのがいいです。

 

[高速・最高]リーンUXの適用(Apply Lean UX)

リーン・スタートアップに密接に関係しているのがリーンUXです。リーンUXは、優れたユーザー体験を発見して作り出すための、迅速で低コストな分析主導のアプローチです。 私は、リーンUXコミュニティの代表者であるローラ・クラインの「機能の見せ掛け」テクニック（多くのリーンUX技術の一つ）を学びました。 リーンUXの詳細については、ジェフ・ゴーセルフとジョシュ・セイデンによる「Lean UX ―リーン思考によるユーザエクスペリエンス・デザイン」と、ローラ・クラインの「UX for Lean Startups: Faster, Smarter User Experience Research and Design」から学ぶことができます。

 

[高速・安全・継続]頻繁な協調と統合(Collaborate Integrate Frequently)

チーム内やチーム間でのコラボレーションと統合が貧弱だと、組織は危険にさらされます。これは、ソフトウェア開発における多くの問題の根本的な原因になっています。ソロワークは、知識サイロ（何かの仕組みを一人だけしか知らない）、より大きな欠陥、脆弱な問題の解決、より強い注意力の散漫と、より少ない規律（特に良いテストを書いたり、リファクタリングによる設計の改善に対する）を生み出す傾向があります。ペアリングとは、二人で一緒に仕事をし、ペアを定期的に交換することです。モブプログラミング(mobbing)は、三人以上で協力して、キーボード・マウスを「ドライブ」する人を定期的に交代する、開発に対するコミュニティアプローチです。ペアリングとモブプログラミングの両方が、学習のスピードを高め、価値のある結果を生み出す流れを加速し、重要なスキル・知識に対する危険な依存性を減らし、技術への容易な変更を可能にし、人々を最高に輝かせるものをもたらします。ディープソロの作業（深い単独作業）を可能にするチームもあります。彼らはコードレビューによる協調作業によって素早くマスターブランチに統合していきます。

 

[安全・高速]安全に失敗できる環境(Make it Safe to Fail)

あなたの会社に恐れの文化があるなら、どんなすばらしいプラクティスやプロセスもあなたを助けられません。最高の企業は、人々が実験、失敗、異議、そして彼ら自身が安全と感じる文化を育成します。デイブ・スノーデンは、小規模で安全な実験によって複雑なシステムに起きる大切な応答を得るのに役立つセーフフェイルプローブの利用を説きます。安全に失敗できる企業は、「学習する組織」です。 Etsy社は、その輝かしい例になります。最も最近入った新規社員の一人が、大切なCSSファイルを間違って削除してウェブサイトをダウンさせました。彼らは何をしたでしょうか？ 彼らは、そのエンジニアに、重大な欠陥を発見した「三つ袖があるセーター賞」を与え、サイトをより柔軟性の高いデザインに修正しました。

 

[安全・継続]テストとリファクタリング(Test Refactor)

テストと設計はアジリティの本質です。モダンアジリストは、探索的テスト、自動テスト、（主に設計の活動であり、副次的にテストの活動でもある）テスト駆動開発や、いくつかの手動テストを実行します。Industrial Logic社でテストとリファクタリングの訓練・指導をしたモダンアジャイルコミュニティでの定量的な研究の一つでは、欠陥が八〇％以上減少しました。信頼できる高速で自動化されたソフトウェア動作チェックがあることは、プログラマが、コードの変更や欠陥の生成を恐れることが少なく高速に仕事ができるセイフティネットを持つことになります。リファクタリング（挙動を変えずに既存のコードの設計を改善する）は、設計が複雑になることを回避し、コードを簡単かつわかりやすく（したがって変更しやすく）する重要なプラクティスです。リファクタリングは「見直し」です。これは、ラテン語では再び見る（re-videre）を意味します。私たちはもっと学び、以前の作業の欠陥を発見し、コードの設計・読みやすさ・シンプルさを向上させるように努力することで見直しを行います。テストとリファクタリングは、共にチームのスピードに不可欠な存在であり、それゆえモダンアジャイルの重要な部分です。

 

[安全]人々への敬意と感謝(Respect Appreciate People)

安全の文化を確立するには、（役割、年齢、学歴、人種、性別によらない）心からの敬意と感謝が重要です。アンゼニア（Anzeneer）は、時間、お金、情報、評判、関係、健康を守り、人々を尊重します。コラボレーションアプリのSlackが、一ヶ月まるまるサービスにアクセスしなかったので、ある程度の金額を払い戻しましたというメールを送ってきた時、私は敬意と大事に思われていることを感じました。Alcoa社の前CEOであり、米国の財務長官であったポール・オニールは、組織が不断の卓越性を達成するためには、人々が何時でも誰にでも尊敬され感謝される文化を持たなければならないと述べました。Industrial Logic社では、DuePropsを使用して定期的に皆に感謝しています。

 

[安全・高速]非難しないふりかえりを指揮(Conduct Blameless Retrospectives)

セス・ゴーディンは、かつて「人々は失敗を恐れず、責任を恐れている」と言いました。ノーム・カースの二〇〇一年の古典的な本「Project Retrospectives: A Handbook for Team Reviews」に、「最初にふりかえりを試みたときに人々が最も露わにする恐れの1つは、儀式が非難と反論を撒き散らす否定的なグチのセッションになるというものです」とあります。ゆえに、ノルムは、ふりかえりの前に慣習的に読まれるかの有名な「ふりかえりのお約束」を定義しました：たとえどんなことに気付いたとしても、チーム全員が、その時点で知っていたことや彼(彼女)のスキル及び能力、利用可能なリソース、そしてその時の状況で最善を尽くしたのだと理解し、心の底から信じます。このお約束は、ふりかえりを学びに焦点を当てた安全な場になるように整えます。Etsy社のジョン・オルスポーは「Blameless Postmortems and a Just Culture」で、これについて書いています。エスター・ダービーとダイアナ・ラーセンは、「アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き」という優れた本を書いています。

 

[継続]フローに集中(Focus on Flow)

モダンアジャイルは、タイムボックス（例えば、スプリントやイテレーション）による作業の連続的な流れを好みます。カンバンは連続フローを可能にします。カンバンボードを使用して、チームは作業をボード上で見える化し、重要な作業をボードに設けられた列を移すことでプルし、仕掛品を制限し、サービスの分類（緊急または正常な作業など）を補助し、ボトルネックを見える化して取り除き、開発中の価値を人々に流します。タイムボックス内でどれくらいの作業をするかを予測しようとする時間を費やしたり、ストーリーポイントの正確な値を考慮したり、魅力的なバーンダウンやバーンアップチャートを公開するために見栄えを良くしようとする必要はありません。これは、合理化されたアジャイル計画です。デイヴィッド・アンダーソンは、彼の極めて重要な著書「カンバン: ソフトウェア開発の変革」でそれを美しく表現しています。

 

[継続・高速・安全]継続的なデプロイとリリース(Deploy Release Continuously)

ケント・ベックはかつて、ティモシー・フィッツによる「不可能な一日五十回をやっている」という衝撃的なビデオを私に示しました（ああ、不運なインターネットプロバイダーはティモシーの素晴らしいビデオを失いましたが、彼はそれについてのブログを書きました）。ティモシーは、IMVU（リーン・スタートアップの発祥の地）が、一日に何回もプロダクション環境へ安全にデプロイすることによって、初期アジリストの想像をはるかに上回る継続的インテグレーション（CI）の実践をしていることを説明しました。CIのダイアルは十一に調整されました。継続的デプロイは、早期な速い実験（A / Bテスト等）を実現し、ユーザーが最も必要とするものをできるだけ迅速かつ安全に提供することを可能にします。これは、「コンセプトをキャッシュにする」までのサイクルを劇的に減らすので、私が好きな、リーンに影響を受けたプラクティスの1つです。ティモシー・フィッツは Industrial Logic社と一緒にCD(継続的デリバリー)のeラーニングコースを作成し、現在、モダンアジャイル・プラクティスに関する本を書いています。ジェズ・ハンブルとデイビッド・ファーレイは、このプラクティスの深い専門家であり、「継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化」の著者です。

 

[継続・安全]プロダクトコミュニティを形成(Form Product Communities)

適切な人がいなければ、人々を最高に輝かせるソフトウェアを作成することはできません。適切な人々は、プロダクトコミュニティを作り上げます。 デイビッド・シュマルツの言葉によれば、プロダクトコミュニティは「プロダクトに影響を与えたり、プロダクトに影響を受ける可能性のある人々」です。デービッドは、このようなコミュニティは「常に」あなたが思っているよりも大きく、ほとんどのプロダクトが直面する主な問題は「自分自身のコミュニティ意識の欠如」であると考えています。プロダクトコミュニティは、フロントエンド、バックエンド、ミドルウェア、およびUXチームに分かれておらず、独自のバックログを持ちます。プロダクトコミュニティはフルスタックであり、原始的なソリューションを、人々を最高に輝かせ、組織の成功に役立つ洗練されたプロダクトへと進化させる準備ができています。プロダクトコミュニティを形成することは、誰が何をどのようにすることが重要な結果を達成するのに不可欠であるのか認識するのに役立ちます。プロダクトコミュニティは、「憲章」において頻繁に定義付けと洗練化が行われます。

 

[継続・高速・安全]ソリューションを進化(Evolve Solutions)

ソリューションをすばやく進化させるには、人材とチームを組織して、何を構築し、協調し、統合し、開発し、リリースするのか計画する必要があります。モダンアジャイルな「お店」は、フィードバックからすばやく学ぶため、ユーザーにプロダクトや機能をすばやく提供します。「進化の設計」はこのような学習の鍵であり、ユーザーに価値をすばやく伝える最良の方法の一つです。また、プロダクトコミュニティ内やプロダクトコミュニティ間での協調と統合のリスクを明らかにし、修正するための非常に便利な方法です。

 

参考文献

Joshua Kerievsky, “Modern Agile”, https://www.industriallogic.com/blog/modern-agile/

今給黎 隆, 「モダンアジャイル」, http://www.slideshare.net/imagire/ss-64457130

CSP(認定スクラムプロフェッショナル)を取得しました

認定スクラムプロフェッショナルとは、開発プロセスの１つであるスクラムに関して、実践をして、学んだことがまとめられ、深い知識があることを認定する資格です。研修やテストの受講で取得できる資格ではなく、認定スクラムマスターなどを取得した上で、今までの実践をドキュメントにまとめてレビューを受けなければなりません。

認定スクラムプロフェッショナルは、私が取得した時点で全世界で3738人、日本にいる人としては25人と、まだまだ少ない人数です。この段階で資格を取得できたことは、スクラムに関するアーリーアダプターとして他の方の参考になる人にならなければと身が引き締まる想いがします。

認定資格に関しては、資格を取得するために認定団体の収入になるポイント稼ぎをする必要があったり、「取らないと気になるけれど、取っても食べられない」という足の裏のご飯粒のような資格であることも確かでしょうし、資格を持っているからといって技能があるとは限らないなど、認定ビジネスの是非を含めていろいろなご意見があるかと思います。私にとっては、自分の周りの人で認定スクラムプロフェッショナルを持つ人が増えてきたというのもあるのですが、スクラムに関して、聞きかじりで導入して間違った運用をされているのを多く見るにつれ、適切な助言ができる存在になりたいと思い、資格の取得を決意しました。

この資格の取得には、今まで一緒に仕事をしてきた方々や、コミュニティなどでお会いした方々からのご協力、ご指導がなければ叶えられなかったものなので、こちらで改めて御礼をさせていただこうとおもいます。ありがとうございました。

また、認定スクラムプロフェッショナルを取得するにあたっては、伊藤さん(id:hageyahhoo)さんの「How to acquire CSP／「認定スクラムプロフェッショナル」の資格を取得する方法」を参考にさせていただきました。認定スクラムプロフェッショナルの資格取得は英語でやり取りされるため、日本語での情報は、申請をするにあたる敷居が下がり、心理的に大変楽に資格を申し込むことができました。ありがとうございました。

現在、認定スクラムマスター、認定プロダクトオーナー、認定スクラムディベロッパーを所持している方、もしくは取得を意識されている方は、実践することで取得できるこの上位資格を心に留めておいていただければと思います。

まだまだ未熟で、間違った発言などもあるかと思いますが、今後も資格の名に恥じないように学び、成長していきたいと考えております。これからもよろしくお願いいたします。

レイトレ合宿3?

皆様、レイトレ合宿ってご存知ですか？

絶滅危惧種(いい意味で)と思われているレイトレ人が一同に集まる会らしいです。

そんな会が来月の月末8/29(土)～8/30(日)に「レイトレ合宿3」という名前で開かれるらしいです。
私は残念ながら別の予定が入ってしまっていけないのですが、レイトレに興味がある人は参加してみてはいかがでしょうか？

という紹介だけでは悔しいので、ちょっとプログラムを組んでみました。

レイトレ合宿をみると、単純にレンダラを組めばいいのではなくて、レギュレーションに従って出力しないといけないとのことです。
特に次の2つは、時間がからむので少し厄介です。

• おおよそ30秒毎に、レンダリングの途中経過をbmpかpngで連番(000.png, 001.png, …) で出力してください。
• 15分以内に自動で終了してください。

ということで、30秒ごとにBMPを出力して、15分前には終わるレンダラを書いてみました（レンダラ自体の中身自体は、smallptや、eduptのほぼコピペです）。

https://github.com/t-pot/RayTraCamp3

逆に言えば、あとは「src/renderer/renderer.h」以下のレンダラを書き換えるだけで何とかなるので、レイトレ合宿に参加しやすいのではないでしょうか。

でも、こんな簡単なプログラムで、こんなきれいな絵が出るなんて、今の時代すごいね。