究極のプログラマーは「真田さん」!?――技術者のあり方とは ：ヒライタケシの「投げる前から変化球」（その2）（2/3 ページ）

ちょっと間が空いてしまったが、ヒライタケシの「投げる前から変化球」第2回目をお届けしよう。今回はヘキサドライブの松下正和氏に登場していただこう。松下氏は大手ゲーム会社に在籍後独立。現在はゲームプログラマーの制作集団を率いている。平井氏との間で、どのような会話が展開するのか……。

[ヒライタケシ／ITmedia +D Games編集部，ITmedia]

メインプログラマーとして

平井　メインプログラマーを担当されたのはいつからですか？

松下　わたしは前の会社に、アーケードゲームの格闘ブームのちょっと終わりの方に入社しました。格闘ゲームにたずさわった後は、時代とともにコンシューマへ仕事が移っていきました。ドリームキャストのゲームだったので、1999年ぐらいでしょうか。そのころからメインプログラマーを担当しています。まだアーケードとコンシューマ両方の仕事をしていましたね。

平井　松下さんはずっとアーケードを担当されていたのですか。

松下　その会社だけではなく、業界全体でアーケードが縮小化の傾向にありましたが、入社5年目ぐらいまではずっとアーケードでした。ドリームキャストやプレイステーションぐらいから、アーケードでもコンシューマでも発売するタイトルが出てきました。ハードの性能もアーケードとコンシューマが並んできたので、そこからはずっとコンシューマです。

平井　その後、有名タイトルも担当されましたよね。

松下　Xbox LIVEタイトルのネットワーク周りですとか、会社共通のライブラリシステムなどもやってました。まだ当時はアーケードとコンシューマ両方を作っていましたから、Direct Xを担当する人がいなかったので、やらせてほしいと名乗り出て、社内ライブラリに関わったんです。すると次に「Xboxタイトルをやってよ」となり、その後、PS2でリリースされた有名アクションゲームや、Xbox360でミリオンヒットしたタイトルの担当をさせて頂きました。

平井　ライブラリを作る方とゲームを開発する方が同じというのはなかなか少ないですけど、会社的な文化としてあったんですか？

松下　いえ、あんまりないんですが、その当時の上司が理解ある方で、「こんなのやりたい」と言うと自由にやらせてくれる人だったんです。次に何か新しいことに関わりたいと思って、Direct Xをやりたいと。

平井　僕もそうなんですよね。それまで経験がなかったんですが、入社したら「システム管理も一緒にやってほしい」と言われて、メインプログラムとシステム管理の両使いになりました。セガに来て、セガサターンの後期になったら、ライブラリチームの打ち合わせに呼ばれるようになって、実際に自分が使うにふさわしいライブラリはどんなものか、というディスカッションをしながら制作に取り組めました。

　今はマルチプラットフォームを最初から考えているので、昔とはやり方が違いますけれど、わたしの場合はターゲットごとにライブラリを作ってましたね。どちらかといえば自社のフレームワークという形で考えているところが多かったと思います。今はレイヤーが広がりました。

松下　昔はそれこそ、チームごとにシステムを作ったりしてましたね。わたしが最初に共通ライブラリチームの立ち上げに関わった時が、初めての会社共通ライブラリができ始めた頃でした。

平井　セガはドリームキャストの時もアーケードとコンシューマは別々で作っていました。開発者ニーズが違ったのが全てだと思います。開発マシンもアーケードはSGIを使っていて、コンシューマはPCを使っていました。

松下　ライブラリの重要性はまだ認識されていないような時代で、PCとXboxの担当者がわたしと新人の2人だけでした。それなのにタイトルが3本ぐらいあって大変でした。

平井　そこから共通のフレームワークを作り出していったんですね。

松下　それが第一段階という形ですね。そして共通システムの良さが認められて、全体のフレームワークを第2弾でやってる感じでしょうね。そういうのが好きで得意なプログラマーが、入社してきたのもあるでしょう。

　会社側が言ってきたというのもあるでしょうけど、現場のプログラマーがこういうことをやりたくて作っちゃいました。というきっかけで動き出したと言えます。

平井　なるほど。ところでメインプログラマーに必要な要素・思考って何だと思いますか？

松下　全体の効率を上げられることですね。チームの中の一プログラマーとして、その部分の仕事をこなすのは最低条件であって、チーム全員のポテンシャルを上げることでしょう。皆が持っている潜在的な能力を引き出すというか。基本的にゲームに対して熱い情熱を持っている優秀な人たちですから、うまくつなげてあげることですかね。

