【スライドあり】社内勉強会「Hacker’s GATE Plus」を開催しました!

こんにちは。ウィルゲートで開発を行っている三島です。

先日、3月23日にオルトプラス(エンジニアブログ : AltPlus Tech Blog)さんと合同勉強会「Hacker’s GATE Plus」を弊社のオフィスを使って開催しました。 この勉強会は弊社の岡田が他社との交流を通してエンジニアとしての知識を深めていくことを目的に定期的に開催しているものになります。

今回の勉強会は「アプリについて」をテーマに開催しました。 ウィルゲートからは私が「Webエンジニアがアプリを開発(運用)できるようになるまで」を発表しました。

当日のスライドは以下になります。

f:id:MikaE:20180426200124j:plain

f:id:MikaE:20180426200140j:plain

感想

私がネイティブアプリの運用を始めたときは、社内でアプリ開発を行っていなかったため、ネイティブアプリについて聞くことのできる人がいませんでした。 こういった機会で自社にない知見を得ることができるので、少しでも自分にないものを取り入れていきたいと感じています。 今後も登壇など積極的に取り組んで行きます。

開発室を成長させる4つの戦略

f:id:odoroodoro:20180502152849j:plainはじめまして、執行役員の鶴飼です。主に開発組織の戦略・ビジョン作りやトップマネジメント層の育成を行っています。 前期まではゼネラルマネージャー(以下GM)として開発組織の強化に専念していました。 執行役員になりGMとは違う一段上のステージで組織を牽引するなかで意気込みを語っていきたいと思います。

そもそも私はどんな人物か?

執行役員になるまでの経緯

ウィルゲート入社前
  • 2015年5月にウィルゲートに入社するまで、およそ14年間はweb系SIerとして4社ほど経験をしてきた
  • PM経験が豊富で、オフショアも中国とベトナムなど複数経験済み
  • 10年ぐらいはPHPの現場でやってきており、チョコチョコ書いていた
  • メインはサーバサイドだが、インフラ構築、ミドルウェアチューニング、当時ajaxがはやり始めた頃に使い始めるなどフルスタックエンジニアだったと思う
  • 他社サービスのグロースをメインで行ってきたが、自社サービスのグロースや組織作りがしたくて転職。
  • 自社サービス・組織としても成長途中である事、社長の社員に対する想いや企業理念に惹かれ、ウィルゲートに入社。
ウィルゲートに入社後
  • 最初はエンジニアとして入社希望しており開発を頑張っていた
  • 当時、自社サービス(サグーワークス)の大規模開発(25人月程度)があり、PM経験があった為、抜擢される
  • 入社3ヵ月でリーダーに抜擢
  • 自社サービスの特性など、今考えるとあまり分からぬままプロジェクトスタート
  • 自らも開発しながらプロジェクトを完遂させる
  • 10月頃から特殊案件で人員が減る中、サグーワークス、暮らしニスタなど複数のメンバー管理も行う
  • 2016年1月からマネージャに就任
  • 2016年4月からゼネラルマネージャに就任
GMになってから
  • 開発全体の戦略を纏める
  • マネージャ兼務のまま、リーダーの育成
  • 経営ミーティングに参加
  • 開発本部発足
  • 事業横断で技術ナレッジの蓄積が出来るようにフロントエンド・バックエンドなどセクションに分け、スペシャリストの育成体制の推進
  • 採用戦略の立案
  • 登壇や勉強会などのイベント開催

GMになってからの2年間でも自社技術が相当ブラッシュアップされ、環境も整備されたと思います。

tech.willgate.co.jp

tech.willgate.co.jp

これはメンバーの成長意欲に後押しされた形で体制を作ってきたものになります。 また、社内にマネジメントコースとスペシャリストコースがあり、大きくは2つに分かれているものの、”技術”というものが明確では無かったという点もあるので、 スペシャリストの中でもフロントエンドやバックエンドなど得意技術軸で成長ができるように整えてきました。

4つの戦略

長くなってしまいましたが、今期から執行役員として全事業開発の生産性向上及び技術研究をテーマに進めていきたいと思います。

ウィルゲート開発室は13期目を迎えましたが、過去最大のエンジニア人数になっています。

