前書き

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

前編記事

• 本記事は後編です。前編は以下の記事です。

主催者紹介

• 野口 啓之

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

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

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

  • とぐろ島の神髄（表）をクリアした後、鑑定師の腕輪を拾えず泣く日々だったところ、ようやく拾えた！😆

対談者紹介

• 小巻 旭洋

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

  • FileMaker 開発者。

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

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

「自分の考え」なんて在るのか

小巻: 自分で何かを考えてアウトプットするプロセス、たとえばコードを書くときに「これってどうなんだろう？」と思う瞬間があると思います。そういうとき、壁打ち相手が AI であってもいた方が生産性が上がるのかな、とか……一方で「自分で考える」ことの意義と言いますか……このあたりについてどう思いますか？

野口: 「自分で考える」って、難しい問いですよね。そもそも「自分自身」をどう捉えるか、から始まってしまうんじゃないかと思いますが……

小巻: 哲学的な。

野口: 直接的な答えにはならないかもしれませんが、そうですね……。周囲から何も言われない状態で、つまり刺激ゼロで何かを考えるというのは、結構難しいことだと思っています。たとえば、今も、こうして小巻さんとの対話があるからこそ、私の今のこの発言は生まれています。一人だったら、こんなこと思ってるかどうかも分かりません（笑

小巻: なるほど。

野口: 人の脳って常に全力で機能しているわけじゃないですし、様々な外的要因や状況が絡み合って、そこで思考というものは発露されていくものだと考えています。たとえば暑さ寒さやお腹の空き具合など、快／不快の状態の差異にかかわりなく同じ思考ができるというのは、よほどの修業を積まないと無理じゃないでしょうか。

小巻: うんうん。

野口: このように捉えた時、「今、私が 100% 考えてること、これが私の考えなんだ」というものの純粋さ・信憑性について、疑問が残るわけですよ。

小巻: 自分の考えだと思っていることだって、そもそも「それ本で読んだことでしょ」っていうこともありますよね。色々な体験を通じて得たり、誰かの真似をして得たりとか。それらがソースになっているとすると、「じゃあ、それは実のところ誰の考え？」みたいな問いに行き着きますね。

野口: はい。学習の積み重ね、色々なことの「砂粒一つ一つ」の積み重ねによって、自分というものが成り立っています。今、日本語で物事を考えて、日本語を話しているという事実ひとつとっても、日本語という「フレームワーク」の中に閉じ込められちゃっていますから。

小巻: はいはい。

野口: 英語話者、アラビア語話者とは、言語のフレームワークも違ければ、生活文化風習のフレームワークも違う、宗教のフレームワークも違う。というところで、私の信念としては、「ピュアな私 100%」なんて、そんなもんないよ、っていうのがあるんですよ。

小巻: なるほど。

野口: じゃあそこに新しく AI が入ってきました、といったって、なんかこの観点においては大した変化もないのではないかと。ヒトとであろうが AI とであろうが、誰かとやり取りをすることによって、自分がちょっとずつぐにゃぐにゃとスライムのように変形しながらアウトプットしていることには変わりないわけで。

小巻: 確かにそうですね。

野口: AI って、別に自己と対立するものでもなく、それすらも数多くある自分を構成する一要素に過ぎないのかなと思いました。……いやあ、ちょっとその、小巻さんの問いに対してストレートに答えられていないですね。

小巻: いやいや、この答えってすごく難しいですし、「これだ」っていうものを持ってる人もいないと思いますし。なかなか……そうですね……。「今の自分は何なんだ」という哲学的な問いになりますね。「今、自分はどうしてそのように選んだんだろう？」みたいなこと。多分、答えはなくて、過去の積み重ねで今になっていて、自分の言葉として発しているけど、それだけじゃない。

野口: はい。

小巻: 失敗から学んだこととか、人の話を聞いたこともある。難しいですね。

野口: 人間の身体性とか、どこまでが自分なのか、みたいなことを考える時に、留意しないといけないことってたくさんあります。今だって、野口と小巻さんとは、何の補助もなく「生」の私がむき出しになってコミュニケーションしてるわけじゃないですよね。

小巻: そうですよね。

野口: まず、我々はこのインターネット空間を通じて、この Google Meet でやり取りしてる、っていうのもあります。そこはすっ飛ばして、仮にリアルに会っていたとしても、私が小巻さんを見るためには、まずメガネを通してますし、水晶体だって通してます。

小巻: はい。

野口: 現象そのものとしての小巻さんというものを知覚するには、脳にダイレクトに信号を送らなきゃいけないと思うんですけど、そんなことできないじゃないですか。そもそも信号に還元している時点で、っていうのもありますし……。だから、やり取りするには、必ずいろんなインターフェースを、いろんなフィルターを経るしかない。

小巻: はいはいはい。

野口: そういう中で、AI を特別視する必要って、別にないんじゃないかなと思ってます。

小巻: 確かに確かに。そうですね。なんなら、有益なら使った方がいいし、有益に使える要所要所で使えばいいじゃん、っていう感じですよね。

野口: はい。私、根本がとにかくプラグマティスト、要は実用主義者で、「目的に対して便利ならなんでもいいじゃん」という考えでして。もちろん、一定の倫理ブレーキはあるわけですけれども、倫理ブレーキというものすらも、結局のところは「それやったらアウト」という、ルールの中で中長期的に不利益を被るからに過ぎないところがあるものだと思っています。

小巻: はいはい、なるほどなるほど。いやでも、AI に対する姿勢としては素晴らしいですよね、そうあるべきというか。

ChatGPT をプログラミングに活用するならどこから？

野口: お話伺っていると、小巻さんって、すごく自己成長意欲というか、もっともっと成長していきたいっていう姿勢が強い方ですよね。私もわりとそういうタイプで、とにかく「昨日の自分」より「今日の自分」の方が、より良いものになっていたいと思うんですよ。

小巻: はいはいはい、すごくわかります。

野口: 昨日の自分にナメられたくない、みたいな（笑　なので、「AI を使っている自分」になることで、「使っていない頃の自分」よりも、変容して前に進めるようになっていけるかな、と思います。で、「使えるようになってから、使わない」っていう選択をするのと、「最初から使わない」っていう選択をするのとでは、同じ選択でも質的に違うかなと考えています。

