この記事は、2021/7/21 に行われた WESEEK Tech Conference の内容です。

今回の WESEEK Tech Conference は、WESEEK が開発案件を担当させていただいている、インターネットマルチフィード株式会社(以下「MF社」と表記) 杉本氏を迎えて WESEEK 武井、今間の 3 人の対談形式で行いました。

社内に開発部隊が存在しなかった MF 社に存在していた課題から、WESEEK がジョインし開発部隊を作り、アジャイルと Rails を利用し、どのように課題を解決していったのかをご紹介します。

MF と WESEEK

インターネットマルチフィード(株)とは？

MF社では、JPNAP と transix というサービスを提供しております。

JPNAP は IX(Internet eXchange) のサービスで、様々な事業者様にご利用いただいております。
transix は NTT 東・西日本が提供しているフレッツ光の IPv6 IPoE 接続を事業者様向けに提供しているサービスです。

各サービスの詳細な内容については、こちらをご覧ください。

https://www.mfeed.ad.jp/

IXP/JPNAP とは？

組織(AS)同士がお互いにトラフィック交換をする場合、本来であれば相互に接続する回線を各々で用意する必要があります。(図1 左の絵)

IX と接続することで、同じ IX に接続されている他の組織との接続が IX との接続だけで実現可能となります。(図1 右の絵)

JPNAP は IX 事業者のうちの一つで、様々な事業者に接続いただいております。
2021/07 現在で総トラフィック 3.88Tbps、総 AS 数 200 以上となっております。

詳しくはこちらもご覧ください。

JPNAP
お客様一覧 | JPNAP

JPNAPにおける自動化のあらまし

2014～2015 年頃、JPNAP では IX におけるポートの開通作業を部分的に自動化できていました。
しかし、同時期に行われた APRICOT というイベントで、ある IX による開通作業を完全自動化している発表を聞き、杉本氏は衝撃を受けたようです。
また、発表で行われたような完全自動化するためには、内製で開発できるチームの立ち上げが必要だと感じたそうです。
(当時 JPNAP で自動化を実現するツールを開発していたのは、社内の一部の人間だけでした。)

そして、そのチームには、限られた社内リソースだけではなく、社外のリソースを活用しようと考えていました。

(株)WESEEKとは？

当時、WESEEK は受託開発が得意分野で、売り上げは受託開発に寄っていました。
WESEEK は、インフラ～アプリケーションのフロントエンド開発までワンストップで提供できる開発会社で、ネットワーク運用の経験がある人員も在席しています。
今回のような、ネットワーク運用の自動化をソフトウェアを用いて解決するという日本でも数少ない特殊なミッションに適していたため、MF社/WESEEK 間での契約に至りました。

当時(2015年頃)のMFにおける課題

それでは、当時 MF 社内におけるソフトウェア開発及びその他の課題としてどのようなものがあったのでしょうか。

社内ツール事情

社内の各個人がバラバラにツールを作って、バラバラに管理されていた(置かれていた)
- このソフトは Ruby、このソフトは Perl、このソフトは PHP…
- 使い方はソース嫁
- リポジトリ管理されていない
置いてあるホスト、ディレクトリもバラバラ
- /usr/local/bin? /usr/local/opt? /home/XXX/tools?
社内みんながコードを書けるわけではない
- 偶然コードを書ける人が開発頑張るソリューション(あるある)
起きていた問題
- ex.) ツール作成者がいなくなったあと、誰も保守できない
  - ○○まではできるけど、これに△△を追加したい
  - どこをどう改修したらよいのか…
  - 1 からソースを読もうとするが時間がない
- ex.) 本業の傍らで、なかなかやりたいことを開発できない
  - 本業は IX ネットワークの構築、保守
  - なかなか未来を考える時間が取れない…

MF 社は上述した通り、ネットワークサービスを提供する会社なので、ネットワークが出来る人はたくさん在席していました。
しかし、本業ではないため、コードを書ける人というのは希少種でした。

その中でも本業の傍らで書かれたコードは、管理するまで手が回らず、上記のような問題が発生してしまっていました。

課題一覧

業務に利用するソフトウェアの管理が統一されていない
- リリース手法が決まっていない
- どういう環境に設置/運用すべきか決まっていない
業務に利用するソフトウェアの開発・メンテができない
- 誰でも開発できる状態ではない
- 利用する技術が定まっていない
ソフトウェアの新機能提供がスピーディーに実現できない
開発者として新しいものを追いかけていけていない

課題は既存のツールの運用管理だけではなく、新しいソフトウェアの開発スピードだったり、そもそも世の中にすでにある新しい技術を追いかけられない、という問題もありました。

