前書き

連載対談「この人と話そう」について

主催者紹介

• 野口 啓之

  • 株式会社きみより 代表取締役として、IT / DX を中心とした何でも屋さんとして顧問を請け負う

  • 一般社団法人全日本ピアノ指導者協会 ( ピティナ ) 本部事務局 元 CTO → 現 IT 顧問

  • ネオプラグマティズムの思考様式をベースとしつつ、歴史学徒として概念史を嗜みつつ、ヨハン・ゴットフリート・ヘルダーの教育論研究を終生のテーマとする

  • 引き続きとぐろ島で荒らしと戦っている日々

対談者紹介

• 小巻 旭洋

  • 株式会社フルーデンス 代表取締役

  • FileMaker 開発者。

  • 最近では、 API 連携や JavaScript 連携、 AWS や GCP を活用した業務の自動化やデータ分析、パフォーマンス改善などのお手伝いをすることが多いです。

  • Angular、 Cloudflare Pages / Workers、 SQLite などの勉強をしています。

現職の紹介とこれまでのキャリア

野口: 本日はよろしくお願いします！　最初に、これまでのキャリア、どうして起業に至ったか、現職でどのようなことをされているか、そのあたりを簡単にご紹介いただけますか？

小巻: よろしくお願いします、株式会社フルーデンスの小巻です。今は、業務委託の開発をおこなっています。 よろしければ GitHub のスポンサーに登録していただけると嬉しいです（笑

野口: ご覧の方、ぜひ！

小巻: それは冗談としまして。そもそものバックグラウンドとしては、昔、会社員時代に FileMaker をいちユーザとして使っていました。就職するまでパソコンに触れたことがなく、そこで初めて Excel や FileMaker に触れることになったのですが、興味を持つようになり、個人でも買って、趣味の一環として色々と作成をしていました。

野口: 完全未経験からだったんですね。

小巻: その後、他の会社に転職しつつも FileMaker を使って業務改善を続けていましたら、周りからの声の影響も受けて、本格的にこれを仕事にしようかと思い至り、独立することにしました。

野口: なるほどですね。その最初の会社は、差し支えなければどのような関係のお仕事でしたか？

小巻: 光通信という会社ですね。

野口: あ、光通信さんですか、はいはい、あの WEB サイトが超シンプルで有名な。

小巻: そこで営業していました。

野口: 光通信さんで FileMaker を使っていたということですが、その後の転職先でもFileMaker を使っていたんですか？

小巻: はい。

野口: へー。それって、転職先を選ぶ際には FileMaker が使われているかどうかっていう視点があったんでしょうか？

小巻: いえ、ないですね。むしろ FileMaker を使って業務効率化をしませんか、っていう提案をしていました。
野口: ああー！　それで実際に説得して導入できるって、すごいですね！　 

小巻: いえいえ。

野口: そして FileMaker を使えることが周囲に認知されるようになったということですよね。どういうきっかけで、会社外で知られるようになったんでしょう？

小巻: 光通信には長く勤めていたこともあり、同僚や様々な部署の方と仕事をする中で FileMaker に詳しい人だということが少しづつ知られていきました。で、辞めた後も、そのあたりのつながりやご縁を通じて、ですね。あとはブログを始めたりしたことでも、少しずつ反応がありました。

野口: コンピュータに関しては全くの未経験から始められているんですよね。師匠的な人はいました？

小巻: いえ、基本的には全部独学ですね。参考書を買ったり、ひたすらトライアル＆エラーで学んでいました。

野口: おおー。私もほぼ同じ途を歩んできたので、ものすごく共感します。

小巻: 遠回りした部分もありますが、アンチパターンを経験することで、今ではより良い実装というものが分かるようになったかなと思っています。

野口: 急がば回れ的なこと、ありますよね。それで独立されて、最初から FileMaker 開発で事業を始めたんですか？

小巻: そうですね。最初は完全独立でなく、副業から始めたんですよ。Claris Partner ( 旧 FileMaker Business Alliance ) の方とのつながりで、週 2, 3 回の仕事をしながら、自分自身での直契約も受けるようなかたちで始めました。

野口: なるほど、最初は副業だったんですね。

小巻: いきなり飛び出してしまうと大変なので、最低限の収入を確保しながら段階的に移行しました。もし仕事が増えなかったら、最悪、戻ればいいや、と。

野口: 撤退基準を持っておくのって、だいじですよね。Claris Partner の方とのお付き合いはどのように始まったんですか？

小巻: 先ほどお話ししたように、ご縁ですね。以前からの知り合いを通じて、紹介いただきました。

野口: いきなり仕事を振ってもらうのって大変だと思いますが、信頼関係を築くために、どのようなアプローチをとられていたんでしょう？