小巻: それはそうですよね。引き出しとして持つことができてない。そもそも引き出しとしてないのか、引き出しとしてあるけど使わないのか、の違いですよね。

野口: はい。

小巻: 仮に ChatGPT を何か仕事に活用しようという点において、プログラマー的な要素としては、どういうところからやるとよさそうというのは、何かありますか？

野口: 一番手っ取り早く使えるのが、リファクタリングの依頼、コードレビューかなと思います。

小巻: はいはい。

野口: 例えば、すごく雑に書いちゃってから、「これ、適切に関数分割してもらえますか」と。

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

野口: ChatGPT にお願いするときって、一般的には役割を規定してあげると質の良いアウトプットが来やすくなるんですよ。なので、「あなたは CTO です」と規定してあげてから、「保守・運用の観点から、このコードをレビューしてください」「その上で、リファクタリングすべき箇所があれば実施してください」とお願いするのが、便利な使い方です。もちろん、その際のコードは、秘匿されるべきものだとダメですし、シークレットキーなどが含まれていたらマスキングしてあげてください。

小巻: 一人で、コード書いて ChatGPT にレビューしてもらえるというわけですね。

野口: そうなんです。

小巻: これ、すごく学習になりますね。自分にない発想が得られたり。

野口: あとは相手から出してもらったものに対しては、こちらでもレビューするんですよ。「あー、なるほど、こういう風に書いてきたのか」「でも、ここ、そうじゃなくて、こうなんじゃないの？」って。「ここ、こうだから、もうちょっとこういうコードにして」って、さらに投げ返すんですよ。そうすると、それに応じたものをさらに出してきてくれたりするんです。

小巻: あー、なるほど。

野口: そういうやり取りを繰り返していると、「あー確かに、この関数、ここでこういう風に分けるのもアリか」とか、「へー、ここでこのメソッド使えるんだ」とか、そもそも「こんなメソッドあったんだー」とか、そういうような新しい気づきっていうのもありますね。

小巻: はいはい。

野口: なんか一人でコードを書いてると、ちょっと退屈になってくる瞬間ってあるじゃないですか。

小巻: ありますね。

野口: そういう時に、なんか AI がいるというよりは、ちょっと指向性が変に特化した尖った後輩がいてくれる、みたいな感じで。メンタルケアをしなくてもいい後輩がいる、っていう（笑

小巻: なるほどなるほど。確かに。FileMaker で使うにはまだ難しいところではありますけど、一般的なプログラミングにおいては確かに良さそうですね。趣味でやってるプロジェクトのちょっとしたリファクタリングとか、早速やってみよう。

野口: FileMaker で活用するなら、今だと設計とかモデリングの方ですかね。「こういう用途のアプリケーションを作りたいんです。テーブル設計をお願いします」「それぞれのテーブルにおいて必要となりそうなフィールドと、あとはプライマリーキー、外部キーの確認をお願いします」みたいな感じで投げちゃったら、ザザザーッと出してくれますね。

小巻: はい。

野口 で、それをですね、「ER 図として起こしたいので、Mermaid 書式で出力してください」ってお願いして出力してもらったものを、ダイアグラム系の GUI ツールにインポートする。

小巻: なるほど、そうすると描画までできるのか。そうか、データベース設計ねー。

野口: あとは Google Colab で実行しやすいようなコードブロックごとの Python コードを出力してもらって、ちょっとしたスクリプティング処理のお手伝いなんかも、便利です。

小巻: なるほど、テストデータの生成なんかもやりやすそうですね。

野口: そうですね、Colab を使うといろんなところに連携してテスト実行するというのもやりやすかったりします。なので、最近は FileMaker Data API との通信確認なんかも Colab でやることが多くなりました。

FileMaker Data API

小巻: FileMaker Data API って、どういう使い方がケースとして考えられますかね？

野口: 私が今関わっているプロジェクトでは、Google BigQuery にデータを渡すためという用途がありますね。

小巻: あー、なるほど。

野口: 今までだったら、csv に 1 回エクスポートしたものを、インポートし直すというかたちでしたけれど、それって処理がシームレスでシーケンシャルにならないじゃないですか。なんていうか、「この時間にはこれが出来上がってるから、この時間にはきっと取り込めるはずだよ」みたいな、予測ベースになってしまいがちですよね。

小巻: はいはいはい。

野口: FileMaker Data API を実行する環境として、例えば GCP なら Cloud Functions なんかを採用して。

小巻: はいはい、AWS だと Lambda ですね。

野口: ですね。それで FileMaker Data API から取り出した JSON データを、SQL 実行により BigQuery へ Upsert させる、といった処理です。

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

野口: それがデータ転送用途で、他にはフロントを Nuxt にしてデータソースとして FileMaker Data API を指定したという用例もあります。

小巻: それは商用リリースされているものですか？

野口: 社内用ですね。例えばですが、FileMaker で名刺管理をしているとしましょう。で、Android デバイスでそれを確認したいというニーズがあった場合、WebDirect だとちょっとブラウザセッションの管理とか色々面倒なので、ライトな使い方として採用してみました。

小巻: なるほどなるほど、そういう使い方、良いですね。

野口: もし表に出すかたちで商用リリースするとしたら、直接 FileMaker Data API を叩きにいくような作り方にはしないかもしれません。たとえば、裏側で定期的に JSON データセットを叩いて、キャッシュ的に static なファイルとして保存しておいて、それを返すようにするとかですね。どれくらいリアルタイム性が問われるかにもよりますけれども。

小巻: 確かにそうですね。環境によりますけど、S3 バケットに置いておくとか、サーバ側のキャッシュ機能を使ったりとかですね。

野口: ですね。

小巻: 僕は商用の本番環境で、直接 FileMaker Data API を叩くような使い方は、そこまで積極的に使わないんですけれど、その理由としては、端的に言うと、不安定だろうと思っていまして。それこそ FileMaker Server が生きていないといけないっていう前提が必要になりますし、FileMaker Server 側の SSL 更新もしっかり管理しなきゃいけないです。また、定期的な更新をかけていかなきゃいけないとなると、どうしても FileMaker Server が止まることがありうるので、不安定なところが残ってしまうと思うんですよね。