課題へのアプローチ(序盤編)

上述のような課題に対して、まず最初にチーム開発を実現する上で取り組んできたことをご紹介します。

初期フェーズでやったこと

技術選定

継続的な開発・メンテを実現するために、利用技術は統一化した
- バックエンドについては Ruby on Rails を採用
- 既に Ruby で書かれたツールが他に存在していて、一番低コストで開発・保守できるから(MF からの要望)
- Rails は Ruby での MVC フレームワークのデファクトである
  - ORM から始まり task runner(rake) まで、業務のロジックを実装するための仕組みが一通り揃っている
  - コミュニティによってちゃんとメンテされている
フロントエンドについてはあとで、AngularJS を追加で採用した

Rails は MF 社からの要望で採用しました。
理由は、社内で一部自動化を実現していたツールで利用されていたのが Ruby で、Ruby 言語における Web アプリケーションフレームワークのデファクトが Ruby on Rails であったためです。

発表当日、「今選択するとしたらどの言語を選択するか？」と杉本氏に質問したところ、「ネットワーク本業の人でも扱いやすい言語として Ruby を選んでいるだろう」と話していました。

開発/フィードバックをやり取りするためのツールを導入

今ではどれでも当たり前に使われているツールとなりますが、それまで MF 社には開発チームやフローが存在しなかったため、Slack/Redmine/Jenkins/GitHub といった開発に携わる全員が業務で利用するためのツールを整備しました。

開発スタートアップの整備

開発初心者でも、すぐにコードが書き始められるようにする
以下をまとめたドキュメント
- 各種開発に利用するツールのインストール手法
  - VScode/3-way merge tool など
- clone するリポジトリの場所
- (Rails の場合) rails s するまでに必要なコマンド
  - bundle/yarn など
開発するプロダクトごとに用意している
- が、Rails は大体同じ
  - rails db:migrate db:seed, yarn...

開発スタートアップは、初めて開発に携わる人でも同じツールを使い、同じ手順で開発スタートラインに立てるため、本案件においても WESEEK 社内においても非常に大きな存在です。
また、この開発スタートアップは、上記のように GROWI 上に記載されており、誰でも編集できるドキュメントであるため、チーム全体で日常的にドキュメントの改善も行える体制ができました。

単純な MVC アプリだけではなく、ネットワーク機器を操作するツール等、チームが関わる全ての開発物において開発スタートアップを用意したため、それまで開発してこなかった人も問題なく開発できました。

(WESEEK 社内では、スタートアップを実施したときに詰まったところをドキュメントに反映しないと怒られます…)

今までの開発してきたプロダクト一覧

esthar (Angular)/dollet (Rails)
centra (Angular)/nautilus (Rails)
starrod (Ruby)
server-config-generator (Ruby)
開発実績 (nautilus)
- 26,703 コミット (2016/3/8~2021/07 現在), PR 数は 4400 以上
- モデル数: 103
- テスト数: 3114
- リファクタも何度となく経験

今まで MF/WESEEK 共同で開発してきたプロダクト一覧を掲出しました。
ここまでのプロダクトを開発できた要因を、発表当日、杉本氏より以下のように話していました。

チーム開発ができる体制が整ったからこそ開発できた
- 数人で、本業の傍らでは開発できない規模だった
アジャイル開発を用いて小さくプロダクトを作り始め、成功体験を重ねてこれたのでここまで開発できた

WESEEK ジョイン後の課題

序盤で行ったアプローチを実施し、チームで継続的な開発/メンテができる土壌は整いました。
しかし、さらなるスピードアップ/スケールを求めて、以下のような課題が出てきました。

開発スピードが上がらない
- WESEEK ジョイン当初は、業務と開発の両方の話が分かる人が少なかった
- 開発物の要件定義ができる人の稼働がボトルネックに
開発に関わるリソースをスケールさせたい
ソフトを作るだけでは業務フローが改善されない
- 業務利用のソフトウェアは、開発だけでなくフローもセットで考えなければならない

MF 社内でネットワーク運用をする人(=開発したソフトウェアを使う人)がどういう情報をどういう風に出すと嬉しいか等、開発への要望をまとめるという作業を、初期の段階では杉本氏が実施していました。
しかし、開発と業務がわかる人は数少ないため、その点がボトルネックとなっていました。

また、MF 社よりもっと開発スピードを加速させたいという要望をもらっていましたが、そこに対して具体的な対策が打てずにいました。

スケール/ボトルネック解消へ

そこで、WESEEK では普段の業務で何に困っているのかを知るのが重要と考え、社員を MF 社へ常駐するための準備を始めました。
スクラム開発を MF 社内にも浸透するため、WESEEK 社員と一緒にスクラムミーティングやその他の社内ミーティングに参加できるようにしました。

