2019年以降、Slack APIがどのように変化し何に注意すべきかについてご紹介します。主にBlock Kit、Modal、Home tabなどSlack上での新しい表現や、Granular permissionsと呼ばれる新しい権限モデルへの対応方法について詳しく説明しています。

2020年のSlack App開発者が知るべき最新のSlack API仕様 | PLAID engineer blog

2020年のSlack App開発者が知るべき最新のSlack API仕様

<html><head></head><body><p>こんにちは、エンジニアの <a href="https://github.com/komukomo" target="_blank" rel="noreferrer">@komukomo</a> です。2020/01/30 に行われた <a href="https://inthecloud.withgoogle.com/anthos-day-2001/register.html" target="_blank" rel="noreferrer">Google Cloud Anthos Day</a> に 「GKEにおけるセキュリティ対策と運用」というタイトルで登壇させていただいので、こちらのブログでもその内容を簡単にまとめておきます。（他の登壇者の方の資料も<a href="https://inthecloud.withgoogle.com/anthos-day-2001/register.html" target="_blank" rel="noreferrer">公式サイト</a>にて公開されています）</p>
<hr>
<p>我々が開発している <a href="https://karte.io/" target="_blank" rel="noreferrer">KARTE</a> ではユーザの行動データを扱っており、その中にはセンシティブなデータも含まれているので KARTE を開発する上ではセキュリティというのは重要なトピックです。ということで今回お話したのはセキュリティに関する内容で、直接プロダクトの KARTE とは関係ないのですが、</p>
<ul>
<li>GKE でのセキュリティに関する考え方</li>
</ul>
<p>と、個別機能の紹介とユーザ目線での注意点や感想ということで</p>
<ul>
<li><a href="https://cloud.google.com/kubernetes-engine/sandbox/" target="_blank" rel="noreferrer">GKE Sandbox</a></li>
<li><a href="https://cloud.google.com/binary-authorization/" target="_blank" rel="noreferrer">Binary Authorization</a></li>
<li><a href="https://cloud.google.com/anthos/config-management/" target="_blank" rel="noreferrer">Anthos Config Management</a></li>
</ul>
<p>について発表してきました。内容としては、これからGoogle Kubernetes Engine (GKE) を導入しようとしている方や運用しはじめの方、機能の概要を知りたい方向けのお話となっています。</p>
<p>こちらにスライドとざっくりお話した内容を載せておきます。</p>
<script async="" class="speakerdeck-embed" data-id="b9e34200315a473fae23b66f07ca4168" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<h1 id="GKEにおけるセキュリティ対策">GKEにおけるセキュリティ対策</h1>
<p>最初のトピックは GKE でのセキュリティ対策の話で、中身を省いて結論のみ書いてしまうと、</p>
<ul>
<li>ユーザの管理範囲と Google の管理範囲を意識しましょう</li>
<li>まずは GKE 公式のドキュメントにそって運用していきましょう</li>
</ul>
<p>ということで基本的すぎる感じになってしまいましたが、それでも重要なことだとは思うので、ここにも当日紹介したドキュメントのリンクを貼っておきます。</p>
<p>GKE の記事:</p>
<ul>
<li><a href="https://cloud.google.com/kubernetes-engine/docs/concepts/security-overview" target="_blank" rel="noreferrer">Security overview</a></li>
<li><a href="https://cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster" target="_blank" rel="noreferrer">Hardening your cluster's security</a></li>
<li><a href="https://cloud.google.com/kubernetes-engine/docs/security-bulletins" target="_blank" rel="noreferrer">Security bulletins</a></li>
</ul>
<p>こちらは GKE に限らず、Kuberentes の記事:</p>
<ul>
<li><a href="https://www.cncf.io/blog/2019/01/14/9-kubernetes-security-best-practices-everyone-must-follow/" target="_blank" rel="noreferrer">9 Kubernetes Security Best Practices Everyone Must Follow</a></li>
<li><a href="https://kubernetes.io/blog/2016/08/security-best-practices-kubernetes-deployment/" target="_blank" rel="noreferrer">Security Best Practices for Kubernetes Deployment</a></li>
</ul>
<p>以降は個別の GKE の機能のお話です。</p>
<h1 id="GKE Sandbox">GKE Sandbox</h1>
<p><a href="https://cloud.google.com/kubernetes-engine/sandbox/" target="_blank" rel="noreferrer">GKE Sandbox</a> は、信頼できないワークロードをクラスタで動かすようなケースで有用な機能です。<br>
内部では <a href="https://gvisor.dev/" target="_blank" rel="noreferrer">gVisor</a> が使われていますが、この仕組みは使う前にざっくりとでも中身を知っておくとといろいろと判断する上で役に立ちます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/69ebe27d-0498-4443-96bb-bc1888ce20d6/Screen-Shot-2020-01-31-at-13.11.04.png" alt="Screen-Shot-2020-01-31-at-13.11.04"></p>
<p>gVisor では kernel の System Call をインターセプトして、kernel の機能を emulation するようなレイヤを実装しています。（さらっと書きましたが、なかなか凄まじい実装です。コードは<a href="https://github.com/google/gvisor" target="_blank" rel="noreferrer">こちら</a>。）<br>
このようなレイヤを実装することで、コンテナは System Call を直接実行できなくなり、Host はセキュリティを考慮して制限された System Call のみ処理するようになるので、kernel の脆弱性を悪用するような攻撃から Host を守ることができます。</p>
<p>この gVisor をGKE上で使えるようになっているのが、 GKE Sandbox です。</p>
<h2 id="注意点">注意点</h2>
<p>使用する上で気をつけておくとよさそうと感じたのは、互換性、パフォーマンス、gVisor の責任範囲についてです。</p>
<h3 id="互換性">互換性</h3>
<p>kernel の機能を emulation している部分があるので、そもそも使いたい機能が使えるかはまず確認しておくとよいかと思います。GKE Sandbox にも gVisor にも互換性に関するドキュメントがあるので両方読んでおくと確実かと思います。</p>
<ul>
<li><a href="https://cloud.google.com/kubernetes-engine/docs/concepts/sandbox-pods?hl=en#limitations-incompatible" target="_blank" rel="noreferrer">(GKE Sandbox) Incompatible features</a></li>
<li><a href="https://gvisor.dev/docs/user_guide/compatibility/" target="_blank" rel="noreferrer">(gVisor) Compatibility</a></li>
</ul>
<p>自分は GKE Sandbox を最初試したとき <a href="https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/" target="_blank" rel="noreferrer">Port Forward</a> が使えないということを知らずにデバッグしようとしていて、無駄に調査に時間をかけてしまいました😅</p>
<h3 id="パフォーマンス">パフォーマンス</h3>
<p>こちらもgVisorがSystem Callをemulationしているため gVisor を使うとそのワークロードのパフォーマンスが劣化する可能性があります。逆にいうと、System Call を激しく使わない数値計算のようなワークロードはそれほど影響はないと考えられます。<br>
実際に GKE Sandbox を使う場合にはもちろんその時に計測するかと思いますが <a href="https://gvisor.dev/docs/architecture_guide/performance/" target="_blank" rel="noreferrer">gVisor のPerformance Guide</a> もあるのでこちらも参考になるかと思います。</p>
<h3 id="gVisorの責任範囲">gVisorの責任範囲</h3>
<p>仕組みをしっていれば当たり前の話かもしれませんが、gVisor を使えばサンドボックス化は完璧、というものではありません。例えば Pod 間通信の制御をするなら別途設定が必要です。自社でサンドボックスのような基盤が必要なサービスを運用する場合は、gVisor の挙動を把握した上で適宜必要なレイヤーの制限をかけていく必要があります。<br>
gVisor がどのような目的で作られ、どのような脅威を軽減するのかについては <a href="https://gvisor.dev/docs/architecture_guide/security/" target="_blank" rel="noreferrer">Security Model</a> に詳しく書かれています。</p>
<h1 id="Binary Authorization">Binary Authorization</h1>
<p>次の話は<a href="https://cloud.google.com/binary-authorization/" target="_blank" rel="noreferrer">Binary Authorization</a>。こちらは信頼できるイメージのみがデプロイされることを保証できる機能です。クラスタでBinary Authorization を有効にすると、Pod 作成の前に Policy のチェックが入ります。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/66682698-9e64-4edf-8df2-0d15a91021ce/Screen-Shot-2020-01-31-at-13.35.02.png" alt="Screen-Shot-2020-01-31-at-13.35.02"></p>
<p>Policy の設定としては image の Path のホワイトリストの他、 <a href="https://cloud.google.com/binary-authorization/docs/making-attestations" target="_blank" rel="noreferrer">attestation</a> という概念があるので、信頼できる検証者によって検証されたイメージのみ許可、といった設定が可能です。（※発表スライド内では"署名"と書いてしまっていますが、英語では attest なので多分"証明"、"検証"という訳の方が正しいですね。）</p>
<p>設定可能な <a href="https://cloud.google.com/binary-authorization/docs/policy-yaml-reference" target="_blank" rel="noreferrer">Policyの仕様</a> はとてもシンプルなので、ざっと<a href="https://cloud.google.com/binary-authorization/docs/example-policies" target="_blank" rel="noreferrer">設定例</a> と合わせて読めばすぐに把握できるかと思います。</p>
<p>運用時は、いろいろと例外的な状況も発生するかと思いますが、Dry Run（Policyチェックしてログは出すが制限しない）や、Break Glass（ Policy を無視してデプロイできるようにするannotation）という機能もあり、こういった運用時の考慮もされています。</p>
<h2 id="注意点・感想">注意点・感想</h2>
<p>Binary Authorization の注意点としては、PolicyはGCPのプロジェクトごとで、クラスタごとの設定はある程度できるのですが Namespaceごとの細かい設定はできません。そのため、大きなクラスタで複数チームを Namespace で管理している場合は Policy 設定が難しいかもしれません。</p>
<p>ちなみに Mercari さんではGKEのBinary Authorizationではなく、その内部で使われている<a href="https://github.com/grafeas/kritis" target="_blank" rel="noreferrer">kritis</a> を<a href="https://tech.mercari.com/entry/2019/12/23/084839" target="_blank" rel="noreferrer">自社でフォークして使用している</a>とのことです。</p>
<p>また、「何かを強制する」機能全般に言えることですが、Dry Run や Break Glass の機能があるとはいえ、管理するProjectが大きくなればなるほど導入が大変になるものです。（有効化したものの全対応が難しくいつまでたっても dryrun 状態...のように）<br>
導入するつもりなら早めに、迷っているなら修正が難しくなる前に判断するのがよいかと思います。</p>
<h1 id="Anthos Config Management">Anthos Config Management</h1>
<p>最後に<a href="https://cloud.google.com/anthos/config-management/" target="_blank" rel="noreferrer">Anthos Config Management</a> （以下、ACM）。こちらは、セキュリティというよりは運用の話ですが、Namespace や RoleBinding など様々な設定を管理するための機能です。</p>
<p>ACMはいわゆる <a href="https://www.weave.works/blog/what-is-gitops-really" target="_blank" rel="noreferrer">GitOps</a> で クラスタの設定管理をするツールで、クラスタに ACM のオペレータを入れておくと、そのオペレータが指定した Git Repository と同期し設定をクラスタに反映してくれます。（ちなみに、とくに管理可能なオブジェクトの制限は今の所ないようで Namespace や RoleBinding だけでなく、Deployment や Service でも同期してくれます。そのため ACM でアプリケーションのようなものもデプロイ可能ですが、反映の順序は考慮されないそうなのであくまでも設定系のオブジェクトのみにしておいた方が良さそうです。）</p>
<p>単一クラスタ、単一 Namespace しか扱っていない場合はさほどありがたみはないかもしれませんが、複数クラスタ、Namespace を運用していて、似たようなポリシーを全体に適用したいケースなどに有用かと思います。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/24dbe497-853a-4a1a-8f86-e14c60707833/Screen-Shot-2020-01-31-at-13.35.41.png" alt="Screen-Shot-2020-01-31-at-13.35.41"></p>
<p>Git Repository との同期だけであればその他の <a href="https://fluxcd.io/" target="_blank" rel="noreferrer">flux</a> や <a href="https://argoproj.github.io/" target="_blank" rel="noreferrer">argo</a> などでも可能かとは思いますが、ディレクトリの階層構造でNamespace に階層構造のようなものを持たせられる、という点は特徴的です。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/13096746-712c-4544-b2bb-5a1dcdd9754b/Screen-Shot-2020-01-31-at-13.35.49.png" alt="Screen-Shot-2020-01-31-at-13.35.49"></p>
<p>例えば ACM で管理するポリシーの Repository を上の図のようなディレクトリ構成（緑は何らかのk8sオブジェクトのyaml、オレンジは Namespace の yaml とします）にした場合、Namespace が3つ (audit, service-a, service-b) 作成され、<code>all-policy</code> は全てのNamespace に反映、<code>app-policy</code>は <code>service-a</code>と<code>service-b</code>の Namespace にのみ反映、といった挙動になります。</p>
<p>ちなみに ACM の他にも、こういった階層構造を使うというアイデアはあるようです。<br>
https://github.com/kubernetes-sigs/multi-tenancy</p>
<h2 id="感想">感想</h2>
<p>ACM は仕組みも動作もシンプルなので、Anthos を使っていてクラスタ、Namespace が複数あるような環境ならば入れておいて特に損はなさそうかなと感じました。ACM の導入についても、既に多くのクラスタにいろいろな設定をいれて管理していたとしても、ACM 管理用の repository に対象のyamlを入れてそのオブジェクトが管理対象になる（ <code>configmanagement.gke.io/managed: enabled</code> という annotation がつきます）のを待つだけなのでそこまで大変ではなさそうです。</p>
<h2 id="Policy Controller">Policy Controller</h2>
<p>ACM の基本的な機能は以上なのですが、追加オプションとして、 <a href="https://cloud.google.com/anthos-config-management/docs/concepts/policy-controller" target="_blank" rel="noreferrer">Policy Controller</a> という機能もついており、こちらは <a href="https://github.com/open-policy-agent/gatekeeper" target="_blank" rel="noreferrer">Gatekeeper</a> を使ったポリシーの Enforcer です。（ACM の機能とは全く別機能のような気がしますが、現状 ACM の中の機能として提供されていたのでおまけとして紹介しています。）</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/0099943d-6ac9-4d92-aa5f-74580eafe43e/Screen-Shot-2020-01-31-at-14.49.23.png" alt="Screen-Shot-2020-01-31-at-14.49.23"></p>
<p>例えば <a href="https://kubernetes.io/docs/concepts/policy/pod-security-policy/" target="_blank" rel="noreferrer">PodSecurityPolicy</a> の場合は、「特権コンテナ禁止」といった特定の条件の制限ができるかと思いますが、こちらは任意の Kind の field をチェックできるため柔軟に設定をすることが可能です。公式の例では、Ingress の domain に重複がないか、Namespace に特定の prefix がついているか、などをチェックするサンプルがありました。</p>
<p>何をどう制限するか、というのは <a href="https://www.openpolicyagent.org/docs/latest/policy-reference/" target="_blank" rel="noreferrer">Rego</a> という言語で書くことになるのですが、<a href="https://cloud.google.com/anthos-config-management/docs/how-to/creating-constraints-and-templates" target="_blank" rel="noreferrer">よく使うテンプレートは予め用意されている</a>ので Rego を知らなくてもある程度使うことができます。</p>
<h1 id="最後に">最後に</h1>
<p>Google Cloud Anthos Dayで話したGKEのセキュリティとその周りの機能の紹介でした。Kuberentes も GKE でも次々と新機能がでてくるので追っていくのは大変ですが、全てのユースケースで必要なものではないものも多いので、しっかりそれぞれの機能を把握した上で適切に運用していきたいですね。</p>
<hr>
<h1 id="おまけ">おまけ</h1>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/c94b1c36-a2d1-45ee-ae26-2b5bd16a8c2f/anthosday-plaid.jpg" alt="anthosday-plaid"><br>
<a href="https://github.com/MasayaAoyama" target="_blank" rel="noreferrer">@amsy810</a> さんに撮っていただいた写真。ありがとうございます👍</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/aab76dea-068f-413c-832b-cfdbaa6baac5/20200130A_L260.jpg" alt="20200130A_L260"><br>
こちらは Google Cloud Anthos Day 後の懇親会。Googler、登壇者、スポンサー、様々なAnthos/k8sな人たちと話しました。これからのさらなる盛り上がりを感じたとともに、我々もどんどんアップデートしていかないとと感じました！...ということで、スピード感を持って一緒に開発していく仲間は常に募集しているので、興味のある方は<a href="https://meet.plaid.co.jp/" target="_blank" rel="noreferrer">弊社採用ページ</a>または <a href="https://www.wantedly.com/companies/plaid/projects" target="_blank" rel="noreferrer">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>
</body></html>