チームが大きくなると一人当たりの生産性は下がり、また全体の見通しが悪くなります。 自社でプロジェクトリーダーやプロジェクトマネージャーを育成しつつ、組織もプロアクティブに変更を加える事で、役割を明確にしつつ見通しのよいエンジニア組織でありたいと思います。 また、事業フェーズに合わせ、新しい技術へのチャレンジもメンバーの成長に合わせてどんどん取り入れて行きたいと思います。 やはりエンジニアは新しい技術に常に触れられる環境にいるのが最もバリューを出せると思いますし、何より自分自身が楽しくあるためでもあります。

また、それらを戦略に落とし込む時に大きな戦略を4つに分けて考えています。

  1. 事業開発戦略
    • 主に自社事業の開発する上でのチーム編成や抜擢人事、また事業のフェーズに合わせたQCDの設定などを方針を固めます。
  2. 採用戦略
    • 新卒・中途及び業務委託や外注など、開発人員の補強や中長期的な人員戦略の立案をします。
    • 母集団形成から訴求ポイントの打ち出し、リクルーターの教育まで含めて方針を固めます。
  3. ブランディング戦略
    • ウィルゲートの開発室の打ち出し方だけではなく、所属している社員に伝える為にもブランディング戦略は必要と考えています。
    • ブログのみならず、勉強会や登壇イベントなどアウトプットの方針を固めます。
  4. 技術戦略
    • 自社のコンピタンスとなる技術の追求や自社事業の中期目線で必要になる技術をキャッチアップ。
    • 開発本部のディレクターを中心に技術キャッチアップを行い、マネージャやプロジェクトマネージャが適宜、技術導入検討を行えるようにします。

戦略については、マネージャやPMOとディスカッションを繰り返し、各ユニットの戦術の形に紐づけてメンバーへ共有する形で、個人の成果が開発や事業の成果に直結するように設定しています。

まだまだ足りない技術もありますし、エンジニアの働きやすい環境が整ったとは言い難いですが、自身のWillでもある「ウィルゲートだからできるエンジニアとしての成長」にフルコミットしていきたいと思います。

Bitbucket Pipelines (CI) を使って気持ちよく開発する

サグーワークス開発チームの池添です。

今回はチーム目標「Comfortable development / 2.0」の取り組みの中から Bitbucket Pipelines (CI) の活用内容をお話していきます。 チーム目標に関しては下記記事に書いてありますのでぜひ読んでみてください。

tech.willgate.co.jp

Bitbucket Pipelines 利用に至ったきっかけ

チーム内では以前からコードレビューの時間短縮、負荷軽減のためにCIツールなどの導入を検討してきていました。

しかし、なかなか導入できなかった背景としてサービスの利用技術が古く、Composer が導入できない PHP のバージョンだったため、コードスタイルチェックのツールである phpcs やユニットテストのためのツールである phpunit が導入できないという状態が続いていました。

以前の記事でも紹介させていただきましたが、PHP のバージョンアップやフレームワークCakePHP のバージョンアップに成功し、今回 CI ツール導入にこぎつけることができました。また、チーム内にテストコードを書く文化を浸透させるためのCIツールとしての意味合いも強く、おかげで今では多くのテストコードが書かれています。

tech.willgate.co.jp

Bitbucket Pipelines とは

2016年10月から Atlassian が提供しているCIツールで、同じく Atlassian 提供の Bitbucket と連動させることができます。ビルド環境は Docker を採用しており自由にイメージを選択し、CI 環境を構築することができます。特徴としては、Bitbucket が公式で提供しているため連携のための手順が不要ですぐに使い始められることです。設定ファイルは bitbucket-pipelines.yml というものに記述していくのですが、docker-compose.yml のように記述していくことができるので直観的に書くことができとても使いやすいです。

ja.atlassian.com

他の CI ツールとの比較

導入の際に他の CI ツールとの比較もしたので載せておきます。

