■ 飲み会＆新入社員 
今日は飲み会。少々飲んだので頭が少し呆けてる。やっぱりアルコールは苦手。あと、この区切りを機会に退職する人が何人かいる。前回の仕事でお世話になった人も多くてとても残念なことではあるけど、今の仕事以上にやりたいことがあるのであれば、それはそれでとても良いことだと思う。それぞれの特技を生かした新天地での活躍に、心から期待したい。
明日からしばらくUP休暇に入るので新人研修の引継ぎなどをどうするか相談。プログラマが知っておかなくてはならない知識は年が経つごとに、ハードウェア・アルゴリズムなどの低レベル部分から、アプリケーション・設計などの高レベル部分への積み重ねでどんどんと増え続けているため、学生のレベルが毎年変わらないと仮定すると、平均レベルの新人の相対的な実力は、年を追うごとにじわじわと下がっていく、ということになる。最近は便利な開発環境や言語が増えてきているために、ライブラリやフレームワークを利用してなんとなく動くものは作れたとしても、その基礎となる低レベル部分に対する知識や理解度に関しては不安に感じることが多く、なにかとアンバランスな印象がある。
でもまぁ、入社時の能力なんて大多数の人は誤差レベル程度の違いしかないわけで、本当に大切なのはゲームプログラマとしてその後伸びる為に必要な、モチベーションの源になるような「何か」を持っているのかどうか、に尽きるのだろうと思っている。伸びる人は放っておいても伸びるし、そういう人が多いと本当に楽。
で、そういうものを持たない人についてはどうすればいいのか、というのは永遠の課題なのかもしれない。「人間は環境が作る」という言葉通り、ぬるま湯のような環境の中ではヌルい人間しか育たないだろうけど、かといって負荷が限界を超えて人が潰れてしまうのも困る。何にしても、基本的にはある程度の苦しい状況を乗り越える経験なしには人は成長しない、ということだけは間違いないのだろうけれど。
とりあえず、明日からはせっかくの休みなのでぬるま湯につかるような状態ではなく、少しでも有意義に過ごせるようにはしていきたい。
■ [本][読了]ウェブ進化論 
ほとんど著者のBlogで呼んだことのある内容であったにもかかわらず、最後まで一気に面白く読むことができた。感想はいろいろあるけれど、とりあえず直接仕事に関係ありそうな印象に残った一節から引用。
しばらくして私は、この仕事のスタイルは「組織と情報」に関するコペルニクス的転回なのだと気づいた。私たちが慣れ親しんできた「組織の仕事」では、組織内の情報は隠蔽されているのが基本だ。別の部署で何が起きているのかはわからない。トップが毎日何を議論しているのかを知ることはできない。「この人間にこの情報は開示してもかまわない」と誰かが判断した情報だけが開示される環境下で、個々人が仕事をしていく。だから、貴重な情報を握ってコントロールすることが組織を生き抜く原則となる。よって、部門内や部門間で情報共有を目的とする会議が増えていく。
しかしモチベーションの高いメンバーだけで構成される小さな組織で、全ての情報が共有されると、ものすごいスピードで物事が進み、それが大きなパワーを生む。仕事の生産性が著しく向上する。誰かが提示した問題点が別の誰かによって解決されるまでの時間や、面白いアイデアが現実に執行されるまでの時間は、時に数分という場合さえある。
ゲームも絶え間ない問題解決の末に出来上がるものだから、「適切に問題が提示されて」「それが可及的に速やかに解決される」ような体勢をつくることは、より良いものを効率的に作るためにはとても大切であるように思っている。
そのためにプログラマができることは、冷静に問題を把握・判断して解決できる能力を持つことと、新しくて面白いアイデアを簡単に試して見てみることができるようなフットワークの軽いワークフローを構築することだろう。「こんなことができたらきっと面白いよね？」と言われて数分後に「動かしてみたらこんな風になりました。これだったらここをもっとこうすればさらに面白いのでは？」みたいなやり取りができるようになれば、物事は加速度的に面白くなっていくはずだろう。
また、やることを最初にかっちりと決めて、それを下層に周知していくようなトップダウン体勢では柔軟さに欠け、そこからは創意工夫のある面白いものは生まれにくいように思う。柔軟で試行錯誤がやりやすい体制を作るためには、大人数のチームであっても10人程度の小規模なチームと同程度のフットワークの軽さを維持できるような仕組みが必要になる。
そのためには、リーダーが考えたコンセプトや実装方法を下位に伝達するための職種別の指揮系統とは別に、特定の問題解決のための権限をもったセクションを越えた3～5人程度の小規模なグループを状況に応じて集合離散させながら、それぞれのグループで適切な問題の検出とそのすみやかな解決を行っていけるような柔軟な構造が、チームの中から自然に生まれてくるような形が理想的だろう。
起こった問題やその解決策はチームの関係者全体で共有され、トップは個々の問題の認識と、それに対するそれぞれの小グループから出てきた解決策がコンセプトに則っていて適切かどうかを緩やかに管理しながら、場合によっては適切なタイミングでテコ入れを行っていく。このような構造はある程度スケーラブルに構築できるだろうから、経験上、50人くらいまでのチームであればこういった緩やかではあるけれど強い構造を持った組織の運用を行うことは十分可能なのではないか、と思っている。
