<p>こんにちは。エンジニアの@kei-tamiyaです。2018年4月に新卒で入社して8ヶ月ほど経ちましたが、エンジニアとして実際に何を学んだのか、入社する前に思っていたイメージは実際働いてみてどうだったのか、について振り返ってみたいと思います。<br>
　こちらの記事は<a href="https://qiita.com/advent-calendar/2018/plaid">PLAID Advent Calendar 2018</a> 4日目の記事でもあります。</p>
<h2>想定読者</h2>
<p>PLAIDの「人」や「考え方」に興味を持っている方<br>
PLAIDにはエンジニアとしてどんな成長機会があるか知りたい方</p>
<h2>入社前に抱いていたイメージ</h2>
<p>入社する前には累計2,3ヶ月ほどインターンをしていました。その間に、入社すると思考面と技術面に関して以下のようなことが経験できて得られそうだなと考えていました。</p>
<h3>思考面</h3>
<p><strong>(A) 物事の本質を捉える力を高められそう</strong></p>
<ul>
<li>常に目的に対して正しいと思う意見をぶつけ合う</li>
<li>間違っているものや考えはガンガン捨てる</li>
</ul>
<p><strong>(B) 自分が最高に楽しいと思える何かを見つけられそう</strong></p>
<ul>
<li>プロダクト愛と熱量を持っている人が多い</li>
<li>その環境でのめり込んで開発すると気づきがありそう</li>
</ul>
<h3>技術面</h3>
<p><strong>(C) 全般的な開発技術を習得できそう</strong></p>
<ul>
<li>フロントエンド・サーバーサイドで職種を分けていない</li>
</ul>
<p><strong>(D) サーバーサイドの開発力をしっかり高められそう</strong></p>
<ul>
<li>これまでフロントエンドの経験が多めだったのでサーバーサイドを強めたい</li>
<li>高トラフィックを前提にして、多種のDBを扱う経験ができそう</li>
<li>GCPをメインで使い倒していて、かなりのトラフィック・データ量がありそうなのも面白そう</li>
</ul>
<p><strong>(E) 早い段階で高難易度な経験を積めそう</strong></p>
<ul>
<li>KARTEが機能単位でプラガブルな（拡張性の高い）実装になっている</li>
<li>一人で丸ごと実装を担当できそう</li>
</ul>
<p>これらそれぞれが実際にはどうだったのかを振り返ってみます。</p>
<h2>実際にはどうだったのか</h2>
<h3>思考面</h3>
<p><strong>(A) 物事の本質を捉える力を高められそう</strong></p>
<p>実際にこの考え方を感じる場面・実践する場面は非常に多いです。「これってなんでやってるんだっけ？」「そもそも何を解決したいんだっけ？」という問いに立ち返り、元来の目的を再認識した上で現状で取りうるより良い方針に修正をし、トライするといった改善を行えるのは非常に建設的で面白い環境だなと思います。</p>
<p>そもそも私は人の感情を考えてなるべく不快な気持ちにさせないように発言・行動することを大切に生きているので、言葉を意識しすぎて逆にわかりにくくなったり、わざわざ議論しなくてもいいかと問題解決から遠のいてしまうことが多い人間だったのですが、「ああ、ここまではっきり言っていいんだ」と気付かされたのは大きな驚きでした。</p>
<p>「自分たちが解決したいことは目の前の課題および長期的な目標であり、それは達成すべき非常に重要なものである」という前提に立って考えると、事実ベースで課題の本質を認識して発言・共有することでチームとして向き合って解決していくことが重要で、目先の考えすぎな気遣いや感情等は不要なものである場面がほとんどなのだと認識できたのは思っていた以上に自分が成長できたことだなと感じています。</p>
<p><strong>(B) 自分が最高に楽しいと思える何かを見つけられそう</strong></p>
<p>私はそもそも何か特別にやりたいことがある人間ではありませんが、最高にのめり込めることを見つけることが目下の人生の目標だったりします。弊社のメンバーは前職までの経験でWeb上のユーザー体験に対して疑問や課題を感じたために、KARTEの「多様なデータをひとりの人として理解し、一人ひとりに合わせた体験づくりをする」という世界観に共感しているメンバーが多く、そのモチベーションを間近で感じて自分の探したい「何か」の参考にしたいなという思いがありました。</p>
<p>最近では月に1度エンジニア全体で、長期的な未来にKARTEを通して成し遂げたい理想像を全員でディスカッションするような場を設けています。普段の開発で精一杯になって視野が狭くなっていましたが、一歩引いて開発している意義を理解することによって、以前よりも主体的な立場で将来を見据えて開発に取り組めるようになりつつあると感じています。<br>
　<br>
自分の中でまだ「何か」は見つかってはいませんが、何かを成し遂げていくということは「圧倒的な熱量」と「覚悟」が必要なんだなと学んでいます。</p>
<h3>技術面</h3>
<p><strong>(C) 全般的な開発技術を習得できそう</strong></p>
<p>経験できています。役割を完全に分離して開発する形態は、どこか一部門の開発が遅れることでボトルネックになった場合に開発全体が滞ってしまったり、効率が悪くなってしまうような状態が好きではなかったので、機能ごとにIssueを切ってプロジェクトの進行状況やチームの状況次第で誰がどのIssueを担当してもある程度開発できる点はストレスフリーで良いです。</p>
<p>しかしながらまだまだ自分の開発速度も遅く、機能単位で担当する分、大きな機能を丸ごと実装する際はかなり時間がかかってしまって自分がチームのボトルネックになってしまうケースは多いです。この点は課題ですが、割と重要な機能であっても、実力がある程度伴っている場合においては自分で手を挙げれば任せてもらえるので、もっとできることを増やしていこうというモチベーションは高まります。</p>
<p><strong>(D) サーバーサイドの開発力をしっかり高められそう</strong></p>
<p>これも経験できています。学生の頃はフロントエンドの開発をメインで行っていましたが、先述したように幅広く開発技術を習得したい思いもあり、大規模トラフィックを考慮したDBの設計・運用ができて、開発速度の速い環境が良いなと考えていました。実際に規模の大きい配信機能の修正を担当する機会もあり、使われている諸々のDBの仕様を色々調べてキャッチアップし、コードを順に追いつつ理解して実装することで少しずつ実装力が上がってきていると感じています。<br>
　<br>
今年特に多く触れた機能の例としては、Node.jsからのBigQueryやSpannerの操作、QueueとしてのMongoDB, Spanner, Redis, Cloud Pub/Subの活用、Redisを用いた重複配信の制御などの実装・修正・レビューを行い、課題の解決手段の幅が非常に広がりました。</p>
<p><strong>(E) 早い段階で高難易度な経験を積めそう</strong></p>
<p>開発要件が多い新規の機能を少人数のチームで実装していたこともあり、大きな機能単位で担当する機会は早い段階で得られました。方針が定まっていない状態で大きめの機能を担当した際は、必要要件は何があるのかを誰に聞いて、どの粒度でIssueを分割してどの順で開発を進めれば良いのかがわからず相当な時間がかかってしまいました。技術力が至らなかったのはもちろんですが、どちらかというと仕事の進め方・コミュニケーションの取り方の点で圧倒的に力不足を感じて悔しかったので、「エンジニアリング組織論への招待」を読むなどして自分の何が問題だったのかについて冷静に理解して、不確実性と向き合う日々を絶賛送っています。</p>
<h2>学んだこと</h2>
<p>ここまでの内容を一度まとめると、以下のことを学び、徐々にできるようになってきているなと実感しています。</p>
<ul>
<li>目的を達成するために、不要な感情を切り離して、本質的な課題に対して向き合うこと</li>
<li>適切なコミュニケーションによって課題を理解し、解決可能な単位に分割すること</li>
<li>目の前の課題と長期的な課題を適切に捉えることで、主体的に開発に参加すること</li>
<li>Node.js, Vue.js, 各種DB（MongoDB, Redis, BigQuery/BigTable/Spanner等のGCP周り）を用いた開発力の向上
<ul>
<li>大規模トラフィックを考慮した実装</li>
<li>実装力（適切な実装方法を考える力、コーディング速度や可読性）</li>
<li>知らない技術を使用する際のキャッチアップ力</li>
</ul>
</li>
</ul>
<p>思考に関しては、入社前に体験できそうだと思っていたことを実践し自分なりの解釈をすることで新たな発見と学びを獲得し、技術に関しては新たな「学び」というよりは着々とできることが広がっている感覚です。</p>
<h2>逆に自然には学べていないこと</h2>
<p>もともと得たかったものは意識して取り組んでいることでもあり、ある程度身につくのは当然なので、逆にあまり伸びていない能力や課題感についても触れておきます。</p>
<ul>
<li>フルスクラッチでの開発力・企画力</li>
<li>厳密なスケジュールや方針を立てる力・厳格なテストを書く力</li>
<li>確実に予定通りに達成していく力</li>
</ul>
<p>現状での開発は基本的にKARTEの開発がメインで、新規事業としては<a href="https://karte.io/product/app/">KARTE for App</a> や<a href="https://karte.io/product/datahub/">KARTE Datahub</a>などの規模感の大きい機能を実装する形式なので、新規プロダクトを完全にゼロから開発する機会はまだ経験していません。現状で稼働している環境との親和性を考えてアーキテクチャを考える機会は多いですが、フルスクラッチでアーキテクチャ・フレームワーク等を考えて実装したり、ビジネスプランそのものを考えるなどの機会は少ないです。</p>
<p>また、スピード感をかなり重視し、今書いているコードは全て壊すぐらいのつもりで書く文化なので、全体の完全な設計や綿密なスケジュールを立てたり、仕様書通りに実装をするといったスキルは身についていません。テストに関しても、サーバーサイドのユニットテストがメインでコア部分をしっかり守る程度で、厳格に取り組んだ対象とは言えないです。</p>
<p>綿密な計画を立てないのは、より良い方針が浮かぶことでの仕様変更があったり、差し込みがあることを前提としていたり、「その場しのぎの実装」ではなく「少し時間をかけても根本的解決・より良い状態となる実装」を選ぶ傾向があるため、決められた時間内にある一定量のタスクを確実にこなしていくようなスキルは意識しないと高まらないと感じています。社内の開発スピードは非常に早いので、現状では成長余地を見込んで任せてもらえる内容も、「より良いものを作るためならどれだけ時間をかけてもいいんだ」といった勘違いをしてズルズルと長引かせていては自分がボトルネックになってしまいます。</p>
<p>そのため、意識的にミニマム機能を実装する期限を設定したり、この時間内にこれだけの機能を実装し終える、といった目標設定を都度しながら開発する必要性を感じています。</p>
<h2>まとめ</h2>
<p>本記事では、PLAIDの新卒エンジニアとして8ヶ月働いたことで私が学んだことを、入社前に抱いていたイメージと実際に感じたこととを比較することで考察しました。<br>
特に、課題への向き合い方や適切なコミュニケーションの重要性についての思考の変化と、KARTEの開発を通して経験できた技術/あまり自然には学べてはいない能力の一例を紹介しました。</p>
<p>なお、この記事の内容は完全に私の主観によるものですが、チーム環境や開発時の状況によって得られる経験も違うため、あくまでも1人のエンジニアの体験記として捉えていただけますと幸いです。</p>
<h2>最後に</h2>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するPLAIDでは、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に入社して何を学んだのか、入社する前に思っていたイメージは実際働いてみてどうだったのか、について振り返りました。