小巻: 紹介だと信頼してもらいやすいというのはありますね。ブログを通じてのお問い合わせや、紹介で案件を受けた後になって、発注してくれた人がまた別の人を紹介してくれる、というかたちで広がったりもしました。独立当初は料金も安く設定していたので、その点も選ばれる一因だったと思います。

野口: なるほど、本当に良いご縁があったんですね。最初から株式会社で始めたんでしょうか？

小巻: 最初は個人事業として始めて、それから法人成りで株式会社にしました。

野口: 個人事業はどのくらいの期間を？

小巻: だいたい 3 年ぐらいですね。

野口: 2014 年ぐらいから個人事業で、2016 年に法人化という流れですね。

小巻: はい。ちなみに、フルーデンスという名前にする前は、ソルブシステムという名前で活動していました。

野口: システムで解決する、的な意味合いでしょうか。今のフルーデンスという名前には、どのような意味が込められているんでしょう？

小巻: 「自由に遊ぶ」という意味で、「フリー」と「ルーデンス」という言葉を掛け合わせたものです。

野口: ホモ・ルーデンスなどで有名なルーデンスから来ていたんですね。

小巻: 他に同じ名称がないことも重要視していました。

野口: なるほど！　ググラビリティ、重要ですよね。唯一無二なお名前感があって、前から好きです。

小巻: ありがとうございます！

野口: 今は、主に FileMaker 開発が中心なのですよね？

小巻: はい、8 割方 FileMaker の仕事ですね。残り 2 割がバックエンドの仕事です。

野口: FileMaker 以外のサーバまわりということですか？

小巻: 具体的な例として EC サイトのデータ集計やレポート作成などがありますね。

野口: データアナリスト的なこともされているんですね！　そういったお仕事については、どのような経路で依頼が来るんですか？　

小巻: もともとその会社が FileMaker を使っていて、私がサポートしていたことがきっかけだったりしますね。徐々に FileMaker 以外のこともやることになって。その会社で EC 事業者向けのサービスを開始し、その新しいサービスのバックエンド部分をお手伝いすることになりました。

今後の展望と WEB アプリ開発

野口: その 8 : 2 の開発ジャンルの割合って変えていきたいなーとか、ありますか？　つまり、今後の展望として、何かお考えはありますか？

小巻: WEB アプリケーションの開発にも興味があって、今後はそちらの方面も増やしていきたいと考えています。ただ、忙しくてなかなか進まないのが現状ですね。

野口: FileMaker と WEB 技術を組み合わせたようなことにも興味があったりしますか？

小巻: そうですね。とはいえ、特に印刷関連の要件など FileMaker が得意とする分野を WEB でどう実現できるか、というのは大変そうですよね。

野口: ああー、そこは難しいですよねー。完全にゼロにするというのは、なかなか。

小巻: はい。

野口: 最近、FileMaker でも WebDirect の強化だったり、FileMaker DataAPI だったり、WEB ブラウザに向けての機能が充実してきていますよね。FileMaker を残しつつどうやっていくか、という観点として、バックエンドが FileMaker でフロントエンドが WEB 技術という組み合わせがひとつあります。小巻さんは、フロントエンドの JS フレームワークとしては Angular を追われていますよね。

小巻: はい。まだまだ素人なので Angular を仕事に、というレベルではないと思っていますが、それができるくらいになることを目指しています。

野口: いつ頃から Angular を知って、触り始めたんですか？

小巻: 2020 年頃ですね。

野口: あれ、もっと前から触られていませんでしたっけ？　……自分の記憶違いかな。

小巻: もっと前だと WEB アプリもモバイルアプリ開発もどちらもやりたいと思っていましたね。Swift もやってみたかったりして。学習リソースをどこに割くのがいいのかな、と悩んでいました。WEB では React の方を Angular よりも先に触っていましたね。

野口: あー、先に React を触られていたんですね。

小巻: Angular 2020 年くらいになってからですね。で、これが一番いいなと思いました。

野口: 私、たしか小巻さんを初めて知ったのが 2017 年頃だったかと記憶していますが、その時はまだ Angular に触れていなかったんですね。あれ、なんだっけな、Google 関連の技術でブログ記事書かれていたはずですが……あの、FileMaker と Gmail の組み合わせとか……

小巻: それは Go ですね。

野口: あ、 Go でした！　記憶違いでした！　そうそう、FileMaker 開発者で Go 触っている方もいるんだなーと物珍しく思って、それで FileMaker カンファレンス ( 現 Claris Engage Japan ) に出展されていた小巻さんに、突撃挨拶に行ったのでした。

小巻: ありましたね（笑

野口: その節は突然すみません、一方的に「ブログ記事読みましたよー！」って突撃したので、キョトンとされてしまった……（笑

