こんにちは、ドリコムでエンジニアをやっている Smith (@do_low) です。
今回はドリコム社内で行われたエンジニア勉強会の様子をお届けします。

今回の勉強会

• 割とカジュアルに始まった
• 複数職掌合同で開催した
• LT枠が埋まった

本勉強会は「エンジニア勉強会」と題したエンジニアが対象の勉強会です。
きっかけは、 QAエンジニア(以下QAE) としての活動を行っている @grem_ito の「QAE活動報告がしたい！」という要望によるものでした。
ドリコムでの社内勉強会などの実施は誰でも自由に行うことができ、今回の勉強会も会場予約と社内イベント管理ツールへの登録、の2ステップでの実施となっています。
当初はエンジニアリングに関する発表のみを予定していましたが、QAE という役回りは弊社の部門では品質保証部に近しいので、「せっかくだし面白そうだから品質保証部も一緒に勉強会やろうぜ！」というノリで声をかけ、そのノリのまま合同で登壇する運びとなりました。
今回の勉強会で予め決まっていた登壇者は2名のみでしたが、イベント告知後より募集したLT発表枠にも複数名が集まるなど、熱量の高い勉強会となりました。

1部:品質保証部の活動について

1部は品質保証部の長坂が下記のアジェンダに沿って発表しました。

▲通年タンクトップの長坂

• ”品質保証”ってなぁに？
• QCとQAの職務とは？
• ドリコム史～品質保証編～
• QAの苦しみ～プロダクト間の差分～
• QAの理想～プロダクト間の差分～
• 困ってい「た」事例

品質保証部による対エンジニア向けの発表ということもあり、普段の業務上では改めて聞く機会の少ない品質保証部の定義や役務について触れてもらいました。
ドリコムではコンスタントに中途採用を行っていますが、その副作用として従業員の「ドリコム歴」の長短がまばらになっていることもあり、3つめの「ドリコム史～品質保証編～」は他職種理解という意味では非常に興味深いものとなりました。 4,5 の QA の苦しみと理想については、読者においても気になる内容かと思いますので一部を抜粋して紹介させていただきます。

QA チームが困っていることを一言で言うと、プロジェクト間の差分が多くてツライ。

• マスターデータが異なる
• ブランチ戦略が異なる
• 準備しているサーバが異なる
• 管理画面仕様や要件が異なる
• お知らせミスの対策が異なる

いかがでしょう？
同業種にとっては非常に耳の痛い話もあるのではないでしょうか。
他職種理解の観点では、実際に困っていることを共有してもらうことで「たしかにこれは辛いなぁ」という気付きが起こりました。
これに対して、理想の状態も提起されています。
基本的にはいずれの項目に対しても全社標準規格などが求められていました。
今回の発表では品質保証部の取り組み全般を網羅した内容となりましたが、勉強会参加者のエンジニアや品質保証部のメンバーが、よりお互いが幸せになるような仕事が意識できるきっかけになったと思います。

2部:QAE活動2018下期ふりかえり共有

2部はゲーム事業本部の @grem_ito による QAE 活動の振り返りでした。

▲QAE の @grem_ito

• エージングテストのマイル1完了の共有
• ゲームプロダクトの改善チームでの取り組みについて
• 2018下期の取り組み
• 今後について

直近でプロジェクトとして進めていた開発の共有から始まり、「ゲームプロダクトの改善チームでの取り組みについて」では実際の改善事例の紹介が行われました。
その一つとして「JSON 翻訳ツール」が挙げられています。
ゲームでは、キャラクターのパラメータなどが定義されているデータとして「マスターデータ」と呼ばれるデータを作成し、利用しています。
このマスターデータは、今回紹介された事例では JSON 文字列で表現されており、人間が読むデータとして見た場合は可読性の低い部類に入ります。
マスターデータは読み取るだけでなく、データの追加や更新も発生するものであり、データを JSON 形式のまま人の手で編集しようとすると当然のようにデータ不具合のリスクが高まります。
また、マスターデータのようにシステムで扱うデータはほぼ英数字で表記されており、例えばRPG のキャラクターのスキルなどを表現する際には、それがどのようなスキルかを直感的に理解させることには不向きです。
下記はマスターデータ定義の一例ですが、よほど慣れている作業者でも読解が困難でしょう。

<br>
[{”type”:9,”slots”:[98],”target_self”:1}]<br>

そこで、JSON のキーや値を人間に読みやすいように翻訳するためのツールが開発されました。
このツールは単に JSON のキーを読みやすい論理名称に変更するものではなく、値も含めたセマンティックが人間に通じるように翻訳されます。
以下は先程挙げたデータの翻訳例です。

<br>
自分は「剣」装備枠を炎属性にする<br>

この変換処理一つだけでもマスターデータ追加や更新作業の事故リスク低減に繋がることは想像に易いでしょう。
このような縁の下の力持ち的なツール類の紹介の後、 QAE の半期の活動の振り返りを下記の項目で締めくくっています。

• 不具合を防ぐ取り組みはデータが作られる時、または作られた直後に実施すると良い
• オートメーション化できる作業とできない作業がある
• 無理にツールで解決しようとしない

特に３つ目は、QAE という職能においてエンジニアリングが得意分野であるが故に留意しておくべき点ではないでしょうか。
弊社ではまだまだ QAE の役割を担うエンジニアは多くはありませんが、その活躍の幅も広いと思われます。 その後は LT 枠の発表もあり、本会は盛況の内に閉会しました。

まとめ

今回の勉強会のまとめです。

• 職掌問わず勉強会を開催、参画できる
• 困っていることを共有しあえる
• QAE の取り組み共有が行われている

本記事ではドリコムのエンジニア勉強会をピックアップしましたが、ドリコムで行われる勉強会がどのようなものか、また、その雰囲気が読者の皆様にも伝われば幸いです。
今後もなにか勉強会ある度に、レポートしていこうと思いますのでよろしくお願いいたします。