野口: そうなんですよ。

小巻: ただ、FileMaker Cloudなのか、自分でホストしているのか、という点にも違いがありますし、非機能要件を考慮したり、一概には言えないのですけどもね。

野口: それはありますね。

小巻: なので本番環境で使っていないのですけれど、社内用とかちょっとライトな使い方っていうのは、確かにありますね。あと、静的ファイルとしてキャッシュしておくっていうのは良さそうですね、確かにね。

野口: そうですね、本当に中規模以上で外部向けに使うことと、安定性をしっかり求められるってなったら、どうしても MySQL や PostgreSQL を選んでおく方が無難ですね。

小巻: そうですよね、無難ですよね。いやあ、普段から触られてるからなのか、引き出しが多いですね。勉強になります。

野口: いえいえ恐縮です。というか、話しすぎてますよね、私……

n8n と Claris Connect

小巻: 続いて、n8n についても訊いてみたいです。結構前に、話題に挙げられていましたよね。

野口: はいはい。

小巻: その頃は使われていたとして、今はどうでしょう？　Claris Connect も出てきたので、どうなのかなと。

野口: n8n については導入をかなり検討した上で、やめました。というのもまさに Claris Connect が出てきたからですね。

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

野口: となると、なぜ n8n じゃなくて Claris Connect を選んだのか、という話になるわけですが……ピティナで共有されていた .fmp12 ファイルって、日本語が多く使われていたんですよ。ファイル名にしろテーブル名にしろスクリプト名にしろ、あれこれと。

小巻: はいはい。

野口: 日本語環境に対しては n8n で直接指定することができなくて、必ず URL エンコーディングしなければいけなくなるんですね。

小巻: なるほど、それは面倒ですね。

野口: n8n に対して直接手を入れてプルリクを出すことも検討しましたけれど、そもそも n8n 側で FileMaker まわりの更新があまりされていないようにも見えていまして、さてどうしようかなーと思っていたら Claris Connect が出てきたという経緯でした。

小巻: はい。

野口: Claris Connect については、登壇もしましたし公式記事も寄稿しました通りで、それなりに使い込むに至りましたが、最初はやっぱり「これ、本当に大丈夫かな？」って思ってましたねー……（笑　とはいえ、実際にお金払って使って、直接 Claris の方々へフィードバックをしていかないと、機能も良くなっていかないだろう、と思いまして。

小巻: 確かに。貢献的な意味もありますよね。

野口: それでまあ、突撃隊長みたいな感じで使っていこうと思って選んだんですよ。これに限りませんが、やはり最初についたユーザが「ここはもっとこうした方がいい」「やった方がいいよ」という声をあげて、それがちゃんと届くようになっていないと、サービスって改善されていきづらいんですよね。

小巻: はい。

野口: Claris Connect を使って見て何が辛かったかというと、やはり月あたりの利用上限ですね。ちょっとしたステップを組んでいくだけで、一つのフローにおいて消費量がかかりすぎるんですよ。

小巻: わかります、すぐ上限に達してしまいますよね。

野口: Claris Connect にはフリー版もありますが、とはいえ数百回が上限だと、テストもままならないんじゃないかと思います。

小巻: マスタ系の処理ならまだしも、イベント系だとあっという間ですよね。

野口: はい、例えばトリガーに対しての実行が何ステップか走って、最後に結果を返す……もうこれだけで 5 ステップくらい使いますからね。

小巻: FileMaker との連携という観点でいうと Claris Connect というのは、 curl とかそういったことを学ばなくても使えるのが大きいわけですよね？

野口: そうですね、直接 FileMaker Data API を触らなくてもよいというか。起点を FileMaker Pro に置かずに FileMaker スクリプトを実行できるというのが強みだと思います。FileMaker Pro を起点にするなら手前のスクリプトで curl の実行でも何でもできるわけですが、外部の何かがトリガーになって FileMaker Pro の処理を……というのが弱かったわけですね。

小巻: そうですよね、確かに。 Webhook の受け取り役としてとても良いですよね。

野口: なので、FileMaker Pro から Claris Connect を直接実行できる、というのは、個人的には「そこじゃないんじゃない？」という気はしています。FileMaker Pro がトリガー側になるというのは、既に十分満たされていると思っていまして。

小巻: はいはい、ありましたね。これからどうなるかわかりませんが、進化することに期待しています。特に Webhook を簡単に扱えるようになるのはおおきいですよね。Cloud Functions や Amazon API Gateway などを使わないとできなかったことが、少ないステップでできるようになるのは利点です。例えば、Slack や LINE などの通知を受け取る仕組みを簡単に設定できたりですね。

野口: 良いですよね。

小巻: 先日リリースされた Custom Connectors や、今後サポート予定のOAuthなどがリリースされれば、さらに多くのことが可能になるので期待しています。

野口: そうですね、ただ FileMaker 側との連携に特にこだわらないなら、他のツールを使った方が良いかなとは思っています。たとえば Zapier や Make などですね。安くて上限も緩めです。このあたりは FileMaker をサポートしていませんが、FileMaker 側からトリガーを叩くことだけはできます。

https://www.make.com/en

小巻: 確かに。

野口: なので Claris Connect は Zapier や Make などを競合と考えず、あくまで FileMaker に特化したものという姿勢を貫いた方が良いなと思っています。料金プラン的にも FileMaker と抱き合わせちゃって、導入ハードルをもっと下げるなどした方が良いだろうなと。

小巻: 使ってもらうきっかけを作っていかないとなりませんよね。

野口: 小巻さんは、Claris Connect か n8n か Zapier か何か、こういったオートメーションツールって使われてますか？

小巻: あんまり使っていないんですよ。Lambda か Cloud Functions か Cloudflare Workers を使うことがほとんどですね。先ほどの話と同じですけど、学習の意味も込めて、あえて手を動かす道を行ってるんじゃないかと。

野口: なるほど、学習として。

小巻: 自由度も高いですからね。何かあってもドキュメントを読んで解決できるというのがありますから。やっぱり体系的に理解するっていうことに意味があって、Lambda を触っていて得た知識は Cloud Functions でもどこでも応用がきくようになります。だから、しっかりとドキュメントは読んでおくのが大事だと思っています。

