■ "アート・オブ・プロジェクトマネジメント" 読書メモ

だいぶ昔に買って積んでたのを見つけてちょこちょこ読んでた。具体的な手法よりもマネジメントに対する思想を学ぶのに適した本だと思う。ここで書かれているようなことは長い経験をとおして学ぶ類のもので、肌身で感じるのは経験に譲るほかないにしても、駆け出しマネージャの人はある種の先達の言葉として見ておくといいと思う。ただし経験なくして深く理解したと思い込むのも間違いだし、結局のところ先達とはいえ他人の意見が自分と自分を取り巻く環境にすべて適用できると考えるのもあまりいいアイデアではないと思う（特に著者の人はなかなかひねくれた考え方を持っていると感じたのでこの本ではそれが顕著だと思う。ひねくれていない人はひねくれていない人の言葉を鵜呑みにしても問題ないけど、ひねくれた人はひねくれた人の言葉を鵜呑みにはできない。性格的にもそうだし、そもそもひねくれかたが人によって全然違う）。

そんなわけで心に残った部分を抜粋。かなり一面的な抜粋をしているので、抜粋をみて違和感を覚えたら原文を読んでみるのがいいと思う:

• スケジュールの3つの目的
  • 物事がいつ完了するのかを表す
  • プロジェクトに貢献するすべてのメンバーに対して、チーム全体における個人の成果物の位置づけを理解させ、各メンバーの協調を促進させる
  • 進捗を管理し、作業を管理可能な塊に分割するツールをチームに与える
• スケジュールが遅延するということは、誰も把握していないコストが隠されていた、あるいは無視されていたということ
• どのようなプロジェクトでも、合格点はリーダーが定義する
• スケジュールを機能させるためにやるべきこと
  • マイルストーンの長さはプロジェクトの不安定さに見合ったものとする
  • ビジョンに対しては楽観的に、スケジュールに対しては懐疑的に
  • 設計に力を注ぐ
  • 追加/削除を議論するためのチェックポイントを計画しておく
  • 計画の哲学をチームに伝えておく
  • 問題領域におけるチームの経験を見極める
  • 共同作業に対するチームの自信と経験を測る
  • リスクへの取り組みは早めに行う
• 明確な考えを語ろうとした場合、必ずしも多くのページが必要になるわけではない
  • 米国憲法は7,000ワード、モーセの十戒は300ワード、マグナカルタは5,000ワード
• 要求記述時によくある間違いを解消する
  • 要求の交渉と繰り返しのための計画を提供する
  • 誤った前提を見つけ出す
  • 失われた情報を見つけ出す
  • 各要求の相対的な優先順位を定義する
  • 曖昧になっている言葉を洗練/除去する
• 優れた質問なしに優れた答えは得られない
• 焦点あわせの質問 - 「解決しようとしているのはどのような問題なのか？」
  • これが効果を発揮するためには、この質問が邪魔なマネージャからの心ないツッコミに聞こえない程度にあなたが信頼されている必要がある
• 「悪いアイデアを目にするまで、私にはどれが優れたアイデアかまったくわからないんだ」
• プロトタイピングはトップダウンで、ユーザが目にする部分を、彼らが目にする順番で作っていく
• "命令ではなく対話を行った場合、どんなやり方を使った場合よりも迅速に必要なものを手に入れることができました。さらに私の出したアイデアに対して彼らが優れた改善策を示唆することも増えました。私は、演説・命令よりも対話のほうが優れているということを学んだのです"
• 下層から行うプロジェクトのマネジメント
  • あなたよりも強い権力を持った人々が、納得できないプロセスをチームに強要することもあります。こういった状況に対処する方法は3つあります:
    • そのプロセスからチームを守る
    • そのプロセスに対して反旗を翻す
    • そのプロセスを無視する
• 人を不快にさせない電子メール
  • 簡潔に、シンプルに、ダイレクトに
  • やることと締切りを明記する
  • 優先順位を明確にする
  • 受信者がメールを読むと仮定しない
  • 実況放送を避ける
  • ご参考メールは別建てで
  • 気軽に電話する
