「PHP の現場 14」

PHPの現場 14. データベースにかける（soudai1025）
（ https://php-genba.shin1x1.com/14 ）
◆Googleドキュメントで読む場合はこちらのリンクをどうぞ。
https://docs.google.com/document/d/1qsCYi0FIzjDN_g2Q6vxk7kmXIYt0UCVIc2rZX5DPkLE/edit#heading=h.bubqb8shrd1
◆話者
・新原雅司（ @shin1x1 ）
・そーだい（ @soudai1025 ）
-----------------------------------------------------------------------

新原／
はい、「PHPの現場」です。今回のゲストは、そーだいさんです。じゃあ、そーだいさん、簡単に自己紹介をお願いしまーす。

そーだい／
はい。こんばんは、よろしくお願いします。そーだい、Twitterは、@soudai1025 というアカウントでやってます。「株式会社はてな」っていう会社で、「カスタマー リライアティビリティ エンジニア（Customer Reliability Engineer）」っていう、「顧客の仕事を技術で解決する仕事」ってのをやっていて、
普段、僕のことを知っている人はだいたい「データベースの人」だったりとか、あと「ベストスピーカー荒らし」みたいな感じで、色んなカンファレンスに出てたりしています。よろしくお願いします。

新原／
（笑）はい、よろしくお願いします。いやあ「ベストスピーカーさんのお話」ですからね、今日はきっと面白いですよね。

そーだい／
ハードルが、いきなりあがってきましたね（笑）頑張ります。よろしくお願いします。

新原／
今日はせっかく、そーだいさんに来ていただいたので、データベースの話を中心にいこうかな、と思うんですけれども。
まずは、小ネタを２つばかり話してから本題にいきたいと思います。

まずですね、そーだいさん、Silex（サイレックス）って使ってました？
そーだい／
実は僕は、使ってないんですよ。

新原／
あ、なるほどなるほど。実はですね、今日、Silexが2018年の６月でend of lifeになるっていう発表があってですね。

そーだい／
Twitterでちょっとバズってましたよね。

新原／
あ、そうですそうです。なので、「ああ、ついにきたか」という。

そーだい／
あーなるほど。

新原／
Silex、割と使われているんで。ちょっとこの辺使っている人は、来年の６月までに、何とかしないといけないんじゃないかなあ、とは思ったりします。

そーだい／
うーん、確かに。あの、EC-CUBEの新しい奴は（Silexを）使ってるんじゃなかったでしたっけ？

新原／
そうそうそう、そうなんですよ。

そーだい／
書き直したばっかりなのに、大変そうだなって思ってます。

新原／
ね（笑）。まあSilexの分はそんなに分厚くないと思うんで、なんとかなるんじゃないかなあ、とは思うんですけど。
 

そーだい／
ちょうど関西のPHPカンファレンスの委員長をやってたタカハシ君と昨日、飲んでたときに、SymfonyとLaravelとか、あと、フレームワーク……僕、FuelPHPっていうフレームワーク大好きだったけど、今 息してないっていう話をしたときに……。

新原／
ぶははは（笑）

そーだい／
今からSymfonyがメインのストリームになるんじゃないかな、みたいな話をしている矢先にこれだったんで、やっぱり時代はSymfony 3 に流れていくのかな、感じで、しんみりした気持ちでタイムラインを見てました。

新原／
まあ、Symfonyも新しいバージョン、Symfony 4 っていうのを開発してて。

そーだい／
え、そうですか。

新原／
そうなんですよ。で、それのですね、マイクロフレームワーク版というか、まあSilexの後継みたいなやつで、SymfonyFlexというのがあって。

そーだい／
へえ～～～～。

新原／
んで、これを使うのが……Silexのような要件のときは、Symfony Flexというのを使う感じになるんじゃないかなー、と思います。

そーだい／
なるほど。すごい、今日いきなり勉強になりました。

新原／
ははは（笑）
……まあねえ、Silex、１から２にあがるときも確か結構、１のまま沈黙期間があったと思うので。マイクロフレームワークはPHPには、たくさんあったんですけど、なんかだいぶ、絞られてきた感がありますね。

そーだい／
そうですね。CodeIgniter（コードイグナイター）が、やめる・やめないみたいな話のときも結構増えて。結局、CodeIgniterにまた集約されて、みたいなかたちのところと。そのタイミングで他の流派が出てきたり、みたいな感じで、４～５年前は色々出てきたんですけど、ちょっとそういうのは、落ち着いた感じありますね。

新原／
ふむふむふむ。最近でいうと、SilexとSlimと、あとLaravelのマイクロフレームワーク版のLumenが、よく聞くところかなーと思いますね。

そーだい／
確か、ISUCONがSlimかなんかで問題が出てたと思います。

新原／
あ、ですね、ですね。出ました出ました。

そーだい／
僕のチーム、Goで出てたんですけど、僕がGoは全然、詳しくないんで。PHPのコード読んで「ここがボトルネック、ここにN+1があるから、たぶんGoもあるはずだ」みたいな感じで、デバッグしていました。

新原／
あはははは（笑）新しいやり方ですね。で……あ、ISUCON出たんですか。

そーだい／
そうです、出たんですよ。

新原／
どんな感じですか。

そーだい／
僕がデータベース担当で、言語担当の人とチームで分かれてて。あんまりデータベースは難しいのは出なくて、最初の１～２時間くらいで僕、やることなくなっちゃって。（笑）

新原／
（笑）じゃあ、データベースがボトルネックじゃなかったんですね。

そーだい／
まあ問題としては、データベースに画像ファイルを保存する、っていう、mamyさん（ @mamy1326 ）が好きそうなやつなんですけど。
画像ファイルを取り出すところは、そんなに難しくなかったんですけれども、Webサーバ側をどうやって、こうスケールさせるかみたいなところで、画像ファイル、コピーしなきゃいけないんで。

新原／
ふむふむふむ。

そーだい／
今だと世の中、S3でそんなのできるけど、S3無かったら、久々に、どうやるんだっけ？みたいな感じで。だいぶ僕もクラウドに毒されてるなって思いました。

新原／
あーなるほど。……あ、そうか、なんか出てましたね。ローカルに保存したら、ホストによって、タイムスタンプが違ったりして、キャッシュしてくれないって。

そーだい／
そうそうそうそう。

新原／
ETagヘッダーの値が変わったり、そんなんで、うまくキャッシュしてくれないとかって。

そーだい／
そうなんですよ。「あー、そういえばあったなあ」みたいな気持ちになりました。

新原／
あはははは（笑）……そーだいさんは、画像ファイルとか、自分がシステム作るときは、どこに入れるんですか？

そーだい／
僕は……もう今なら、さすがにS3だと思うんですけど。……僕、データベースに保存をしていた時期があって。

新原／
お、さすが～。

そーだい／
えへへへ（笑）……まあ、ハシカみたいなものなんですけど。画像っていうか、PDFですね。領収書みたいなPDFで、バックアップも一緒に取らなきゃいけない、データベースと一緒に、っていうときに、整合性をとるとか、あとアップロードにコケたら、テンポラリにゴミが残ってちゃいけないっていうの、結構、難しいじゃないですか。

新原／
はいはいはいはい。

そーだい／
アップロードしてインサートなのか、インサートしてアップロードするのか、どっちかでコケたら、排他制御できないから、エラーでゴミを掃除する、みたいなことしなきゃいけないってのが、面倒くさくて。バックアップも１回で済むんで、DB（データベース）に保存するってことをやってました。

新原／
あー、なるほどなるほど。

そーだい／
結構その案件が厳しくて、データファイルを暗号化しなきゃいけないとか。ポスグレ（PostgreSQL）は、データファイルを暗号化するライブラリがあって。それで安く済むので、ポスグレの中に、じゃあ保存しよう、っていう感じで、やってましたね。

新原／
ほーーー。

<--6分30秒

そーだい／
ポスグレ、いい感じに、そういうでっかいファイルを保存する仕組みとかも、最初から用意されてたんで。MySQLよりは良かったな、とは思うんですけど。まあでも今はもう、さすがに、スケールDBがボトルネックに絶対になるんで、Webサービスだったら、ローカル……っていうか、S3に保存するかなって思います。

新原／
ふむふむふむふむ。そうか、でもS3に保存したりすると、SQLアンチパターンのファントムファイルとかに、ひっかかっちゃうって話ですよね。

そーだい／
あー、そうですね。ファントムファイルは、やっぱり歴史があるサービスだと、確かにそういうことが起こりがちなんですけど。弊社にも、「はてなフォトライフ」とかあったりしますけど。とはいえ、やっぱりデータベースに保存するのは、パフォーマンスがボトルネックになりやすくて。特に最近の仕組みって、RDBよりも外がすごい速いから、RDBがボトルネックになりがちなんで、そういうのはちょっと難しいだろうなあ、と思っています。

新原／
ふむふむふむ。

そーだい／
チームメイトは、Redisに保存したって言ってました。

新原／
あーーー、なるほど！

そーだい／
弊社の他の人（＝チームメイト）は、「Redisに保存すれば、アプリケーションサーバがそこから呼べるんで、速い」って。「確かに。なるほど」って思ったんですけど。

新原／
ふーむ。今回のISUCONのやつは、DBのままに入れてると、そこが遅かったんですかね？

そーだい／
そうですね。そこがまず、１コめのボトルネックで。DBにあるので遅い、っていうのが１つ。じゃあ今度はローカルに置くと、画像ファイルでかいんで、ネットワークのボトルネックになるんで、ちゃんとキャッシュさせましょうとか、304を返せるようにしましょう、みたいなのが２つめで。で、僕は、その２つめのところで右往左往してて、全然だめだったんですけど。

新原／
はははは（笑）。そうか、じゃあ、そーだいさん的には、もっと複雑なデータベースのほうが、面白かったんですかね。

そーだい／
そうですね。なんか、100億レコードくらいあって、これどうやってシャーディングするか、っていうほうが得意な感じですね。

新原／
あ～（笑）。でも今後、そういう問題も出る可能性もあるんですよね。

そーだい／
そうですね。問題作る人の采配によるので。結構、その問題作ってる会社のカラーだったりとかが、けっこう出る感じですね。

新原／
確かに。ISUCONは、いつも終わったあとに「あ、あったんだ」って気づくんで。１度は出てみたい感じですけど。

そーだい／
そうですね……僕、PHPのメンバーで出てみたいなって思います。

新原／
あ～、はあはあ。

そーだい／
いっつも、なんかPerlとかGoとかがすごく注目されるので、「いや、PHPもやれるんやぞ」っていうところを出したいなと。

新原／
なんかその、言語がボトルネックになる……まあ、問題によるか。問題によるでしょうけど、……別にPHPだから不利ってこともないんですかね。

そーだい／
そうですね、今回の問題とかは、別に「PHPだから」っていう感じじゃなくて。どっちかというと、GoとかNode.js（ノード）……今回Node.jsが強かったんですけど、Goも多いんですけど……GoとかNode.jsをやってる人が、どっちかというとインフラも得意っていう人が多いっていうだけで。昔、ちょっと前だとPerl（パール）の人とかそうですし。別にPHPでも、同じようなアーキテクチャしっかり組めれば、全然、予選は突破できるんじゃないかな、って思います。

新原／
ふむふむふむふむ。……来年、ですかねぇ。

そーだい／
そうですね。で、来年の今頃、覚えているかどうか、なんですけど（笑）。

新原／
そうそう（笑）。だいたい、終わってから、はてブとかに、記事がいっぱい出てきて、「あ、あったんだ」って気付くっていうのが、だいたいパターンなんで。

そーだい／
はい、分かります。僕も１週間前くらいに社内で話題になったんで「あ、出なきゃ」みたいな感じでした。

<--9分50秒くらい

新原／
あははは、なるほど（笑）。
……で、もう１つの小ネタなんですけど。これは、#phpgenba で、azu（あず）さんという方からtweetいただいたんですけど。いつだったかな、今週アタマか先週くらいですかね。
「PHPコミュニティでブーメランを投げ合うのをやめよう」というポストがあげられててですね。
これについてちょっと、「PHPの現場」で聞きたいと。

そーだい／
なるほどなるほど。

新原／
これって、そーだいさん、読みました？

そーだい／
読みました読みました。これ、なんかその……表現がすごい難しいんですけど、「ブーメランを投げるのをやめよう」と言っている本人がブーメランを投げてる感があったのが、ちょっと非常に残念だなあと思います。

新原／
あははは、いいっすね、いいっすね（笑）核心を突いた意見ですね、まさに。

そーだい／
「多様性は善だ」って、まつもとゆきひろ（ @yukihiro_matz ）さんとかが、よく言ってらっしゃいますけど、僕それはすごく正しいと思っているんで。
PHPは、いろんなフレームワークがあったり、いろんな言語の特徴を取り入れて発展している言語だと思うので、色んなフレームワークがあっていいんじゃないかなと思っていて。それをチョイスするエンジニア側の力量であったりとか、要件に合わせた設定力みたいなところが重要であって。なので、「フレームワークの優劣」とか、もっといえば「言語の優劣」って、あまり、ないんじゃないかなと思っている派だったので。
読みながら、確かにSymfonyで僕はデザインパターンとかすごい学んだことは多かったんですけど……。とはいえ世の中で、Laravelがこれだけ使われているのは、Symfonyにない部分がいっぱいあるからだ、と思っているので。それを正しく伝えるのであれば、もうちょっと言い方があったんじゃないかな、みたいな気持ちがあります。

