Engineer Blog

Kairi Ueno

Hiroki Tamiya

Yugo Tsuchiya

TomokiIchikawa

Yoshito Ikeda

Haruki Tazoe

Hajime Shiozawa

Kazuki Katsurada

masashi kobayashi

lapla

Takehiko Okayama

Kotaro Ito

Yuhei Yasuda

naoyashiga

Takumi Ishii

Sojiro Nishimura

Katsumi Kobayashi

Kota Momoki

Calloc

Shohei Shiraki

Takaaki Kanetsuki

Yui Taniyama

Kota Yatagai

Shuhei Kondo

kenshin tanaka

KARTE Team

Security Team

Tomoya Koike

Haruki Tosa

Daiki Sakuma

Takuma Shibuya

plaidinc

Takami Yamada

Blocks Team

Takanori Koga

Takumi Katayama

Yu Nishimura

Takuya Ogawa

akira.kasuga

Kosuke Oya

Yoshiyuki Komazaki

mizchi

Ryosuke Suzuki

koichi tanaka

Arnaud Avondet

kazupon

daigo.isamatsu

Jun Kusahana

Shinnosuke Ozawa

Rei Ishikawa

Hiroto Harada

Kei Tamiya

Nobuhiro Ito

kazushi oohira

Yohei Meguro

Kazuto Kojima

Tomoki Koga

Kenichi Suzuki

Takaaki Nakama

Takahiro Tokunaga

Kohei Kadowaki

kantetsu

Makoto Kataigi

Tatsuya Monoi

Jumpei Ikegami

Masahiro Yamauchi

Shinji Eto

Yuta Nishimura

Hideyuki Okada

Wataru Ikarashi

Naoto Kato

Yuki Makino

Atsushi Fujikawa

Naohiko Takemura

Daikichi Sasamori

Atsushi Kobayashi

Naoki Shibayama

Daiki Matsui

Yohei Noda

プレイドでエンジニアをしている田宮です。今回は Cloud Logging と BigQuery 用いて開発した 監査ログ の紹介をします。

マルチプロダクトにおける全操作を網羅する監査ログ収集基盤：設計思想と実装 - 収集編

<h1>はじめに</h1>
<p>こんにちはプレイドの<a href="https://cxclip.karte.io/products/info/message-beta/">KARTE Message</a>チームでエンジニアをしている<a href="https://x.com/prooooograming">土谷</a>です。</p>
<p>今回は大量メール配信を実現するためにKARTE Messageで取っている仕組みを紹介していきます。</p>
<h1>KARTE Messageについて</h1>
<p>本題に入る前に、まずKARTE Messageについて説明します。</p>
<p>KARTE Messageはマルチチャネル(Mail/アプリPush/LINE *)での大量配信を行えるMAツールとなっており、主に以下の機能を備えています。</p>
<ul>
<li>配信の管理
<ul>
<li>配信対象抽出の設定</li>
<li>配信コンテンツの設定・コンテンツへの埋め込み</li>
<li>配信速度・頻度の管理</li>
</ul>
</li>
<li>配信対象の管理
<ul>
<li>誰に配信するのかを取り扱うための配信対象を管理するためのリスト機能</li>
<li>リストに対するフィルタリング機能</li>
<li>リスト同士を組み合わせて配信対象を絞り込む機能</li>
</ul>
</li>
<li>配信コンテンツの管理
<ul>
<li>配信コンテンツをテンプレートとして管理</li>
</ul>
</li>
</ul>
<p>これらの機能に加えてKARTEの特有の機能を利用した配信対象の抽出などもできるようになっています。</p>
<p>* LINEとの連携機能は現状β版として提供しています。</p>
<h1>このブログで出てくる用語</h1>
<p>まずメール配信においてよく使われる用語の説明をします。理解している人は読み飛ばしてください。</p>
<p><code>Eメール</code> : 一般的にEメールはマーケティングメールとトランザクションメールに大別できます。</p>
<p><code>マーケティングメール</code> : 受信者がアクションをしていなくても送信者側が能動的に送信するメールです。メルマガ配信やクーポンメールなど。</p>
<p><code>トランザクションメール</code> :  受信者が何かしらのアクションを起こした時に受等的に送信するメールです。ログインメールやパスワードリセットメールなど。</p>
<p><code>メールバウンス</code> : 送信したメールが何らかの理由で相手のメールサーバーに拒否されて、送信者に戻ることです。メールバウンスはハードバウンスとソフトバウンスに大別できます。</p>
<p><code>ハードバウンス</code> : メールの拒否理由が恒久的な問題の場合のメールバウンスのことです。メールアドレスが存在しないなど。</p>
<p><code>ソフトバウンス</code> : メールの拒否理由が一時的な問題の場合のメールバウンスのことです。受信者のメールボックスがいっぱいなど。</p>
<p><code>IP/ドメインレビュテーション</code> : メール送信時に利用するサーバーのIPアドレスやFromドメインに対して付けられる評価をレピュテーションと呼びます。スパムメールのようなメールをたくさん配信しているとレピュテーションが下がり、メールプロバイダー(GmailやYahoo!メールなど)から受信を拒否される場合があります。レピュテーションの管理はメールプロバイダーがやっていたり、第三者機関がやっていたり、さまざまなパターンがあります。</p>
<p><code>SPF</code> : SPFレコードというDNSレコードを利用して、送信されたメールの送信元IPを確認することで送信者がなりすましをしていないかを確認する仕組みです。</p>
<p><code>DKIM</code> : DKIMレコードというDNSレコードを利用して、送信されたメールの内容が第三者に改竄されていないことを確認する仕組みです。</p>
<p><code>DMARC</code> : SPF/DKIMの確認に引っかかった時に、どのように対応すべきかを送信元のサーバーが表明しておく仕組みです。</p>
<h1>大量メール配信の運用における課題</h1>
<p>マーケティングメールが大量に送信されている現在の環境では、同様に大量のスパムメールも送信されています。メールプロバイダーはメールの大量送信に対して、スパムメールかどうか・送信者がスパマーではないかという判定を厳しく行なっています。</p>
<p>そのためマーケティングメールをエンドユーザーに届けるためには、送信したメールがスパムメールでないことを証明する必要があります。</p>
<p>メールプロバイダーは送信されたメールがスパムメールでないことを確認するために、以下のような項目を確認しています。</p>
<ul>
<li>SPF/DKIM/DMARCの設定確認
<ul>
<li>これらのDNSレコードの設定がされていないとスパムメールと判断される場合があります。</li>
</ul>
</li>
<li>IPレピュテーション・ドメインレピュテーションの確認
<ul>
<li>送信元のIPレピュテーションやドメインレピュテーションが低いと、スパムメールと判断される場合があります。</li>
</ul>
</li>
<li>メールコンテンツの正当性の確認
<ul>
<li>メール内のコンテンツにhttpのセキュアではないリンクがあったり、不審なスクリプトなどが含まれていたりすると、スパムメールと判断される場合があります。</li>
</ul>
</li>
<li>メール配信量の急増の検知
<ul>
<li>特定IPからのメールの配信量が急増すると、スパムメールと判断される場合があります。</li>
</ul>
</li>
</ul>
<p>上記のようなスパムメールかどうかの大量のチェックが各メールプロバイダーごとで設定されているため、マーケティングメールをエンドユーザーに届けることが簡単ではないことが課題となっています。</p>
<h1>KARTE Messageにおける大量のメールをエンドユーザーに届けるための仕組み</h1>
<p>ここからは、KARTE Messageで行なっているマーケティングメールを正常にエンドユーザーに届けるための仕組みを紹介します。</p>
<h2>AWS SESを利用したマルチテナント構成</h2>
<p>大量メール配信においてIPレピュテーションを高く保つことは、上述した通り非常に重要です。これを実現するには、スパムメールと判定される可能性のある質の低いメールの送信を極力避け、メールプロバイダーに確実に受信される質の高いメールを送信する必要があります。</p>
<p>そのため、質の高いメールの配信量を最大限に増やすことが有効なアプローチの一つです。これにより、仮に少量の質の低いメールが送信されたとしても、全体におけるその割合を低く抑えることができ、結果としてIPレピュテーションを高く維持することにつながります。</p>
<p><img src="https://ik.imagekit.io/plaid/913abcd7-570a-481a-bc9b-b9cb0c8ff3e4/blog_image1.png" alt="blog_image1.png"></p>
<p>KARTE Messageでは、それを実現する仕組みとしてマルチテナントなメール配信を行なっており、KARTE Messageが所有しているIPアドレスをクライアントごとに固定せず、全てのIPに均等に振り分けて送信しています。</p>
<p><img src="https://ik.imagekit.io/plaid/c3e46daa-6c2d-4f66-b27e-b7a349813334/blog_image2.png" alt="blog_image2.png"></p>
<p>結果として冒頭で述べた通り、KARTE Messageを利用しているクライアント全配信量が母数となるので、特定のクライアントで質の低いメールが多少送信されても影響を小さくすることができます。</p>
<p>また、複数のクライアントの配信をKARTE MessageのIPで送信しているため、配信はほぼ24時間常に行われています。そのため、1クライアントが急な大量配信をしたとしてもKARTE Message全体では配信量の急増にはなりにくく、メール配信量の急増によるIPレピュテーションの低下を防ぐことができ、送信されたメールもスパムメールと判定されづらくなります。</p>
<p>こういったIPレピュテーションの運用は、1クライアントでやろうとすると配信量や配信時間の問題で運用が難しくなる場合があります。KARTE Messageではマルチテナント配信にすることで、その運用負荷をクライアントから取り除いています。</p>
<h2>まとめ</h2>
<p>マルチテナント配信以外にも、KARTE Messageではメール配信の細かなモニタリングを行ったり、SPF/DKIM/DMARCの設定の補助機能なども提供することで、なるべくマーケティングメールの運用負荷を下げるような機能提供を行なっています。</p>
<p>KARTE Messageでは、メールという長年コミュニケーションツールとして中心になっている技術であるからこそ難しくなっている部分を管理することで、価値を届けるプロダクトを作っています。</p>
<p>興味がある方は<a href="https://recruit.plaid.co.jp/product">採用ページ</a>をご覧ください。お待ちしております！</p>


KARTE MessageというMAツールでメールの大量配信を安定的に行うためのシステム設計やIP運用の考え方などを説明

KARTE Messageで採用している大量配信を実現するためのアーキテクチャ

KARTE Messageの大量メール配信を支える技術

