DeNAが手がけるプロダクトの品質向上と、ソフトウェア開発の生産性の向上を、自動テストやツールなどを用いて実現させるプロ集団「SWET（Software Engineer in Test）」。
そんな「SWET」の中でも、より珍しい領域を扱うエンジニアがそろっているのがSWET第一グループです。
なにせ彼らが手がけるのは「形式仕様記述」。ゲームやアプリの仕様を、自然言語ではなく明確な構文が定義された形式的な言語で記述する記述法のことです。
海外ではAWS、国内ではゲームなどで形式仕様記述が使われていますが、形式仕様記述を業務で使う職場はまだまだ珍しいとのこと。
DeNAのSWET第一グループが目指すビジョンとは？第一グループの2人のキーパーソンに聞きました。
より早く、より火元から、リスクを消す
2014年DeNA新卒入社。入社後約4年間アプリゲームの開発にエンジニアとして携わる。その後今のSWET第一グループの前身となる組織に異動。2022年4月からSWET第一グループのグループリーダーとして仕事に取り組む。
――まず、「SWET」の役割を教えてください。
鈴木 穂高（以下、鈴木）：はい。DeNAの品質管理部に属する「SWET」は、Software Engineer in Testの略で、アプリやゲームのプログラムの欠陥を見つけたり、欠陥が入り込まないための対策を講じたりするチームです。
「SWET」はふたつのグループに分かれていまして、私たち第一グループは、実装の前段階にあたる仕様書の品質を向上させるための取り組みをしているチームです。
それに対し第二グループは、実装の品質向上、効率化に取り組むチームとなります。
――仕様書の品質を向上させるということは、実装の前の仕様書の段階で欠陥がありえるんですね？
鈴木：ありますね。本来仕様書に記載すべき仕様が書かれていなかったり、書かれている仕様に誤りがあったりした結果、欠陥が生まれます。
伊藤 瑛（以下、伊藤）：過去の実例でいうと、リリースから3年たったあるゲームタイトルの欠陥を分析したところ、不具合種別の中で、一番大きな割合を占めていたのが仕様不備でした。
仕様書を書く段階での不備がなければ、生じなかったコストが多々あったわけです。
鈴木：なので、言い方を変えると、私たちSWET第一グループは、大きな火事になる前に、より早い段階で欠陥を取り除くために尽力するチームということになります。
――そんなSWET第一グループに、お二人は、どのような経緯でジョインされたのでしょうか？
鈴木：私は2014年に新卒でDeNAに入社。最初の部署でゲームアプリの開発を担当しました。
エンジニアとして開発をしていたとき、「仕様書の品質が上がれば開発効率ももっと上がるのでは」という思いがずっとあったんですね。
というのも、アプリゲームって仕様がとても複雑で規模も大きい。チーム内で仕様書のレビューはしていましたが、どうしても仕様上のミスや抜け漏れが出てしまい、ジレンマを抱えていました。仕様書の品質を担保する別の手段が必要だと考えていたとき、SWETグループの存在を知りました。SWETには仕様書の問題に対して取り組める環境があったので、自ら手を上げて2018年にSWETの仲間入りをしました。
――伊藤さんは？
伊藤：僕は2019年に中途入社でDeNAに入りました。それ以前はゲームではなく、Webの開発を手掛けていました。サーバーサイドがメインでしたが、人が足りずフロントをやることもありました。
2019年11月DeNAに中途入社。前職ではWeb系の運用開発を担当。DeNAではGo言語を用いたプロダクトの品質向上に取り組んだのち、2021年から現在の業務に従事している。
いずれにしても厳しい納期の中で運用開発をしていると品質が担保されず、QAなど品質管理にあたる工程の方々に全部しわ寄せがいくことに課題を感じていました。
開発者目線で「もっとエンジニアリングなどの仕組みで、品質の担保や改善はできないのか」と考えたときに、DeNAの「SWET」を知りました。
――「SWET」の仕事がしたくてDeNAに入られたわけですね。
伊藤：はい。社内にテストチームを持っている会社はいくつかありますが、歴史があり、本格的だなと感じたのがDeNAでした。
最初は今でいう第二グループで自動テストの仕事を手掛けながら、エンジニアとしてより新しいことに挑戦したくなり、仕様の領域の品質改善に取り組む第一グループへ移りました。
――伊藤さんがおっしゃった「形式仕様記述」を手がけるのが、第一グループの最大の特徴だと伺っています。
鈴木：そうですね。私たちSWET第一グループは仕様の領域に特化して品質改善に当たるチームとなります。たぶん、国内では稀な組織だと思います。
手段として形式仕様記述を用いています。
「形式仕様記述」が持つ２つの大きなメリット
――あらためて「形式仕様記述」とは何か、教えてもらっていいですか？
鈴木：はい。ゲームにしろアプリにしろ、仕様書は自然言語で書かれます。自然言語とは普段私たちが生活のなかで使う言語、日本では日本語ですね。
自然言語は普段から使い慣れているし、表現の幅も広く、微妙なニュアンスを伝えられるメリットがあります。
一方で、デメリットとしては、受け手によって意味が変わることもありえる曖昧さがあることです。
――確かに、聞き間違いや受け取り方の違いで、コミュニケーションの齟齬（そご）が生じることもよくありますね。
鈴木：そうなんです。仕様書において、そんな受け取り方の違いによるコミュニケーションの齟齬が生じると、それが欠陥になります。
ある動きをさせるつもりで書いた仕様が、そのようには受け取られず実装されれば、当然、仕様書通りには動きませんからね。
伊藤：もっとも曖昧さを持つ自然言語で仕様書を書いている以上、少なからずありえるリスクといえますよね。
そこで「一部だけでも自然言語を使わずに仕様書を書く」ことに我々はチャレンジしているのです。
具体的には「形式仕様記述」を使っています。自然言語ではない人工言語で仕様書を書くのです。
――人工言語とは、文字通り意図的に人が作り出した言語。コンピュータ言語や楽譜のような、誰がどう読んでもひとつの意味しかない言語のこと、ですよね？
鈴木：そうです。
形式仕様記述で使う言語は、専用の記述言語で、いわば人工言語です。
StackのAlloyによる形式仕様記述の例
厳密な構文なので、曖昧さがありません。形式仕様記述をする最中に曖昧な点やミスに気づけますし、「意図した仕様が寸分違わず伝わる」という大きなメリットがあります。
――なるほど。楽譜に「ド」の音符があったら「ド」以外出せないように、「こういう意味じゃないか」と間違って解釈されたり、読み間違われることがないわけですね。
鈴木：そのとおりです。解釈がひとつになりますからね。仕様の書き手と読み手との間にあったムダなコミュニケーションが減るわけです。
もう一つ、書き方によっては、形式仕様記述を使うと仕様を動かすことができます。
――どういうことでしょうか？
伊藤：形式仕様記述で書かれた記述は形式的なので、アルゴリズムにそって動くエンジンさえあれば、記述した仕様を動かせます。そしてそれをビジュアライズできます。
既存のエンジンもあるし、DeNAでは私たちが開発した特別なエンジンもあるので、形式仕様記述で書いた仕様を、それらのエンジンで動かせるのです。
動かすことでこの動きは頭の中で思い描いていた動きと一致するのかしないのかがわかりやすくなります。
鈴木：結果として仕様を形式仕様記述で書けば、仕様書を通したコミュニケーションの齟齬が減ります。
――なるほど。開発段階の欠陥も減り、手戻りも少なくなるわけですね。ただ、そもそも形式仕様記述を覚えるのが、簡単ではなさそうです。
伊藤：そうなんです。デメリットは学習コストが高いこと。だからこそ、広く普及しているとはいえない状況です。
ーーということは、DeNAのゲームやアプリの仕様書のすべてが形式仕様記述でできているわけではない？
伊藤：ええ、私たちも「形式仕様記述を使ってもらうこと」がミッションではありません。そもそも仕様全体に形式仕様記述を適用したら、コストが上がりすぎます。
鈴木：そこで、仕様の中でも形式仕様記述のコストに見合った効果が出せそうな部分を抽出しそこに適用します。
――形式仕様記述にすべきか否かの判断はどのようにするのですか？
鈴木：たとえば複雑で間違えたら致命的になるような部分が該当します。
ゲームでいえば、インゲームと呼ばれるところ、バトルのコアになるロジックです。たとえば「最初の1ターンで相手を殲滅できる」のような1ターンキルが起きうると、ゲームの面白さやフェアネスを台無しにしかねません。一度機能が出てしまうと修正も難しいですしね。
こうしたインゲームの部分は、不備のないよう、多少時間をかけてでも、形式仕様記述にするメリットは大きいと思います。
一方で、「このボタンを押すとこうなる」といったアウトゲームの仕様は、仮に欠陥があったとしても致命的になることは少ないので、形式仕様記述は適用しないといった判断をすることが多いです。
――興味深いですね。ただ野暮なことを聞くと、形式仕様記述だとあまりにクリアに仕様が伝わりすぎて、開発側の自由度がなくなるというか、息苦しさみたいなものは生じないのでしょうか？
鈴木：あ、それは逆というか誤解ですね。形式仕様記述が表現するものはあくまで仕様です。実装は仕様を満たしさえすればどのように実装しても構いません。書かれるべき仕様がどれだけ明確に書かれているかはご懸念の点と関係ないと思っています。
――なるほど。現場の開発エンジニアの方々から、積極的に形式仕様記述を使っていきたいという声はあがっているのでしょうか？
鈴木：残念ながらそこまでは……というのが正直なところです（笑）。やはり見慣れないものだし、学習コストのハードルも高い。
ただ、仕様における抜け漏れ、伝わりにくさに課題を抱いている開発者の方は少なくないので、少しずつ啓蒙しているところです。
また、そもそも私たちが手掛けているのは形式仕様記述だけではないので、他のアプローチでも仕様における品質改善を実践しています。
伊藤：あくまでわたしたちのミッションは「仕様書の品質改善」です。そのひとつの強力な武器として、形式仕様記述があるわけです。
学ぶためのカリキュラムは充実。意欲のある方に参加してほしい！
――たとえば仕様におけるどのような部分を改善させていくのでしょうか？
伊藤：事業部によっては開発のプロセスそのものが明確になっていないところがあります。そうしたチームには開発プロセスを可視化するお手伝いから実施しています。
鈴木：開発プロセスが明確になってようやく仕様書を書き上げるプロセスについて提案ができます。地道な作業をしていますね（笑）。
あるいはすでに運用中のプロジェクトに対して、複雑で把握するのが困難な仕様があれば、「この部分を形式仕様で記述しなおしませんか」といったアプローチもしています。
――そうした活動から、少しずつDeNA内で形式仕様記述の良さを感じ、興味を持つ人が増えている感じでしょうか？
鈴木：まさにそうで、DeNAには手を上げると他部署と兼務ができるクロスジョブ制度があるのですが、その制度を使って今年1月からSWET第一グループにジョインしてくれる別部署の仲間が入りました。
第一グループで手を動かしながら形式仕様記述を覚えた後、戻って自分の持ち場でそれを広めてくれるような、そんな循環を狙っています。
――どんな人にこれからSWET第一グループの仲間になってほしいですか？
鈴木：そうですね。まず形式仕様記述という、なかなか学べない領域に挑戦する気持ちと、学ぶことへの貪欲さはあったほうがいいかなと思います。
伊藤：そうですね。あとは個人的には開発などを手がけるなかで「何がボトルネックなのか」「改善点はないか」と、そうした視点がある人は向いている気がします。
鈴木：この領域に馴染みのない方でも受け入れています。しっかりと形式仕様記述をはじめ業務をする上で必要な知識・スキルを学ぶためのカリキュラムも用意しています。興味と意欲がある人なら、ぜひジョインしてほしい。
社内も社外も問わず、仕様の品質が大事だという理解と品質を守るためのアクションをひろめていきたい。また、仕様書やプログラムが美しく整理されていく気持ちよさを多くの方に実感してもらいたいです。ひいてはそれがすばらしいサービスづくりにもつながっていますしね。
※本記事掲載の情報は、公開日時点のものです。
※本インタビュー・撮影は、政府公表のガイドラインに基づいた新型コロナウイルス感染予防対策ガイドラインに沿って実施しています。
執筆：箱田 高樹 編集：フルスイング編集部 撮影：小堀 将生
