画面制作(html, css)をエンジニアが行うようになってからの課題と取り組み

暮らしニスタのPMを担当しているウィルゲートの水口と申します。 暮らしニスタの開発チームでは、2016年のリニューアルリリース以降、画面のコーディングをエンジニアが行っています。今ではスムーズに開発ができていますが、最初はうまくいかなかった事もありました。今回はエンジニアが画面コーディングを担当するようになってからの問題点と、これまでどう改善してきたかについて紹介させていただきます。

リニューアルまでの制作フロー

f:id:mizuguchi-harumi:20181010194019p:plain

デザイナー(制作会社など)からHTML、CSS(scss)を受け取り、エンジニアはフレームワークへの反映のみ行っていました。

リニューアル以降の制作フロー

f:id:mizuguchi-harumi:20181010194030p:plain

デザイナーはデザインまでを担当、エンジニアがHTML、CSS(scss)をコーディングするようになりました。

エンジニアが画面制作するようになってからの問題点

画面制作スキルのバラツキ

ほとんどのエンジニアが画面コーディングを担当してなかったので、メンバーごとに画面コーディングの得意不得意がありました。はじめはフロントが得意なエンジニアに画面制作の担当を寄せていましたが、それだけでは工数が足りないこともありました。ただし不得手なメンバーが担当すると、工数がかかってしまい、全体的な開発コストが膨らんでしまっていました。

デザインの連携

一部を除いてエンジニアは高機能なデザインソフトを持っていません。デザインコーディングに必要な色、サイズ等の詳細な設定値を図る方法が確立されていなかったため、デザインの把握に時間がかかっていました。

修正・手戻りの発生

デザインの連携が上手くいかなかったこと、制作に慣れていないなどが影響して、制作後のレビューとその修正に膨大な時間がかかっていました。また、画像では伝わらない画面動作等の動的な部分について、後から指摘を受けることもあり、手戻りが沢山発生していました。

上記のような問題が半年くらい続き、デザイナーも含め、メンバー間の協力体制も揺らぎかけてきました。
もっとスムーズに開発が進められるように、デザイナー、フロントエンジニアを中心にチームで改善を行ってきました。

現在のフロー

f:id:mizuguchi-harumi:20181010195008p:plain

フローと担当者は変わっていませんが、連携方法が変わりました。

改善したポイント

デザイン連携にZeplinを導入