小巻: いえいえ。Go は学習コストが低く入りやすかったのが魅力的でしたね。当たり前ではあるんですけれど SDK があるというのが、とても強くて。何でもかんでも FileMaker で開発しようというのは、ちょっと非効率かなと思うところがあり、Go で開発した処理を FileMaker から実行しに行くようにするなど、やっていました。

野口: そういった切り分け、重要ですよね。餅は餅屋というか。

小巻: でも Go はあくまでバックエンドだから、フロントなら JS を学ばざるを得ないということになりまして。

野口: なるほど、それで Angular に行き着いたんですね。私も 2019 年に一年間の育休を取ったとき、お仕事では採用しなかった Angular を触っていたんですよ。当時 CTO をしていた全日本ピアノ指導者協会 ( ピティナ ) では Vue を採用したので、Angular はプライベートで触っておくべきかなと思いまして。

小巻: Angular を採用しなかったというのは何かあるんですか？

野口: ライフサイクルが決まっているんですよね。半年に 1 回、定期的にバージョンアップしていく、というもので。仕事で導入するとしたら、チームで保守運用するにあたり、その速度についていくのが厳しいかなという判断で、技術選定から外しました。

小巻: それはありますよね。Angular を触っておくべきかな、というのは？

野口: 2018 年頃から AltJS としては TypeScript を使おうという風潮が強くなってきていました。で、当時の React や Vue と比べたら Angular が一番相性が良かったように感じていたので、個人的に触ってみました。React は 2015 年頃に触っていたんですが、Angular はしっかり触ったこともなくって。

小巻: なるほどなるほど。

野口: 復職後も、チームに Angular の速度感を押し付けるのは難しいと思い、結局選べませんでした。既に Vue を導入していたため、作り替えるコストを払ってリターンが得られるかというと、それも見込めませんでしたし。

小巻: そうですよね。

野口: 小巻さんは Angular の魅力、他と比べてどうこうというのは何かありますか？

小巻: Angular はベストプラクティスや、開発する上で必要になる情報がドキュメントにちゃんと書いてあり、Angular だけでやりたいことがほとんど実現できる点が良いと思っています。さらに、Angular Material という UI コンポーネントも大好きです。React や Vue のことを深く知らないというのはありますが、おそらく周辺ライブラリを選定する知識や、バージョンの整合性を確認したり、コードやライブラリをアップデートする技術なども必要になると思います。

野口: ありますね。

小巻: やっぱり素の React や Vue をそのまま使うだけでは、少し複雑なアプリケーションには対応しきれないですよね。特にルーティングや状態管理の問題が……

野口: はいはい、そのあたりが鬼門になってくるものですよね。しかも状態管理は、最適と言われるものが変わっていきますし……必ずしもそうした流行りに追従し続けることがヨシとも限りませんが、最近だと Remix が話題になること多いですね。

小巻: そうですね。例えば、A というアプリを作る場合に Remix と Next.js のどちらが向いているかどうかとか、そういった判断は JS や TS に詳しい人ならできると思いますが、これから入門となると、Angularも他のフレームワークも、そこまで学習コストは変わらないんじゃないかと思いました。それだったら、フルスタックで揃っている Angular の方が自分にあっているんじゃないかと。

野口: 選択肢がほとんどないというのが、逆に安心材料になるわけですね。

小巻: そのフルスタックなところが「重い」と言われることもありますが、実際にはそこまで重くないんじゃないかな……と感じています。たしかに Observable や RxJS の概念が少し分かりにくいというのはあるかもしれませんが……でも、それらは全部、丁寧にドキュメント化されています。Google がやってくれているという安心感もありますね。

野口: はい。

小巻: Angular の話をすると、過去の破壊的な変更の話題がでますが、Angular に限らず、フレームワークを使う上では、おおきな変更があることは避けて通れないと思います。アップグレード用のコマンドも用意されています。学ぶ量が多いのは確かですが、でも、他を学ぶのとそんなに変わらないかなと思います。

野口: そうなんですよね。いずれを選んだとしても……

小巻: Google 社内でも Angular は広く使われているでしょうし、急になくなることもないと思います。実際に多くのところで使われていますよね。FileMaker の Admin Console もそうですし、Google 自社の Firebase, GCP や、他だと Lucidchart なども Angular 製なんですよ。

野口: Angular 製のものは以下サイトで確認できますね。

小巻: こうした諸々のことから、Angular をちゃんとやっていけば大丈夫そうだということで、Angular を選びました。

野口: ありがとうございます、よくわかりました。先ほど、リリースサイクルが定期的で早いということに言及しましたが、よく言えば安定的と言えますからね。

小巻: そうなんですよ。

野口: 実際、 Vue が Vue 3 を出してから Nuxt.js が 3 になるまでにはかなり遅れていました。そのせいで Vue 離れが出てしまったくらいです。今振り返れば、「いやー Angular を選んでおけばよかったのかもしれない……？」などと思ってしまう瞬間もあるわけで、どの技術を選んだのが正解だったのか、時にはわからなくなります。