平井　松下さんはコミュニケーションが誰とでもできる、高いヒアリング能力をお持ちだと思います。同じエンジニアでもグラフィックス思考の人がいて、システム思考の強い人がいる中で、全ての人にアプローチできる人ですよね。

松下　ヒアリング、好きなんですよね。

平井　僕も当たり前な話ですが、インプットとアウトプットという設計をていねいにしています。プログラミングそのものより、その日にやるべきことの目標をしっかり立てています。どこまで何にチャレンジして到達するというテーマや目標を、誰かと話し合ってシェアするようにしています。特にこの業界のプログラミングは1人で書けるものではないので、情報伝達、つまり「報告・連絡・相談」をきっちりすることが何より大切だと思ってます。

松下　わたしの場合は、朝礼に加えて終礼もやってました。今日はどこまで進みました、問題がここに発生していますという報告を夕方の6時半ぐらいに、少しでもやることにしています。さらに週1回の会議もあって、“これでもか”というぐらい情報共有をしています。

平井　それはいいですね、朝礼でかかげた目標がどこまで今日できたかという過程まで、すぐチェックできますし。

松下　最近はそれに加えてSkypeのチャットルームで、リアルタイムに提案や報告をしていますね。ログが残るので後から入ってもログを見て状況が分かるわけですよ。当人がいなくても回答を書き込んだりできますし。

平井　弊社はIRCで同じことをしています。情報共有の大切さは、どこの会社でも認識は一緒ですね。

　例えばプログラミングだけじゃなくて、開発セクションで言ったらデザイン・企画・サウンドといろいろありますが、さらにリサーチといった所も含めて、大事にしている開発手法はありますか。これはプログラミングというよりはグループワークの中でのプログラミングになりますが。

松下　これまでもほんとにいろいろなものに挑戦したんですよ。ブレストするときに、大きな模造紙を買って、紙の真ん中から書いていったりとか。でもなじまない人もいるし、その人その人に合わせた話し方、やり方をするのが大事だなと気が付きました。

　とあるタイトルを開発していた2年の間には、十数名のプログラマー全員と3カ月に1回、個別に話をするようにしていました。長い開発期間の中ではもちろん毎日話をするんですが、個別ミーティングをしたいなと思って。今の会社になってからは1カ月に一度必ず、1人1人と話す機会を設けています。普段から食事にいって雑談したり、一緒に隣で仕事もしてるわけですが、それでも個人で話をしています。

平井　ボクは開発というものを「航海」に例えることが多いんです。前もって準備することはとても大事です。設計とコンセプト、そして目的地を決めるわけですが、ディレクターという船長は、そこへ向けて行って、帰ってこなくちゃいけないんです。最初に決めたことは大切に守りつつ、臨機応変でなくてはならず、チャンスは厚くピンチは薄くするために舵を切るのが、メインプログラマーの素養なんじゃないかと。特にゲームというエンターテインメントのくくりでは、この作業が多いと思います。時代のニーズもトレンドも、どんどん変わっていくけれど、自分たちが目的とするスタイルも突き抜ければ作風が変わってしまうので、とがったり丸くする部分にクッションを置きつつ、方向性を決めていくのがメインプログラマーに必要なことだと考えています。

　そこに松下さんがおっしゃったような“コミュニケーション”が加われば、すごい成果物が返ってくるのかもしれません。

松下　セクションごとに仕事内容は違っても目的は同じはずなので、そこをうまく調停していくことで、いいゲームができると思います。もちろん時にはぶつかることもありますが、ぶつかっても前に進めるようにやることですね。

　現場の方たちって職人さんが多いんですよね。そして、お互いに良いものを作ろうと思っている。ただ、そこには色々な制約があって、全ての人が納得いく答えを出すのは難しい。以前であれば、プランナーさんだったりが、各セクションの調停をすることもあったかと思うのですが、規模が大きくなり、システム的にもかなり複雑になったことで、調停をする人にも、かなりの専門知識が必要になってきました。そこで、メインプログラマーと呼ばれる人たちの仕事も、ちょっとずつ変わってきたと思いますね。

　技術も分かり、ゲームの企画的面白さも分かり、デザイナーさんの理想としている部分も理解し、プロデューサの要求するスケジュールも把握しつつ……という複雑な要件をこなすことができるポジションとして、メインプログラマーが必要となるのではないでしょうか。

　ただ、チームによって役回りに違いが出てくることがあります。その時にチームを組んだ同士でお互いの得意分野を認め合い、分担できるのが理想ですね。そういう風に、チームにより柔軟に対応できるということも、メインプログラマーとして重要かと思います。

平井　同感です。