以前は画像での連携でしたが、Zeplin(https://app.zeplin.io)というツールを使うようにしました。 このツールの導入により、デザインコーディングの制作工数と手戻りが減少できました。 ZeplinはSketchデータから簡単に作成でき、連携に使える機能が色々あります。

①要素の設定値が表示される

コーディング時に必要なサイズや色等の設定値が表示されます。 f:id:mizuguchi-harumi:20181011201106j:plain

②スタイル属性値の自動生成

ある程度の表現は自動で出力されるので、コーディング時に細かい属性を考えなくても良くなりました。

③コメント機能

Zeplinは画面にコメントをつけることができます。 デザイン画像からは判断できない事などデザインの不明点を書いたり、制作後レビューのフィードバック連携にも利用しています。 f:id:mizuguchi-harumi:20181011201113j:plain

デザインパーツの共通化

デザインの体系化・デザインガイドライン作成

ページ毎、エリア毎にデザイン制作が行われていたため、サイト内に様々なデザインが混在していました。似たようなデザインなのに、要素が統一されていないため、バラバラにCSSをコーディングする状態になっていました。
デザイナー中心にガイドラインの整備を行い、色、文字サイズ、間隔等設定値の整理からはじまり、ボタン、見出し、リスト等のデザインについても統一されました。
今では各ページのデザインについても体系化されたデザインに沿って作成されるようになっています。

スタイルガイドの整備

フロントエンジニアを中心に、CSSの構造の見直しと、体系化したデザインをもとにスタイルガイドを整備しました。

設定値の共通化(色、文字サイズ等)
f:id:mizuguchi-harumi:20180903133317p:plain

パーツ(ボタン、アイコン、画像等)の共通化
f:id:mizuguchi-harumi:20180905165656p:plain

レイアウト(グリッドシステム等)の共通化
f:id:mizuguchi-harumi:20180903134746p:plain

リスト型のレイアウトやグリッドシステムについても共通化され、楽にレイアウトを表現できるようになりました。

デザイン共通化によって、同じようなデザインを何度も書くと言うことが減りました。また、必要なコーディング量が減ったので、画面制作が得意ではないメンバーもスムーズに画面を作ることが可能になりました。

コミュニケーションの増加

デザイナーとエンジニア間でデザインの要件や意図の連携がうまくいかず手戻りが発生したり、デザインのコーディングの難易度が高すぎて、最初の見積りより工数がかかってしまうことがありました。
デザイン制作前に要件と方向性の確認し、画面制作に取り掛かるまえから認識齟齬を減らすようにしています。また、デザインコーディングの前や途中でも、密にコミュニケーションをとり、コーディングの難易度が高すぎる場合に簡単な表現に変更できないか、デザインガイドラインから離れている箇所があれば統一できないかなどの実装上の相談を都度行うようにしています。

最近の課題

これまではデザイナーが常に社内にいることが多かったのですが、最近ではデザイナーがリモートにいる事が増えてきました。基本的にはSlackで連携していますが、文字では伝わりにくい場合は、電話やSlackの動画チャットを使うようにしています。

まとめ

今回はエンジニアがコーディングを担当するようになってからの問題とどのように改善してきたかについてご紹介しました。
改善を通して、エンジニアメンバーが画面制作をスムーズに行えるようになりました。その結果、デザイナーはデザインに専念することができ、エンジニアも画面制作以外の開発にも時間を避けるようになり、チームの全体の生産力向上につながったと感じています。

Embulkを活用してAmazon Elasticsearch Serviceへデータを同期させた話

こんにちは。インフラチームの高畑です。

今回は Elasticsearch (ES) を AWS に移行した際に導入した Embulk についてお話しします!

Embulkとは

Embulk とは、 Fluentd の開発者である古橋貞之氏によって開発された、 Fluentd のバッチ版のようなものです。 プラグインにより、インプットとアウトプットを柔軟に切り替えることが可能となっており、バルク処理に特化しています。

Fluentd と Embulk の違い
Fluentd
  • データのストリーミング転送
  • 既存の大量なデータは転送ができない

Embulk
  • 定期実行によるデータ転送
  • 分散処理により既存の大量なデータを転送できる

Embulkで利用できるプラグインは以下の通りとなっています。

プラグインの一覧はこちら

Input Plugin RDS、S3、GA、ES・・・・・
Output Plugin RDS、S3、GA、ES・・・・・
Filter Plugin カラムを削ったり、再構成したり
File Parser Plugin
File Decoder Plugin
File Formatter Plugin ファイル関係
File Encoder Plugin
Executor Plugin Hadoop上で実行させたり

導入前

これまで、サービスで利用する ES を自前で構築し、JDBC ドライバを利用して RDS から ES に対しデータを転送していました。 また、ログ基盤として EFK (ES + Fluentd + Kibana) をAWS のマネージドサービスを用いて構築を行なっていました。

サービスで利用する ES を AWS ES に統一しようと考えていたのですが、AWS ES は JDBC を利用したデータ転送が出来ないという問題があり、サービス用の自前 ES とログ基盤用 AWS ES が混在するという無駄な状態となってしまいました。

そこで、これらを解決するため、JDBC での転送をやめ Embulk を利用してデータ転送を行うことにしました。

f:id:tkhttty:20181005143003p:plain

導入後

Embulk の設定ファイルはとてもシンプルな構造となっており、 RDS からデータを取得して ES へ送るだけであれば以下のように設定するだけで動作します。

(括弧で括っているところは環境に応じて変更する必要があります)

f:id:tkhttty:20180921164109j:plain

Embulkを活用して 1 日 1 回の同期処理をさせることにより、AWS ES に RDS のデータを流せるため、自前の ES は不要になり ES の混在状態を解消することができました。

またこれにより、自前で ES を管理する必要がなくなり運用コストの低下にもつながりました。

f:id:tkhttty:20181005142043p:plain

おわりに

Embulkを活用することにより、自前で構築していたESを使う必要がなくなり運用コストの削減に繋げることができました。

同様なことで悩んでいる方がいらっしゃいましたらぜひ活用してみると良いかと思います!

アプリもくもく会を開催して感じたこと

はじめに

こんにちは。ウィルゲートで開発を行っている三島です。 私の所属するメディアチームでは「暮らしニスタ」や「Milly」などのメディアサイトの構築と運用を行っています。また、webサイトだけでなくwebViewではありますが、スマートフォンアプリの開発も行っています。

今回はメディアチームでアプリについて学ぶ時間として開催している「アプリもくもく会」について紹介していきます。

f:id:MikaE:20180906214635j:plain

もくもく会を開いた背景

アプリ開発は2016年から行っていますが、ウィルゲートではこれまでwebサイト構築を主に行ってきたため、アプリ開発についての知見がありませんでした。 これまではwebViewのアプリであったため、ネイティブアプリに比べ開発難易度が低く、なんとか調べながら開発を行っていくことができていました。

アプリができてから2年ほど経ち、アプリを使ってくださるユーザーが増えてきたため、 更に使いやすいアプリにするために、アプリをネイティブ化することが決まりました。

ネイティブアプリはこれまで作成してきたwebViewのアプリよりも難易度が高く、知らないことが多いです。そのため、これまでのようにトライアンドエラーを繰り返すことは効率が悪いと感じていました。 アプリ開発を1から調べながら学ぶことは効率が悪いため、ウィルゲートでは社外のネイティブアプリ開発に知見を持っている方にアプリの技術顧問として入っていただけることが決まり、アプリ開発についておしえていただけることになりました。 技術顧問についての詳細は下記の記事を見てください。

tech.willgate.co.jp

ネイティブ化に向けて技術顧問の方に入っていただき、アプリ開発における疑問点は解消できていますが、今後webViewからネイティブへ移行することでこれまでよりもアプリの保守工数が増加することが見込まれています。 しかし、現在チーム内でアプリの開発を行っている人が私以外にいないため、必然的に対応できる人も1人です。今後アプリを開発保守していくためにも、チームとして技術の底上げが必要だと感じていました。 チームとして技術を底上げするためにアプリについて学ぶ時間を作る必要があると感じていました。アプリについて学ぶ時間として勉強会やもくもく会などがありますが、メディアチームではもくもく会を開催することにしました。

勉強会ではなくもくもく会を開催することにした理由としては以下の2点です。

  • 勉強会の形式にもよりますが、もくもく会のほうが実際に自分でコードを書く時間が多く各自のレベルに合った勉強ができる
  • 各自で勉強をしてもいいが、勉強するためには強い意志が必要になるので集まって勉強をしたほうが続きやすい

もくもく会でやっていること

もくもく会では一般的なもくもく会と同じように時間が空いた人が集まって個人でアプリについて学ぶ場にしています。 ただ漠然とアプリについて調べたり、コード書いたりするだけでは効率が悪いので、mixiさんのiOSTrainingやAppleのswiftのチュートリアルなど基礎的なことを学ぶ事ができる資料を見ながら勉強しています。

iOSTrainingはXcodeの使い方やSwiftの書き方など基礎的なところから学ぶことができるため、初心者の方におすすめできる資料だと思っています。

GitHub - mixi-inc/iOSTraining: Training course repository for iOS app developmentgithub.com

Appleのswiftのチュートリアルは英語で書かれているため読むことに時間がかかってしまいますが、簡単なCRUDのアプリを作ることができるため、楽しく学ぶ事ができるのでおすすめです。

developer.apple.com

もくもく会の感想

良かったこと

良かったこととしては、チュートリアルを進めていくことで基礎的な力はついたと感じています。また、これまで1人で勉強をしていたため疑問の解消に時間がかかっていましたが、チームで勉強を行うことで他の人に質問をすることができ、より効率よくアプリ開発について学ぶことができています。特にこれまで1人で調べ1人で解消していたため孤独を感じていましたが、雑談しながら勉強することで楽しく勉強ができ良かったと思います。 時間を作って参加してくれたチームメンバーには感謝しか無いです。

反省点

チュートリアルをこなすことで基礎は学ぶ事ができたと思いますが、実際のプロダクトコードでは応用が求められます。もくもく会チュートリアルで学んだことを実際に使ってみることができなかったです。今後は実際に題材を決めアプリを作ってみるなど応用を学ぶ事ができるように工夫していきたいです。

まとめ

アプリもくもく会を始めて3ヶ月経ち、全体として基礎的な知識はついてきたと感じています。 今後こういった活動を続けていくことで、ウィルゲートの開発組織全体としてwebアプリだけでなくネイティブアプリを開発できるようになり、より多くの人にサービスを利用してもらえるようにしていきたいです。

Chrome DevToolsを使用してサイトのパフォーマンス改善をしてみた

こんにちは!開発室メディアユニット所属新卒1年目の小澤です。
ウィルゲートでは現在(2018年9月1日)4つのメディアを出版社と協業で運営しており、そのうちの3つを自社で開発、運用・保守しています。

暮らしニスタ|知りたい!教えたい!暮らしのアイデアがいっぱい!

Milly ミリー|妊娠・出産・子育ての“今知りたい”をすぐ解決

花時間 | 花やグリーンから始まるボタニカルライフの提案

PV数や回遊率を上げるためには良質なコンテンツを提供するのはもちろんですが、その他にできる取り組みとして、UI・UXの改善、表示速度のチューニングなどがあります。
今回は、ページの表示速度を改善する一歩目として、webブラウザGoogle Chrome」に標準で搭載されている 「Chrome DevTools」を利用して簡単にサイトスピードを計測する方法を紹介します。

Chrome DevTools(旧:DeveloperTools)とは?

Googleの開発者向けサイト、Google Developersによると、

Chrome DevTools は、Google Chrome に組み込まれたウェブ作成およびデバッグツールのセットです。 DevTools を使用してサイトの反復処理、デバッグ、プロファイリングを行います。

と書いてあります。
詳しくはこちらをご覧ください。

developers.google.com

具体的な用途としては、表示崩れの原因特定、JavaScriptデバッグ、表示速度のチューニングなどがあります。
webエンジニアなら一度は使ったことがあるのではないでしょうか。
非常に多機能で本記事では紹介しきれないので、表示速度の計測方法に絞って紹介します。

表示速度の計測

今回は自社で開発、運用・保守している暮らしニスタの速度を計測します。

現在の表示速度を計測する
  1. Google Chromeで計測したいページを表示させます。
  2. Chrome DevToolsを表示させます。
    Chrome DevToolsはコンテキストメニューかキーボードショートカットから表示できます。

ウィンドウ上部にパネル名があり、標準で9つの機能がそれぞれ強力な機能を提供します。
速度を計測するためには、「Performance」タブを選択します。

google dev toolsの画像

Performanceタブ右上の歯車マークをクリックすると計測時の設定ができます。

f:id:rikipedia-5r:20180903210821p:plain

Network

計測する際の回線速度を設定できます。デフォルトは「Online」で、速度はPCが接続しているネットワークに依存します。他にも「Fast 3G」「Slow 3G」「Offline」がプリセットとして用意されており、カスタム設定もあります。

CPU

Google Chromeに割り当てられたCPUリソースの使用量を設定できます。デフォルトは「No throttling」で、特に制限は設けません。他にも「4× slowdown」「6× slowdown」がプリセットとして用意されています。

今回の計測での設定は次のようになります。

対象ページ バイス 回線速度(上り) 回線速度(下り)
https://kurashinista.jp PC 97Mb/s 97Mb/s

回線速度を一定にし、PC版の暮らしニスタトップページを計測してみます。

計測してみる

それでは早速計測してみましょう。
Performanceタブ左上の更新マークをクリックすると計測が始まります。

f:id:rikipedia-5r:20180903211226p:plain

ページによっては計測に時間がかかるのでしばらく待ちます。

f:id:rikipedia-5r:20180903211035p:plain

計測が終わりました!

f:id:rikipedia-5r:20180903211412p:plain

計測結果の詳細を説明します。

f:id:rikipedia-5r:20180903212021p:plain

①:レスポンスからページの表示が完了するまでに何が起こっているかの概要が分かります。
縦の赤線が引いてある箇所は、ページの表示が完了した時点を表しています。
赤線が引いている箇所を左端までドラッグすると、ページの表示が完了するまでの数値が分かります。 上記画像では700msあたりからページの描画が始まり、赤線が引いてある3200msあたりで表示が完了しています。

②:①で選択した範囲で何が起こっているかの詳細が分かります。
Summaryタブでは、大きく分けて6つの数値を見ることができます。

Loading

与えられたURLからHTMLを読み込んで、そこから更にレンダリングに必要な付属するリソースを読み込んで解釈していきます。 このフェーズでは主にリソースのダウンロードとパースを行います。 リソースを一式読み込んだ後、JavaScript実行(Scripting)へ移行します。

Scripting

レンダリングエンジンが、JavaScriptのコードをJavaScriptエンジンに引き渡して実行させます。

Rendering

JavaScriptの実行が終わると、今度はレイアウトツリー構築(Rendering)に移行します。この中ではスタイルの計算(Calculate Style)とレイアウト(Layout)という2つの処理が行われます。

Painting

DOMツリーのレイアウト情報の算出が終わると、最後のレンダリング結果の描画(Painting)に移ります。このフェーズでようやくレンダリングエンジンはユーザーが見ることができる実際のピクセルを描画します。ここでは、ペイント(Paint)とラスタライズ(Rasterize)とレイヤーの合成(Composite Layers)という3つの処理が行われます。 最後のComposite Layersが終わることで、ユーザーの目にはレンダリングエンジンが描画した画面が表示されます。

Other

JSエンジンのイベントループに対するオーバーヘッドの時間です。

Idle

JSやCSSなど、リソースをダウンロードしてからレスポンスが返ってくるまでの待ち時間です。

(以下から一部抜粋)

Webフロントエンド ハイパフォーマンス チューニング

Webフロントエンド ハイパフォーマンス チューニング

計測結果
Loading(ms) Scripting(ms) Rendering (ms) Painting(ms) Other(ms) Idle(ms) 合計(ms)
976.0 1215.8 330.7 57.2 578.6 720.6 3,000.5

ページの表示が完了するまでに約3秒かかっています。 日本ラドウェア株式会社の調べによると、操作開始時間の理想的な数値は3秒だと言われています。 ぎりぎり3秒台なので及第点ですね。

webtan.impress.co.jp

ちなみに理想は表示速度が爆速で有名な阿部寛のホームページです(笑)。

f:id:rikipedia-5r:20180903214442p:plain

同じ条件で計測してみたところ、暮らしニスタの約15分の1でした。道のりはまだまだ長そうです。

ボトルネックの特定

約3秒の内訳の内、40%がScriptingに使われています。 Scriptingは、先程も述べたようにJSの構文解析を行うフェーズです。 つまり、JSの容量が大きいとそれだけ読み込みにかかる時間も増えるということです。

Scriptingに問題があるということがわかったので、次に実際にボトルネックとなっているファイルを特定します。

Summaryと同じタブの「Call Tree」タブを選択します。 次に、列「Activity」の「Scripting」を選択します。 そうすると、Scriptingの中で具体的にどのイベントにどれだけ時間がかかっているかが「Evaluate Script」で分かります。

f:id:rikipedia-5r:20180903220157p:plain

青枠で囲ったあたりが今回のScriptingの大半を締めているので、この箇所がボトルネックであると分かります。 ちなみにボトルネックのファイルをたどったところ、どうやら広告の読み込みに時間がかかっていたようです。 さらにどのファイルのどこがボトルネックであるかを調べるにはJSプロファイラを利用して特定することができますが、今回の本題とは別の話なので割愛します。

対策

広告の読み込みに時間がかかっていることがわかったので、各広告の読み込みにかかる時間を計測し、 とりわけ時間のかかっている広告は一旦取り外し、その他にはasync属性をつけることによって広告の読み込みでrenderingをブロックせず、documentの解析が終わったらscriptを読み込むようにしました。 この対策によって、広告の読み込みにかかっていた時間を大幅に短縮することができました。

最後に

今回はChrome DevTools使った簡単な速度の計測方法を紹介しました。 計測の方法は他にもたくさんあり、上記のようなやり方が正解とは限りません。 ちなみにGoogleが公式で推奨しているパフォーマンスの分析方法なども紹介されていたりします。

developers.google.com

あくまでも参考程度に考えておくと良さそうです。

おまけ:速度計測の自動化

Chrome DevToolsを使い、何回か計測した平均などを求めたい場合、出力された数値を毎回コピペするのはとても煩雑で手間がかかります。 そこでおすすめなのが、サイトスピードを自動で計測し、リッチに表示してくれるsitespeed.ioです。

f:id:rikipedia-5r:20180903223058p:plain

コマンド一発で指定したURLに対して計測を自動で行います。 計測する際にはヘッドレスブラウザを使用し、詳しい値を計測しています。 他にもユーザーエージェントの選択やBasic認証などにも対応しているので、とても便利です。

それでは良い開発ライフを!

Fluentd(td-agent)とNorikraを活用したDoS対策をメディアに導入したお話

こんにちは。インフラチームの高畑です。

今回、弊社で運営しているメディアに Fluentd と Norikra を活用した DoS攻撃対策を導入したのでご紹介いたします!

導入に至った背景

これまでは Apache のモジュールである「mod_dosdetector」を利用して DoS攻撃の対策を行なっていました。

mod_dosdetector とは
同一 IP アドレスから一定回数のアクセスがあった場合に、環境変数「SuspectDoS」または「SuspectHardDoS」をセットするモジュール。
セットされた環境変数の値を使い、「mod_rewrite」で DoS攻撃と判定されたアクセスを 503 へリダイレクトさせることによりアクセスを遮断する。

しかしながら、 mod_dosdetectorApache 2.4 以上には対応していないため、最新の Apache を導入している場合などには利用ができませんでした。 また、全サーバに対してアクセス制限ができない、ファイアウォールで防げないという問題もあり mod_dosdetector の利用を諦めることになりました。

そこで、ログ収集管理ツールであるFluentdとログのストリーミング解析ができるNorikraを活用して DoS攻撃対策を行うことにしました!

Fluentd とは
全てのログをJSONとして扱うことを目的として開発されたログ収集管理ツール。
入出力のプラグインが豊富で、S3やElasticsearchなどにもログを送信することができる。
Norikra とは
Norikra is an open-source Stream Processing Server with SQL.

・Schema-less event streams (called as 'target')
SQL processing with window specifier supports, and JOINs, SubQueries
・Complex input/output events with nested Hashes and Arrays, and Query supports
・Dynamic query registration/removing, without any restarts
・Ultra fast bootstrap and small start
・UDF plugins

公式githubより引用)