• 打ち合わせを不快なものにしない方法
  • 会議室で過ごす時間の重みが、コンピュータの前で過ごす時間の重みに勝ることはほとんどない
  • ファシリテーションの技芸
    • 司会者の席に座る
    • 耳を傾け、言い換えを行う
    • 話の方向づけを行う
    • 対話を終了させる
    • 記録を残す
  • 議論の3形態
    • 対話性の高い議論
    • 報告あるいは（対話性が）中程度の議論
    • 状況のレビューやプロジェクトのレビュー
• 「誰かが暗闇でロウソクをひっくり返したとき、あなたはその人を非難することもできれば、ロウソクを灯すこともできる。しかし問題のあることを知っていたにも関わらず何の対処もしなかったのであれば、非はあなたにあるのみだ」（ポール・ホーケン）
• 問題の発生を知る方法
  • 現実と現行の計画の間に大きな乖離がある
  • 乖離が何か、その原因は何か、それを解決するのは誰の仕事か、そういったものが実際に存在するのかといったことについての混乱がある
  • 乖離の解消に向けたリソースの適用方法が不明確である
• 説得と議論を使い分ける
• 厳しい状況の最中に、マッサージセラピストを連れて各オフィスをまわり、メンバーに10分間マッサージを行った凄腕のマネージャもいましたこれは、そのプロジェクトに参加していない人たちの間で、何日も話題に登るほど素晴らしい効果を生み出したのです
• 自然のプレッシャーと人工のプレッシャー、ポジティブなプレッシャーとネガティブなプレッシャー
• 「信頼とはすべての重要な人間関係の核である。信頼なしには、与えることも、一体感を得ることも、リスクを犯すこともできない」（テリー・ミズラヒ）
• 優れたリーダーであるほど、伝家の宝刀を抜こうとしません。剣を抜いたが最後、誰もあなたの言うことを聞かなくなり、剣の言うことに耳を傾けるようになるのです
• 組織としての観点から見た場合、専制君主的な振る舞いは深く考えようとする人を遠ざけてしまいます。それと同時に、言われたことだけやればいいという風潮を作り上げます。専制君主が作り出す環境は、唯々諾々と従う人にしか耐えられないものであり、また逆に唯々諾々と従うしか能のない人は専制君主の下でしか働けない
• 優先順位づけによってものごとが成し遂げられる
• リーダーやマネージャが優先順位を無視して「イエス」と言い続けた場合、他のメンバーもそれを真似するようになる
• 「ノー」の言い方
  • 「ノー、それは我々の優先順位に合致していません」
  • 「ノー、時間ができた場合にのみ行います」
  • 「ノー、あなたが＜不可能なことをここに入れてきてください＞を行ってください」
    • 不可能なことっていうよりここでノーをいう原因の解決ができればイエスと言える、ということじゃないかなあ
  • 「ノー、次のリリースで考えます」
  • 「ノー、絶対ダメです」
• 飛行機の前方を飛行する
• 「計画に従うことで勝利できるような戦いはないが、計画なくして勝利できるような戦いもない」（アイゼンハワー）
• 「私の意見では戦闘というものは計画どおりに行えるものではない。計画は変化に備えた共通の基盤でしかないのだ。重要なことは、全員が計画を知っておくことで、容易に変更が可能になるということなのだ。近代戦は非常に流動的であり、意思決定は迅速に行わなければならない。そしてそのほとんどは計画に従ったものとはならないのだ。しかし全員が少なくとも、自分はどこからきて、どこに向かっていくかということを知っている（必要がある？）のだ」（イスラエル防衛軍司令官 ダン・ラネル陸将補）
• ウォーチームを組織する（終盤の戦略
• 力の源: 報酬・威圧・知識・人脈・影響力

■ 強化版irbのpryがすごい

Rubyを書いてるとき、何かと検証のためにirbを多様する。readlineをちゃんと入れておけばそこそこ使いやすいのだけど、今日pryというirbの強化版みたいなソフトウェアが存在することを知った。

調べてみたらめっちゃ高機能なので、常用するかどうかは未定としてざっと使ってみた特徴を紹介します、

インストールが簡単

$ gem install pry --no-ri --no-rdoc
$ pry # 起動