小巻: そうですね。

野口: 軽さ重さでいえば、軽さ重視ならそもそもフルスタックを選ばずに Alpine.js のようなものを jQuery 代わり感覚で入れてしまえばよいわけで。

小巻: はい、Svelte とか。

野口: なのであえてフルスタック系を入れるなら、本体で全部備えてる Angular を選ぶのは理に叶っているのでは、という感覚、よくわかりました。肌感が一致しました。

小巻: よかったです！

WordPress と CMS の選定

野口: だいぶ以前のことですが、在りし日の “twitter” で見かけたことが気になっていまして。「WordPressがツライ」と（笑

小巻: ああー……（笑

野口: 今、自社ブログは WordPress なんですよね？

小巻: はい、その通りです。

野口: 確かもっと前は、別のシステムを使っていませんでしたっけ？

小巻: そうですね、一時期は Gatsby を少し使ってみたのですが、結局 WordPress に戻りました。

野口: あー、そうなんですね。戻られた……にもかかわらず「Wordpressがツライ」と感じられている具体的な点って、どのあたりでしょう？

小巻: 長期的な運用を考えると、WordPress の管理がかなり難しいと感じています。短期的には問題ないと思うんですが。

野口: ほうほう。

小巻: 例えば、WordPress の アップデート って簡単にできますが、それとあわせてテーマやプラグインも一緒にアップデートしなければならないです。それらが古く取り残されると、使えなくなる関数が出たりして、テーマ自体が動かなくなったり、設定画面から編集できなくなることもあります。

野口: ありますよね。

小巻: PHP に明るくないから腰が重いということもあるかもしれませんが、全て自分で管理し続けるのは、非常に大変だと感じています。実際、購入したテーマが更新されずサポートされずになってしまって、塩漬けにせざるを得なくなり……

野口: 先ほどの JS ライブラリと同じような話ですね、テーマを買う選定眼みたいなものが問われてしまう……

小巻: 記事の編集時も自分が普段使っているエディタを使いたいんですよ。CMS のメリットって、複数の人が管理できるようなところだと思いますけれど、一人でやっているとそこに魅力は感じませんし、メリットよりデメリットの方が目立ってきてしまったというところで、「ツライ」に至りました。

野口: そこに対して、今後はどうしようとか考えられていますか？

小巻: 移行についてはかなり悩んでいまして、既存の投稿をどう扱うか……カノニカルの問題もありますから、今のサイトや記事は放置するのも一つかと思っています。本格的な対応をやるのはコストが見合わなそうで……

野口: リターンが見合うかどうかの問題、難しいですよね。

小巻: ですので、そのままにしておいて、別のサイトを SSG ( Static Site Generators ) で立ててしまおうかと。11ty が有力候補です。

野口: 11ty って詳しくないんですけれど、どういう技術スタックなんでしょう？

小巻: すごく簡単なんですよ。コンフィグ設定して、Markdown や HTML を書くだけでテンプレート展開してくれます。多分、学習コストは色々ある SSG ツールの中でもかなり低い方じゃないかと。すごくシンプルで、逆に複雑なことはできないんですけども。

野口: なるほど。

小巻: シンプルにマークダウンを書いて、ただそれを投稿するという点では、だいぶハードル低くできるので、僕は好きです。

野口: これをローカル環境にインストールしておいて、結果としては手元に HTML が出力されるわけですよね。それをデプロイするのはどちらに？

小巻: GitHub のリポジトリを通じて、Cloudflare Pages ですね。ビルドの指定などは Cloudflare Pages 側で設定できるので、シンプルに push だけすればデプロイできます。

野口: あー、Cloudflare Pages いいですよね。弊社サイトも使ってますし、他に構築する時も何かと選んでます。もう離れられなくなった（笑　GitHub Actions の設定すら要らないですからね。

小巻: 体験良くてよく使ってます。

野口: Cloudflare の進化、すごいですよね。DNS の管理も、一昔前は Google Cloud DNS を使ってたんですけど、もう全部 Cloudflare DNS に移しました。

小巻: 私も全部移しましたよ。

野口: 脇道に逸れちゃいますけれど、アレ、最初 1 回ハマっちゃいまして。Cloudflare DNS って、デフォルトだとプロキシ設定にチェックが入っていて。

小巻: はいはい。

野口: シンプルに DNS だけっていうのが、あのチェックを外さないといけないことに気づいていなくてですね、飛ばした先の nginx 側で、どういうわけか https 通信がなんかおかしなことになってんだけど……っていうのに当たりました……

小巻: ありますね、確かに。

野口: ただまあ、そこを一度踏んでしまっておけば、それ以外はすごくシンプルだし、GUI としても軽いし、便利で。いやもう、元々エッジサービスをやっていたところがこんなに幅広く手を広げられて、いろいろされて、すごいなー、って。