野口: 先ほどの AI の話のときに言及し忘れていたのですが、そのようにして自分の頭に叩き込んでおくことの重要性は、間違いなくあります。どういうときに効いてくるかというと、反射レベルで必要になるときなんですよね。

小巻: 例えばどのような？

野口: ガスの匂いがした時に「やべえ、ガス漏れてるぞ」って気づけるかどうかで、生死を分けるわけじゃないですか。

小巻: はいはい。

野口: お風呂場で、この洗剤とこの洗剤、絶対同時に使っちゃいけないよね、みたいな。

小巻: はいはい、雨よけの防水スプレーを室内で使っちゃいけないとか。

野口: ですね。こういうクリティカルに致命的なものに対してはしっかりと自分に叩き込んでおかないといけないと思います。IT でいえばセキュリティに関するところですね。その線引きも難しいかな、というのはあるわけですが……そりゃ、いつ何がクリティカルになるかって、そんなことが事前に全て分かっているほど楽なことはないですから。

小巻: ですよね、難しいところですね。少し話が逸れるかもしれませんが、人間ってやっぱり、サボりたいというか手間を省きたいと思うものなので、FileMaker Cloud とか、FileMaker Server のホスティングサービスを利用することで、FileMaker Server を自前で管理しないようにするに越したことはない、という立場もあるわけじゃないですか。

野口: はいはい、ありますね。

小巻: 一方で、そのあたりの管理をしっかりしたい派の人もいる。僕はそっち派の人間なので、SSH 接続したいし、できれば自分で管理したいと思っています。

野口: 自分も同じ派閥です（笑

小巻: AI の活用からクラウドサービスから、だんだんと何かをしなくてもよくなるという流れは進んでいくものと思っています。ただ、自分が泥臭くやってることというのも、これはこれで意味はあるのだろうなと思いたいです。

大規模クラウドサービスと VPS の活用

小巻: 自分の時間を割いてでもサーバー管理をしっかりやりたいというのは、トレードオフ問題ですよね。

野口: そうなんですよね。私も、かなりレイヤーの低いところから面倒を見たいタイプではあるため、既存のお守りを除いて、自分から積極的にコンテナ技術の導入もしてこなかったくらいです。「裏側で何かわからないけれどよろしくやってくれます」とか、ちょっと許せないなーというところもありまして（笑

小巻: うんうん。

野口: Infrastructure as Code という考え方そのものは、すごくよくわかるんですよ。でも、そこから数歩進んでいくと、いろんなところが隠蔽されて見えなくなってしまったりする。で、エラーが起きた時にむしろ追跡しづらくなる場面が出てくる。トレーサビリティが消えてしまう、っていうのが好きではないな、と。

小巻: はい。

野口: そんなわけで、用途別に VPS などで一つサーバを立ててしまって、シンプルに手を動かしてインストールする……っていうことを愚直にやってきた人間だったんですよ。ただ最近はリソース管理についてもう少しシビアにしようかとは思って、一つの VPS の中に Docker コンテナを複数立てて、限られたリソースの中で「このコンテナを起動しておいて」「このコンテナは落としておいて」みたいな管理をどれくらいやれるかなーという実験をしているところです。

小巻: ポートフォワーディングやルーティングでいろいろできるからいいですよね。手元の使ってないマシンをホスティングにして、Cloudflare Tunnel を使えばパブリックにもできちゃいますし。もちろん、むやみに公開するのはあんまり良くないですけど、自分で遊ぶという点であれば好きにやれちゃいますね。

野口: それに関連すると、小巻さんってラズパイで FileMaker Server を動かしたりとかってしてないですか？

小巻: いや、してないですね。できると思うんですけどね、Arm 対応しましたからね。

野口: 今のラズパイってメモリ 8 GB くらいまで積んでいるので、要件満たしているからいけるじゃん、と思っているんですよ。「誰かやってほしいなー」「やってる方がいたら、その体験談を聞きたいなー」と（笑

小巻: 面白そうですね。I/O の問題で本番環境として使うかっていうのはちょっと置いといたにしても、気になりますね。

野口: 自分でやるには、今ちょっと時間取れないけれど、やってる方がいたら話を聞いてみたいなーということで、最近、詳しそうな人に、ちょっとこう、お話をして、唆したりしています（笑

小巻: 余力があれば、やりたいと思います（笑

野口: クラウド話に戻すとして、今は三大ベンダーでいうと、AWS を中心として利用されてますか？

小巻: AWS を使うことが多いです。自分自身は GCP をよく使ってますけど、クライアントでの要件には AWS が多く選ばれますね。

野口: やっぱりそうなりますよね。

小巻: AWS と GCP は完全互換ではないですし、どうしても導入規模からして AWS を選んでおいたら楽かなとはなりがちですね。逆に野口さんはどうですか？

野口: 私も自分では GCP を選びますね。AWS でしかできないことがあれば使いますが、AWS はとにかく初心者に対する落とし穴が多いじゃないですか。変な翻訳でインスタンスを誤って削除しがちになっていたりとか。全体的にインターフェースが不親切なままで、2012 年から見ていますが、ほとんど改善されないんですよ。

小巻: はいはい。

野口: 後発の GCP は料金的に少し優しい部分がありますし、良くも悪くも Google だからこそのインターフェースで、迷うところが少なく済むというのが大きいですね。

小巻: そうですね。

野口: もう一つの Azure は、特に Active Directory が必要な場合以外はあえて選ばないですね……ただ、最近だと LLM を安心して使いたいという需要はありそうです。

小巻: あー、なるほど。そっち方面での引き合いは、増えてきていそうですよね。

野口: あと Text-to-Speech の使い勝手に関しては Azure がいいかなという感触で、ブラウザベースで簡単に使えるし音声ファイルのダウンロードまでできるんですよ。たしか AWS もブラウザ上で確認まではできたはずですが、Azure の方が品質が良かったかな……で、 GCP についてはブラウザで試せなくて、わざわざ API を叩かないといけないのが、不便でしたね。

