スクーティー社の技術に対する取り組み

3/10/2017

スクーティー社の技術に対する取り組み

本記事では、技術に対する弊社の価値観や取り組みをご紹介したいと思います。もし弊社の働き方や環境、方向性などをイメージしていただけると幸いです。

※本記事は、英語版スクーティーブログの翻訳版です。

Scutiは、東南アジアの人生を変えることができるWebサービスを提供する使命を持っています。

半期のスローガンは「ベトナム代表」です。

これは、ベトナムだけでなく世界に向けてサービスを提供するためには、開発に携わる各々のメンバーも世界トップレベルのプロフェッショナルで働く気概を持とうという願いを込めています。トップレベルのエンジニアたるために、我々は下記に述べるような価値観を大切にしています。

先にまとめると、下記を大切にしています。

開発プロセスを出来る限り自動化し、ソフトウェア開発に時間を割くことに注力します。
ツール類を駆使してソフトウェアの品質を担保します。
う●こコードは決して本番サーバにデプロイしません。
ユーザのために働きます。

PHP/Laravelフレームワークに注力

我々のコア技術はLaravelフレームワークです。モダンなPHPフレームワークの一つです。
レポジトリパターンをLaravel上に実装したものをフレームワークとして使用し、CRUD機能をPHPUnitのテストコードとともに効率的に実装します。

新しい技術やツールを積極的に使用します

弊社には主に2つの事業があります。受託開発と自社サービスです。各々、技術面では下記のように補いあっています。

受託開発では、使用する技術は基本的にお客様に依存します。したがって使用する技術領域は自社サービスよりも広くなる傾向にあります。
自社サービスでは使用する技術は自分たちで選択出来ます。機能拡張も自分たちでやります。したがって技術領域は受託開発よりも深くなる傾向にあります。

この2つの事業により、弊社のエンジニアは広く、深い技術領域を経験出来ます。

自社サービスにおいては、積極的に新しい技術やツール類を使用するようにしています。下記に一部を紹介したいと思います。

Vagrantでローカル環境を構築

プロジェクト開始時に開発者はVagrantでローカル環境構築し、Vagrantfileを生成します。これによりほかのプロジェクトメンバーとも全く同じ環境を共有でき、一瞬で環境構築が完了します。

Github、Trello、JenkinsをSlackと連携

全てがSlackと連携されており、Slackにあらゆる更新情報が通知されます。メールはほとんど使用しません。チームメンバー同士のコミュニケーションは高速に進められます。これにより、コミュニケーションそのものに割く時間を極力短縮し、アプリケーション開発に注力できるようになっています。
最近FirefliesというSlackのプラグインを導入しました。これはAIでSlack上でのチャットを分析し、簡単なアクションでToDo管理できるというものです。チケットで管理しづらい細かなタスクの漏れを防ぐのにかなり便利です。おすすめです。

サーバ環境はAWS

我々は基本的にサーバ環境をAWSで構築します。AWSでのサーバ構築、共有は非常に簡単で、環境構築に割く時間を短縮出来ます。また、冗長化構成も非常に簡単に構築出来ます。

セキュリティの解析や担保はvulsとVAddyを使用

セキュリティの高いアプリケーションを構築できることは、エンジニアとして重要なスキルの一つです。一般的なセキュリティ対策はフレームワークでカバーしていますし、テスト項目にも入れていますが、最終的なチェックはvulsやVAddyを使用し、定点観測するようにしています。

柔軟なScrumプロセス

弊社では主にScrumプロセスを適用します。これは、メンバーのアサインを受託開発と自社サービスの両方で柔軟に行うことが目的です。各メンバーはScrumプロセス上でタスクの調整を自分自身で行っています。

Scrumを取り入れることのメリットは下記の点だと理解しています。

チームメンバー全員で、誰が何をやるのかを共有できる。
潜在的な課題を事前に検知することができる。
改善を仕組みとして継続できる。

ハイブリッド型（？）レトロスペクティブミーティング

各スプリントの最終日にレトロスペクティブミーティングを開催します。我々はレトロスペクティブミーティングのやり方そのものもより効率的なものを追求し、改善してきました。結果、アジェンダをプロジェクターで移し、各人の意見を付箋で該当箇所にどんどん貼っていくという、上記の写真のような方法を現在はとっています。これにより生産性や効率を上げる改善案がより多く集まるようになりました。我々は自分たち自身に決して妥協しません。

CI/CDベースの自動化した開発プロセス

ソフトウェア開発そのものや品質の担保に時間を割くために、ソフトウェア開発プロセスを出来る限り自動化しています。

ブランチをマージする度にJenkinsのビルドスクリプトが実行され、code fixerやコードの重複度や循環複雑度といった静的解析が実行されます。これらのスクリプトがもしパスしなかった場合は、その時点でビルドスクリプトは停止し、エラーの結果がSlackに通知されます。もしパスしなかった場合はう●こコード認定され、上記のような通知のされ方をするので恥ずかしいです。このようにしてう●こコードがマージ、或いはデプロイされることを防止しています。
全てのスクリプトがパスすれば自動的にデプロイされます。現状は自動デプロイはステージング環境のみで、本番へは事故防止のためにマニュアルでのデプロイをしています。

ソースコードの品質担保

ソースコードの静的解析だけでなく、ソースコードレビューがプロセスに組み込まれています。レビューを通らないとソースコードをマージできません。レビューにより、不適切な変数／関数名やマジックナンバー、メソッドの不適切なクラスへの追加など、静的解析で検知しづらい低品質コードを出来る限り排除します。
一般的な企業では、コードレビューはリーダー格以上のメンバーがやると思いますが、弊社では全員がお互いにレビューし合います。これは別の開発者がどのような機能をどの様に実装したかをみておくことで属人性を減らしておく目的と、学習のためです。他人のコードを読むことで、今まで知らなかったコードの書き方の「気づき」を得る機会になっています。

ユーザのために働く

我々はあくまでもユーザのためにソフトウェアを開発します。自己満足であってはいけません。また、お客様のためでもありません。あくまでもユーザのためです。ユーザのために素晴らしいソフトウェアを提供することがエンジニアとしてのアイデンティティであると信じているためです。我々は常に、それはユーザのためなのか？を問い続けます。例えお客様からの指示であっても、それがユーザのためになるかどうか疑問な点があれば、意見をさせていただくこともあるかもしれません。その代わり、ユーザにとって最高のソフトウェアを一緒に目指すスタンスで働きます。