エフェクティブプログラマー

だんだん夏っぽくなってきたなぁと思っていたのですが今日の大阪は
あいにくの曇り空です。
今日だけではなく天気予報ではしばらく曇り空が続くようですね。
がヘキサドライブでは毎年恒例になりつつある例のアレの準備が着々と進められています。
今年は過去最大の参加人数になりそうで今からワクワクしているシラッチです。


さて、E3の話題を…というわけではなく、今日は身近で地味な？自動化の
具体例について書いてみたいと思います。

いきなりですが
「Release ビルドを行った実行ファイル(exe)を zip 圧縮して、所定のパスへコピー後、メールで連絡する」
という作業があったとします。
簡単な作業に思えるかもしれませんが、もしこれを
「１年間、毎日１回、決められた時間に」
という条件付きで行うとしたらどうでしょうか？

他に緊急の作業が割り込んで、予定していた時間に対応が
行えない時や、単純に忘れていたなんてことがあるかもしれません。
そんな時真っ先に私が思いつくのは「自動化」です。

例えば、以下のような BAT ファイルと Python スクリプトで実現できそうです。
動作確認環境：
Windws7、Visual Studio 2010、Python 3.2.2

build.bat

call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"
MSBuild .\sample\sample.sln /property:Configuration=Release /property:Platform=Win32 /target:Rebuild

work.py

# -*- coding: utf-8 -*-

import os
from zipfile import ZipFile, ZIP_DEFLATED
import shutil
import smtplib


def compress_file(compress_filename, zip_filename):
    """ 指定のファイルをzip圧縮 """

    target_file = ZipFile(zip_filename, 'w', ZIP_DEFLATED)

    dst_path = './%s' % compress_filename
    target_file.write(dst_path, compress_filename)

    target_file.close()


def send_mail():
    """ メールの送信 """

    smtpserver = '【SMTPサーバ名】'
    from_addr = '【送信元メールアドレス】'
    to_addr = '【送信先メールアドレス】'
    msg = """From: %s
To: %s
Subject: コピー完了のお知らせ
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;  charset="UTF-8"


コピーし終わりました。
""" % (from_addr, to_addr)

    smtp = smtplib.SMTP(smtpserver)

    smtp.sendmail(from_addr, to_addr, msg.encode('utf-8'))
    smtp.quit()


def main():

    # ビルドを行うバッチを実行
    os.system('build.bat')

    # 実行ファイルをzip圧縮
    compress_file('sample/Release/sample.exe', 'sample.zip')

    # zipファイルを所定のパスにコピー
    shutil.copy('sample.zip', '【所定のパス】\\sample.zip')

    # 完了のメール送信
    send_mail()


if __name__ == '__main__':
    main()

あとは Python スクリプトの呼び出しを Windows のタスクや
Jenkins のジョブとして登録しておけば、定期的に行わなければ
いけない作業から解放されます。

手動で行った場合、１回に10分かかるとして 365日行ったと
仮定したら、単純計算で 3650分（60時間50分！）もこの作業に
時間を使ってしまう事になる…と考えると手動でやるのは
もったいないと思ってしまいます。

挙げた例は極端かもしれませんが、少しコストパフォーマンスを
意識出来れば、ゲームを開発するうえで新しいアイディアを考えたり
更なるクオリティアップに専念するための時間が、しっかり
確保できるようになるかもしれませんね。

今にやっているお仕事のクオリティもガンガンアップするよう
工夫していきたいと思います

視点

こんにちは。さいやん、こと齊藤です。

昨今の円高で日本のものづくりの危機が叫ばれています
日本でものを作っても、円高では海外に売る場合に
利益を圧迫することになるからです。
　1$ = 100円のときに80円の原価でものを作って1$で売れば
　日本円にして100円で売れるので20円の利益が出ますが、
　1$ = 80円（円高）のときに80円の原価でものを作って1$で売っても、
　日本円にして80円にしかならず、利益は出ないからです。
　円高前から輸出で利益を上げていた企業は利益が出なくなって
　きていることが分かると思います。
すなわち、円高の現状では今までの商売が成り立たなくなってきます
さて、どうすればいいのでしょうか。
価格競争ではなく他には真似できない技術で勝負し、
オンリーワンの価値を売り込めるようになるといいのではないでしょうか。
では、オンリーワンの価値はどうやって生み出せばいいのでしょう
この問いに簡単に答えられれば苦労しません…
しかし、ヒントはあります。