Fluentd + NorikraでDoS攻撃の対策をする

当初、 Norikra で検出されたイベントを各サーバが取りに行く構成にしようと思っていたところ、一度でもイベントを取得したらそのイベントは消え、そのほかのサーバがイベントを受け取れないという状況になりました。

そのため、下図のような構成に変更を行いイベントを受け取る Fluentd を Norikra サーバに同居させることになりました。

f:id:tkhttty:20180907113546p:plain

  1. Norikra サーバに対して各メディアのフロントサーバから Fluentd でアクセスログを送信
  2. ログを受け取った Norikra サーバは登録された SQL をもとにアクセスログを解析
  3. 検出されたイベントを Norikra サーバの Fluentd でキャッチし、各サーバに対してイベントを送信
  4. イベントを受け取った各サーバはシェルスクリプトからファイアウォールに該当 IP アドレスを登録
  5. 一定時間が経過したらアクセス制限を解除

これにより、検出された IP アドレスに対して全サーバで同時にアクセス制限をかけることが可能となりました。

おわりに

Fluentd と Norikra を組み合わせることにより、すごく手軽に DoS 対策を行うことができました。

NorikraでDoS攻撃を検知した際に Slack やメールで通知を行うこともできるので、より早く発見できるようになりました!

AWS Shield などのサービスが使えないような環境にはとてもおすすめです。

