こんにちは。SideCIの角です。
オフショア開発を運用している中で、「コードの品質が低い」「いちいち英語で指摘するのは面倒…」と思っているプログラマ・ディレクターの方のお声をお聞きします。
他にも、社内のプログラマから「オフショアは上がってくるコードが汚いからやりたくありません！」みたいな声とオフショア開発現場と板挟みになってしまっていたりする方も。。
私自身、中国に発注していた時には毎日変更依頼をメール、メール、メールしていた記憶があります。
今日はオフショアラボを数年間運営しているチームでの日本のエンジニアの品質へのこだわりとオフショアチームとの取り組み事例をご紹介させて頂きます。
品質といえば「仕様通りか」と「セキュリティ」「可読性」「保守性」など色々ありますが、「仕様」についてはまた別の記事で紹介させて頂きたいと思います。今回はコードレビュー編ということで、コードをレビューするときに気になる部分の品質についてです。
とあるベトナムと日本のエンジニアの品質の考え方の違い
日本のエンジニアとベトナムのエンジニア、もちろんその他の国も、国によって文化が違います。文化が違えば、品質への考え方も違います。国だけじゃなくプロジェクトの規模などによっても「品質」の定義はまちまち。
以下の様な「日本と比べて…」を聞いたり、言ったことがあったりしませんか？
- 「ベトナム人はセルフチェックの習慣がない、ミスに気づかないままコードが上がってくる。かっこ(ブロック)のとじ忘れがあることも」
- 「英語版のファイルだけ書いてきて、日本語のファイルが欠けてて日本側で動作確認出来ない」
- 「ベトナム語でコメントを書いていてまったく読めない！」
もちろんオフショアに限った話ではないですが、日本のエンジニアが憤慨してしまうこともしばしば。その度に英語で修正の依頼をするのは大変！(日本語でも十分面倒です)
設計やロジックが良い、実装が早い、仕様通りにすぐ作ってくれる。
そんなメンバーでもオフショアチームでは問題なく動くコードだったり、動くからOKということで日本のエンジニアからすればNGなコードが上がってくることも多々あるようです。
既にオフショアを上手く運営できている会社さんの多くも、最初はこういった問題に遭遇したとお聞きします。その上でどのように改善したか聞くとだいたい次の3つのステップで解決や緩和が出来るそうです。
- 日本のエンジニアのこだわりの「品質」を定義する
- オフショア側のエンジニアと品質の定義を共有する
- 定義を仕組み化する
日本のエンジニアのこだわりの「品質」を定義する
問題が起こる度に指摘してオフショア側に合わせてもらっていては、お互い大変。
それに、都度指摘して形成出来た「品質」は属人的で、メンバーの出入りがあるとあっという間に崩れてしまいます。
そのためにまずは「品質」を定義する必要があります。
「最低限、こんなコードを書こう。こんなコードはNG」
「コメントは100%英語で書くことにしよう」
「1ファイルは1000行までにして、メンテナンス性を高く保とう」
などなど。
まずは日本側からこれをディスカッションし、日本チーム内で合意形成しましょう。
オフショア側のエンジニアと品質の定義を共有する
日本チームで合意形成出来た品質の定義を英文にし、オフショアチームに共有しましょう。
必要に応じて、中国語チームなら中国語、ベトナム語チームならベトナム語など。
ただし、品質の定義はプロジェクトの進行度合いによっても変わってきます。
全チーム共通で英語でも良いかもしれません。
「共有」といってもメールで送るだけではNG.
オフショアチームから追加したい品質項目を聞いたり、逆に、今のプロジェクトの状態では妥協したほうが良い、スピードを優先した方がいい、といった理由から品質の定義から除外や妥協する内容もあるはず。Skypeやapiary, Google Hangoutなどを使ってディスカッション、すり合わせをしましょう。
定義を仕組み化する
品質の定義を紙に印刷して貼りだす？デスクトップに保存していつも見られるようにする？
品質を常に心がけるための方法はいくつもあります。チームに合ったものを選択しましょう。
わたしがよくきく&おすすめする方法は「仕組み化」「プログラム化」です。
仕組み化とは？
品質の定義をプログラミングし、コードを自動的にチェック、品質の定義違反を常にアラートを出すような仕組みを作ります。すると、品質の定義違反はゼロにキープしたり、悪化を防ぐことが出来ます。
仕組み化の具体的な方法
ゼロから仕組みを作ることは開発コスト上なかなか現実的ではありません。いくつかの既存のソフトウェアがあるので、それらを活用する方法がおすすめです。
品質の定義とチェックのためのソフトウェア
各プログラミング言語ごとに様々なソフトウェア・ツールがあります。
これらを使うことでプログラマブルにコード品質をチェックすることが出来ます。
品質の定義が変わった時には設定ファイルを変更することで追従出来ます。
- コーディング規約のチェック
- RuboCop(Ruby), PHP CodeSniffer(PHP), flake8(Python), CheckStyle(Java)
- セキュリティスキャナー
- Brakeman(Ruby on Rails)
- バグの検出
- pyflakes(Python), FindBugs(Java), Infer(Objective-C, Android Java)
- プラクティスの共有
- rails_best_practices(Ruby on Rails), Android Lint(Android)
- 設計への示唆・スメルチェックツール
- PHP Mess Detector / PHPMD(PHP), PMD(Java), Reek(Ruby)
チェックの自動化の仕組み
先に紹介したツールはすべてローカルPC(お使いのPC)にインストールして実行出来ます。
コードを書く度に都度実行すればそれで問題ないですが、全部のツールを１個ずつ実行したり、保存の度に実行するのは非常に面倒です。自動化の仕組みを導入しましょう。
自動化の仕組みを4パターンご紹介、それぞれのメリット・デメリットを一言ずつ。
- ローカルPCとエディタ連携
- Jenkins上での実行とグラフ化
- テストのためのPaaSを使った自動実行
- コードレビューのためのPaaSを使った自動実行
ローカルPCとエディタ連携
Vim, Emacs, Atom, RubyMine, Eclipse, Android Studioなど各種のエディタで各種のソフトウェアと連携するためのプラグインがオープン・ソースで提供されています。
開発メンバー全員がこれを導入し、ローカルでチェックするようになると、とても早いです。
テストと違って解析は処理量・処理時間もさほど大きくないので、非常におすすめです。
難点は開発メンバー全員が導入しないといけないことです。誰か１人でもやらない人がいると誰もやらなくなっていってしまいます。
Jenkins上での実行とグラフ化
GitHubやBitBucketと連携したJenkinsを構築するのも一つの方法です。
各種のツールを実行するためのプラグインも充実していますから、プラグインをインストールし、ビジュアライズ(グラフ化)用のプラグインと組み合わせ、警告数を常にチェックすることが出来ます。
デメリットは「Jenkinsを見に来る人がはたして何人いるか？」です。多くの方はわざわざブラウザを開いてjenkinsの実行結果を見に行くことはしません。
たとえば、１件以上の指摘が出ていればGitHub上でのStatusをFailedにし、マージしづらくしてしまえば見に来るかもしれません。ただし、それは厳しすぎ、疲れてやめてしまったというケースをお聞きすることがあります。
テストのためのPaaSを使った自動実行
テストのためのPaaSであるCircleCI, Wercker, Travis, Shippable, CodeShipなどを既に導入している方も多いのではないでしょうか？
これらのPaaSの中で解析ツールを実行することも出来ます。何もツールを足すことなく実行出来ますし、全員に同じ環境を提供でき、導入コストも低いです。
デメリットは初期コストや実行時間です。解析用のツールはPaaSのコンテナの中にはインストールされていませんから、コード更新毎にそれらをインストール、解析する必要があります。インストールしたツールをキャッシュさせておくこともサービスによっては出来ますので軽減出来ます。
また、実行結果の出力方法(見る場所)も問題です。解析処理の実行結果をFailedにすればGitHubなどに通知され、皆が見に来ますが、それは厳しすぎるかもしれません。別の出力方法として、結果をSlackやHipChatなどのチャットサービスに通知することや、GitHubに指摘結果をコメントするためのコードを書いて同梱することなども良いかもしれません。これらをやっていらっしゃる方や、そのためのソフトウェアもいくつか存在します。
コードレビューのためのPaaSを使った自動実行
2014年ごろからコードレビューのためのPaaSサービスがいくつか登場しました。これらを使うと数ステップで自動的な解析の仕組みを構築でき、また、結果を容易に受け取ります。
ここでは3つほど紹介します。
- SideCI
- HoundCI
- Code Climate
SideCIは私たちが開発しているサービスで、15種類以上の解析用のソフトウェアをホスティングしています。30秒ほどでセットアップでき、結果はGitHub PullRequest上で受け取れます。また、プロジェクト全体の品質の状態(警告数)を確認することも出来ます。
HoundCIはオープン・ソースで提供されているソフトウェア及びクラウドサービスです。昔に書いたコードはチェックしないポリシーで、SideCIよりも数秒単位ほど実行速度が早いのが特徴です。また、オープン・ソースであるため、オンプレミスで使うことも可能です。8種類の解析用ソフトウェアがホスティングされています。
Code Climateはこれらの中で最も古くからあるソフトウェアです。前述の２サービスが月額$15以下なのに対し、$99からと少し高額です。ただし、コードの重複度などをスコア化するなど、既にあるコードを綺麗にしていきたい、常に最高にクリーンな状態に保ちたい、という方におすすめです。
Code ClimateはPaaSよりはSaaSに書く、独自のスコアリング、解析部分が多くあります。その反面、「自社の品質を定義する」という目的にはあまり即していないかもしれません。
まとめ
オフショアラボのエンジニアと、日本のエンジニアの品質の考え方は違います。
これはオフショアに限らない話ですが、文化が違う分、日本人同士よりも大きな差が出ます。
この違いをスムーズに吸収する、コミュニケーションコストを落とす、高い品質に保つためには、「品質」の定義のすり合わせが必要です。
まずはプロジェクトオーナーである日本側で品質を定義し、共有し、合意する必要があります。
品質の定義は作るだけでなく、作成後、定義に沿っているかチェックし、警告を出し、常に守る文化・チームを作ることが重要です。それを自動化するためにはいくつかの方法がありますが、私たちのおすすめはSideCIなどのコードレビューのためのPaaS(SaaS)サービスを使うことです。これらを使うと短時間に仕組みを構築できます。また、仕組みを構築する前にも、試しに使ってみることで、現状を知るのに役立つかもしれません。
ぜひ品質について、エンジニア間ですりあわせ、定義してみてください。
