Sharely開発が最強にスムーズな5つの秘密
こんにちは、コインチェック採用グループ(@coincheck_hr)です。今回は、コインチェックの新規事業であるSharelyのエンジニア募集に伴い、約1年半、Sharelyの開発を牽引してきた龍頭 翼(りゅうとう・つばさ)さんにお話を伺いました。
▼バーチャル株主総会支援サービス「Sharely」の設立背景はこちら
Sharelyの事業概要
--龍頭さん、本日はよろしくお願いします。まずはSharelyについて、事業の概要を教えてください。
Sharelyはオンラインでの株主総会開催を支援するプロダクトです。オンラインでの株主総会の開催が認められる前は、株主総会は基本的にオフラインで行うものでした。Sharelyはを完全オンライン、もしくはオンラインとオフラインのハイブリッドで開催できる機能を詰め込んだサービスです。例えば株主総会に参加する株主が議案への質問をWeb上でスムーズに出来るような機能はもちろん、株主総会を開催する企業様の総会運営をより楽にするための機能の開発にも力を入れています。
--現在Sharelyの開発は龍頭さんがほぼお一人で行われているとのことですが、今回、なぜエンジニアの募集に至ったのかを教えてください!
おかげさまでSharelyの導入事例・支援実績も増えてきている中で、細かい機能追加や改修、お客様の声を踏まえてさらにプロダクトをステップアップさせていきたいためです。他にも、急な病気や事故で開発ができないとなった時のリスクヘッジ、そしてSharelyから派生した新たなプロダクトを生み出していくためにも、複数名のエンジニアがいる体制にしたいと考えるようになりました。
本日は龍頭さんに、「Sharely開発がスムーズに進んでいる5つの秘密」を教えていただきます。
コードが綺麗
テストカバレッジが高い
しっかりとしたドキュメント化で、開発の履歴やルールがわかりやすい
エンジニアの裁量が高く、様々なことにチャレンジできる
フレックスタイム、副業OK
それでは早速一つ目のご紹介です!
秘密1:コードが綺麗!
--まずは一つ目。Sharely開発にあたってエンジニアにとってのメリットになるのが「コードが綺麗であること」だとお伺いしています。これは開発当初から意識されていたことですか?
そうですね、Sharelyは立ち上げ当初から開発担当者はほぼ一名の状態で行ってきたので、「意識してきた」というよりは、「結果的に綺麗なコードになっていて、それを守るためのルール作りをしている」というイメージです。スタートアップでの開発はスピードを重視するあまり、複数人で開発を行いそれぞれが担当箇所を独自のやり方で作っていくことによって、”なんとか動くけれど裏側はぐちゃぐちゃ”ということが起こりやすいんです。
しかしShareyは初期の開発は和田さん(当社ファウンダー&アドバイザーの和田晃一良)がRuby on Railsで行い、僕がそれを引き継いだ後も和田さんが一人で作ったルールを踏襲して開発しているので、複数人の思想が入り乱れていることがありません。結果的に、Sharelyはフロントエンド・バックエンド両面が非常に綺麗でわかりやすいコードで書かれています。
--コードが綺麗であることで、エンジニアとしてはどのような「動きやすさ」「開発のしやすさ」を感じますか?
いざ入社した時に、コードを見てわかりづらいとまずそこでストレスがかかり、タスクを渡されても動きづらいということはエンジニアにとってはよくあることです。コードがきちんとルール化され、綺麗になっているだけで立ち上がりも早く、不安なく開発に入っていくことができるのは大きなメリットだと思っています。
SharelyではRuboCopという静的コードの改善ツールを導入しています。RuboCopの設定に沿って、プログラムコードがその設定通り書かれているかしっかりチェックを行っているので、「人が作ってきたルール」と「機械に任せてエラーを見つけやすくする」という両軸から、綺麗なコードを書きやすい環境になっていると思います。
秘密2:テストカバレッジが高い!
--先ほども少しお話に出ましたが、スタートアップやベンチャー企業での新規事業開発は、スピード感を重視するあまりコードを書く上でのルールが決まっていなかったり、テストカバレッジが低い状態で行われているイメージがあると思います。その中でSharelyはテストカバレッジ率が高いそうですが、なぜそのような方針になったのですか?
多くの方は、「テストコードを書かない方がコードを書く量そのものは少なくて、開発スピードが速くなる」とイメージされると思います。ただ、僕の経験と感覚上、結果的に「テストコードを書いた方が開発スピードは速くなる」というのがわかっていたので、テストカバレッジ率の高さには拘りました。例えば、テストコードを書かずに開発を進めて、後からバグが見つかると、そこに時間を取られてしまいます。まだまだ実装すべき機能はたくさんあるのにバグがどこにあるのか、どうすれば直るのか考える時間のロスが出てきてしまうんです。そういう無駄をなくすためにも、Sharelyでは積極的にテストコードを書くことに決めています。
--テストカバレッジ率はフロントエンド、バックエンド共に高いのですか?
テストカバレッジ率が高いのはどちらかというとバックエンド側の話です。フロントエンド側はまだあまり書けていません。Sharely開発における一つの課題ですね。フロントエンド側のテストコードを書くという風習は比較的最近生まれたものだと思うので、ちゃんと世の中に合わせてSharelyも頑張っていきたいです。新しく入ってくるエンジニアは、そこにもチャレンジできると思います。
バックエンド側においてはテストコードを書いてやっているので、ある程度挙動は安定しています。フロントエンド側は、まずエンジニアサイドで画面が動くかチェックした上で、テスト項目を作り、CSチームにテスト依頼などを行っています。
秘密3:しっかりとしたドキュメント化で、開発の履歴やルールがわかりやすい
--ドキュメント化についても、Sharelyチームでは高く意識していると伺っています。ドキュメント化をしっかりやろう!となった背景があれば教えてください。
元々、Sharelyの初期開発をしてくれていた和田さんがしっかり文章に残してくれるタイプで、僕が開発を引き継いだ時も非常にわかりやすかったのがSharelyの「ドキュメント化文化」の始まりだと思います。何かしらの理由で僕がSharelyの開発から抜ける可能性はありますし、次に入ってくる人が辛くないように、スムーズに開発に着手できるように、しっかりとしたドキュメントを作ることは文化として根付いています。
--社内ドキュメントをまとめる上で、何かルールなどはありますか?
今のところ、Sharelyのチーム自体が少人数なこともあって細かいルールは設けていません。その代わり、テンプレートをしっかり作って、ドキュメントにまとめるときのストレスが少なくなるように工夫は行っています。
--例えば、実際にどのようなドキュメントがあるか教えてください!
「コーディング規約」「インフラのこと」「環境構築のこと」「障害が発生した時の反省会と解決した方法」「リリースノート」など様々です。CSのメンバーも、各セクションごとに定例会議のドキュメントをまとめてくれていたり、お客様ごとのドキュメントなどもしっかり準備しています。Sharelyチームのドキュメントを見れば大体のことがわかるようになっているはずです。
秘密4:エンジニアの裁量が高く、様々なことにチャレンジできる!
--実際に、エンジニアの裁量が高く、エンジニア起案で良いものができたエピソードがあれば教えて下さい!
僕が実際に決めて実装したものだと、株主総会を運営する企業側のダッシュボードで、配信を行う「メインツール」「サブツール」の二つを選ぶことが出来るように改修しました。Sharelyに求められる大きな機能のひとつは、オンラインの株主総会のスムーズな配信です。配信プラットフォームを用いて株主総会をライブ配信する際に、万が一メインツールに問題が起きた時に、すぐにサブツールに切り替えられるように仕様を変更しました。
株主総会は株式会社の最高意思決定機関であり、大変重要な会議体です。配信のトラブルで議事進行に支障が出ることは避けなければなりません。配信ツールのメイン・サブの即時切り替え機能の実装によって、トラブルに対応する速度が上がり、オンラインで株主総会を開くことのリスクを軽減することができました。
--エンジニアの裁量が高いことはチームやプロダクトにどのような良い効果をもたらしますか?
基本的には、モチベーション高く働いてもらったほうが良いものが出来ると思っています。何か新しいものを生み出すこと、作り出すことにモチベーションを感じるのであれば、仕様から自分で決めて実装していく環境で良いものを生み出すことがベストです。Sharelyの場合は、「こういうものを作りたい」を自分で作り出すことができます。また、少人数のチームで動いているので、エンジニアが「やりたい」と思えばすぐに動くことができます。自分自身の勉強にもなりますし、モチベーションにも繋がり、より良いプロダクトが生まれるきっかけになると思っています。
秘密5:フレックスタイム、副業OK! 働きやすい環境!
--龍頭さんの1日のスケジュールを教えて下さい!
僕は大体朝6時半から7時半くらいに出勤しています!現在Sharelyは全体で8名のチームなので、カスタマーサクセスチームの毎週の定例ミーティングに参加したり、隔週でのSharely全体のミーティングに出たり、事業部長と開発定例を行う合間に、ひたすらコードを書き、大体16時くらいには終業しています。
--朝型の働き方なんですね! 16時以降は何をされてるんですか?
そこからは少し副業をしています。副業が終わり次第、筋トレをして、自分のための時間を作ったり、勉強したり……基本的にコインチェックでの仕事はフレキシブルなので、かなり自由な働き方ができています。夕方になってから子供と散歩に行ったり、少し抜けて病院に行ったりといったことができる働きやすさも、Sharelyのエンジニアとしてモチベーションを保てている理由の一つだと思います。
--本日は色々な「秘密」を教えていただきありがとうございました!最後に、Sharelyチームのエンジニアとして、開発していく上でチャレンジしたいことがあったら教えて下さい。
まずは技術的な部分で言うと、現在使用しているRuby on RailsやNuxt.jsといった言語に拘らず、別のより新しい技術を取り入れつつ良いプロダクトにしていきたいと思っています。新しい技術にチャレンジできることはエンジニアのモチベーションにも直結するので、縛られずに新しいことはどんどん取り入れたいです。
また、プロダクトとしては、より少人数で数十億・数百億円規模の収益を生み出せるようなプロダクトにしていきたいと思っています。株主総会はオンラインでやるのが当たり前の世界を実現していきたいですね。
--最後に、どのようなエンジニアにSharelyチームに入社して欲しいかお聞かせください。
なんでも率先して、「これがやりたい!」「あれがやりたい!」と言うタイプの人と働きたいです。もちろん、技術的な部分でも、機能的な部分でも、組織的な部分でも、自ら「こうしたらもっと良くなるんじゃないか」と考えられること、考えることが楽しい人と一緒に働いて、実際に動いて高めあっていけたら嬉しいです。ご応募お待ちしています!
--ありがとうございました!
▼Sharelyエンジニアの募集要項はこちら!!