ネットワーク・ソフトウェア両方わかる人材を手配(WESEEK)
MF 社への常駐に向けた準備
- 武井が1週間視察
- WESEEK 内及び MF ステークホルダーへインプットの時間をすぐ作った
WESEEK 人員の常駐開始
スクラムミーティングを毎日実施
- アジャイルでプロダクト開発を行えるように、開発(dev)チームに所属する MF 社員と一緒にスクラムを毎日行うようになった
WESEEK 人員が MF 社内 MTG に参加
- 本業で困っていること、改善したい箇所などを WESEEK メンバーが直接ヒアリングできる状態へ
Slack 上にフィードバックを行えるチャンネルを用意
- MF 社内で業務中に困ったことをすぐにアウトプットできる場所を準備した

上記で行った事項のうち、Slack 上にフィードバックのチャンネルについては杉本氏も印象深かったようで、「最初の内は作ったソフトウェアをリリースしても反応がなかったが、あるタイミングから自動化して業務を効率化していこうというムーブメントが社内全体に広がった。」と話していました。

Rails を利用したチーム開発

最後は、実際にチーム開発を行う上で、実施してきた技術的な解決手法をご紹介していきます。

実際の開発における課題

継続的にテストを実行できる環境が存在しない(CI)
最新の開発版を継続的に確認できる環境が存在しない(CD)
- 開発中に埋まったバグがリリースまで気づかれない
- 開発の進捗を確認できない
リリースされると、何ができるようになるのかを知る術がない
リリース後、本番のデータでしか起きえないバグケースが出てくる
- 利用している実行環境、ライブラリのアップデートがされない
- バージョンアップは適宜行わないと、技術的負債化…
リリース後、発生しているエラーに気づけない
- 「何かができない」に対してどこがおかしいかわからない

開発/リリースフロー

リポジトリ、CI/CD については今時では当たり前の git + Jenkins Multibranch Pipeline の構成を取ってます。
トピックブランチが push されたときに、CI が走るようになっています。

CI では、ER 図出力/lint/テスト/API ドキュメント生成を行っていて、ブランチごとに結果が閲覧できるようにしています。

ブランチについては、master/stable/その他の区分けで運用しています。
Redmine のストーリー、またはタスクごとにブランチを切って開発を行うルールにしています。

デプロイ先環境

lab
staging
(advance)
production

デプロイ先環境は上記の 4 環境あります。
それぞれ以下のような形で、運用しています。

lab
- master ブランチのバージョンが動いている
- 検証環境のデータが入っている
staging
- master ブランチのバージョンを動かしている
- production 環境のデータが入っている
  - 毎日 2 回、production 環境からのデータ同期を行っている
- 本番データを利用している理由
  - 検証環境のデータでは、モデルの量とモデルの構成パターンが足りていない
  - 本番環境にあるデータで動けば何も問題ない、という考えのもとに生まれた環境
- master ブランチのバージョンで動かした際に出てきた事象の検証、リリース前の動作確認などで使われる
(advance)
- トピックブランチごとに動作確認が必要な場合は、適宜デプロイジョブを作って環境構築をする
  - ex.) 内部構造を大幅に変更するような機能改修、スキーマ変更など
- デプロイ先インフラのリソース見合いで、常に存在していない
production
- stable ブランチのバージョンのアプリが動いている

技術的負債を作らないために

利用 gem の選択基準

メンテされていないと、Ruby/Rails のバージョンアップの足かせとなる可能性が出てくる
ex.) https://github.com/hzamani/active_record-acts_as
- ActiveRecord の polymorphic association で MTI(Multi-Table Inheritence) を実現するための gem
- そこまで active に開発されておらず、Rails update 時の足かせとなった
メンテの判断基準として、GitHub star 数や直近のコミット日時なども参考になる
- GitHub star 数が多い = 利用者が多そう
- コミット日時が直近 = メンテされていそう

開発したアプリで利用する gem/ツールなどは、「メンテされているかどうか、今後メンテされるかどうか」 という点を重視して選択しています。

ライブラリ/実行環境の継続アップデート実現

以下の仕組みで継続アップデートを実現できている
- gem update 時の自動 CI
  - tachikoma -> Dependabot
ex.) 立ち上げ時と現状のバージョン比較
- nautilus 立ち上げ時の Rails version: 4.2.6
- 2021/07 現在の Rails version: 6.1.4

ライブラリの継続アップデート、およびそれに伴うデグレが発生しないように、tachikoma や Dependabot を使いできるだけ作業を自動化しています。
アップデート時の CI が失敗した場合は原因を調査し、利用側のコードを修正する、ライブラリ側のバグの修正を待つ、などの対応を日常的に行っています。

