ENGINEERING ISAOの開発

ISAOのエンジニア

“たのしい”をうみだすために、欠かせないエンジニア。
十人十色、さまざまなスキルセットを持ったメンバーが揃っています。

エンジニア数

カテゴリ

好きな言語

使用エディタ

プロジェクトと開発体制

ISAOの自社サービスを支えるエンジニアの、仕事、取り組み、ポリシー。
彼等が日頃どんなマインドでプロジェクトを進め、チャレンジをしているのかをご紹介します。

goalous team goalous team goalous team english
Project-01

www.goalous.com

goalous team

「Goalous」プロジェクト

Goalousはチームが一体となってゴールを達成するための、最強にオープンな社内SNSサービス。
「GKA」という先進的な概念を取り入れています。

プロジェクトで大きな目標「Goal」を決め、ゴール到達に必要な指標を「KR (Key Result) 」として定めます。 そして達成に向けて日々活躍するみんなの業務を「Action」として、写真を使いながら投稿・共有。 活動状況をオープンにすることで、そこから新たなコラボレーションを次々と生みだしてゆく。

Goalousは、ひとつのプロジェクトだけではなく、組織全体の活性化を促すチームコラボレーションサービスなのです。


環境

メンバー内訳:Webエンジニア4人, PL1人
バックエンド: PHP7, CakePHP, MySQL, Redis, Nginx
フロントエンド:React, Redux, Angular, jQuery, webpack
インフラ: AWS (EC2, ALB, OpsWorks, RDS, ElastiCache, S3, etc)
ツール: GitHub, TravisCI, JIRA, Confluence, Slack, Vagrant, Chef, etc


チームの特徴

あなたのチームに、日本語がほぼ喋れないアメリカ人エンジニアが突然Joinすることになったとしたら、どうしますか?
異動願いを出す、頭を抱える、とりあえず筋トレをする、読経で心を鎮めるなど人それぞれだと思います。当時のチームメンバーは日本人だけで、皆あまり英語が得意ではありませんでした。
しかし、チームのコミュニケーションにおいて日本語のままだと彼を置いてけぼりにしてしまう。でも英語ムズカシイ。。そして皆で話し合った結果、僕らはついに決断を下しました。

「OK!これからは基本的に英語を使おう!!!」
それ以来、Slack、Gitコメント、ソースコメント、JIRA&Confluence、朝会…全てを英語に変更し、今に至ります。

英語に変更した当初は正直に言って非常に開発効率が落ちましたし、メンバーのストレスも多少あったと思います。それでも英語を続けた理由は、僕らがエンジニアとして英語が必須であることを理解していたから。
ポジティブに考えれば、ネイティブのアメリカ人と毎日ビジネスでの英語のやりとりができるのでこれだけ恵まれた環境はありません。
今では、まだ完璧ではないにしろ英語で技術的なディスカッションができるようになりました。
またブラジル人やインドネシア人のエンジニアも加わり、国際色豊かで非常に「面白い」チームとなっています。

英語がもたらしたものは新メンバーとのコミュニケーションだけではありません。
英語で書かれた多くの技術ドキュメントを読むことができ、ネットに居る世界中のエンジニアへ向けて技術的な質問ができるのです。
これは確実にエンジニアとしての幅を広げることにつながるでしょう。

Yes,we can.

  • HTTP/2移行を敢行した若きリードエンジニア、
    仕事のテンションを上げることが最も大切だと語る。

このプロジェクトのチャレンジ

Goalousのリードエンジニアを務めている吉田です。
以前、Goalousはサービス全体の大規模なパフォーマンス改善を行ったのですが、その際にHTTP/2に移行しました。

Read More ▼