小巻: すごいですよね、僕も大好きですね。

野口: 話を戻しまして……いやー、私も実は、この対談の記事をどこにデプロイしようかなって悩んだという経緯がありまして。そもそもオウンドメディアでやるかどうしようか、というところからではありましたが……

小巻: そうだったんですね。

野口: オウンドメディアでやるにしても WordPress  なのか、ヘッドレス CMS なのか……ただ後者で、ローカル環境を構築するということになると、端末依存になっちゃうわけで、「別端末にも同じようにビルド環境を作っておかなきゃいけないのか……？　なんかそこに依存されちゃうのもなー……」とか思いまして。

小巻: はいはい。

野口: それとは別のコンテクストですが、今後どこまで SEO 対策みたいなことが有効になってくるのかな、という問題もありまして。今、ただでさえ Google の検索結果だとか広告だとかの品質が落ちてるという話題を目にする機会が多くなりましたよね。なんというか、Google そのものが大丈夫なんだろうか……？　みたいな。

小巻: ありますよね。

野口: 検索エンジンの地位。ただでさえ若い人は、「検索しよう」ってなった時に、その検索したいもの・得たいものに応じて検索先を選ぶ。口コミだったら Twitter / X を、画像メインなら Instagram を、動画見たかったら TikTok を、っていう。そこに加えてさらに、LLM の台頭で、チャット系のアシスタントツールも入ってき始めたわけです。こうなると、従来ほどには SEO の重要性は高くないだろうと。

小巻: はい。

野口: もちろん、一定程度は重要性が担保され続けるとは思うんですけれども、じゃあ、そのサイトが何ページ目の何番目に表示されてるか、みたいなことについては、さほど重要でもなくなるだろうなぁ、と。つまり、「ドメインパワーを得る」みたいなのは、昔ほどそんなに、なんていうか、言うほど重要じゃないなって思いまして。それで最終的には note という、文字プラットフォームに乗っかろうという選択肢をとったんですよ。note に掲載することで、note 内集客というものもできますし。

小巻: たしかに。note は note で一つの SNS みたいなものになっていますよね。

野口: 小巻さんはこのあたりどのように考えられていますか？

小巻: 多分、効率面だけでいったら note や はてなブログ などの方がいいと思いますよ、やっぱり。設定とか学習に時間を割いてる時点で、「何やってんだ」っていう話だと思うんですよ。

野口: まあまあ……（笑

小巻: そもそも自分の限られた時間をどこに使うんだっていうことですよね。環境構築する時間で記事書いた方がよいのかもしれない。でも、構築するところそのものだって楽しい、っていう一面もあると思ってるんですね。そういう回り道も楽しんでる、みたいな。

野口: ああー、それはたしかに。環境構築を通じた学習効果が得られるというのもあるわけですね。

小巻: おっしゃる通りです。実際の仕事の際に、そこで学んだことが役に立つことって、多々ありますよね。どの経験がどのような関係性を持って結びついてくるか分かりませんから。なので、私の場合は好んでわざと遠回りしているところもある気がします。

野口: すごくよくわかります。私もだいたい仕事で使う・導入する技術って、一度はプライベートで使うようにしてるんですよ。どこの何とも知らないようなものを、いきなり実戦投入できないですよね。自分の肌感覚として分かっておかないとならない。かといって業務時間使うのもなっていうところで……

小巻: はい、ですので、普通の人は note がいいと思いますね。

野口: 普通の人は note で間に合うし、なんなら多分、普通の人って WordPress の運用でも、小巻さんが懸念されていたようなことって気にされないんですよね。

小巻: そうそう。

野口: 小巻さんのように真面目な IT エンジニアほど WordPress って長期運用するの大変だな、って思ってしまいがちで……むしろ普通の人は、放置して、セキュリティホールガバガバのものをたくさん溢れさせてしまう……で、そのことに無自覚だ、という感じなんじゃないかと思います。「普通の人」に失礼な評かもしれませんが、だって、詳しくないから仕方ないわけですよね、そこは。「常識感」が違いますから。

小巻: そうですよね。

野口: 「常識感」って時代や層によって変わって当然ですから。例えば 1960 ～ 70 年代あたり、電車の中がタバコの煙でモクモクして大変なことになっていましたとか、今からしたら「ありえないだろそれ」みたいな状態だったわけですけれど、当時はそれが当たり前だったんですよね。今、多くの WordPress が濫立しては放置されていく……っていうことに、特に疑問を持たない人が多いというのが、なんか重なるなと思いました。

小巻: 確かに。……ちょっと話がズレますけれど、野口さんのサイトって、どういう構成なんですか？

野口: 弊社サイトは、もうシンプルに 1 枚のペライチな HTML です。それを GitHub に push → プルリクエスト → マージ して、Cloudflare Pages へデプロイという流れですね。ビルド系のツールも一切手元に入れてないです。