2020/01/30 に行われた Google Cloud Anthos Day に 「GKEにおけるセキュリティ対策と運用」というタイトルで登壇させていただいので、こちらのブログでもその内容を簡単にまとめておきます。

Google Cloud Anthos DayでGKEのセキュリティ対策と運用について話してきました | PLAID engineer blog

Google Cloud Anthos DayでGKEのセキュリティ対策と運用について話してきました

<p>こんにちは。プレイドで2019年8月から現在までDevインターンとして働いている大矢です。2020年4月からは正社員として働く予定です。<br>
この記事では、プレイドのインターンでどんなことをしたか、何を学んだか、そして入社を決めた理由について書いていきたいと思います。</p>
<h1>はじめに</h1>
<p>簡単に自己紹介をします。僕は大学では情報工学を専攻していて、自然言語処理の研究をしています。<br>
2019年の8月からプレイドでインターンを始めて、週4日程度で通い、今月で約半年になります。<br>
プレイドでインターンをする以前にも、他社のインターンでWebアプリの開発をしたり、自然言語処理の技術を使った開発をする機会は何度かありました。研究が落ち着いた頃、開発経験を積みたいと思いインターンを探していました。</p>
<h1>インターンを始めるまで</h1>
<p>プレイドのインターンの求人（ <a href="https://www.wantedly.com/projects/387546">https://www.wantedly.com/projects/387546</a> ）には</p>
<ul>
<li>求められるレベルが非常に高い</li>
<li>圧倒的に成長できる</li>
<li>社員と同じチームで働くことができる</li>
</ul>
<p>というように書いてあり、求められるレベルが非常に高いことにビビりつつも、ちょっと背伸びした環境にいたほうが成長できるということはなんとなく知っていたので、面接を受けてみることにしました。面接では、プレイドのインターンの制度について聞いたのが印象に残っています。<br>
プレイドに参加したインターン生は、インターン担当の社員、メンターと数ヶ月おきに面談を行います。面談までの期間の成果や働き方をみて、継続が難しいと判断された場合には契約の更新が行われない場合がある、というものです。<br>
最初は戸惑いましたが、この制度はとても良いものだと思いました。まず、求人に書いてあった「求められるレベルが非常に高い」「圧倒的に成長できる」に対する説得力が格段に上がりました。求人にこのようなことを書いてある会社は他にもありますが、この会社で働けば確実に成長できるなと感じました。<br>
また、自分にとっても良い刺激になるなと考えました。3ヶ月おきに評価があるため、それまで気が緩むことなく常に全力で働ける。そして契約の更新が行われた場合には、一定の自信になりますし、更新が行われなかった場合にも、学生なので生活に困るということはないし、挫折を味わうことで成長につながるのではないかと思いました。<br>
つまり、インターン生にとってもこの制度はプラスだと思い、インターンに参加することを決めました。</p>
<h1>インターンでやった仕事</h1>
<p>プレイドでは、エンジニアのチームは1チーム1〜5人程度に分かれ、そのチームで2〜3ヶ月の期間（フォーカスと呼びます）目標を立てて開発をしていきます。僕は、入社してから1ヶ月間はAPIチームというチームで働いていたのですが、フォーカスの区切りのタイミングで基盤チームというところを希望し、行かせてもらうことができました。<br>
それぞれのチームでやった仕事について紹介したいと思います。</p>
<h3>APIチームでの仕事</h3>
<p>インターンに参加して初めに与えられたタスクは、KARTEが提供する、開発者向けのAPIを開発するというものです。社員が取り組むような実践的で非常にやりがいのある仕事であると同時に、このタスクに関してはほとんど仕様が決まっていなかったので、僕にとってはチャレンジングな仕事でした。また、Node.js や Mongo DB についても全く経験がなかったため、技術的にも初めての状態でした。<br>
実際に取り組み始めてみると、そもそもKARTEのことをもっと知らないと、仕様を決めることもできないと感じました。以前に参加したインターンでは、仕様が決まったタスクが渡されることがほとんどだったので、そのプロダクトについて詳しくなくても、ある程度はできてしまうものでした。<br>
KARTEについて学ぶには、KARTE Dojo という、わかりやすい動画が用意されています。僕はその動画を見て、KARTEとはどんなもので、どういう機能がよく使われているのかということを理解しました。とは言っても、実際のユーザがどのように使っているか、APIにどのようなニーズがあるかまではわからないので、社員と相談しながら仕様を決めていきました。<br>
結果的に、無事に1つのAPIの実装を終えることができました。</p>
<h3>基盤チームでの仕事</h3>
<p>ちょうどフォーカスの区切りの頃、モノリシックなKARTEのシステムをマイクロサービス化するということを主に行なっているチーム（基盤チーム）があり、僕はとても興味を惹かれたので、9月からは基盤チームにジョインすることになりました。基盤チームでは他にも、開発環境をよくするための取り組みや、既存のサービスのパフォーマンスを改善するための取り組みを色々と行なっています。<br>
僕はチームとしてこのような仕事に打ち込めることが非常に有意義だと思いました。なぜなら、APIの開発をしていた時に、テストの不便さや、開発環境のパフォーマンスの悪さを感じつつも、目の前の仕事を早くこなさなければという気持ちが優先してしまい、具体的な改善作業をするには至らなかったからです。<br>
基盤チームでは、いろいろな事をしましたが、今は主にテストの改善をしています。まずは、不安定なテストを計測する仕組みを導入しました。 具体的には、github に push するたびにCircle CI で実行されるテストの結果を、Google BigQuery に送り、Google Data Portal で可視化しました。この可視化により、e2e（エンドツーエンド）テストの不安定なシナリオを特定できるようになったり、「不安定な気がする」ではなく「何%の確率で落ちているから不安定だ」と数値で示せるようになりました。<br>
また、不安定なテストにはある程度共通の原因があることもわかりました。改善については、テストケースに一つ一つ修正を入れていくというよりかは、今あるテストを壊して、不安定になる原因を排除しつつ作り直すというような方針で進めています。<br>
不安定なテストは開発スピードに大きく影響するため、非常にやりがいがあり責任のある仕事だと感じています。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/23177920-367c-4182-a4ee-8db534cf03f7/photo1.jpg" alt="photo1"></p>
<h1>インターンで感じたこと、学んだこと</h1>
<h3>仕事の進め方について</h3>
<p>インターンでも社員と同様に信頼して仕事を任せてもらえているという実感がありました。<br>
APIチームで開発をしているときに、プレイドで初めての仕事だったため、わからないことはどんどん質問するようにしていました。これまでのインターンやアルバイトなどで、そのように指導されていたからです。とにかく早く成果物を完成させるということに、重きを置きすぎていました。しかし、プレイドで仕事を始めて1〜2週間ほど経った時、メンターから「遠回りしても、自分一人で解ける範囲を増やすためにもっと時間を使って良いよ」という言葉をいただきました。<br>
実際にこのことを意識しながら仕事をしてみると、より解ける範囲が増えていくことに気づきました。問題に直面したとしても、次に何をするべきか考え、手を動かすことができました。<br>
こうして、自分が解ける範囲がどんどん増えて行くことを実感し、仕事が楽しく感じましたし、自信にもなりました。<br>
この時に、メンターが、インターン生が作る成果物だけでなく、インターン生の成長にも大きな価値があるという風に意識しているのだと感じました。</p>
<h3>APIについて</h3>
<p>APIチームでは、仕様を考えていく際に色々なことを学びました。<br>
APIはKARTEでできないことを外でしてもらうためのサービスなので、既存の管理画面からGUIで操作が可能なことを提供しても意味がありません。自分なりに、KARTEのユーザだったらどうするか、ということを意識しました。また、サービスの内部で使っているAPIは、仕様を変更した時の影響範囲が把握できるため、変更が難しくありません。しかし、外部のAPIの場合には多数のユーザがそのAPIをすでに利用している可能性があるため、破壊的な変更をすることが困難になります。そのため、APIにどのような機能を持たせるかは非常に慎重に検討する必要があり、必要最低限の機能を備えるのが良いということを学びました。</p>
<h3>基盤（テスト）について</h3>
<p>基盤チームでは、主にテストの改善をしていて、技術的に学ぶことが非常に多かったです。<br>
テストにも何種類かあり、ユニットテスト、システムテスト、e2eテストなどがあります。僕は初め、e2eテストをたくさん作れば、コスパよく網羅的にシステムのテストができるとなんとなく思っていました。<br>
しかし実際には、e2eテストはもろく、不安定になりやすいもので、テスト対象のシステムのソースコードが同じでも、成功するときもあれば失敗するときもあるといったものでした。そのため、外部の環境になるべく依存しないテストを多く作り、e2eテストはシステムのコアな部分を守る必要最小限のものにするのが理想的であるということを学びました。</p>
<h1>プレイドへの新卒入社を決めた理由</h1>
<p>入社を決めた理由はいくつかありますが、プレイドの文化には特に良い印象を持ちました。<br>
例えばプレイドには「承認より謝罪」という文化があります。<br>
これは、「自分で考えてやるべきと思ったことは、誰かの承認を得なくても、とりあえずやってみて良い」というようなものです。他にも色々な文化があるのですが、多くの文化に共通する考えがあると思っています。それは、「なるべくポジティブに考えたり、人のポジティブな側面を信じる方が、トータルで得られるメリットが大きい」というような考えです。<br>
「承認より謝罪」の文化の話でいうと、承認を得るために余計なことを考える必要がなかったり、失敗したとしてもそこから得られる学びがあって、それと比較したら失敗することによるデメリットは（多くの場合は）小さい、といった考え方になると思います。<br>
実際にプレイドに来て、このような考え方がプラスだと実感できた場面はいくつもありました。APIチームでメンターから「遠回りしても良いよ」という風に言われて実践してみたときもそうでした。このような文化のある会社で働けることは、自分の人生にとってプラスだと思いました。<br>
正直、僕はプレイドから内定をいただいたときに、こんな優秀な人たちの中でやっていけるのだろうかと考えました。僕にはすぐに人と比較してしまったり、自信をなくしてしまったりしてしまう癖がありました。でも、最近はそんなこと考えても時間の無駄だなと思っています。優秀なメンバーと一緒に働けることは自分の成長に大きなプラスになりますし、たまに自信をなくすくらいがちょうど良いと考えています。<br>
入社してからは今以上に多くの困難があると思いますが、成長の機会と捉えて、前向きに働いていきたいと思います。</p>
<h1>最後に</h1>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://meet.plaid.co.jp/">弊社採用ページ</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>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/76095c7b-50a0-4ae7-af87-8b346f0d0c69/photo2.jpg" alt="photo2"></p>