この仕組みのおかげで、開発から数年経ったプロダクトでも、最新のライブラリを利用したアプリケーション開発を実施できています。

My.JPNAP 公開へ

ここまで作り上げてきたプロダクトを組み合わせて、新しい MF 社の顧客向けサポートサイトの公開を実現することができました。

プロダクト構成
- centra (Angular)
  - My.JPNAP フロントエンド
- nautilus (Rails API)
- gargant (Rails API)
  - IX ネットワーク上で稼働している機器のステータスを返す
- suppon (Rails API)
  - JPNAP をご利用中のお客様へのお知らせ情報を返す

技術的負債への対応

SRE という概念が 2017 年から出てきた
- サイト全体を面倒見る人の総称
- ソフトウェア～インフラまで幅広い知識が必要となる
- 運用はできる限りエンジニアリングで解決する
- 新しいものを追いかけていないと実現できない
本案件でも様々な変更を行ってきた、行えた
- tachikoma -> Dependabot
- Jenkins -> GitHub Actions 使えるところは使う
- AngularJS -> Angular -> Vue/React …
- 開発環境 Vagrant -> devcontainer
- インフラオンプレ -> Kubernetes

まとめ

当たり前のことを当たり前にやる大切さ
- WESEEK 内で確立されていた高い「当たり前品質」を MF 社内に根付かせた
機動力・柔軟性
- アジャイルの強み＞日本企業的契約形態に引っ張られる硬直
  - MF 社の文化受容に対する柔軟性、「正しいこと」に対する理解があったからこそ実現できた
Rails の強み
- Rails 本体、gem も含めたエコシステム全体が強かった
- コミュニティによりメンテされている豊富な機能を利用して開発できた
最初に掲げた完全自動化というゴールが見えてきた
- 新しい技術への挑戦、技術的負債化という部分で戦いながらも実現できた

Appendix: 利用 gem ご紹介

著者プロフィール

今間俊介

株式会社WESEEK

某 ISP に 2 年弱勤務した後、2013 年に WESEEK へ入社。
現在は、今回ご紹介するインターネットマルチフィード様開発案件などプロジェクト問わず、Rails/Kubernetes を中心としたインフラ/アプリの設計・構築・運用に携わる。

株式会社WESEEKについて

株式会社WESEEKは、システム開発のプロフェッショナル集団です。

【現在の主な事業】

通信大手企業の業務フロー自動化プロジェクト
ソーシャルゲームの受託開発
自社発オープンソースプロダクト「GROWI」「GROWI.cloud」の開発

GROWI

GROWIは、Markdown記法でページを記述できるオープンソースのWikiシステムです。

GROWI.cloud

GROWI.cloudはOSSのGROWIを専門的知識がなくても簡単に運用・管理できる、法人・個人向けの商用サービスです。

大手SIer・ISPや中小企業、大学の研究室など様々な場所でご利用いただいております。

【主な特徴】

テキストも図表もどんどん書ける、強力な編集機能
チーム拡大に迅速に対応できる管理者向け機能を提供
充実した機能・サポートでエンタープライズにも対応

【導入事例記事】
インターネットマルチフィード株式会社様
https://growi.cloud/interviews/mfeed/?utm_source=connpass-top&utm_medium=web-site&utm_campaign=mf

株式会社HIKKY（VR法人HIKKY）様
https://growi.cloud/interviews/hikky

WESEEK Tech Conference

WESEEK Tech Conferenceは、株式会社WESEEKが主催するエンジニア向けの勉強会です。
月に2回ほど、WESEEKに所属するエンジニアが様々なテーマで発表を行う予定です。

次回は、8/5(木) 19:00~20:00に開催予定。

「jpg/png/svgに、最近はwebpなんてのも登場し、画像ファイル、結局何を使えばいいの…！？」「ベクターデータとラスターデータって、何が違う？」「結局、画像ファイル、なんでもよくないですか？」という方向けに、デザイナー目線での画像ファイルの解説を行います。

現在、connpassやTECH PLAYで参加受付中です。皆様のご参加をお待ちしております！
https://weseek.connpass.com/event/219585/
TECH PLAYはこちらから

一緒に働く仲間を募集しています

東京の高田馬場オフィス、大分にある別府サテライトオフィスにてエンジニアを募集しております。
中途採用だけではなく、インターンシップも積極的に受け入れています！

詳しい募集要項は、弊社HPの採用ページからご確認ください。

企業を超えたアジャイル+Railsを利用した開発の成功事例

目次