おはようございます！プレイドのエンジニアの <a href="https://twitter.com/jumpei_ikegami">@jumpei_ikegami</a> です。 
趣味はポッドキャスト配信です。
さて、プレイドでは定期的に、開発チームで合宿に行っています。
(過去の開発合宿のブログ記事は下記）
<a href="http://blog-plaid.com/event/2772/">2016年:秋</a>
<a href="/plaid-developpers-camp-2017-spring/">2017年:春</a>
今回は、開発フォーカスの区切りということで、前フォーカスの振り返り、4月以降の新チーム体制でのフォーカス、プロダクトの見せ方などについて、議論を深めてきました。
開発をしない開発合宿も珍しいと思いますが、目の前の開発業務を離れて、長期的な視野で開発の仕方や、何をするべきかを見つめ直すことで、本当にやるべき仕事にフォーカスできるようになります。
特に、<a href="/software-development-not-start-from-shu/">先日のエンジニアブログ記事</a>で弊社kadoppeが書いていた、「『常にゼロベースで考えて進む』プレイドの文化」が、議論の中にも表れていました。
そんな開発チーム合宿の様子を、写真多めでお送りします。
<h1>五反田発、館山行き貸切バス</h1>
館山の合宿先までは、オフィスのある五反田から貸切バスで移動しました。
バスの写真は、私が寝ぼけていたのでありません。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/5e8fb80a-ae61-455a-af07-e722a3f393cd/010-2.jpg" alt=""> 
（途中のサービスエリアで食べた、「つみれ汁:¥200」と、「ふきのとうの天ぷら:¥50」）
お酒が無いのが不思議です。
車内では、遠足気分を高めるための駄菓子の配給がありました。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/1a37dd1e-d700-42ad-b9c1-bef6a1f0573b/020-2.jpg" alt=""> 
(宿に着いてから「ソースせんべい」を食べる、ぐろっちさん)
<h1>海の見える宿</h1>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/cf8baae9-a779-4953-9634-11eb1c205532/030-1.jpg" alt="">
今回は、千葉県館山市、房総半島の南の端にある「<a href="https://tateyama-retreat.jp/">館山リトリート</a>」という宿にお世話になりました。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/68720b41-1492-4546-8ba8-e91932fae1d7/040-2.jpg" alt="">
議論に使った大広間からも、海が見えました。
考えに詰まったら大海原をみながら頭を整理することができました。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/22d452a0-ffb7-47b8-85c4-9132b17c34a1/043-1.jpg" alt="">
食事は自分たちで準備するスタイルで、広々としたキッチンを自由に使えます。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/cc1ae859-d3bd-40e0-b4c3-49cd063ec2ee/045.jpg" alt="">
<h1>ゼロベースで議論！議論！議論！</h1>
合宿のコンテンツは、ひたすら議論を重ねるものでした。
主な内容は4つありました。
<h2>未来のユーザーに、KARTEをどのように見せる？</h2>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/23b7183b-23a9-4614-a915-7627c592c3a8/050.jpg" alt="">
「<a href="https://karte.io/">KARTE</a>のキャッチコピーを考える」という題材を通して、未来のKARTEユーザーにどんなメッセージを伝えたいかを考えました。
出た意見をいくつか挙げます。
<ul>
<li>KARTEを単なるツールとしてではなく、プラットフォームとして見せていくべき</li>
<li>要望への「最適化」では足りない。それを知った上で、どう期待を超えていくか？</li>
<li>クライアント企業の指標を上げるだけではなく、その先のエンドユーザーを幸せにすることを含めて見せ方を考えたい。是即ち「愛」</li>
</ul>
開発チームの仕事は、ただプロダクトを作って終わりではありません。 
自分たちが作っているプロダクトがどのようにユーザーに届けられるのか、という点についても関心が高いのが、プレイドの開発チームのよいところだと感じました。
<h2>チーム間の連携、どうすればうまくいく？</h2>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3640d85d-416a-4dc6-a5cd-d9d31267dfdb/060.jpg" alt="">
これまで、開発内の別チームや、ビジネス側のチームとの連携などがうまくいかなかったことで、手戻りが発生したり、ユーザーへのデリバリー方法に問題が生じたりしました。
そこで、「チーム間連携」というテーマで、理想・課題・解決策を挙げるために議論しました。
出た意見をいくつか挙げます。
<ul>
<li>理想は、「スタンドプレーから生じるチームワーク」</li>
<li>チームを固定化せずに、ビジネスメンバーも巻き込んで流動的に変えていく</li>
<li>生産性を優先すると、社内で情報格差が生じてカオスになる。それをある程度許容すべき。ルールを作るのではなく、そういうカオスな状況でもパフォーマンスを出せるメンバーを増やしていく方が建設的</li>
</ul>
「チーム間連携」という話だと、「定例ミーティングしよう！」というような安易な話になりがちです。 
それを超えて、さらに深い議論に発展していたのが、印象的でした。
プレイドには「常にゼロベースで考える」以外にも、「ルールをなるべく作らない」という文化があります。今回の議論も、ルールではなく、マインドやチームのあり方の話で課題を解決しようとするところに、「らしさ」が出ていました。
<h2>コーヒーブレイク</h2>
休憩時間では、コーヒー好きが集まるプレイドらしく、コーヒーミルを持ち込んで、コーヒーを飲むメンバーもいました。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/705d5c03-7111-4b1e-bece-7e74b01ea541/070.jpg" alt=""> 
(ハッピーターン」を取りに来た、デザイナーのミギーさん)
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/2b9eb2ad-e8c2-46db-8418-ecf2ef85ff3e/080.jpg" alt=""> 
(カメラを向けると、わざとらしい笑顔を向けてくる、ぐろっちさんと、ノブくん)
全く外に出る時間はありませんでしたが、昼間の天気も最高でした！ 
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/08c6cf6d-e1c3-45bd-9261-d249b0b55700/090.jpg" alt="">
<h2>新しいチームでのミッションどうしよう？</h2>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/320f652e-821e-49ba-a0f5-cf3a5ad302bd/100.jpg" alt="">
4月から開発チームの再編があり、最初の3ヶ月で行うミッションの言語化、状態目標の設定、注力issueの洗い出し、などを行いました。
PLAIDには固定的な「部署」という概念はなく、定期的にチーム構成が再編されます。 
それによって、ナレッジが蛸壺化しにくくなったり、個人が色々な役割を担えるようになります。
開発チームも同様で、機能の多いKARTEの中でも、定期的に自分が開発を担当する機能が変わっていきます。
この議論では、前のチームでのやり方に捉われず、そもそもどんな課題を解決するべきか？を「ゼロベース」で考えていきました。
私はBizDevチームというビジネスサイドのチームに属しているのですが、「開発チームが作った機能のデリバリーに関して課題があり、その整備に注力していこう」という目線合わせができてよかったです。
<h2>前フォーカスどうだった？</h2>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9b6f792f-35a1-426e-8286-857fc92ad9fd/110.jpg" alt=""> 
(CTOが買って飲まなかった「プロテインドリンク」をみんなで勝手に飲んでいる図)
最後に前回のフォーカスについて、その進め方のKeepとProblemをみんなで挙げていきました。
出た意見をいくつか挙げます。
<ul>
<li>Keep
<ul>
<li>作り始めたものを一回壊して、ゼロから作り直すことで、本当に良いものができた</li>
<li>「既存機能の改善」を束ねて大きくリリースしたのは、ただ新機能を出すより難しいことができた</li>
<li>チームが自律的にパラレルで動けるようになった</li>
<li>1人でやるよりもチームでやることで、より良いものができた実感がある</li>
</ul>
</li>
<li>Problem
<ul>
<li>差し込みタスクでスイッチングコストがかかった</li>
<li>もっと細かい粒度でリリースして、反応を見ながら開発しても良かった</li>
<li>チームの壁が厚く似たようなものを別で作ってしまったので、もっと流動的に人の入れ替えがあると良かった</li>
<li>不安定なテストがあるなど、フォーカス外のissueが放置されがちで、負債が溜まってしまった</li>
</ul>
</li>
</ul>
この議論についても、結果として、「新しいルール作ろう！」ではなく、「次に同じ状況になったらもっとうまくできる！」という実感の共有をできたのが、良かったと思いました。
次に似たような課題に直面するときも、チームメンバーやプロダクトの状況はそのときとは違うかもしれません。 
無批判にルールを当てはめるのではなく、その都度「全力で考える」という前提を置いた上で、その考えるための材料を、この議論で洗い出せたと思います。
<h1>うまい魚に、うまい酒</h1>
議論の合間の食事も、みんなで楽しみました。
1日目の夜は、豪勢に鯛のあら汁と寿司でした。 
寿司には、「ストロング・ゼロ」がよく合います。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f7e8c85f-a71a-414b-a8c0-7e9d1ce06a31/120.jpg" alt="">
一日中議論をしても、飲み会の話題は尽きません。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9b190878-dacf-49c9-9f36-5eb0c99582f3/130-1.jpg" alt="">
期待のルーキー、カンテの悪酔いに、先輩藤川くんも苦笑い。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/18de3482-98db-424d-bf9b-2ba505576086/135.jpg" alt="">
2日目の朝から、余った寿司を食べました。箸がなかったので、まさかのスプーンです。 
寿司は昼まで余ったので、夢の「3食お寿司のすしざんまい生活」が実現しました。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/58f58376-5fc2-46c8-8f64-56aa9dc73d8b/140-1.jpg" alt="">
2日目の昼は、なんと海鮮鍋でした。 
このシズル感。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/73a2f0aa-8395-4c20-92f9-27e8b27fa2c5/150-1.jpg" alt="">
鍋にすると、こうなります。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/5a4dbb25-68cc-4721-a775-77225a2a81d2/160.jpg" alt="">
<h1>アクアラインを通って五反田へ</h1>
2日間の日程も、あっという間に過ぎました。
帰りも、バスでアクアラインを通って東京に帰りました。
この日は強風が吹いていて、途中の「<a href="https://www.umihotaru.com/">海ほたる</a>」では階段を登っている途中で吹き飛ばされるかと思いました。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/2a1f54dd-515d-4c6e-b694-2eede764e709/170.jpg" alt="">
バスでは、一部のメンバーが余った「ストロング・ゼロ」で宴会をしていました。私も2本目を空けるまでは記憶がありました。
思えば、この合宿で何本の「ストロング・ゼロ」を飲んだのだろう。プレイドの文化は、「常にゼロベースで考える」こと。昼に「ゼロベース」の議論を重ねて、夜に「ストロング・ゼロ」を飲み明かす。これが本当の......「ストロング・ゼロ・ベース思考」？？
......ふと、目を開くと、そこはいつもの五反田の街でした。
ということで、合宿で持ち帰ったアイデアを、ここ五反田のオフィスから実現していきます！
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/5cd766d1-f9ac-4d98-ab5f-f0654af798c3/180.jpg" alt="">
<h4>最後に</h4>
ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニアやインターンを募集しています。 
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a> 
または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a> 
をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！
<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>

開発チームで、千葉県館山市に合宿に行って来ました！開発の節目ということで、KARTEをどう見せていくか、何にフォーカスすべきかなど、1泊2日に�

1泊2日ぶっ通しで議論する開発合宿をしに、館山に行ってきました！ | PLAID engineer blog

1泊2日ゼロベースで議論する開発合宿@館山に行ってきました！

<html><head></head><body>こんにちは、はじめまして。プレイドの @kadoppe です。
2017年4月に入社したエンジニアです。この記事を書いている時点のプレイド歴は11ヶ月です。
この記事では、自分が個人的に最近大事だと考えている『「型を守る」ことから始めないソフトウェア開発」』というトピックについて書いてみようと思います。
技術成分が少なめの内容ですが、こういうことを考えているエンジニアもいるんだよ、ということで興味がある方はご覧ください。
<h1 id="５行まとめ">５行まとめ</h1>
少し長いので5行で内容をまとめます。
<ul>
<li>「守破離」というソフトウェア開発の技術・方法論を効果的に学ぶための考え方がある。</li>
<li>「型を守る」ことから始めるソフトウェア開発は、問題を解決する上で最適・最速ではない可能性がある。</li>
<li>「型を守る」「型を破る」「型を離れる」のどこから始めるべきか、問題の内容や、プロダクト・チームの状態を考慮した上で決めるべき（最初から型破りでいい＝型を守ることから始めないソフトウェア開発）</li>
<li>「常にゼロベースで考えて進む」プレイドの文化において、型を守ることから始めないソフトウェア開発は進めやすい、というか自然とそう考えさせられる力学が働いている。</li>
<li>僕にとっての「プレイドの良いところ・好きなところ」はそういうところ。</li>
</ul>
<h1 id="守・破・離 〜 shu ha ri 〜">守・破・離 〜 shu ha ri 〜</h1>
唐突ですが、みなさん「守破離」について知ってますか？
「守破離」とは、ソフトウェア開発の技術・方法論を効果的に学ぶための考え方の一つです。本来は日本の合気道に由来する、武術を学ぶ際の考え方ですが、日本に止まらず世界的に使われています。
この考え方の中では、人が技術や知識を得るまでには、「守（型を守る）」「破（型を破る）」「離（型から離れる）」の３つの段階を経るとされています。
<blockquote>
守：最初の段階では、学習者は師の教えを正確に模写する。理論についてあれこれ考えずに、その作法に集中する。作法が複数ある場合でも、師の教えをただ忠実に守る。
破：この段階では、学習者は新しいことに手を出す。基本的な実践を身に着けたなら、技術の裏にある原則や理論を学んでいく。また、他の師からも学び、得たものを自身の実践に採り入れていく。
離：この段階では、学習者は、自身の実践を通じて、他者から学んでいく。自身の手法を生み出し、学んだことを自身の環境に適応させていく。
</blockquote>
引用元: <a href="http://bliki-ja.github.io/ShuHaRi/" target="_blank" rel="noreferrer">守破離</a>
この３つの段階に従うことで、効果的に技術や方法論を身に付けることができ、最終的には分野でイノベーションを起こすことができるようになる、という考え方です。
非常にわかりやすいので、個人的にはとても好きです。前職でもこの考え方は凄く大事にした上で、新しいやり方や方法論などをチームに取り入れたりしていました。
<h1 id="ソフトウェア開発における型">ソフトウェア開発における型</h1>
では、ソフトウェア開発における型とは何でしょうか。
ソフトウェア開発を進めていく中で、プロダクトやチーム、エンジニアは、日々様々な種類の幅広い問題に直面します。
世の中にはそういった問題に対する解決策が、事例やフレームワーク、あるいは開発プロセスとして、書籍やWeb上の記事といった形で、広く一般に公開されています。
例えば、以下のようなものが例として挙げられます。
<ul>
<li>アジャイル開発手法やウォーターフォールモデルといった開発手法</li>
<li>スクラムのようなフレームワーク</li>
<li><a href="https://www.amazon.co.jp/dp/B00G9QJ1ZO/" target="_blank" rel="noreferrer">組織パターン</a>のような書籍にまとめられているパターンランゲージ</li>
<li><a href="https://12factor.net/ja/" target="_blank" rel="noreferrer">The Twelve-Factor App</a> のような方法論</li>
<li>ブログの記事に記載されている小さな tips</li>
<li>etc.</li>
</ul>
大きさや粒度は違えど、これらは全て、ソフトウェア開発において発生した何らかの問題に対する解決策です。このような解決策が「ソフトウェア開発における型」だと考えます。
<h1 id="「型を守る」ことから始めることをあえて批判的に捉える">「型を守る」ことから始めることをあえて批判的に捉える</h1>
突然何を言っているんだという感じではありますが、プレイドという新しい環境にジョインしてから、プレイドの文化や雰囲気に触れて、今までの自分の仕事のやり方や考え方を見つめ直す機会があったので、色々考えたのです。
上に紹介した「守・破・離」という考え方では、「守」から始めることが「良し」とされていると捉えることができます。しかし、「型を守る」ことから始めることが常に正しいとはいえないと思います。
ここでは、こじつけかもしれませんが、型を守ることから始めることを、あえて批判的に捉えてみます。
<h2 id="思考停止では？">思考停止では？</h2>
「型を守る」＝「理論についてあれこれ考えずに、その作法に集中する。」で本当にいいんでしょうか。その理論は自分たちが抱えている問題に対して本当に正しく、適切なものなのでしょうか。
そもそも正しい理論を教えてくれる「師」なんて存在するのでしょうか？そもそも正しい理論なんて存在するのでしょうか？
一般的な解決策を信じきって、自分たちが直面している個別の問題に適用してしまってもいいのでしょうか。
<h2 id="問題に対してその解決策は最適解か？">問題に対してその解決策は最適解か？</h2>
同じように見える問題でも、その問題が発生した環境や背景、プロダクトやチームが違えば、本質的には違う問題です。
問題が違えばそれに最適な解決策も異なるはず。なので、そこから生まれる結果も最適なものではない可能性があります。
その前提の上で、「作法が複数ある場合でも、師の教えをただ忠実に守る。」のは本当に正しいアプローチなんでしょうか。
問題が少しは改善するかもしれません。でも、実はそれは局所最適解で、本当の最適解には気づけないまま、時間が過ぎていってしまうかもしれません。
最初から、自分たちの直面した問題に対して、ゼロベースでフルカスタマイズされた解決策を適用する。そのために問題をしっかり認識・分析することが、問題を最適に近い形で解決するための近道なのではないでしょうか。
<h2 id="時間がかかりすぎないか？">時間がかかりすぎないか？</h2>
「守」から始めたとして、では「破」「離」にたどり着くまでにはどのくらいの時間がかかるのでしょうか。
例えば「スクラム」の例を挙げてみると、とあるスクラムコーチ曰く、スクラムをはじめたばかりのチームが「守」のフェーズが終わるまでに短くても「3ヶ月くらいかかる」とのことでした。
でも、自分たちにその時間的余裕はあるのでしょうか。ユーザーや市場は待ってくれるのでしょうか。「破」や「離」にたどり着く頃には会社はプロダクトはどうなっているのでしょうか。
最初はとりあえず始めてみて、そこで得られたフィードバックをもとに、あとで調整しながら最適に持っていく方法もあります。
問題を解決するまでにフィードバックループは何度か回すことになると思いますが、「守」から始めることで、少なくとも一回は余分に多くフィードバックループを回すことになってしまいます。
その1回を許容できる時間的余裕が、自分たちにはあるんでしょうか。
<h1 id="「型を守る」ことから始めないソフトウェア開発">「型を守る」ことから始めないソフトウェア開発</h1>
ここまでで、言いたかったのは『「型を守る」ことから始めるソフトウェア開発は、問題を解決する上で最適・最速ではない可能性がある』ということです。「型を守る」ことから始めることが正しいときもありますが、必ずしもそうとは限りません。
大切なのは以下の2点だと思います。
<ul>
<li>自分たちが直面している問題を、自分たち固有のものだと捉えて、問題についてしっかり認識した上で正しく理解すること。</li>
<li>問題に直面しているプロダクトやチーム、個人の状態（問題に対する習熟度、背景、環境など）を正しく理解すること。</li>
</ul>
その上で、
<ul>
<li>世の中に一般的に公開されている解決策をまずはそのまま適用してみるのか（＝型を守る）</li>
<li>それを参考に少しカスタマイズした上で試してみるのか（＝型を破る）</li>
<li>ゼロからフルスクラッチで自分たちだけの解決策を考えて適用してみるのか（＝型を離れる）、</li>
</ul>
その時々に応じて最適だと考えられる選択肢を取ることが重要だと考えています。
これが『「型を守る」ことから始めないソフトウェア開発』です。最初から型破りでもいいんです。
これが自分たちが最適かつ最速に問題解決に近づくためのアプローチだと思いますし、個人的には凄く重要なポイントだと考えています。
<h1 id="え、そんなの当たり前のことでしょ？">え、そんなの当たり前のことでしょ？</h1>
ここまで書いた内容を眺めてみると「当たり前のこと / 誰でも気付いていること」を書いてるいるなぁと思いますし、ここまで読んでいただいている方も同じ感想をお持ちかと思います。
ですが、僕の経験上、
<ul>
<li>ついつい思考停止した上で「型を守る」ことから始めてしまう</li>
<li>問題をしっかり認識・理解することよりも、先に解決策ありきで物事を進めようとしてしまう</li>
</ul>
といった罠が、ソフトウェア開発に日々取り組む中で、いろんな場所に仕掛けられているような気がしています。「型を守る」ことに引っ張られる、そういう力学や雰囲気が自然と当たり前のように存在しているような。
「型を守る」ことから始めることや、解決策ありきで物事を進める方が、圧倒的に楽です。考えることの量がとても少ないです。一般的な解決策の方が、ゼロベースでフルカスタマイズした解決策よりも、周りの人が理解しやすかったりします。
人間は弱いものなので、気を抜くと、どうしても楽な方に引っ張られてしまいます。
だからこそ、楽ではないが、本質的なアプローチが取ることは難しいことだと思いますし、それがやりやすい環境がもしあるとするならば、それ自体凄く価値のあることだと思います。
<h1 id="「常にゼロベースで考えて進む」">「常にゼロベースで考えて進む」</h1>
プレイドのコーポレートサイトに、エンジニアリングチームの文化について書かれているページがあり、そこには以下のような記述があります。
<blockquote>
カオスと問題を楽しむ 
フレームややり方は決めずに、常にゼロベースで考えて進むのが重要であり何より面白い作業だと考えています。
</blockquote>
このように、プレイドには「フレームややり方は決めずに、常にゼロベースで考えて進む」ことを良しとする文化があります。
僕がすごく共感していて、実際にプレイドで仕事をする上で「良い」と感じているのが、この「常にゼロベースで考えて進む」という考え方・スタンスです。プレイドには多様なメンバーが所属していますが、ベースとしてこの考え方が根付いているように感じます。
そして、これによって『「型を守る」ことから始めないソフトウェア開発』がとてもやりやすくなっているように思います。意識しなくても気づいたら、そういう方向に思考が向いているというか、自然とそうなっているというか。
型（フレームややり方）を最初から作らずに、まずは問題をしっかり認識・理解した上で、自分たちにとって最適なやり方を作っていく。自然とそういう思考になるような、力学や雰囲気がプレイドには存在しています。
仮にそういう力学や雰囲気がないと、ついつい「フレームややり方」ありきで問題を解決しにいってしまうのではないでしょうか。
<h1 id="大変だけど、楽しいし、価値があること">大変だけど、楽しいし、価値があること</h1>
ゼロベースで考えることはとても大変ことです。自分たちのプロダクトやチーム、個人のことを真剣に見つめ直す必要があります。辛くなる時ももしかしたらあるかもしれません。
ゼロベースで考えたことで、スピードがもの凄く遅くなっていては元も子もありません。フルスクラッチで解決策を考えるとはいえ、時間をかけすぎてはいけない、そういったプレッシャーの中で物事を考える必要があります。
それでも、その思考のプロセスが楽しいのです。これまでたくさんは使ってこなかった脳の部分をたくさん使う感じがします。
それが自分自身を成長させますし、何より、プロダクトやチームが抱えている問題を本質的に解決するための近道であり、さらには長期的なプロダクトの成長やユーザーへの価値向上に繋がると信じています。
それができる環境で僕は今働いていて、こうやって言葉を並べるだけではなく、自分の仕事をどんどん価値に繋げていきたいと、日々取り組んでいます。
<h1 id="おわりに">おわりに</h1>
最近、「プレイドで働く上で楽しいこと、良かったことはなんですか？」と社外の人に質問される機会が何度かあったのですが、毎回上に書いたようなことを答えています。
具体的なエピソードを書いていないですが、それはまた別の機会に紹介できればと思います。
なお、この記事の内容は、あくまでも、僕個人の考え、僕個人から見たプレイドについての考えです。
プレイドのエンジニアチームは、幅広いスキル・バックグラウンド・ビジョンを持った多様なエンジニアで構成されており、なので、全然違うことを考えているエンジニアもいます。
この記事では、こういうことを考えているエンジニアもいますよ、という一例を紹介しました。
<hr>
ウェブ接客プラットフォーム「<a href="https://karte.io/" target="_blank" rel="noreferrer">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。
詳しくは<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> 
をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！
<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>

最初から「型破り」でもいいんです。「型を守る」ことから始めないソフトウェア開発、という考え方について紹介します。

「型を守る」ことから始めないソフトウェア開発 ー 常にゼロベースで考える | PLAID engineer blog

「型を守る」ことから始めないソフトウェア開発 ー 常にゼロベースで考える

みなさん、ごきげんよう。プレイドの@tik-sonです。
現在、PLAIDエンジニア陣で<a href="https://codezine.jp/article/corner/711">CodeZineで連載</a>をしているのですが、 
今回は<a href="https://codezine.jp/article/detail/10674">KARTEを支える監視構成についての記事を書きました。</a>
記事のリード文で紹介しているように、シビアな要件が求められる、大規模解析サービスの監視のポイントや、構成などを書いているので、是非とも御覧ください！
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/0c95bcdc-12bd-491a-baff-7aa28c0af6ed/image--2--2.png" alt="image"> 
<a href="https://codezine.jp/article/detail/10674">大規模解析サービスを支える監視サービスと監視構成のポイント</a>

12.5億UUを解析するKARTEを支える監視構成について記事を書きました。

「型を守る」ことから始めないソフトウェア開発 ー 常にゼロベースで考える

「型を守る」ことから始めないソフトウェア開発ー常にゼロベースで考える