会社概要

  • 今回ご協力頂いた企業:株式会社クラウドワークス
  • ご利用人数:約30名
  • ご協力いただいた方:CTO 弓山彬さま エンジニア 五十嵐英樹さま

各人が改善を行いやすいチームを

 100万人以上の登録者が利用する日本最大級のクラウドソーシングサイト、クラウドワークスを運営する株式会社クラウドワークスさんにお伺いしました。官公庁や上場企業などの利用実績も豊富なクラウドワークスでは、エンジニアやデザイナーといったプロフェッショナルから、シニアや主婦まで、幅広い登録者が仕事をしています。

 株式会社クラウドワークスさんの開発チームは約30名、「許可を求めるな謝罪せよ。」をモットーに掲げ、2014年の上場以降、メンバーの増加に合わせて、コードの品質にも注力しながら開発を進めています。より良い環境を創出するべく打ち合わせへの参加をオープンにしたり、カジュアルに質問できる環境を作るためにSlackに#develop_kikerukaというチャンネルを作り「聞ける化」を推進するなど、チームコミュニケーションを取りやすく、各人が改善を行いやすいチームを作っています。

クラウドワークスのエントランスにて

持続的な成長のフェーズで生産性を1000倍にする

―コードの品質を重視されているとの事ですが、その理由などをお聞かせください

弓山さん: 私たちには、CrowdWorksというサービスを提供し続けるという大きなミッションがあるので、維持しやすい、メンテナンスしやすいコードを書いていこうという価値観を強く持っています。

一度作って終わりの使い捨てコードとは違って、提供し続けていく、より良く改善し続けていくことがサービスの価値につながるので、品質の良いメンテナンスしやすいコードにしていく必要があるのです。

見通しよく設計・実装されているコードと、それと真逆の複雑すぎるコードを比べてみると、いろいろなケースがあるとは思いますが、機能拡張するときの生産性は100倍、1000倍、あるいはそれ以上の違いが生まれると思っています。

やわらかい表情で話す弓山さん

元の設計がよくない時というのは、そこが良くないだけではなく、良くない設計をかばうための良くないコードがさらに継ぎ足されていきます。こうして複雑化していったコードはどんどんとわかりにくくなり、サービス改善のコストを高くしていきます。

そしてある時点でこれはダメだということに勿論なるのですが、それをわかりやすくするためにも、膨大なコストがかかります。

五十嵐さん: 私は過去に、技術的負債が新たに生みだされていくところを何度も目にしてきました。

クラウドワークスではエンジニア同士でコードレビューを行っていますが、コードの書き方への指摘は、人によって考え方が違ったりもして、コミュニケーションコストを発生させていきます。そういうものをもっと、人と人だけではなくツールによる第三者的な視点からのフィードバックを介在させてコミュニケーションをとりやすくするのがよいですね。

私は性格上、コードは美しくあるべきだという思いが強いので、持続的な成長が重視される今のクラウドワークスのフェーズで、全体を考えながら設計を綺麗にしていくことによって貢献できると思います。

丁寧に説明してくださる五十嵐さん

弓山さん: 最短時間でのリリースを優先する、先々のことを想定して色々組み込んでおく、コードをシンプルに保つなど、どの部分に重きをおくかは、サービスのフェーズによって優先すべき選択肢が変わってきます。クラウドワークスは上場し、エンジニアも増えてきて、ちょうど「持続的な成長のフェーズ」に入ってきていると思います。

「持続的な成長のフェーズ」では、より改善しやすくしていくためにメンテナンスしやすい、読みやすく把握しやすいコードにしていくことに価値があると思っています。

コード品質の計測やテストのカバレッジの計測だけではコードは綺麗にならなかった

―過去の取り組みではどういったことがあったのでしょうか

弓山さん: 以前、ツールを使ってコード品質の計測や、テストカバレッジを計測していたのですが、計測値の変化が改善にうまくつなげられていませんでした。

これは2つの原因があったと考えていています。

1つ目は普段のレビューのサイクルと違うところでツールの指摘が行われていたことです。

2つ目はツールからの指摘が、実際の運用の状況に対して適切な指摘ではないケースが多く見られたことです。

以前のツールでは、普段コミュニケーションがおこなわれているGitHub上ではxマークがつくだけで、内容を確認しにいくのに手間がかかりました。このため、あまり指摘自体を確認されないという状況が発生していました。

githubの画像を添えて

GitHubステータス通知

この見づらい問題に加えて、指摘内容としては適切でも、現在の我々の状況では対処するのが難しい指摘であることが多くて、効果的なフィードバックに繋がっていませんでした。まさに「割れ窓」で指摘自体が重視されない状況になってしまっていたのです。

SideCIを使ってPull Requestにコード品質の計測結果を表示させよう

―どのようにその問題に取り組んでいかれましたか

弓山さん: 「このままじゃまずいよね」という課題意識は長い間持っていたのですが、なかなか対応できていませんでした。数人のエンジニアで話していたときに、改善しようと盛り上がり課題解決に向けた取り組みを始めました。クラウドワークスでは、「エンジニア部活動」という制度があって、エンジニアが3人集まると業務の10%までの時間を自由に使って改善などの活動ができるようになっています。

