ソフトウェア開発における インターフェイスという考え⽅ ⼩⼭健⼀郎 / Tailor Inc. 2025.3.22 PHPerKaigi 2025

少し実⽤的で⼩さなOSSを書くのが趣味 ● GitHub: @k1LoW ● X: @k1LoW ● SWE at Tailor Inc. ⼩⼭健⼀郎 ⾃⼰紹介 2 Ken'ichiro Oyama

● インターフェイス ○ 様々なインターフェイスからみえるインターフェイスの特性 ● ソフトウェア開発におけるインターフェイスという考え⽅ ○ 何をインターフェイスとみるか ● まとめ アジェンダ 3

● 本セッションは、普段私がソフトウェア開発において意識している「インターフェイスという考え⽅」に ついてできる限り⾔語化するもの ● ただ⾔語化しても伝わりにくいので、様々なインターフェイスを紹介しつつそれらの特性や共通点などから 導出していくことを試みる ● ⚠広く合意された意味のインターフェイスではないので注意⚠ ソフトウェア開発におけるインターフェイスという考え⽅ 4

5 インターフェイス

● interface /ˈɪnɝˌfeɪs/ ● 接点。境界⾯。界⾯。 ○ 点とか⾯ ● 結び付ける。繋ぎ合わせる。 ● ITの分野からみてもあまり違和感がないように思える。 ⼀般的な意味でのインターフェイス インターフェイス 6

● AとBの境界がインターフェイス？ ● AとBの接点がインターフェイス？ ⼀般的な意味でのインターフェイスのイメージ インターフェイス 7

ref: https://www.php.net/manual/en/language .oop5.interfaces.php インターフェイス 8 PHPのオブジェクトインターフェイス Interface（オブジェクトインターフェイス）

"オブジェクト インターフェースでは、クラスが実装すべきメソッドやプロパティの 宣⾔だけを⾏うコードを作 成できます。ここでは具体的な実装は必要ありません。 インターフェイスには、ふたつの互いを補完する役割があります。 1. 同じインターフェイスを実装していることで、 開発者が交換可能な異なるクラスを作成できるようにします。 2. メソッドや関数が、インターフェイスを満たす引数を受け付け、 操作できるようにします。" ref: https://www.php.net/manual/ja/language.oop5.interfaces.php ● 事前にインターフェイスを定義し、それを満たすクラスを実装するという「制約」 を設けることによっ て、 ある種の秩序 を提供しているといえる Interface（オブジェクトインターフェイス） インターフェイス 9 PHPのインターフェイス

ref: https://go.dev/tour/methods/9 インターフェイス 10 Goのインターフェイス interface型

"interface(インタフェース)型は、メソッドのシグニチャの集まりで定義します。 そのメソッドの集まりを実装した値を、interface型の変数へ持たせることができます。" ref: https://go-tour-jp.appspot.com/methods/9 ● Goでは、型がインターフェイスで定義された全てのメソッドを実装していれば、その型は⾃動的にイン ターフェイスを実装したことになる。 ○ 明⽰的な implements キーワードは不要。 ○ ダックタイピング "If it walks like a duck and quacks like a duck, it must be a duck" ● Goのインターフェイスは値を使⽤する側（インターフェイスを満たす実装を使⽤する側）が定義する。 ○ "Go interfaces generally belong in the package that uses values of the interface type, not the package that implements those values." ○ ref: https://go.dev/wiki/CodeReviewComments#interfaces interface型 インターフェイス 11 Goのインターフェイス

● 「全てのメソッドを実装していれば」ということなので、その実装すべきメソッドがないのであれば、あ らゆる型が interface{} を実装したことになる。 ● つまり「任意の型を受け⼊れる」という使い⽅ができる ○ 個⼈的にとても感動した ● 今では any というエイリアスがはられている interface型、メソッドをゼロにしたらどうなる？ コラム 12

● Graphical user interface ● アイコン、メニュー、ボタンなどの視覚的要素を使 ⽤してユーザーインタラクションを可能にするイン ターフェース ● （以下個⼈の感想） ● Webにおいては「UI」と呼ばれるものと強く関連が あるインターフェイス ○ UI ... ⼈間と機械の間のインタラクションポイ ントであり、視覚的、聴覚的、触覚的な要 素。 ○ 使いやすさ、効率性、アクセシビリティ、お よび美観に影響を与えることで、ソフトウェ アの成功を左右すると⾔える。 インターフェイス 13 GUI

