石畑義文氏

　「CEDEC 2011」の最終日となる9月8日、「ハッター軍曹のソフト運営改革術」という変わったタイトルのセッションが開かれた。講演者は株式会社セガ 第一研究開発本部 セクションリーダーの石畑義文氏。

　石畑氏はセガに入社後、3Dロボットアクション「電脳戦機バーチャロン」シリーズのプログラマーを担当。このシリーズの中に「ハッター軍曹」という、石畑氏をモチーフにしたロボットのキャラクターが登場する。……ということで本講演は、「ハッター軍曹」こと石畑氏がソフト運営改革術について語るものである。

　その後、石畑氏は新型基板「LINDBERGH」を採用したアーケード用テニスゲーム「パワースマッシュ3」の開発に携わった。そしてその経験を買われ、2007年7月からアーケード用サッカーゲーム「WORLD CLUB Champion Football（WCCF）」の新作、「Intercontinental Clubs 2006-2007」のチーフプログラマーを任される。「WCCF」はそれまで「NAOMI2」基板で開発されていたが、「2006-2007」から「LINDBERGH」を採用することになったためだ。

　タイトルに「2006-2007」などとあるように、「WCCF」はほぼ毎年のペースで新作を投入している。選手カードを直近のシーズンのものにリニューアルするとともに、ゲームのアップデートも行なっている。そして「2006-2007」は先述のとおり、基板の変更という大きな仕事も発生した。それまでの新作投入よりも仕事量が増大し、プログラマーたちは目の前の仕事を片付けるだけで精一杯になってしまった。

　その状況を、石畑氏は是としなかった。では、それをいかにして打破し、チームを改革したのか。「ハッター軍曹」が自らの取り組みを語っていった。

問題点を洗い出し、理想像と照らし合わせて、課題をクリアしていくというステップで話が進められた

■ スクラムをやめ、チームとしての運用を取り戻す

スライドでは「ハッター軍曹」が大活躍。概ねこのノリで進んでいく

　当時の「WCCF」の開発チームは、仕事量が増えた分、スタッフが増員されていた。しかしそれでも先を考えられるような余裕のある状態とはいえなかった。石畑氏は今後も1年に1回新作をリリースしなければいけない前提から、将来を見据え、安定して動ける理想の状態を考えた。

　最初に取り組んだのが、問題解決に時間がかかっていた点。当時のチームはスクラムの手法を使っていたが、スプリントが1カ月で、その間ひたすら作業を続けていた。問題が起きても1カ月先延ばしされてしまっていたのが原因だ。

　石畑氏はこれに対して、「スクラムをやめる」という選択を取る。代わりに、週1回のプログラマーミーティングで作業の見直しを実施し、問題確認を1週間に縮めた。さらにチームを少人数の班構成に細分化し、班長を置いて一定の権限を委譲。班内の問題は班長判断で解決していいことにし、週1回の報告を受ける形にした。タスクの確認も、従来は全員でやっていたものを班単位で行ない、効率化を進めた。

　ただし、スクラムの仕組みのいい部分は残した。その1つが、全員参加の朝礼。各々に昨日何をして今日何をするかを数十秒で語らせた。細かいところは見ないが、昨日も今日も同じことをやっていると、どこかが詰まっていることに気付ける。またその日の作業が明確化され、朝からモチベーションを持って仕事ができる効果もある。さらには気を利かせた人があるツールを作っていたら、朝礼で同じツールを別の人が作っていたことが発覚し、重複を避けられたこともあった。

　この施策により、チームとしての運用が可能になった。しかし、まだタスクが多いことには変わりない。

スクラムをやめて、週1のミーティング、班構成、朝礼といった仕組みを実施。問題の発覚と対応の迅速化が図られた

■ コードレビューや毎日のビルドで意識改革を図る

　次に石畑氏は、バグの多さに目を向けた。実装に追われてバグを取る時間がなく、動かなくても放置してしまうという状況が発生していた。安定運用のために、チームが協力するという意識を持たせることが次の課題になった。

　ここでの施策は、コードレビューをすること。週1のプログラマーミーティングに組み込み、当番制で必ず全員に回るようにした。いつか自分に回ってくるので、他人が指摘されたものは直そうとするし、各自がソースを追いかけることで、コーディングルールが徹底され、自然と全体像を掴んで設計力を養えるという効果もある。またレビューを行なう本人のほかに、議事録の担当者も別に立てることで、レビュー担当者と会話させてコードの理解をより深めさせた。

　自分だけのソースではない、ということを意識させるための施策だが、「WCCF」のようなシリーズタイトルにおいては、1度直したソースが先のリリースにも活きてくるため、単発の製品よりも効果が長く続くというメリットがある。

　ただし全てのソースをコードレビューするような時間は当然なく、バグも完全に解消はしない。そこで石畑氏は次の策として、静的解析ツール「QAC++」および「Coverity」を導入した。初期化忘れや配列のオーバーラン・アンダーランといったよくあるミスを丁寧に指摘してくれる。特に自分のソースに自信を持っているベテランには、ツールが機械的に指摘してくれるのが効果的なのだという。またこれらのツールはバグを見つけるだけでなく、犯しやすいミスと推奨する修正などのテキストも同時に見られ、教育としての効果も高い。結果として、バグは2カ月ほどでほぼ解消した。

　解析ツールの注意点として石畑氏は、「指摘されたら同じようなところは見直す」、「他の人に教えて再発防止を防ぐ」といったことで効果を高めることも付け加えた。なお「QAC++」と「Coverity」はどちらも有料だが、デバッグ期間の縮小に成功し、リリースを早められたおかげで、ツールの分は十分に回収できているという。

　さらに安定運用に向けた施策として、毎日、朝にビルドしなおした。これは当番制で1人に行なわせ、必ず実際に動く状態まで持って行かせた。毎日遊べる状態にすることを意識させることで、安定運用するという意識に改革させるのが狙いだ。また副次的な効果として、他人のコードを見るのでコードレビューとほぼ同じ効果が得られるとともに、バグがあれば担当者と会話もするので、班単位を超えたコミュニケーションも生んだ。

コードレビューにはさまざまな効果が期待できる。ただし時間をかけないでやるのもポイント
静的解析ツールはバグをつぶすとともに学習効果も期待できる

毎日遊べる状態を保つことで、バグを放置するという意識からつぶし、安定運用の意識を植え付ける

■ 作業の効率化がゲームを面白くする！

　これらを行なって効率化を進めた結果、18人いたプログラマーのスタッフは約2年で13人に減り、2010年には10人で回せるようになった。それでも1年に1回以上のペースで新作のリリースを続けている。

　今後の課題としては、1人で抱える分が多くなってきたため、人の入れ替え時に大変であることと、班同士が縦割りすぎて連携がやや心配な点が挙げられた。またこのやり方を他のチームに使えるのかどうか、例えば100名のチームでも機能するのかは実証している最中だという。

　石畑氏は講演の締めに、「これらの効率化をするのは、ゲームを面白くするための時間を取るため」と述べた。講演のタイトルに「ハッター軍曹」と書いてしまえるくらいのユーモアと余裕を持って臨める環境を整えましょう、というのがこのセッションのメッセージと言えるのかもしれない。

作業の効率化により、安定して新作を投入するとともに、プログラマーを減らすことに成功した