五十嵐さん: 部活では、改善について許可を求めることなくどんどんやっていけるのがいいですよね。「許可を求めるな謝罪せよ。」というキーワードも社内の頻出用語です。

当初、SideCIを知っている人たちが何人かいてSideCIならコードをチェックしてGitHub上のPull Requestに指摘をコメントしてくれるぞということで、まず社内の日報サービスのリポジトリに導入してみました。

開発チームの様子

普段のコードレビューはGitHub上で行っているので、そのサイクルの中に組み入れていこうと考えました。

使ってみたところ、大量に指摘が出てきて(笑)。これをクラウドワークスのリポジトリに適用するにはかなりの調整が必要だなということがわかりました。

にこやかに話すお二人

弓山さん: 日報サービスのリポジトリにSideCIを適用してみて、入れればいいだけというものではないということがわかり、これはとても良い知見でした。何を自分たちの品質に関するルールにするかきちんと調整して進めていこうという覚悟をしました。また、以前問題だったレビューのサイクルとずれていた問題については、Pull Requestにコメントされることによりうまく回りそうだというイメージが持てました。

Pull Requestへのコメントでコード規約を議論

―コメントを入れていく試みはうまくいきましたか

五十嵐さん: もともと使っていた測定のツールからSideCIでのコードレビューへの乗り換えにあたって、まず、Pull Requestへのコメントは無効化した状態でSideCIを適用しました。どのルールが適切か検討をすることにしたのです。SideCIでチェックされるルールの中には現状に対して厳しすぎるものもあったので、それらを除外していくことをまず行いました。

弓山さん: 本格導入の準備は、週1回のMTGで方向性などを確認して、各自の宿題で作業を進めながら、3週間ほどで一通りの準備を終えました。

コードスタイルのバラつきが多いという課題意識もあったので、まずは、スタイルの揺れを減らすようにRuboCopの自動修正機能を使って、一括で変更しました。

五十嵐さん: 適用するルールをある程度絞ったので、静的解析の結果をPull Requestにコメントとして載せるように設定しました。

普段コードの議論をしている場であるGitHubのPull Requestにコメントがつくと、指摘にもとづいてコードを修正したり、Slackで私と弓山さんのところに「このルールは厳しすぎるのではないか」と連絡がくるようになりました。以前のツールのように指摘が放置されることはなく、議論を通して共通認識が広まったり、ルールが知られていったように思います。

弓山さん: 導入当初は指摘内容に対して議論が多くありましたが、それぞれ議論して反映していった結果、最近では指摘があるとさっと直すようになってきました。現状のルールについては、メンバーに定着しているように思います。

把握しやすいコードでより価値を高めていきたい

―これからの課題や今後の取り組みをおしえてください

弓山さん: 現時点では採用していないルールだけれども、やったほうがいいよねーというところがまだあります。極端な例だと、「メソッドの行数を5行以内にする」というような規約が役に立つ場面も時にはあると思うのですが、それが適切な場所とそうでない場所でルールを分ける必要もでてくると思います。

また、既存のコードも多く存在しているので、いきなりルールを導入するのが難しいという側面もあります。緩やかに導入していくために、細かくルールを調整できるようにツールを拡張したり、ビジネスのスピードを落とさないようなバランスを考えることも必要で、将来的には取り組んでいきたいと思っているポイントですね。

五十嵐さん: コードの品質が下がっているものの中でも、一番よく使うコアとなる部分について、優先的に直していきたいというのがあります。

それと、既存コードと修正したコードが混在する状況ができると、どっちに合わせるかということでメンバーが迷ってしまうことになるので、どういう改善を行っているのかを伝えていくことも課題だなーと思っていますね。

品質が悪くなっちゃうケースとして、統一感を持たせるという意図で既存のコードと書き方を揃えることがありますが、それをそのまま実行しているとよくない書き方まで踏襲してしまうことになります。悪い所はきちんと改善していける流れを作っていきたいですね。

弓山さん: サービスを提供し改善し続けていく中では、読みやすく把握しやすいコードであることには大きな価値があると思っています。

読みやすさにも幾つかの観点があると思います。例えば、複数のメソッドがあるときに、同じような構造で書かれているほうが読みやすいという価値観。これはこれで良いのですが、既存のメソッドが読みづらくなっているならば、あえて違う構造で実装するという選択肢が有効なケースもあるでしょう。

このレベルの指摘になると現在の静的解析では難しい領域になってきますが、ツールが進化してこういった指摘まで自動化できるようになると嬉しいですね。

終わりに

クラウドワークスさんでは、コード品質の重要性と取り組みにおける知見をお話ししていただきました。コード品質をあげるには、チームメンバーでのルールを共有したり、納得したりするプロセスが重要であることがよくわかりました。

より大きな価値を提供し続けていくためにも、既存のコードを整理し、維持していくことは重要です。より良いサービスの実現を目指し、クラウドワークスさんでは整理されたコードの維持のために、継続的な改善・投資に取り組むことを重視していることが感じられたインタビューでした。

3人の集合写真

解析結果まで30秒、
無料でお試しください

SideCIは14日間無料でお試し頂けます。登録開始から約30秒で解析結果が閲覧できます。
また、OSSはすべての機能が無料で無制限にご利用頂けます。

導入事例一覧