小巻: なるほどなるほど。まあ、そうですよね。全てにおいて、どれか一つに集約されるというのはなかなかないわけで、横断的に使うということはありますよね。

野口: ただ、なるべくですが、そもそも海外大規模クラウドではなくて、国内 VPS を選ぶようにしていますね。弊社の目的としても、日本の中小企業を元気にしていきたいということから、外資系企業にお金を落とすよりも、国内企業に流したいと思っています。あとは為替リスクへの直撃回避目的もあります。

小巻: はいはい。

野口: 最近だと Xserver VPS を使うことが多いですね。nginx はホスト機に直接インストールして、そこから各 Docker コンテナへ通信を振り分けてあげています。

小巻: そのようにしていると、おおむね自分で把握できるようになるわけですね。パッケージの保守とか諸々を自分でやらないといけないから、ハードといえばハードだけれど、それをしっかりやるからこそ Linux サーバ運用の知見が蓄えられるということですね。何かトラブルがあった時でも自分で対応できるようになる。

野口: そうなんですよ。それから最近、弊社ではエンドポイントを GAS で用意することが多くてですね。VPS 側に立てた API を外から直接叩かせるのではなくて、いったんそこを経由させるようにしています。

小巻: あー、なるほど。

野口: もちろんレイテンシーが多くなりますからパフォーマンス最重視なところでは使えませんけれど。

小巻: はいはい、そういう使い方もアリですね。

野口: VPS はパフォーマンスも全然悪くない、というか、払った金額に対して得られるスペックとしてはむしろお得なくらいなので。

小巻: 確かに、安いですよね。AWS でインスタンスを立てて、ずーっと停止せずに置いておくと、結構な金額になりますからね。

野口: はい。AWS や GCP で、確約割引を使ったとしても、それでも VPS の方がコストは抑えられますね。特に今だと Xserver のコスパは素晴らしいです。

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

野口: 競合含めて使ってみたんですけれど、Xserver って VPS としては最後発なくらいなんですよ。確か 2022/09 開始なので、まずハードが新しくて、スペックが良いんですよね。だから I/O もとても良くて。

小巻: なるほど。

野口: もちろん、どのサービスもハードウェア的な経年劣化は避けられませんから、数年後に競合がハードを一新したら、事情は変わるかもしれませんけれども。

小巻: それはそうですよね。

野口: あと管理画面が一番わかりやすくて、一番早い、というのも大きいですね。某 C 社のように、VPS を立てる上限が裏側に定められている……といったことも今のところなさそうなので……まあ、あまりここで言い過ぎるとステマというかダイマというか PR っぽくなってしまうのでこのあたりで割愛しておきます（笑

小巻:（笑　あー、でもいいな、ちょっと検討しようかな。

野口: メモリ 2 GB くらいのものだと 1,000 円以下で借りられちゃったりするので……

小巻: あー、ほんとだ、安いですね、確かに。

野口: 何かのバッチ処理を cron で動くようなものとして置いておいたとして、従量課金かからないから Cloud Functions で動かすよりだいぶ安くなったりもしますね。

小巻: はいはい、そうですよね。従量課金だとそのあたり気にして、じゃあこれは S3 に置いて……みたいなことを考えなきゃいけないですもんね。料金体系はシンプルですよね。使ってみよう。

野口: はい、お試ししやすいと思いますので。

開発ツールや生産性管理

小巻: もう一つ訊いてみたいことがあります。趣味みたいなもので、開発ツールや生産性の管理といったことを見たり聞いたり、それから自分でも実践したりするのが好きでして。どういうところにこだわりがあるか訊いてみたいです。例えば vimmer であるとか、そういうところがもし何かあれば。

野口: そうですねー、エディタからいえば、今は主にメインで 2 つ使っています。まずシンプルなテキスト処理用に EmEditor を。

野口: これは Windows 版しかないですね。それからプログラミング全般のほうは Visual Studio Code ですね。VSC の前は Atom で、もっと遡ると Adobe Brackets とか Sublime Text とか……

小巻: はいはい、ありましたね。ただ今となってはもう VSC が定番ですよね。

野口: そうですよねー。生産性管理、タスクやプロジェクト管理のほうは、今はもう完全に GitHub に押し込んじゃってますね。

小巻: GitHub ですか。それって、お客さんと一緒っていうところでも、問題ない感じですか？

野口: そうですね、お客さんに対しては、普段使われているものがあればそこに乗っかってしまうので、こちらから GitHub を導入しましょう、と提案するケースがまだ少ないですね。ただ、導入例はあります。

小巻: なるほど。自身での管理は完全に GitHub ということですね。

野口: そうですね。それから、GitHub issues は使っていても GitHub projects や discussions までは使っていない、という場合に、issues とあわせて使いましょうっていう導入例もありました。

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

野口:ゼロからの導入事例だと、 全然タスク管理と無縁の方に、「無料で使えて、いわゆる掲示板のようなものなので、使ってみてください」とお願いして使い始めてみていただいたところ、すんなり抵抗なく活用できているということもあります。英語っていう点はありますけれど、今、無料で使える、つまり導入障壁が限りなく低く、デファクトスタンダードになっていて、コードともつながっているしマークダウンも書ける、っていうところで、GitHub 強いなぁと思っています。

小巻: 確かにそうなりますよね。そうか、お客さん側まで GitHub に引き込むんですね。今まで経験ないですが、まあそっちの方が望ましいので、それもアリですね。

野口: GitHub の使い方として、コードの差分管理用というより、もう吹っ切ってプロジェクト管理用として issues や discussions だけ使うということでお誘いしちゃうっていうのも、アリだと思うんですよね。

小巻: そうですね、この issues で検索してみて見つからなかったら、新しく作成して、コメントしてください、と。掲示板のようなものだから、その感覚で使ってみてください。という感じですもんね。

野口: はい。英語だし動線が分かりづらいということがあるなら、ブックマークバーに issues の URL を登録しておいてもらえば、一覧が表示されるようになりますから、と。

小巻: 確かに強いですよね。各 issue やコード間との連携もできますし。エコシステムというかツールが揃ってますもんね。

野口: はい。何なら GitHub Actions でフローのカスタマイズまでできますし。