新原／
確かに確かに（笑）そうですね。まあ、このポストのリンクは、（「PHPの現場」の）「Show notes」には貼っておくんですけど、ちょっとざっくり説明するとですね。
PHPの中にも、いろんなサブコミュニティがあってですね。フレームワークやライブラリ、CMSの何かプロダクトであったり、たくさん、いろいろなサブコミュニティがあって。……あるんですけど、そのサブコミュニティ同士で、ケンカまでは言わないですけど、ちょっと意見がぶつかったりとか、派閥争い的なことがあったりします、と。
で、１つのトピックとして書かれているのが …… この記事を書いたのが、Symfonyのコミュニティの方なので…… Symfonyのミートアップに行ったときに、そのミートアップでLaravelの話をしたら……あ、とある方がLaravelの話をしたら、会場で笑いが起こったと。それも良い意味ではない笑いが起こって。で、次の日に、別の参加者が「すごい不快な思いをした」というようなコメントをポストしたんですね。それでハッと気が付いて、「こういうのはよろしくないな」と。
……というのが、前半というか、中盤くらいまでの話なんですね。

<--12分30秒くらい

で、ここまでは良いんですよ。これはまあ。
「だから、こういうのをなくしていこう」という話にるのかなあと思ったら、そこから後は、どっちかというとSymfonyとLaravelユーザーとの争いに対するSymfonyユーザー側からの意見、みたいな内容になってきてですね。「あれあれあれ？」っていう。それは（そーだいさんの言う「本人がブーメランを」というのは）僕も正直、思いました。

そーだい／
そうなんですよね。前半で終わってれば、すごいいい話だったんですよね。

新原／
そうなんですよね。で、最後のほうにですね、これも字面というか文章自体はすごく良い内容なんですけども……「我々は、同じような考えというか、同じような問題を同じようにとく人同士で集まってしまいがちで、『やっぱりこうだよね』『自分たち以外の方法は、良くないよね』ということで、どんどん考え方や方向が固まっていってしまう。そういうのはやっぱり、良くなくて。特に、これからこういう開発を学んでいく若い人に、何か教えを出すときに、同じような方法を伝えてばっかりじゃ良くないんじゃないか」ってことが書かれているんですけど。
でも、なんとなくこの人自体は、SymfonyやDoctrine（ドクトリン）の考え方が良くて、Laravelとかのほうは「ん～？」というような考え方を、書いててですね。それはSymfonyやDoctrineの考え方に固まっていってるんじゃないかな、っていう印象は……ありました。

そーだい／
そうですね。これは言語関係なく色々な現場であるんですけど、マジョリティ側がマイノリティ側をなんかディスって、お笑いにしたりとか、逆にマイノリティ側が自虐するのが面白い、みたいなのが、結構世の中にはあるので、それの悪い例がちょっと出ている気がするなって思いました。

新原／
うんうんうん。

そーだい／
後半で（この人が）言っている「いろいろな視点を持つこと」は僕、すごく大事だと思っていて。人間って、普通の人は、僕もそうですが、“引き出し”って「やったこと」しか増えていかないし、“想像”も「自分の知っている範囲」でしか想像できないので、全く違うアーキテクチャや考え方を学ぶのは、視野が広がると思うんですよね。

なので、例えばマイクロフレームワークと重厚なフレームワークを触ってみるとか、LL（軽量プログラミング言語／
lightweight language）とコンパイル言語の両方触ってみるとか、型が強い言語と弱い言語、両方触ってみるとか。そういうのは、色々なことを全く違う視点から見れるので。その中で「自分はここが好きだな」っていうのは、全然言っていいと思うんですけど、「これが違うな」っていうのは……自分のフェーズやプロダクトのフェーズによって全然変わってくるので、良し悪しがあるのかな～って思います。
実際によく僕、似たような話でいうとMySQLとPostgreSQLってよく比較対象になって。僕は両方使うんで、両方の良し悪しがすごく分かるんですけど、やっぱりどっちかしか使わない人のほうが多いので、結構意見がどっちかに寄りがちなことがあるんですけど。最近は、MySQLとPostgreSQLって、お互いに意見交換することで良くなっていることが結構たくさんあって。例えばPostgreSQLだと、レプリケーションをMySQLから学んでたりとか。（逆に）MySQLの型の制約っぽいところや、JSON（ジェイソン）型とかもそうですけど、それはPostgreSQLから学んでたりとかするんで。そういうことがもっと他のコミュニティでもうまくできるような、自然な流れをもっと作っていけたらなあと思ったりします。

新原／
そうなんですよね。Webアプリケーションだと、MySQLをよく使われるところが多いので……。僕もいつも面白いなと思うんですけど、例えば何かシステムを開発する話があって、僕はPostgreSQL使うことが多いので、「じゃあ、データベースはPostgreSQLを使います」っていうと、説明を求められるんですね。「なんでPostgreSQLなんですか？」って。そこで「MySQLでいきます」っていうと、何の説明も要らないんですね。最近はちょっと変わってるかもしれないんですけど。MySQLだけ使っている人からみると「なんでわざわざPostgreSQL使うんや」っていうような意見が出てくるってのは、よくありますね。

そーだい／
そうなんですよね。僕は、フレームワークも言語もミドルウェアも、得手不得手があって、的確にチョイスするのが、エンジニアの腕の見せ所だと思ってるんですけど。前回の成功体験に引きずられたり、「チームがMySQLだからMySQLで」っていうのも多いので……。いい感じに新しいチャレンジをやっていく方法があればいいのにな、って思っているので。
僕自身も、「新しい言語やフレームワークはつらいな」って思うタイミングもあるんで、そこでチャレンジをやめてしまうと、その人のエンジニアとしての成長は、そこで止まってしまうのかな、と考えたりします。

新原／
ふむふむ。いやでも、さっきのポストの内容はホント……。まあ見る人、話す人の視点によっていろいろ感じ方はあるし、このポストではSymfonyとLaravel、DoctrineとEloquentですけど、ここが多分、PHPの中の（他の）プロダクトで差し替えても結構、成り立つことはよくあるんで……。

そーだい／
そうですよね。

新原／
何かね～。何か、モヤモヤっとすることは、ありますね。これって、自分が攻撃される側に回ると、すごく敏感に反応するんですけど、うっかり攻撃側に回ってると、多分あんまり分かってない、っていうことがありそうな気がしてて。

そーだい／
そうですね、はい。それはそうだと思います。

新原／
だからそれこそ、僕がこの「PHPの現場」で色々な話してて、もしかしてそれが刺さってる人もいたりするのかなーとか、ちょっと思ったりもしましたけどね。これを見て。
 

そーだい／
いま、はてなブックマークのコメント見てるんですけど、皆さん、いろんな意見があって「なるほどなー」みたいな気持ちになります。これは皆さんぜひ、見てみてください。

<--18分20秒ごろ

まあでも僕、逆に「意見交換が出るほど活発なコミュニティなんだな」みたいな視点でも、PHP（のコミュニティのことを）思っていて。
ちょっと前までは、これTwitterでも言ったんですけど、「PHP書いてる」っていうとバカにされる、みたいな感じだったじゃないですか。でも、PHPの中で良し悪しを言ったりとか、他のプロダクト（プログラミングなど）と比べて良し悪しがちゃんと議論できるような評価が最近、だいぶ付いてきたなと思っていて。

新原／
ふーむ、ふむふむ。

そーだい／
そういう意味では、このブログ（「PHPの現場」）自体がどうとかは措いといて、いろんな意見が出てくること自体は良いことだなーって思います。

新原／
確かに。そりゃそうですね。この手の話は昔からあるっちゃあるんで。残念だなと思うのは、今、そーだいさんが言ったみたいに、PHP言語自体が、そうやって揶揄されることがあって、そういうことをちょっとでも聞いたことが、皆、あるはずなのに、
簡単に攻撃する側に回ってしまうというのが、残念というか。「ああ、やっぱり人間ってそういうものかな」っていう気もしたりします。

そーだい／
難しいですよね。僕も、だから、すごい気をつけなきゃいけないなと思っていて。僕、結構メンタルとか強い側なんですよ。

新原／
あはは（笑）

そーだい／
登壇とか、「すればいいじゃん」って結構気軽に言っちゃう側なんですけど。それとか、「書けば、原稿は進むから」「本とか書けばいいよ」って言っちゃうんですけど、それってやっぱり、自分ができるから言っているだけで、やっぱり苦手な人もいて。逆にその人が出来ることで、僕が苦手なことも必ずあるはずなんで。そういう、得手不得手みたいなのをしっかり、把握するってめちゃくちゃ大事だなと思っていて。それは30代になって、あるていど色々な人に意見できる立場になったからこそ、気を付けないと。さっきの話じゃないですけど、「攻撃側に回っちゃうタイミングがいつか、あるかもしれないなあ」って。結構、気を付けるようにしています。

新原／
ふむふむふむ。

そーだい／
……小ネタは、こんなところですかね。

新原／
そうっすね。まあ、この話だけでも、１時間は全然しゃべれそうですけど。
せっかくなので、データベースの話にいきましょうかね。
そーだいさんといえば、「データベースの人」。最近は「監視の人」でもありますけど。

<--20分30秒ぐらい

PHPアプリケーションを作るにあたって、データベースって当然使うことが多いんですけど、それの組み合わせ方とか、そもそもデータベースの話とかってのを、今日はしたいと思っています。
えーとまずはですね。そーだいさんが、PHPのアプリケーションを作るときって、データベースの操作って何でやってたんですか。

そーだい／
そうですね。これ言うと炎上するんですけど(笑)。結構、「オレオレフレームワーク」……じゃなくて、「オレオレO/Rマッパー」を書く側だったんですよね。

新原／
おーー。いいじゃないですか。

そーだい／
はい。理由が２つあって。Doctrine2とか、よくできてるなと思うんですけど、どうしてもMySQLとPostgreSQLと両方で動くようにするから、どっちかにしかできないことが、サポートされてなかったりするんですよ。

新原／
あ～～～～。なるほど。

そーだい／
なので、ベースは結構ミニマムなクエリビルダーがあって、それをPostgreSQL寄りにするとか、MySQL寄りにするとか。あとは、ちょっと古いO/Rマッパーだと、配列を投げると、バルクインサートしてくれるとか、オブジェクトにするとか、そういうのを書き換えていくと、独自のフレームワークっぽいO/Rマッパーだったりとか、フレームワーク側をちょっと改修して対応する、となりがちだったので……結構そういうのやってしまいがちだったので……。あまりよくないなあと思いつつ、そういうのが多いなって、今思い出しました。

新原／
そうか、まあフレームワークについてるO/Rマッパーは、ナマのクエリーを吐こうとすればできるんで、それでやれないこともないけど、自分たちの要求で使うにはめんどくさいというか、手間が多いということですかね。

そーだい／
そうですね。逆に、僕がデータベースをチューニングする仕事って、そういう一般的なO/Rマッパーではもう性能限界だとか、そういう場面が多かったんですね。さっきの話じゃないけど、１億レコードとか10億レコードが入っているテーブルを、コードを書き直さずに出来るだけパフォーマンスあげたいとか、設計を変えずに対応するにはどうするか、みたいな。
そうすると、例えば細かいチューニングで言うと、INSERTしたユーザーのIDをゲットしたいっていう時に、PostgreSQLだとreturning句っていうのを使うと、INSERTしたIDを取得できるので……。

新原／
うんうんうんうん。

そーだい／
そういうふうに書き直してSELECTを１回減らすとか。そもそも、AUTO INCREMENTでintを超えることがあって。

新原／
おお～（笑）

そーだい／
そうすると、ユーザーIDって普通は一意な数字を使うことが多いと思うんですが、IDじゃだめだ、ってことになるんで、UUIDに置き換えるようにフレームワーク側でちょっといじって、値を入れてやって、INSERTする部分はメインのロジックは変わらなくて普通にセーブしてるだけなんだけど、AUTO INCREMENTじゃなくてUUIDを発行して、入れ込んでいる、という形で差し替えたりしている。そういうことをやっていました。

新原／
ほおーーーー。あ、でもそれアプリケーションの中では、シーケンシャルなIDで管理してるんですよね？

そーだい／
あの……中間テーブルみたいな、IDと、UUIDを紐づける中間テーブルを作っておいて、アプリケーション側はそれをJOINして持ってくる、みたいな。

新原／
あああ～～、なるほどなるほど。あ、それ面白いっすね。

そーだい／
なんかそういうのやってたりしたんで。前職の時くらいですね、久々にデフォルトのO/Rマッパーをガリガリ使った、みたいなのは。

新原／
あ～～、なるほど。じゃあ、よくあるようなCRUDじゃなくて、もっと複雑なクエリーとか、バカでかいデータ量と戦ってた、というわけですね。

そーだい／
そうですね、そういうのが多かったです。