最近では「生物模倣」と言われる手法で様々なものが生まれています。
トンボの羽を模して作られた風車は極微風でもとらえることができ、
効率よく回ることから従来以上の効率的な風力発電が可能になりました。
蚊の口を模して作られた注射針は痛みを大幅に軽減することが
可能になりました。

世の中の事象で、「どうしてだろう？」と疑問を持つことは
非常に大切だと思います。
生物模倣は生物の構造を研究し、学ぶことで新しい技術に
昇華させることですが、身近なことでも、
「あの人はどうしてあんなに仕事ができるんだろう」
「あの会社はどうしてあんなに儲かっているんだろう」
「あのゲームはどうしてあんなに面白いんだろう」
と疑問を持って研究することで、見えてくるものがあると思います。

少し視点を変えるだけで、他者とは違った結論にたどり着く。
そこから生まれる独自性に価値が生まれたとき、
イノベーションとともに新たな領域に踏み出せるのではないでしょうか。

専門家として、ある一点を掘り下げることも大切ですが、
視点を変えることで見えることも大切にしていきたいと思います

車輪の発明

2月も後半になってようやく暖かくなってきたなと思いきや、朝起きたら関東はなんと雪
都心はそうでも無いのですが我が家の近辺は道路までしっかり積もっていて大変でした　
こんにちは、ゆうです。
去年から未だにSkyrimをプレイしていますが、
PC向けに先日待望のCreation Kitがリリースされました　

Creation KitはBethesda社によるSkyrim用公式MOD作成ツールですが、
追加のMOD作成のみならず、何と既存データの編集を行う事も出来ます。
Skyrimがどういうデータで構成されているのか確認する事が出来るという太っ腹なツールで、
軽く覗いてみただけでもその圧倒的なボリュームに驚かされる事でしょう。
特にゲームを作ってみたいと思っている方には非常に勉強になるのでは無いかと思います。
ただ、データの変更が面白くてゲームが全く進まなくなってしまうのが難点ですが・・・



圧倒的なデータ量のSkyrimですが、
3Dモデル・テクスチャ・テキスト・音声・敵のAIやパラメータ等々、
大量のデータで構成されている点では他のコンピュータゲームも変わりありません。

ではそのデータはどのように作成するかと言うと、
モデリングツールやペイントツール、表計算ソフトやテキストエディタ等市販のツールを使ったり、
専用のツールを使用したりして作成しています。

専用のツールはインハウスツールと呼ばれ、
各社毎、もしくはプロジェクト毎に開発された物で基本的には公開される物ではありませんが、
CEDECの講演等でノウハウと共にお披露目されたりする事もあります。

では、何故開発の工数を割かねばならず、
時にはその後のメンテナンスが必要になる専用ツールを作成するのでしょうか。

一つは、出来無い事を出来るようにする、という点があります。
汎用的な機能を持つ市販ツールではフォローできない様な
ゲーム独自で必要な事を実現する為に作らざるを得ない場合です。

他には、代替手段はあるけれど開発効率を挙げるために作成する場合もあります。
日々の作業で必要となる手間を減らし、
効率を上げることで減る全体の工数がツール作成の工数を上回る場合は
インハウスツールを作成する事は有益だと言えるでしょう。



自分の先輩にいつも素晴らしいツールを作成する人がいました。
使う人の事が良く考えられており、
そのまま販売しても遜色ないのではないかと思えるとても使いやすいツールです。

自分はゲームを作りたかったので、
ツールを作るのはあまり面白い仕事だと思えず、
何でそんなに機能を盛り込んだ物を作る事ができるのかと尋ねた事がありました。
先輩は
「自分は面倒かもしれないけど、
　インターフェースをわかりやすくしたり操作性を良くする事でチーム全体の無駄な作業が減り、
　その分必要な所に時間を掛けられるようになるよね。
　それって間接的にではあるけれど、
　ゲーム全体のクオリティを上げる事に役立っているんじゃないかな」
と答えてくれました。
その時は、そういう物かな、としか思わなかったのですが・・・