小巻: はいはい、そうですよね。ちょっとチャレンジしてみようかな。もちろん、お客さん次第ではあると思うんですけれども。

野口: はい、そこの合意は取りつつで。

小巻: 他に、日頃の気づきやらコードスニペットやらを、スクラップ的に記録するときに、これを使う、というのはあったりしますか？　アイディアはこっちに、みたいなことだったり。

野口: あー、そうですね、アイディアは……今は Slack や Discord で自分宛に DM を投げるとかですね。

小巻: なるほど、一人 Slack 的なやつですね。

野口: 最近だと ChatGPT に投げておくっていうのもありますね。

小巻: あー、なるほど。そこに貯めておく場所が、ある程度統一されていれば、そこを見に行けばいいっていう感じですもんね。

野口: そうですねー。で、コードのスニペットなんかは、今は全然書き溜めてないですね……それこそ昔は Google ドキュメントとか Google Keep だとか……あと Trello に置いていたこともあったんですが、今はもう記録してないですね。

小巻: 今、お仕事としては手を動かすというか、コンサルや相談がメインになってきたからというのがあるからでしょうか？

野口: いや、実のところまだまだ手を動かすこともあるんですけど、どちらかというと、GitHub issues に活動記録として書いたコードごと書き残しておくということが多くなりましてですね。

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

野口: あのコードは、あの issue に記録してあったよなー、みたいな感じで思い出しますね。

小巻: はいはい、なるほど、issues に集約するっていうのは確かにいいですね。そこで検索すればいいだけですもんね。

野口: そうですね。かなり GitHubに 寄せてますね。

小巻: 素晴らしい。

野口: 何かと issues に手順を残しておくようにしているので、例えば、 Qiita などでこれを記事にしよう、みたいなものも、スレッド形式でどんどん書き残しておいてから、後でそれを編集して記事に直す、みたいな。

小巻: なるほどー、issue のその使い方、いいですね。自分のタスク管理なら、やろうと思えばそういう使い方はいくらでもできますもんね。

野口: 小巻さんは、今、どういうものを使われてるんですか？

小巻: プロジェクト管理という点でいくと Redmine を主に使ってますね。セルフホストしている Redmine にお客さんを追加して、プロジェクトを作って、という昔ながらのやり方ですね。ちょっと使い勝手が悪いところについては、受け入れてもらいつつやっているということが多いですね。

野口: なるほど。

小巻: 基本、書いたことは全部、そこに入れちゃってますね。エディタで書いたものについては、ログ的なリポジトリを作って、GitHub へプレーンテキストとして push していくようにしています。リポジトリは 2023 年 とか 2024 年 みたいにして分けておいて、アイディアやら打ち合わせメモやらコードやら、全部そこから全文検索で拾いに行くようにしていますね。

野口: 2023, 2024 っていうのは、フォルダというかディレクトリで分けているわけじゃなくて、そもそもリポジトリで分けるんですね？

小巻: 当初、いろいろ突っ込んでおこうかなと思っていた時に、リポジトリのサイズ上限問題もあって、分けようかなと判断したんですよね。結局、ほとんどプレーンテキストだけにはなっていますけれど。

野口: へぇー、面白いです。

小巻: 他の方がどういう風にこういう管理をされているかなー、というのは興味があったので、聴けて良かったです。

野口: ほんと、流派がいろいろありますよね。Backlog を使ってます、とか。

小巻: ですね。すごく勉強になりました、楽しいです。

FileMaker での開発について

小巻: 最後に FileMaker に関して、開発におけるこだわりを訊いてみたいです。これも長くなっちゃうかもしれませんが……FileMaker だけに限らなくてもいいのですが、開発において野口さん自身がどのようなこだわりを持っているか、興味があります。

野口: FileMaker 開発におけるこだわりとしては、まず、自分 1 人だけで永続的に開発していく想定なのか、それとも自分が面倒を見ることのできる時間には制約があり、他の誰かへ引き渡していくか、というところで、大きく分かれますね。

小巻: はい、それはありますね。

野口: それこそ自分だけしか触らないのであれば、自分の能力的な劣化っていうことは現状そこまで考えがたいと思っていますので、技術的制約、作り方については、自分が分かる範囲で遠慮なしになりますね。

小巻: なるほど。

野口: 一方で、他の人が触るとなると、ある一定の制限を設けるようにします。例えば関数の作り方、計算式の作り方ひとつとってもそうで、汎用的な可読性、可用性を重視します。レイアウトでも WEB ビューアを使わずにするなど、どれだけネイティブな機能だけで完結させるのか、というところですね。

小巻: はい。

野口: それ以外のこだわりも結構ありそうですが、そうですね……スクリプトのコメントで、ドキュメント的に GitHub issues への URL を貼っておく、ということはやりますね。このスクリプトを何で作ったのか、みたいなことは、コメントとしてベタに書いておくんじゃなくて、関連する issue URL へ飛んで読んでね、としておきます。そうすると、作った経緯とか誰が作ったかとか、プロジェクト管理側に関連づけられる。

小巻: それはチーム開発時にも生きてくるノウハウですね。

野口: はい、まさにですね。そしてチーム開発に限らず自分一人だとしても、です。今の自分から将来の自分に対して、どれだけ優しい手紙を送ってあげられるか、というふうに思ってます。忘れちゃいますから、本当に、「何だっけこれ？」って（笑

小巻: スクリプトステップ内にコメントを書いておくだけだと、検索性が悪いということもありますし。

野口: はい、スクリプトステップ内だと画像が貼り込めないという問題もありますよね。

小巻: はい。

野口: 先日の関口さんとの対談でも出た話題ですが、FileMaker のスクリプトについては、もっとメタ的な情報を参照編集できるようにしてほしいですよね。要は、最後に編集したのが誰か、とか、最後に編集した日時がいつか、みたいな情報を、手書きでなくてメタ情報として記録され、ユーザ側も UI 上で見られるようにして欲しい。今、それができない以上、どうやって記録を残しておくべきかということで issue へのリンクを貼っておくという次善策を採っています。