こんにちは！10月初旬から4月末までの7ヶ月間、ソフトウェア開発のインターンとしてプレイドで働いていた[上野海吏](https://x.com/kairi_noel)(@kairi_noel)です。

プレイドで7ヶ月間の開発インターンで体験したことと得られた学び

AIエージェントによるセキュリティレビューの試みを紹介します。

AIエージェントによるセキュリティレビューことはじめ

この記事では、MongoDB Atlas Stream Processing を使った BigQuery へのレプリケーションシステムについて解説します。

MongoDB Atlas Stream Processing を使った BigQuery へのレプリケーション

<p>はじめまして、エンジニアの nito です。PLAID Advent Calendar 2018 の三日目の記事でもあります。</p>
<p>最近は KARTE の開発者向けのプラットフォーム開発を主戦場に、API の仕様策定や開発者向けの管理画面の実装、ドキュメンテーションなどを担当しています。</p>
<p>今回は <a href="https://support2.karte.io/update/2018/12/12347/">12/3 にリリースした KARTE の開発者向けプラットフォーム「Developer Portal」</a> の開発をおこなううえで、大切にしていた <strong>Developer Experience (DX)</strong> という考え方をご紹介します。</p>
<h1>KARTE Developer Portal とは?</h1>
<p><a href="https://developers.karte.io">KARTE Developer Portal</a> は KARTE が提供する開発者向けプラットフォームです。主に次の2つの機能で構成されています。</p>
<ul>
<li>ドキュメント: 具体的なユースケースに則した使いかの説明をするガイド・技術仕様を網羅するリファレンス</li>
<li>管理コンソール: KARTE の API や Webhook など開発者向けの機能にアクセスし管理する。</li>
</ul>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/5e45005b-8956-41e9-bad1-6f5a928e5788/Screen-Shot-2018-12-03-at-4.49.26.png" alt="Screen-Shot-2018-12-03-at-4.49.26"></p>
<h1>Developer Experience とは?</h1>
<p>DX は、2011年に UX Magazine で投稿された <a href="http://uxmag.com/articles/effective-developer-experience">Effective Developer Experience</a> という記事で紹介されています。<br>
以下は一部引用したものになります。</p>
<blockquote>
<p>Platform product owners must be concerned with assisting developers in accomplishing this if end users are to have a good user experience overall. Attention to these details is called developer experience (DX), ...</p>
</blockquote>
<blockquote>
<p>(訳) エンドユーザーに、そのプラットフォーム上で、優れた体験をさせたいと考えているならば、プラットフォーム・オーナーは開発者がこれを達成するのを手助けしなければならない。そして、こうした開発者への細やかな配慮のことを Developer Experience (DX) と呼ぶ</p>
</blockquote>
<p>続けて、次のように言っています。</p>
<blockquote>
<p>and enabling app developers to be successful through better DX will create a more successful UX for the platform product.</p>
</blockquote>
<blockquote>
<p>(訳) より優れた DX を通して開発者を成功させることで、プラットフォームのユーザー体験をさらに成功させるだろう</p>
</blockquote>
<p>また、<a href="https://www.infoq.com/news/2015/10/api-developer-experience">What is API Developer Experience and Why It Matters</a> では、API 設計に対して DX という考え方を拡げ、</p>
<blockquote>
<p>API developer experience is a relatively novel focus aimed to improve API design so it provides a seamless experience to developers when writing software. It can help increase programmers’ efficience and make it easier for developers to achieve goals on behalf of end users.</p>
</blockquote>
<blockquote>
<p>(訳) API Developer Experience は、API 設計を良くするための目標としては比較的新しく、開発者にシームレスな開発を可能とします。そして、プログラマーの効率をあげ、開発者がエンドユーザーの利益になるように目標達成するのを簡単にすることができます。</p>
</blockquote>
<p>と伝えています。</p>
<p>DX は、開発者が気持ちよく生産的に開発できるかどうかに注意を向け、開発者の体験を良くすることで、それが結果としてエンドユーザーの良い体験につながるという考え方です。</p>
<h1>KARTE Developer Portal で実際に注意したこと</h1>
<p>この考え方は、タイトルにもあるように、KARTE Developer Portal を開発する上で非常に大事にしています。<br>
ここからは、実際に DX を意識したところ、ここでは、とくにドキュメンテーションに関して気をつけたところを、いくつか紹介していきます。</p>
<h2>実際のユースケースに合わせたガイド</h2>
<p>KARTE Developer Portal のドキュメントでは、KARTE が提供している API やフロントエンドから利用できる JavaScript モジュールなどの仕様をリファレンスとして網羅しています。しかし、(開発者の方なら経験があるかと思いますが、) リファレンスだけで、すべてを理解するのはかなり厳しいと思われます。</p>
<p>そのため、リファレンスで記載されている各API や関数の使い方としてガイドを提供しています。ガイドは、どのような目的で、どのように使うのかを例 (サンプルコード) を交えて紹介しているので、開発者が迅速に開発に取り掛かることができます。</p>
<p>たとえば、以下は [ガイド] &gt; [基本的な使い方] の「チャットボット連携」に関するドキュメントのタイトルですが、目的から記事にたどり着けるようにタイトルをユースケースを表すようにしています。また記事ごとに目的をもったシナリオと捉えて、動詞をタイトルにしているのも工夫のひとつです。</p>
<pre><code class="language-plaintext">チャットボットと繋げる
├── チャットボット連携のセットアップ
├── ユーザーにメッセージを送信する
├── ユーザーのメッセージを受け取る
├── ユーザーの担当者を変更する
└── ユーザーの担当者変更情報を受け取る

</code></pre>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/82c73a32-efa4-4018-81f1-13173007a1a7/Screen-Shot-2018-12-03-at-22.16.04.png" alt="Screen-Shot-2018-12-03-at-22.16.04"></p>
<h2>コンセプトを最小限で理解するためのチュートリアル</h2>
<p>また、そもそもプラットフォーム上で開発する場合、そのプラットフォームがどのようなプロダクトで、どのようなコンセプトを持ったプロダクトであるかを理解することも非常に重要になります。そこで、[クイックスタート] というチュートリアルを設けて、KARTE の最小限の基本的な機能をさらいながら、そのコンセプトを理解できるコンテンツも提供しています。</p>
<h1>おわりに</h1>
<p>本記事では、Developer Experience という考え方を紹介しました。KARTE Developer Portal では、DX をもとに、紹介したドキュメントをはじめ、API 設計などにも適用しており、開発者、ひいては KARTE ユーザーに良い体験を提供することを目指しています。</p>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a>または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE
<p>_IgY4VF5ukBo_EUKZLg&quot; data-width=&quot;300&quot; data-height=&quot;60&quot;&gt;</div></p>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>


開発者向けプラットフォームを開発するうえで大切にした「Developer Experience」という考え方; KARTE の開発者向けプラットフォーム「Developer Portal」の開発をおこなううえで、大切にしていた Developer Experience (DX) という考え方をご紹介します。


開発者向けプラットフォームを開発するうえで大切にした「Developer Experience」という考え方 | PLAID engineer blog

開発者向けプラットフォームを開発するうえで大切にした「Developer Experience」という考え方

<h1>0. はじめに</h1>
<p>PLAIDのEngineerの 大平和史 (<a href="https://twitter.com/tai_hey2?lang=ja">@tai-hey</a>) です。</p>
<p>前職でSEとして金融系超大規模プロジェクト(数年、数十億円規模、最大数百人)を経験し、現在は真逆となる小規模プロジェクト(4人チームでのサービス開発)でスタートアップのエンジニアとして経験を積んでいます。</p>
<p>ミッションクリティカルな、一つのエラーでも業務影響が存在する大規模な品質最重要のシステムと、toBではあるものの、攻めの開発かつスピード重視のSaaSスタートアップでの開発手法に目的と手法にかなりの差異を感じる毎日です。</p>
<p>それぞれのシステムは価値を提供するビジネスに合わせて作られるため一長一短であり、スピード重視・品質重視か、またそのバランスは生み出すビジネスの価値や目的に沿って特徴があります。その中でプレイドのこだわりはスピード重視の攻めの開発です。社員数を増やし、日々開発を進めていく中で、プロジェクトの規模が大きくなってもいかに開発スピードを落とさずにいれるかの対策を考察していきたいと思います。</p>
<p></p>
<h4>メッセージ</h4>
<p>今回のブログのメッセージをここで先にお伝えしたいと思います。「構造が硬直しがちなシステムを、肥大化する前に最適な単位に疎結合・高密度にアップデートし続け、 開発スピードを維持する」となります。</p>
<h1>1. ビジネスモデルと社会インパクトの特徴について</h1>
<p>まず、そもそもの品質重視の大規模システムと、スピード重視の開発では、ビジネスモデルの生まれや経緯が違うことが大きな源流となります。今後の考察にも役に立ちますので先に整理しておきたいと思います。<br>
両者には大きなビジネスモデルの差異(受託開発かプロダクト・アウトか)と社会インパクトについての観点から分析します。</p>
<h3>1.1 ビジネスモデル</h3>
<p><strong>大規模システム開発のビジネス(基本受託開発となる)</strong></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/7b8de494-eac4-41ab-94f1-0767eb28fb8b/biz_jutaku-1.png" alt="biz_jutaku-1"></p>
<p>大規模システムは基本的に顧客から外部に開発を外注します。大規模システムの目的はミッションクリティカルで、SLAが他の業界にくらべ高く、求められる品質も高い傾向にあります。</p>
<p>そのため顧客の社内では開発要員の調整や、品質の保持を実現が難しいため、開発手法はウォーターフォールで実施し、顧客から求められた仕様でガチガチにシステム構築を行い、受託会社が顧客のシステムを構築します。</p>
<p>受託開発では顧客が仕様を決めてそれ通りに作るため、ソースコードなどの資産は顧客のものになり、顧客のものを修正することになるので修正一つ一つに契約の合意形成のプロセスが発生します。また、顧客のビジネスにほぼ100％アジャストすることが求められます。</p>
<p>作った後の話にはなりますが品質を求める実例としては下記のようなケースがあります。これで温度感をイメージしていただければと思います。</p>
<p>例えば</p>
<ul>
<li>業務を止められないので業務停止中に原則で夜10時〜朝の間に作業を行わなければならない</li>
<li>夜間一つのジョブが落ちてしまったら業務開始までに必ずリカバリする</li>
</ul>
<p>等があります。<br>
　　　　　<br>
　　　　　<br>
　　　　<br>
<strong>SaaSのビジネス</strong></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/7502ecca-8ffb-4e46-ae0b-70f0a4554c36/biz_SaaS-1.png" alt="biz_SaaS-1"></p>
<p>SaaSプロダクトは自社製品としてプロダクトを開発し、顧客のシステムと連携する形になるため、プロダクトの仕様は自社で決めてそれに顧客の業務やシステムが、ある程度アジャストする方針になります。プロダクトのソースコードも自社資産になるのでコストの払い出しや修正の要否は自社で検討することになります。個別の顧客ビジネスに必ずしも100％アジャストしなくてもよいですし、プレイドの場合はKARTEを用いて新たな接客の形態や業務を提案することが弊社ビジネスの価値となります。</p>
<h3>1.2 社会インパクト</h3>
<p>次に社会インパクトについて比較してみます。</p>
<p><strong>大規模システムの社会インパクト</strong></p>
<p>受託大規模開発では顧客のビジネスや業務を理解し、深く入り込んでいくことがビジネスの強みです。個社適用でシステムを構築しており、システム作成当時から顧客数やデータ量が元々多いため、一つのミスのインパクトが社会的に大きいケースが多く、構造の変更よりも社会インフラとしての現状をいかに守るかの判断が重要視されます。</p>
<p><strong>SaaSスタートアップでの社会インパクト</strong></p>
<p>スタートアップも同様ではじめは小さい容量や機能でスタートすることが大半です。そのため始めは社会インパクトが小さいため実現可能性のスピードが重視される傾向にあります。ただし、今後利用顧客数も増え、インパクトが少なからず大きくなり、データ量も増大していく（弊社の場合既に大きくなっています）傾向にあります。<br>
また、利用機能やソースコード量も増えてきます。それにより既存の顧客を守るために保守的になりすぎてしまうのはビジネスの成長を考えた時に足かせとなる可能性があります。スピード減は事業リスクとなりうるので、そうならないような事業推進について考えることが必要です。</p>
<h1>２． 構造が硬直しがちなシステムを、肥大化する前に最適な単位に疎結合・高密度にアップデートし続ける</h1>
<p>いよいよビジネスモデルの前提を1章で踏まえた上でSaaSスタートアップがプロダクト規模、開発規模が大きくなってきた場合、2.1のモデルを使って、どのようなリスクがあり方向性が必要かを考察したいと思います。前職で超大規模システムに携わってきた際に感じた反省から、プレイドでも同様のデメリットを発生させないために攻めのアクションを考察していきたいと思います。</p>
<h3>2.1 価値創造のためのシステムとその構造について</h3>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/8ed7388f-7fe3-44a2-806a-3152c5671296/model.png" alt="model"></p>
<p>システムとビジネスを取り巻く環境は「価値、顧客のビジネス、管理/ ルール、処理、構造」を構成要素として把握することができます。構造(アーキテクチャ)を構築して、処理(ソースコード)として記載し、管理(インプットから出力されるアウトプットデータの管理)します。そこに顧客のビジネスが乗り価値が生まれる。このモデルを元に各ビジネスとシステムの構造を考えます。</p>
<h3>2.2 超大規模システムの特徴と変遷について</h3>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/0dc46a52-a512-4342-8473-639ec072124c/2daikibo.png" alt="2daikibo"></p>
<h4>構造と処理を変えられないシステムは硬直化・肥大化する</h4>
<p>構築したシステムは10〜20年前のシステムが多いと思いますが、当時の最新のアーキテクチャで作られているはずです。ただ、そこからアーキテクチャの構造を変化させることはほとんどなく現在業務を行っています。<br>
ビジネス要件が追加された場合、処理を追加するためにソースコードは増大するのが普通です。複数サブシステムを一つのモジュールに入れてしまうようなモノリシックで構築したものはそのままとなります。</p>
<p>アーキテクチャを更改するタイミングは5年に一度サーバリプレース案件が発生する時があるのですが、サーバを単純リプレースするだけでかなりのコストとリスクがかかるので、ソースコードを見直してリファクタリングするような活動はされづらいです。その時の判断と企業には寄りますが、業務上最低限の移行（保守が切れるサーバを新しいものに移行する）で遂行されることが多いと思います。</p>
<p>このようにミッションクリティカルなシステムなためどうしても現行業務を死守しなければならないと、<br>
・処理（ソースコード）複雑性が上がってしまうが、ひとまず動くように処理を増大させる方向に傾きやすい<br>
・構造（アーキテクチャ）をドラスティックに変えるチャレンジが数年に一度のチャンスしかない<br>
※但し顧客の予算とリスクテイクの関係で最低限のリプレースしか行われないことが多い。<br>
　<br>
という選択肢を取らざるを得なくなってしまいます。<br>
　<br>
　<br>
そうすると構造を変えられないので、それを補うために処理（ソースコード）を分岐処理や冗長なコードで増大していきます。（今はクラウド化の流れが来ているが）サーバもオンプレミスのままで、アップスケールで対応するのがメインとなります。</p>
<p>また、増える仕様を管理するためにエクセルでの管理資料を増大させることになります。顧客のビジネス要件を満たすきめ細やかな処理を追加するたびにシステムやその管理が増大し、図の各階層のバランスが肥大化するようになります。</p>
<p>早い段階でアーキテクチャやソースコードの最適化や分割を行わないと、構造を硬直させたまま肥大化させてしまうことが私の経験上での反省です。</p>
<h4>顧客のビジネスとの密着度が硬直化の要素の一つ</h4>
<p>また、顧客のビジネスとシステムとの密着度も要因の一つと考えます。大規模システムはミッションクリティカルが多いため、システム停止などが顧客のビジネスに直結します。そのため無闇にシステム構造を変更させることもできないため硬直した巨大システムは肥大化を続けていき、構造の変革が更に難しくなってきます。</p>
<p></p>
<h2>2.3 KARTEのシステム構造としての特徴について</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/656a26a4-30c0-406d-86b3-e07d41777b53/2plaid.png" alt="2plaid"></p>
<h4>現状は最適に近いシステム構成</h4>
<p>相対してスピード重視のプレイドはどうでしょうか。<br>
　<br>
現状私が把握できているプレイドでの構造は上記のように認識しています。プロダクトリリースから3年半が経っていて、構築にあたって2010年代に作られたこともあり、最近技術を取り入れていると感じています。構造（アーキテクチャ）を見てみるとインフラはマルチクラウドで構成され、スモールスケールで増大が可能です。処理（ソースコード）に関しても日常的にリファクタリングが行われ、日々モジュール化が行われています。</p>
<p>構造も処理もそれぞれモジュールとして分割して、余計なソースコードは日々削除するようになっているので、余計な関数などは積極的に集約する活動が行われているように感じます。</p>
<p></p>
<h4>今後の勝負は既存のデータを守りつつ積極的に構造と処理を変革させることができるか</h4>
<p>現状はうまく行っているように見えますが、今後のリスクもはらんでいます。それぞれの処理は現状のコード量と実現したいビジネスのバランスがある程度取れている状態ではありますが、ソースコードの全体量とそれぞれのコード量が増大しているのは間違いないです。更に既存データ量も増大しているため、サーバ上にはかなりのデータ量が格納され続けています。</p>
<p>そうすると大規模開発の状態にもあった顧客に対するインパクトが少なからず増大する傾向になります。本当はアーキテクチャやソースコードをドラスティックに変えていきたいですが、KARTEに入っている既存データや既存顧客のビジネスを守りつつ開発を進めることになるので、そこを考慮しつつ開発することが必要となります。</p>
<p>ソースコードが肥大化する前に構造を硬直化させずに、アーキテクチャやモジュールを分割、共通化、最適化を積極的に行うべきと思っています。マイクロサービス的に細かくすればよいというわけではなく、構造を変革することを直近のコストを考えすぎて先送りにするのは問題と思っているので、都度最適な粒度を検討して分割するべきと思っています。</p>
<h4>顧客ビジネスとの密着度は疎結合でありつつ、顧客のビジネスにインパクトを与える機能実装が必要</h4>
<p>既存のデータを守りつつ構造と処理を変革させることが必要ですが、受託大規模開発と比べKARTEは汎用的な業務を提案していくスタイルなので、顧客業務との密着度を疎結合的にそのままキープしつつ、開発スピードを上げていくことが事業の価値と直結すると私は考えています。少なくとも密着度を上げすぎるような特定の顧客向けに個別の実装をするなどは避けたいと思っています。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a70c3377-2169-4022-81ad-753353813224/2hikaku.png" alt="2hikaku"></p>
<h1>３． 直近の構造を変革させる攻めの活動</h1>
<p>1章の前提の比較、2章までの考察を踏まえて、最後に開発スピードを落とさないために必要であった、<br>
構造と処理を積極的に変革させていく例がありました。その例を紹介します。</p>
<h4>リポジトリの分割による構造と処理の最適化</h4>
<p>直近の活動としては肥大化した特定のリポジトリを分割する活動を行っています。現在プロダクトリリースから開発をしている既存の大きくなりがちなリポジトリを分割し、機能ごとにデプロイを行えるようリポジトリ分割の活動を始めています。</p>
<p>ディレクトリ構成の変更や、共通的に使用するモジュールの集約化や、最適化を行っています。</p>
<p>実際に分割直後の機能を触ってみたのですが、buildも十数秒かかっていたものが体感で一瞬で終わるまでになっています。今後のプロジェクトは常に構造を変革することを念頭に入れながら開発をしていきたいと思っています。</p>
<h4>エンジニアとして必要なのは開発時のプロジェクト判断は、構造と処理の変革を常に頭に入れておくこと</h4>
<p>今後様々な開発プロジェクトを推進していく立場になっていくと考えると、特に既存機能が関わる箇所については、顧客と常に相対している、ビジネスサイドとのコミュニケーションを今回の考察を元に推進していきたいです。</p>
<p>機能開発を進めていく際に既存顧客を守りすぎて開発スピードを落とす方向に開発を進めることは避けたいです。既存顧客は守りつつ、開発スピードを落とさない方向、または長期的に見た時に構造や処理をそもそも作り変える着想を持ちつつ、プロジェクト判断をしていこうと思います。</p>
<h2>仲間を募集しています</h2>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a>または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
(function(d, s, id) {
var js, fjs = d.getElementsByTagName(s)[0];
if (d.getElementById(id)) return;
  js = d.createElement(s); js.id = id;
  js.src = "https://platform.wantedly.com/visit_buttons/script.js";
  fjs.parentNode.insertBefore(js, fjs);
}(document, "script", "wantedly-visit-buttons-wjs"));
</script>


品質重視の超大規模システム開発経験からスピード重視の開発する環境に転職し、大規模システムの観点から攻めのスピード開発を止めないために考察した記事です。

超大規模システム経験者が考える、攻めの開発を続けるために大切なこと| PLAID engineer blog

超大規模システム経験者が考える、攻めの開発を続けるために大切なこと

<p>みなさま初めまして！<br>
PLAID Engineer Blog初投稿の韓 徹（<a href="https://twitter.com/sskt0809">@sskt0809</a> ）です。</p>
<p>プレイドは、2018/11/3(土)に秋葉原UDXで開催された<a href="https://vuefes.jp/">Vue Fes Japan 2018</a>にプラチナスポンサーとして協賛しました。<br>
私はスポンサーセッションで参加者全員の前で登壇する機会もいただき、Vue Fes Japan参加者の皆さんに<a href="https://karte.io/">KARTE</a>について伝えることができました。</p>
<p>今回のブログでは、Vue Fes Japanの様子や、スポンサー参加の裏話などをお伝えします。</p>
<h2>会場の様子</h2>
<p>自分が会場入りした午前9:00の時点でPLAID以外の各スポンサー企業さんも準備が整っていて、すでに会場はほぼ完成していました。</p>
<p>ヘイ株式会社さんはトイレットペーパーをノベルティに、株式会社リブセンスさんはガチャガチャを用意したりと、ユニークなブースもあり、見るだけで楽しいブースもいくつかありました。</p>
<p>私たちはKARTEのバナーや50インチのディスプレイに公式動画を写し、ノベルティは弊社デザイナーが用意してくれたPLAIDとKARTEのステッカーとメッセージカードを同梱した渾身のステッカーセットを用意しました。<br>
（結果ステッカーセットを渡すと「こんなにステッカーもらえるの？！」って反応がもらえて、大成功でした。）</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/b9e49923-c8ae-483e-b779-4add5e8163be/45B2B854-035A-48D4-B649-5C62402E9464-2.JPEG.jpg" alt="45B2B854-035A-48D4-B649-5C62402E9464-2"><br>
<em>ブースの準備は整った！の様子。</em></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/b5999bcf-07d2-4d4c-b631-d90023827bd0/IMG_0875.JPG.jpg" alt="IMG_0875"><br>
<em>ノベルティのステッカーセット。来場者の皆様に好評でよかったです！</em></p>
<h2>そして開幕</h2>
<p>会場には続々と参加者が入場し、キーノート開始までに約300人の方が集まり会場は熱気に溢れていました。（会場スタッフやスポンサーの方を含むと400人強はいました。）<br>
そして、10:20にVue Fes Japan 2018主催のkazuponさんの開会の挨拶でイベントが開催されました。<br>
まず一発目のプレゼンはVue.jsクリエイターのEvan Youさんのキーノートです。Vue.js 3.0が登場する話、どこが2.x系と変わるかをプレゼンしていました。</p>
<p>そのEvanさんのプレゼンの次がお待ちかねのプラチナスポンサーセッションで弊社PLAIDの登壇です。登壇前はEvanさんの登壇の後であるのと会場の人数の多さのプレッシャーがありましたが、いっぱい練習したんだから大丈夫！大きい声で伝えたいことは強くゆっくり話す！って自分に言い聞かせてましたw</p>
<h2>登壇内容</h2>
<p>今回は「KARTEが1,000サイト以上でVue.jsを動かしている話」という内容で発表しました。以下がスライドです。</p>
<script async class="speakerdeck-embed" data-id="98c6724ce2c94580aa22383431fd7ba3" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<p>主な内容は以下です。</p>
<ul>
<li>プレイドでは、Vue.jsがリリースされた2014年からVue.jsをKARTEの開発で使用している</li>
<li>お客様がKARTEの管理画面で作成したアクション（エンドユーザーに出すポップアップなどのコンテンツのこと）もVue.jsで作られている
<ul>
<li>それらがお客様のWebサイト上（1,000サイト以上！）で動いている</li>
</ul>
</li>
</ul>
<p>プレゼンする前は緊張しましたが、話し始めるとちゃんと練習した甲斐があり、プレゼン自体は大きなミスなく話せたと思います。ただし、最後に言い間違って「ちゃいます、ちゃいます」というお茶目な関西弁が出てしまいました...。その関西弁についてのツイートが2ツイートくらいありました。今やいい思い出です！</p>
<p>発表後はツイートを見ると「KARTEの管理画面すごい！触ってみたい！」「650コンポーネントもあるんだ！」「2014年から使ってるんだ！」「関西弁に安心感を感じる」といったポジティブなツイートばかりだったので、安心と嬉しさがこみ上げました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/7f2096f0-68a7-4413-84d9-343d334e7d25/04AA081E-AF0A-4C38-9D07-CFAC5F1F162F.JPEG.jpg" alt="04AA081E-AF0A-4C38-9D07-CFAC5F1F162F"><br>
<em>登壇時の様子。我ながら顔が硬いですね...。</em></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3837230f-2643-47f6-8a33-e817229ae73f/Image-from-iOS.jpg" alt="Image-from-iOS"><br>
<em>聞いていただいた方々ありがとうございました！</em></p>
<h2>PLAIDのブースの様子</h2>
<p>プレゼンが終わったからと安心してはいけません。本当に会場の皆さんに魅力を伝えるのは発表の合間合間のブース対応なのです。<br>
発表見てブース来ていただいた人も多数いました。（弊社エンジニアであり、<a href="https://shiganai.org/">しがないラジオ</a>パーソナリティの池上に会いに来た方も多数いました。）</p>
<p>Vue.jsをどのように使われているかという質問はもちろん、KARTEがどういうことができるのか、サービス自身に興味を持っている方も多い印象を受けました。<br>
改めまして、ブースに来ていただいた方ありがとうございました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/78c2e7b4-783a-43a7-b933-9035f9acf530/Image-from-iOS--1-.jpg" alt="Image-from-iOS--1-"><br>
<em>ブースに多数の方々が来てくれました！</em></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/bc056c5d-6cb1-49cd-85c0-3fa9d8367276/FC51D036-7939-4D81-9EA0-604039015FBD.JPEG.jpg" alt="FC51D036-7939-4D81-9EA0-604039015FBD"><br>
<em>エンジニアの民谷（タミー）もブース対応に参戦。ありがとう！</em></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/2f677bec-23b4-44b6-946a-f71836d3a550/18C158A2-317C-48BC-BAD6-67730DD67073.JPEG.jpg" alt="18C158A2-317C-48BC-BAD6-67730DD67073"><br>
<em>エンジニアの野田(@positiveflat)はVue Fes Japanのスタッフとして大活躍していました！</em></p>
<h2>プレゼンで割愛した内容を一部紹介</h2>
<p>今回の発表はアクションの配信する箇所をメインに話しましたが、この内容にfixするまでにプレゼン内容に紆余曲折あり、説明したくても残念ながら割愛した部分を紹介したいと思います。</p>
<h3>Vue.jsをなぜ採用したか</h3>
<p>KARTE ではVue.jsがバージョン0系で登場した2014年から採用しています。当時、様々なフレームワークと比較しましたが、軽量でシンプルなフレームワークであること、状態管理のしやすさなどを理由にVue.jsに決めました。</p>
<p>実際には、学習ハードルが低く一部のデザイナーやフロント経験の浅いエンジニアでも直感的に使えるという特徴から、スピード感を持った開発を続けられています。また、ドキュメントやライブラリの充実など、Vue.jsコミュニティが活発である点もメリットを感じるところです。</p>
<h3>デザインシステムの導入</h3>
<p>PLAIDでは今年の頭からデザインシステム「BAISU（バイス）」の構築プロジェクトが始まりました。BAISUプロジェクトはKARTEのユーザー体験を良くし強いプロダクトを作るのが目的です。内部的にはデザイナーとエンジニアがよりスピード感を持って協業するために、デザイン原則、スタイルガイド、パターンライブラリを用意しました。</p>
<p>実際に一部の画面ではBAISUのガイドラインに沿ったリニューアルしたりと積極的にアップデートしています。弊社ではデザイナーもVue.jsを書くのでBAISUによりスピードを上げて開発できます。BAISUの詳細は後日、弊社デザイナーが書いてくれることを期待。</p>
<h2>最後に</h2>
<p>今回はVue Fes Japanの運営の方々、会場に来ていただいた皆さん、準備を手伝ってくれた弊社スタッフには本当に感謝しています。<br>
自分はこのような大規模なテックカンファレンスに登壇することは初めてで、新しい学びも多く、そして精神面でも色々鍛えられました！<br>
またこのような機会があれば、どんどん積極的に手を上げていこうと思います。</p>
<p>あと、Vue Fes Japanのアフターパーティは非常に豪華でEvan Youさんとも2ショット撮れたので最後まで大満足のカンファレンスでした！</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/5877741e-8196-4d88-a823-4f732167fc71/34C704BC-FFA2-4E37-8F73-5FAF34B4A683.JPEG.jpg" alt="34C704BC-FFA2-4E37-8F73-5FAF34B4A683"><br>
<em>アフターパーティの料理めちゃくちゃ豪華でした。とても美味しかったです。</em></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3bd4258d-5878-48df-8317-b5dc7ea6cce8/IMG_1339.JPG.jpg" alt="IMG_1339"><br>
<em>Evanさんとの2ショット！寿司トークも盛り上がり、楽しかったです。</em></p>
<h2>仲間を募集しています</h2>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a>または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
(function(d, s, id) {
var js, fjs = d.getElementsByTagName(s)[0];
if (d.getElementById(id)) return;
  js = d.createElement(s); js.id = id;
  js.src = "https://platform.wantedly.com/visit_buttons/script.js";
  fjs.parentNode.insertBefore(js, fjs);
}(document, "script", "wantedly-visit-buttons-wjs"));
</script>


プレイドは、2018/11/3(土)に秋葉原UDXで開催されたVue Fes Japan 2018にプラチナスポンサーとして協賛しました。
Vue Fes Japanの様子や、スポンサー参加の裏話などをお伝えします。

Vue Fes Japan 2018に登壇してきました！#vuefes | PLAID engineer blog

Vue Fes Japan 2018に登壇してきました！#vuefes

エンジニアである私が、ビジネスチームを加速させる為に取り組んだ4つのアプローチを記載しました。
エンジニア的な思考を使って、どうチームリーディングすることが効果的なのか。私が取り組んだ中から、特に効果が高かったものを紹介させていただきます。

エンジニアがビジネスチームを加速させる為に取り組んだ4つのアプローチ | PLAID engineer blog

エンジニアがビジネスチームを加速させる為に取り組んだ4つのアプローチ

<p>プレイドのエンジニア兼ハンターの <a href="https://github.com/algas">@algas</a> です。<br>
<a href="https://ramdajs.com">Ramda.js</a> の関数を例にして JavaScript による関数型プログラミングの考え方を紹介します。<br>
本記事では Ramda.js 自体を紹介するのではなく、より深い関数型プログラミングの考え方を学ぶきっかけを作れることを意図しています。</p>
<h2>想定読者</h2>
<ul>
<li>Node.js でアプリケーションを実装したことがある</li>
<li>関数型プログラミングに興味がある</li>
</ul>
<h2>JavaScript でなぜ関数型プログラミングが必要なのか</h2>
<p>JavaScript のモジュールの多くは Mutable で副作用の影響を受けやすい実装になっています。<br>
副作用の影響を受けやすければ、そのモジュールを複数の場所で利用するのが難しくなります。<br>
さらに関数などのインターフェースが適切でなかったり、意図したとおりに機能しなければ再利用するのが難しく冗長なコードが増えてしまうことになります。<br>
冗長なコードは可読性が低く理解するのにも時間がかかります。<br>
それによって不具合を混入しやすくなったり、不具合を解消するのに不要な時間がかかってしまいます。<br>
関数型プログラミングを導入することで、コードを短く保ち素早く実装して不具合を混入しにくくなることが期待できます。<br>
これはもちろん手法の一つであり、すべての問題を解決する万能の魔法ではありません。</p>
<h2>Ramda.js と関数型プログラミング</h2>
<p>Ramda.js は JavaScript の実用的な関数のライブラリです。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/c88bd433-7b95-48db-a621-3166bd1ad72c/ramdaFilled_200x235.png" alt="ramdaFilled_200x235"><br>
以下のような特徴を持っています。</p>
<ol>
<li>純粋関数型<br>
不変で副作用の影響を受けにくいような設計になっています。</li>
<li>自動カリー化<br>
関数の再利用がしやすくなります。</li>
<li>引数の最適化<br>
基本的には最後の引数にデータが来るようになっています。</li>
</ol>
<p>Ramda.js は便利な関数を数多く揃えていて、このライブラリを使ってアプリケーションを実装するだけでも非常に有益です。</p>
<p>Ramda.js を使うとどのように便利なのかについては、<a href="http://randycoulman.com/blog/2016/05/24/thinking-in-ramda-getting-started/">Thinking in Ramda</a> のブログに良くまとめられています。</p>
<h2>map の定義</h2>
<p>Ramda.js の <a href="https://ramdajs.com/docs/#map">map</a> 関数の定義を見てみましょう。</p>
<pre><code class="language-haskell">map :: Functor f =&gt; (a -&gt; b) -&gt; f a -&gt; f b
</code></pre>
<p>上記は JavaScript の文法ではありません。<br>
特に Haskell に馴染みがない読者向けに上記の定義を詳しく説明します。<br>
ちなみに Haskell では Ramda.js の map が <a href="http://hackage.haskell.org/package/base-4.12.0.0/docs/Prelude.html#v:fmap"><code>fmap</code></a> という関数に該当します。</p>
<p>'=&gt;' の左側は関数の型制約です。<br>
<code>Functor f</code> とは f は <code>Functor</code> であることを示しています。<br>
Functor 自体が何かについては後ほど詳しく説明します。</p>
<p><code>-&gt;</code> は関数型コンストラクタです。<br>
<code>a -&gt; b</code> とは型 <code>a</code> の値を引き数に1つ取り、型 <code>b</code> の値を返す関数であることを示しています。<br>
例えば <code>a -&gt; b -&gt; c</code> は第一引数に型 <code>a</code> の値を、第二引数に型 <code>b</code> の値を取り、型 <code>c</code> の値を返す関数です。<br>
a, b のように小文字で書かれた型に特に制約がなければ任意の型であることを表しています。</p>
<p>小文字がスペース区切りで連続している場合には、関数を適用したことを表しています。<br>
つまり <code>f a</code> は関数 f を a に適用した値です。</p>
<p>上記を踏まえてもう一度 <code>map</code> の定義を見直してみます。<br>
<code>map</code> は第一引数に <code>a -&gt; b</code> という値(すなわち関数)、第二引数に <code>f a</code> という値を取り、<code>f b</code> という値を返します。</p>
<p>詳しくは <a href="https://github.com/fantasyland/fantasy-land">Fantasy Land Specification</a> をご参照ください。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/b3490a2b-51bb-45ed-865b-ca289e6f2314/logo.png" alt="logo"></p>
<h2>Functor とは何か？</h2>
<p>Fantasy Land Specification に記載されている <a href="https://github.com/fantasyland/fantasy-land#functor">Functor</a> の定義を見てみましょう。</p>
<ol>
<li>Identity<br>
<code>map(a =&gt; a, u) == u</code><br>
<code>a =&gt; a</code> という「何もしない」関数を map に適用しても、適用する前と同じです。</li>
<li>Composition<br>
<code>map(x =&gt; f(g(x)), u) == map(f, map(g,  u))</code><br>
これは <code>x =&gt; f(g(x))</code> という x に関数 g と関数 f を map で適用した値は、<br>
関数 g を map した値にさらに関数 f を map した値と同じです。</li>
</ol>
<p>Functor とは上記2つの性質 (Identity, Composition) を示すような型制約のことを指します。<br>
上記の map は Functor の例のために仮においたもので、map 以外の Functor の性質を持つ関数も同様の性質を示すことが期待されます。<br>
また map 関数の定義における f には任意の Functor を適用できます。</p>
<h2>Functor 制約を持つ関数の実装例</h2>
<p><a href="https://github.com/ramda/ramda-fantasy">Ramda Fantasy</a> では Functor として Maybe, Either など8つの実装が紹介されています。<br>
また Array, Object も Functor の性質を満たすことが分かっています。<br>
これらはすべて Functor の性質を満たしているので、Ramda.js の map 関数を適用できます。</p>
<p>以下で map 関数を使った実装例を紹介します。</p>
<pre><code class="language-javascript">const R = require('ramda');
const S = require('sanctuary');

const mapFunc = R.map(R.compose(S.mult(2), S.add(1)));
const a = [1,2,3];
const z = S.Just(42);
const n = S.Nothing;
const w = S.Right(99);
const e = S.Left(&quot;error&quot;);

console.log(mapFunc(a));
console.log(mapFunc(z));
console.log(mapFunc(n));
console.log(mapFunc(w));
console.log(mapFunc(e));
</code></pre>
<p><code>mapFunc</code> は Number を値に持つ Functor の中身に &quot;1 を足して 2 倍する&quot; 関数です。<br>
上記で mapFunc という関数を異なる Functor に適用していることに注目してください。<br>
ここでは List Number, Maybe Number, Either Number のそれぞれの値に全く同じ形式で mapFunc を適用しています。</p>
<p>出力結果は以下のとおりです。</p>
<pre><code>[ 4, 6, 8 ]
Just (86)
Nothing
Right (200)
Left (&quot;error&quot;)
</code></pre>
<p>各値に &quot;1を足して2倍した&quot; 結果が得られていますね。</p>
<h2>そもそも Functor を使うと何がうれしいの？</h2>
<p>Functor 自体は抽象的な存在であり、そのものが実践的な役割を持つわけではありません。<br>
Functor である Maybe などが実際に便利さを示します。<br>
したがって、ここでは Maybe を使うと何が便利になるかということを例に説明します。<br>
<code>Maybe a</code> は <code>Nothing</code> と <code>Just a</code> という2つの値コンストラクタを持ちます。</p>
<pre><code class="language-Haskell">Maybe a = Nothing | Just a
</code></pre>
<p>※ <a href="https://github.com/sanctuary-js/sanctuary">Sanctuary.js</a> の実装では <code>S.Nothing</code> と <code>S.Just(value)</code> という関数がコンストラクタです。<br>
ここで a は Non-Nullable Value になります。null は Nothing に変換されます。<br>
Maybe の世界には null は存在しないので、値が null であるかどうかをチェックする必要はありません。<br>
実装例で示したように Functor (Maybe) であることを前提とした関数を適用した場合には、Nothing か Just かを気にすることなく関数を適用することができます。<br>
Maybe を使う場合に null または Nothing を気にしなければならないのは、以下の2つの時だけです。</p>
<ol>
<li>外界から Maybe の世界に値を変換する時</li>
<li>Maybe の世界から外界に値を変換する時</li>
</ol>
<p>つまり、Maybe を使うと多くのプログラマにとって煩わしい null チェックの回数を大幅に減らすことができます。</p>
<p>本記事では Functor を主な例として説明しましたが、Fantasy Land に記載されているように Functor よりもさらに複雑な条件を持つ Applicative や Monad などの概念も存在します。<br>
これらを詳しくするには余白が足りないので他書にその役割を譲ることにします。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/2c88e33e-e64f-4f54-88ee-4205b516b80a/dependencies.png" alt="dependencies"></p>
<p>上記は Fantasy Land Specification から引用した図です。</p>
<h2>まとめ</h2>
<p>本記事では Ramda.js, Fantasy-Land を中心に Functor を使った JavaScript による関数型プログラミングに触れる試みをしました。<br>
現実的に現段階において本記事の概念に近づく実装をするためには以下を実践するほうがよいでしょう。</p>
<ul>
<li><a href="https://www.typescriptlang.org/">TypeScript</a> で <a href="https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-0.html">strictNullChecks</a> を有効にする</li>
<li><a href="http://www.purescript.org/">PureScript</a> で実装する</li>
</ul>
<p>また本記事では説明できなかった項目やさらに発展的な内容を知るには Haskell などのプログラミング言語の仕様や実装を学ぶことをオススメします。</p>
<h2>参考文献</h2>
<ul>
<li><a href="https://ramdajs.com/">Ramda.js</a></li>
<li><a href="https://github.com/fantasyland/fantasy-land">Fantasy Land Specification</a></li>
<li><a href="https://github.com/ramda/ramda-fantasy">Ramda Fantasy</a></li>
<li><a href="https://github.com/sanctuary-js/sanctuary">Sanctuary.js</a></li>
<li><a href="http://hackage.haskell.org/">Hackage</a></li>
<li><a href="http://randycoulman.com/blog/categories/thinking-in-ramda/">Courageous Software: Thinking In Ramda</a></li>
</ul>
<h2>最後に</h2>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a>または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
(function(d, s, id) {
var js, fjs = d.getElementsByTagName(s)[0];
if (d.getElementById(id)) return;
  js = d.createElement(s); js.id = id;
  js.src = "https://platform.wantedly.com/visit_buttons/script.js";
  fjs.parentNode.insertBefore(js, fjs);
}(document, "script", "wantedly-visit-buttons-wjs"));
</script>


Ramda.jsの関数を例にしてJavaScriptによる関数型プログラミングの考え方を紹介します


JavaScript で体感する関数型プログラミング | PLAID engineer blog

JavaScript で触れる関数型プログラミング

<p>こんにちは、SREの @ikemonnです。<br>
先日開催された <a href="https://builderscon.io/tokyo/2018/">builderscon tokyo 2018</a>で、<a href="https://karte.io/">KARTE</a>にSpinnakerを本番導入して得られた知見について発表させていただきました！</p>
<p>「<a href="https://www.spinnaker.io/">Spinnaker</a>」とは、Netflixが開発したマルチクラウド環境へのCD(Continuous Delivery)ツールです。<br>
利用企業としては、<a href="https://www.waze.com/">Waze</a>や<a href="https://www.mercari.com/jp/">mercari</a>等が有名です。</p>
<ul>
<li>Waze: <a href="/google-cloud-next-18-spinnaker/">Google Cloud Next '18でWazeのSpinnakerのセッションを聞いてきました!</a></li>
<li>mercari: <a href="https://tech.mercari.com/entry/2017/08/21/092743">SpinnakerによるContinuous Delivery</a></li>
</ul>
<p>KARTEでも2018年の1月からSpinnakerを本番環境で導入しており、Spinnakerの<a href="https://www.spinnaker.io/community/">community page</a>にロゴを載せてもらっています！</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/fc6f3d32-3193-42e8-b01c-5332fdf0a732/2018-09-11_10_25_27-1.png" alt="2018-09-11_10_25_27-1"></p>
<p>スライド:<a href="https://speakerdeck.com/ikemonn/builderscon-tokyo-2018">Multi-Cloud deploy with Spinnaker</a></p>
<script async class="speakerdeck-embed" data-id="538d3911f1db4e47aa40ad3a676a8853" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
<h2>概要</h2>
<p>Spinnakerの主な特徴は「Multi-Cloud」「Automated Releases」「Built-in Deployment Best Practices」です。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/dc6f7d76-58e8-44b0-9c91-b9f87e94f4c4/-2018-09-11-10.07.55-1.png" alt="-2018-09-11-10.07.55-1"></p>
<p>KARTEでは、SpinnakerをAWSとGCPのマルチクラウドへのデプロイで利用しています。<br>
(マルチクラウド構成についてはこちら:<a href="/devsumi-2018/">Developers Summit 2018に登壇してきました #devsumi</a>)</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/0432da5b-c632-45b2-922b-70ca3ed885bf/-2018-09-11-10.20.09-1.png" alt="-2018-09-11-10.20.09-1"></p>
<p>インフラの負荷としては、秒間最大22,000events/sec、1日10億eventsくらいで、これらを支えるインフラにデプロイしても問題なく稼働しています。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ed57ddbf-4de6-4fda-b61f-b2e7fb2438bb/-2018-09-11-10.19.43-1.png" alt="-2018-09-11-10.19.43-1"></p>
<p>Spinnakerは、「マルチクラウド対応」「デプロイ機能が充実」「Immutable Infraを強制する」等といった点で、マルチクラウドへのデプロイにはかなりオススメのツールです。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/6d614f1c-2327-4fe5-91b5-bb2fb9241cd2/-2018-09-11-10.21.13-1.png" alt="-2018-09-11-10.21.13-1"></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a6e480ef-9b83-4b1f-b45c-c2673dda32dc/-2018-09-11-10.21.31-1.png" alt="-2018-09-11-10.21.31-1"></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f08e5e82-12f4-4289-ae8f-3d062010db3b/-2018-09-11-10.21.46-1.png" alt="-2018-09-11-10.21.46-1"></p>
<p>しかし、Googleで検索しても運用周りの情報が少なく導入/検討しづらいなと感じていました。</p>
<p>そこで、今回の発表では「Spinnakerへの移行のきっかけ」「移行コスト」「運用してみて期待通りだった/期待と違ったこと」等の運用に関する内容を盛り込みました。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9ac75b9b-9553-48b4-ae9d-263ac4df0c20/-2018-09-11-10.24.09-1.png" alt="-2018-09-11-10.24.09-1"><br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/8e99a1f6-0bf4-49cd-89aa-38583038df87/-2018-09-11-10.22.25-1.png" alt="-2018-09-11-10.22.25-1"></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/7ccc4733-3151-4df6-bc75-24cf18965a81/-2018-09-11-10.22.51-1.png" alt="-2018-09-11-10.22.51-1"></p>
<p>「期待と違っていたこと」でバグの話をしましたが、Spinnakerも徐々に安定化してきており、現状回避できないバグには遭遇していません。(v1.9)<br>
(導入当時はどうしても回避できないバグがあり、修正してPR出してました…！)</p>
<p>マルチクラウドのCDをやっていくには自信を持ってオススメできるツールなので、ぜひぜひ試してみてください！</p>
<h2>補足</h2>
<p>スライドで紹介したツールやドキュメント等のリンクです。</p>
<ul>
<li><a href="https://www.spinnaker.io/">Spinnaker</a></li>
<li><a href="https://cloudplatform.googleblog.com/2017/06/spinnaker-10-continuous-delivery.html">Spinnaker 1.0: a continuous delivery platform for cloud</a></li>
<li>カナリアデプロイ
<ul>
<li><a href="https://github.com/spinnaker/kayenta">spinnaker/kayenta</a></li>
</ul>
</li>
<li>pipelineをコードで管理する
<ul>
<li><a href="https://blog.spinnaker.io/spin-and-roer-managed-pipeline-templates-4fde2951c648">spin and roer + Managed Pipeline Templates</a></li>
<li><a href="https://github.com/spinnaker/roer">spinnaker/roer</a></li>
<li><a href="https://github.com/spinnaker/dcd-spec">spinnaker/dcd-spec</a></li>
<li><a href="https://github.com/spinnaker/spin">spinnaker/spin</a></li>
<li><a href="https://docs.google.com/document/d/17Ifm562aypjLSHnNJ02COFv_VMv3spicH-7zMYd-oXE/edit#">Spinnaker CLI Design</a></li>
</ul>
</li>
<li><a href="https://join.spinnaker.io/">SpinnnakerのSlackグループ</a></li>
</ul>
<h2>最後に</h2>
<p>リアルタイム解析を実現するCXプラットフォームの「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、マルチクラウド環境の大規模インフラの設計/構築/運用をしていきたい！というエンジニア（インターンも！）を募集しています。</p>
<p>詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a>または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>


先日開催された builderscon tokyo 2018でスピーカーとして登壇させていただきました！ 概要 「Spinnaker」は、Netflixが開発したマルチクラウド環境へのCDツールです。今回はSpinnakerをKARTEに導入し、半年以上運用して得られた知見についてお話しました。 

Netflix発のOSS"Spinnaker"でマルチクラウドにデプロイしている話 #builderscon

<p>エンジニアチームの mkataigi です。たまには趣向を変えて、エンジニアっぽくないコードの出てこない話を書いてみようかなと思います。以下多分に個人の見解です。</p>
<p>ベンチャーに限らず、あらゆる組織において「最良の結果」を出すことは大事です。「最良の結果」を出せない組織は、一時的には成功したとしても、いずれ「最良の結果」を出した組織に追い抜かれてしまいます。一見着実に進んでるように見えるのに、なぜか競合に差をつけられていく、イノベーションのジレンマというやつですね。</p>
<p>有名な言葉ですが『「最良」の敵は「良」である』と言う言葉があります。人間の時間は有限なので、やったほうがいい（=良）ことをやり続けてしまうと、最大の結果（=最良）を出すための時間がなくなってしまう。つまり、組織が成功し続けるためには、常に「最良の結果」にフォーカスし続けることが必要、ということです。</p>
<p>なお、参考文献は以下になります。</p>
<ul>
<li>イシューからはじめよ―知的生産の「シンプルな本質」
<ul>
<li><a href="https://www.amazon.co.jp/dp/4862760856">https://www.amazon.co.jp/dp/4862760856</a></li>
</ul>
</li>
<li>仮説思考 BCG流 問題発見・解決の発想法
<ul>
<li><a href="https://www.amazon.co.jp/dp/4492555552">https://www.amazon.co.jp/dp/4492555552</a></li>
</ul>
</li>
</ul>
<h1>解くべき課題を考える</h1>
<p>「最良の結果」を出すためには何をすればよいのでしょう。まず「結果を出す」ためのステップを考えて見ます。</p>
<ol>
<li>課題を設定する</li>
<li>課題を解決する</li>
</ol>
<p>このうちどちらをより優先する必要があるのでしょうか。</p>
<p>抽象的でわかりにくくなってきたので、例えば<code>大阪で友達と会う</code>という結果を得ることを考えて見ます。この場合それぞれ次のようになります。</p>
<ol>
<li>課題設定 <code>大阪へ行く</code></li>
<li>解決方法 <code>新幹線で行く</code></li>
</ol>
<p>例えば大阪へ新幹線ではなく鈍行列車で行った場合（課題設定は正しく、解決方法が間違い）はどうなるでしょう。この場合は時間はかかるもののいずれ着くし、途中で間違いに気づけば特急に乗り換えするなどリカバリーをすることもできます。逆に、新幹線に適当に乗った場合（課題設定が間違い、解決方法は正しい）はどうなるでしょう。いくらたっても大阪に着くことはないですし、どこにいるかわからずリカバリーすることも難しくなります。つまり課題設定を正しくするほうが重要ということなります。</p>
<p>エンジニア業界でよくある「顧客が本当に必要だったもの」というやつですね。課題設定が正しくないと、結果が出ないどころか、不要なものを作ってしまいメンテナンスコストだけかかるという、マイナスの効果しか得られません。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/c3be8e6e-0e62-437d-98ff-9738cbcc0c8c/----------2018-08-23-17.29.13.jpg" alt="顧客が本当に必要だったもの"><br>
<a href="http://www.projectcartoon.com/">http://www.projectcartoon.com/</a></p>
<h1>最良の課題の条件</h1>
<p>では「最良の結果を出すための課題」を発見するにはどうすれば良いのでしょう。見つける方法を考える前に、まず、自分たちがどんなものを探すのかを明確にするために、どんな課題が最良の課題なのはっきりさせましょう。以下の３点がポイントかなと思います。</p>
<ul>
<li>その課題が解決されることで、将来に大きな影響を与える</li>
</ul>
<p>まず一つ目が、その課題が解決されると将来の展開が大きく変わるもの、になります。その課題が解決されることで別の課題をそもそも解く必要がなくなる課題です。</p>
<pre><code class="language-plaintext">「運転の自動化」という課題が解決されたら、
「大阪への移動経路を探す」「電車内で寝過ごさないようにする」などの課題が、そもそも課題ですら無くなる
</code></pre>
<ul>
<li>その課題は自分だけが解決できる</li>
</ul>
<p>次がなぜ自分がその課題に取り組むか、の部分です。自分以外の人には解決できないけど自分にだけ解決できる課題というのは、自分が解決しないとずっと課題のまま残り続けるため、より解決する重要度が高い問題となります。組織としてもそれがいわゆる競合優位性に繋がるので重要です。</p>
<pre><code class="language-plaintext">「大阪へ直行する路線を作ってしまう」ことができれば、
大阪へ行くための方法を探す必要は無くなる
</code></pre>
<p>（自分にはできないが、世の中にはできる人がいるかもしれない！）</p>
<ul>
<li>その課題に答える方法がある</li>
</ul>
<p>そして当たり前ですが、課題の答えを出せる、出す方法を思いつけることが重要です。結果を出すという観点から考えるとアウトプットが無いと無意味です。</p>
<pre><code class="language-plaintext">「ワープ」する機械を開発できれば大阪へ行くための方法を探す必要はないが、
現代の技術ではできる可能性は非常に薄い
</code></pre>
<h1>最良の課題を見つける方法</h1>
<p>最良の課題をテクニカルに見つける方法を、、、といきたいのですが、課題の定義からもわかる通り、誰にでも同じ方法で見つけられる、というものでは無いようです。とはいえ、それで諦めるのではなく、見つける可能性を高める方法を考えてみたいと思います。</p>
<p>一般的な方法として、最良の課題を探り当てられなくても、「これは良い課題かな？」というところから課題をブラッシュアップして最良に近づけていく思考法を考えてみます。状況によらずに常に成り立つ課題は、将来への影響が大きい可能性が高いと言うことはできそうです。</p>
<ul>
<li>極端な状態を考える</li>
</ul>
<p>状況を極端にしてみることで、状況が変わっても変わらない課題の本質が浮かび上がってきます。</p>
<pre><code class="language-plaintext">毎日大阪にいく場合はどうすればいいか
お金を無限に持っている場合にはどうするか
逆にお金がない場合はどうするか
</code></pre>
<ul>
<li>別の人の視点から考える</li>
</ul>
<p>複数の人の視点の重ね合わせることで、誰から見ても重要な、課題の本質が浮かび上がってきます。</p>
<pre><code class="language-plaintext">老人が大阪へいきたい場合はどうすればいいか
外国人ならどうするか
</code></pre>
<ul>
<li>抽象化したり具体化したりする</li>
</ul>
<p>課題を抽象的にしてみたり、具体的にしてみたりすることで、普遍的な課題の本質が浮かび上がってきます。</p>
<pre><code class="language-plaintext">抽象的にして別の場所に時間通りに着くにはどうするか
具体的にして大阪に15時に着くにはどうするか
</code></pre>
<h1>さいごに</h1>
<p>以上、最良の課題を見つけるための方法について見てきました。プレイドでも「データによって人の価値を最大化する」ために、日々最良の課題を発見するために奮闘しています。</p>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a>または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>


組織をより成長させるために、解くべき最良の課題にフォーカスする。そのための解くべき課題の見つけ方を考えてみる。

最良の課題を発見する技術 | PLAID engineer blog

最良の課題を発見する技術

<p>エンジニアの<a href="https://twitter.com/jumpei_ikegami">gami</a>です。<a href="https://twitter.com/search?vertical=default&amp;q=%23%E3%81%97%E3%81%8C%E3%81%AA%E3%81%84%E3%83%A9%E3%82%B8%E3%82%AA&amp;src=tyah">趣味はポッドキャスト配信</a>です。</p>
<p>今回は、「<a href="https://nodejs.org/">Node.js</a>」に焦点を当てた記事です。</p>
<p><a href="https://plaid.co.jp/">PLAID</a>では、約5年前から「<a href="https://karte.io/">KARTE</a>」というサービスを開発しています。そのサーバーサイドの実装は、ほとんどがNode.jsで記述されています。</p>
<p>一方、国内企業の中で、サーバーサイド実装にNode.jsを採用している企業は少ない印象があります。<br>
そこで、以下についてご紹介します。</p>
<ol>
<li>PLAIDがNode.jsで実現しているプロダクト</li>
<li>Node.jsを5年間使ってわかった強みと弱点</li>
<li>Node.jsを使いこなすための工夫</li>
</ol>
<h1>1. PLAIDがNode.jsで実現しているプロダクト</h1>
<p>実際にPLAIDがどのようにNode.jsを使っているかを紹介します。PLAIDでは、「リアルタイムユーザー解析サービス」であるKARTEを主に開発しているので、KARTEの開発について説明します。</p>
<h2>プロダクトの規模</h2>
<p>まずは前提として、KARTEのプロダクトとしての規模がわかるデータを紹介します。</p>
<h3>リクエスト数、イベント数</h3>
<p>KARTEが解析しているデータの規模感は、2018年8月現在の値でおよそ以下の通りです。</p>
<ul>
<li>最大 約20,000 イベント/秒</li>
<li>最大 約10億 イベント/日</li>
</ul>
<p>KARTEが扱うユーザー情報は、「イベント」という単位で連携、解析されます。エンドユーザーのブラウザから飛んでくるリクエストの中に、1つ以上のイベントが含まれています。<br>
1日で10億回ものユーザー解析を処理しているので、かなり「大規模」と言えるかと思います。</p>
<h3>ファイル数</h3>
<p>KARTEのメインのリポジトリのうち、Node.jsで書かれたサーバーサイドの実装に関するファイルの数と行数をカウントすると、以下の結果になりました。</p>
<ul>
<li>ファイル数
<ul>
<li>1,759ファイル</li>
</ul>
</li>
<li>行数
<ul>
<li>126,256行</li>
</ul>
</li>
</ul>
<p>（マイグレーションバッチ、テストコード、空行、コメント行などは除く）</p>
<p>他にも、一部の独自ライブラリはリポジトリを分けて開発しているので、それを加えるともう少し大きくなります。</p>
<h2>実現している機能</h2>
<p>以下の図がKARTEの大まかな構成図です。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/1e0a1a17-d440-48a9-988a-55b9a5058519/----------2018-08-15-14.41.54-1.png" alt="----------2018-08-15-14.41.54-1"></p>
<p>今後の説明のために、ざっと解説します。</p>
<h3>track/analyze（エンドユーザーの解析とデータ送受信）</h3>
<p>KARTEでは、解析対象のサイトにタグ（ネイティブアプリならSDK）を設置してもらいます。<br>
そこから送られるイベントをリクエストとして受け取り解析をするのが、「track」と「analyze」です。</p>
<ul>
<li>タグやSDKからイベントデータを受信
<ul>
<li>エンドユーザーのセグメントを解析</li>
</ul>
</li>
<li>1秒以内にエンドユーザーにポップアップなどの最適なアクションを送信</li>
<li>レスポンス後の処理も含めて、ユーザーデータを再計算</li>
</ul>
<p>特に、エンドユーザーからのリクエストに対してポップアップなどの最適なアクションを1秒以内に返す必要があり、高いパフォーマンスが求められる部分です。後述するように、NodeのClusterモジュールを使って負荷分散しています。</p>
<p>なお、KARTEではエンドユーザーから送られるイベントデータのスキーマをほとんど決めていないため、大量のスキーマレスなJSONデータを受け取る必要があります。Node.jsはJSONデータの取り回しが楽である反面、大規模なJSONを大量に扱うというCPUインテンシブな処理が苦手なのが悩みです。</p>
<h3>admin（クライアントに管理画面を提供）</h3>
<p>「admin」では、管理画面上でユーザーデータを閲覧できる機能等を提供しています。</p>
<ul>
<li>ルーティング
<ul>
<li>(SPA部分はvue-routerに任せる)</li>
</ul>
</li>
<li>設定値などを保存するMongoDBの操作
<ul>
<li>スキーマ定義</li>
<li>read/write</li>
</ul>
</li>
<li>フロントエンドから叩くRPC APIの提供</li>
</ul>
<p>KARTEではスキーマレスなNoSQL DBである「<a href="https://www.mongodb.com/">MongoDB</a>」を多用しています。MongoDBはほぼJSONライクなドキュメントを扱うので、Node.jsとの相性はかなりよく、DB周りの処理を自然に書くことができます。</p>
<p>主に実現している機能は以上です。</p>
<p>KARTEは「単純なWebサーバーとしての機能」だけではなく、「エンドユーザーの解析機能」をプロダクトのコアとして提供しています。その両方の機能について、特に言語を分けずに全てNode.jsで記述しています。</p>
<p>なお、システムの全体像や解析サービスを実現するGCPの活用方法については、PLAIDのエンジニア陣が執筆した以下の記事をご覧ください。</p>
<p><a href="https://codezine.jp/article/corner/711">大規模解析サービスを支えるGCP活用事例連載一覧：CodeZine</a></p>
<p><a href="https://codezine.jp/article/corner/711"><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/d31e904e-3650-45c6-9e29-730796f284af/----------2018-08-17-12.09.24.png" alt="----------2018-08-17-12.09.24"></a></p>
<h2>言語（AltJS）</h2>
<p>言語については、場所によって使い分けています。</p>
<ul>
<li>解析部分
<ul>
<li><a href="https://www.typescriptlang.org/">TypeScript</a></li>
</ul>
</li>
<li>その他
<ul>
<li>ES6</li>
<li><a href="https://coffeescript.org/">CoffeeScript</a>（一部）</li>
</ul>
</li>
</ul>
<p>解析エンジン部分だけは、固めに書きたいのでTypeScriptを使っています。大半のソースコードは、開発速度を優先して生のJavaScriptで記述しています。</p>
<p>元々はCoffeeScriptを使っていたのですが、世の多くの会社がそうであるように、Pure JavaScriptの機能強化に伴い、徐々に書き換えを進めています。</p>
<h2>フレームワーク、ライブラリ</h2>
<p>主に以下を使っています。（挙げるとキリがないので、だいぶ削っています）</p>
<ul>
<li><a href="http://expressjs.com/">Express.js</a>
<ul>
<li>薄いので拡張しやすい</li>
</ul>
</li>
<li><a href="https://lodash.com/">Lodash</a>
<ul>
<li>主に複雑なオブジェクトの操作で利用</li>
</ul>
</li>
<li><a href="https://caolan.github.io/async/">async</a>
<ul>
<li>非同期処理を連続/並列で実行するときに便利</li>
</ul>
</li>
<li><a href="http://mongoosejs.com/">Mongoose</a>
<ul>
<li>MongoDB用のODM（Object Document Mapper）</li>
</ul>
</li>
<li><a href="https://www.npmjs.com/package/cron">cron</a>
<ul>
<li>定期バッチの実行</li>
</ul>
</li>
<li><a href="http://plaidev.github.io/bolt-rpc/">bolt-rpc</a>
<ul>
<li>PLAID独自RPCライブラリ
<ul>
<li>OSSとして公開中</li>
</ul>
</li>
<li>内部で<a href="https://socket.io/">socket.io</a>を利用</li>
<li>Node.jsで記述</li>
</ul>
</li>
<li><a href="/webdb-forum-2016/">Brook</a>
<ul>
<li>PLAIDの独自解析エンジン</li>
<li>Node.jsで記述</li>
</ul>
</li>
</ul>
<h1>2. Node.jsを5年間使ってわかった強みと弱点</h1>
<p>上述したKARTEの実装を日々書いているPLAIDのエンジニアに、Node.jsのメリットとデメリットを訊いてみました。カテゴリ別に整理します。</p>
<h2>ノンブロッキング/イベントループ</h2>
<h3>強み</h3>
<p>Node.jsの良く知られたメリットは、KARTEの開発でも享受できています。</p>
<ul>
<li>大量のリクエストが来ても、パフォーマンスが低下しにくい</li>
</ul>
<h3>弱点</h3>
<p>逆に、非同期処理を多用するため、例外発生時やプロファイルをするときに問題の箇所を特定するのが難しかったり、そもそも記述が複雑になりやすかったりします。</p>
<ul>
<li>例外が起こったときのデバッグがキツい</li>
<li>プロファイルむずすぎ</li>
<li>非同期処理がわかりにくい</li>
</ul>
<h2>シングルスレッド</h2>
<h3>強み</h3>
<p>シングルスレッドであることで設計がシンプルになりやすい点は、意外とメリットを感じる点です。</p>
<ul>
<li>コンテキストスイッチによるパフォーマンス低下を防げる</li>
<li>ハードな制約なので、message queueなどを使って綺麗にプロセス分離したシンプルな設計になりやすい</li>
</ul>
<h3>弱点</h3>
<p>やはりCPUバウンドな処理が苦手な点が大きな弱点です。特に弊社の場合は大規模なJSONを扱うことが多く、JSONのパージングが同一スレッドで起きることでブロックされることに悩まされたりしています。</p>
<ul>
<li>シングルスレッド・マルチプロセスの癖/限界</li>
<li>シングルスレッドなのでハングすることがたまにあるし、原因特定が難しい</li>
<li>CPUをゴリゴリ使う処理とは相性が悪い</li>
</ul>
<h2>言語としての性質</h2>
<h3>強み</h3>
<p>特にPLAIDではフロントエンド/サーバーサイドでエンジニアを分けずに開発しているので、どちらも同じ言語で書けるというメリットは大きいです。</p>
<ul>
<li>フロントとサーバーサイドを同じ言語で書けるのでスイッチングコスト低い</li>
<li>JSONをそのまま扱える</li>
<li>非同期処理が簡単に書ける</li>
<li>決まりごとが少なく、用途が自由</li>
</ul>
<h3>弱点</h3>
<p>逆に、Node.js自体が自由すぎて起こる問題もあります。なお、一部では前述のようにTypeScriptを導入しています。</p>
<ul>
<li>シンプル過ぎるので、ファイル構成からコードの書き方まで混乱しがち</li>
<li>typoなどで実行時エラーが起こる</li>
<li>型が弱い</li>
</ul>
<h2>npm/エコシステム</h2>
<h3>強み</h3>
<p>大量のnpmライブラリがOSSとして公開されていて、CTO曰く「センスがいいモジュールが多い」ということです。</p>
<p>また、Node.jsが使っているJavaScriptエンジンであるV8の進化が早く、Node.jsのバージョンを上げただけでパフォーマンスが大幅に向上したことがあります。過去にはKARTEでも、Node.jsのバージョンを6から8に上げたとき、パフォーマンスが2倍以上上がった例がありました。</p>
<ul>
<li>ミニマムでセンスがいいライブラリが多い印象</li>
<li>GoogleがV8をどんどん進化させてくれる</li>
<li>Express.jsがシンプルで良い</li>
</ul>
<h3>弱点</h3>
<p>反面、npm自体のバグや依存性解決の難しさで時間を溶かすことも多かったです。依存性解決については、以前<a href="/npm-to-yarn/">このブログでも紹介</a>しています。ただし、npmのバージョンアップで徐々に解消されつつあります。</p>
<ul>
<li>npmのバグが多い</li>
<li>node_moduleの依存関係周りが辛い</li>
</ul>
<h1>3. Node.jsを使いこなすための工夫</h1>
<p>大規模で高いパフォーマンス要求を求められるプロダクトの実現や、Node.jsの弱点の補完のために実施していることをいくつか紹介します。</p>
<h2>Node.jsのClusterモジュールによる負荷分散</h2>
<p>KARTEでは最大で1秒間に数千リクエストを処理する必要があります。ただし、通常は1つのポートにアクセスできるプロセスは1つだけであり、そこがボトルネックになってしまいます。</p>
<p>そこで、Node.jsのClusterモジュールを使うことで、Cluster内に組み込まれたロードバランサが、リクエスト処理を複数のワーカープロセスに分割してくれます。これにより、CPUのコア数を最大限活かすことができます。</p>
<p>KARTEでは、特にtrackのパフォーマンス向上に役立っています。</p>
<h2>perfコマンドとFlameGraphを使ったCPUプロファイル</h2>
<p>CPU使用率が急上昇したときに、どの処理が重いのかを調べるため、CPUのプロファイリングをすることは多いと思います。しかし一部のプロファイリング用のライブラリは実際にコードの中に組み込むため、アプリケーション自体のパフォーマンスに影響する可能性があります。</p>
<p>そこで、perfコマンドで外側からプロファイルを取ることで、パフォーマンスにほぼ影響を与えずにCPUリソースを無駄に使っている関数を特定できるようにしています。</p>
<p>Node.jsでperfを使ったプロファイルを実現するには、<code>--perf-basic-prof-only-functions</code>などのプロファイル用のオプションを起動時に付ける必要があります。オプションを付けるとperf用の<code>.map</code>ファイルを吐いてくれます。</p>
<p>プロファイル結果は、<a href="https://github.com/brendangregg/FlameGraph">このライブラリ</a>を使ってFlameGraphとして出力しています。FlameGraphというのは、こういうやつです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/7b6c3bea-7c5f-4c82-8ce8-d67603d64957/----------2018-08-17-11.23.12.png" alt="----------2018-08-17-11.23.12"></p>
<p>出典: <a href="https://nodejs.org/en/blog/uncategorized/profiling-node-js/">Profiling Node.js | Node.js</a></p>
<p>使いどころとしては、hubotのコマンド経由でいつでも実行できるようにしている他、特定のインスタンスについて自動でプロファイル結果を出力するようにしています。KARTEではDatadogで各インスタンスのパフォーマンスを監視していますが、パフォーマンスが出ないインスタンスは自動で殺すようにしています。後からその原因を追いたい場合に備えて、殺す前に自動でperfコマンドを実行してプロファイルをしています。</p>
<p>なお、KARTEを支える監視サービスと構成については、以下の記事をご覧ください。</p>
<p><a href="https://codezine.jp/article/detail/10674">大規模解析サービスを支える監視サービスと監視構成のポイント | CodeZine（コードジン）</a></p>
<h2>マルチスレッド処理へ</h2>
<p>Node.jsは基本的にシングルスレッドで動作するので、特にCPUインテンシブな処理が苦手です。KARTEではスキーマレスな構造データを大量に行うため、その点がボトルネックになりやすいのが悩みでした。</p>
<p>Node.jsでもマルチスレッド処理がしたいという熱い想いは、弊社エンジニアの牧野が以前ブログで書いています。</p>
<p><a href="https://tech.plaid.co.jp/js_multi_threading/">MicrosoftのNapa.jsでJavaScriptをマルチスレッド化する | PLAID engineer blog</a></p>
<p>Node.js v10.5.0からWorker Threadsが使えるようになったので、今後は一部の処理をそちらに置き換える計画を立てています。</p>
<h1>まとめ</h1>
<p>Node.jsを採用して5年間ほどKARTEの開発に使い続けましたが、特に「リアルタイムユーザー解析サービス」である特性上、その恩恵を受けることが多い。</p>
<p>また、Node.jsやV8の進化も早く、今後の発展が非常に楽しみです。</p>
<p>国内企業がプロダクションでNode.jsを採用する例はまだまだ少ないですが、とても強力な言語なのでぜひ使っていきましょう！</p>
<hr>
<p>リアルタイムユーザー解析プラットフォームの「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。</p>
<p>詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a>または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>


Node.jsをリアルタイム解析サービスの開発で5年間使って知ったメリットやデメリットを紹介します。大規模な解析サービスをNode.jsで記述する上での工夫などについても解説しています。

PLAIDがNode.jsを採用し、5年間で12万行書いてわかったこと | PLAID engineer blog

PLAIDがNode.jsを採用し、5年間で12万行書いてわかったこと

<p>はじめまして。デザイナーの @kazutokojima です。<br>
KARTEを実際に利用されている方の目線でプロダクトの使い勝手や体験を良くしていく「Kaizen」チームとして活動しています。</p>
<p>今回は、昨今よく聞くコンピュテーショナルデザインの考え方とその取り組みについてお話します。</p>
<hr>
<h2>デザインの種類</h2>
<p>「<strong>Design in Tech Report</strong>」については、2015年版の最初のレポートから読まれている方も多いと思います。</p>
<p>最近ではTHE GUILD勉強会「Design in Tech Report 2018 を読み解く」でも取り上げられました。<br>
今回の記事を書く上でとても参考になったのですが、その内容が<a href="https://goodpatch.com/blog/1st-design-in-tech-report-2018-the-guild/">記事として公開</a>されていますので、もしまだお読みでない方はぜひ読んでみてくださいね。</p>
<p>さて、同レポートでは2016年版から「<strong>３つの種類のデザイン</strong>」が提唱されています。</p>
<iframe src="//www.slideshare.net/slideshow/embed_code/key/3XJKMfA5UIw6Rw?startSlide=47" width="595" height="485" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen> </iframe> <div style="margin-bottom:5px"> <strong> <a href="//www.slideshare.net/johnmaeda/design-in-tech-report-2016-59530038" title="Design In Tech Report 2016" target="_blank">Design In Tech Report 2016</a> </strong> from <strong><a href="//www.slideshare.net/johnmaeda" target="_blank">John Maeda</a></strong> </div>
<p>上記のスライドを参考にそれぞれ見てみましょう。</p>
<h4>クラシカルデザイン：</h4>
<p>ロゴやポスターや建築、家具などデザイナー自身の意匠により最終的な完成品を仕上げることを目的としたデザインを指してそう呼んでいるようです。一般的に、他者への影響力や受賞歴など外部的な要因が成果となるようです。</p>
<h4>デザイン思考：</h4>
<p>同レポートではユーザーニーズ（共感）からビジネス上の課題（バイアス）を見つけ出し問題解決するために用いるプロトコル（手順）を指してそう呼んでるように思います。クラシカルデザインとは対象に、複数のステークホルダーとの合意形成など内部的な要因が成果となることが多いです。</p>
<h4>コンピュテーショナルデザイン：</h4>
<p>本来は設計などの知的作業をコンピューターに任せる新しいデザイン手法を指すようですが、同レポートでは利用環境や利用者数などの違いからクラシカルデザインと対比して、永遠に持続することを目的としたデザインというように捉えることができると思います。常に変わり続けて完成しないため、成長を続けていることだけが成果と言えるかもしれません。</p>
<br/>
<br/>
と、同レポートに記載されている内容を書き出してみました。
<p>それぞれのデザインの違いと、コンピュテーショナルデザインをどういう文脈で語ろうとしているかについてはご察しいただけたかと思いますが、これだけでは「コンピュテーショナルデザイン」がどういうものかまだピンと来ないですね。</p>
<p>では、どういう文脈でコンピュテーショナルデザインを語ろうとしているかという前提が共有できたものとして、今回の記事の本題に入っていきたいと思います。</p>
<hr>
<h2>デザインのScaleの関係</h2>
<p>ここから今回の記事の主張に入っていきたいと思います。</p>
<p>さきほどのスライドの図では、よく見ると3つの種類のデザインを「<strong>Scale</strong>」という横軸をとって並べています。<br>
その関係性を知ることで、コンピュテーショナルデザインをより立体的に理解出来るようになります。</p>
<p>では、「クラシカルデザイン」→「デザイン思考」→「コンピュテーショナルデザイン」のScaleの関係を整理してみましょう。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/8fcd9593-d113-418d-938e-7571482ff9d2/Untitled---New-frame--2-.jpg" alt="Untitled---New-frame--2-"></p>
<h5>→ クラシカルデザイン</h5>
<p>クラシカルデザインで重要なポイントとして「デザインをモノに定着させること」が挙げられます。<br>
デザイナー自身の意匠により見た人にとって良いと思えるような完成品に仕上げることはデザインにとって最重要と言えます。</p>
<p>まずは、クラシカルデザインのキーワードを「<strong>定着</strong>」としてみます。</p>
<h5>クラシカルデザイン → デザイン思考</h5>
<p>本来の「クラシカルデザイン」は才能ある個人による専門領域と言えますが、徐々にチームで対抗するプロセスが生まれていきます。自身の発想に依るのではなく、他者のニーズから着眼点を得る手法は今日ユーザー中心デザインなどと呼ばれています。</p>
<p>天才でなくともよいデザインが生み出せるようになり製品・サービスのコモディティ化が進むと、クラシカルデザインで言う「定着」作業の前段階においてさらに大きな視点で考えよう、という流れが出てきます。</p>
<p>そして、ユーザー中心にビジネス全体を考える「デザイン思考」が大きく注目されます。<br>
デザイン思考を広めたとされるIDEOのCEOティム・ブラウンは以下のように述べています。</p>
<blockquote>
<p>デザイナーの感性と手法を用いて、顧客価値と市場機会の創出をはかるもの</p>
</blockquote>
<p>デザイン思考は、「定着」作業を除くユーザー中心のクラシカルデザインのプロセスと同じと言えます。<br>
クラシカルデザインとの親和性はもちろん、デザイナーだけでは困難な規模の「発想」が出来るようになった点に「クラシカルデザイン→デザイン思考」のScaleの関係性をとることが出来ます。</p>
<h5>デザイン思考 → コンピュテーショナルデザイン</h5>
<p>クラシカルデザインとデザイン思考が深く結びついたことで、製品やサービスの品質は今まで以上に向上しています。</p>
<p>ただ、近年スマートフォンなどのテクノロジーが急速に発展を遂げながら個人に行き渡り、たくさんの人たちのコンテクストが実データとして得られるようになると、ユーザー中心に課題を捉えて解決策を形にするというプロトコルは、ユーザーからの情報量の増加に対してアウトプットのスピードが足りない、という事態に陥っているように捉えられるようになります。</p>
<p>そうなると、1つのモノに関わる利用者数の増加やテクノロジーの進歩に対して、ユーザーのニーズを満たす製品・サービスを提供するための考え方が必要とされるようになります。</p>
<p>そして、コンピュテーショナルデザインがそれにあたるのではないか、と同レポートからは受け取れるように思います。コンピュテーショナルデザインの核が、完成を求めず常に進化を続けることなら、別の言い方をすると、持続可能性を担保することとも表現できます。</p>
<p>それを「デザイン思考→コンピュテーショナルデザイン」のScaleにあてはめて考えると、デザイン思考で得た「発想」を「持続」して成長させ続けることができる関係が見えてきます。</p>
<br/>
<br/>
こうしてScaleの関係を整理してみると、3つの種類のデザインには密接な関わりがあり、またそれぞれのデザインへの取り組みが製品やサービスを大きく成長させるために必要だと言えることがわかりました。
<p>KARTEという自社のプロダクトに関わり、大きく成長しようとしている今、まさにこのコンピュテーショナルデザインの「持続」という考え方がぴったりとハマるように思います。そうすると、それをどのように実行していくのかが重要になってきます。</p>
<p>では、コンピュテーショナルデザインの取り組みへの第一歩として、KARTEで具体的にどのようなアプローチを進めているのかを見ていきましょう。</p>
<hr>
<h2>コンピュテーショナルデザインの第一歩</h2>
<p>「発想」を「持続」するために何から始めると良さそうか。</p>
<p>デザイン思考のScaleとしてコンピュテーショナルデザインを捉えると、製品やプロダクトのデザイン面だけの成長だけでなく、中期・長期的には組織の成長にも適用していけるように思います。</p>
<p>私個人としては、コンピュテーショナルデザインへの第一歩は将来的には組織・チームとしての持続性の醸成につなげていくためのものと考えています。</p>
<p>少しづつコンピュテーショナルデザイン的な考え方を広げていくために、個人規模で出来ることから探ってみます。<br>
まず、デザイン思考で上手く行かない部分からきっかけを見つけようと思います。</p>
<p>デザイン思考で「発想」し続けることが難しいと思われる理由に、ユーザー中心デザインの核とも言える「ペルソナ」が機能しないと思える点が多いことが挙げられます。</p>
<p>事実、KARTEのプロダクトにおいても業種や役職など多種多様で、チーム内でのブレない人物像を作り上げることは非常に困難なことです。仮に時間をかけて作成したとして、そのペルソナの行動の背後にある状況については推測が多くなるのが実際で、実データを原動力とするコンピュテーショナルデザインにおいては推測する時点ですでに不適合だと感じてしまいます。</p>
<p>ペルソナが上手く機能しづらい「事実」や「スピード」の要素を補完する他の方法はないかと検索していると、<a href="https://www.intercom.com/blog/using-job-stories-design-features-ui-ux/">こちらの記事</a>で「<strong>Job Story</strong>」という手法の存在を知りました。</p>
<p>記事の主旨は、ペルソナを使用するユーザーストーリーの代替として、ユーザーのジョブに着目したJob Storyの利点についての説明になります。ジョブという言葉が示すように、クレイトン・Ｍ・クリステンセン氏のJTBDの考え方をベースとしているようです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/550204c1-a2a9-481f-ae28-8f71e07b462e/Untitled---New-frame--1-.jpg" alt="Untitled---New-frame--1-"></p>
<p>ユーザーストーリーは、ユーザーが実現したいことやユーザーにとって価値があることを簡潔にまとめた文章のことで、アジャイル開発などでよく使われるモデリングの手法のようです。短い期間でイテレーションをまわすアジャイル開発において、ユーザーストーリーはそれ自体が機能要件として扱われることもあるようです。</p>
<p>対してジョブストーリーは、アジャイル開発におけるユーザーストーリーの機能的な側面を持ちつつ、ペルソナなどの推測部分を取り除くことで、ストーリーの因果関係をより明確にすることが出来ると説明されています。</p>
<p>両者の違いとして前者は「誰の」視点なのかにフォーカスしているのに対し、後者は「どういう時に」という状況にフォーカスを置いています。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3dd5c4a9-5675-428c-9bef-b01326cd5398/Untitled---New-frame--5-.jpg" alt="Untitled---New-frame--5-"></p>
<p>具体的にどういう違いがあるかを書いて比べてみます。</p>
<p><strong>ユーザーストーリー：</strong></p>
<ol>
<li>マーケターとして</li>
<li>ユーザーの個別の行動を知りたい</li>
<li>だからKARTEを使う</li>
</ol>
<p><strong>ジョブストーリー：</strong></p>
<ol>
<li>ユーザー獲得もいよいよ天井が見えてきて、ユーザーごとの売上を伸ばすのが重要になってきた</li>
<li>ユーザーの個別の行動を知りたい</li>
<li>だからユーザーに対して個別にアクションを行え、LTVを高めやすいKARTEを使う</li>
</ol>
<p>あくまで例ですが、フォーカスを置く対象が変わることで、前提条件との因果関係がよりはっきりするように思います。また、同じような規模のサービスが似た状況にあるだろうことも事実に基づいて考えることが出来ます。KARTEで言えば、「似た状況にあるサービスの数」×「LTVを高めるためのアイデアのインパクト」から優先度の決定までスムーズに行えそうです。</p>
<p>「Job Story」であれば、事実に基づき素早く判断して製品やサービスの成長を「持続」させることが出来そうなので、まずは下記の要望・フィードバックフォームを作成するところから始めました。</p>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/65513e5f-0e46-46aa-9f92-148a3924ca2a/----------2018-08-06-22.05.32.png" width="50%">
<p>最初ということもありわりと忠実にJob Storyを再現しています。<br>
当初は本当に和訳に近い形式で制作していたのですが、チームのメンバーにレビューを受ける中で日本語との違いや、文章の理解にブレが生じやすいことがわかったので、何度か修正を繰り返してこのフォーマットにしています。</p>
<p>現在は、このフォームを手始めに、いくつかある要望やフィードバックを受け付ける際のフォーマットを同じようなものに統一していきたいと考えています。また、チーム内でもジョブの考え方が広まってきており、少しづつユーザーの状況にフォーカスする取り組みが増えてきています。</p>
<p>直近は、ユーザーからの要望やフィードバックに細かな粒度で個別に素早く対応することになると思いますが、このようなフォーマットで要望やフィードバックを積み重ねていけば、本質的な改善を事実に基づいてブレのない状態でチームとしてこなせるようになるのではないかと期待しています。</p>
<p>事実に基づいていれば情報や判断に迷いが無くなるので当然スピードも上がります。また、足し算的な修正ではなく、引き算を含めた本来の意味での改善にも根拠を持って取り組めるようになります。</p>
<p>こうして、コンピュテーショナルデザインの言う常に変わり続けることを「持続」し続ける状態を生み出し、さらにこの繰り返しがやがて本来の意味でのコンピュテーショナルデザインに合流できれば良いなと思います。</p>
<h2>終わりに</h2>
<p>というわけで、自分なりの考えでコンピュテーショナルデザインの第一歩に「Job Story」を選び、実際にトライをしてみている、というお話でした。</p>
<p>ネット上では、「ペルソナに変えてJTBDモデルにしよう」という記事もたくさん見かけまし、それがベースとなっている「Job Story」自体は非常に有効なのではないかと思っています。</p>
<p>とはいえ、今回ご紹介した要望やフィードバックの集め方は遅効性の高い取り組みで、コンピュテーショナルデザインに求められるデータ駆動のスピードを獲得するにはまだまだ時間がかかりそうに思います。まだまだ工夫が必要そうです。</p>
<p>この記事を読んで、興味を持つきっかけや何かの助けになりましたら幸いです。</p>
<hr>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体のデザインに興味がある！というデザイナーを募集しています。</p>
<p>詳しくは <a href="https://plaid.co.jp/recruit.html#designer">弊社採用ページ</a><br>
または <a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a></p>
<p>をご覧ください。</p>
<p>もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>
<hr>
<p>最後までお読みいただきありがとうございました!</p>


スケールには必要？コンピュテーショナルデザインの考え方とその取り組み

<p>はじめまして。プレイドの @tomoponzoo です。<br>
2018年4月に入社、現在プレイド暦4ヶ月目のエンジニアです。<br>
プレイドでは、今年の3月にローンチした「<a href="https://karte.io/product/app/">KARTE for App</a>」のモバイルSDK開発をメインで担当しております。</p>
<p>開発に携わって4ヶ月が経ちましたが、今でもSDKをリリースする際は緊張してしまいます。それはSDKに非常に高いレベルの品質が求められるからです。</p>
<p>今回は、SDK開発の勘所や品質の重要性、仮にSDKで問題が発生してもアプリを絶対に死なせないための方法について考えていきたいと思います。</p>
<h2>SDK開発の勘所 - 品質の重要性</h2>
<p>冒頭で述べた通り、非常に高いレベルの品質が求められるSDKですが、それはなぜでしょうか？</p>
<p>仮に低品質なSDKを組み込んだ時に起こり得ることについて、想定してみます。</p>
<ul>
<li>アプリがクラッシュするなどの問題が頻発</li>
<li>アプリクラッシュにより、エンドユーザーの体験が悪化</li>
<li>エンドユーザーの体験が悪化することにより、クライアントのビジネスに悪影響を及ぼす</li>
<li>最終的には自らのビジネスも毀損する</li>
</ul>
<p>以上のように考えると、なぜSDKに高い品質が求められるのか理解できると思います。</p>
<p>このように高いレベルの品質が求められるSDKですが、開発するためには、エンジニアの想像力や品質への拘りが重要になります。これは非常に大変ですが奥深く面白い部分でもあります。</p>
<h2>品質維持のためのアプローチ</h2>
<p>では、高い品質の維持、また万が一問題が発生したときに影響を最小限に抑えるためにどんなことができるでしょうか？</p>
<ul>
<li>問題を起こさない仕組みを整える
<ul>
<li>ソースコードレビューの実施</li>
<li>テストの自動化</li>
</ul>
</li>
<li>問題が発生したときに影響を最小限に抑える仕組みを整える
<ul>
<li>確実なエラーハンドル</li>
<li>プロセス分離</li>
</ul>
</li>
</ul>
<p>このように品質維持のためのアプローチは様々ですが、今回は表題にもあるとおり、堅牢なSDKを実現するための方法として「プロセス分離」について考えてみます。</p>
<h2>堅牢なSDKを目指す！</h2>
<p>プロセス分離 - これはアプリケーションのプロセスと、SDKのプロセスを分離することです。<br>
プロセスを分けることで、仮にSDKのプロセスがクラッシュしたとしても、アプリケーションのプロセスには影響を与えず、処理を継続することが可能になります。</p>
<p>なお本質的には、SDKがクラッシュしないように実装すべきです。<br>
ただし人間が作る以上、バグが入り込む可能性は0ではありません。もちろんバグが入り込まないように様々な対策を行うわけですが、それらをすり抜けバグが入り込む可能性は否定できません。<br>
万が一の事態におけるフェイルセーフとしてプロセス分離を活用すべきです。</p>
<p>ちなみに、iOSプラットフォームにおいてプロセス分離を行うのは至難の業です。というのも通常のアプリケーションからはプロセスを自由に生成することができません。そのため今回はその制限の中でどうやってプロセス分離を実現するか試行錯誤しながら考えていきたいと思います。</p>
<h2>マルチプロセス（プロセス分離）を実現するための手段</h2>
<p>では、マルチプロセスを実現する場合にどんな手段があるでしょうか？<br>
パッと思いつくものを列挙してみました。</p>
<ul>
<li>fork</li>
<li>App Extension</li>
</ul>
<h2>forkとは？</h2>
<p>あまりにも有名で説明は不要かと思いますが、forkはUNIXシステムにおけるシステムコールのひとつです。<br>
forkを使うことで、これを呼び出したプロセスのコピーを生成することができます。</p>
<p>iOSは、UNIX系システムのひとつであるため、forkを使うことが可能です。</p>
<h2>forkを試す</h2>
<p>では、早速forkを使ってプロセスの生成ができるか試してみたいと思います。<br>
まずXcodeで適当なプロジェクトを作成、<code>main.c</code> を以下のように修正し、シミュレーターで実行してみます。<br>
うまく行けば、子プロセスが作成されプロセス分離への道が開けます。</p>
<pre><code class="language-obj-c">int main(int argc, char * argv[]) {
  pid_t pid = fork();
  if (pid == -1) {
    NSLog(@&quot;fork() failed&quot;);
  } else if (pid) {
    NSLog(@&quot;[Parent] PID: %d, PPID: %d&quot;, getpid(), getppid());
  } else {
    NSLog(@&quot;[Child]  PID: %d, PPID: %d&quot;, getpid(), getppid());
  }
}
</code></pre>
<pre><code class="language-plaintext">2018-07-28 17:35:45.858546+0900 MultiProc[39705:13798053] [Child]  PID: 39705, PPID: 39702
2018-07-28 17:35:45.858704+0900 MultiProc[39702:13797947] [Parent] PID: 39702, PPID: 39703
</code></pre>
<p>おっ！意外にも、あっさりプロセスの生成ができてしまいました。<br>
子プロセスの親プロセスIDを確認すると、親プロセスのIDと一致しており、親子関係があることが確認できます。</p>
<p>同じことを実機を使ってやってみたいと思います。</p>
<pre><code class="language-plaintext">2018-07-28 18:17:47.617257+0900 MultiProc[4926:1877048] fork() failed
</code></pre>
<p>今度は失敗しました。<br>
iOSでは、アプリケーションの<a href="https://developer.apple.com/jp/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html">バックグラウンド実行</a>にかなりの制限があります。そのため独自にプロセスを生成して動かすこと自体不可能なのでは？と思っていましたが、やはり当初の想定通りダメなようです。</p>
<h2>App Extensionとは</h2>
<p>forkがダメだったので、もうひとつのアプローチについて考えてみます。</p>
<p>App Extensionですが、 <a href="https://developer.apple.com/jp/documentation/General/Conceptual/ExtensibilityPG/index.html">App Extensionプログラミングガイド</a>で説明されている通り。<br>
iOSアプリケーションを拡張する仕組みのひとつです。アプリケーションとは分離された別のプロセスとして動作するのが特徴です。</p>
<p>アプリケーションを拡張するために用意された仕組みであるため、通常はAppleが用意した拡張ポイントに対応するExtensionしか開発できません。<br>
今回は、プロセス分離を実現すべく非公開の拡張ポイントを利用して独自のExtensionを作ってみます。</p>
<h2>App Extensionの仕組み</h2>
<p>独自のExtensionを作る前に、Extensionの仕組みについてみておきます。</p>
<p><strong>Extensionのライフサイクル</strong><br>
通常は停止しています。<br>
アプリケーションからのリクエストに応じて起動し、処理を実行、最後に結果をレスポンスし、終了する流れになります。</p>
<p><strong>Extensionとのやりとり</strong><br>
アプリケーションとExtension間のやりとりには、XPCと呼ばれる仕組みが利用されており、シリアライズしたプロパティリストをやりとりすることでプロセス間通信が実現されています。<br>
なお実際にやりとりを行う際は、XPCをラップしたNSExtensionと呼ばれる非公開クラスを利用して、やりとりを行うことになります。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/1704575d-34af-4e4b-a1da-d28ace594fa2/extension.png" alt="extension"></p>
<h2>App Extensionを作る</h2>
<p><strong>注意！！！<br>
App Extensionの作成過程で非公開APIを利用しています。<br>
非公開APIを利用した場合、審査でリジェクトされる可能性がありますのでご注意ください。</strong></p>
<p>では、Extensionを作っていきましょう。<br>
適当なプロジェクトを1個作成しておきます。</p>
<h4>1. App Extensionを作成</h4>
<p>任意のテンプレートを利用してExtensionを作成します。</p>
<h4>2. App Extensionの設定を修正</h4>
<p>Info.plistにExtensionの拡張ポイントや主要クラスの設定があるので、以下のように修正します。</p>
<pre><code class="language-xml">&lt;key&gt;NSExtension&lt;/key&gt;
&lt;dict&gt;
　&lt;key&gt;NSExtensionPointIdentifier&lt;/key&gt;
　&lt;string&gt;com.apple.app.non-ui-extension&lt;/string&gt;
　&lt;key&gt;NSExtensionPrincipalClass&lt;/key&gt;
　&lt;string&gt;Extension&lt;/string&gt;
&lt;/dict&gt;
</code></pre>
<h4>3. 非公開APIのインターフェースを定義</h4>
<p>NSExtensionは非公開のAPIです。<br>
利用するためには、APIに対応するヘッダーファイルを各々で用意する必要があります。</p>
<p>なお非公開APIのインターフェースを調べるには、<a href="http://stevenygard.com/projects/class-dump/">class-dump</a>などのツールを利用します。</p>
<p>今回は、以下のようなヘッダーファイルを作ります。</p>
<pre><code class="language-obj-c">@interface NSExtension : NSObject
+ (instancetype)extensionWithIdentifier:(NSString *)identifier error:(NSError **)error;

- (void)beginExtensionRequestWithInputItems:(NSArray *)inputItems completion:(void (^)(NSUUID *requestIdentifier))completion;
- (int)pidForRequestIdentifier:(NSUUID *)requestIdentifier;
- (void)cancelExtensionRequestWithIdentifier:(NSUUID *)requestIdentifier;

- (void)setRequestCancellationBlock:(void (^)(NSUUID *uuid, NSError *error))cancellationBlock;
- (void)setRequestCompletionBlock:(void (^)(NSUUID *uuid, NSArray *extensionItems))completionBlock;
- (void)setRequestInterruptionBlock:(void (^)(NSUUID *uuid))interruptionBlock;
@end
</code></pre>
<h4>4. ホストアプリケーションを実装</h4>
<p>Extensionとプロセス間通信を行うために、NSExtensionクラスのインスタンスを生成し、リクエスト処理やレスポンス処理を実装します。</p>
<p><strong>NSExtensionインスタンスの生成</strong></p>
<pre><code class="language-obj-c">NSExtension *extension = [NSExtension extensionWithIdentifier:@&quot;jp.co.plaid.MultiProc.Extension&quot; error:nil];

[extension setRequestCompletionBlock:^(NSUUID *uuid, NSArray *extensionItems) {
　　// リクエスト完了
　　NSLog(@&quot;Request completed: %@&quot;, uuid);
}];
</code></pre>
<p><strong>Extensionにリクエストする</strong></p>
<pre><code class="language-obj-c">NSExtensionItem *item = [[NSExtensionItem alloc] init];
[item setAttachments:@[@&quot;VALUE&quot;]];

[extension beginExtensionRequestWithInputItems:@[item] completion:^(NSUUID *requestIdentifier) {
　　int pid = [extension pidForRequestIdentifier:requestIdentifier];
　　NSLog(@&quot;Began extension request: %@. Extension PID: %i&quot;, requestIdentifier, pid);
}];
</code></pre>
<h4>5. Extensionを実装</h4>
<p>ヘッダーファイルを修正します。<br>
Extensionクラスが<a href="https://developer.apple.com/documentation/foundation/nsextensionrequesthandling?language=objc">NSExtensionRequestHandling</a>プロトコルに適合することを宣言します。</p>
<pre><code class="language-obj-c">@interface Extension : NSObject &lt;NSExtensionRequestHandling&gt;
@end
</code></pre>
<p>実装ファイルを修正し、NSExtensionRequestHandlingプロトコルに適合させます。</p>
<pre><code class="language-obj-c">@implementation Extension
- (void)beginRequestWithExtensionContext:(NSExtensionContext *)context {
　　// レスポンスを返す
　　[context completeRequestReturningItems:@[] completionHandler:^(BOOL expired) {
　　　　NSLog(@&quot;Completed request.&quot;);
　　}];
}
@end
</code></pre>
<h2>App Extensionを動かしてみる</h2>
<p>ここまでできたらシミュレーターで実行してみます。<br>
以下のようなログが出ればOKです。<br>
ホストアプリケーションのプロセスIDが74665、ExtensionのプロセスIDが74671となっており、それぞれ別のプロセスで動作していることが確認できます。</p>
<pre><code class="language-plaintext">2018-07-29 22:19:03.749751+0900 MultiProc[74665:14952372] App PID: 74665
2018-07-29 22:19:12.725051+0900 MultiProc[74665:14952478] Began extension request: 34E68F5B-520A-48EC-93EE-03599A310B24. Extension PID: 74671
2018-07-29 22:19:12.730459+0900 MultiProc[74665:14952478] Received response.
</code></pre>
<h2>App Extensionをクラッシュさせてみる</h2>
<p>さて、ここまで色々試してきましたが、ここで当初の目的である「SDKがクラッシュしても、アプリが絶対に死なない！」ことを確認してみたいと思います。</p>
<p>以下のように、Extensionをクラッシュさせるためのコードを入れて実行してみます。</p>
<pre><code class="language-obj-c">NSExtensionItem *inputItem = context.inputItems[1];
</code></pre>
<p>Extensionでは、NSRangeExceptionが発生しクラッシュしますが、アプリケーションは影響を受けず何事もなかったかのように動作しています。</p>
<h2>まとめ</h2>
<p>今回は「プロセス分離」という手段を用いて、堅牢なSDKを実現する方法とその可能性について探ってみました。</p>
<p>現状はプラットフォームとしての制約が大きく、また非公開APIを利用しないと実現できないなど、実際にプロダクトに適用するのは難しいということが分かりました。<br>
アプリケーションからプロセス生成できない理由として、端末の性能やリソース制約の問題が大きいと考えています。将来端末のリソース制約について考えなくて良くなった時には、このような手段も現実味を帯びてくるのではないかと思いました。</p>
<p>なお今回作成したアプリのソースコードは<a href="https://github.com/tomoponzoo/MultiProc">GitHub</a>で公開していますので、動作や実装が気になる方は、ぜひダウンロードして動かしてみてもらえればと思います。</p>
<h2>最後に</h2>
<p>CXプラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、品質にこだわりたい！想像力をフルに発揮したい！モバイルエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a><br>
または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a><br>
をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>


はじめまして。プレイドの @tomoponzoo です。
今回は、SDK開発の勘所や品質の重要性、仮にSDKで問題が発生してもアプリを絶対に死なせないための方法について考えていきたいと思います。

絶対にアプリを死なせない！プロセス分離による堅牢なSDKの実現方法 | PLAID engineer blog

絶対にアプリを死なせない！プロセス分離による堅牢なSDKの実現方法

Engineer Blog

Recent Article