CIサービス名 料金体系 他と比べての目立つところ 2並列、月1500分のときの料金
Bitbucket Pipelines $10
500分まで無料
$10 / 1000分
弊社ではBitbucketを使っているので別ツール側の設定がほとんど不要, 実行時間に対して課金する(スケールは自動で行われる) $10
CircleCI $50
1並列で無料
2並列で$50
※時間はどこまで増えても金額が変わらない
最大で 24時間 * 60分 * 2並列 / day まで回せる
月あたり86400分くらい。
利用企業が多いので情報も多い
課金によって時間の制限が無い
スケールに対して課金する
$50
TravisCI $129
1並列で$69
2並列で$129
※時間はどこまで増えても金額が変わらない
最大で 24時間 * 60分 * 2並列 / day まで回せる
月あたり86400分くらい。
スケールに対して課金する
金額高め
$129
droneio 無料
ホスティング料金がかかる
自分たちでホスティングする必要がある
あまり情報が多くない
ホスティング料金
Bamboo $10
ホスティング料金がかかる
自分たちでホスティングする必要がある
弊社ではAtlassianクラウドを利用している以上はあえてBambooにする理由はない
$10+ホスティング料金
Jenkins 無料
ホスティング料金がかかる
自分たちでホスティングする必要がある
自分たちで細かな設定もいじるので運用に向けての検証などが必要
ホスティング料金
AWS CodePipeline $9.5 + 誤差
1並列あたり$1
最安インスタンスが $0.005 / 分
API Gateway, Lambda, S3 の軽微な金額が加わる
$1 + ($0.005 * 1500min)
複数のツールを組み合わせるためコストや利用がややこしい
AWSの安心ハイアベイラビリティ
$9.5+ホスティング料金

上記を踏まえ、2並列月1500分としたときの最安値を比べコストが一番かからず、かつ Bitbucket との親和性が高いという理由で弊社では Bitbucket Pipelines を採用しました。

Bitbucket Pipelines の利用例

私のチームでは下記内容をリモートブランチにプッシュしたタイミングで実行するように設定しています。自動で実行されることにより、コードレビューの負荷を下げることができています。

下記のようにステップごとに任意のコマンドを実行し、結果をコミット単位で確認することができます。 コミット単位以外にも手動実行や、スケジュール実行も可能です。

f:id:zoe302:20180413095744j:plain

また、下記のようにWebhooksを設定することでSlackなどとの連携も簡単にできます。

f:id:zoe302:20180413100854p:plain

f:id:zoe302:20180413100859p:plain

おわりに

いかがでしたでしょうか? Bitbucket Pipelines に限らず CI は日頃の開発作業を効率化するのにとてもいいツールです。

今回は社内でも一番使われている、テストの実行とコードスタイルチェック、ビルドの実行、Slack への通知を CI によって自動化し、効率化する方法を紹介しました。

紹介した内容以外にも、マージ済みのリモートブランチを削除したり、マージのタイミングで各環境へコードをデプロイしたり、スクリプトで表現できるものであれば大体自動化できるので、ほかにもいろいろ試してみるといいかもしれません。

「兼チャレ」「兼任」という制度を活用してみました

はじめまして、インフラチームの内田です。主に社内ネットワークを担当しています。 ウィルゲートでは「兼チャレ」「兼任」という制度があり、私は前年度に両制度を活用して開発室以外の部署に兼任していました。 「兼チャレ」「兼任」という制度について、またその時の感想をご紹介いたします。

「兼チャレ」「兼任」という制度

「兼チャレ」「兼任」とは何か?

ウィルゲートでは「兼チャレ」と「兼任」という2つの制度があります。 「兼チャレ」「兼任」共に自分が所属する部門以外の部署への兼任に挑戦できる制度となっており、社員が多様な経験を通して自分、事業、組織を成長させるための挑戦機会を制度として実施しています。 2つとも部署を兼任するという点で同じですが、稼働と予算に対する考え方が違っています。

「兼チャレ」は主にチャレンジの意味合いが強く、ミッションや稼働工数は定められていません。 兼チャレ先事業部の上長と相談して何をするのか、何がしたいのか等を決めて業務として取り組んでいきます。 志望者が応募した後に両部署で検討およびすり合わせを行い、上長から承認を得て挑戦することができます。

