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>

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

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

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