小巻: ツールは使わず、ひたすらシンプルな感じなんですね。楽ですよね。

野口: はい、これまでの経験で多くの JS / CSS フレームワークを通ってきたんですけれど、結局、コーポレートサイトくらいなら、一番軽量でコントローラブルなのは素の状態のものだなーって思うに至りました。

小巻: そうそう、わかります。普通に CSS を書けばいいじゃん、って話ですよね。

野口: たとえばユーティリティファーストだと Tailwind CSS があるじゃないですか。

野口: 割と出始めの頃、2018 年くらいにモックアップで使ってみたんですけれど、実はそのユーティリティファーストでやろうっていうのは、Tailwind が流行り始める前から既に自分でもやっていまして。2017 年ですね。

小巻: 自分で作ってたんですね、それに近しいものを。

野口: はい、リポジトリでは `semantic` と名付けていますけれど、まあユーティリティですね（笑　`font-size-1` とか、そういう Class をたくさん定義して、それを HTML 側へ割り当てていく、と。これを作ったきっかけとしては、2013 年くらいから Bootstrap とか、当時色々あった Material 系の CSS フレームワークをいくつか使ったことによる悪い体験からです。自由度が本当に低くて、結局、デザイナー側からのリクエストに対してフレームワークを無理矢理にカスタマイズしていかないとならなくなってしまう、っていうのが、なんかもうツラすぎまして。で、ビルド時の最適化ツールとか入れないと、使ってない CSS 定義が山ほどあるのに読み込まなきゃいけないから、重いんですよね。

小巻: うんうん。

野口: 当時、CI/CD が今ほどには環境として整っていなかったというのもありましたし。色々積み重なって、「じゃあもう、最低限必要な定義だけ自分で用意して割り当てればいい」と。なんかアレコレと共通化を必死に頑張ってやっても、必ず後から要件として例外が出てくることによって、破綻してしまうんですよね。

小巻: はいはいはいはい。

野口: 「ここだけはこうしたい」「じゃあこの共通化してたこれ、崩さなきゃいけないじゃん」みたいなことで。それじゃあ最初から、割り当てる要素をマイクロ的に分割しておいて、なんかプラモデルとかレゴとか組み立てるかのように、「じゃあこれが必要になったらこの Class を追加すればいいね」「いらなくなったら消せばいいね」っていう風にした方が、よっぽど楽じゃん、って思ったわけです。

小巻: なるほど。

野口: そうしたら世の中的にも Tailwind が出てきて、「あ、やっぱりユーティリティファーストのニーズがあるんだなー」と納得しました。でも、Tailwind は Tailwind で、そこのルールに従わなきゃいけなくなりますし、そこへの学習コストがかかります。Tailwind 自体の ver.up にも追従しなくてはならない。それなら、全部自作でいいじゃん、と。

小巻: まあ、そうなりますよね。

野口: そのあたりが 2018 年に落ち着いた結論でしたね。

小巻: 結構早くからやられていたんですね。ルール作りをして、社内で共通認識にして。

野口: そうですね、社内でシンプルに作ってしまって。

小巻: 素晴らしい。

野口: なので、そこで培った思想を今でも引き継いで、弊社サイトにも適用しています。Speed Insight とか Lighthouse とかで、サードパーティーのものを読んでると、それだけでスコア落ちちゃったりしますし。

小巻: 遅延しますもんね。Large JS とか、使われてないのあるから削減しろよ、みたいな。いやいや、Google のアナリティクス用の JS ですよ、って思いますけれど（笑

野口: ありますね（笑

小巻: じゃあ野口さんのスタンスとして、そういう背景から、なるべくシンプルかつ通信量も少なく最低限のもので、ちゃんと動くように、っていう感じなんですね。

野口: そうですね。しかもその流れが LLM 、まあ ChatGPT が出てきたことで、今後ますます加速するんじゃないかなーという気はしています。シンプルなコードを一つ放り込んじゃうだけで、「ここをしたいんだけれど」「じゃあこうしてください」っていうやり取りをしやすいんですよね。ソースがあちこちにいろいろと分割してると、構造そのものの学習に一手間かかったりします。一方で 1 枚のペラ、せいぜい CSS と JS と HTML それぞれで 3 つのファイルに分かれてるだけで、あとは全部ページ内遷移とかでうまくコントロールされている方が、LLM 時代の静的サイトとしてはいいんじゃないかなー、っていうふうに思ってます。どうしてもマルチページ構成にする理由があるなら、少し事情も変わりますが。

小巻: 確かにそうですよね。それこそ Tailwind 使うなら、LLM 側が学習理解してくれていないといけませんし、ビルドもしなきゃいけないわけですもんね。