スマホアプリ内製化に向けた取り組み!アプリ技術顧問に参画いただきました

はじめに

はじめまして!メディアユニットでマネージャーをしている福原です。 メディアユニットでは毎日の生活をもっと豊かにするアイデアメディア『暮らしニスタ』をはじめ 複数のメディアサービスの開発を担っています。

本ブログでは暮らしニスタのスマホアプリリニューアルにあたって アプリ技術顧問に参画いただいた話についてご紹介いたします。

技術顧問を採用した背景

『暮らしニスタ』は二年前にほぼwebviewのiOS/Androidアプリを 当時在籍していた業務委託の方に2ヶ月で作っていただきリリースいたしました。

ただウィルゲートは以前からwebを中心に事業拡大してきた背景があり、webの開発においては社内にかなりのナレッジが貯まっているもののスマホアプリ開発に関しては一切のナレッジがありません。 したがってリリースしてからの二年間、半ば放置に近い状態で温めてまいりました。

ただそんな中でもアプリを使ってくれるユーザーさんが多数おり、そのユーザーさん達に長い間『暮らしニスタ』を使い続けてもらえるように、また他のメディアサービスでもアプリ化構想があり社内にアプリ開発・運用のナレッジを蓄積したいということでアプリをリニューアルすることになりました。