これだけ。

irbの上位互換で馴染める

たぶん詳細な機能はいろいろ違うと思うけど、Rubyなシェルとして使うぶんには問題なさそう

ハイライトがきれい

いちいち色付けされる:

補完が効いてうれしい

上のコード書きながら気づいたんだけど、定義されてるクラス名やメソッド名で補完が効くみたい（！）

コンテキストを変えられてすごい

デフォルトではpryクラスの中にいることになってますが、自分で定義したクラスの中にcdしたり、cdしたクラスの中ではそのクラスの状態をlsで参照したり変更できます:

もっと深いことができそうだけど、とりあえず未調査。

シェルが叩けてたのしい

irb使ってるとファイルを開く前にlsしたかったりしてtmuxとか使ってないと詰む（使ってても実はカレントディレクトリが違ったりして面倒いことになる）んだけど、pryではコマンドの前に . をつけるとそのコマンドをシェルに流してくれる:

まだまだ全然機能があるのがカッコいい

これだけでも超使い勝手よさそうなのに、公式ページをみるとまだまだ楽しげな（gist-extensionとか）が満載なので、これからちょくちょく使って見ようと思います。

Pry 公式ページ

■ Grit::Repo.initが失敗するとき

GritはRubyからGitリポジトリを操作するためのライブラリ。最近これを使ってサーバサイドで変更を記録する仕組みを作る必要があった。

Grit自体の作りかたもちゃんとした文書になっていない部分が多いので、近いうちにGitのコマンドとの対応表を作りたいと思う。

それはそれとしてコケた話。結論からいうとgit 1.6.4.4でコケる場合がある。

GritからGitリポジトリを作成する（git init相当のことをする）には以下のような手順を踏む:

require 'grit'
include Grit
repo = Grit::Repo.init('path/to/repo') # This accepts either absolute or relative path

ところがこのGrit::Repo#initがInvalidGitRepositoryErrorを起こす。

このメソッドは何をしているかというと、当該ディレクトリにリポジトリがなければgit init相当のことをして、そのあとでGrit::Repo#new（存在するリポジトリの読み込み）してその結果を返す。

Gritの仕組みを大雑把に説明すると、Ruby側でオブジェクト指向的にリポジトリを扱うための準備が必要ならそれをして、そのあとでmethod_missingを利用して直接gitコマンドにサブコマンドを渡す、みたいなことをしている。

なのでここでRepo#initが最終的にどんなコマンドを発行するか調べてみたところ、次のようなものだった:

$ git init .

で、これがうまくいく環境といかない環境がある。うまくいく環境ではリポジトリが作成されて、うまくいかない場合には次のようにUsageが表示される:

$ git init .
usage: git init [-q | --quiet] [--bare] [--template=<template-directory>] [--shared[=<permissions>]]

で調べてみると、git-initのmanpageにバージョンによって違いがあった。まずは1.6.4.4のものを抜粋してみる。

NAME
       git-init - Create an empty git repository or reinitialize an existing one

SYNOPSIS
       git init [-q | --quiet] [--bare] [--template=<template_directory>] [--shared[=<permissions>]]

ほんで1.7.4のもの:

NAME

git-init - Create an empty git repository or reinitialize an existing one

SYNOPSIS

git init [-q | --quiet] [--bare] [--template=<template_directory>] [--shared[=<permissions>]] [directory]

というわけで、純粋にGit 1.6.4.4ではgit initにディレクトリ名を渡せない、というのが真相の様子。

根本的解決にはGitの更新、それができない場合にはGrit::Repo.init('')で呼び出せばディレクトリ名が後ろにつかないので実行できる。ただしこの場合カレントディレクトリに対してしかリポジトリを作れないので、chdirしておく必要がある。

■ ブログが続かない

ブログを書く周りと友人のうち何人かと「ブログが続かない」みたいな話をすることがあって、僕もそのひとりなのでなんで続かないのかを考えてみると、たぶん普段頭の去来する記録するべきものごとっていうのは大半が外に出せない（お仕事の都合とか人間関係とかで）ものなんじゃないかなと思った。