● Command-line interface ● ユーザが⽂字列（コマンド）を⼊⼒してプログラ ムに命令するインターフェイス ● ref: Command-line interface tool design / PHPerKaigi 2024 ○ https://speakerdeck.com/k1low/phperk aigi-2024 インターフェイス 14 CLI

● プロトコルやエンドポイント、リクエスト/レス ポンスのフォーマットの規約の集合 ● OpenAPI SpecやProtocol Buffersなどによるス キーマは、まさにインターフェイスの定義 インターフェイス 15 Web API

16 様々なインターフェイスからみえる インターフェイスの特性

インターフェイスの設計は 使⽤者の体験に繋がる 17

様々なインターフェイスからみえるインターフェイスの特性 18 A C

● 使⽤者に対して表出しているのがインターフェイ ス ● USB Type-AもUSB Type-Cもユニバーサルな接続 規格であり電源供給の仕組みでもあることは同 じ。しかし、表裏（上下）がなくなったことによ る使⽤体験向上はとても⼤きい ● UIはUXに繋がる -> IはXに繋がる ● インターフェイスは使⽤者の体験に繋がると捉え て設計しなければならない ● 「⾒てわかる。使ってわかる」 視覚的、触覚的 （聴覚的）肌触りを意識しないといけない 様々なインターフェイスからみえるインターフェイスの特性 19 インターフェイスは使⽤者の体験に繋がる

インターフェイスは契約 20

"どんなサービスやアクセスを提供しようとするのか。 インターフェイスというのは要するに提供者と顧客の 間の契約だ。使いやすく、収拾がつかなくならない程 度に⼗分な機能を装備した、画⼀的で便利なサービス を提供することが望ましい" Brian W.Kernighan, Rob Pike. 「プログラミング作法」 第4章 ● 契約が不明瞭であってはならない ● 契約は安易には変更できない（してはいけない） 様々なインターフェイスからみえるインターフェイスの特性 21 インターフェイスは契約

● 値を提供する側が定義する ● 提供する側からの契約を提案する形 「このインターフェイスを使⽤してください。それを満 たした値を提供します」 様々なインターフェイスからみえるインターフェイスの特性 PHPのインターフェイス ● 値を使⽤する側が定義する ● 使⽤する側からの契約を提案する形 「このインターフェイスを満たしていれば受け⼊れま す」 Goのインターフェイス 22 PHPもGoもインターフェイスは契約

● "Deleting fields can cause serious problems if not done properly." ○ ref: https://protobuf.dev/programming-guides/ proto3/#deleting ● Protocol Buffersはメッセージをバイナリ形式でシリ アライズするが、それにフィールド番号を使⽤して いる。 ● 使わなくなったからといって安易にフィールド番号 を詰めると、メッセージを正しくデシリアライズで きなくなる。 ● フィールド番号を使われないように確保するために reserved キーワードがある。 様々なインターフェイスからみえるインターフェイスの特性 23 Protocol Buffers 契約であるがゆえに安易に変更できない

"インターフェイスの裏にある実装は、プログラムの他 の部分に⼀切影響や⽀障を及ぼすことなく変更できる ように隠しておく必要がある" Brian W.Kernighan, Rob Pike. 「プログラミング作法」 第4章 ● 表出しているということは使⽤者から使⽤できて しまう。 ● 使⽤者が契約の⼀部と考えてしまう。 ● ⼀度使われてしまうと、安易に変更できない。実 質的に契約となってしまう。 様々なインターフェイスからみえるインターフェイスの特性 24 「実装の詳細は隠蔽されるべき」とはどういうことか(1/2)

"マイクロサービス間でAPIをやり取りする中でいい感 じの場所を探したら、metadataっていうなんでも含め られるフィールドを誰かがみつけたんですよね。ここ に⼊れておけばあとで表⽰の時に使えるじゃん！っ て。 （中略）そこで、metadataをセットしなきゃいけない んだけど、何をセットすればどういう表⽰に変わるの か、調べるのがすごく⼤変だったんです。" メルカリ技術書典部. 「Unleash Mercari Tech! vol.4 ~ メルペイ⽴ち上げ当時に戻ったら？~」 ● あったら使われてしまう 例 様々なインターフェイスからみえるインターフェイスの特性 25 「実装の詳細は隠蔽されるべき」とはどういうことか(2/2)

26 インターフェイスには インタラクション（相互作⽤）がある