なぜ移行したか
HTTP/2の大きな特徴でもあるリクエストとレスポンスの多重化によりサイトの高速表示を実現したかったからです。
HTTP/1.1の場合1つのリクエストが完了するまで次のリクエストを送ることができません。
この制約を回避するために、ほとんどのブラウザは1ドメインへの接続を同時に複数行うことで、通信の多重化を図っています。
ただ同時接続数には限りがあるため、リクエスト数が増えれば増えるほどヘッドオブラインブロッキングが発生してしまいます。
特に画像をメインとするGoalousはリクエスト数も多いのでパフォーマンスに悪影響を与えていました。
しかしHTTP/2では1つのTCP接続上でストリームと呼ばれる仮想的な双方向シーケンスを作ること(ストリームの多重化)によりHTTP/1.1の問題を解決しています。
このストリーム多重化によりリクエスト待ちを減らしたかったのもあり、パフォーマンス改善の施策のひとつとしてHTTP/2化することに取り組みました。
苦労した点
GoalousではAWSのOpsWorks(Chefを使用してクラウドエンタープライズでアプリケーションを設定および運用するための設定管理サービス)を使用しています。
そのOpsWorksのスタック設定とChefレシピ修正に非常に苦労しました。
HTTP/2はAWSのロードバランサーのELBではなくALBでないと使用できません。
従ってそれまでOpsWorksでELBと紐付けていた構成を変更する必要がありました。
しかしOpsWorksはELBとの連携はコンソール上で簡単にできますが、ALBと連携するための設定は備えていませんでした。
そこでALBに対してOpsWorksが管理するEC2インスタンスを紐付けるためのChefレシピを用意して、検証を重ねた結果何とかOpsWorksにより構成した環境でHTTP/2でのアクセスに成功しました。
これは「はじめの一歩」
正直今はまだHTTP/2のメリットを活かせているとは言えません。
HTTP/2はストリームの優先度・フロー制御・サーバプッシュ等の特徴も備えているので、これから徐々にHTTP/2のメリットを活かせるように改善するつもりです。
しかしGoalousをより高速に、より質の高いシステムにしていくための布石としてHTTP/2へ移行したことは良いチャレンジでした。
サービスの未来を見据えて、こういった布石を早い段階で打っておくことが大事だと私は思っているからです。

このHTTP/2化の取り組みを、ISAOのブログ(IsaB)で記事にしていますのでご覧ください。
“そうだ、HTTP/2に移行しよう(OpsWorks基本編)”
“そうだ、HTTP/2に移行しよう(OpsWorks実践編)”

Goalous

エンジニアとして目指しているもの

「テンションが上がって仕事ができているか」を私は重要視しています。
エンジニアとしてチャレンジングな仕事ができているかもそうですが、 それは面白くない仕事をどう面白くできるか、あるいは面白くない仕事をどう無くすかという意味も含んでいます。