「兼任」では明確なミッションが定められており、そのミッションを達成するために稼働や予算を調整して業務に取り組みます。 両事業部間で稼働について相談、どちらの事業部でどれくらい稼働するのかを決めてから業務開始となります。 兼任ではミッションを達成できそうな人を会社が選出して調整を図ります。 対象者の同意が得られたら両部署で検討およびすり合わせを行い、上長から承認を得て兼任が開始されます。

何故兼チャレに挑戦したのか?

自身について迷っていたので、色々経験してみたかった

私が兼チャレに挑戦してみようと思ったのは、自身のキャリアについて悩んでいたからです。 今までインフラのエンジニアとして働いてきたのですが、自分は将来どうなりたいのか、何がしたいのか。よくわからないまま日々の業務をこなしていました。 そうした時に主にコンテンツを企画しているチームが兼チャレを募集しており、「挑戦してみてはどうか」とマネージャーから声がかかりました。 私自身としても色々体験して自分の見識を広げたいと考えていたので、兼チャレに挑戦してみることにしました。

兼チャレに挑戦した成果と課題

全てが刺激的、未知の領域は楽しい!

今までずっと開発室に所属していたので、他の事業部で行われている業務について何も知りませんでした。そのため、兼チャレ先で行われていた業務は全て未経験で、とても新鮮でした。 お客様に直接納品するコンテンツとはどのように企画しているのか、今まで開発室が作ってきたツール等はどういった時にどのように活用されているのか。 今までは漠然としか知らなかった物が目の前で扱われていて、とても刺激を受けました。

自走できるメンバーに成長!

取り急ぎ兼チャレとして所属し、最初に行った業務はコンテンツの初期企画でした。 ウィルゲートではコンテンツマーケティング事業としてお客様に適したコンテンツを企画・納品しています。 その中で初期企画という業務ではお客様から「どんなターゲットを想定しているのか」「どんな情報を閲覧者に届けたいのか」等をヒアリングして企画書を作成し、お客様に納品する業務のことを指します。 0からコンテンツを企画したことはなかったので、世のコンテンツとはこのように作られているのか、と感銘を受けました。

より詳しくコンテンツについて知りたい方は、 検索ユーザーに愛されるコンテンツ設計について徹底解説~集客できるコンテンツとは?~ | プロモニスタ をご参考頂ければと思います。

「エンジニア」としての価値は提供できず

しかし、作業員としてコンテンツの企画・運用に徹してしまい、エンジニアとしての価値貢献はほぼ何もできていませんでした。 元々チームメンバーが少なく、運用する上で人の手が足りていなかったので一定の貢献はできていたと思いますが、それ以上の何かを残すことはできず兼チャレの期間が終了してしまいました。 運用について手を動かすことばかり考えていたので、考える方向を変えたらもっと良いものが貢献できたのではと思い悔しく感じたのを覚えています。

兼任として参画、求められているミッション

今度は兼任、兼チャレ時に出来なかった価値提供のリベンジ!

兼チャレ期間が終了して開発室所属に戻ると思っていたのですが、「引き続き兼任として業務を手伝ってくれないか」と声がかかりました。 チームメンバーが少なく私が抜けると運用が回らなくなってしまうので、運用が安定するまで協力して欲しいと。 私個人としては兼チャレ時に提供できなかったエンジニアとしての価値を今度こそ届けるチャンスと考え、承諾しました。 両事業部から承認が得られましたので、今度は兼任として所属、業務に取り組みました。

兼任に挑戦した成果と課題

今度こそ「エンジニア」として価値貢献!

今度は予め運用業務と効率化の両軸で稼働することを事前に決めておき、スケジュールや稼働工数もそのように分配して業務に取り組みます。 それが功を奏し、運用業務もそこそこに効率化に向けて稼働することができ、今まで手動で行われていた運用業務を自動化するマクロを開発し、運用を開始しました。 その結果としてマクロ導入前に比べて80%の稼働削減に成功、常に運用業務に圧迫されていたメンバーたちの負荷を削減することに成功しました。

他にも改善、チーム全体稼働50%削減を実現

その後も手動で行われている業務をマクロなどで自動化できるものは一通り自動化させていき、最終的にはチーム全体の稼働を50%削減することができました。 兼チャレから始まってようやくエンジニアとしての価値貢献ができたかと思い、やりがいと強い達成感を感じたのを覚えています。 そういった流れで兼任先には間違いなく価値貢献ができたかなとは思います。