次第に自分の事だけでなく全体を見られるようになってきて、
ようやくそれがとても大切な事だったんだと気づきました。
1回の作業あたり1分の効率化でも、1日10回操作すればそれだけで10分、
1ヶ月で200分、さらに掛けることの人数・開発期間分です。
その分ビジュアルのクオリティを上げたり、
キャラのアクションを増やしたり、色々な事に時間を割けるようになります。
それは、最終的にはプレイした人の満足へ繋がるのではないでしょうか　

高機能な専用ツールを作る事は必ずしも重要では無いですが、
全体のバランスを見て効率化を行い、
より大切な事に時間を費やせるようにする事はとても重要だと思います。
ツールだけで無く、例えば座席の配置やPCの操作機器を変える等でも変わるかもしれません。



さらには開発業務のみならず、勉強や生活自体にも同じ事が言えると思います　
楽をするために苦労をする、そんな視点で日々を見なおしてみると、
色々捗るようになるかもしれませんね！

−・−・−・−・−・−・−・−・−・−・−・−・−・−・−・−・−・−・−・−・−

なお、明日3/1より二日間は松下のblog記事にもある通り、社員旅行となっております。
ヘキサドライブblogの更新もお休みとさせて頂きますのでご了承下さい。

クリエイターの栄養

こんにちは。
ゲームを朝イチで買うためだけに早起きするえーきちです

今日も「ダークソウル」を買うために早起き・・・
のつもりがうっかり寝過ごしてしまい
結局いつも通りの出社になってしまいました・・・

***

さて、もはやゲーミングプラットフォームとしての地位を確立した
といっても過言ではないスマートフォンですが
今秋発表・発売と噂されている iPhone5 を au でも発売すると日経ビジネスが報じています。

もちろん正式発表ではない以上、確実とは言い切れませんが
au からの発売が実現すれば、飛ぶ鳥を落とす勢いのスマートフォン業界に
さらなる一石を投じる形になります


スマートフォンの普及台数が増加するということは
アプリケーションの需要も増加するということ

先日のブログでも紹介した通り、TGSでの出展数が倍増するなど
ゲーム業界全体としても、スマートフォンに対する大きな流れが出来ています。
au からの iPhone5 発売が実現する如何に関わらず
今後もこのトレンドが続くであろうことは想像に難くないでしょう。

***

ところで、このブログをご覧頂いている方の中には
ゲーム業界を目指している方もいらっしゃるのではないかと思いますが
そういった方にこそスマートフォンアプリの作成にチャレンジして欲しいと思います


スマートフォンアプリは、開発の手軽さや公開のし易さなど
PCアプリケーションに比べて、個人で開発する際の利点が多くあります。

特に「世間の目の届くところに公開する」ということは
開発に対する大きなモチベーションになり得ます
公開することにより辛口・甘口様々なレスポンスが返ってきますが
「他人に見ている」と意識するだけで、より良いものを作ろうとする気にさせてくれるはずです。

　意見が返ってくる
　　↓
　意見を元に作品をより良くする
　　↓
　さらに多くの意見が返ってくる

といった具合に、プラス方向の軌道に載れば
自分の技術も自ずと向上して行きます。


「楽しんでもらう嬉しさを感じる」ということは
クリエイターにとって非常に大きな糧となります。
私も、より多くの人に楽しさを提供できるように、日々精進して行きたいと思います

時間短縮

こんばんは。平尾です
友人のつぶやきから、ストリートファイターIII 3rd STRIKE ONLINE EDITION が配信されているのを知り、夜中にダウンロードしてブロッキングの練習をする事に…
往年の名作に浸るのも良いですね〜

＊＊＊

今月に入ってすぐぐらいに、
「スーパー主婦直伝！　我が家の時間革命」
というテレビ番組が放映されていて、何となく見ていました

内容は、どのようにすれば毎日の時間を効率良く使えるのか、
ということを紹介していました。
（詳細は上のリンクを参照してください）


例えば…

・自分が苦手だと思う家事にかかる時間を把握する
・やるべきことはスケジュールに載せて、必要になるまでは考えない
・大事な仕事は頭がしっかり回る午前中に行う
・時間の使い方を紙に書き出し、無駄な時間が何かを把握する
・毎日の作業のペースを作る
・作業はひとつずつこなす
・寝る前はしっかり片付ける