新原／
へええ～、面白い。でもそうなったらもう、O/Rマッパーっていうか、ほとんどもうSQLを直接書くんじゃないですか？

そーだい／
SQLを直接書くことも多くて、っていうか、どちらかっていうと、その……DOAでやるとか、DDDでやるとかいうところの……リポジトリを、「今はRDBだけど、こっから先はファイル」みたいなかたちで、分割していって、メソッドをいっぱい生やす、みたいな。

新原／
……ふむ。

そーだい／
で、メソッドが、例えばget_userって、O/Rマッパーがget_userしてるんですけど、そのget_userの中で、さらにちっちゃいメソッドがいっぱい呼ばれていて、実はそのメソッドが、さっきいったような、UUIDの発行とか、UUIDを使って自分のIDをとってきたりとか、ファクトリーメソッドパターンみたいな感じを作って、そのオブジェクトを返す、といったことをやっていたので。だからSQLを書く時も、そのSQLがどこで何回呼ばれるかとかすごい重要なので、マテビューにしたほうがいいとか、ストアドを書いた方がいいとか、トリガーを書いた方がいいみたいなかんじで。そういう設計をすることが多くて。ゼロから作り直すときに、あんまりそういうことは考えなくていいと思っていて。僕、まれにゼロから１を作るタイミングで呼ばれることがあるんですが、それってだいたいリプレースなんですよね。MySQLからPostgreSQLに移行とか、オラクルからPostgreSQLに移行ってときに、ゼロから作り直す。そのときにはちゃんと設計できるんで、チューニング全然考えなくていいし、O/Rマッパーも「Javaでやります、O/Rマッパーです」。そのO/Rマッパーに最適なテーブル設計を最初からするので、SQLゴリゴリチューニングする、なんてこともしなくていい。「結論、設計だな」みたいなところがすごくある。

新原／
あははは。

そーだい／
だから、そういうのが自分の中にあるので、アウトプットするとき、結構「設計大事ですよ」ってのをすごく言うことが多いですね。

新原／
ふむふむ。さっきの、アプリケーションの中ではget_userするだけでよくて、しかも引数で渡すのは１とか２というシーケンシャルなIDでいいんだけど、内部的にUUIDに変換したりとか、あちこちから頑張って引っ張ってきて、最後はユーザーモデルか何かを返す、っていう感じなんですよね？

そーだい／
そうですそうです。

新原／
まさにそれ、リポジトリパターンですね。

そーだい／
……みたいなのを、ないところにつっこむ、みたいなことを……最初からリポジトリパターンでやっていたら、それって多分、リポジトリをつけかえるだけでいいから、すごく楽なんですけど。昔のフレームワークだったりとか、それこそCodeIgniterを使う人ようなだと、愚直なMVCのMの部分＝データベース、みたいな。１テーブル、１モデルクラス、って感じの設計が多いので、そういう風になっていると結構大変だな、っていうところがあったりして。

新原／
ん～。

そーだい／
なので、皆さんには、速さもすごく大事なんですけど、柔軟性を……ここの部分がこのシステムの柔軟性を担保してくれている、みたいな遊びの部分、差し替えしやすいパーツがどこなのかっていうのを意識してほしくって。データベースよりアプリケーションのほうが、絶対的に変化しやすいんですよね。テストコードも書きやすいし。テストもしやすいし、変更もしやすいし、あとデプロイもしやすいんですよね。データベースだとデプロイするときに、ロックのことを考えなきゃいけないとか、マスター・スレーブのデータの整合性を考えないといけないから。
例えば同じことが、トリガーと、ストアドと、アプリケーションでできるっていうときに、なぜアプリケーションがいいかというと、戻しやすいし変えやすいんですよね。

新原／
うんうんうん。

そーだい／
で、データの……その、論理IDとかスマートIDって言ったりしますけど、IDの数字の中に、「最初の4桁は1から始まったら管理者で、9から始まったらゲストユーザー」みたいなの使っちゃうと、変更する、そのロジックを変えたいっていったら、データを入れ替えなきゃいけないので……。1000件くらいならいいんですけど、1億件くらいとかになったら、データ入れ替えられないじゃないですか。
でも、アプリケーション側だと、そこのロジックを、is_adminを別のオブジェクトに変えればいい、みたいな感じで簡単なので、そういうところで「これは変更するときは、ここ変えるだけでいいな」みたいなことを考えてくれると、すごくいい設計になるんじゃないかなーって思っています。

新原／
うんうんうん。

そーだい／
なので、「（前回出演者の）knitさんや そーだいさんは、すぐ正規化しろって言う」って話題になりましたけど、結構僕、柔軟性を持たせるためには正規化した方がいいと思っていて。前回のお話の中で、「行き切って戻ってくる」っていう話で、ほとんどの人が行き切ってないし、そもそも「行き切ったから非正規化してるんだ」っていう人の、さらに70％くらいは、「いやそれは非正規化せんでも、他のこういう設計で実は対応できるよ」っていうのが結構あるんで。
例えば、外部キー制約をMySQLにつけると、子のテーブルにINSERTしちゃうと、親テーブル側の外部キー制約の対象がロックされちゃうんですよね。共有ロックされちゃう。子テーブル２個くらいが更新しているときに、別のトランザクションが親テーブルを更新すると、ロックをとって、デッドロックしやすいっていうのがMySQLでは良くおこるので、外部キー制約を外す、とかに なりがちなんですが。それはそもそも、親テーブルにUPDATE走らせるからダメで。UPDATE対象のレコードを、別テーブルに切り分けてやると、子が２つできて、親テーブルにも共有ロックはかかるけど、排他ロックじゃないので更新できるので全然問題ない、みたいなかんじで。責務（※そーだいさん注：オブジェクト指向プログラミングの用語で「そのプログラムの役割の範囲」を「責務」という）を小さくするとか、スコープを小さくするっていうのが、アプリケーションもデータベースも一緒で。それでもどうにもならなかったときに、じゃあどうするか？っていうのがすごく腕の見せ所だと思っていて。まずはそこまで皆頑張ってほしいな、っていつも思っています。

新原／
あー、なるほど。それいいですね。「行き切って戻る」けど、実は戻らなくていいことも結構ある、ってことですね。

そーだい／
そうですそうです。

新原／
あ～、でも確かにそうっすよね。その「行き切った」っていうところが、それも何か世界的な標準があるわけじゃないので。その人が「行き切った」と思っているだけなので。実際それは分かっている人から見ると、「ああ、いやそれ全然行き切ってないよ」っていうのは、ありそうですね。

そーだい／
その「行き切る」って、100人いたら何人行き切るか、みたいな世界観だと思っていて。そこでしんどいから、手前で他の方法があると、そっちに食いついていきやすいと思うんですよね。これ、今日のTwitterで見た話でもそうだったんですが、長期的には他のほうが……例えば、「１日我慢したら2000円もらえて、でも今日だと1000円しかもらえない」ってときに、皆、今日の1000円を取りに行く、みたいなところがあって。「とりあえず今日の仕様を満たすためには、こっちでええやろ」とか、「パフォーマンス問題だけど、とりあえずこれで何とかなるらしいから、これ使おう」みたいな感じで。もちろんビジネスとのバランスはあるんですけど、目先の利益を取りがちになるので。それだけじゃなくて、もうちょっと長期的なビジョンを持てると、すごい、エンジニアとして自分の伸びしろが急激に伸びる日が絶対あると思っていて。

新原／
うんうんうん。

そーだい／
僕、データベースでいうと、オラクルエンジニアやってたときからPostgreSQLの時もそうだし、PostgreSQLからMySQLに行ったときも、MySQLの人は「外部キー制約は張らないよ」って最初すごい言われたんですけど、「いやでもオラクルでもPostgreSQLでも張ってるから、張らなくてもできるはずだ」っていうことで、色々考えたときに、「あ、MySQLでもやっぱり外部キー制約張ってもアプリケーション作れるな」みたいなことを思ったりしましたし。

新原／
うんうんうん。

そーだい／
もちろん今の話はデータベースですけど、アプリケーションの設計のときもそうで。ActiveRecordは、すごく良くできてるデザインパターンだけど、ActiveRecordだけにこだわるのはだめだし、逆に、「新しいリポジトリ作った方が絶対いいんだ」ってすぐリポジトリに行っちゃうのではなくって、ActiveRecordはなんでActiveRecordで、リポジトリパターンは、なんで最近いいって言われているのか、両方ちゃんと分かるようになることがすごく大事だと思うんで。自分の中でしっかり腑に落ちるというか、身につけた状態で次のステップにいくといいんじゃないかな、っていうのはすごく思っています。

<--32分30秒あたり

新原／
うんうんうんうん。いい話ですね～。

そーだい／
ありがとうございます。

新原／
でも現場で実際やってると、まあ時間的な余裕もそうですし、何かしらやっぱり制約ってあるじゃないですか。

そーだい／
はい。

新原／
そーだいさんは、実際の納期とか、自分が使えるリソースとかと、「理想を目指す」ということのバランスって、どうやって取ってるんですか。

そーだい／
ええと、自分の中に２段階、納期があって。絶対守らなくちゃいけない仕事の納期と、リカバリ……「ここから最悪リカバリできる」っていう２段階の、手前の納期。で、手前の納期より手前では、妥協は絶対しなくて。ギリギリまでめちゃくちゃ考えるし悩むし、「Ａっていう方法が最適だ」と思ってるけど、それをすぐ実装するんじゃなくて、「実は他にもあるんじゃないか？」と。自分の中での「何とかなるやろ」っていう納期（「手前の納期」）の手前までは、ずっと考えて。例えば１週間あって、実装に２日かかるんであれば、５日間は実際の設計や方法をしつこく考えて。で、「もう手をつけなきゃいけないな」っていうタイミングで手をつけて、残り２日で実装する、という形でやっています。
ただ、この２日間で実装するというのも、問題がありがちなんで、本当のエンドは例えば……12月１日がリリース日だったら、１週間前にチームレビューがあって、そこがもう最終的に絶対守らなくてはならないレビューのタイミングだとしたら、そこから逆算して……っていう感じで。「ぎりぎりまでねばる」っていうのも、実務では大切にしていて。とはいえ、そこで全部解決できるわけじゃない。そこで解決できなかったことは、プライベートな時間で、知っていそうな人に聞いてみたり、自分で試してみたり。あとは……僕は、本を読むだけじゃ理解できないことが多くて、自分でプロダクトを作ってみるっていうのは結構、よくやりますね。

新原／
あ～～、なるほど。確かに自分で作ってみると、全然違いますもんね。本で読んでいるだけと、実際使ってみるのとでは、やっぱり、全然、しみてくる度合いが違うというか。

そーだい／
ああー、確かに確かに。

新原／
そういうのってありますね。

そーだい／
そういうのを繰り返すと、引き出しが結構増えていって。これは、ペパボの ぴーやまさん（ @pyama86 ）の丸々パクリなんですけど、「引き出しの中に物が入っていないと、意味がない」わけじゃないですか。本を読むのって、引き出しは増えるんですけど、じゃあ中にどんなものが入っているかっていうと……。当然、（本を読むだけで）入る人もいるんでしょうけど、僕は手を動かさないと中に入らないんで。引き出しが新しく増えたら、その中に新しいものを入れる、みたいなことは、やるようにしています。

新原／
ふむふむふむふむ。

そーだい／
ただ、これは僕が……、すごい夜更かしなんですよね、僕。

新原／
あはは(笑)

そーだい／
だから、夜の時間にそういうことができるから……。それと同じことを他の人に「押し付ける」のは良くないなーって。さっきの話じゃないけど。
逆にいうと、本読むだけで、すごくできる人もいるし、逆にプロダクトを作るんじゃなくて、皆と話をすることでアイデアが出る人もいるんだなーって、最近思ったりしたんで。

新原／
うんうんうんうん。はい。

そーだい／
逆に僕もそういうやり方を色々、学んでいかなきゃいけないなと思っています。

新原／
そうですね、僕もやっぱりインプットするだけ……一方通行で、つまり本を読むとか何かの発表を見るとか、それだけだと刺激が弱くて。

そーだい／
あー、「刺激が弱い」。なるほど。

新原／
自分で書くのももちろんそうだし、あとこうして話をするのもそうだし、やっぱり色々な刺激を与えて、自分の頭に、しみこませていくっていうのは、ありますね。

そーだい／
なるほどなるほど。僕、結構、勉強会に参加する理由が、そんな感じですね。

新原／
あー、はいはいはいはい。なるほど。

そーだい／
ちょっと前のコミュニティの話で、新原さんが「行くのは楽しいけど、それだけなのか」っていうのがあると思うんですけど。あそこに行くと、誰かしらは自分が悩んでる悩みを知っている人だったり、同じような悩みを知っている人がいて、そこで意見交換をすることで、答えはなくても、なんか新しい方向性が見えたりとか。あと、いろいろな人がいるわけじゃないですか。僕は、フロントエンドとか弱いから、フロントエンドの人の意見を聞いて、「あ、なるほど。こういう視点があるのか」みたいなところがあって。そういう、色々な視点があったり、自分の悩みに、他の視点からアドバイスをもらったりっていう、そういう交流の場として勉強会に行くことが結構多いなー、と思います。