今後はメイン事業部にも事例を共有したい

兼任先ではそういった成果を残してきたのですが開発室にはうまく共有できておらず、私ばかりが良い経験をしたという所で終わってしまいました。 今後は兼任に限らず新しい領域に挑戦した際は何が良いのか、何に苦労したのか等を開発室に伝えられたらと思っています。

まとめ

社会人として部署などに所属した場合、全く触れたことのない領域に挑戦するのは工数の兼ね合いや調整等とても大変なことだと思います。 しかし兼チャレという制度のおかげで未知の領域に挑戦することができ、とても良い経験をさせてもらいました。

また、今まで開発してきたアプリ等がどのように使われているのか、自分たちが組み上げてきたものがどうやって役に立っているのかを知ることができました。 場面によっては自分が使うこともあり、どこをどうしたらもっと便利に使ってもらえるのだろうか、といった発想まで繋がってアプリの改善を行うこともできました。 様々なことに興味がある人や自分のように迷走している人にとって、この兼チャレまたは兼任という制度はとても良い刺激を受けることが出来る制度だと思います。

PHPフレームワークのバージョンを上げるための取り組み

f:id:m_yokomichi:20180215185907j:plainサグーワークス開発チーム PMの横道です。

前回はチーム目標に対する取り組みのお話しをさせていただきましたが、
今回はその取り組みの1つであるPHPフレームワーク(以下フレームワーク)載せ替えの取り組みの内容をお話していきます。

tech.willgate.co.jp

フレームワーク載せ替えの取り組みの背景

1年ほど前に実施したサービス全面リニューアルでフレームワークをCake1系から3系に載せ替えを行いました。

※その時の記事はこちら tech.willgate.co.jp

リニューアル完了時に載せ替えられたのはシステム全体の半分ほどでした。
フレームワークを載せ替えた箇所の新規開発や追加改修については整備されているので開発しやすい状態になっていますが、載せ替えが終わっていない箇所については開発しづらい為、開発工数がかかってしまうということが起きていました。
開発しやすい環境作りのために、フレームワークの載せ替え作業をチーム全員で協力して行っていくことにしました。

フレームワーク載せ替えするにあたって

サービスを成長させるための機能開発がある中で、意気込みだけでは並行してフレームワーク載せ替え作業を進めることはできません。
継続的にフレームワーク載せ替え作業を進めていくためにどうすればいいか考えた結果

  • 載せ替えない対象を明確化
  • 載せ替える対象を種別分けと優先度付け

上記の2点を決めてから取り組むことにしました。

継続的に進めるために決めたこと

載せ替えない対象を明確化

システム全体の半分を載せ替えるとなると開発工数がかなりかかってしまうので、載せ替え対象と載せ替えない対象の仕分けを行い、特に載せ替えない対象を明確にしました。

  1. 今後使われなくなる機能は対象外とする

    • 現在運用で使用していない機能は対象外
    • 使用頻度が低い機能は対象外(使用頻度を事業部にヒアリングして確認)
    • 別画面で代替え可能な場合は載せ替え対象外
  2. 上記の以外の機能の中で載せ替え対象の仕分けを行う

    • セキュリティの観点で重要な機能は載せ替え対象
      • ログイン機能やポイント換金機能など
    • サービスの主軸になる機能は載せ替え対象
      • サービス成長の過程で改修する可能性があるため
    • 上記以外は載せ替え対象外
      • (小さい機能に関しては、載せ替え作業を研修期間に課題として有効活用することもあり)

載せ替える対象を種別分けと優先度付け

載せ替え対象が明確になったので次は優先度決めと開発計画を立てていきます。
優先度は「開発」と「保守」の2種類に分類

開発:機能改修するときに対象の機能ごと作り直す
保守:現行の機能をほぼそのまま作り直す

「開発」に分類された機能

機能改修自体に事業部が考えている優先度があるため、その優先度に合わせて載せ替えを実施していきます。
載せ替えを行わない開発と比べ開発コストはかかってしまいますが、システム保守コストと追加改修があった際のコストを考えると投資するメリットがあることを事業部に説明し承諾してもらっています。

「保守」に分類された機能