右も左もわからない中で時間を掛けて自分たちだけで一からリニューアルするよりも、専門家の方に知見をいただきながら進めていく方が、期間や品質、その後の保守も含めればコストの面でも良いという判断でアプリの技術顧問採用にいたりました。

技術顧問の採用軸

技術顧問を採用する上で以下4つスキルを重視して選定いたしました。

1.アプリ開発の技術選定スキル(重要度:高)
Swift, Objective-C, Java, Kotlin, ReactNativeなどなど多様な言語やフレームワークがあるなかで、それぞれのメリデメを理解しており適切な技術選定が出来る(アドバイス出来る)

2.アプリ開発の設計スキル(重要度:高)
チーム・アプリの規模・メンバーの習熟度などを踏まえた上で運用効率の高い設計、複数メディアに展開する上で汎用性の高い設計が出来る(アドバイス出来る)

3.アプリ開発の実装スキル(重要度:中)
現役でアプリ開発を行っており、鮮度の高い技術指導が出来る。コードレビューが出来る

4.アプリのグローススキル(重要度:低)
アプリのリテンション向上やインストール数を伸ばすノウハウを持っている

また上記以外でもウィルゲートと同様の課題を抱えた会社の顧問経験であったり、ご指導いただく上でコミュニケーションが取りやすい(人柄的に)など様々な観点で選定させていただき、 株式会社サーキュレーションhttps://www.circu.co.jp/)にご紹介いただいたラグナロク株式会社(https://ragna-rock.com/)の西本誠さん(以下、西本さん)にお願いすることにしました。