新原／
ふむふむふむ。

そーだい／
で、ただ……ギブアンドテイクの世界なので、コミュニティって。行って、聞くだけじゃ戻ってこないので、ちゃんと自分でアウトプットできることをしようと思っていて。だから今、自分が一番勉強したこととか、僕が一番アウトプットで出せるものを、できるだけスピーカーやったりブログでアウトプットして、で、そのアウトプットに対してインプットをもらったタイミングで、ついでに聞いてみるって感じで。そういう感じで、勉強会に参加するって感じですね。

<--37分20秒

新原／
でも、意見交換って意味だと、それこそ今だとポッドキャストもあるし、「勉強会」じゃなくても、飲みにいったりとか、そういうのでもいけるんじゃないかなと。いわゆる、ちゃんと会場を借りて、人を集めて、スピーカーの人がちゃんとスライド用意してきて……っていうことをしなくても、できるんじゃないかな？みたいなのも、ちょっと思ったりするんですよ。

そーだい／
それは、……その、なんですかねぇ。コミュニティのメンバーだったりとか、飲みに行く人が、答えを知っている場合は、それでいいと思っていて。「デザインパターンの話だからこの人に聞こう」とか、「ＤＢの話だからこの人に聞こう」みたいな時はいいと思うんですけど。
「誰に聞けば答えを持っているか分からない」時っていうのは、やっぱり雑多なところというか、多様性のあるところに行く必要があると思っていて。そういう場所は、勉強会とか新しいコネクションを作りやすい場所かなって思っています。
で、この話は……僕、ブログで、「自分のホームじゃないところで話をしたほうがいい」というのを（書いてるんですが）……。
YAPC::Kansai（ヤプシーカンサイ）の控室で、竹迫さん（ @takesako ）というリクルートテクノロジーの顧問をされている方に言われた時に、「ああ、なるほどなー。だから僕は色んな勉強会に行こうという気持ちになるんだ」って思ったんですよね。
「敢えてアウェーで戦う事に意味があるって話」です。

新原／
ああ、なるほどなるほど。

そーだい／
で、そういうところがあるので……。もちろん、知っている人と話をするのは、コンテキストが共有できているから、話が早いんですよ。

新原／
うんうんうん。

そーだい／
話は早いし、お互いに似た者同士で話をするからすごく楽しいんですけど、どうしても「楽しい」で終わってしまいがちで、新しい視点だったりとか、自分が実は間違ってるよ、ってことを言ってもらえなかったりしがちなので。なので、色んな所に行くとか、コミュニティに行ったり、カンファレンスに行くことは大事だなって思います。

新原／
あ～、なるほど。それは確かにありそうですね。

そーだい／
実際に……僕、けっこうエンジニアの人は話が合うから、話すの好きなんですけど、そうじゃなくて、「エンジニアじゃない人と話すの大事だな」って、「はてな」という会社に入って思って。

新原／
うんうん。

そーだい／
はてなって、ランチがあるんですよ、昼に。で、フリースペースでランチするので、目の前に営業の人が来るとか、総務の人が来るとか、誰が座るか分からないし、誰と話してもいいんですよね。
そうすると、結構いろんな話が、昼のランチの１時間の間に行われていて。それで結構学ぶことも多いし。それはそれで、「あ、なんか勉強会と同じようなメリットがあるなあ」って思ったりします。

新原／
ふむふむふむふむ。

そーだい／
僕、結構、好き嫌い激しい方だったんですけど、「好き嫌いしちゃだめだな」みたいに思って。

新原／
へ～、意外な感じですね。なんか「誰でもウェルカム」なイメージですけど。

そーだい／
いや～、そんなことはなくて、やはり、得手不得手は僕もあるので。

新原／
あはは、そうなんですね。

そーだい／
はい。でも、そういうのをやってかなきゃな、って最近すごく思う。

新原／
確かに、エンジニア同士だと、視野がせまくなるというか。深くはなるんですけど、どうしても見る範囲が狭くなりがちなので、そうじゃない人と一緒に話すのは、確かにいろんな発見がありますね。

そーだい／
そうですね。

新原／
特に、すごく技術的に煮詰まっている時とか、さっきの「フレームワークどれにしよう」とか、何でもいいんですけど……「言語何にしよう」とかでもいいんですけど。エンジニアじゃない人と話してみると、「あ、そうか。ブラウザ立ち上げて動けばいいのか」とか、当たり前のことに気づかされる、というか。

そーだい／
うんうん、確かに。

新原／
その辺の「主従」は意識して考えないとなあ、と思いますね。もちろんエンジニアとしては技術的にもっともよいものを探したいな、とは思うんですけど。とはいえ、「趣味」ではないので。そこで悩むのではなくて、早く届けて価値を出す、ということが大事な時もあるので。その辺、ハッと気づかされるときもありますね。

そーだい／
僕、結婚して良かったなと思うのは、そういう……。ウチの奥さん、エンジニアでも何でもなくって、普通の、一般人というか……どちらかというと専業主婦なので、エンド･ユーザー側の意見が聞けることが多くて。
僕が、「UIをＡとＢどっちにしようかな？」とか「アプリケーションをどういう方向性にしようかな」って悩んでいると、「そもそもそれって意味あるの？」みたいな。
「あ、そっか。これそんなに悩むことじゃなくて、とりあえず両方やってみて、ダメだだったら戻せばいいのか」みたいなことを気づかせてくれる。

やっぱり、色々な人に相談する、話をするというのは大事だなと思うことが多いです。
新原／
分かります。僕も家族は全然、開発とか関係ない人なんで。技術の選定とか、深いことは当然、そんなに話さないですけど。とはいえ、話をしていて「今こんなこと悩んでるよ」って言って、「それ、そもそも悩む必要あるの？」とか、「どっちでもいいんじゃない？」って返ってくると、「ああ、確かにね」という時はありますね。

そーだい／
そうですね。転職とかも、僕は奥さんが背中押してくれたから、今回、

東京に来れた、みたいなところも結構あるんで。
新原／
あ～。そう、それ。でも、すごい決断ですよね。

そーだい／
いやほんと。僕は東京で仕事することなんて絶対ないと思ってたので。でも奥さんに相談してみると、意外と普通に、すっと行った感じですね。

新原／
へ～。もう、こっち来てどれくらいになりますか？

そーだい／
僕、１月１日入社なので、もう少しで１年ですね。

新原／
こっち出てきてやっぱり、違うなあと思いますか？まあ、色々違うでしょうけど。

そーだい／
そうですね。「東京すごいな」って思うところは、インターネットで見た人と普通に会えるというところが結構あって。それこそ、僕らが、勉強会や大きいカンファレンスに行っても話す機会が持てなかったような人でも、普通に話す機会があるってのは、良いところだなあと思うんですけど。
難しいなと思うところは、逆に、覚えきれないとこ。僕も覚えてないし、向こうも多分覚えてってことが結構あって、「密なコミュニケーションをする」というのが、きっかけがないと難しいなと思いました。

新原／
あ～～……。なるほど。
そうなんですよね。カンファレンスとかで会うと……もちろん、色々な人と会って、楽しいんですけど、ある程度、多少なりとも知っている間柄でないと、なかなか深く話せないというか。深くコミュニケーションとれないっていうのはありますね。

そーだい／
はい、そうですね。

新原／
そうなんですよ、僕、ポッドキャスト始めた理由のひとつは、実はそれもあるんですよね。

そーだい／
ほう～、なるほどなるほど。

新原／
色々な人とコミュニティで会って、楽しいんですけど、「みんなでワイワイ」というパターンが多いので。それはそれで楽しいんですけど、１対１とか、３人とか、「少人数でじっくり話す」っていう機会って、意外とないんですよね。

そーだい／
確かに。

新原／
それこそ、「すごく仲がよくて、いつも会ってる人」とは、そうなるんですけど……懇親会終わって、何次会とかになってくると、そうなるんですけど。
でも、そうでもない人と、じっくり話すという機会ってあんまりなくて。その辺もやりたいな、と思ったのが、ひとつのきっかけでしたね。

そーだい／
言われてみれば、皆でワイワイするのって、「誰かがめちゃくちゃ得意な話」を聞くんじゃなくて、「皆が知っている話」がテーマになりがちなので、例えば「最近、こういうの使ってますよね」みたいな話をするだけで終わりがち。
「実際に仕事でこうだった」とか、「最近のキャリアはこういうこと考えてる」って発展していかないので、確かに「なるほどなー」って思いました。

新原／
あと、話題も移りがちじゃないですか。別に、その時はそれで楽しいんですけど、「この話をもっとしたい」とかいう時は、やっぱり小人数じゃないとなかなか難しいなと思う時があるので。

そーだい／
確かに、確かに。

新原／
なので、ちょっとまだ聞きたい話があるので、データベースの話に戻ります。

そーだい／
ははは(笑)、ありがとうございます。

<--44分56秒

新原／
で、えーと……。データベース、いろいろあるんですが……。
実際に、PHPアプリケーション……PHPじゃなくてもいいんですけど、データベースを使ったアプリケーションで作るときにですね、例えば、

マイグレーションツールって、何か使ってました？
そーだい／
僕は、マイグレーションツールに一番最初に出会ったのは、Ruby on Rails（ルビーオンレイルズ）だったんですけれども。まあやっぱり出てきた時は「すげえ、天才だな」って思ったんですよね。で、Ruby on Railsでコードを書いたあとは、Doctrine 2 ……Symfonyの案件だったので……そこでもDBマイグレーションやったりしたんですけれども。運用フェイズの、ある一定くらいのレコード……そのSymfony 2 の案件が、レコードが本当に“億”を超えるくらいになったときに……

新原／
ふふふ（笑）

そーだい／
マイグレーションできないんですよね。３時間とか４時間とか掛かっちゃって、デプロイできない……っていうところになって、「ああ難しいなあ」みたいなのは思うところがありました。

新原／
はあ。あ、それは、ALTER文とか走らせたりしなきゃいけないとか？

そーだい／
そうですそうです。

新原／
あー、なるほど。

そーだい／
で、よくある手法なんですけど、MySQLとかだと、マスターとスレイブがあったら、スレイブ側にALTERを流して、タイミングよく、マスターとスレイブをフェイルオーバーさせるとか……。

新原／
ふーむ。

そーだい／
あるいは、マスターしかない状態だと、テーブルでまったく同じものを作っといて、そっちにALTER文を流して、そして、こことここはダブルライトをアプリケーションでさせるか、トリガーで書き込んでるんだけど、どっかのタイミングでスッと入れ替える、みたいなことは…マイグレーションツールではできないですよね。

新原／
うんうん、そうっすね、そうっすね。

そーだい／
だから、どっかのタイミングで、乗り換えるタイミングが来るなあと思っていて。そこがこう、なんか……いま僕も、良いものがあればいいなあと思うんですけれども。

新原／
うんうんうんうんうん。

そーだい／
ただ、Python（パイソン）のDjango（ジャンゴ）。あのマイグレーションツールは、よく出来てるなあと思うことが多いですね。

新原／
へええ～～。

そーだい／
あいつは、外部キー制約ちゃんと張ってくれるし、PostgreSQLとかだと、パーティション切ってくれたりとか、シャーディングっぽいことを、O/Rマッパー側で吸収してくれたりとかするんで。「よく出来てるなあ」って思ったりします。

新原／
ほおお～～。なんか、その「外部キー制約つける」っていうのは、マイグレーションツールとか、O/Rマッパーの仕事なのかなあ？っていう気も……。

そーだい／
あの、マイグレーションツールで設定は当然するんですけれども、「自動的にやってくれる」っていう意味で……はい。

新原／
なんかあの、さっきの「PHPコミュニティでブーメランを投げ合うのはやめよう」でも書いてあったんですよ、確か。「Doctrineは外部キー制約つけてくれるけど、Eloquentは、つけてくれないから如何なものか」みたいなことが書いてあって。「いやそれは、あなたが（外部キー制約を）つけるように書けばいいんじゃない？」って僕は思ったんですけれども。それって、ツールが自動的にやるもんなんですかね？

そーだい／
それは、「やってくれたら嬉しい」っていう話、だとは思うんですけど……。

新原／
うんうんうんうん。

そーだい／
それは、必要性の判断ができる人が、そういう判断ができるんだと思う。必要性の判断できない人のデフォルトを、どっちに寄せるかだと思うんですよね。

新原／
あーなるほど。

そーだい／

まさに僕、「制約」が来月号のSoftware Designの連載の内容なんで、すごい考えたんですけれども（笑）
新原／
おおっ、いいですね（笑）

そーだい／
似たものって結構あるじゃないですか。外部キー制約だけじゃなくて、ENUM（イーナム）だったりとか、チェック制約だったりとか、サロゲートキーとかナチュラルキーもそうですが。
「どこまで何をやるか」というか、どこまでDB原理主義で行くか、どこまでアプリケーション側でやるか。DB側は、制約によってデータを守っていて、アプリケーション側は、規約というか、バリデーションというか、ロジックなどでデータを守るんですけど。どっちに重きを置くかだと思っていて。
で、最初の方の話に戻るんですけど、「アプリケーション側は仕様変更に強い」んですよね。

