元々は非エンジニア　現在は大学のWeb出願システムを開発

私のキャリアの始まりはエンジニアではなく、財務・会計パッケージの品質管理を担当していました。ただいずれはエンジニアになりたいと思っていたこともあり、紙ベースで判子を回していた品質管理の承認を効率化するシステムを自力で開発し、それがきっかけでプログラミングに関わっていくようになりました。

その後は数社で経験を積んだのですが、特にソーシャルゲームの会社で16チームをマネジメントした経験は今でも活きていると思います。

2013年5月にヒトメディアに入社したのですが、その背景にあったのは個人的に「Gamification（ゲーミフィケーション）」に関心を持っていたことです。日常生活の様々な要素をゲーム化する、ということですが、ITと教育、そしてGamificationを組み合わせたら面白いのではないかと。

勉強ってもともと退屈なものじゃないですか。楽しんでそれをできる人が強いんだと思うんですね。そこでヒトメディアが教育の事業を展開していることもあって、入社を決めました。

現在は、apply japan.comという大学のWeb出願システム開発に関わっています。昨年は某有名私立大学の一般入試にも採用され、出願者約3万人、決済総額10億円超える規模になりました。

この出願システムの開発で難しいのは、大学ごとに細かい要件が異なるため、共通化できる部分が少ないことです。また個人情報を扱うので、弊社でも地下2階にセキュリティルームを設けるなど、セキュリティ対策を行っています。

コード品質を可視化したい！選んだのは「Scrutinizer」

開発チームは日本側とベトナムのオフショアに分かれていて、全部で20名ほどです。大学によって要件が異なるので、縦割りのチームで動いています。前述した私立大学の場合は、3名で開発していました。

私の役割は、全体のアーキテクチャーを作るところや、開発環境を整える部分。それからビジネス面では、お客様とコミュニケーションをとったり、見積もりをしたり、といった部分を担っています。

開発チームに関して以前から課題意識を持っていたのは、コード品質を可視化できていなかったことです。いわゆるレガシーなコードが存在するので、その危険度や健康具合を掴んでおきたかったんですね。

品質の悪いコードを、どこから直せば効率的なのかも知りたいと思っていました。また、ベトナムを含めて業務委託の方もいらっしゃるので、エンジニアのスキルに個人差が出ていて。エンジニアの評価という面でも、良し悪しをきちんと評価するようにしたいと考えていました。

更に、PHPを使って少人数で開発しているとありがちかもしれないのですが、テストを書く文化が浸透していなくて。そこにも困っていたので、CIツールの導入検討もしていました。この、コード品質の可視化とCIという両方の役割を担うツールとして、2015年3月に導入したのが「Scrutinizer（スクリューティナイザー）」です。

プルリクエスト単位でコード品質を評価する

Scrutinizerは、コードの静的解析、点数化、CIの機能を持ったツールです。他にもCircleCIのようなツールも検討したのですが、カバレッジの算出にはCoverallsを組み合わせる必要があったり…。その点、Scrutinizerのいいところはまさに一気通貫という部分で、これひとつに必要な機能がしっかりと揃っています。

導入は非常に簡単で、Gitで管理しているレポジトリがあれば自分のリポジトリに.scrutinizer.ymlという名前で設定ファイルを作成しレポジトリにpushするだけです。あとは変更があるたびにコードの静的解析が実行されます。プロジェクト単位で10点満点でスコアが算出され、さらにファイル単位でもA〜Fの評価がつきます。

▼プロジェクト単位で10点満点、ファイル単位でA〜Fの評価

非常に良いのは、プルリクエスト単位でも評価が出るところです。トピックブランチにプッシュするだけでScrutinizerが走り、「このプルリクエストによってファイルの評価がAからBに下がった」というようなことが毎回分かります。この、プルリクエストから結果が見られるという点は非常に良いですね。

▼プルリクエスト単位でファイルのスコア変更を可視化

「チェックしたい」と思わせる、見やすいUIが素晴らしい

Scrutinizerの良いところは、ダッシュボードが非常に分かりやすいことです。コードの解析や点数化自体を行うツールは他にも多くありますが、ここまで綺麗にグラフになるものってなかったので。*チェックしたいな、と思わせるUIになっているんですよね。

ツールって見た目も大事だな、と改めて感じています。*今では月に一度の全社共有会でも、Scrutinizerの各種統計を使ってレポーティングしています。

▼見やすいUIのScrutinizerダッシュボード

ダッシュボードに限らず、他の画面も分かりやすいですね。例えば「Issues」の画面には、問題のあるファイルが一覧で表示されていて、様々な観点からコード品質をチェックすることが可能です。

バグが多いもの、コーディングスタイルに問題があるもの、それからduplicate code（重複コード）。似たようなコードが複数の箇所にあるので、ひとつにまとめられないか、という指摘です。

▼問題のあるファイルが一覧表示される「Issues」

duplicate codeは、人がコードレビューをしても気が付くとは限りません。それに自分が書いたところは綺麗に作ったつもりでも、問題のあるソースをコピーしてしまったためにコードの点数が下がるケースもあります。その場合に、Scrutinizerであれば機械的に、悪い部分をしっかりと特定できます。

まさにGamification！コードの点数を上げるモチベーションUP

Scrutinizerのスコアが悪い時には、必ず病巣があります。それがしっかりと可視化されることで、プロジェクト全体のコード品質を高めていくことができるようになりました。また、悪いところが見つかった時に、そこをピンポイントで直すのか、捨てるのか。全体とのバランスで判断できるようになりましたね。

また、スコアリングされることで、なんとなくコードを良くしたくなるんですね。実際に私も、Scrutinizerを導入したばかりのころは「どうやったら点数が上がるんだろう…？」という感覚でけっこう夢中になって直しまくっていたこともありました（笑）。

他にもけっこう遊び心があって、Issueを修正すると「Good job」とさりげなくほめてくれたり。こういった部分はまさにGamificationに通じるところなので、結構気に入っています。

「コード品質の可視化」 = プロダクト全体の品質を保つため

Scrutinizerの料金はコンテナ単位で、BASICというプランで月額49ユーロです。これで約20名のチームで活用できているので、コストパフォーマンスはかなり高いと思います。 PHPで開発している現場で、レガシーなコードもあってテストを書く文化がない、という話はよく聞きます。

そういったチームでGitで管理しているレポジトリがあるのであれば、まずは登録して試してみてもいいのでは、と思いますね。

結果的に、スコアリングによってコード品質を高めることができましたが、はっきりと「何点以上にしましょう」ということを決めているわけではありません。やはり動く機能を作ることが最優先なので。

基本的には点数が下がらないようにしながら、バランス重視で考えています。 プルリクエストもランクがCだから通さない、ということではないです。テストがこけるようであれば修正が必要ですが、そうでない場合にScrutinizerのスコアを理由にレビューで落とすようなことはしていません。

コード品質を可視化することの目的は細部にあるのではなく、プロダクト全体で一定のクオリティを保つ、ということです。

以前は「もうちょっとコードを綺麗にできるはずだ」と思っても、根拠に乏しかったですし、品質のチェックは人任せになってしまっていた部分があったんですね。一体どれだけ悪いのか、ということもはっきりとはわかりませんでした。

そこが可視化されたことは、良いプロダクトを作って行くために本当に大きかったと思っています。（了）