なのでBasic認証かけたhikiで書くようにしたらわりと続いてます。ただ誰かに見られる文章であるってことは結構緊張感を生んでたようで、悲惨な文章が残されてるケースも結構あったりして。

それでも書かないよりマシなのかな。

■ 聖人になった

嘘です。相変わらず煩悩にさいなまれる俗人のままですが、その代わりに成人になることはできました。2010年12月4日を以ってのことです。

思ってたよりちょっとだけうれしいです。

実は年々誕生日を祝うみたいな感覚を失いつつあって、今年なんかは特にひどくて京都行きの夜行バスで見ず知らずのおっさんの隣で誕生日を迎えるという随分と残念な感じでした。でもメールやFacebookや電話なんかでお祝いしてくれた人もいて、なんかこんなどうしようもないやつのためにわざわざ申し訳ないなあとか思っちゃいました。来年からは俺も誰かの誕生日をお祝いしたいです。

なんかこれ小学生の作文みたいですね。自分の気持ちを素直に文章にするっていうのは普段あんまやらないので、文体まで変わって誰だお前って感じです。

ちなみに今まで誕生時間を2:00だと思ってたんですが、母親によれば13:50頃だということで、成人の瞬間自体は知らないおっさんの隣で迎えたわけじゃなさそうです。

12月4日の14時頃といえば、ちょうど@waturaといっしょに発表をしてたとこだと思うので、わりに感慨深いものがあるなあなどと思います。

それはそれとして、これを読んでいるみなさん、あるいは読んでないみなさん、なんかこんなどーでもいい文章を最後まで読んでくださってありがとうございます。

これからもよろしくって感じです。

■ 立命館大学学生ベンチャーコンテストにて中信イノベーション賞を獲得

Web制作からスタンドアロンアプリの開発まで幅広く活動しているHas-keyですが、この度立命館大学学生ベンチャーコンテストにて決勝進出し、中信イノベーション賞を獲得しました。

結果ももちろんうれしいながら、他の参加者や同コンテストの運営団体であるF-DooRsの面々がおもしろい人ばかりで、今後なにかいっしょにできることがあればなーと思います。

この場を借りて、同コンテストに関してHas-keyを支えてくれたみなさん、それから会場や懇親会で我々に興味を持ってくれたみなさん、本当にありがとうございました！ これからも是非よろしくお願いします :)

ちなみに中信っていうのは京都中央信用金庫のことで、京都では有名だそうです。

■ ゲーム制作もくもく会（ハッカソンみたいなもの）

12月23日と12月26日の2日で、筑波大学のどこかに集まってもくもくゲームをつくってUstで垂れ流す会をやろうと思っています。垂れ流して誰が得すんだとか集まる意味あんのかとか深いことは考えずに、普段から「書きたいなー」と思ってるけどなかなか機会がなくて集中して取り組めないテーマに取り組む機会になればなーと考えています。

今のところ参加してくれそうなのはほぼ内輪だけっぽいですが、もちろん僕および他の参加者と面識のない方でも全然歓迎です。Twitterで@tnzkとかに連絡していただければ詳細をお伝えしますです。

あと「ゲームつくるのに興味はあるけど、具体的にどうしたらいいのかは...」って人がいたら是非この機会に相談してみてください！ 僕は自分が何か書く以上に誰かが何かを書くのを見るのが好きなので、サポートしたいと思います。もちろん僕のほかにもっと優秀な人が参加しているはずなので、彼らに相談しても良いと思います :)

とりあえずここでは要項だけ:

• ゲーム制作もくもく会（ハッカソンみたいなもの）
• 内容: 筑波大学のどこかに集まって自分の書きたいゲームを書く
• 日時: 12月23日, 12月26日 各9:00-21:00
  • 途中の出入りとかはもちろん自由です
  • 20時くらいに交流のきっかけも兼ねて「どんなの書いたか/書いてるか」を発表する機会をつくりたいかなーと思ってます。もちろん自由参加です
• 場所: 未定

■ WDKのインストールからミニフィルタのサンプル"passThrough"をビルドするまで