楽しくないけどやらなければいけない仕事はあふれています。
例えばルーティーンとなっている退屈な手作業や、アプリケーションの負の遺産となっている箇所のコード修正とかは多分誰もやりたくないんですよね。(苦笑
なので、楽しくない作業自体を極力発生させないようにして、楽しい仕事に集中できるように改善することを考えています。
その方法のひとつが「自動化」ですね。
具体的にはTravis CIを使ったデプロイフローの自動化やSeleniumの自動テスト導入、あるいはAWSでコンソール上の面倒な手動設定をシェルスクリプト化すること等が挙げられます。
そうしてできるだけ自動化し退屈な作業を無くすことによって、テンションが上がる仕事、自分がやるべきことに集中できます。
もちろん自動化だけでは補えないものもありますが、不要な作業が発生している根本の原因を探ることは常に必要だと思っています。

仕事のやる気はパフォーマンスに直結します。
なので、自分の仕事へのモチベーションに向き合うことはこれからも意識したいですね。

Let’s do it together!
メンバー写真 Mamoru 業務風景
Project-02

mamoru-secure.com

メンバー写真

「Mamoru」プロジェクト

『Mamoru』は、ユーザビリティーとセキュリティーを両立した認証&ワークススタイルイノベーションサービスの統一ブランドです。
今回は MamoruシリーズのMamoru Bizというワークスタイルイノベーションサービスについてご紹介します。

ISAOのオフィスでは様々な”ちょっとしたもの”を販売しています。
朝食がわりの惣菜パン、置き菓子やドリップ式コーヒーにバーカウンターのアルコール類など、さまざまな種類と金額が混在しており、管理はとても面倒です。
Mamoru Bizの「ペイメント機能」はこれらの社内決済をQRコードで一括管理し、購入はバーコードを読み取るだけ。履歴は経理に集められ、給与天引きでキャッシュレスにしています。
他にも勤怠管理やフリーアドレスの課題を解決する「チェックイン機能」があり、勤怠システムと連携させることで打刻の手間をなくし、グラフィック機能で座席を可視化し誰がどこに座っているのかを把握できるようにしています。


環境

メンバー内訳:PL兼マーケティング1人、プログラマー3人、インフラエンジニア1人、デザイナー1人、バックオフィス1人
バックエンド: PHP7, MySQL, Redis, Laravel
アプリ:Swift, Kotlin
インフラ: Azure (Web App for Container, SQL Database, Redis)
ツール: GitHub, Slack, Docker, エディタは好きなもの etc


チームの特徴

まず技術面から。
Mamoruには認証サービスのMamoru PUSHとワークススタイルイノベーションサービスのMamoru Bizがあり、ほかにもここに書けないサービスがいくつかあり、これらは全てひとつのチームで開発しています。
Mamoruの各サービスが発展途上にあるため、それぞれのメンバーは「昨日はサービスAの機能を開発して」「今日はサービスBのバグ修正をする」ということがざらです。 そのため、なるべく多くのメンバーがどのサービスも開発できる状態をつくるようにしています。
それぞれのメンバーが技術的に得意領域を持ちつつ、重なる部分を広げていくイメージです。

Azureで新しい技術を導入する際には Azureを得意とするメンバーが関わりますが、既存環境に手を入れるような場合は他のメンバーが作業を行うこともあります。
普段コードを書かないメンバーも、場合によってはGitHubにPullRequestを送ります。 コードレビューは誰かが行うスタイルで、マージすると社内で利用しているステージング環境にリリースされ、その後本番環境へリリースする手順を取っています。
それぞれが得意な技術を深堀りしつつ、技術の幅を広げる。メンバーの冗長化という側面もありますが、ISAOが大事にしている"成長"の機会を促進する意図も含んでいます。

ビジネス面では、各サービスのドメイン知識が豊富なPLが中心に施策を打っています。
業界との繋がりも多く、最近では某セキュリティー団体をリードされている外部の方に勉強会を開いていただきました。こういった貴重な機会を得ることができるのは、Mamoruチームならではかもしれません。

  • Mamoruのメンバーは、全員が自走できるエンジニア。
    本番環境へのDocker導入と、目指すエンジニア像を語る。

このプロジェクトのチャレンジ

インフラを担当している秋山です。
技術的なチャレンジとして、Mamoru BizでDockを本番環境に導入しました。

Read More ▼

なぜ導入したか
Docker を動かすインフラはMicrosoft AzureのWeb App for ContainerというDockerのPaaSサービスを採用しています。
Mamoru Biz の開発にDockerを採用した理由としては、MamoruがAzureを全面的に利用していることが前提ではありますが、Docker によって開発環境や本番環境を同じ環境にし、かつ特定クラウドにロックインされないポータビリティが得られる点にあります。
Web App for Containerは2017年9月に正式リリースしたばかりですが、私が Mamoruとは別のプロジェクトで取り組んでいるインフラ事業でもお客様環境で利用しており、導入への抵抗はほとんどありませんでした。
ほぼ同じ構成を採用している別のサービスについて書いたISAOのブログ(IsaB)記事は下記です。
“LAMPのシステムをAzureの PaaSに移行しました”
導入障壁
Dockerをプロダクションで採用するとなると、プログラマーがそれに対応できるかが問題になりがちですが、ともにMamoru Biz を推進していたメンバーはDocker採用に前のめりだったため、僕らには問題になりませんでした。
Web App for ContainerはひとつのDockerコンテナを動かす Webに特化した PaaSなのですが、Mamoru BizのDockerfileは彼に用意してもらい、私はレビューするだけでした。Web App for ContainerはひとつのDocker コンテナを動かすWebに特化したPaaSです。Mamoru BizのDockerfileはメンバーが用意し、私はレビューするだけでした。
デプロイフローは今回Docker Hubのプライベートリポジトリを利用しています。Git Hubからのインテグレートがどのように動くか、メンバーに使ってもらい、体感してもらいながら託していきました。
デプロイフローについても IsaBに書いています。
“Azureエンジニアから見たDockerを取り巻くDevOpsサービスのまとめ”

ISAOのエンジニア
こういったようにプロジェクトを進める際は、基本的な Azureサービスの使い方やポイントとなる部分を私がプログラマーに説明し、プログラマーには自分で使って慣れてもらう、という形を取ることが多いです。
多くの人がほかのプロジェクトを兼任しているため、同時にひとつの作業に向き合う時間は限られます。ナレッジを共有しつつもそれぞれが「自走できるエンジニア」としてふるまうことがISAO では求められるといえるでしょう。裁量が大きいことを好む方には合っているかもしれませんね。

業務風景

エンジニアとして目指しているもの

もともとプログラマーをやっていた経験があり、今はインフラ寄りのエンジニアをやっています。
DRY, YAGNIといった原則をサービスの機能という意味だけではなく、プロジェクト活動の中でも常に念頭に置いて日々の業務を進めています。

たとえば、Azureはクラウド市場でAWSを追い上げる2番手ですが、同時に、AWS経験があるエンジニアはISAOに限らず世の中にあふれています。
Azureを追っているエンジニアは、入社時のISAOには多くなく、私がその領域を切り開くことで活躍の機会が多くなるのではないかと考え、率先して Azureへの理解を深めました。

また、インフラエンジニアでプログラムを書くことに抵抗がなかったり、サービス開発をしていてインフラにどういうものを求めるかの肌感覚を持っている人はそこまで多くないように感じます。
インフラの視点とプログラマーの視点、両方を持つエンジニアとして、ISAOへフィードバックできるものがあると考えています。

あとは、個人としてもちょっとしたハックを何かしら続けるようにしています。
Railsや Electron, React, RaspberryPiなど、そのとき気になったものに触れてきました。
ITの世界では遊びで触っていた技術を1年後に仕事で使うことになる、といったことはザラに起きるもの。フットワークの軽い取り組み、マインドを持ち続けることが大切。
「やったことがいつか自分に返ってくる」瞬間を実感できるのは、とてもうれしいですね。

Let’s do it together!

ナレッジ・マネジメント

エンジニアに必要なものは、日々変わってゆく技術を自らの興味の向くまま追いかけるドライブ力。
けれどそれだけでは偏ってしまうし視野も狭い。では、どうするのか。
ISAOで行われているオープンなナレッジ交換をご紹介します。

社内外向けセミナー
パートナー企業からの情報提供や、自分の関わったプロジェクトで得たノウハウを社内外へ向けて発信しています。
この他にも、やりたい人が手を挙げて聞きたい人があつまる、カジュアルな社内セミナーも開催されています。
社内外のメディアで情報共有
今日仕事でやったこと。やってしまった失敗。チャレンジした新しい試み。気になったTechニュース。
さまざまな「今日のこと」を社内SNSで発信&情報交換。

ISAO Qiita

IsaB

RECRUIT

ISAOでは新卒・第二新卒・中途にかかわらず通年採用しております。
ガンガン成長しながら、世界を楽しくするサービスを生み出したいという方、ぜひご応募ください!

世界の仕事をたのしくする
英語切り替えバナー