「世界に、“一番のワクワク”を届ける」をミッションとし、スマートフォン向けゲームの企画・開発・運営を行っているゲーム会社、f4samurai。
秋葉原に拠点を構える同社は、世界観の構築に強みを持ち、『オルタンシア・サーガ -蒼の騎士団-』（『オルサガ』）をはじめ、『マギアレコード 魔法少女まどか☆マギカ外伝』（『マギレコ』）、『コードギアス 反逆のルルーシュ ロストストーリーズ』などを手掛け、いずれもヒット作として覚えている人も多いだろう。
そんなf4samuraiのゲーム開発はどのようにして行われているか。今回、gamebizでは、そんなf4samuraiの開発環境を、同社マスコットであるエフフォーくんと探る「f4samuraiマガジン」を特集掲載していく。同社がヒット作を輩出するその秘密について探ってみた。
皆さん、こんにちは！ f4samurai・エフフォーくんです。
2024年4月より、当社の最高技術責任者（CTO）が創業役員の松野より二代目の森本へ変更となりました。
今回の記事では、新たにCTOに就任した森本が目指すエンジニア組織について、チーム指針・技術指針の両面からお伝えします。
f4samuraiのエンジニア部が掲げる価値観や今後の展望などを語ってもらいました。
【目次】
- CTOになるまでの歩み
- f4samuraiエンジニア組織の指針【チーム編】
-１．自分ではない誰かのために。
-２．今日明日よりも、先の未来のために。 - f4samuraiエンジニア組織の指針【技術編】
-１．ニーズ思考であれ。
-２．ドメイン思考であれ。 - 大切にしている価値観
-１．技術は「手段」であって「目的」ではない。
-２．理解されてこその成果。 - 「強いエンジニア組織」を目指して
CTOになるまでの歩み
ーー： まずは森本さん自身のキャリアについて伺いたいと思います。f4samurai入社前までの経歴について教えてください。
新卒で大阪のSES（エンジニアがクライアントの会社に派遣され、その会社で業務を行う形態）企業に入社しました。新卒研修が東京実施だったのと、その後決まった配属先も東京だったので、結局それ以降の社会人生活はずっと東京で過ごしています。その会社のクライアントが株式会社野村総合研究所だった繋がりで松野さん（f4samurai取締役・初代CTO）と出会いました。
数年間SESの仕事を続けた後、もっと上流から開発に携わりたいという気持ちが徐々に強くなり、転職を考えるようになりました。このときすでに松野さんたちはf4samuraiを立ち上げていたのですが、すぐに合流したわけではありませんでした。
そこからさらに2年ほど経った頃、以前同じクライアント先で働いていて、f4samuraiに転職したという知人から「また一緒に働かないか？」と誘いを受けました。松野さんたちが立ち上げた会社ということもあり、一度話を聞いてみようと連絡したのが入社のきっかけになりました。
ーー：f4samurai入社後はどのようなキャリアだったのですか？
入社してすぐは『ボーダーブレイク mobile －疾風のガンフロント－』にジョインしていました。専門領域はサーバーサイドなのですが、当時はプロジェクトマネジメントのような仕事もしていましたね。
その後、当時開発中だった『オルタンシア・サーガ -蒼の騎士団-』にサーバーサイドエンジニアとして参画して性能回りなどを担当し、運用まで携わった後、『マギアレコード 魔法少女まどか☆マギカ外伝（以下：マギレコ）』の開発に参画しました。マギレコではアプリ自体の開発業務を行ったり、ネイティブ・サーバー・フロントの3つのエンジニアチームのつなぎ部分を担当したりとより幅広い業務に携わることができました。
その後も、大型プロジェクトに関わったりと、f4samuraiジョイン後は開発から運用まで幅広いキャリアを積めたように思います。現在は新規プロジェクトに参画しつつ、今年（2024年）の4月からはCTOとして、各プロジェクトの状況把握からメンバーのマネジメント、方針の判断などの旗振り役のような業務のほか、エンジニア部門の代表者として組織の意思決定を行う会議等にも出るようになりました。
f4samuraiエンジニア組織の指針【チーム編】
ーー：森本さんが目指すエンジニア組織のチーム指針を教えてください。
チーム指針は大きく2つあると思っています。
１．自分ではない誰かのために。
まず大前提として、自分のためではなく、他の誰かのために仕事をしてほしいと思っています。
人間というものは、自分のことしか考えていないと「早く終わりにしよう」「ただやるだけでいいや」のような“こなす”思考になりがちだと感じていて。でも仕事を依頼されるということは、必ずそれを“やってほしい誰か”がいるわけですよね。「どうしてこの依頼をしてきたのか」「どういう意図があるのか」など、関わる人の意図をしっかりと汲み取り、理解する努力のできるチームでありたいと考えています。
また技術的な観点でも、「自分が分かればいい」という独りよがりなコードや設計はエンジニアとして良い成果物とは言えません。依頼されたコードを書いて渡した後、仮にバグが起きたとしたら、多くの場合それを直すのは自分ではなく別の誰かです。
絶対にバグを起こすな！ということではなく、自分の手から離れた後、誰でも直すことができるコードを書く必要があるということ。「このコードは他人のために書いている」という意識を常に持っていてほしいです。それを積み重ねることによって、エンジニアリングに起こりがちな属人性の排除にも寄与していきたいと考えています。
個人的に「自分にしかできない」という言葉が好きではなくて。世の中には、自分にしかできないことを作ることで、自身の雇用や市場価値が守られると考える人も多いですし、身を置く場所によってはそれも一つの正解だと思います。
でもその考え方は、できればf4samuraiでは持ってほしくありません。少し冷たい表現になりますが、私も含めて「替えのきかない特別な存在」というのはこの世にいないと思っています。むしろ、突然今の仕事から離れなくてはいけなくなったとしても、すぐに誰にでも引き継げる状態を作っておける人のほうがチームの成果は最大化されますし、そういう人を個としても評価していきたいと考えています。
２．今日明日よりも、先の未来のために。
もう一つは、何かの意思決定を行うとき、今日明日など直近のことだけを考えて決めるのではなく、2年後、5年後など“もっと先の未来”を想定してほしいということです。
例えば、以下のような2つのライブラリのどちらかを選択する場面があったとします。
長期間使われていて実績が非常に多い。使い勝手も良い。ただし、メンテナンスチームはすでに解散しており、この先どういう不具合が出るかわからない
比較的新しいライブラリで実績は少ない。プログラム構造も変更しないと使えないが、動きが活発でこれから主流になっていく可能性がある
今この瞬間の業務効率を考えると選択するのは間違いなく「前者」です。しかし、f4samuraiのエンジニアチームは、ここで「後者」を選択できる組織でありたいと考えています。なぜなら、前者はいつか不具合が出たり、最新バージョンに追いつけなくなったりして、数年後にはいわゆる“技術的負債”になる可能性が高いからです。
確かに後者を選択した場合、改修のための時間や人的リソースなどのコストがかかります。しかしその場しのぎの正解ではなく、明日よりもっと先の未来を考えた選択をしていくことを優先するならば、そのコストを加味しても後者を選ぶべきだと判断できますよね。
納期が迫っていたり、開発に余裕が無かったりするとついつい「今、楽をすること」に流されがちですが、エンジニアは長期的目線を持って考え、「こうするべきだ」と周りを説得できる、周りが納得しなければさらにその上の責任者に働きかけられるくらいであるべきだと思っています。
これまで社内でも似たような場面において、技術的負債を作らないように努力をしてくれていたエンジニアメンバーがいます。しかし、組織方針としては明確に示すことができていなかったので、これからは改めて「技術負債を作らないこと」をチーム指針として伝えていき、そういう動きのできるメンバーを後押ししつつ、エンジニア組織一丸となって先を見据えた開発に取り組んでいきたいと考えています。
f4samuraiエンジニア組織の指針【技術編】
ーー：続いて、技術指針を教えてください。
こちらも2つ考えています。
１．ニーズ思考であれ。
一つは、常に「ニーズ思考」で開発に当たってほしいということです。
ニーズ思考とは、叶えたいものに対して、「必要な技術は何か？」を考え、最適な方法を組み合わせて提供しようというものです。叶えたいものありきの考え方で、提供する技術はあくまで「手段」という考え方になります。
一方、ニーズ思考とは正反対の考え方として「シーズ思考」というものがあります。こちらは技術ありきの考え方で、新技術などが出てきたときに「それをどう使おうか？」から考える思考法のことです。そのため、こちらは技術自体が「目的」であることが多いです。
近年活発なAIを例に挙げると、とにかくAIを使ってみて、AI技術を活用できそうな場面を探していくのがシーズ思考です。逆にニーズ思考は、困っていることや解決したいことがあり、その一手段として考えたときにAIが使えないかを試してみるというイメージです。
f4samuraiのエンジニアチームには、技術を目的とはせず、“叶えたいことを実現するため”に技術を使ってほしいです。エンジニアであれば最新技術には当然興味はありますし、どうにかして使ってみたい気持ちにもなると思います。ですが、組織の中のエンジニアとしては、常にニーズ思考を優先させてほしいという気持ちで指針の1つとしています。
２．ドメイン思考であれ。
もう一つは「ドメイン思考でいよう」という指針です。このドメインとは「領域」という意味で、ドメイン思考というのは端的に言うと、開発において“情報の領域を重んじる”考え方になります。
一般的な感覚でいうと、みんなが幅広い知識を持っていて、専門外のこともわかるほうが良いように思えますよね。しかし、ゲーム開発の世界でそれをやってしまうとスムーズな開発の妨げになってしまうことがあるんです。
例えば、サーバーサイド領域である「ガチャを1回引く条件は何か」という情報をクライアントサイドエンジニアが安易に自領域に組み込むのはご法度です。なぜかというと、ガチャを引ける条件が変わったときに、その情報や知識をクライアントサイドエンジニアにも共有しなければならなくなるためです。
この情報を「サーバーサイドエンジニアだけが必要とするもの」にしていれば、サーバーサイド内だけで変更作業を完結させることができ、クライアントサイドには変更したものを通常のフローに沿って渡すだけで済みます。なんでも知っているエンジニアたちがドメインを無視して開発するよりも、スムーズに、効率的に開発ができるのです。
一度開発が完了したらそれ以降の運用やアップデートのないシステムを作っているのであれば、このドメイン思考はおそらく必要ありません。開発の情報を隅々まで知っているエンジニアさえいれば、領域関係なく開発ができますし、エンジニア自身も楽です。ですが、モバイルゲームというのは長期運用を前提として開発する必要があり、さらにその中でアップデートをくり返していくサービスです。
そのようなものをチームで開発していく以上、f4samuraiのエンジニアには「この知識はどのドメインが持つべきなのか」をきちんと考えてほしいですし、安易に「それうちでもできるよ」とは言わず、ドメイン外の知識を重く扱ってほしいなと思っています。
大切にしている価値観
ーー：森本さん自身が大切にしているエンジニアとしての価値観を教えてください。
大きく3つあります。
１．技術は「手段」であって「目的」ではない。
技術指針と繋がる部分なのですが、技術は手段であって、目的ではないということです。エンジニア部門の指針としてご説明しましたが、これは自分の根底にある価値観の一つでもあると思っています。
ただ、シーズ思考が全面的に悪いとは全く思っていません。個人としてシーズ思考を持っているのは自己研鑽の観点でも全然良いと思いますし、シーズ思考だからこそ導き出せる方法もあるかもしれません。ニーズが出たときのために、最新技術を常に追っておく姿勢は必要だと思いますし。
エンジニアメンバーの皆さんには、何か技術的な提案を行うときは、ただ単に「最新技術だから」という理由で提示するのではなく、シーズ思考＋αの納得できる理由と一緒に提示してほしいなと思っています。
２．理解されてこその成果。
「どんなにすごいことをしても、相手に理解してもらえなければ何の意味もないし、成果にもならない」と思っています。
非エンジニアの方で「エンジニアにしてもらった説明、難しくて全然わからなかったけど、自分の理解力がないせいだよね……」と思った経験のある方もいるのではないでしょうか。ですが、基本的にそれは非エンジニア側の落ち度ではなく、理解できるような説明ができなかったエンジニアの責任だと私は思います。
例えば、私がすごく難しいことをやってのけて、ものすごい発明をしたとします。しかし、そのすごさを分かっているのは自分だけで、周りの人には「なんかすごいんだろうけど、何がすごいのかはわからない」と言われてしまったら、それはもう伝える能力が不足している自分のせいです。どれだけ実態がすごいものでも、中身が伝わっていない時点で、一般社会においては全く価値がないと言われても仕方ないのかなと。
他人と関わって生きていく以上、他人に理解されないと何も始まりません。そのすごさを周りに理解されることこそ“成果”なのです。そのためにも、誰にでも分かる言葉で説明すること、周囲の理解を得る努力をすることが大切だと考えています。
３．徹底的に“怠惰”であれ！
問題発言と思われるかもしれませんが（笑）、エンジニアとしては“楽できるところは楽しよう”という考え方はとても重要だと思っています。私はエンジニアリングという学問は“サボりの学問”だと思っていて、省ける作業や無駄な工数を削り続けた先に、本当に必要な開発や、手や頭を使う場面が存在すると思っています。
機械やAIに任せられるところは任せればいいですし、エンジニアは最初の1回だけ手を動かして、あとはドキュメントを整理して誰でも作業できるようにしておくのも有効な手段です。もし、繰り返し同じことを行っていたら、それはたぶん自動化ができるし、まして手動でやっていたらそれはもうエンジニアがやることではないんですよね。エンジニアなら、2度も3度も同じ作業をしないようにする意識を持っていなくてはいけないと思います。
それに付随して、時間効率を重んじるという価値観も持っています。要は“働いた時間”にお金をもらっているのではなく、“生み出した成果”にお金をもらっているという考えです。もしも同じ成果を出せるのなら、何時間も残業をするよりも、より短い時間で達成できる方が優秀だと言えるのではないでしょうか。
より短い時間で最大限の成果を出す。そのために「もっと効率化して時間を短縮できないか」「作業をもっと楽にできるようにして、新たな開発に取り組めないか」を考えられる“戦略的怠惰”のような思考は重要だと思っています。
「強いエンジニア組織」を目指して
ーー：最後に、CTOとしての今後の展望を教えてください。
すぐにできる改善には都度取り組んでいるので、将来的な話になりますが、一つは短期的評価ではなく、もっと中長期の目線で評価できる体制にしていきたいです。指針の一つでお話した「技術負債を作らない」という話に繋がるのですが、短期的評価だけだと負債を作らないように動いてくれる人の評価がしづらくなってしまいます。なので、先を見据えた行動かどうかも加味して評価できる体制にしていきたいと思っています。
あとは、余剰人員の確保をきちんとできるようになりたいなと。目下の売り上げと経費を考えると、余剰人員は持たず、適切な人数で開発に当たるのがベストに思えるのですが、余剰人員を持てないと人手が足りなくなったときの対応が難しくなってしまいます。
また、余剰人員で全体に余裕を作ることで、研究開発部門のようなものを立ち上げられないかと考えています。新規の技術を常にキャッチアップすることで、ニーズ思考だけでは息詰まる場面のカバーもできるようにしていきたいですね。
色々とできることはあると思いますが、最終的には、f4samuraiのエンジニア部門をどこよりも強い組織にしていきたいというところに繋がると思います。例え話ですが、エンジニア部門だけが独立して一つの会社になったとしても採算が取れるような会社にしたいです。
そのくらいの気持ちで、エンジニア部門のさらなる組織化・強化を目指していきます！
他にも、f4samuraiではnoteおいても開発環境について発信している。気になる人は以下のnoteでチェックしてみよう。
連載企画「f4samuraiマガジン」のアーカイブはこちらから。