f:id:akys-fkhr:20180904111452j:plain

技術顧問との連携方法と具体的な相談内容

基本的には週1回来社いただき1時間半のMTGを実施する形式をとっています。またSlackでも必要に応じて都度コミュニケーションをとっています。

具体的な内容としては大きく2つに分類できます。 1.開発の進め方について相談・ディスカッション 2.開発を進めていてわからないことを質問 進め方を相談した上で一週間開発を行い、そこで出た疑問や問題点を翌週に質問するという流れで進めていました。

開発の進め方について相談・ディスカッション

例)
・設計していく上でアーキテクチャどう選定すればいいですか。(MVC,MVP,MVVMなど)
ディレクトリはどういう分け方をするのがいいですか。
・共通処理はどこに書くのが適切ですか。
・StoryboardとViewControllerでどう役割を分けるべきですか。

開発を進めていてわからないことを質問

例)
・複数のcollectionViewが存在する場合にDelegateはどこに記載するべきでしょうか
・StoryboardのViewで選択したdevice幅でビルドされてしまいます
・iOS9の場合にAutoLayoutで制約の重複が発生しcrashしてしまいます

その他こんなことを質問してました

例)
・コーディング規約ってどうやって決めていけばいいでしょうか
・初心者が学習を進める上でおすすめの方法はありますか
・データ分析は何のツールを使っていますか
・デプロイツール何使っていますか