開発側で順に対応していくので下記の内容で優先度決め、順次対応することにしていきました。

  1. セキュリティの観点で重要な機能
    • サポートが切れた状態で使用し続けることはリスクなので優先度を高くする
  2. 運営が不便に感じている機能
    • 作り直すついでに修正することで運営工数が下げる狙い
  3. 使用頻度の高い順
    • 使用頻度が高ければ追加改修が来る可能性が高くなるので早めに対処

事業部サイドでは開発予定していない内容ですが、事業部に必要性やメリットをしっかり説明することで理解してもらうことができたので、載せ替え作業を行う時間を確保することができました。

現在の進捗状況

開発に絡めて載せ替えを継続的に行っている為、この1年間で載せ替え作業をかなり進めることができていて、最近では古いフレームワークでの追加改修は全く行っていないので、主要どころの機能は一通り載せ替えることができたと実感しています。
あと半年ほどで載せ替え作業が終了する見込みが立っているので、引き続きチームで協力して載せ替えを進めていければと思います。

サグーワークス オンライン発注リニューアルプロジェクトを振り返って

 サグーワークスの開発をしている石川です。

 昨年度サグーワークスは、フレームワークを載せ替え、システムの大半をリニューアルし、サグーワークスの地盤を固めることができました。
 今回はオンライン発注リニューアルプロジェクトとその振り返りについてお伝え出来ればと思います。

 

サグーワークスとは

f:id:char1129:20180326184205p:plain

 サグーワークスとは、受託型記事作成サービスです。コンテンツを求める企業から、記事の制作依頼をいただき、記事の企画や構成を行なった上で、サグーワークスに登録しているライターの技量や経験に応じて、ライターに様々なお仕事を紹介しています。
 2018年2月、クライアントが記事をオンラインから発注することができる、オンライン発注機能のリニューアルをいたしました。

リニューアルプロジェクトの始まり

 今回の開発はリニューアルで、以前にもオンライン発注機能がサグーワークスにはありました。リニューアル前のオンライン発注機能は、昨年度のフレームワーク載せ替えリニューアルと並行して開発された機能であったため、リソースも期間も制約が厳しく、機能を限定した形でリリースに至りました。そのような状況で開発した機能でありながら、多くの発注者の皆様にご愛顧頂き、嬉しく思います。
 そして機能のリリースから1年が経過した2017年10月、記事のニーズの変化に合わせて、オンライン発注リニューアルプロジェクトが始動しました。

プロセス

 今回のリニューアルでは過去の発注者の声や要望を整理し、サグーワークスを運営する事業部だけでなく、コンテンツの企画をするコンサルタントやディレクターの協力を得て、初期の企画・要件設計、デザイン、プロトタイプが出来上がってきた段階で徐々に開発がスタートしていきました。
 今回のプロジェクトではUI/UXの改善も含めたグロースの観点も取り入れ、フォームの傾向分析、発注者の流れ、今後の改善施策の整理を行いました。ここで上がった施策の一部として、フォームの表示順の変更や、ボタンの表記の変更、数字の見せ方などがあり、現在いくつかは経過を観察しているところです。

リリース

 2018年2月20日、リニューアルされたオンライン発注機能をリリース致しました。リリース当日から発注があり、開発者、事業部から喜びの声があがりました。改めて作り手としてエンジニアとして、使っていただけることが嬉しく感じる瞬間でした。

プロジェクトを振り返って

 プロジェクトを終えてから、私たちはwebディレクターを交えての振り返りの機会と、チームメンバーとKeep, Problem, Tryに分けたKPT形式で振り返りを行いました。
 ディレクターとの振り返りでは、運用面で改善した点や今後に向けての課題が上がりました。運用面での改善した点では、社内のコミュニケーションツールとして利用しているSlackとシステムとの連携や、発注者が作成した案件の情報を直接サービスに取り込み、記事の募集につなげられる点、納品が自動化し、出来上がった記事から発注者に届けられる点が運営メンバーにとって役立っている点で、別のフローにも早く取り入れたいという声が上がったと聞きました。一方で、現在の運用体制における課題や記事のニーズと品質についての課題、今後のサービスをどう成長させていくかといった課題があがりました。ここで上がった点は、今後の開発で変化させていき、サービスの成長につなげていければと思っています。

 