新原／
うんうんうん。そうっすね。

そーだい／
ただ、規約でデータを守ろうとすると、バグとヒューマンエラーにめちゃくちゃ弱いんですよ。
バグは、まあまだ、テストで担保する方法とかあるんですけど、ヒューマンエラー、要はアプリケーションを通らないとか、デプロイのタイミングでデータが入ってしまった、とかいうのが守れなくて。運用でカバーみたいなタイミングで、アップデート分流すと事故るとか。

新原／
ありますね（笑）。

そーだい／
WHERE句を付け忘れたUPDATEを……。

新原／
ああ～！！（笑）ありますね（笑）。

そーだい／
はい。そういうのが、守れないんですけど。
データベース側は、正しく、自分の思った通りに、―もちろん制約が正しくないというヒューマンエラーはあり得ますけれども―、正しく制約がついていたら、正しくデータが入る。例えば、「消費税が８％以下に絶対設定されないようにする」というのをやったら、「５％」とか絶対入らないわけじゃないですか。

新原／
そうですね。

そーだい／
そういうのでどちらがいいか、っていうところがあって。これって「どっちで痛い目を見たことが多いか」で、バランス……つまりDBに寄りがちだったり、アプリケーションに寄りがちだったり、するんですけれども。
僕は、両方で痛い目にあった結果（笑）、ビジネスロジックを持たせたりとか、状態を持たせることは、できればアプリケーション側にやらせたほうが良くって。DBは事実だけ、結果だけを持たせるようにして。
その「結果」が、“変わらないもの”や“変化しにくいもの”……例えば「都道府県」だったりとか……。

新原／
ふむふむふむ。

そーだい／
あとは……、“ビジネスロジック上、絶対に変わったらいけないもの”、例えばお金の清算の結果だったりするなら、厳しく制約をつければいいと思う。逆に「ブログの記事の文字数」みたいなのなら、そんな細かくこだわらなくてもいいだろう、ということで、ゆるく（制約を）つけたらいいと思っていて。

新原／
ふむふむふむ。

そーだい／
「じゃあ、トリガーとかストアドとかマテビューとかは、何のためにあるの？」っていうのはですね。
とはいえ……設計で最初の思想でずっときても、どっかで仕様変更や、方向性が変わったタイミングで、パフォーマンスとか色々な理由で、吸収しきれないときが、あるじゃないですか。

新原／
うんうんうん。

そーだい／
例えば「データベースリファクタリングがしたい」とか、「データの速度をあげるためにテーブル設計を変えずにやりたい」とか、そういう時のための“奥の手”なんですよね、あの辺は。

新原／
ふむふむふむ。

そーだい／
奥の手だから、ストアドとかトリガーとかを、積極的に採用するのは、また違うなと。逆にいうと、トリガーを使いたくなった時は、「他の方法で対応できるんじゃないか」とか。そういうのは、テストコードを書く時、テストを書くことによって、クラスを見直すタイミングになったりとか、メソッドを見直すタイミングになる、TDD（テスト駆動開発）みたいなところがあると思うんですけれども。

新原／
ふむふむふむ。

そーだい／
トリガーとかストアドとか、“DB特有の機能”を使いたいときは、「設計に何か間違いがあるんじゃないか」とか、「これ本当に大丈夫なの？」というのを振り返るきっかけになる。

新原／
ほほ～ぅ。

そーだい／
そこが、良い中間点というか、バランスをとるタイミングかな～、と思います。

<--51分17秒

新原／
ふむふむふむふむ。

いわゆる「不吉な匂い」ってやつですね（笑）。
そーだい／
あ、そうですそうです。

新原／
あ、それ、面白い視点ですね！「ストアドとかトリガーを使いたくなったら、“不吉な匂い”と思え」っていう。

そーだい／
そうですね。

新原／
なるほどね～。

そーだい／
チェック制約は、まあ好みかなーと思っていて。だから、ENUMとかも、そうです。ENUMとか、あとは……マテビューもそうですけど。その辺は、使いたくなってきたら、ちょっと考えた方がいいかなって。
逆に、ユニーク制約とnot null制約と外部キー制約は、最初からなるべく使った方がいいと思っていて、「外したくなった時」に、逆に「何か問題があるんじゃないかな」と思うようにしています。

新原／
なるほど。あ～、なんか、結構、意外というか……。話を聞いてて、割と僕も同じような意見だったので。なんかもっとこう、「データベース原理主義」の意見が出るのかなーと思ってたんですけど。

そーだい／
あはは（笑）僕、多分、アプリケーション書くからだと思うんですよ。僕は、データベース側からアプリケーション書く側になった人間なので。アプリケーションとデータベースで、データベースが得意なことも知ってるんですけど、苦手なことも知っているんで、「アプリケーション側でやった方がいいな」って思うことも結構あるっていう。

新原／
んん～～（なるほど、みたいな感じで）。

そーだい／
逆にいうと、アプリケーション側が苦手なことが、ユニーク制約だったりとか、nullのチェックだったりだと思うので、そういうところはデータベース側でしっかり担保しよう、みたいなところが、（データベースとアプリケーションの）「棲み分け」かなあと思っています。

新原／
ふ～む、ふむふむ。

そーだい／
なので、意外と、僕は、「null許容派」ですし、

サロゲートキーは、どうしても必要な場合は付けてもいいなー、と思っています。
新原／
ほぉ～。あ、「積極的に使う派」ではない、ってことですか。

そーだい／
あの、O/Rマッパー使う場合は、サロゲートキー使うんですけど（^^; サロゲートキーだったりとか、あと、UUIDをキープしたりするんですけど、「全部のテーブルに必須にはしない」っていうか。

新原／
ああ～。

<--53分02秒

新原／
それこそ、さっきの……“ENUMの取りうる値を制限したい”ときに、「チェック制約を付ける」っていうのも１つなんですけど、チェック制約だと変更するのが大変なので、「別テーブル作って、外部キー張って、取りうる値を別テーブルのレコードで定義する」という方法をよくやると思うんですけど。

そーだい／
そうです、そうです。

新原／
その時の別テーブルに、サロゲートキーを入れるのか。それともENUMで取り得る値、…例えばコードでもいいんですけど…、そういったものだけを入れるのか。

そーだい／
その値をJOINで取り出したいか、値だけでいいのか、というのがすごく重要だと思うんです。例えば、都道府県のテーブルとかが、そういうとこだと思うんですよね。

新原／
そうっすね、そうっすね。

そーだい／
で、都道府県テーブルって、別にJOINで取ってこなくてもいいんですよ。変わらないから。１回取ってきて、例えばRedisに突っ込むとか、フレームワーク側のキャッシュだったり、memcachedだったりにくっつけといて、ビュー側でくっつける……みたいな感じで出来ればよくって。
その場合、それを表す値であればそれに近ければ何でもいいと思うので、サロゲートキーでも、ナチュラルキーでもいいかなと思う。
JOINする場合は、できればintであってほしい。それは、JOINがintのほうが早いっていうのと、インデックスを絶対張るから、intのほうが４バイトで小さい、っていうのがあって。
あとは、ソートのことを考えたりすると、インデックスがあった方がいいので。
その場合は、サロゲートキーを付ける、みたいな。
どっちかというと「どういう使い方をするかで決める」ということですね。

新原／
あー、なるほど。

そーだい／
実際、都道府県の場合は、ソートした時に北海道が一番上に来てほしいわけじゃないですか。

新原／
ははは（笑）、そうですね。

そーだい／
だからまあ、サロゲートキーがあったほうが良いでしょうし、それはサロゲートキーに見えるけど実は「都道府県の連番」っていうナチュラルキーなんですよね、それは。だからそれはそれでいい。
でも「事業部名」とかだと、例えば「営業部が一番上に来なきゃいけない」とかの要求がないのであれば、サロゲートキーでなくてよい。何か、連番でない別のIDでもいいんじゃないかなと思ったり。

新原／
O/Rマッパーとか使っているとサロゲートキーを要求されることが多いので、あんまり意味がなくても、例えばENUMの値でも、ID付けたりとか、以前はしてたんですが。でも、最近はそろそろ意味ないよね、と思って、値だけを置くようにしているんです。

そーだい／
そうですね。

新原／
結局、ENUMの値ってアプリケーションで定義しているはずなので。なので、「ENUMの取りうる値全部ほしい」とかは、アプリケーションが普通、持っていると思うんですよね。

そーだい／
確かに。

新原／
どっちかというと、データベースの制約のためにテーブルを作っている、と。僕は最近、そういう見方をしてますね。

そーだい／
確かに。僕、Djangoで作っているときに、そんな感じなんですよね。ENUMクラスみたいなのが作れて、そこに、都道府県をぜんぶ最初から全部書いてあるものが……逆にいうと「アプリケーション側とデータベース側が同じですよ」っていうために、データベース側にも書いてある、みたいな。

新原／
あ、そうそうそうそう。そうなんすよ、そうなんすよ。

そーだい／
そういうのありますね、確かに。

新原／
やっぱりアプリケーションで持っている値で、当然ロジックが変わるとかもよくあるので。データベースだけに値があって、それを機械的に取ってきてどうの、っていうよりは、ロジックが絡むから、アプリケーションにもあるべきものなので……。その辺の考え方も、以前とは変わってきたなあと思いますね。
それこそ、アプリケーションを主と考えるのか、データベースを主と考えるのか。その辺によっても考え方が違うと感じます。

そーだい／
確かに。僕、結構データベースとアプリケーションって世界線が違うので、インターフェースが大切だなと思っていて。今の話でいうと、アプリケーション側で「１」だからテーブルでも「１」、っていうのも違うと思って。
実はuserってオブジェクトがアプリケーション側にもあるけど、データベース側にはユーザーテーブルとユーザープロパティと、ユーザーなんちゃら……みたいな感じで、複数のテーブルのJOINの結果がユーザーオブジェクトであるから。それをJOINした結果のビューでもいいわけでしょう。

新原／
うんうんうん。

そーだい／
ビューには、連番のサロゲートキーを、O/Rマッパーのためにつけてあげてもいいかもしれない。小さく持っているところは、別々に持たせてもいいと思っているし。
だから極端な話、「データストア＝RDB」になりがちなんですが、RDBじゃないことも、最近は多いわけじゃないですか。NoSQLとか。
なので、インターフェースをしっかり考えてあげて。
そのインターフェースが責任境界線なので。
その責任境界線で、「データストア側はこれをしっかりやってほしい」し、「アプリケーション側はビジネスロジックをいかにうまく表現するかを頑張ってほしい」と思っていて。
そういうところが、最近けっこう議論されることが多いんじゃないかなーって、インターネット見てて思います。

新原／
うんうんうん。僕もまさにそういうところが、リポジトリパターンとか使う利点だと思うので。リポジトリパターンを使っていて、例えばデータベースで「PostgreSQLやMySQLを切り替えやすい」とか、「KVS等の差し替えがしやすい」とか……そういう利点もあるんですけど。どっちかというとまさに「責任境界線」。「アプリケーション側の要求はここまで」で、データベースの都合はリポジトリの中の実装に閉じ込めてしまう。「複数のテーブルに別れてる」とか、「一部分はファイルから取ってくるのか」「もしかしたら、別のAPIたたきに行っているのか」そういうことは全然気にしなくてよくて。
最終的に、与えたパラメータにそったデータが返ってくればいいっていうだけなんで。それがきっちり分けれるというのが、すごいいいなあと思って。

そーだい／
確かに、確かに。トランザクションを無視するのであればREST APIでも別にいいと思っていますし、結果参照性だけでアプリケーション側がいいのであればNoSQLでいいだろうし。サービスを表現するときに、そこらへん「得意なことを誰にさせるか」というのが結構大事だなと思っています。それって、アプリケーションだけやっている人だと、今の時代、極端にいえばアプリケーションだけで何でもできるから、アプリケーションに責務を寄せがちだし。データベースが得意な人だとデータベースに寄せがち。だからバランスよくいろいろ見れる人って大事だなと思う。
最初の話に戻るようですが、越境じゃないけど、色々な視点を持てることが大事だなって思います。

新原／
そうですね。割と、しっかり分けておくといいとこどりできるんですよね。O/Rマッパーで一気通貫にやっていると、データベースの仕様はO/Rマッパーの仕様に引きずられるし、アプリケーションの内容もデータベースに引きずられたりするんですけど……。ちゃんと、リポジトリなどで、しっかりレイヤーを分けておけば、アプリケーションはアプリケーションで最適な形で作ればいいし、データベースもデータベースに最適な形で作ればいいので、すごくこれはやりやすい形ですね。

そーだい／
そうなんですよ。僕がよく一時期、天狗になっていた時に言っていたんですけど。データベースを自分で設計した時に、アプリケーション側で困ったことがなかったんですよね。

新原／
あ～、はあはあ。

そーだい／
それは、自分が苦手な部分を解決できるからってことになるんですけど。そういうところが結構あるので、一生懸命にサービスを作るなかで匙加減を知るのは大事だし、責務のスコープとかを考え出すと、自然と、クラスやモデルもそうだけど、正しい形になっていきやすいところがあるなあと思うんですよ。
だから、そういう考え方が、DDDだったりDOAだったり、色々な言葉があるけど、それは「どっちかだけ選ばなければならないもの」ではなくて、実は両方成立するものだと思っています。