たまにブログを書かないと何かうまく頭が働かなくなるのは、たとえば「次のエントリに書こう」として積極的に記憶に残してる情報が思考の駆動を妨げているのかもしれない。ということで断片的な情報をちょくちょく吐いてみることにしよう。

WDKのインストール

WDKはここから入手できる: "Windows Driver Kit (WDK) ダウンロード ファイルの入手場所と手順について"。特に依存ファイルとかはなくて、インストーラに従えば問題なくインストールできた（VirtualBox上のWindows Vista）。

インストールが済むと、プログラム → Windows Driver Kit → WDK 6001.18002 → Build Environment にWDKのパスなどをオプションで渡すように設定しされたコマンドプロンプトへのショートカットがあるので、ビルドにはこれを使う。

ちなみに普通にC:\WinDDK\6001.18002\bin\x86にパスだけとおしてビルドしようとしても、諸々の設定が足りないっぽくて"environment variable NTMAKEENV or OTOOLS must be defined"と言われてうまくいかないので、たぶん上記のものを使ったほうが手軽。

ミニフィルタのサンプル"passThrough.sys"のビルドとインストール

ミニフィルタのサンプルは標準では C:\WinDDK\6001.18002\src\filesys\miniFilter にある。収録されているサンプルは次のとおり:

C:\WinDDK\6001.18002\src\filesys\miniFilter>dir /b
cancelSafe
cdo
ctx
dirs
MetadataManager
minispy
nullFilter
passThrough
scanners
wapBuffers

passThroughはその名のとおり、何もせずにオペレーションをそのまま通過させるミニフィルタで、動作確認のためにログを吐く以外には特に何の動作もしない。passThroughフォルダ以下にあるファイルで、このミニフィルタを読み解いてインストールするために特に重要なファイルは次の3つ:

• passThrough.c - このミニフィルタ本体のコード
• passThrough.inf - インストールの設定ファイル
• objfre_wlh_x86\i386\passThrough.sys - ビルド後に生成されるドライバの本体

ビルドは簡単で、passThroughフォルダで次のコマンドを実行する:

C:\WinDDK\6001.18002\src\filesys\miniFilter\passThrough>build -ceZ
BUILD: Compile and Link for x86
BUILD: Start time: Wed Dec 01 19:13:51 2010
BUILD: Examining c:\winddk\6001.18002\src\filesys\minifilter\passthrough directory for files to compile.
BUILD: Compiling and Linking c:\winddk\6001.18002\src\filesys\minifilter\passthrough directory
Compiling resources - passthrough.rc
Compiling - passthrough.c
Linking Executable - objfre_wlh_x86\i386\passthrough.sys
BUILD: Finish time: Wed Dec 01 19:13:54 2010
BUILD: Done

    4 files compiled
    1 executable built

objfreフォルダ以下にpassThrough.sysが生成されていればビルド成功。

インストールの手順は次のとおり:

1. passThrough.sysとpassThrough.infを同じフォルダに配置する
2. passThrough.infを右クリックし「インストール」をクリック

インストール後、ミニフィルタを有効化する（ロードする）必要がある。これはビルドと違って普通のコマンドプロンプトで良いけど、管理者権限が必要:

C:\Users\tnzk\Desktop\hoge>fltmc load passThrough

C:\Users\tnzk\Desktop\hoge>fltmc

フィルタ名                      インスタンス数 階層          フレーム
------------------------------  -------------  ------------  -----
PassThrough                            14       370030         0
luafv                                   1       135000         0
FileInfo                               14        45000         0

fltmcでロードされているミニフィルタの一覧が表示されるので、ここにPassThroughの表示があれば成功。

ちなみに無効化するときは fltmc unload passThrough でいけます。

動作の確認

DebugViewを使いました。管理者権限で起動して"Capture Kernel"を有効化しないとダメかも。

おまけ

ビルドするたびに右クリックするの面倒くさいのでバッチファイルにした（passThrough.infの置いてあるフォルダで実行してね）:

参考

• "Filter Driver Development Guide"

■ アプリケーションがつかうレジストリを調べる（DLLインジェクション）