小巻: なるほどなるほど、ありがとうございます。確かに、そもそものところで、一人で継続的に開発から保守までするのか、そうでないのか、という切り分けは大事ですね。技術選定、つまり、どういうレベル感で実装すべきかということを意識しなくてはならない、と。

野口: そうなんですよ。それから次のこだわりとしては、パフォーマンスの重視ですね。レイアウト上でのレンダリング一つとってもそうで、例えば、タブコントロールとスライドコントロール、どっちを置いた方がレイアウトのオブジェクト負荷が高いのかというのが良い例で、これはタブの方が負荷が高いんですね。レンダリングの検証したら、タブの方が 5 倍以上重かったんですよ。

小巻: はいはい。

野口: 多分、スライドはタブよりだいぶ後に実装されたから、内部的に fmp12 形式に沿った軽くて良いコードになっているんじゃないかなー、と予想しています。だから、スライドで済ませられる場合はスライドの方にして、必要に応じボタンを置いてタブっぽく触れるようにしてあげるということをしたりですね。

小巻: なるほどなるほど。そうですね、FileMaker は歴史が長いから、昔からあるものは古いコードを引きずってる部分がありますからね。今さらなかなか変えられないところがあるわけですよね。

野口: そうなんでしょうね。それから、もう絶対ここについては編集も検索もしないよね、みたいなフィールドの表示をする時には、マージフィールドを置くようにするとか、細かいところに気を配りますね。ユーザビリティを損ねず、リスク管理的観点も含め、オブジェクト負荷が軽いものを選んでおくようにします。

小巻: やっぱりパフォーマンス面を気にされるっていうのは、前職で B2C 向け WEB アプリケーションを扱われていたからということですよね。FileMaker でも  WebDirect 環境だと特に注意しないとならないでしょうから。もともとそういったことへの意識も強かったんですか？

野口: そうですね。私も小巻さんと同じような経歴で、事務職として始めて独学でやってきたわけですが、けれど 1 ユーザーとして使ってても、「このレイアウト、開くの重いなー」っていう経験って、心に積み重なってくるものがあるじゃないですか。段々とそのレイアウトそのものを使うことを避け始めてしまうような。

小巻: はいはいはい。

野口: ユーザー心理としてそうなってしまうというのを、絶対避けなくてはと思っていました。WEB の世界に足を踏み入れてみると、ここではパフォーマンスのチューニングってカリカリにやっていくのが当たり前の世界観でして。

小巻: そうですよね、確かに。

野口: バックエンド側での通信もそうだし、バックエンドから返ってきた後のレンダリングでも気をつけなきゃいけないし。時間的にそういう開発に長く身を置くようになったので、そこでの感覚をまた FileMaker 開発に持って帰ってきたという感じですね。

小巻: なるほど、素晴らしい。

野口: それとの関連で、状態管理／変数管理にもこだわりが強い方ですね。

小巻: そのあたりの管理っていうと、例えばログインにおけるセッション的なレコードがあって、とか、そういう……？

野口: そういうのもありますし、もっと初歩的なところからのものも（笑　私が使い始めた頃って、ひたすらあちこちでグローバルフィールドが使われまくってまして、スコープが汚染されまくってたんですよね。そもそも変数ですらないんですよ。

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

野口: これはローカル変数でいいよね、これはグローバル変数でいいよね、これはグローバルフィールドにしなきゃいけないよね、みたいなところを、ちゃんと用途別に切り分けて、しっかりと管理するようにしましょう、という、そのあたりのところからですね。

小巻: なるほど。

野口: データビューアで見ると、このグローバル変数にこういう値が入っているんだけど、これってどこのスクリプトで設定されたか分からない、みたいなことって起こりがちじゃないですか。

小巻: はいはい、起こりますね。

野口: そういうものを、ちゃんと透明度を上げていかなきゃいけないよね、とか。

小巻: 確かにね、難しいところですね。FileMaker らしさというのがどうしても出てきてしまう。そういう環境においても、うまいこと管理するというところですよね、

野口: そうなんですよ。設定用やリセット用など、グローバル変数を扱うための専用スクリプトを独立させておく、という管理手法はよく採っています。値を入れたいんだったら、そこへ引数を受け渡すようにする、みたいな。

小巻: なるほど、setter / getter みたいなスクリプトが用途別にあるんですね。

野口: 他に変数まわりで言うと、ローカル変数よりももっと小さいスコープとして、関数内での変数もあるじゃないですか。

小巻: はい。

野口: 式内変数を見分けるように接頭辞をつけるといったことは、しないようにしてます。どうしてかというと、そもそも式外の変数を直接は取り扱わないようにするからですね。外の変数の値を使う場合、式内変数に入れ直してから使います。つまり、内外での変数を区別しなきゃいけないという状態を避けます。具体的には Let 関数において、最初に変数をセットし、それ以降はその変数だけを使うようにするということですね。

小巻: あー、なるほどなるほど、そうですね。

野口: コードリーディングの負担を下げる、つまり依存するコンテクストをどこまで認知していないと読めないのか、という認知負荷を下げるっていうのを、かなり意識しています。

小巻: 確かに、それって、自分としては「こだわり」というほどには思っていなくて日常的にやっているけれど、第三者から見たら「それってこだわりじゃん」と思われるみたいなところもありますよね。

野口: ありますね。

小巻: 「こだわりって何ですか？」という問いって、実は難しいものなんですね。自分の中でこだわりかどうかという見極めが必要なものって、たぶん他にもたくさんあるはずなので。

野口: そうですね。その「言語化が難しいかも」みたいなのって、やっぱり他の方との対話を通じてでしか見えてきづらいじゃないですか。「あ、この方、ここのところはこだわってないんだ」「でも自分はそこってこだわってるんだよなあ」みたいな気づきの積み重ねを通じて、「こだわりポイントはここなんだ」と自覚が生まれてくるわけですよね。

小巻: はいはい。

野口: 私もこれまで、他の方と会話する中で「自分はここにこだわってるんだな」っていう自己認識を作ってきた結果として、小巻さんからの問いに対して答えられましたから。

小巻: なるほどなるほど。僕、これはこだわりじゃなくて当たり前のことだよなって感じているところが多々あったんですけれど、たとえば三日後の自分は他人という観点から「コメントをつける」とか「なるべくハードコードしない」とかいうのも、こだわりといえばこだわりですよね。