といったことが紹介されていました


なるほど、こんな感じで見直していけば、家事まわりの時間短縮ができそうです。
ただ、これらの方法は家事だけでなく、普通に仕事にも使えそうです！


今自分がやっている仕事が適切な時間で効率良く出来ているか。
改めて自分の過ごしている時間を見直したり、
やるべき作業の量に押しつぶされていないか
毎日行っている作業に無駄はないか

上記の項目に当てはめて改めて見直してみると、
無駄にしていた時間を実りある時間に変えられるかもしれません


より価値のある濃い時間で充実した毎日を過ごせるよう、
より良い成果を残せるよう、
変化を恐れず日々がんばっていきたいと思います

面倒だと思う事

関東は梅雨いり宣言の後、連日の雨ですね。
そのせいか夜になるととたんに冷え込むので、
5月頃に「そろそろ夏用の布団に変えようか」なんて話していましたが、
面倒がって変えなかったのが功を奏した感じのゆうです。

さて、この「面倒だ」という言葉、
一般的にはネガティブなイメージで受け取られるかと思います。

「ちょっとこの仕事頼むよ」
「ええ、面倒くさい」

・・・出来る、出来ないではなく
「出来るけど面倒だから断りたい」
という風に聞こえます
あまり良くない印象を持ってしまいますよね
しかし、自分がやっとプログラマらしくなって来たかな、という頃、
先輩に「プログラマにとって、面倒だと思う事はとても大切な事だ」と言われました。

当時の自分はやっと必要最低限の仕事がギリギリ出来るようになってきた程度で、
その方法であるとか、より良い手段について検討する余力がありませんでした。
例えばキャラクターのパラメータを変更したい、と言われた時・・・
　ゲーム中にポーズをかけ
→デバッグ機能からパラメータを変更し
→その値をメモしてプログラマまで教えてください。
という手順を取っていました。
企画の人がゲームのバランスを変更したくなる度、
「ちょっと敵の体力を調整して欲しいんだけど」と言われてメモを渡され、
値を変更し、実行ファイルを更新して確認してもらい、
「まだ違うんだよね」とまたメモをもらい・・・
面倒ですよね。

ある日、先輩に言われました。
「面倒だと思ったなら、それを改善する環境を作成すれば良い。
　それができるのが技術者なのだから」
確かに、環境を用意しているのはプログラマなので、
それを改善できるのもプログラマだけなのです。
上記の例で言えば、パラメータを外部化し、
デバッグ機能から直接保存、起動時にそのファイルを読み込みできるようにすれば良いのです。
「面倒と思うのであれば、そこが良くない所だと判っているのだから直せば良い」
確かに、その通りでした。
（そして、次回は最初からそういう機能を付けよう、と学びました）

面倒だ、良くないな、と思わなかったら改善できないのだから、
そう思う事はとても良い事で、
面倒なら面倒でないようにすれば良いだけの事。
ネガティブな要因があるのであれば、
それをポジティブに修正すれば良い
技術者とはかくあるべき、と教えられた一件でした。

クラフトマンシップ

こんにちは。さいやん、こと齊藤です。

先日、TVでも取り上げられていて気になっていた、ここに行ってきました



「ものづくり」をテーマに、ショップ内に工房があるかたちのお店が多く、
職人さんの制作作業を間近で見られるような、作り手とお客さんの距離が
ぐっと縮まるような店づくりが意識されています。

※写真は店外から撮影しました。
お店に入ると、もっと間近で見られます！


JRの高架下に、そんなユニークなお店が軒を連ねる形で一つのテーマパーク
のようになっているのが2k540。


公式サイトはこちら。
http://www.jrtk.jp/2k540/

2k540限定の商品などもあり、ウィンドウショッピングだけでも十分楽しめます

陳列された商品から得られる情報だけでなく、実際に作り手の職人さんとお話し
させて頂くことで得られる裏情報やこだわりなどを聞くと、ぐっとその商品の
魅力が増すように感じました