Windowsのアプリケーションの中には設定なんかの情報をレジストリに登録するものがある。その傍らでレジストリは使用しないアプリもある。だいたい使わないやつは「このソフトはレジストリを使いません」みたいなことを書いてあるけど、それが常に正しいとは限らないので、あるアプリケーションがレジストリを使うかどうか、使う場合はどんなキーをつくるのか調べる。

調べ方

いくつか手段が考えつく:

1. レジストリ監視ソフトみたいなやつがあるのでそれを起動しながら当該アプリを動かす。動作中に更新されたレジストリはそのアプリによって使用されるものである見込みがある。もちろん偶然同じタイミングでレジストリを更新した別のアプリによるものかもしれない
2. 実行ファイルのバイナリ中にRegSetValueとかその辺の文字列が含まれているかどうか調べる。ただしモジュールをロードしているだけで使ってない場合がある
3. DLLインジェクションをかけ、RegSetValueEx(A|W)が呼び出されたらファイルにログを残して記録する

今回は(3)を使った。

コード

こんなん:

RegSetValueExW用もほぼ同じ（Unicode文字列のバイト数チェックに注意）。

ビルドしてadvapi33.dllって名前にしとく

実験

まずはこいつをターゲットに:

ビルドしてモジュールをロードしてるADVAPI32.dllの記述をADVAPI33.dllに書き換える

で実行ファイルと同じディレクトリにadvapi33.dllを置いて実行する。と、registrylog.txtが保存される。

HOGEHOGE: hogehogevv 

実践

大学の計算機になぜか入ってたeoっていうアーカイバをターゲットにする。

これも同じく実行ファイルからADVAPI32.dllを探して、ADVAPI33.dllにする:

eoでも同じく

で、実行する。実験用のアプリと違って勝手に終了する類のものではないので、適当にいろいろいじったら自分で終了する（レジストリアクセスがあった際にダイアログか何か表示するみたいな感じにしようかと思ったけど、うっとうしそうなのでやめた）。

するとregistrylog.txtが保存されてて、こんな感じになる。

感想

eoが懐かしかった。

■ 第2回40時間ゲームプログラミングコンテスト 第2報

第2報っていうのかどうかよくわかんないですが...

このブログ、Twitter、つくらぐのML、あるいはリアルと各所でいろんな意見をくださったみなさん、ありがとうございました！いただいた意見を（とりあえず匿名で）リストアップして、それを踏まえて新しい案を書きました。また意見をくださるかたは是非お願いします！

日程について

「クリスマスはさすがにないわ！」というのをほぼ全方面からいただいたので（たしかに...）、日程を改めたいと思います:

2011月1月14日 18:00 - 16日 18:00

新年早々ということでどうでしょうか！ 8日-10日の3連休も考えたんですが、10日が成人の日ということで成人式に出席する方もいるんじゃないかなあということでこっちにしました。

審査方法について

審査方法について、こんな意見をいただきました:

• 「講義室にプレイ環境を準備して、一般の来場者による審査」で良いと思う。一般審査員の参加は宣伝次第
• 「講義室にプレイ環境を準備して、一般の来場者による審査」と「Webで作品をダウンロードできるようにして、Web経由で一般の方による審査」の併用で良いと思う
• 会場点とWeb点に係数をつけて、会場点を重視するようにする

個人的にも「講義室にプレイ環境を準備して、一般の来場者による審査」がいいかなーと思ってます。

このコンテストには「ゲームの規模にもいろいろあって、コード書いたことがなくてもやってみれば作れたりする」みたいなことを啓蒙するって目的もあるので、情報以外の人にも見てほしい＝審査者層っていう気持ちはあります。

同じ理由でWebからの審査も受け付けたいですが、意見でもいただいたように環境がうまく整わないケースもある（加えてそれに最適化することが有利であるようにはしたくない）ので、その解決策として重みをつける（会場点を重視する）というのがベストかなと考えています。

というわけで審査方式は:

• 講義室にプレイ環境を準備して、一般の来場者による審査: 開発者のPCとかその辺に動作環境をつくるので確実に動く。こっちがメイン
• WebでTwitterアカウントで個人識別して、作品のアーカイブを配布して審査: こっちは地理的につくばにくるのは難しい人向け。でも動作環境の整えやすさが被審査数に影響するので（それはあんまりこのコンテストでは重視しないので）、こっちの点数は0.7くらいの係数をかけて加算する