f:id:char1129:20180326184356j:plain


 チームでの振り返りで上がった今回の良かった点は、タイトなスケジュールの中、チーム全体で誰が何をしているのか把握できたこと、大きな機能の開発が先に完了し、全体の流れが確認できるように開発が進められたこと、テスト期間や検証期間、改善期間を十分設けられたことが上がりました。またチーム内でスケジュールの共有や連携を促す人が生まれ、各人が率先して作業のカバーを行う動きが取れていたことは、次のプロジェクトにも引き継いでいきたいことです。
 一方で、チーム内で情報の共有が初めからうまく行われていたかというと、そうではありません。チーム内でハブとなる形で状況を把握する人が生まれ、お互いのタスクを把握するところから、これまで以上にチームワークを発揮してプロジェクトが行えたことです。この経験から、プロジェクト開始のキックオフの意義、定期的なタスクの確認、報告・共有を行う必要性を再認識するきっかけになりました。

最後に

 プロジェクトが円滑に進行できたことは、多くの人々の協力があった上で成し遂げられたことだと思います。今回のプロジェクトに関わった皆さまに改めて御礼と、サグーワークスを利用してくださるユーザの皆さまにサービスを安心して末長く使っていただけますよう、今後も開発していければと思います。

JavaScript のグラフライブラリ比較 - 私達がChart.jsからHighchartsに乗り換えた理由 -

はじめに

新卒2年目(もうすぐ3年目!)のエンジニア、宮西です。

現在、私が開発に携わっているプロダクトでは、グラフを使って様々なデータを表示しています。 グラフ化の利点は、一目で要点を伝えられるところ。 開発中のプロダクトは分析系のサービスであるため、「分かりやすいグラフ」はとても大切な要素です。

今までは、Chart.jsというグラフライブラリを使って、これらの画面を作っていました。 しかし、より分かりやすくするために、高度な機能・柔軟なデザイン性が求められるようになりました。 その中で、Chart.jsでは対応しきれない部分がでてきたため、ライブラリの再選定を行うことになりました。
今回はその結果をお知らせしたいと思います。

技術選定に至った背景

やりたかったこと

今回作りたかったグラフは以下のようなものです。 f:id:miyanishi-yuki:20180319094555p:plain

具体的には、

  1. 折れ線グラフ・棒グラフ・積み上げ棒グラフおよび、これらの複合グラフを描画する
    • 複合グラフの場合、y軸が左右にあるグラフ(2軸グラフ)となる
  2. グラフの点とその周辺にマウスオーバーした際に、そのグラフを強調して表示する
    • 対象のグラフを太く、他のグラフを薄く表示する
    • 対象の点の情報をツールチップで表示する
  3. カーソルに追従する縦線を引く
  4. グラフの中に任意の文字や絵文字を表示し、クリックした際にイベントを発火させる
  5. その他、細かなグラフのデザイン(例えば、x軸のラベルの文字間隔など)を調整する

なぜ、Chart.jsではできなかったのか

Chart.jsは、HTMLのcanvas要素にグラフを描画しています。 実際に、Chart.jsで描画されたグラフがどのようなHTMLで構成されているのかを見てみると、canvas要素しかありません。 まさに、キャンバスに描かれた絵のようなものです。 そのため、決められたオプション以外の動きやデザインの変更は不得意という欠点がありました。

上記の「やりたかったこと」の内、1, 2はChart.jsでもできたのですが、3と4はChart.jsのオプションでは用意されていませんでした。 また、5についてはまさにChart.jsの不得意な分野でした。
少々強引な方法を使えば実現するものもありましたが、 別のグラフライブラリで簡単にできるのであればChart.jsに固執する必要はないと考え、 新しいグラフライブラリを探す決断に至りました。

比較した結果

結論

この技術選定の結果、Highcharts という有料のグラフライブラリを使うことに決めました。 以降で、比較したグラフライブラリについてと、比較結果を順を追って説明していきます。

選定候補のグラフライブラリ

今回選定を行ったグラフライブラリは以下の6種類です。

比較

最初に、比較に用いた記号の意味を説明します。