f:id:akys-fkhr:20180904111253j:plain

まとめ

アプリ技術顧問の西本さんに参画いただいてから約3ヶ月。技術選定・設計が終わりネイティブページ開発やPush通知構築を進める中でアプリ開発内製化に確かな手ごたえを感じています。 求めていたアプリ開発についてはもちろん、それ以外にもアプリ業界の動向や他社事例などを幅広い知見をいただけており技術顧問の西本さんに参画いただいて本当によかったなと思います。 また技術獲得のため顧問採用に投資してくれる会社の方針・文化も本当にありがたいですね。 今後アプリ以外の分野に関しても、こういった形で更なる技術力向上を検討すべきだと思いました。

SQSで処理を非同期化したらストレスフリーになった

f:id:cocoeyes02:20180725091923j:plain

こんにちは。サグーワークス開発チームに所属している大津です。

サグーワークス開発で Amazon Simple Queue Service (以下 SQS と呼ぶ)をサービスに導入したので、SQS の紹介と実際に導入した例を紹介したいと思います!

今回は他のメッセージキューイングサービスなどには触れず、あくまで SQS にテーマをしぼってお話ししていきます。

SQS とは?

SQS は AWS ( Amazon Web Services )が提供しているメッセージキューイングサービスです。

キューへメッセージを送信、あるいはキューからメッセージを受信・削除をすることができるシンプルなサービスになります。