ゲーム制作においてはなかなか発売前にその制作過程をユーザーの皆様に
お見せする機会も少なく、一部の宣伝担当者を除くと現場の作り手との対話で
その魅力を伝えるということはほとんどないのですが、イベントというかたちで
少しでも身近に感じられるような取り組みはゲーム業界でもたくさん行われています。
中でも東京ゲームショウなどは有名ですね

また、発売前に一般ユーザーの方に触れて頂く機会は少ないと書きましたが、
質の向上のため、モニタリングテストというかたちで一般の方に参加頂いて
テストプレイをして頂き、難易度や操作性のチューニングをするということは
行われています
特に、子供向けタイトル等に関しては、制作者である大人の思惑が対象となる
子供の感性と大きくズレていないかを確認するために実施されることが
多いように思います。

「ものづくり」において、その商品の特性に合わせた様々な取り組みで
お客様により価値のある商品をお届けするための努力が行われていることを
再確認することができました

ゲーム制作のみならず、さまざまなクリエイティビティに触れることは、
ゲーム制作自体をまた違った角度から見直すことにつながりますので、
常に色々なことにアンテナを張って、自分の目で見て、触れて、
作り手としての幅を広げていきたいと思います

飛躍的快感

こんばんは。イノウエです！

突然ですが、先日、電動自転車を購入しました
子供を乗せて坂を楽に移動する為に買ったのですが、
想像以上のアシストパワーで、劇的な進化を体験しました

「おぉ・・おぉぉぉ！！すごい！！！楽ちんや！！」と叫びながら
嬉しくてニヤケまくりの顔で坂を上っている姿は、
さぞおかしい人だった事でしょう…
しかしながら、この快感は止めることが出来ませんでした
それほどまでに、飛躍的な快感だったのです


さて、上記のような快感は、ゲームでもよくありますよね。

・キャラクターのレベルが上がった時
・装備を新しく購入した時
・敵の弱点をついた時
・敵の動きを把握し、攻撃を見切った時

などなど。
今まで苦労していたのに、急に楽になる瞬間があります。
何度も倒されたことがある敵を一撃で倒せたりすると、
「どうだ、まいったか！がはははは！！」となりますよね

この快感をうまく得られるようにするため、
開発者は地道に、様々な技を使います。

レベルアップのタイミングを苦戦した後になるよう合わせたり、
パラメータの上がり方に波を作ってみたり、
敵が強くなって絶望しかけた時にポロッといいアイテムを出してみたり。
わかりやすいところから、気付かないようなところまで、
しっかりメリハリをつけて快感が得られるようにします。
特に、一瞬で大きな変化をもたらす箇所をどこか一部分に入れると、
より大きな高揚、快感につながります

文章にすると単純ですが、世界トップレベルの面白さを出すためには、まだまだ研究せねばです。
ということで、研究に戻ります


（余談ですが、カラオケの点数も、抑揚がしっかりある方が高得点になるそうです。
　歌もゲームも、変化が人の心を刺激するという事でしょうか。
　興味深いですね）

ソフトウェアメトリック

お久しぶりですシラッチです。
先日学生さんの新卒面接をさせて頂く機会がありました。
いろいろ新発見があり勉強になったので、今回は
そのひとつを紹介したいと思います。

「プログラムをする上で気をつけている事は何ですか？」
という質問に
「自分以外の人が読んだ時に分かりやすいソースを書くように気をつけています」
という回答を頂くことが多かったのですが、分かりやすいソースの判断基準は
主観的で評価が難しいなぁと感じました。
（※分かりやすくなるように心がけるのは大事で必要な事だと思います。）

確かにコメントをしっかりつけたり、コーディング規約を設けて、それに沿って
コードを記述することで分かりやすくなると思います。
ですが、さらにその精度を上げられないものかと思って調べてみると、
何と私が生まれる以前にプログラムの複雑度を測る方法が開発されていました。

ソフトウェアを分析/計測する方法をソフトウェア測定法（ソフトウェアメトリック）と
いうのだそうですが、その中でも、プログラムの複雑度を測るのに使われる
循環的複雑度（Cyclomatic complexity）というものがあるそうです。

「複雑なプログラム＝潜在的にバグが入りやすいプログラム」という観点から
プログラムの制御構造の複雑さを測定し、バグの発生率を下げることを目的としたもので
一般的には、以下のような判断値となるようです（※計測ツールにより多少異なるようです）。