<--1時間1分03秒
 

（そーだい／
続き）
逆に僕は、一番最初にDOAを学んで、次にオブジェクト指向を学んだんですけど、「その２つのうちのどっちか」っていう世論が多い中で、「これ、でもどちらかだけの話じゃないよな」って思っていた時にDDDっていう言葉と出会って、「あ、そうか。僕が思っていたモヤモヤを、言葉にするとこういうことなんだ」みたいな感じで思ったんですよ。

新原／
ふ～～む。

そーだい／
なので、多分、今日の話が共感できるのは、同じような……つまり、アプリケーション側とデータベース側で、お互いの視点のインターフェイスが近いから、っていうことはあると思います。

新原／
ふむふむふむふむ。ほんと、この話はちょうど、PHPカンファレンスの懇親会のときに立ち話で、ちょっとしていたんですけど。
そーだいさんってもっと「データベースの人」っていうイメージがあったから、データベース中心に考えて、データベースに最適な形で……「アプリケーションはいわば、データベースの値を操作するためのもの」っていう発想があるのかなー、って思ってたんですけど。意外と考え方が似てたのが、すごい驚きました。

そーだい／
そうなんですよね。……そうなんです、僕もこう、逆にアプリケーションサイドの人が、僕の意見に「いやいや、そんなんRDB key-valueストア（KVS）でしょ」とかって言われたりするんですけど。（※そーだいさんより注：「RDBをKVSとして使う人が多い」という意味です。）

新原／
あっははははははは（笑）。

そーだい／
そうですね、だから僕もPHPカンファレンスの時に「アプリケーションサイドの人でもこういうことを思えるって、やっぱりひとりで色々なことをやっている人は強いんだな」って感じました。
若者にも、好き嫌いせず、他のレイヤーを触ってほしいなあって思いますね。

新原／
まあやっぱり、システムを作るってなると、アプリケーションだけ作るとか、データベースだけ作るって……まあそういう分業されてるとこもあるんでしょうけど、それよりやっぱり「とりあえずシステムとして提供しないといけない」ので、両方必要ですよね。それは、他のインフラとかでも同じですけどね。当然、アプリケーションとデータベースだけじゃなくて、それを動かす基盤が必要なので。そこも含めて物事を考えたほうが、僕は面白いとは思いますね。

そーだい／
それを僕、キャリアの話でもそうなんですが……
自分の生存戦略でもそうですが、
機能であったり、仕組みとか、特定のところだけに寄っちゃうと、例えばPHPが何らかの理由で死んだり、僕の場合、PostgreSQLが何らかの理由で死んだ時に、自分のストロングポイントを失うわけじゃないですか。

新原／
ふむふむふむふむ。

そーだい／
でも、そのバランス感覚だったりとか、設計の発想力とかって、別にSQLじゃなくても生かされるだろうし、?言語でも生かされるだろうと思うので……なんか、リスクヘッジにもなるなあ、と思うんですよね。

新原／
あ～、確かに。

そーだい／
なので……もちろん「費用対効果が高いところに投資するのが正」というわけじゃないんですが。色々なところに投資したり、自分のやりたいことをやるのが一番いいんですけど、まあそういうところで、キャリアパスに悩んでいる方は、「自分の今までメインの戦場じゃなかったところ」という意味で、下のレイヤーを見てみたり、下のレイヤーの人がアプリケーションサイドを見てみたり、というのは、すごく良いんじゃないかなと思います。

新原／
そういう話でいうと、強みを１コ持っておいて、その強みをどんどん伸ばしていくのも１つの手なんですけど、逆にその周辺のことを一緒にカバーしておくと……「２つを両方分かる人」って意外と少ないので。「アプリケーションとインフラ」でもいいし、「アプリケーションとデータベース」でもいいし、「エンジニアだけど外でお客さんと話ができる・説明するのがすごい上手」とか……１つの技能だけじゃなくて、もう１つ別の技能と「掛け算」ができるようになると、割と生かせるなあ、とは思いますね。

そーだい／
確かに。
……いま僕、いいなあと思ったのは「掛け算」という表現。
すごくいいなと思いました。そうなんですよ、「足し算」じゃないんですよね。「掛け算」なんですよね、軸が増えたタイミングって。

新原／
そうそうそうそう。で、面白いのが……もう１コの軸は、そんなに強くなくていいんですよ、実は。

そーだい／
あーー、確かに。

新原／
１コめが強ければ、もう１コはそんなに強くなくてもいい。「両方をカバーできる人」って、一気にガンと減るんで。そこは、強みになるんじゃないかな、と思いますね。

そーだい／
確かに。それは僕もすごく思います。よく言われる、「マネージャーが技術を分かったほうがいい」というのも同じで。

新原／
うんうんうんうん。

そーだい／
「めちゃくちゃマネジメントが得意な人が、少しでも技術を分かってくれる」だけでもいいし、「技術はそれなりに得意なプレイヤーの人が、少しでもマネージャー側のことが分かってくる」と、リーダーの人が、すごく仕事がしやすくなる。そういうのは確かに、実際の経験談としてもよくあるなあ、と思うので。「なるほどなあ」と、今、自分の中で言葉になってなかったことが、言葉になって言語化されて、すっと入ってきました。

新原／
あ～、よかった。でも、そーだいさんなんか、まさにそうですよね。強みはありつつ、いくつかのものを掛け算で、戦っている感じがするので。

そーだい／
そうっすね。僕は、あの……器用貧乏なんですよね。データベースの世界だと、「この道30年」とか「40年」の人が実際にいらっしゃって。「歴史を知ってる」って、めちゃくちゃ強みだなと思ったんですよね。

新原／
ほ～～ぉぉ。

そーだい／
こないだ、PostgreSQLのカンファレンスがあったんですけど。石井 達夫さんっていう、PostgreSQLの本当に初期のほうから関わっている日本人のコミッターで、60歳を超えられた方がいらっしゃって。話をしているときに、「PostgreSQLは最初、Lispで書いてあったんだよ」って言われて。

新原／
え～～～っ（笑）そうなんですね。
（※文字起こし人注：アスキーのサイトにこんなページがありました）
★日本PostgreSQLユーザ会主催の「PostgreSQL Conference Japan 2017」をレポート
PostgreSQL「進化」の軌跡――誕生から20年を石井達夫氏が振り返る
http://ascii.jp/elem/000/001/581/1581945/

そーだい／
ビックリじゃないですか。もともとPostgreSQLの前身の部分は、Cで書いてあったらしいんですけど、「Cじゃ普通すぎる」つって、Lispで書き始めたらしくって。

新原／
あっはははは！（笑）

そーだい／
でもLispじゃ、さすがに限界があって、Cに書き直されたらしいんですけど。

新原／
へえええ～～ぇ。

そーだい／
Cのコアの部分のとこ読むと、Lispの時の雰囲気が残ってて、マクロとかがLispっぽい、とかあるらしくって。そういう話とか知ってると、コードに対する理解力が、すごく上がるじゃないですか。

新原／
うんうんうん、そうっすね！

そーだい／
だからやっぱ、そういうとこ強いなあって思うし、そういう人と「ヨーイドン」で、同じ方向性で勝負しても仕方ないなあと思って。なのでまあ、色々な視点を持つのって大事だなあと思っています。それと、投資って、最初の方、そこそこ上手になるまでは、そんなにめちゃくちゃ頑張らなくてもそこそこ上手になるんですけど……ある一定レベルから、どんどんリソースが必要な配分が、上がってくるじゃないですか。

新原／
わかる。

そーだい／
で、僕、そこで結構、心が折れちゃうんですよ。

新原／
っふふふ（笑）。

そーだい／
上手くなれば上手くなるほど、「すごい人」との距離が見えてきて。「あ、この人めちゃくちゃすごい人なんだな」みたいになる。で「あ、オレ10年 投資しても、この人に追いつけないな」みたいなことが見えてきたときに、「他の視点を持つことって大事だな」と思ったんですよね。それの繰り返しで、今、色々なことをやっている、という感じです。

新原／
確かに。そういう人と出会えるのは、コミュニティの良さですね。

そーだい／
あ、そうですね、そうです。

新原／
今、聞いてて思いました。

そーだい／
僕は結構、「コミュニティに育ててもらった」という気持ちがすごく強くて。それはやっぱり、「知識を提供してもらった」というよりは、やっぱり「出会いを提供してもらった」と思っています。
エンジニアの良いところは、年齢も性別も関係なく平等に話ができるところが、すごく良いと思ってて。

新原／
うんうんうんうんうんうん。

そーだい／
例えば先ほど言った、石井達夫さんとかも、だいぶ先輩なんですけど、普通に僕に話しかけてくれるし、僕の質問には普通に全力で答えてくれるし。逆に、例えば弊社だと、他の若い子……20代が多いんですけど……、話をする時に、僕が年上だからって向こうが変な気を使って質問をやめることもないし、僕の質問にも真面目に答えてくれる。

新原／
うんうんうんうんうんうん。

そーだい／
もちろん、そこに性別も関係なくって。例えば、COBOL作った人だって、女性なわけじゃないですか。

新原／
うんうんうんうんうんうん。

そーだい／
まあ、良く言えば実力主義だから。その実力が、コードやアウトプットで分かりやすい業界なので、そういう意味ではすごく縁に恵まれやすいところだなあと思っています。
会いに行く人も選べるわけですよ。今はTwitterやフェイスブックで、ある程度「ここに行けば、こんな人がいる」というのが、見える化されているので、そういう意味では本当に僕はコミュニティに出会いを提供してもらったなあと思います。だから僕、「恩送り」していかなきゃいけないなって思っています。

新原／
そうなんですよね。僕もコミュニティには本当にお世話になっていて。いやホント、「コミュニティとの出会いがあったから今がある」というのは間違いないんですけど。
ただなんか、「どういう風にやっていけばいいんだろうな」というのは、考えるところですね……。

そーだい／
「（正しい）答え」ってないんですよね。

新原／
まあね、もちろんね。

そーだい／
勉強会ブームとかって、ITができて、まだ数十年じゃないですか。だから、世代交代も、厳密にはしていなくって。まだ頑張っている方も、いっぱいいらっしゃいますし。そういう意味ではまだまだ、これからだろうなと思っています。
僕らより上の世代の人って、新しい技術がどんどん出てきて、「テストコードならt_wadaさん」だったりとか、「PostgreSQLだったら この人」みたいな感じで、「早い者勝ち」である反面、最初の先駆者は一生懸命頑張って道を作っていたんですが……。
僕らの世代なんか、ある程度コミュニティで「知の高速道路」が用意されているので、どこを走るかを選びながら、自分にあったコミュニティを探す、みたいな感じなんで。
逆に、僕らよりも今から10年後、20年後の子たちの方が、僕らの世代に整備されていた知の高速道路がもうない、とか、インターネットにある情報が古い、とか、いろんな問題が出てくるかもしれないから、大変かもなあと思ったりします。
逆にいうと、その高速道路の先で詰まっている、つまり「自分が勉強したことは他の人もだいたい知っているから、自分のカラーを出しにくい」みたいなことも、僕らより下の世代の子たちはあるかもなー、って思ったりします。

新原／
あ～～～。

そーだい／
現役の時代が長いじゃないですか。「35歳定年説」とはいうけれども、40歳になっても50歳になっても……例えば新原さんも僕より先輩だけど、現役でコード書かれてますし……あと、なかなか、どかないんですよね、先輩が。

新原／
あっはっは、あははははは（笑）

そーだい／
（笑）なので、その……「ポジションを譲ってあげる」というのも、結構大事だなー、みたいなことは思ったりします。

新原／
ああ～、なるほどね。

そーだい／
僕、PostgreSQLユーザー会の中国支部長という担当を、６年くらいやってたんですけど、そこですごい成長できたんです。それに、すごく楽しかったんですけど……。「東京に出てこよう」と思った大きなきっかけのひとつが、そこのポジションを、誰かに譲らなくちゃいけないと思ったからなんですよね。

新原／
あ～……。あー、なるほどね。

そーだい／
で、譲るためのひとつの大きな動機にもなるし、僕がそこに甘えちゃうから、１回、出なくちゃいけないな、って思ったんです。
ポジションというか、環境が人を育てる、と僕は思っているので、「自分の役割が終わったな」と思ったら、そこに甘えず、（後進に）譲っていくの、大事かなあ、って思っています。
ちなみに僕、今「データベース芸人」みたいな感じですけど、若者でデータベースが好きな子が出てきたら、どんどん その子にスピーカーのチャンスを譲るとか、イベントのところを振るとか、いろんなところで譲っていくって大事だなーと思ってます。

新原／
確かに、それはまあ、分かりますね。まあ、一方、それをずっと楽しみ続ける、というのも、ひとつの方法だなと思うので……。

そーだい／
まあ、確かに。

新原／
うん……。これから何かこう、ちょっとコミュニティに出たりしてやっていこうと思った時、データベースとか割と良いなあと思うところは、「どのアプリケーションでもたいがい絡む」し、プログラミング言語が関係ないので、「横断的に関わる」じゃないですか。