って感じでいこうと思います。

素材について

素材についていただいた意見はこんな感じ:

• 「事前準備の制限をせず、フリーな素材集を作るに留める」をベースにするとして、たとえば、準備する素材は事前に大体告知されていて、参加者が「俺が作ろうとしている作品にはこういうのが足りない」というのを各自事前に作るor探すができるようにしておく
• 「みんな同じ素材セットを使う」がおもしろそう。同じ素材でも作り方(使い方)でここまで幅のある作品ができるのかぁっていうのを体験してみたい
• 運営側で準備するものくらいは早めに告知

ほかにもたくさんの意見をいただきました（ありがとうございます！）。

これについては、

• 運営がフリー素材集みたいなのをつくっておく
• 素材集の内容は早めに公開して、足りないものを各自準備する

という方向性でいきたいと思います。

その他

ブログでいただいた意見から抜粋ですが（@notozekiさんありがとう！）:

ゲーム「プログラミング」コンテストと銘打っているならば(3)にして純粋にプログラミングの腕を競うというのもなきにしもあらずなんですが、作れる作品の幅が狭まる可能性と、微妙な「初心者お断り」な空気が漂うのでう〜んという感じです

僕も初心者が参加しづらいところがあるよなーとは思っていて（実際前回も）、なんとかしたいなーと考えています。プログラミングの腕を競おうみたいなことは意図してないんですが、事実上そういう空気になっていることを複数の方から意見としていただいているので、対策すべきだろうなーと思ってます。

初心者の人に参加してもらうためにできることはこんな感じのことが考えられて:

1. 簡単なSTGやRPG、パズルゲームなどのサンプルを公開しておいて、それをベースに拡張版などを応募することを認める
2. 入門者向けのドキュメントをつくって配布する
3. チーム参加を認めることを体系化して、経験者と組んで参加してもらう

(3)あたりはコストが低くて運営としては実現しやすいかなーと思ってます。(2)は僕なんかが書かなくてもWeb上にたくさんのリソースがあるので、それへのリンク集みたいなのを作るほうがベターなのかな。

(1)は実際のところ「これならできるかも」って初心者の人が思ってくれるかどうかが微妙なところだなーと思います。「(1)なら参加したいかも！」って人いますか？

もっとその他:

• 会場は講義室併用ということで決定でよさそうです
• それにあたって、宿舎のお風呂についてのガイド（道案内や料金など）を書く予定です
• 新年なんでお餅とかたべたいですねー

というわけで

みなさんまた意見いただけるとうれしいです！

11月の暮れには正式な決定案といっしょにWebサイトを公開、参加登録とかはじめたいですねー。

■ 第2回40時間ゲームプログラミングコンテスト草案

今年9月に開催された40時間ゲームプログラミングコンテストの第2回を、12月に開催する予定です！

前回も多様なバックグラウンドを持つ人が集まり、個性的な作品を見ることができて個人的にはとても満足でした。第2回も是非多くの方に参加していただければと思います。

ルールは概ね第1回と同じものになる予定です:

• 12/24(Fri) 18:00 - 12/26(Sun) 12:00 のだいたい40時間でゲームをつくる
• 作品を自由ソフトウェアライセンス（GPL, BSD, MITなど）で公開
• 12時から審査員による審査を行い、最優秀賞・優秀賞を決定

変更点

いくつか第1回と異なる点、あるいはどう変更するか迷っている点があります。未決定の部分もあるので、それについては是非みなさんからの意見をいただけるとうれしいと思います。

• 会場（たぶん確定）
• 審査方法（悩み中）
• 素材の準備I（悩み中）

会場

前回はルール説明・審査結果発表以外の開発場所はすべて自由ということにして、特につくらぐ側では準備しませんでした。

今回は講義室を確保して、21時までの間は講義室を開発に利用できる形にしたいと思っています（もちろん他の場所で開発いただいても構いません）。

審査方法

審査は、以下の3つのうちのどれかにしようと思っています。