野口: ですね。小巻さんは、こだわっている部分はありますか？

小巻: 「ちゃんと作る」っていうこと、つまり、横着しないっていうことは気をつけているかもしれません。やっぱり当たり前のことかもしれませんが。データ設計の話で、単一テーブルじゃ無理だから、中間テーブルを持たなきゃ、みたいなときに、「改行区切りの値でいいや」みたいなことで逃げたりすることもできるじゃないですか。

野口: ありますねー。

小巻: できるんですけど、結果的にそれで進めていっても良い結果にならないので、「ちゃんと作る」「作り直す」ということを意識しないといけません。それによる納期の遅延という問題が起きる可能性というのもあるわけですけれど、なるべく「正しく作る」というのを意識して頑張ってますね、はい。

野口: だいじですね、妥協しない。

小巻: 結局それが負の遺産になって、後になって「あー、ここ中間テーブルだったらよかったのに」って。一生懸命、計算式でごにょごにょがんばって誤魔化しているくらいだったら、やっぱりちゃんとテーブル作っておいた方がいいよね、っていう話ですね。

野口: そうですね。今の話を受けてなんですが、もう一つのこだわりポイントとして、そういう風に自分が選択した理由、つまり「何でこうしたのか」そしてどちらかというとこれが重要ですが、「何でこうしなかったのか」っていうことを、しっかり記録に残しておくように意識しています。

小巻: なるほどなるほど、確かにね。

野口: 有名な和田卓人さんが、「コメントには何でこうしなかったのかを残せ」と言っていましたが、あれにはすごく感銘を受けて実践するようにしています。後から読んだ人が、「本当はこういう風に回った方が近道なんじゃね？」って勘違いして進み始めてしまうのを防がないといけない。地図でいえば、たとえば等高線を理解しないで、三次元的な地形を無視して二次元的な進み方をしてしまいかねない。高い山がそびえている頂上に、直線で進もうとしちゃう。

小巻: はいはいはい。

野口: 「それ近道に見えるでしょ？　でもそうしなかったのは、こういう理由があってね……」っていうのを、後の人にもわかるように、記録しておくのは大切ですね。将来の自分含め（笑

小巻: なるほどなるほど、コメントとしてだけでなく、そこら辺もちゃんと issue として残したりとか。背景とかも残して、っていうことなんですよね。

野口: そうですね、はい。

小巻: ほかに意識している点ですと、FileMaker の得意なことにちゃんとフォーカスする。FileMaker が苦手としていることを、頑張ってやらない、っていうのは意識してますね。

野口: 餅は餅屋だと。

小巻: はい。B2C 事業で大量レコードを取り扱って集計するとかですね。何十万件とかすぐにいくようなレコードを頑張ってどうにかする、っていうことそのものが、そもそも間違いなんじゃないか、とも思っていまして。頑張って集計テーブル作って、みたいなこともアリといえばアリですが、それも遅いですし。

野口: 決して得意な領域ではないですよね。

小巻: スキーマの変更があるたびに集計テーブルの作り直しもしないといけませんし。やっぱりそこは BI ツールを使ったりした方が良いですよね。BI ツールに渡すための生データを渡せるようにするから、FileMaker 以外のところでよろしくやっていただく、みたいな割り切りをしちゃうことが多いですね。

野口: 切り分けが難しいですが、重要なところだと思います。

小巻: なるべくそんなに無理に頑張らない。それって、お客さんの商売を理解する、ということにも繋がってくると思っているんですよ。結局それで何を解決したいのか、っていうことですね。

野口: なるほど。

小巻: どれだけお客さんにとってプラスになるのか、さほどプラスにならないのか。お客さん自身が理解されていないところもあるかもしれません。これが必要なんだということを、すごく大げさに言う人もいるし、実は必要なのにいらないと言われることもあります。そのあたりの解像度を、お話しを通じて一緒に高めていく。まぁちょっと具体的ではないんですけど、そういう想いを持ってやっていますね。

野口: いえいえ、貴重なこだわりですね。……というあたりでそろそろ締めに向かっていきましょうか。今日はどうでしたでしょうか？

小巻: まず思ったのは、対談の中でも結構出てきましたけど、やっぱり第三者と話すことによるその刺激が大きいですね。「これってこだわりなんだ」っていうくだりが代表的でしたけれど、このような認知ができたりとか、改めてアウトプットすることで思考が整理されていきました。

野口: 本当に、自分に対する気づきを得られますよね。

小巻: Angular をどうして使っているのかということもありますし、なぜ「そうしているのか」っていうところの背景を、改めて自分の中で整理できたっていう良い機会になりました。今やってることも、さらに別のことを色々とやってみたいな、とか。私からも色々と聞けて、VPS のこととかすごく勉強にもなりました。ありがとうございました！

野口: いえいえ、ありがとうございます。小巻さん、聞き上手だからこちらから話しすぎました……（笑　私は連続して、田中さんと関口さんとお話しさせていただいていますから、今度は 小巻さん ⇔ 田中さん ／ 小巻さん ⇔ 関口さん ／ 田中さん ⇔ 関口さん といった組み合わせでの対談では、どういった話題が出てくるのかなというのが楽しみでして。イチ読者として読ませていただきたい、って思いましたので、機会があればぜひお願いします！

後書き

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

ようやく最後になって FileMaker の話題が出ました（笑
たぶん FileMaker に限って対談をおこなったとしても、同じくらいの分量の記事を作れるくらいになりそうなのですが、話題が本当に多岐に亘りましたね。
後編だけでも 20,000 文字超えているので、読み応えたっぷり！　……むしろ長くて読んでもらえないかもしれない？　いやいや楽しいのでぜひ読んでください！🙏
初っ端で 「自分の考え」なんて在るのか から始まりますからね。なかなか IT エンジニア同士の対談で珍しいのではないでしょうか。

ちなみにエディタは VSC 使ってますって語っていましたが、現時点 2024/03 だと VSC と Cursor を併用しています。Cursor のドキュメント読み込み機能がありがたくてありがたくて……

記録

• 対談日

  • 2024/01/19

GitHub 上でのファイル

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