そーだい／
確かに、確かに。

新原／
そういう分野にコミットすると、掛け算が、めちゃめちゃ効きやすいんですよ。

そーだい／
うん、うん。

新原／
僕、似た話だなあと思ったのが……僕、いっときすごく、Vagrant（ベイグラント）を追いかけてる時期があって。

そーだい／
はい。

新原／
で、ブログ書いたり発表したり、本を書いたりしたんですけど。それをやってた時は、普段自分がいるコミュニティ以外からも、お声が掛かることが多くて。これはまた別のスピーカーさんに言われたんですけど「ええもん見つけましたね」って。「え、どういうことですか？」と言ったら、「掛け算が効きやすい。どこの分野にも関わってくるものだから」と。自分が普段いるフィールド外からでも、どんどん出て行けるし、確かに「これは良いな」と。別に、それを狙って追いかけてたわけじゃないんですけど。なんか、面白いなあとは思いましたね。

そーだい／
僕も、Vagrantは確かに新原さんのQiitaとかで、すごく勉強した記憶があるんですけど……。

新原／
ははっ（笑）。

そーだい／
僕は、そういう意味では、……もともとデータベースが好きだったか、というとそれは難しくって。どっちかというと、費用対効果というか。投資したとき、言語なら移り変わりがあるけど、「データベースは中にデータが入っている以上、すぐにはなくならんだろう」っていう気持ちがあって、データベースを最初に選んだんですよね。

新原／
ほおお～ぉぉ。あ、じゃあ割と意識的にそこにいったんです？

そーだい／
そうですね。

新原／
ほおお～～！

そーだい／
最初、セキュリティかデータベースかですごく、悩んだんですけど。セキュリティは、すごくジャンルが広いんですよ。

新原／
はあ、はあはあはあ。

そーだい／
「セキュリティを知るためにはプロトコルを知らないといけない」とか、「レイヤーをいっぱい知らなくちゃいけない」とか「言語の仕様を知らなくちゃいけない」とか、あと「PHPじゃなくてCを知らなくちゃいけない」とか……すごい、果てしない。先が見えないというか、仕事として成り立つまでには、先が長いな、と思ったんですよね。
（一方で）データベースって、古典みたいな本が未だに現役だから、本を読めば、それなりにまず最低限の仕事はできるし、やれる仕事はいっぱいあるので、「最初はデータベースを頑張ろう」って思ったのが、20代前半くらいのときの、きっかけなんですよね。
で、「データベースを頑張ろう」って決めた理由も、初めて行った、広島県福山市っていうところの勉強会で「オープンラボ備後」っていうのがあったんですが、そこに、Linuxカーネルで有名な、ひらさんっていう人が来てて。
（※第１回オープンラボ備後　　https://sites.google.com/site/openlabbingo/home/dai-1kai--opun-rabo-bingo ）
（※平 聡輔さん  http://www.kerneldesign.info/wiki/index.php?%A4%D2%A4%E9 ）
当時、僕は23～24歳くらいなんですけど、その人に飲み会の時に「俺も23歳か24歳の時は、Linuxカーネルで生きていくって決めてたよ」みたいなこと言われて。

新原／
へえぇ～～～。

そーだい／
「あ、じゃあオレもそろそろ決めなきゃ！」みたいな気持ちになったんですよ。

新原／
ははははは（笑）。

そーだい／
（笑）んで、まあ最初にデータベースを選んだ、って感じなんですけど。でも、好きなものって……これ、炎上するから言いにくいんですけど……（笑）

新原／
（笑）

そーだい／
恋愛と一緒で、最初から好きになるケースって少なくて。「仲良くなった人を自然と好きになる」ってことってあるじゃないですか。

新原／
ああ～！まあ、そうですよね。

そーだい／
「幼馴染は小さいときには気にならなかったけど、ずっと一緒にいたから、気がついたら好きになっていた」っていうのと一緒で、データベースも、最初はそういう気持ちで投資したけど、なんか知れば知るほど奥が深いし。仕事で……、あ、データベースって仕事ですぐ使えるんですよね。

新原／
うんうんうん、そうっすね、確かに。

そーだい／
職場にデータベース自体はある。だから、トライアル＆エラーのサイクルも短くて良かったので、それでどんどん好きになっていった、という感じですね。

新原／
へえぇ～～～……。データベースとか、PostgreSQLのコミュニティとかで、若い人とかって、増えてたりするんですか？

そーだい／
そうですねえ。３年に１回くらい若い人が増える、って感じなんで……。平均年齢はどんどん上がっていくんですけど、若い人は一定数いる、って感じですね。

新原／
ふ～～～ん。でも最近だと、それこそ、そーだいさんとかを見て、「あ、ちょっとコミュニティ行こう」っていう人とか出てきてるんじゃないんですか？

そーだい／
出てきてくれてるんですけど、僕より先輩だったりするので……。

新原／
あはははは（笑）。

そーだい／
そもそも僕より若い人に、ちょっとアプローチしなきゃなー、って思ってます。

新原／
ふ～む。

そーだい／
最近、僕が勉強会でヒアリングして分かったことがあって。データベースで困るのって、だいたい20代後半からなんですよ。

新原／
……ほう。

そーだい／
若い人っていうのは分からないし。そもそも、もうあるから、良いか悪いかわかんないじゃないですか、与えられた設計とか、データベースが。
で、ある程度自分で設計できる立場になったりとか、「運用するときに判断を求められる立場」になったときに、しんどいとか、こうすればよかったのか、みたいなのに悩む時期がきて。そのタイミングが、20代後半だったりとか、30代前半だったりするので……。
僕は今、33歳なので、やっと僕と同世代の人と話が合うようになってきた感じです。

新原／
あはははは（笑）。そう考えたら、すごい早いですよね、着目した時期とかが。

そーだい／
そうですね。まあそれは、運が良かったなあと思っています。

<--1時間17分23秒

（そーだい／
続き）
同級生はすごい、Androidとか、スマホアプリ全盛なんですよ。

新原／
あ～～～！まあでも、そっちに目が行きますよね。

そーだい／
で、僕が、Android1.6とか、2.2ぐらいまでは、（プログラムを）書いてたんですよ、実際に。けど、変化が早すぎて。僕、もう23歳で結婚してて、子どもがいたので、それを追いかけるだけのリソースが、持てなかったんですよね。当時は、アプリがどんどん出てくるわ、どんどん出さなきゃいけないな、って危機感に追われて、どんどんアプリ作ってたんですけど。作れば作るほど、運用が……当然ですが、掛け算で増えていくので、「ああ、これは僕には限界だ。得意な人に任せよう」みたいな気持ちになって。それでAndroidをやめて、Webアプリケーションに絞ろう、という気持ちになった感じですね。

新原／
あ～～～、なるほど。

そーだい／
なので、当時は、Objective C とかも、ほぼ C みたいな感じのコード書いてました。

新原／
あははははは（笑）

そーだい／
でも今は、多分もっと若い子は、スマートフォン……。僕の時って、Webアプリケーションって、仕事じゃなくて趣味だったんですよね。

新原／
あ、はあはあはあ。

そーだい／
自分で作って遊んで、で作れるものだったんですけど。僕より若い子に聞くと、「Webアプリケーションは仕事で、スマホが趣味です」って言ってて。もっと若い子だと、「スマホとかWebアプリケーションが仕事で、Unityでゲーム作ってます」とか。

新原／
あ～～～～！はあはあ。

そーだい／
で、思い返してみれば、僕より先輩とかも、DNSとかネットワークとかインターネットとかデータベースが、「遊び」だったんですよね、あの人たちからすると。
そういう人たちが、成熟させていって、仕事にさせて、僕らがその仕事を引き継いでいるので、そういう意味では僕も、ちゃんと仕事になるように育てていくっていうの、大事だなって思っています。ソフトウェアだとか、サービスを。

新原／
んん～～～。うんうん。
確かに、昔学生の頃は、プログラムを書いて、それが仕事になるっていうのは、あんまりピンとこなかったですからね。実際にそういう人がいるのは、知っていたんですが、なんかあんまり現実的な感じがなくて、「特別な人しかなれない」と思ってましたから。

そーだい／
そうなんですよ。僕も、こんなに自分がプログラム書けるようになるとは思わなかったんですよね。
逆に、成長するタイミングって突然訪れるなあ、って自分では思っていて。例えば10代のときに分からなかったことが……。僕、10代でプログラミング挫折した理由が、ポインターだったんですよ。

新原／
ほうほうほう。

そーだい／
C で、構造体とポインターだったんで、「全然理解できん」って思ってたんですけど。
社会人になって、Javaとかやって、オブジェクト志向をやったら構造体は分かったし。
ポインターは……。データベースのfecthの時に、カーソルで移動させるじゃないですか。「あ、これどっかで見たことあるぞ」って気持ちになって。「あ、ポインターって実はカーソルと似てるな」みたいな感じになって。

新原／
あ～、なるほど。はいはいはいはい。

そーだい／
で、それでCを書いてみたら、「あ、なんとなく分かってきた！」みたいな感じで、すごい理解が深まったりとか。

新原／
ふぅ～む。

そーだい／
「回り道って、意外と回り道じゃないんだな」みたいなことは、思ったりしますね。

新原／
あ～、面白いですね。僕はもともと、アセンブラやってたんで、Cの構造体とか、ポインターとかは……。あの、Cのポインターの、記号の使い方とかは、どうかと思いますけど……（笑）。

そーだい／
あはは、なるほど（笑）

新原／
なんか、あれが余計に混乱を招いているような気もしますけど。でも、指し示していること自体は、割と飲み込みやすかったです。
なんか、そーだいさんって……「更に先の概念に１回行って、それから戻ってみると分かる」っていうのは、結構ありますよね。

そーだい／
そうですね。僕、アレなんですよ、「甘やかされた世代」なんで……。

新原／
あはははは（笑）

そーだい／
PHPも、4とかじゃなくて、5の世代なので。メインで使ってるのは5.2と5.3が一番最初からあった世代なので……メモリが抽象化された世代なんですよね。

新原／
うんうんうんうん。

そーだい／
なので、そこをどうやって扱うか、みたいなところとか、他の言語や他のミドルウェアから知る、ってことが結構多かったですし……。TCP/IPとか、HTTPプロトコルとかも、最初は全然分かってないけど、「分からなくてもアプリケーション作れる」っていう世界で、最初は育って。でも、でかいアプリケーションになっていくと、どんどんそういうの考えなきゃいけないっていう……。つまり、完全には抽象化されていなくって、漏れてるところで。漏れてる部分を少しずつ埋めていくと、ある日突然、「あ、なるほど」って理解する日が来るっていうのを繰り返して、成長していった感じですね。
で、データベースって、色々なところのレイヤーとつながっているので、「反復横跳び」みたいに、「他のとこ行って、データベースに戻って、また他のとこ行って、（データベースに）戻って……」の繰り返しで色々なことを学ぶってことが、結構多くて。なので、そういう意味でも、たまたまではあるけど、「データベース選んだのは良かったな」って思います。

新原／

「反復横跳び」って、いいっすね。
そーだい／
ありがとうございます（笑）。

新原／
なるほど。あ～～、でも確かに「横のレイヤーに行って、また戻って来て、っていうのを繰り返す」っていうのは、なんか、しっくりきますね。
そうですよね、そういう低レイヤーのこととか、原理原則的なことって、厳しい人は「それを知ってからじゃないとだめ」とか「それは絶対に知るべき」みたいな意見もあるけど……。僕はどっちかというと、もっと上位の抽象化されたレイヤーから入っていっても全然よくて、それで用が済んでるんなら、それでもいい。困ったときに（低レイヤーに）降りていけばいいんじゃないかなって。そうじゃないと、僕らプログラミングしている人間は、コンピュータの中のトランジスタとかのことも全部知ってないとだめか？って言われると、そんなことはないでしょうから。

そーだい／
そうですよね。おっしゃるとおりですよね。CPUキャッシュとか意識しなくてもいいですし、今なんかもう、世の中クラウドになったから、もっと抽象化されてきてるし。そこは「棲み分け」だと思うんですよね。

新原／
そうっすね～。ただ、下の概念、低レイヤーがなくなるってことは絶対なくて、それを知らないといけないっていう人は絶対必要なんですけど。皆が皆そればっかりやる必要もなくて、そういうのが抽象化されて当たり前の世界で、さらに上のことをやる人も必要とされているので。

そーだい／
そうですね。おっしゃるとおりやと思います。結構、サービスを作る上で、「このサービスが誰向けなのか」「どのレイヤーなのか」っていうのは結構あると思っていて。クラウドを作るとか、PaaSを作る人っていうのはサーバー物理とか、下のレイヤーを考えないといけないと思うんですけど。ユーザーに届けるときに、エンド･ユーザーがスマホユーザーであれば、そこまで考えなくていいってことは当然あるでしょうし。なので、「自分が何を作りたいか」って結構大事かなって思います。

新原／
うんうんうん。確かに。

