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

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

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

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

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

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

GPCpp.jpg

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

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

広告

大学のゼミでモブプロ中

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

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

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

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

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

mobpro

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

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

明日のモブプログラミング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フロー.png

ルートに.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」で設定するという方法もあります。

traviscienv

.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」入門」などの入門記事がありますので、そちらを読まれると良いでしょう。

TravisCiIntegrations

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

TravisGhPages

さいごに

さぁ、このプロジェクトを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(認定スクラムプロフェッショナル)を取得しました

Takashi Imagire-ScrumAlliance_CSP_Certificate

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

認定スクラムプロフェッショナルは、私が取得した時点で全世界で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」以下のレンダラを書き換えるだけで何とかなるので、レイトレ合宿に参加しやすいのではないでしょうか。

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

29