「この人と話そう」第0003回：Guppy Web Service／関口敦子さん
前書き
連載対談「この人と話そう」について
主催者紹介
野口 啓之
株式会社きみより 代表取締役として、IT / DX を中心とした何でも屋さんとして顧問を請け負う
一般社団法人全日本ピアノ指導者協会 ( ピティナ ) 本部事務局 元 CTO → 現 IT 顧問
ネオプラグマティズムの思考様式をベースとしつつ、歴史学徒として概念史を嗜みつつ、ヨハン・ゴットフリート・ヘルダーの教育論研究を終生のテーマとする
そろそろ 『風来のシレン 6』が発売されるのが楽しみ
対談者紹介
関口 敦子
Guppy Web Service
FileMaker 開発を中心に仕事を請け負っています。
今まで IT の仕事ばっかりでしたが、最近 IT 以外の事業部も始めました。
自己紹介
野口 啓之 ( 以下 : 野口 ) : 本日はよろしくお願いします。はじめに、会社の概要やいつ頃から事業を始められたかについて軽く教えていただけますか？
関口 敦子 ( 以下 : 関口 ) : はい、わかりました。Guppy Web Service はかなり長い間、約 2 桁年数にわたって事業を行っています。 IT 業界には社会人になってからずっと携わっていて 30 年以上の経験があります。
野口: おおお……！ 大ベテランですね。IT 業界に入られたきっかけは？
関口: 最初は高校の時に BASIC を学んでいましたね。その後、専門学校に進み、COBOL や FORTRAN、さらに C 言語やアセンブラも学びました。
野口: その時代に情報系の専門学校に行かれたのですね。当時って、専門学校卒業した後、どのような職場に就職するのが一般的だったのですか？
関口: 多くの人が、システム開発をおこなっている中小企業に就職していました。SI などとはまたちょっと異なるようなところで。バイトで入っていてそのまま就職とか。
野口: へー、そうなんですね。その頃、開発に使用していたのは、Windows や Mac でしたか？ それとも PC-98 のような？
関口: その頃は、DOS が主流でしたね。プルダウンメニューなどの機能を自作しなければならないほど、まだ発展途上の時代で、コンソールでのプログラミングが一般的でした。
野口: 人手として、いわゆる上流というよりかは、手を動かすプログラマーの数がまだまだ足りていないような状況だったんでしょうか？
関口: どちらかというと SI の層が結構薄かったかなと思います。職人気質のプログラマーが多くて現場が成り立っていたという感じですね。SI をやる人達は、しっかり大学を出て、専門の会社に就職していましたね。
野口: なるほど。その頃のプロジェクトで、こういうのが面白かったなー、とか、逆に大変だったなー、とか、記憶に残っているものってありますか？
関口: とにかく学びが多かったのが面白かったです。新しく WEB 系が出てきたばかりだったので、それまでのシステムと違う作り方を学んだりですとか。新しい言語もそうですけれども、オブジェクト指向が流行ったので、どういう風にオブジェクティブにやっていくかっていう思想を学んだり。
野口: 好奇心ドリヴンですねー。
関口: ものづくりそのものも好きで。自宅で PC を組み立てることも、昔はよくやっていました。自作パーツ屋さんに行って、夏のものすっごく暑い時に、部屋にこもって組み立てたり。その過程で、ハードもミドルウェアの部分なんかも、少し深いところまで知る機会を得られたり。
野口: 自作いいですよね！ 私も 2000 年代は結構やってました。 WEB 系が出てきたのって、やっぱり Windows 3.1 の登場がすごく影響が大きかったっていうことですか？
関口: 最初はブラウザですね。Netscape が出てきて、これはすごいぞってなった。
野口: ほー。ネスケ。
関口: 個人の方ももちろんやられてるし、最先端のことをやってる会社とかも、WEB 系に手を出し始めた。その時に在籍していた会社も、そちらにシフトしていきました。
野口: いわゆる、ニフティのパソコン通信からインターネットに移る転換期ですよね。Netscape は Windows とか Mac で動いてたんですか？
関口: ワークステーションで動いていましたね。もちろん今からすると全然しょぼい機能なんですけれど、当時は革命的で。一般の人も、専用の機器とか使わなくても、世界の情報が見れるようになるぞということがわかってきた。こうしたことが広まっていく過程の時に業界に入れたので、すごく楽しかったですね。
野口: なるほど、私はその時代まだ小学生だったためほとんどかすらなかったんで、生の声を伺えて楽しいです！ ちょっとだけかすったといえば、中学生になってから、PC-98 で RPG ツクールの DANTE 98 をやっていたりしたくらいですねー。DOS は少しだけ触って、なんか亀の絵が描画されるようなプログラムをちょっとだけ書いたことがあったくらいです。自宅に PC が来たのが 1999年 のはじめぐらいで、本格的に触り始めたのは Windows 98 の時代からだったんですよ。当時はテレホタイムに ICQ 使ってみたいな……
関口: はいはいはい。
野口: 感覚的には、今の Slack や Discord とあんまり変わらない感じですよね。当時、Netscape 派の人がまだかなりたくさんいて、IE を使ってるやつなんてダメだ、とかいう言説もたくさん眺めていました。一応多少はインターネット老人会に片足を突っ込んでいるような感じであるんですけど、そのちょっと数年前のことが全然、肌感として知識がないので、今みたいなことを伺って、すごく楽しいです。私がこういうような、まだ子供でいろんな新しいものをおもちゃとして楽しんでる時に、既に関口さんはもう第一線でバリバリ働かれていて……大先輩ですね。
独立のきっかけと屋号への想い
野口: じゃあその、前職というか、会社勤めをされていたのは何年ぐらいされていたんですか？
関口: 正社員で働いていた会社が 2 社です。でも、そこまで長くはなかったんですよね…… 4, 5 年くらい。最初の会社は、バブルが崩壊して倒産してしまって……、2 社目はちょっと肌に合わなくてやめて。その後に、最初の会社で営業だった人が、パートナーと新しい派遣会社を立ち上げたということで、その契約社員もやりました。
野口: そこから独立されるに至ったきっかけは？
関口: そこで何年かくらいした時に、今の夫と一緒の職場になったんですよね。向こうはフリーランスでやっていて、たまたま話す機会があって、技術があってフリーランスでやれている人がいるなら、私もちょっとやってみようかな、と。
野口: おー。ご縁ですね。
関口: 本当に軽い気持ちでフリーランスを始めました。会計知識は持っていたので、帳簿や決算なんかは全然平気でした。でも、細々とした日々の雑事については、想定外のことがたくさんあって、最初は苦労しましたね。ただまあ、慣れてくると、やっぱりフリーランスって、それまでの正社員や派遣社員では体験できないところが色々とあるなと感じて、しっくりくるようになりました。
野口: 個人事業で開業されて、その時からずっと Guppy Web Service の屋号を？
関口: いえ、その時は屋号なしでした。一度、廃業してるんです。フリーランスだと契約がこれ以上難しいんだよねって言われてしまったことがあり、契約社員になったんです。その後にまた、フリーランスに戻ったんですよ。あいだの契約社員の期間は、そんな 1 年もなかった感じで。
野口: ええー。その時って、その税務署に廃業届を出されたんですか？
関口: そうですね、面倒くさいと思いながらも、仕方ないなと思って出しました。
野口: うわー。
関口: で、2 回目の時に屋号を決めようかとなりまして。たまたま家に水槽があって、グッピーが泳いでるんで、じゃあグッピーにしようって。意味も何もなく、隣にいたから、みたいなそんな感じです。後半に Web Service とついているのは、どのようなものでも何かしら WEB サービスに繋がるだろうということで、汎用的な意味合いですね。
野口: 最初に名前をつけた時は勢いとノリだったとして、今は屋号にこういう想いを持っています、というのはありますか？
関口: そうですね、「まあ気楽にやりましょう」と。その、優柔不断にフラフラ～っていうわけではないんですけれども、ある一定のところに固まっているだけじゃなくて、日々色々動いて知識を吸収しながら、世の中を泳いでいけたらいいなって思いますね。
野口: なるほど。名付けの当時は、WEB と WEB 以外の案件の比率だと、どれくらいだったんでしょう？
関口: 当時は 100% WEB でしたね。別に HTML を書いてどうこうというフロント寄りではなくて、Java を用いて WEB サービスの基盤を開発していたという感じです。
野口: Java については、独立前の頃から触る機会が多かったのでしょうか？
関口: 多かったですね、Java が出始めの頃から面白いと思っていました。仕事でも、ずっと Java 畑を歩いてきて。あと Ruby なんかも出始めた頃に面白がって触っていました。
野口: Java での IDE は Eclipse でした？
関口: ですね。
FileMaker を知ることになった経緯
野口: 今はもう Java じゃなくて FileMaker 開発に軸足を移されているわけですよね。その FileMaker を知ることになった経緯をお伺いできれば。
関口: Java 案件ってやっぱり大規模開発になるんですよ。そうすると、やっぱり夜遅く帰ってくるとか、それ以上に「なんだ、今日帰れないじゃん」みたいになるんですよ。
野口: おお……
関口: 子供を産んでから、「これじゃいかんな」と思うようになりまして。で、どうせフリーランスなんだし、ネット環境も整ってきたから、自宅でできることをちょっとやっていこうかなと思いまして。じゃあ開発にあたっては、何が良さそうかなって探していた時に行き当たったのが……
野口: FileMaker ？
関口: じゃなくって Bento だったんですよね。
野口: ああ！ 今は亡き！
関口: パーソナルなツールなのに、ここまでできるんだー、と。すごいな、と思って。これでなんかできないかなーと思ったので、渋谷の Apple Store に行って、講習会というか説明会というか、みたいな感じのところに参加してみたりしました。ただ、やっぱり個人向けなので、本格的な開発をする際には結構制限が大きい。あくまで一人でしか使えないというところがネックで。そこで、上位版の FileMaker というのがありますよって教えてもらえたのが、最初の出会いですね。当時は FileMaker 12 でした。
野口: 12 からだったんですねー。
関口: 逆に野口さんは、FileMaker との出会いってどうでしたか？ FileMaker 以外の選択肢ってあったのかなと。
野口: 私はもう、最初に新卒で入ったところが一般社団法人全日本ピアノ指導者協会 ( ピティナ ) で、2009 年の入社時点で、既にそこでは FileMaker を十何年使ってますっていう状態だったんですよ。だから選択肢なんてなかったんです（笑
関口: なるほど。
野口: ピティナが FileMaker 導入した経緯については、Claris Engage Japan 2020 の時のセッション動画で詳しく話しているので、そちらへのリンクも貼りますが……
野口: 簡単に話すと、代表専務理事の福田成康さんが、当時、 MS Access を使うか 桐 を使うか Lotus を使うか……みたいな感じで、社内業務用において、どのようなデータベースソリューションを使うのが最適解なのか、ということで、相当に時間と労力をかけて選定したらしいんですね。
関口: 懐かしい名前が……その中で FileMaker が選ばれたんですね。
野口: 決定打としては、写真をオブジェクトフィールドに貼り込めたっていう点が大きかったそうです。データベースをどれにするかっていうのは、本当にもう、賭け。社運を賭けるみたいな感じで。彼は当時、別の開発会社の経営者から、「消えゆくソフトウェアの悲哀」ということを聴いていたそうで、消えないものを選ぶことに全身全霊をかけていたそうです。アメリカの FileMaker 本社にも何回か足を運ぶほどで。
関口: そこまでされるんですね。
野口: 若い時分からそういう話を聴いて育ってきたので、私は、技術選定っていうのは、そういう風にそこまで詰めてやるものなんだと叩き込まれましたね。時に慎重に、時に大胆に技術選定をするっていう遺伝子を受け継いでるかなと自覚しています。
関口: 導入当時の FileMaker のバージョンは……
野口: 1990 年代の半ばだから、バージョン 3 とかからですかね。シングルテーブルで全部作らなきゃいけない時代ですね。なので、2005 年に .fp7 になってマルチテーブル化された時に、 1 年ぐらいかけて、マルチテーブルへとファイルをリニューアル統合していくみたいなことをされていたそうです。ただそれでも、私が入社した時には 200 以上のファイルが共有されていましたね。Server も 4 台に分かれていて。うち 1 台は WEB 公開されていたので、ワーカーマシンとマスタマシンとで分かれていたから、全部で 5 台ですね。
関口: じゃあ、もう、「そこにあるものがそこにある」としか言えない感じですね。
野口: そうですね、もう雛鳥が親鳥を初めて見た、みたいなのが、私にとっての FileMaker ですかね。当時は PHP と言われても出版社、Ruby と言われても宝石、JavaScript と言われたらブラウザ側で無効化しておいた方が安全なもの、くらいなイメージでしたから、本当に無知な雛そのものでしたよ（笑
FileMaker での開発体験全般
野口: では、ここから FileMaker ならではの開発や、他の言語での開発経験が FileMaker 開発にどう影響するか、あるいは足かせになるか、といったテーマに入りましょう。また FileMaker の好きな点や開発におけるこだわりについても話していけたら、と。
関口: はい。
野口: まず私から話しますと、最初に FileMaker を経験して、それと関連するかたちで XSLT 言語から、 PHP へ行って、そのあとで HTML + CSS + JS に。あとは原理的なところ、オブジェクト指向や関数型の開発とは何かとか。Ruby やら Haskell やら Lisp やら色々と、常に同時並行でやっていました。他を学べば学ぶほど、FileMaker での作り方へも良いフィードバックがあり、より効率的になったりとか。「あー、こういう思想を FileMaker 開発にも取り入れたほうがよいな」みたいな学びの部分がすごく大きかったんですね。
関口: なるほど。
野口: もちろん逆に、なんで FileMaker はこれができないんだろう、他だったらこんなこともできるのに、っていうのも感じるようになりました。
関口: ありますよね。
野口: さらに逆に、他で苦労することでも FileMaker だとここまであっさり行くんだな、みたいなこともあり。それぞれのメリット／デメリットがはっきり見えるようになったのは、とても自分のためになったなっていう実感がすごく大きくあります。関口さんのほうは、そのあたりはいかがですか？
関口: 同じように数えきれないくらいありますね。私の場合、まるっきり昔の経験が FileMaker で役に立つかっていうとそうではなくて。FileMaker に合わせて考え方をちょっとコンバートしながらやっていくような。設計にしても、開発にしても、やっぱりスパンからして全く違うので。
野口: 時間感覚、全然違いますよね。
関口: 設計に半年かけてましたっていう現場においては、むしろ半年でも短いみたいな感じだったりするんですよ。一方で FileMaker であれば、設計の期間って短ければ 0 日ってこともあるじゃないですか。
野口: ありますねえ。
関口: 話を聞いたら、だいたいこういうシステムが出来上がるよね、っていうようなことが見えるし、実際に実装できちゃうっていうところが、FileMaker の一番のメリットだと思います。ただ、そうは言いつつも、闇雲に頭に描いたもので作っていくと、拡張性がなくなったりします。いかにそのあたりを担保するのか、っていうところで、やっぱり設計って大事だなと戻ってきますよね。
野口: ですね。
関口: いかに短い期間で設計を長く取らずに、納得できる品質のものを実現できるか。例えば、設計内容を単純にドキュメントとして残すのではなくて、FileMaker の中に残すとか。たとえば取扱説明書を作らないとか。取説がなくても使えるようにする方が大事ですよね。
FileMaker におけるテストやバージョン管理
関口: ただ一点、 FileMaker におけるテストの問題。これはもう、長年のもやもやです。
野口: わかります。難しいんですよね。
関口: 他の言語であればテストの自動化についてのノウハウはたくさんあります。それに慣れてたので、FileMaker テストってどうやるんだっていうのが全くわからなかったです。最初の頃は、誰に訊いても答えてくれなくて、公開動画やガイドブックを見てもテストについてはほとんど触れられてないというのが現実で。でもきっと、何かしら誰かテストをやっているはずだと。
野口: テスト用のツールが圧倒的に足りないというのと、構造上無理だよねっていうところがあったりもしますよね。少なくとも、FileMaker Server に共有されている実体に対して直接テストをおこなうのはありえないから、別途、開発環境用のものがなくてはならない。また、データは分離モデルにしておかないと厳しいよねとか。
関口: はいはい。
野口: 基本的にユニットテスト、特にスクリプトとか関数とかのユニットテストばっかりになっちゃって、なかなか結合テストが難しかったりとか。あと、ヴィジュアルリグレッションテストなんて全然できないですよね。まあ、もはやそこについては、同一環境で、レイアウトモードでこのように作られていたら基本的には同じように表示されるはずだっていう、FileMaker Pro / Go というプラットフォームを信じろ、っていうものになっているということだとは思うのですが。
関口: そうですね。
野口: 通常想定されている種類のテストを FileMaker にそのままあてはめようとするのは、もう、無理がありますね。
関口: 無理ですよ。FileMaker でテストファーストにするのは、何だろう、コストが高すぎるっていう感じがするんですよね。でも品質を担保しなくてはならないというところを、どうしたらよいのかな、っていうのが、本当に悩んでます。
野口: 無人テストがしづらいっていうのもありますね。クライアントの UI として FileMaker Pro / Go が必要になってしまう。たとえば WEB ブラウザにおける Selenium のようなものがないので、裏側で走らせてテストさせるみたいなこともできないんですよね。
関口: そうなんですよ。
野口: FileMaker と他の言語での開発での一番のギャップを感じたのは、テスト文化ですね。WEB 開発においても、「テストをやるのが当たり前だよ」って、まあこの十何年でだいぶ浸透したのかなーと思います。「テストをやってないって、ありえないよね」みたいな空気感は、もう 20 代までぐらいの若手開発者だったら、当然のようにあるかな、と。で、若手の FileMaker 開発者を養成しようとするなら、その「テストがない」っていうのがネックになりそうです。「本当にそれ、プラットフォームとして大丈夫なの？」と思われてしまう。また CI/CD みたいなものも、なかなかどうして構築しようもない……みたいなところが出てきちゃうっていうのが……
関口: 難しいですよね。
野口: 結構カルチャーギャップが大きいです。
関口: そうですね。あともう一つ、バージョン管理ができない。できないっていうか、やろうと思えばできる……？ けれど……
野口: 合うツールが無いですよね。バイナリファイルだし、データもひっくるめてのファイルなので、バージョン管理が非常にやりにくい。
関口: みんなどうしてんだろうなっていう風なことは本当に知りたいというか、まずやってるのかどうか……やってないところが多いのかな。
野口: 多分、やっていらっしゃるのはバイナリファイルそのものの、差分バックアップが中心ですよね。じゃあ、差分バックアップとったこちらのファイルと、あちらのファイルとで、バイト数がこれだけ違います、最終修正日も違います、ということが分かるとして、じゃあ具体的に中身として、どこがどう変わっているんですかっていうのが、実際に目で見て確認しないと分からないですよね。しかも、「最終編集履歴」みたいなメタ情報を持っているわけでもないので、とにかく目サーチになる。
関口: そうなんですよ。
野口: じゃあそれをある程度のところ解消するにはどうしたらよいかってことですが、DDR の出力以外でも XML 出力ができるようになったので、Git 管理でリポジトリサービスを使ってテキストベースにしたら、まあ差分の変化は見えるようになります。
関口: はい。
野口: ちなみにこのあたりのこと、今度 2024/02 に FM-Tokyo でお話しさせていただくことになったので、開催終了後に資料ができたらここに貼るとして……
関口: おおー。
野口: そうやれば変更はわかるんですよ、変更は。ただ、じゃあその XML テキストをベースにして、この一部分だけを戻したいってなったときに、取り込むことができない。XML はエクスポートできるけれど、インポートできないんですよね。ここの、このテキストをちょっと変えて、それをインポートし直します、とかができない。XML 情報を .fmp12 ファイルに再変換します、みたいなことができれば、めちゃくちゃ楽なんですけれど。
関口: そうなんですよ。もう一声、なんですよね。
野口: インポートできるでしょう、だってエクスポートできたんだから。
関口: ほんとそう、そこが。もうちょっと頑張ってほしいなって、私もすごく思ってるんですよね。
野口: ただ、これって Git を使ったバージョン管理っていう、他で経験がなければ、FileMaker 開発しかずっとやってなかったら、そもそもやろうという発想に至りづらいですよね。発想できないのが悪いとかいう話ではまったくなく。なので総体的な希望の声も上がりづらかったりするのかなあと思いましたり。
関口: 確かにそうですね。他の点でも、スクリプト作成環境まわりがとても貧弱に感じられて、「私の選択、間違ってたかな？」って思ってしまったこともあったくらいです。そのあたりも徐々に改善されて、 今やっとここまで来たっていう感じがしているんですよね。そもそもが「ローコード」だから仕方ないか、って思うところもちょっとあります。
野口: 「ローコード」だったとしても、例えばスクリプトに、その「最終編集日時」、「最終編集者」、「全体に対するコメント」、みたいなものって、メタ情報として持たせることができると思うんですよ。
関口: 持ってほしい。
野口: それが今、運用でカバーというか……スクリプトの冒頭部分にコメントで、「誰々がどういう風に変更しました」、「このスクリプトの目的はこうです」、みたいなのを書こうという開発ルールもあったりするじゃないですか。いやいやそれはそれは……っていう。
関口: そのコメント、本当の情報ですか、っていう思っちゃう。
野口: 自分もそのルールはあんまり採用していなくて。というのも、あそこのコメントと実態が解離しちゃう、っていうのが一番怖い。
関口: そうですよね。
野口: マナーのある、良いお作法のできる人が、冒頭コメント残していました。でも、別の方、お作法を守ってくれなかった方がいたとしたら、コメントには手を入れずにスクリプトの処理にだけ手を入れてしまうということが起こりうる。そうなると、実体とコメントがずれちゃいますよね。これほどに害があるものってないよなーって。それなら冒頭コメントなしで、しっかり都度都度、処理全体を読んで判定する方が良いくらい。
関口: そこを担保する何かが欲しい、って思うんですよね。
野口: ですよね。いや、本当に本当に。
あらためて FileMaker の良いところ
野口: そういう要望もありつつ、とはいえやっぱり FileMaker だよねー、みたいなに思える FileMaker の魅力や強みって、どういうところだと思います？
関口: FileMaker の強みは、本当に IT に詳しくなくても、それなりにシステムが作れるっていうところだと思ってます。私、さっきテストの話をしたけれども、テストなんてそんなにしなくてもなんか動いちゃう、っていうところも、これはこれですごいなと思っていて。本当にリテラシーも人手も足りずに、それでもなんとか回さなきゃいけないところにとっては、すごくメリットがあると思います。
野口: はい。
関口: それと API を使おうとした時に、スクリプトステップ一つで済むっていうのが、超感動です。「これだけで済むんだ！」って。他だったら色々とこう、ライブラリを入れてそこからさらに何行か書かなきゃいけない。それが、この一行で済んじゃうんだっていうのが衝撃的。これって FileMaker にとっての起爆剤になるんじゃないかって思ったんですよね。
野口: 「 URL から挿入」ステップですね。
関口: 16 からオプションが豊富になって、サードパーティのプラグインを使う必要がなくなりました。それから色々な API を試すようになると、FileMaker 以外の世界に広がっていきます。これが本当に簡単に使える！ 「どうしてこの FileMaker の凄さが分からないのか！」と少しキレ気味になったこともありました（笑
野口: そうですねー……喩えるなら……日本に生まれると、蛇口になったら水が出る、シャワーも浴び放題です。一方で、砂漠の中東に行ったら水は使えないけれど、オイルはジャブジャブです、みたいな。これが恵まれているなー、みたいな自覚って、やっぱり別の土地に行ってみないと分からなかったりするじゃないですか。
関口: すごい、わかりやすい。
野口: そういうことなんじゃないかなと思いました。
関口: あとは FileMaker の良いところって、日本人の好みに合っているというのもありそうです。
野口: といいますと？
関口: FileMaker って、データ、レイアウト、スクリプトがオールインワンになっていますよね。それ以外のものを、ごちゃごちゃと用意しなくてもいいというのが、日本人的な感覚に合うんじゃないかと。抱き合わせ販売って大好きだったりするじゃないですか。
野口: ああー、まあ、余計なことは考えなくてよいみたいな。
関口: セキュリティの部分も、そう深く知っていなくても、ある程度は担保されてるし。ライセンス利用料を払い続けておけば、範囲限定的に使えるっていうのがあるので、中小企業でも運用していけるんだなって思っています。
野口: ものすごくモノリシックの塊みたいな感じじゃないですか、FileMaker って。疎結合とかマイクロアーキテクチャとかとは、もう全くの無縁っていう感じの存在。全部これ一つ、 .fmp12 っていうファイルをとりあえず動かすだけで、もう全部済みます、と。例えば Ruby で Rails でアプリケーション作るなら、 Model, Controller, View を理解し、別途データベースを立てておかなきゃいけないし、公開するためにはラックサーバが……みたいに、あれとこれとこれとこれとこれと……って組み合わせていって、やーっと一つのものになりますよ、と。そういう小難しさとは無縁。まあ、良くも悪くもっていうところではありますけれども。
関口: そうなんです。
野口: そんな FileMaker 開発の、モノリシックな状態にすごく慣れていらっしゃる開発者の方々がたくさんいる中で、一方で AWS や GCP のような、マイクロアーキテクチャ指向のプラットフォームが流行っているというのが、やや不思議に思っています。今、クラウドで FileMaker Server 立てますってなった時に、やたら AWS を使っている人が多いよなー、と。
関口: たしかに。
野口: 冗長構成とらないなら、VPS 一つポンと借りちゃった方が全然安いし、シンプルに全部揃ってますよ、みたいな感じになるんですけれどね。ちょっと謎です。
関口: 謎ですよね、なんでだろう。ただ最近は、FileMaker Cloud を選ばれるクライアントさんが多いですね。
野口: えー、増えてるんですね。
関口: やっぱり、考えなくていいっていうのが楽みたいです。
野口: なる……ほど……FileMaker Cloud に関するコメントは控えておきます（笑
関口: （笑
野口: 安心感という点が出ましたけれど、後方互換については FileMaker は本当に素晴らしいなと、敬意を持っています。基本的に破壊的な変更をほとんどしない。たとえば計算式のふるまいが大きく変化するということは、バグ以外ではまずないですよね。それから、むかーしに作った .fp7 のファイルであっても、コンバートしたら何も問題無く .fmp12 ファイルとして動いちゃいますよね。同じことを Microsoft の Windows に対しても思っていて、20 何年前に作られた .exe ファイルとかがいまだに最新の Windows 上で動いてくれることの凄みたるや。Apple はもうなんていうか、完全に捨て去る姿勢じゃないですか。
関口: そうですね。
野口: Claris は Apple の子会社なのに、そこは相反して、後方互換をものすごく大事にしているのが素晴らしいです。
関口: そうですね、安心して使える点ですよね。
横のつながり、コミュニティ
関口: 次の話題として、横のつながりについて話したいと思っています。今、他の技術者さんと知り合う機会が本当に少ないんですよね。以前、FileMaker 以外を軸足に置いていた頃は、勉強会とかサミットとか、行けば誰かしらとつながりができるっていうのが常だったんです。
野口: なるほど。そういえば 2024/02 のデブサミに参加予定なんですよね。
関口: はい、リアルで。羽田へ行きます。
野口: グラブルのセッションがもう満席になってましたね。デブサミとかへ行っても、この空間で FileMaker を知ってる人って、どれぐらいいるんだろう……みたいなことを、たまに思っちゃいます。
関口: はい。参加しても隣の人と会話がないぞー、って。
野口: ノーコード／ローコードの祭典！ みたいなイベントがあっても、なんか FileMaker ネタで登壇されることがなかったりしますよね。FileMaker って、すごくその、一大勢力的な感じがするんですけれど、それ以外のノーコード／ローコードツールと一線を画されてしまっているような……知名度もあるはずなんですけれど、なんかすごく方言めいてしまっているような。
関口: ありますよね。FileMaker だけの勉強会というのもありますけれど、そこもそこで、「既に出来上がった場」だなーっていう風に感じてがちで、「いや、ここ、私が入っていっていいのかな……」って……
野口: ものすごくよくわかります。でも FM-Tokyo は参加されているんですよね。初参加って、いつなんですか？
関口: コロナ禍でオンライン開催もされるようになってからですね。コロナ前の頃は、サポータスさんの、不定期に集まる会があって、それにはちょっと顔を出していました。
野口: なるほど。今って、FileMaker 以外の方々とのお付き合いみたいなのって、あんまりないですか？
関口: 全くないです。夫婦で IT 業界なんで、そこで会話できるというのがあったりもしますけれど、それ以外だと全く。
野口: コミュニティって、世代とか年齢とか性別とか、いろんな区切り方で集まりようがあるじゃないですか。
関口: はいはい。
野口: そういう別の観点での区切り方で参画していこうかなー、という考えって、あるんですか？
関口: 一つのところにどっぷり、というよりは、いろんなところに顔を出したいっていうのは、ありますね。他の世界を知りたいっていうか、自分の視野を広げたいっていうことで、2023 年にはハッカソンにも 2 つ出ました。自分に足りないところが何かを知って、それを補うために勉強しています。FileMaker をベースにしていますけれど、他の技術を持っている方達との交流を深めていきたいですね。デブサミへの参加もその一つで、私、開発の裏話的なところってすごい大好物なんですよ。心の栄養になります。
野口: あー、わかります、わかります。なんか、プロテイン入りのチョコバーを食べてるような感じですよね。
関口: そうなんですよ。なんかこう、ぎゅっと濃縮したものがそこにある、みたいな。
野口: 私も、ピティナの CTO 時代、ピープルマネジメントがすごく多かった時、行きたいカンファレンスとかにオンラインですら全然参加できない時期が続いていたことがありまして。もうなんか、カラカラに乾いた砂漠みたいな感じだったんですけれど、半年以上ぶりとかでカンファレンスに参加できた時には、染みわたりましたね。料理において、最高の味付けは空腹だ、と。
関口: そうなんですよ、わかります。野口さんは、コミュニティとの関わりってどうですか？
野口: 特に、CTO だった頃は、選んだ技術におけるコミュニティをウォッチしていましたね。数え切れないくらい色々と選定してきましたけれど、実際に導入するまでの間に、個人でも使って肌感を掴んで、他の利用者からも生の声をかき集めるようにしていました。書籍とか WEB の記事やそれこそドキュメントだけだと得られない情報を掴むためには、コミュニティに入ってみるというのは大きいですよね。まあ良いこと書いてあるけれど、ぶっちゃけ実際のところどうなん？ っていう。
関口: なるほど、生の声。
野口: そこで実際に使っている人たち、あるいは開発の責任を持っている人たちの声を直接聞いて、これなら大丈夫っていう確信が得られてから、使い始めるのがリスク回避に繋がります。また、使い始めたからにはやっぱりその使い始めた後になって、これってどうなのかな、みたいなのが出てきますから、ずっとアンテナを張り続けることになりますよね。どのようにして進化していくのか、あるいは停滞／衰退していくのか。みんなが使い続けてユーザーが増えてくれるのか、つまりエコシステムが充実していくのか。それとも、思ったほどには全然使われなくて消えてしまうのか。Google トレンドとか、ああいう数字だけで追いかけるんじゃなくて、自分の肌感・温度感で、しっかりと感じ取っていなきゃいけないっていうふうに思っていますね。
関口: なるほど、技術選定の観点でのコミュニティとの関わりが大きいんですね。少しズレるかもしれませんが、持っている技術を、どのように活かしてビジネスに繋げていくのかっていうのが、受託開発だけだと、そこまで意識しないんですよね。
野口: そういうものなんですね。
関口: この技術を使いたい、っていうところはあったりするんですけれど、そうじゃなくて、この課題を解決するためにこの技術を使う、っていうモノの見方。これが、ハッカソンに参加するにつれ、自分の中で育っていく実感もありました。離れたところから見聞きしているだけでは全くわからない、実際のところ、っていうものに触れられるのが面白いですね。
今後の展望
関口: 実は、今年から新しいことを始めようと思っています。
野口: おおー、新事業ですか。
関口: 先ほども少し触れましたが、システムを求める人の立場に立つことが少なく、それがネックになっていると感じていまして。技術者としての視点だけでなく、事業者の視点で物事を考えることができるようになる必要があるな、と。そう思って、インターネット上での通信販売を始めたんです。
野口: どのような商材を取り扱われているんですか？
関口: 主に手作りのものですね。今着ている、このカーディガンだったりとか、日常着、それからお出かけ着なんかも、自分で作っています。
野口: すごい！ それって、こう、大きい布を買ってきて、自分で裁断して、縫うんですか？
関口: はい、そうです。パターンは購入して使っています。商用 OK のものを使って、ショップとして展開して売るつもりです。ただ、単純に売るだけでは他との差別化が難しいので、付加価値をどうつけるかということを考えています。
野口: いやすごいですね、本当に。商品管理や顧客管理は、自作のシステムでおこなう予定ですか？
関口: そこですね、その必要性を検討する機会になると思っています。既存の販売システムを使って十分かどうか、あるいは自作しないといけないのか。とにかく、システム構築のためのシステム構築、みたいな、過剰さを避けるようにしないとって思います。
野口: そのためには、FileMaker を使わなくても良いということですね？
関口: そうですね。
野口: なるほど、それは良い考えだと思いました。同時並行して開発業務もあるかと思いますので、忙しくなりそうですね。
関口: はい、でも、中長期的に間違った方向へ進まないようにするために必要なことかな、と。今年は挑戦の年ですね。
野口: ほんと挑戦ですね。自分で作って販売するのだけでも大変ですし……発送も自分でおこなうんですか？
関口: はい、今のところはその想定で、ただ、一人で全てやることができるかどうかは未知です。
野口: なるほど。例えば、Amazon のフルフィルメントサービスを利用するとか、そういう選択肢も？
関口: はい、視野には入れています。使うにあたっては面倒くさい部分もあったりすると思いますが、それについても肌感覚を得たいですね。広げすぎると縮小するときに大変なので、まずは 1 か所で始めようと思っています。minne という、手作り品の販売プラットフォームがあるので、そこからやってみます。
野口: BASE や Shopify のようなものを使うのでもなく、プラットフォームに乗っかるということですね。私も、この対談記事を note に掲載するという選択をとったので、すごくよくわかる判断です。……あと、何か「これを話しておきたい！」など、ありますか？
関口: そうですね、あとひとつ。実は、「FileMaker テスト手法を考える会」というのを立ち上げていまして。
関口: 2023/04 以降、あまり活動ができなかったんです。今年は、もう一度エンジンをかけ直したいと思っています。
野口: 良いですね！ FileMaker におけるテストの問題は、先ほども大きく話題になりましたからね。ちなみにその会の活動を通じて、これまでにどのような成果がありましたか？ どこかで、途中経過など確認できるようになっていると、これから参加したいという人も、合流しやすいのかなと思いました。
関口: 標準化やガイドラインのようなものがあれば、開発がよりスムーズになると思っています。なので、ルールやドキュメントを作ろうとしていますが、今時点では、具体的にどこかに公開したりまではできていないんです。
野口: なるほど、そうなんですね。そうしたら例えば、GitHub に Organization とリポジトリを作って、そこで中間成果物を共有したり、議論したりするのはどうでしょうか？
関口: それは良いアイデアですね！
野口: 日本語だけでなく、英語や他の言語での開発者も巻き込むことができれば、拡がりますね。よし、じゃあ、早速こちらで作っておきますね。
野口: ……はい、作っておきました！ 今後こちらで進めていきましょう！ 本日はありがとうございました！
関口: ありがとうございました！
後書き
野口です。ここまでお読みいただきありがとうございました。
前回が私自身で ChatGPT との対談でしたので、実質 2 回目の対人対談となりました。
関口さんというと Qiita での FileMaker Advent Calendar を毎年主催いただいている方！ という印象がとても強く、実際に対談のトピックも全体として FileMaker 成分多めとなりました。
語られている内容については、多くの FileMaker 開発者の方々も同意いただけるようなものになっているのでは、と思います（というか共感して欲しい……！）
一方で、FileMaker 開発に入られる以前に、たくさんの低級～高級言語を触れられていたということは前知識としてありませんでしたので、とても興味深く話を伺えました。
ここに掲載しきれていないような PC 自作話のマニアックな盛り上がりなどもありました😂
また、関口さんによる楽屋裏記事は以下となりますので、こちらもあわせてご覧いただけたら幸いです！
関口さんによる楽屋裏記事
記録
対談日
2024/01/12
GitHub 上でのファイル
https://github.com/Kimi-Yori/TalkWithThisPerson/blob/main/articles/0003.md
この記事が気に入ったらサポートをしてみませんか？