野口: もちろん、静的 WEB ページっていうのと、インタラクションが要される WEB アプリケーションていうのとでは、もう全然別モノですから、後者を作るってなったら、そんなシンプルな構成ってなかなか難しいわけですけれど。とはいえ WEB アプリって一口に言っても、複雑さにはグラデーションもありますからね。

小巻: そうですね。

野口: もちろん、先ほどの話にもあったような、学習効果を見込もうというなら別ですよ。若い人に勉強目的で、「まあいいから自分でメンテナンスして古いものをアップグレードしていくっていう、維持コストを払うっていう経験をしてみなよ」みたいなことであれば、複雑な構成をとってみるのもアリだと思います。

小巻: この話の延長線上でいうと、Vercel の CEO なんかがよくツイートをしている v0.dev というものがあって、これがどんどん使われるようになっていくというのが、近い感じがしますね。

野口: あー、はい、これですね、話題になりますね。

小巻: 簡単なイメージを渡すと HTML、 CSS が返って来るという……。やっぱり CSS って、自分一人で書くのは難しいという問題がありますよね。でも、こうしてサポートしてくれるツールがどんどん出てくるので、それなら全然アリだな、って思えます。

野口: ですよね。

UI のシンプル化と AI 活用

野口: 2010 年代って、まだ FLASH でリッチな WEB サイトを作ろうぜっていう感覚を、引きずりすぎたんじゃないかなーと思うんですよ。インタラクションを豊富にして、アニメーションも派手派手にしていこうというのが FLASH 全盛時代としてありましたよね。

小巻: ありましたね。

野口: いまだにこう、ただのコーポレートサイトでも、パララックスを採り入れて各要素がゆっくり表示されるのって、あるじゃないですか。

小巻: はいはい。

野口: あれは本当にユーザーが求めているんだろうか？　単なる自己満足に過ぎないのではないか？　という見つめ直しが必要なのではないかと思う場面が、本当にたくさんあって……

小巻: そうですね、そうなんですよ。

野口: どんどんファスト化してる世の中なので、「なんかもういいから早く見せて」って思われることの方が多いんじゃないかと。

小巻: ですね。

野口: ユーザが見たいと思っているものを、シンプルに見せるだけ、みたいなこと。それこそ先ほども挙げた光通信の WEB サイトとか良い例だと思ってます。

小巻: ああ、そうそう、話題になりましたよね。

野口: まあ、あれが行き過ぎだとしても、AI 側がこんな感じでいいんじゃないですか、って提案しれくれるような一定程度の質が担保されたシンプルなページさえ用意できれば、もう維持コストもそんなにかからないですし、それで十分なんじゃないかなって思うんですよね。

小巻: 確かに。

野口: WEB やブラウザの仕様も日々変わるし、何よりユーザ側の利用デバイスが変化し続けているから、フロントエンドって終わりがない、みたいな感じになっていたところもあるんですけれど、それなりに落ち着いてきましたよね。フォルダブルデバイスはまだありそうですが、多分、次に行くのって AR グラスでの UI になりますよね。グラスに投影されるブラウザ表示。

小巻: あー、なるほど、はい。

野口: で、そこに行き着いて進化したら……もう終着点なんじゃないかな、という感じはしますが……

小巻: 確かにね、どういう UI で使われるかってところですよね。AR での UI ってどういうのが考えられますか？

野口: その昔、ウィジェットをデスクトップにインストールしているのが当たり前みたいな時代があったじゃないですか。時計があったり、オーディオプレイヤーがあったり、って。ああいうウィジェット単位で、色々な機能・情報が分割されて表示されるようになるのかなー、って思っています。

小巻: なるほどなるほど。そこらへん、野口さんの方が考えられている部分が多そうですよね。僕は「なるほど」って思って聴いていることが多いんですけれど、たとえば落合陽一さんの話を聴いてると、「ぶっ飛んでんなー」って思うんですよね。

野口: もう現実が SF に足突っ込んでいる状況です。

小巻: AR グラスでいうと UI がコマンドライン的に言語そのものになっていくというか、たとえばグラス越しに ChatGPT の答えが表示されるような、新しいインターフェースがどんどん出てきたりするのかもしれないですね。Apple の Vision Pro も出てきましたし。WEB サイトが直接的には見られなくなって、情報の源泉としての役割に変わっていくようになると、我々の開発の在り方も大きく変わりますよね。

野口: そうなんですよ。私もちょっと試みの一つとして、この対談については GitHub に編集履歴を残しながら note に公開していっていますが、それに加えて、一つ一つの発言をエンドポイントとして取り出せるようにしようかなーって思っているんですよ。

小巻: おお。

野口: たとえばスプレッドシートに発言一つ一つを一行ずつ分けて格納しておきます。それで、「こんな発言を取り出したいです」っていうのを GET でパラメータつけて渡された時に「一覧からこんな発言が取り出せました」っていうのを JSON で返してあげる、みたいな。