そーだい／
僕は「誰かの問題を解決したい」んですよね。それは、チームの問題かもしれないし、ユーザーさんの問題かもしれないし、身近な問題かもしれないし、もっと大きな問題かもしれないんですけど。
問題解決するための手段として、プログラミング言語があったり、Softwareがあったり、僕のスキルがある、と思っているんで。「解決するために、誰かがやらなきゃいけないんだけど誰もできないこと」って、たまにあるじゃないですか。

新原／
うんうんうん。

そーだい／
それを、自分が積極的に学ぼうっていう気持ちがあって。そうすると自然と色々、学ばなきゃいけないことが増えた、って感じですね。

新原／
ふ～ん。今、ずっとデータベースのことを、深堀りしてやっていって、「もっと掘っていきたいな」とかっていうの、ないんですか。

そーだい／
僕は……データベースっていっても色々あるじゃないですか。RDBMSが、僕、いま一番力入れてますけど、データストア見て、もっと色々なデータストアのこと知った方がいいと思うんですよね。反復横跳びと同じように。

新原／
あ～～、はいはい。

そーだい／
RDBメソッドは、100あったら７～８割ぐらいは分かっているつもりなんですけど、残りの２割を理解するためにも、他の事を知って……「差分」って、「他」があるから、差分があるわけじゃないですか。

新原／
うんうんうんうん。

そーだい／
立脚点が複数あると、その距離感と自分の立脚点が分かるので、そういう意味では、データストアでいうと、NoSQLだったりとか、分散データベースとかっていうのも、もっと勉強しなきゃいけないな、と思っているし、それが、自分の得意なRDBMSに生きてくると思っています。自分が学んだことをアウトプットすることで、世の中に需要があるなあっていうふうに感じてますね、最近。
……とはいえ、機能について学ぶ気はあまりなくって。例えば「Oracle DBだったらこれでいきます（＝こうすれば、うまくいきます）」とか、めちゃくちゃいっぱいありますけど、それは、それを仕事にしているスペシャリストに任せようかなって思ってます。

新原／
うんうんうんうん。

そーだい／
「SQL Serverじゃないとできない特殊な機能」みたいなのは、僕はあまり深堀りする気はなくって。それは、今はOracleしかできないかもしれないし、SQL Serverしかできないかもしれないけど、もしかしたらいつかはPostgreSQLに入るかもしれないし……。だから「１つのプロダクトにこだわる」ってことは、あまりする気がないって感じですね。１つにこだわっちゃうと、自分の付き合う人も、そこに偏っちゃうじゃないですか。

新原／
まあ、そうですね。

そーだい／
それに、仕事としても僕は結構飽きっぽいので、色々なことをしたいなって思っているんで……。

新原／
なるほど……。例えばPostgreSQLの実装をもっと降りていって、開発に貢献するだの、その周辺のプロダクトを何か作るとか、……色々なアプローチがあると思うんですけど、そういう方向はあんまり……？

そーだい／
周辺のプロダクトは、考えてないわけじゃないんですけど。例えば僕は今、「はてな」っていう会社でサーバー監視の仕組み作ってるから、それとPostgreSQLのモニタリングツール作ったりとかしたいなって思ったりはします。また、前のFuelPHPだとPostgreSQLの対応のコミット出したいとか、考えたりもしたのと一緒で、「何らかの貢献はしたいな」って思っているんですが、それは先ほどの「問題解決をしたい対象にそういうところがあって、その問題を解決することで色々な人が喜ぶのであれば、問題解決していこうかな」って思ってるんですけど。

新原／
うんうんうんうんうん。

そーだい／
「コードを書く」って、ディープワークなんですよね。だから、やりたいことは無限にあるんですけど、取捨選択はしなきゃいけないなー、と思っていて。
最近の僕の興味の対象は、マイグレーションとか、データベースリファクタリングするためのサードパーティみたいな、便利ユーティリティツールみたいなのを作りたいな、という気持ちはあって。

新原／
ほほ～～ぅ。

そーだい／
ただ、僕の悪いところなんですけど、「こうやったらだいたい良いものができそう」「こういうの作れそう」みたいなところで満足してしまって、コードを書かないんですよね。

新原／
（笑）あ～でも、それすごい分かります。そうなんですよ……。

そーだい／
「解決策が見えると急に飽きる」っていうかね。

新原／
そうなんですよ。うんうんうん。

そーだい／
考えるまでは、めちゃくちゃ楽しいんですけど。

新原／
うん。本当は多分それってすごい「入口」で、やり遂げた人との差はめちゃめちゃデカいんですけど。

そーだい／
そうなんですよ。

新原／
ですよね～。そっからやり切るのが、めちゃめちゃ大変なんですけどね。

そーだい／
そうなんですよ。僕も、（自分の）弱いところはそこだなって思っているので。僕、30代の自分の目標は「そーだいさんといえば、コレ」みたいなプロダクトを作ることなんですけど……まだまだって感じです。

新原／
いいっすね、いいっすね。

そーだい／
結局僕、今、他人のふんどしで相撲をとってるのと一緒なので。PostgreSQLを僕が作ったわけじゃないんで。だから、そういうのはちょっと考えていきたいなと思っています。

新原／
うんうんうん。そうなんですよね、その辺がよく考えるところで。やっぱりプログラマーとして、ソフトエンジニアとして、何か自分の代名詞になるようなプロダクトが作りたいなっていう気持ちもありつつ、でも自分が100％それだけをしたいわけでもなくて。それこそ「配分」ですよね。どういう風に配分したほうがいいのかな、っていうのは考えたりしますね。

そーだい／
そうですね。

新原／
ブログ書いたりとか、こうやって話をするのもそうですし、本を書いたりするのもそうですけど、「その時間があったらコード書くべきじゃない？」っていう思いは、やはりありますね。

そーだい／
うんうん。

新原／
それは他の人がどうこう、じゃなくて、自分自身に対して。

そーだい／
そうなんですよね、分かります。新原さんって本出てるじゃないですか。それは、大きなブランドだと思うんですよね。「この人は本を書いたことがある」って。僕はまだ自分の名前が出た本ってのはないですし、自分を代表するプロダクトもないので。スピーカーとして話をしているときも、「僕が考えた さいきょうの理論」とかじゃないわけですよ。世の中で、他の人が書いた論文とかを僕が日本語でしゃべってる、っていうだけなので。そういうところが、自分で……「恥ずかしい」とは思ってないんですけど「もっとカッコイイことできたらな」みたいな憧れがすごくあって。それが逆に、僕が今、成長するための背中を押してくれている。とりあえず30代はそれで頑張ろうかと思っているものの……。

新原／
うんうんうん。

そーだい／
「書いたけど全然だめだった」みたいなことは、当然、世の中にいっぱいあるわけじゃないですか。

新原／
そうですね。

そーだい／
コードは書いてもいきなり流行らないし、Webサービスはうまくいかないことの方が多いんで、そこがすごく、恐怖としてあるんですよね。そういうの、「皆どうやって打ち勝ってるんだろう？」って思って聞くと、打ち勝つ人って、そういうことをそもそも考えてないんですよね。

新原／
だと思いますね。

そーだい／
そこに、すごく大きな壁があるなって思います。

新原／
コミュニティへの還元という意味でも、色々な還元の方法があって。もちろんコードを書くことが一番直接的で分かりやすいんですけど、そうじゃなくても、何かを伝えたり、勉強会をしたり、色々な方法があると思うんですよね。
ただ、（そーだいさんの気持ちは）ほんと分かります。「コードで直接、貢献する」っていうことを、（僕は）全然やってないわけじゃないですけど、とはいえ、色んな活動の時間をすべて「コードを書いての貢献」にあてた方がいいんじゃないかな？っていう思いは、ずっとありますね。

そーだい／
そうなんですよね。パッチは送るんですけど。

新原／
うんうんうんうん、そうですね。プルリク送るとか、そういうレベルですからね。

そーだい／
「できる人は、やっぱすげえな」って思います。

新原／
そう、だからそこもね、「掛け算」が出てきて。コードだけで貢献している人も、それはそれでもちろんすごいんですけど、更にスピーカーとか、外に向けて発信することが上手な人もやっぱりいて。そうなると、もっとすごいですよね。

そーだい／
僕、色々なことやるんですけど、「最強のゼネラリスト」みたいな人がやっぱりいて。何やってもすごい、みたいな人が世の中にはいるから、本当、すごいなって思います。「世界は知れば知るほど広いな」って思うので、そういう意味でもやっぱり飽きない世界だから、エンジニアの世界は面白いなって思います。

新原／
まだまだ、やりたいこともたくさんあるしね。

そーだい／
そうです、そうです。

新原／
確かに、「飽きない」ですね。

そーだい／
先ほどの話で僕、「飽きっぽい」って言ってたんですけど、公務員やってた時期があって。

新原／
うん！？

そーだい／
公務員のときは、すぐ飽きたんですけど、10年やってもエンジニアは飽きないから、すごいなって思います。

新原／
ああ～～、なるほど。それもやっぱり、外の世界を見ているから分かることですよね。

そーだい／
そうですね、はい。公務員のときと比較して……っていうとあれなんですが。
エンジニアの人ってあまり、「他の会社の人だから話さない」とかいう壁を作らずに、国が違っても時差はあっても、普通にTwitterで絡んだりできますし、そういうところも、いいなあって思います。

新原／
あ～、なるほど。

そーだい／
だからこそ僕も、ギブ＆テイクで、「なんで俺ばっかり」みたいな気持ちにならずに、僕もどんどん（自分の持ってる知識を）出していけるし、「なんであんな文化になっているんだろう」って不思議なくらい、良い文化だな、と思いますね。

新原／
ああ～。確かに、改めて言われてみると、そうですね。まあ会社とか、普段自分が属しているところは関係なく、普通に会話したりとか、情報交換したりとか、できますもんね。

そーだい／
そうです。学生時代でいっても、大学が違うとか、部活が違うとか、サークルが違うとかだと、全然話さないっていうのが、僕の周りは多かったんですけど、エンジニアはそんなことないなあって思っていて。
最近、会社で採用の話をしたときに、他社さんとのつながりで、例えばエンジニアだと、コミュニティに行けば何らかのつながりが作れるんですけど、デザイナーとか営業の人ってどこに行けば会えるんだ？みたいな話になって。

新原／
はあ～～～～～、なるほど。

そーだい／
「確かに、どこにいるんだろう」みたいな。どこの会社にもいるはずなんですけど。エンジニアみたいに、気軽にコネクションを作れる場みたいなのって、ないなあと思ったんですよね。

新原／
うんうんうんうん。デザイナーさんのコミュニティも、あるんでしょうけど。なんとなく勝手なイメージだと、セミナーみたいなのが多いような。「教える・教えてもらう」っていうようなのが多い印象がありますね。

そーだい／
確かに。デザイナーってひとくくりに言いますが、Webのデザインとチラシは当然違うし……。

新原／
ああ、そうですね。

そーだい／
でも、ユーザー側は全部ごちゃまぜで「デザイナーだから、できるでしょ」みたいな感じで投げがちなので……

新原／
ふふふ。（笑）

そーだい／
そこは確かに、デザイナーの人は大変だなって思います。

新原／
うんうん。それはアレでしょ、僕らがExcelの質問とかされるのと一緒ですよ。

そーだい／
あ～、確かに。

新原／
「コンピュータ詳しいでしょ」って言われて、「いやいや、そんなの知らないです」っていう。

そーだい／
確かに。「FAX直せるでしょ」とか。

新原／
あっはっはっはっは（爆笑）そうそうそう。コンピュータっていうか、機械やったら何でも得意だと思われるんで。

そーだい／
確かに……。そうですよね、僕いま、自分のこととして表現されると「あ、なるほどな」って気持ちになりました。

新原／
あはははは（笑）まあ……「あるある」ですね。ほんとね。

そーだい／
ああ、確かに。言われたことありますから。うちの奥さんに至っては、パソコン以外でも、スマートフォンでも何でも、「とりあえずあなたに」って。メールアドレスの登録も。

新原／
あはははは（笑）

そーだい／
今のお話を聞いて、僕もデザイナーさんにお話しするときは気を付けよう、って思いました。

新原／
あ～、でもまあそういうことですよ。だからやっぱりね、知らないことはそういう風に見えてしまうんですよね。

そーだい／
うんうん。

新原／
だから、始めの方の話に戻りますが、自分があまり関わってない技術とか、フレームワークとかのことも、外からはそう見えるってことですね。良く分からないところ、目につくところだけ捉えて、あーだこーだっていうのは、不毛だなっていう話ですね。

そーだい／
確かに。いい感じで、（話が）一周回りましたね。

新原／
でしょ！？あはははは（笑）

そーだい／
はい（笑）

新原／
そうですね。で、そろそろ僕の終電がやってくるので、このあたりにしておきましょうかね。
このポッドキャストでは、公式のハッシュタグとして「#phpgenba」というのがありますので、これを付けて、今回の感想とか「こういった話をしてほしい」などツイートしていただければ、参考にしたいので、ぜひ、お願いします。
……ということで、今回のゲストは、そーだいさんでした。そーだいさん、どうも今日はありがとうございました。

そーだい／
ありがとうございました。

<--おわり（1時間37分20秒）