はじめまして、2021年に新卒としてSWETに加わったIKです。今回はSWETに入って感じたこと、思ったことなどを新卒目線で書いていきたいと思います。

IKってどんな新卒？

学生時代にVim scriptばかり書いていた新卒です。主に、ソフトウェアのメンテナンスに興味をもち、OSSにパッチを送る活動をしていました。

パッチを送った主なリポジトリ

また、VimConf2019に登壇し、以下の発表をしました。

Grown up from Vim User to Vim plugin developer side

しかし、一般的なWebシステムやアプリ開発には疎い、そんな状態で入社しました。

どうしてSWETへの配属を志望したのか

私は学生時代、1からソフトウェアを作ることよりも、ある程度形になったソフトウェアのメンテナンスに参加することの方が多かった傾向にあります。そこで行ったメンテナンスの内容を以下に示します。

具体的なメンテナンスの内容
- バグの修正
- feature requestに応える
- パフォーマンスの改善
- Pull Requestのレビュー
- 既存のドキュメントの改善

ソフトウェアのメンテナンスに参加することで、メンテナンスのフェーズは1からソフトウェアを作成するフェーズよりも遥かに長いこと、メンテナンスを継続することはとても大変であることを思い知りました。その経験から、ソフトウェアのメンテナンスの負担を減らすこと、開発時に発生する手戻りを減らすことはソフトウェア開発が行われる限り常に要求されることだと考え、それらに興味を持つようになります。その私の考えがSWETのミッションとマッチしていると考えたため、私はSWETへの参加を志望しました。

SWETのミッション

ソフトウェアテストを起点とし、DeNAのサービス全般の品質向上とエンジニアの開発生産性向上に対して貢献していくことをミッションとする

SWETに配属されてどんな仕事をしているのか

Unityプロジェクトに導入するための静的解析器の開発をしています。 C#向けの既存の静的解析器はいくつかOSSとして公開されていますが、以下の理由により自作する必要があります。

社内独自フレームワークに起因する問題を検査できない
既存の静的解析器のルールでは、検出したい問題を見逃してしまうことがある

では、自作の静的解析器を作成するために行った/行っているフローを以下に示します。

診断の対象を決める
- ECMA334やMicrosoft社のドキュメントを参考に、C#の構文を調べながら、診断の対象になるものを決めて、洗い出す（ここが一番大変）
仕様をデシジョンテーブルにまとめ、テストケースを洗い出す
作成したデシジョンテーブルをもとにテストコードを1件ずつ追加
静的解析器を実装し、テストを通す
3に戻る

静的解析器を開発プロジェクトで使ってもらうためには、適用する開発プロジェクトの人の信頼、すなわち静的解析器に対して好印象を持って貰う必要があります。そのため、正確に静的解析ができているかを検証し、証明するためにテストを書くことは重要です。

要約すると、テストのノウハウを学びつつ、静的解析器を実装する仕事をしています。

SWETの人たちが、新卒目線でどう見えるか

ミスを未然に防ぐことや手戻りを防ぐことに意識をおき、そういった可能性がある箇所に対しての改善を妥協しない人が多い印象です。特にメンターから教わったことの中から印象に残ったものを以下に示します。

テストメソッドの命名をしっかり意識する

SWETにjoinする前の自分は、テストメソッドの命名が雑でした。極端な例を出すと、goodcaseとかbadcaseなどと言った命名をしていました。

FizzBuzzを使った例

[TestMethod]
public void GoodCase()
{
    var actual = FizzBuzz(3);
    Assert.Equal("Fizz", actual);
}

このように、テストメソッドの命名が雑だと以下のようなデメリットがあります。

テストが失敗したとき、失敗したメソッド名やメッセージを見ただけでは失敗箇所の特定が行えず、深くコードを追う必要がある

そこで、テスト対象メソッド名_テスト対象に与える条件_期待する結果のような命名を意識しました。

[TestMethod]
public void FizzBuzz_入力値が3_Fizzを返す()
{
    var actual = FizzBuzz(3);
    Assert.Equal("Fizz", actual);
}

これにより、上記のデメリットを解消できます。

テストの無いリファクタリングはリファクタリングとはいわない

この言葉は自分にとても刺さりました。リファクタリングとは、プログラムの外部から見た振る舞いを変えずに、内部構造を変えることだとした上で話しを進めます。

テストを書き、実行することで、リファクタリングを試みた際に発生したリグレッションを検知できます。しかし、当時の自分は自動テストを実施せずに目視のみの確認でリファクタリングを完了としていました。そのため、抜け漏れが発生し、リグレッションを起こしてしまったことが多々ありました。

リグレッションを放置していると、ボディーブローのように後々効いて、気づいたときには巨大なバグになっていることも少なくありません。こういった状態を作らない、妥協しない姿勢をSWETの方から見習い、吸収していきたいと思いました。

新卒でSWETに入って良かったと感じたこと

テストケースの考え方や、テスト自動化の導入方法は、どんなソフトウェア開発にも必要です。また、テストを導入するためには、テストを導入しやすい環境を作らなければなりません。

これらのテクニックは、これからも陳腐化することはないスキルだと自分は確信しています。そういった潰しの効くスキルを基盤として身につけながら業務に携わることができてとても良かったと感じています。

また、こういったテスト技術を基盤として様々なソフトウェアに関わることで、様々なソフトウェアの知識を吸収ができるのも良さだと考えています。

終わりに

新卒でSWETに入って、うまく仕事を遂行できるか不安ではありましたが、毎日新しい発見がありとても学びになっています。また自分の施策が、ソフトウェア開発を促進するための施策に関われていることを実感でき、今の仕事にとてもやりがいを感じています。新卒でSWETに入ったことを自分は正解だと感じており、今後もSWETで学んだことを様々なソフトウェア開発の促進のために生かしていきたいと考えています。

SWETは中途しか採用していないイメージを持たれている方が多いのかも知れませんが、新卒で入ることも可能です。SWETは学びが多い部署だと思っているので、新卒でSWETに入る選択もありだと思います。もしSWETに興味を持った方がいれば、是非お話しましょう！