記号 説明
ドキュメントを読めば実装できる
可能だが、一工夫必要(許容できる範囲内)
可能そうだが、時間や手間がかかるので、なるべくやりたくない
× 許容できない手間がかかる

実際に比較した結果が以下の表です。

No. Chart.js Taucharts C3.js Google Charts amCharts Highcharts
1 折れ線グラフ・棒グラフ・積み上げ棒グラフおよび、これらの複合グラフを描画する ×
2 グラフの点とその周辺にマウスオーバーした際に、そのグラフを強調して表示する - ×
3 カーソルに追従する縦線を引く -
4 グラフの中に任意の文字や絵文字を表示し、クリックした際にイベントを発火させる × -
5 その他、細かなグラフのデザインを調整する △ or ×

Chart.js以外のライブラリはSVGを用いています。 SVGでは、グラフの点や線、軸やラベルなどのグラフの要素が、HTMLの要素で表現されています。 つまり、ライブラリが用意したオプションで指定しなくても、グラフ描画後にCSSでデザインの調整ができます。 そのため、5のデザインの微調整については、Chart.js以外はすべて○という結果になりました。

Tauchartsは、2軸グラフのデザインに問題がありました。
2軸グラフにした際に、y軸が左右に表示されるのではなく、左側に2つ軸が出てしまいました。 2つの軸が1ヶ所にまとまって表示される状態は見にくく、要件を満たしていないと判断しました。 そのため、Tauchartsについてはその他の詳細な調査を行っていません。

C3.jsは無料のライブラリの中でも高機能で、ドキュメントも充実していました。 調査を始めた段階では第一候補として考えていたのですが、マウスオーバー時に発火するイベントに問題がありました。 C3.jsのマウスオーバーイベント内では、「どのx軸上にカーソルがあるか」は特定できるようになっていました。 しかし、そのx軸上にあるグラフの内のどのグラフが選択されているのかは分かりませんでした。 そのため、2で挙げた「対象のグラフの強調」ができず、利用を諦めることになりました。

最終的に、要件を満たしたライブラリは3つありました。Google ChartsとamCharts、 そしてHighchartsです。 その中でHighchartsを選んだ理由は、ドキュメントの充実度とオプションの充実度、そして調査時に感じた扱いやすさでした。

Google Chartsは要件を満たした唯一の無料ライブラリでした。 しかし、Google ChartsはHighchartsやamChartsに比べて、ドキュメントの充実度は劣ると感じました。 実際、サンプルコードで実装されていた機能を別のグラフで利用しようとした際に上手く動作せず、 さらにドキュメントを読んでも理由が分からずに困ったことがありました。

amChartsはHighchartsと同等の機能がありながら、Highchartsより安価でした。 ドキュメントというよりはサンプルが多く存在していました。ここで気になったのは、ドキュメントの見やすさです。 基本的にサンプルベースになっているのですが、オプションの書き方などを体系的に理解するのが難しく感じました。 オプションやイベントが体系的に説明されたページもあるのですが、今度はサンプルの数が減ってしまいます。 これは個人の好みだと思うのですが、Highchartsのように、体系的にまとまっている中にサンプルが豊富にちりばめられているドキュメントは理解しやすく、魅力的でした。

おわりに

以上の理由から、私のチームのプロダクトでは、新しくHighchartsを利用する運びとなりました。 今回の要件をすべて満たすライブラリはなかなか見つけられず苦労しました。

最後の3つにしぼられた時、Highchartsを使いたいという気持ちがありましたが、値段のこともあり少し躊躇していました。 そんな時、一緒にプロダクトを作っている事業部の担当者から、
「エンジニアの皆さんが使いやすいものを選んで欲しい。無料でも、安くても、使い勝手の悪いものを使って消耗したり、工数がかかってしまうことは望んでいない。」
と言ってもらえたことで、Highchartsに決めることができました。 先日、実際に画面作成でHighchartsを使ってみて、使いやすさや柔軟さを実感しました。 (好みなどもあると思うので、あくまで個人的な感想ですが…。) 改めて、使い勝手を重視して決定させてもらえたことに感謝しています。

この記事が、これからグラフライブラリを使いたいと思っているかたの参考になれば幸いです。