新卒エンジニアから見たPLAID、そこで得られた経験と学び | PLAID engineer blog

新卒エンジニアから見たPLAID、そこで得られた経験と学び

<html><head></head><body><p>はじめまして、エンジニアの nito です。PLAID Advent Calendar 2018 の三日目の記事でもあります。</p>
<p>最近は KARTE の開発者向けのプラットフォーム開発を主戦場に、API の仕様策定や開発者向けの管理画面の実装、ドキュメンテーションなどを担当しています。</p>
<p>今回は <a href="https://support2.karte.io/update/2018/12/12347/" target="_blank" rel="noreferrer">12/3 にリリースした KARTE の開発者向けプラットフォーム「Developer Portal」</a> の開発をおこなううえで、大切にしていた <strong>Developer Experience (DX)</strong> という考え方をご紹介します。</p>
<h1 id="KARTE Developer Portal とは?">KARTE Developer Portal とは?</h1>
<p><a href="https://developers.karte.io" target="_blank" rel="noreferrer">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 id="Developer Experience とは?">Developer Experience とは?</h1>
<p>DX は、2011年に UX Magazine で投稿された <a href="http://uxmag.com/articles/effective-developer-experience" target="_blank" rel="noreferrer">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" target="_blank" rel="noreferrer">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 id="KARTE Developer Portal で実際に注意したこと">KARTE Developer Portal で実際に注意したこと</h1>
<p>この考え方は、タイトルにもあるように、KARTE Developer Portal を開発する上で非常に大事にしています。<br>
ここからは、実際に DX を意識したところ、ここでは、とくにドキュメンテーションに関して気をつけたところを、いくつか紹介していきます。</p>
<h2 id="実際のユースケースに合わせたガイド">実際のユースケースに合わせたガイド</h2>
<p>KARTE Developer Portal のドキュメントでは、KARTE が提供している API やフロントエンドから利用できる JavaScript モジュールなどの仕様をリファレンスとして網羅しています。しかし、(開発者の方なら経験があるかと思いますが、) リファレンスだけで、すべてを理解するのはかなり厳しいと思われます。</p>
<p>そのため、リファレンスで記載されている各API や関数の使い方としてガイドを提供しています。ガイドは、どのような目的で、どのように使うのかを例 (サンプルコード) を交えて紹介しているので、開発者が迅速に開発に取り掛かることができます。</p>
<p>たとえば、以下は [ガイド] &gt; [基本的な使い方] の「チャットボット連携」に関するドキュメントのタイトルですが、目的から記事にたどり着けるようにタイトルをユースケースを表すようにしています。また記事ごとに目的をもったシナリオと捉えて、動詞をタイトルにしているのも工夫のひとつです。</p>
<pre><code class="language-plaintext hljs">チャットボットと繋げる
├── チャットボット連携のセットアップ
├── ユーザーにメッセージを送信する
├── ユーザーのメッセージを受け取る
├── ユーザーの担当者を変更する
└── ユーザーの担当者変更情報を受け取る

</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 id="コンセプトを最小限で理解するためのチュートリアル">コンセプトを最小限で理解するためのチュートリアル</h2>
<p>また、そもそもプラットフォーム上で開発する場合、そのプラットフォームがどのようなプロダクトで、どのようなコンセプトを持ったプロダクトであるかを理解することも非常に重要になります。そこで、[クイックスタート] というチュートリアルを設けて、KARTE の最小限の基本的な機能をさらいながら、そのコンセプトを理解できるコンテンツも提供しています。</p>
<h1 id="おわりに">おわりに</h1>
<p>本記事では、Developer Experience という考え方を紹介しました。KARTE Developer Portal では、DX をもとに、紹介したドキュメントをはじめ、API 設計などにも適用しており、開発者、ひいては KARTE ユーザーに良い体験を提供することを目指しています。</p>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/" target="_blank" rel="noreferrer">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html" 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
<p>_IgY4VF5ukBo_EUKZLg&quot; data-width=&quot;300&quot; data-height=&quot;60&quot;></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="">
</div></body></html>

開発者向けプラットフォームを開発するうえで大切にした「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>


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