キューを介してメッセージを送受信することで、異なるシステム同士でデータの送受信ができます。

メッセージキューイングサービスのメリット

メッセージキューイングサービスの最大のメリットは、システム同士が同期していなくてもメッセージのやりとりができることにあります。

それぞれシステムが好きなタイミングでメッセージを送受信することができます。

SQSを導入 -導入背景-

CRM からサグーワークスへ自動で情報を登録したい

サグーワークスには運営者用の管理機能があります。

それとは別に、CRMでも情報を管理しています。

サグーワークス上でも CRM で管理している顧客情報が必要だったので、CRM からサグーワークスへ手動で顧客情報を登録していました。

以下がその手順と図になります。

f:id:cocoeyes02:20180904095301p:plain

  1. CRM から サグーワークス DB に保存したい顧客情報を確認する
  2. 管理画面から手動で顧客情報をサグーワークス DB に登録する

手動で顧客情報をサグーワークス DB に登録するため、この方法では手間がかかるという問題がありました。

そこで、自動化も含めて運営者用の管理機能をリニューアルしようという話になりました。

仕様変更の影響を減らしたい

自動で顧客情報をサグーワークス DB へ登録するにあたって1つ問題がありました。

CRM でデータの持ち方に関する仕様変更があったとき、サグーワークスのシステムでもあわせて変更する必要がありました。

どう解決するか悩みましたが、「ロジック」と「タイミング」2つのアプローチで仕様変更の影響を減らすことに決めました。

ロジックを分けて疎結合にする

CRM 周りのロジックは「 CRM から顧客情報を取得するロジック」と「取得した情報を保存するロジック」の2つに分けて疎結合にします。

もし CRM 側で仕様変更があっても、「 CRM から顧客情報を取得するロジック」だけ修正すれば対応することができます。

タイミングを分けて処理を非同期にする

CRM への顧客情報を取得する処理とそれ以外のサグーワークスの処理を非同期にします。

そうすることで、CRM への顧客情報を取得する処理でエラーがあっても、それ以外のサグーワークスの処理は実行されます。

これで、他の処理まで実行できなくなるという事態を避けることができます。

条件を満たしたい

「ロジックを分けて疎結合にする」「タイミングを分けて処理を非同期にする」を満たす方法を調べました。

すると SQS を利用すれば上記の条件を満たせることがわかり、SQS を利用することに決めました!

SQSを導入 -利用例-

サグーワークスの運営者用の管理機能を使って顧客情報を登録するとき、手動で CRM に顧客情報を確認しなくても良いように、顧客情報を取り込むバッチを作成しました。

以下がその手順と図になります。

f:id:cocoeyes02:20180904095035p:plain

  1. 管理画面から顧客を指定し、メッセージ(顧客 ID )を SQS に送る
  2. バッチが SQS からメッセージ(顧客 ID )を取得する
  3. バッチが顧客 ID を使って顧客情報を CRM から取得する
  4. バッチが顧客情報をサグーワークス DB に登録する
  5. サグーワークス DB に登録に成功した時は、バッチが登録成功した(あるいは既に登録されている)メッセージ(顧客 ID )を SQS から削除する

バッチと SQS を使うことで、CRM 関連の処理とそれ以外の処理を非同期化することができました。

終わりに

CRM など外部からの仕様変更の影響を減らしたい時には、SQS はとても有効です。

皆さんも是非、プロダクトに導入してみてはいかがでしょうか!