10以下 ― 保守し易く良好
11〜20 ― 場合によりロジックを再検討する必要がある
21〜40 ― 理解に時間がかかる
41〜50 ― 開発者のみ改修可能
51以上 ― 理解不可能

簡単な概念は、線形的に独立したプログラムのソースコードの経路の数を数えて
数が多い程、複雑度が高くなるというもので、

ソースコードの経路数が多い＝プログラムの実行経路の数が多い＝テストケースの量が増える

ということになるようです。
また複雑度が高いと、ソースコードの意味を理解するために多くの経路を追わなければならず
読解が困難になるともいえますね。

試しに私の就職活動で作成したプログラムをフリーの計測ツールにかけてみると…
おおむね10ポイントを下回っていてホッとしたのもつかの間
いくつか 15〜27 ポイントのソースコードが…

循環的複雑度だけを基準に優れたソースコードか否か、という判断はできませんが
自分の書いたプログラムが複雑になっていないか、客観的な指標とするには
良いかもしれません。

気が向いた時にだけ測るのではなく、以前このブログで紹介した Hudson
（現在はJenkinsと名前が変わっているようです）と組み合わせて、日々計測を
行うと効果的かもしれませんね。

ではまた

物事の本質を考える

こんにちは。さいやん、こと齊藤です。

先日、ハラが「見えるようにする」ことの有用性についてblogで取り上げていましたが、
マネージメントを行う観点からは、このことは特に重要[]だと感じています。

これから書く内容は、ちょっとゲーム制作の現場寄りのお話になりますが、
それ以外のことにもあてはめて考えられる内容でもあると思います。


ゲーム制作の現場で必要となるマネージメントの一つとして、スケジュール管理
がありますが、このスケジュールを「見える化」するのとしないのとでは
大きな違いがあります。

私がスケジュール管理するときに使用しているのがこんな感じのフォーマットです。



このようなスケジュール表を作ることで、様々なメリットが生まれます。
まず、作業進行がどのように進むのかが明確になります。

ゲーム制作はチームで行いますので、どの時期に誰が何をしているかという
一覧性が高まることで、担当者同士の作業の関連性（例えば、Aさんのツール作成の
あとにBさんがそれを使用して作業を行う）等が分かりやすくなり、
緊急の割り込み等で作業の順序を入れ替える必要があるときにも、
周りへの影響も把握しやすくなります。

また、ひとつひとつの作業に対する期間も視覚的に見えるようになることで、
作業順序の入れ替えや割り込み対応をスケジュールに入れる際にも、
どの作業と入れ替えるか、作業の重要度や必要な期間を見ながら検討ができることで、
無理なく効果的なリスケジュールが可能です。

加えて、その作業が全体のスケジュールの中で割合が大きすぎたり小さすぎたりしないか、
プロジェクトの意味合いを考えたときにその作業期間に見合った効果が期待できる
作業なのか？等の費用対効果を検討するきっかけにもなります。

作業を行う担当者としても、締め切り意識の明確化や、自分の作業による周囲への
関連性が分かることでその重要さが意識できるようになります。
全員で認識のズレ無く制作進行のイメージが持てる
ことも大きなメリットです。

図のようなスケジュール表を作ることは結構な手間ではあるのですが、
上記のようなメリットを考えると、手間をはるかに上回ります

ゲーム制作では、作っている作品をより良くするために、日々制作内容の見直しを
行っていますので、必然的にスケジュール調整が行われることも多いです。
その度に、こういった見えるかたちで調整できることはとても重要になります。

しかし、スケジュール管理が大切だとはいっても、スケジュールを管理することが
目的ではありません
本当の目的はクオリティが高くユーザーの皆さんの
満足度が高い作品を作ることです。
そのために、限られた時間をどう使うか。その効率化や、チーム全体で同じビジョンを
持つことに有用だからこそ導入しているのです。
管理者は、常にそのことを念頭に、目的と手段の履き違えをしないように
運用することが大切です。

常に物事の本質を考えて、それを達成するために何ができるのか、
について意識しながら日々向かい合うことで、
密度の濃い時間の使い方ができるようになるのではないでしょうか。