小巻: はいはい。

野口: そういう新しい記事データの持ち方、記事の構造化みたいなことをちょっと考えています。こういうようなことで、情報がどんどん細切れになっていく、マイクロ化されていくというのが、ゆくゆく求められてくるんだろうなぁと思っていまして、その実験ですね。

小巻: なるほどなるほど。

野口: 今って、例えば誰かの名言を引用したいとか、誰かの言葉をそのまま引用したいとかってなった時に、どうするかというと、手動でどこかしらか探してはコピペするしか、選択肢がないじゃないですか。HTML ページを開いて、「ここだなー」って目視で確認して、コピペするという引用方法。これが、特定のパラメータを渡して拾ってこられるようになるとよいのではと思っています。

小巻: それにちょっと近いかなって思ったのが、Rebuild.fm のトランスクリプト検索機能ですね。Podcast の音声だけど、そこを検索できるっていう機能が実装されていて。

野口: 全文検索ができるんですね。

小巻: 目的こそちょっと違えど、指向性が同じで面白いです。こういうふうに色んなインターフェースから呼び出せるような API ができていれば、GPTs に組み込めるようになるんですよね。

野口: そうですそうです。個々人でカスタマイズした GPTs を、今後どれだけ多くの人が触れるようになっていくかっていうのは、OpenAI がどれだけ頑張ってユーザを増やせるか、それからどれぐらい無料ユーザにまで利用可能範囲を広げられるのか、というところにかかってきますね。

小巻: そうですよね。

野口: AI に関しては後編記事でもっと本格的に触れることになっていきますが、少し先取り的にお話ししましょう。小巻さんは、業務として AI に関することってありますか？　どれくらい日々の仕事の中で活用できているか、とか……

小巻: 仕事としては、AI に関連する何かっていうのは特にないですね。個人的なところで、関数の名付けについて訊いてみているくらいで……まだ、あまり活用できてないと思います。プログラミングに関しては、すぐにドキュメントを見に行ってしまうんですよ。もう少し ChatGPT に任せた方がいいのかなと思いつつ、でも、自分で確認するというプロセス自体に、価値や意味があって欲しいかなと思っています。経験を積むことで、学びを得て、次からはもっと早くできるように、精度よくできるようになっていくものである、と。

野口: 野球でたとえるなら、素振りをしているということで、これがそのうちヒットを飛ばすための基礎練習になっているんだ、という感じですよね。

小巻: はい、そうですね、そうあってほしいです。

野口: そこが難しいところだなと感じているんですよ。要はその、自分の力だけ、自分の身体感覚だけでホームランを打てるようになる、ということを突き詰めていくというスポーツ的な路線がありますよね、プログラミングにおいて。

小巻: はい。

野口: 野球より、もう少し別の喩えの方が分かりやすいかな……陸上競技でいきます。自分の足だけで、短距離走の最高記録を出そうとがんばろうという競技ですよね。それをやっているところに、自転車に乗り出して「俺の方が早いぜー」っていう人が出てきちゃったら、破綻するわけじゃないですか。

小巻: あー、そうですね。

野口: ただ早くたどり着く、っていう目的であれば、当然自転車を使うべきです。それと同じで AI ツールを使った方がプログラミングの目的そのものは達成しやすくなりますね。

小巻: そうですね、何か目の前の目的に対して素早く解決したいっていうのが一番にあるわけですけど、ただそれだけじゃなくて、その過程で色々とあっちこっち調べ、学びとして得たい、っていうのが、自分の中に暗黙的にあるのかもしれないですね。とはいえ、もう少し活用した方が良いのだろうなとは思っています。

後編記事

• リンク予定

後書き

野口です。ここまでお読みいただきありがとうございました。

本対談企画、初の前後編分割になります！
（初の、といってもまだ始まったばかりなのですが……）
前回の小泉さんとの記事も長かったのですが、今回の小巻さんとの記事はそれよりも長くなるかもしれない予想が立ったので、分割しました。
今後とも分割記事が出てくるかと思いますがご容赦ください。

小巻さんとは FileMaker を接点としつつ、この前編ではほとんど FileMaker そのものの話題に触れていないというのが、面白いですね。
それもこれも、お互いが FileMaker ＋ 別技術の組み合わせ、という方面において強みを持っているタイプだからかもしれません。

後編においても、最後の方まで FileMaker の話題は出ずに、引き続き AI とヒトの知性といった話から、クラウドサービス、プロジェクトマネジメントの話などが展開されていきます。
ぜひ後編記事の方もご覧いただけると幸いです！

記録

• 対談日

  • 2024/01/19

GitHub 上でのファイル

https://github.com/Kimi-Yori/TalkWithThisPerson/blob/main/articles/0005-1.md