1. 前回と同じく、COINS（筑波大学情報科学類）の学生による審査
2. 講義室にプレイ環境を準備して、一般の来場者による審査
3. Webで作品をダウンロードできるようにして、Web経由で一般の方による審査

それぞれ利点/欠点は:

1. 動作環境を確実に準備できる : 絶対数が少ない
2. 学類生じゃなくても確実に審査できる : 大学へのアクセスの関係からあんまり人がこない気がする
3. 多くの人に評価してもらえる : 提供プラットフォームによってすべての作品が公平に審査されない恐れがある

といったところで、とりあえず今は悩んでいるところです。

投票形式自体は前回の択一式ではなく、レーダーチャートみたいな形式で定数を振り分ける感じにしようと思ってます。

素材の準備

前回は料理の鉄人方式ということで、あらかじめ準備した素材のセットをランダムに割り振るという形式にしました。これは、事前準備に当てられる時間の多寡が評価に大きな影響を及ぼしてしまうこと、また事前準備を認めない場合表現の幅が狭まってしまうことを考えての苦肉の策でした。

予想外な素材からインスピレーションを受けるという点で良いこともあり、傍らでやはり素材の引きによって表現の幅が規程されてしまうという問題もありました。

第2回では次の3つのうちどれかにしようと考えています:

1. 鉄人方式を継続
2. 事前準備の制限をせず、フリーな素材集を作るに留める
3. みんな同じ素材セットを使う

個人的には(2)がいいかなと考えています。事前準備には「自分で絵を描く」と「良い素材を探す」という2種類の時間の使い方があって、素材集をスタッフがつくっておくことで事前準備の有無による不公平感を低減できるかなーとの考えです（ちなみに第1回での議論をこ存じない方のために: ここで僕は「事前準備は悪」ということを主張したいわけではなくて、事前準備を認めることによって不公平が生じるということが第1回の時点で多くの参加者の共通見解だったので、なるべくこの不公平感をなくそうとしています）。

というわけでみなさん意見くださいです！

■ プロトタイピングツールいろいろ試してみた

今までプロトタイピングはInkscapeでやってたんだけど、ちょっと良い加減効率わるいなと思ったので巷でたくさん公開されているプロトタイピングツールなるものを試してみることにした。

具体的にはPencil Project とMocking bird, iPlotzを試した。

でも全部じっくり試すのも時間がかかってしまうので、この手のツールは（チームメイトに使ってもらうことも考えて）習得が容易であることも重要と判断して大雑把に使ってみるだけにした。

もし「このツールのキモはココ」ってとこを見落としてるようだったらツッコミ入れてくれるとうれしいです。

Pencil project

Pencil projectはFirefoxのプラグインとして動作する感じ。すごい重かった。GTK widgetとかも描けたりして便利そうではある。

Mocking bird

Mocking bird。名前がかわいくて結構お気に入り。Pencilのあとだったので随分と軽く感じた。Webアプリケーションもモックアップをつくるにあたって必要なパーツは大体揃ってそう。Pagenationなんかもあっておもしろかった。

でもスクリーンショット撮る寸前に固まった。

iPlotz

iPlotz。Appleとは関係がない！Mocking birdと似てて、Mocking birdよりも高機能で重そう。パーツの数自体はMocking virdより多い。

Wireframing モードとManageモードを切り替えられるっぽい。Manageモードではクリックできたりするプロトタイプが見れる。でもManageモードにしたら固まった。

まとめ

Pencilは重い。iPlotzは高機能。Mocking birdが個人的にはちょうどいいかなあ。

とりあえず全部かたまった。

■ Gemのmemcachedがうまくインストールできない場合がある

Portageの更新したあと、memcachedのgemをインストールしようとしたら失敗した（Portage更新との因果関係は不明）。

この問題は既にGithubのBTSで報告されていて、まだ解決されていない。ビルド時のエラーログも報告されている。これは僕が遭遇したものではないけど、状況的にはほとんど同じ。SASLのライブラリがうまくリンクされていないように見える。

とりあえず動くようにしたものをForkして公開しておいたので、同様の問題に遭遇した人は参考にしてください。