● インターフェイスとして、ボタンが⽤意されてい るのであれば、使⽤者は押す必要がある。（使⽤ 者への作⽤） ● ボタンとして⽤意されたことで、連打されてしま うかもしれない。（提供者への作⽤） ○ 本当はレバーとして⽤意すべきものだった のかもしれない。 ● 両⽅の作⽤を考慮してインターフェイスを考える 必要がある 様々なインターフェイスからみえるインターフェイスの特性 27 インターフェイスにはインタラクション（相互作⽤）がある

● インターフェイスは使⽤者の体験に繋がる ● インターフェイスは契約 ● インターフェイスにはインタラクション（相互作⽤）がある インターフェイス（と呼ばれているもの）はいたるところにある 「インターフェイス」という考え⽅をする上で意識しておいて損はないものばかり インターフェイスの特性まとめ 様々なインターフェイスからみえるインターフェイスの特性 28

ソフトウェア開発における インターフェイスという考え⽅ 29

30 何をインターフェイスとみるか

API (NOT Web API) 31

● 関数のシグネチャもAPI。提供者と使⽤者が存在する インターフェイス ○ 引数だけでなく関数名もその機能の使いやす さに影響する。いわゆる 「名前重要」 。 ○ 当然、返り値のデザインも重要（相互作 ⽤）。 ● 複数の関数をまとめたパッケージもインターフェイ ス ○ 使⽤者体験のためにどのようなデザインにす るか。何を⾒せて何を⾒せないのか。 ● 「機能を実現できれば良いわけではない」ことがわ かる 何をインターフェイスとみるか 32 API (NOT Web API)

● 例えば関数のテストは、その関数のシグネチャで は表現できないインターフェイスの挙動の詳細を 表現する 側⾯がある ○ 関数の挙動⾃体は表出しているもの（契 約）。 ○ 関数の責務をテストで表現する。 ● E2Eテストもユニットテストも同じ。 ○ インターフェイスの使⽤者がソフトウェア のユーザなのか、隣で⼀緒にソフトウェア を開発しているエンジニアなのかの違い。 何をインターフェイスとみるか 33 テストはインターフェイスの契約の特性を強固にするもの

34 エラーメッセージ

"しかしそれ以外にも重要なインターフェイスが存在する。 プログラムとそれを使う⼈間との間のインターフェイスだ" Brian W.Kernighan, Rob Pike. 「プログラミング作法」第4 章 ● エラーメッセージやアラートもインターフェイス。 ● エラーメッセージに、内容、原因等を過不⾜なく⽰ すことで、ユーザに次のアクションを促す。 ○ そのまま「次のアクション」をエラーメッ セージに含められるとさらに良い。 ● エラーメッセージやアラートからソフトウェアの使 ⽤体験を向上させる。 何をインターフェイスとみるか 35 エラーメッセージ ref: https://speakerdeck.com/biwashi/runbook-to-minimize-operational-costs-using-automated-code-generation

データベーススキーマ 36

● DDL。データベーススキーマ。 ○ スキーマはOpenAPI Spec、Protocol BuffersといったWeb APIだけではない。 ● 「このようなテーブルと制約でデータストアとし て機能しますので使ってください」というRDBに ⽤意されたインターフェイスと考える。 ● テーブル名やカラム名だけでなく、制約も駆使し てインターフェイスとしての意図＝契約を表現す る。 ● （⼤抵は）テーブル名/カラム名の全てが使⽤者 に公開されているからこそ慎重にデザインする必 要がある。 何をインターフェイスとみるか 37 データベーススキーマ

38 まとめ

● Everything looks like an interface.（全てがインターフェイスに⾒える） ● 今回の内容（特に後半）は、普段はおそらく「インターフェイス」とは呼ばれていない。 ● 「インターフェイスという考え⽅」は、みなさんも空気のように当たり前に⾃然と意識していることだと 思っている。 ○ 「インターフェイスのような特性が必要な箇所はソフトウェア開発のいたるところにある」というメ ンタルモデル ○ ⼀⽅、もう少し強めに意識するだけで開発に新たな視点を得られるものだと思っている。 神々は細部に宿る。 まとめ 39

40 わたしたちは、"Empower every company to deploy any ideas (誰もがデプロイできる社会を創る)" というミッ ションのもと、誰しもがプロダクト開発の担い⼿になることができる社会の実現を⽬指しています。ミッション の実現に向けて、共に挑戦する仲間を募集しています。 https://careers.tailor.tech/ 共に働く仲間を募集しています