安西剛さんの「1on1コーチング体験」を受けてきた：自分の感情を掘り下げる

先日、安西剛（@tsuyok）さんによる「1on1コーチング体験」を受けてきた。安西さんによる参加者募集の記事を以下に示す。

www.tsuyok.work

安西さんとは、5月に開催されたイベント「レガシーをぶっつぶせ。現場でDDD！」の際に初めてお会いした。安西さんはアジャイルやDDDといった面で発信をされていて、以前からTwitterは一方的にフォローさせていただいたので、今回の募集を見た瞬間に「応募しよう」と心に決めていた。

【告知】安西さんは DevLOVE X でも登壇！

なお、安西さんには今週末の「DevLOVE X」でもご講演いただくことになっている。安西さんのご講演「エンジニア、エンジニアリングマネージャーとして成長するために必要なこととは？」は、6月22日（土）13:30-14:10の枠だ。内容は以下の通り。「成長」というポピュラーなテーマについて、コーチングやインタビューの経験に基づくどのようなお話が聴けるのか、楽しみだ。

成長したいと思っている方にたくさんお会いするのですが、具体的にどうすればよいかというのは難しい問題です。そこで、成長とは何か、そのためにはどうすれば良いかということについて考えてみます。

「これまで」のエンジニア、エンジニアリングマネージャーとしての学び、現職でのマネージャー育成コーチングからの学び、エンジニアへの成長インタビュー活動からの学びなどから、ある程度ポイントは絞れることがわかってきました。そのポイントをベースに、「これから」我々はどう学んでいくべきかというところまで考察してみます。

ky-yk-d.hatenablog.com

2回目の「社外の人との1on1」

さて、社外の人との1on1というと、今年の2月にも、nitt-san（@nitt_san）さんによる「いきなり1on1」を受けさせていただいている。下掲はそのときのふりかえり記事だ。

ky-yk-d.hatenablog.com

2月からの4ヶ月の間に、自分の状況も少し変わってきている。2月のときは、自分のスキルやキャリアについての不安感や焦燥感という心理的な側面が重大な関心事だったのだが、「いきなり1on1」の効果もあり、今では良い意味で「腹をくくって」仕事に臨めるようになっている。目下の関心事はより具体的に何を学び、何を経験していこうかというところに焦点が移っていて、その辺りについて気づきやアドバイスが得られればと思って安西さんの「1on1コーチング体験」に応募させてもらった。

自分の感情の動きの契機を知る

今回の1on1でした話のなかで、最も印象に残ったものとして「感情」についてのやりとりがある。

1on1のテーマについて、上で「目下の関心事はより具体的に何を学び、何を経験していこうかというところ」にあると書いたが、これはつまるところキャリアの話だ。キャリアについて考えるときには、生存戦略という合理性*1の観点だけでは足りない。「何をしたいか」や「どんな職場で働きたいか」という問いに答えることはもちろん自分の感情を知ることを要請するし、当人として意識はしていなくても、自分の感情が選択に影響を与えているというのはよく言われることだ。だからこそ、自分の感情の動きの契機を知ることが重要になる。

以前、価値観についての記事（下掲）を書いたことがあったが、感情をそれ自体として強く意識の対象とすることは少なかった。関連しそうなこととして、出来事の記録や自分の気分の上下の把握のため、昨年から「5年日記」というものを毎日つけているのだが、特段感情を掘り下げようとして書いてはいない。今回、安西さんから、記録の手法として「事実・感想・自分の姿勢」という3つを考えるというアイデアをいただいたので、これから試してみたいと思う。

ky-yk-d.hatenablog.com

恣意的な思考停止の一歩先へ

安西さんからは、感情にまつわる様々な問いを投げかけてもらった。例えば、特定の状況についての感情をより詳しく説明しようとするように促していただいたり、似ているが一部条件の異なる状況を想像して、どう感じ方が違うのかを考えてみるようなこともした。それらの問いかけに答えようとするなかで、一つ、気づいたことがある。

それは、普段自分が自分の感情についての分析を恣意的な地点で止めているということだ。一般に、思考をある程度のところで止めるのは、節約という意味もあるので必ずしも否定すべきことではないと思う。しかし、自分の場合、こと感情についてはその重要性に比してあまり深く考えることがなかったので、いいきっかけになった。

あまり普段考えていないレベルで考えたため、問いかけに対して考え込んでしまう時間もあったが、僕が言葉を紡ぎ出そうとするのを安西さんはじっくり待ってくださった。人との対話において、「待つ」ことの大切さはしばしば語られるが、実際にあれほど待ってもらえたことはあまりなかった。普段の自分も「待つ」のが苦手ですぐに説明を始めてしまうので、反省させられもした。

「私は〇〇が好き/嫌いです」はどこまで妥当か

感情を意識の対象とすることについて、代表的な感情として、「好き/嫌い」を例にとってより細かく考えてみよう。普通に生活をしていても、自分の趣味嗜好について思考を巡らせる機会は多い。他人に対して自己紹介をするときにはそれを言語化するだろうし、次に何を勉強するか、どのような時間の使い方をするかを考えるときにも、「どうすべきか」と共に「どうしたいか」を意識する。

「自分の好き嫌い」を意識する機会はあまりにも多いから、いつからか「自分は〇〇が好き/嫌いなんだ」という自己規定は何度も繰り返しているうちに考えなくても言えるようになる。僕の場合であれば、「設計の話が好き」や「UIはあんまり興味ない」などとよく言っている。しかし、それは果たしてどこまで正しく、どこまで深い言明なのだろうか。

自分はあるものが「好き」だと認識していて、それが誤りであることはあまりないだろう。しかし、その好きはどれくらいの好きなのか？なぜそれが好きなのか？と考えてみると、すぐに答えが出せないことがある。ある状況に置かれた自分自身が何かしら肯定的な感情を覚えているしても、その肯定的な感情が状況の中のどのような要員の存在（あるいは不存在）に因るものなのかは案外わからない。

好きだと思っていたのに、環境が少し変わったら急に色褪せて見えるようになってしまったという経験は数多くある。もちろん、人間の気持ちは変化するものでもあるので、それらの全てが避けられたわけではないし、避けるべきものだったわけでもないだろう。とはいえ、これからのキャリアの中では重大な選択を何度かすることになるだろうから、精度を上げるに越したことはない。「アジャイル／DDDが好きだからアジャイル／DDDやっている会社にいこー」というのは安直*2だが、大差のない選び方をしないとも限らない。より細かく考えてみることが必要だと思う。

終わりに

この記事では、「感情」というテーマに絞ってふりかえりを書いた。しかし、当日のセッションでは、上記に止まらない様々なお話をすることができた。アドバイスも多くいただいたが、その中には安西さんが僕の関心を持っている事柄（アジャイルやDDD）についての先人であり、僕が通りそうな道を先に歩んでいる人であるからこそのものが多く含まれていた。これほどまでにぴったりな方に1on1をしていただく機会を得られたことは本当に幸運だった。

貴重な体験をさせていただいた安西さん、ありがとうございました。

*1:何が最適かを見通すのは極めて難しく、現実的には不確実性を免れないのだが。

*2:それでいい転職ができることもあるかもしれないが、「あれ、僕アジャイルがやりたかったのではないでは？」となることは大いにありうるだろう。

JavaにおけるOptionalによるnull安全のための覚書

Java8から導入されたOptionalを利用することで、よりnull安全なコードを書くことができる。ただし、使い方を間違えるとかえってバグを生むことにも繋がる。適切に利用するための覚書を書く。

nullを返す可能性のあるメソッドは、Optional型を返すメソッドに変更する

これがベースになる。Optionalが導入されるまでは、nullを返す可能性のあるメソッドと返す可能性のないメソッドは言語の上では区別できなかった。そのため、nullを返すかもしれないメソッドを呼び出す際には、プログラマがそれを意識した上で、呼び出し元の方でnullチェックを書く必要があった*1。

Optionalを返すように変更することで何が起きるか。Optional型のオブジェクトが戻り値となることによって、そのまま（Optionalから中身を取り出さずに）利用することが禁止されるのだ。中身を利用するためには、Optional型に定義された各種のメソッドを利用する必要がある。同時に、空のOptional（メソッド変更前のnullに対応）が返ってくることを考慮して呼び出すことも強制されるので、「うっかり」nullが画面に表示されてしまったり、NullPointerExceptionをスローしてしまったりということはなくなる。

nullになる可能性のあるフィールドに対するgetterは、Optional型を返すメソッドとする

これは上の原則に含まれているが、意識しにくいものだと思う。通常、getterというと、以下のようなものを想像する。

public class User {
  private String name;
  public String getName(){
    return this.name;
  }
}

このような（しばしばsetterを一緒に書かれる）getterは、Javaプログラマにとっては見慣れたもの（好き嫌いはともかく）だろう。フレームワークがこの種のメソッドの定義を要求している場合もあり、全部を否定するわけではないのだが、Optionalを使ってnull安全なコードを書くという観点からは、この種のgetterは再考に値する。

getterもまた、ひとつのメソッドだ。nullを返す可能性があるのであれば、戻り値の型はOptional型にするべきだ。もしUserのname属性が未設定を許すのであれば、以下のように修正する*2。

public class User {
  private String name;
  public Optional<String> getName(){
    return Optional.ofNullable(this.name);
  }
}

ちなみに、上のようなメソッドを用意する場合、同一クラス内からもフィールドに直接アクセスするのではなく上記のメソッドを利用するようにすべきだ。そうすることで、nullチェックを実装し忘れることを防ぐことができる。このように、外部に対するカプセル化のためのメソッドを自分自身もまた利用することを、自己カプセル化という。Optional型を戻すgetter以外についても使えるテクニックだ。

引数やフィールドにはOptional型を使わない

以上では、メソッドの（nullになる可能性のある）戻り値をOptional型に変更すべきだと書いてきたが、メソッドの（未設定を許容する）引数やフィールドに対しては、Optional型は使わない。

それは、Optional型の引数やフィールドが実行時にnullである可能性を排除できないためだ。下記のようなコードを書いても、思った通りにメソッドが使ってもらえる保証はない。メソッドの利用者は、空のOptionalを渡す代わりに、Optional型のnullを渡すことができてしまう。

public int calculatePrice(Optional<DiscountRate> discountRate){
 // 省略
}

設定を任意としたい引数がある場合には、従来通りnullチェックをメソッド内部で行い、処理を分岐させればいい。一方、nullを許容しない引数については、Javadocコメントにその旨を明記し、実行時にnullが渡された場合に備え、Objects.requireNonNull()等を用いて「防御的プログラミング」を行う。nullを渡さないでくれと言っているメソッドにnullを渡したのであれば、それは利用者側のミスであり、供給者の責任ではない。容赦無くNullPointerExceptionなどをスローして落としてしまえばいい。

参考

*1:nullチェックを怠った結果としてよく見られるのが、ユーザ向けの画面上に表示される"null"の文字列だ。

*2:メソッド名はgetterらしいgetName()よりも単にname()などとした方が良いかもしれない。

Web API の仕様をOpenAPI Specで書いてみて

以前、OpenAPI Generatorの紹介記事を書いた。

ky-yk-d.hatenablog.com

上の記事を書いてから、実際のプロジェクトでOpenAPI SpecでAPIの仕様を書くとともに、その定義ファイルからOpenAPI GeneratorでAngularのクライアントコードを自動生成するということを始めた。まだ課題もあるが、中間報告を書く。

前提条件

今回開発対象としているAPIはサードパーティによる利用を想定したものではなく、もっぱら自社で開発するクライアント（Web/モバイル）から利用されるもの。サーバとクライアントを並行で開発しており、APIの仕様を決めるに当たってはクライアントでの利用のしやすさを重視している。

開発チームとしては、サーバでHTMLを生成する種類のWebアプリケーション開発の経験が長いメンバーが多く、Web API開発の知見はチーム内に乏しい。また、これまで仕様書はExcelがメインであったとともに、構成管理ツールとしてもVSS/TFSに慣れ親しんでいるメンバーがほとんどである。

やっていること

現在は、以下の事柄を実施している。

• OpenAPI SpecによるAPI仕様の記述
• 上記ファイル（YAML）のGitでの管理
• ReDocによるHTMLドキュメントの生成
• OpenAPI GeneratorによるAPIクライアントコードの生成

補足すると、YAMLファイル（およびそこから生成されたHTMLドキュメント）がAPI仕様の正式版ではあるものの、いきなりYAMLファイルを記述するのは辛いので、仕様を検討する過程では一度Excelに記述するようにしている。Excelのフォーマットは、自動生成したHTMLドキュメントの記載項目を参考に作成した。

OpenAPI Generatorのスタブサーバのコード自動生成の機能は、開発の当初の段階では試してみたが、現在は使っていない。クライアントの開発がサーバの開発に先行している場面では、クライアントコードの中にダミーデータを直書きすることで済ませている。また、HTMLドキュメントの生成は、OpenAPI Generatorでも可能だが、見やすいものではなかったためReDocという別のツールを利用している。

github.com

iktakahiro.hatenablog.com

よかったこと：情報の集約

「スキーマ駆動開発」というテーマの特集を読んで導入したOpenAPIだったが、ここまでのところで実感している効用はむしろ、「情報の集約」という側面に関するものである。

具体的には、チーム内で（あまりよくないことだが）よく交わされる「〇〇ってどの資料に書いてありましたっけ」という会話が、Web APIの仕様については全く発生しない。

自社はドキュメントをそれなりに作る会社なので、各種の設計書を作成する際に利用できる標準フォーマットがある程度整備されている。しかし、標準的なものがないケースにおいては、まず大雑把な資料が作成され、プロジェクトが進んで情報が増えていく中でより詳細な、あるいは別の側面からの資料が作成される。その結果、フォーマットの異なる複数のファイルに情報が散逸するということになりやすい。

Web APIの仕様についても、社内には標準がないので、当初は上のような管理が困難な状況に陥りそうになっていた。しかし、OpenAPI Specの導入により、YAMLファイルが単一の情報集約点となった。OpenAPI Specでは様々な情報を記述することができるようになっているから、原則としてYAMLファイルに情報が追加されるようになる。

YAMLファイルには記述しづらい情報のために、補足的な資料を作成することがあっても、YAMLファイルが主たる地位を占めることはチーム内で了解されているので、情報が散逸しづらいのだ。また、OpenAPI Specの仕様で「どのような情報を記述できるか」を知ることは、開発の経験が乏しいWeb APIについて「どのような事柄を考慮すべきか」を考える助けにもなっている。

展望と課題：その他の情報の集約と「スキーマ駆動」

「情報の集約」は、OpenAPIの導入に拠らずとも達成されうるものであるし、本来は達成されているべきものだ。抱えている問題のレベルの低いというのは一方で真理だろう。しかし、自分の現場にとっては、OpenAPIという仕様とその周辺ツール群が、その問題を浮き彫りにすると同時に、解決できるものであることを気づかせてくれた。この気づきを承けて、Web APIの定義以外のドキュメントも、なるべく一箇所に集めるように動き始めている。

一方で、先に述べた通り、スキーマという部分でのメリットはあまり享受できていない。また、各種ツールを利用することによるメリットも最大限享受できているとはいえない。あまり色々やろうとしすぎても大変&混乱を招くのでそこは注意したいが、ツールの導入を少しずつ進めていきたいなとは思っている。

WEB+DB PRESS Vol.108

6月22, 23日に、豪華スピーカー陣によるカンファレンス「DevLOVE X」が開催されます

DevLOVE10周年イベント「DevLOVE X」

きたる6月22日（土）・23日（日）の2日間の日程で、株式会社ナビタイムジャパンさまにて、ソフトウェア開発者向けイベント「DevLOVE X」が開催されます。

devlove.wixsite.com

こちらは、ソフトウェア開発者コミュニティ「DevLOVE」の10周年記念イベントです。DevLOVEは、『カイゼン・ジャーニー』の著者のお一人である市谷聡啓（@papanda）さんが2008年に立ち上げられたコミュニティです。僕は、DevLOVEの運営にここ一年弱ほど関わらせていただいていまして、今回の10周年イベントにもスタッフとして参加します。

すでに市谷さんを中心としたスタッフ陣、それに登壇者の方々からTwitter等で告知をしていただいていますが、こちらのブログでも僕の個人的な思いを添えて宣伝させていただきたいと思います。

豪華スピーカー陣のみなさま

今回の「DevLOVE X」は、総勢60名以上のスピーカーをお招きするカンファレンスという形で行われます。すでにタイムテーブルも公開されています*1。

ご覧のような、「何回分の基調講演ができるんだ」という豪華なスピーカーの方々にご登壇いただきます。

togetter.com

完全に個人的なスピーカーのご紹介（一部）

今回のスピーカーの方々には、僕自身、書籍などを通じて学ばせてもらっている方、あるいは直接的に勉強会等でお世話になっている方が多く含まれています。その中でも、僕がこの業界に入ってからの2年間を振り返る上で欠かせない方々を特に取り上げてご紹介したいと思います。

和田卓人（@t_wada）さん

言わずと知れたt-wadaさん。新卒1年目だった2017年11月に『テスト駆動開発』の新訳が出版され、12月に開催されたイベントで初めて生で接しました。テスト駆動開発というプラクティスを通じて、ドライだと思っていたプログラミングが実は人間の心理と深く結びついた営みであることを教えてもらいました。

テスト駆動開発

広木大地（@hiroki_daichi）さん

『エンジニアリング組織論への招待』の著者。2018年の2月に出版された書籍は、「ソフトウェア開発をこういう風に語れるのか、語っていいのか」という気づきを与えてくれました。僕にこの2年間の中で最も大きな影響を与えた人々の一人と言えます。何とか広木さんの影響圏から脱したいともがいている最中です。

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

横道稔（@ykmc09）さん

「omoiyari.fm」のパーソナリティの一人。omoiyari.fmは、僕がアジャイルやマネジメントというものに関心を持つようになる一因となったとともに、カカカカックさんとの出会いを与えてくれた大切な番組です。伝説の第22回に限らず何度も聴き直しているので、2年間で家族と同僚以外で最も長く声を聴いていた人かも知れません。

lean-agile.fm

カカカカック（@kakakakakku）さん

この人がいなかったら僕はいまこの記事を書いていないでしょう。2018年5月から2ヶ月間、ブログのメンタリングをしてもらいました。影響を受けたというよりも、「生活を規定されている」存在です。僕がブログを書くことを止めるか、僕なりのブログに対する向き合い方を見つけるその時まで、それは続くのだと思います。

kakakakakku.hatenablog.com

参加申し込みはDoorkeeperから

以上、甚だ個人的なご紹介を4名のスピーカーの方について書きました。上に挙げた方々以外にも、様々な分野でご活躍のスピーカーのみなさまが参加してくださり、スタッフという贔屓目を差し引いても「豪華だ！」と言ってよいと確信しています。僕もとても楽しみです。

そんな「DevLOVE X」、まだまだ参加申し込みを受け付けていますので、ぜひ下記からチケット（2days + 懇親会チケット付きで10000円です）を入手の上、ご参加ください！

devlove.doorkeeper.jp

*1:画像は2019年5月28日現在。

リレーショナルモデルと『Clean Architecture』のエンティティ

（エリック・エヴァンスの）ドメイン駆動設計を入り口にして、オブジェクトモデルとリレーショナルモデルについて考えているなかで、「ドメインモデルって必ずしもオブジェクトじゃなくていいんじゃないの」という思いを強めている。

ky-yk-d.hatenablog.com

そのような観点で、改めてアンクル・ボブの『Clean Architecture』を眺めていたら、一読したときは読み飛ばしていた記述に引っかかったので、覚書を残す。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

『Clean Architecture』におけるエンティティ

アンクル・ボブの『Clean Architecture』において、エンティティ*1は以下のように説明されている。

エンティティは、企業全体の最重要ビジネスルールをカプセル化したものだ。エンティティは、メソッドを持ったオブジェクトでも、データ構造と関数でも構わない。企業にあるさまざまなアプリケーションから使用できるなら、エンティティは何であっても問題はない。*2

ビジネスルールをカプセル化したものがエンティティである。そして、それは必ずしもオブジェクト指向モデルによって表現されるものではない。ビジネスルールをカプセル化したものが、複数のアプリケーションから利用されるというのが、アンクル・ボブの描く絵だ。

リレーショナルデータベースはエンティティたり得ないのか

データ構造とその操作によってビジネスルールを表現するということであれば、【リレーショナルモデルにおけるデータ構造+SQLによる操作】を提供するリレーショナルデータベースもまた、エンティティたりうるのではないか、という疑問が生じる。

そもそも、データベースというものは、複数の箇所からアクセスされることを想定したものである点で、単なる永続化手段であるファイルとは異なる。

ファイルはプログラムに「隷属したデータ群」である。一方、データベースはデータをプログラム群から切り離し（＝独立させ）、データベース管理システムにより統合して管理・運用しようとするもので、「多数のユーザから同時にアクセス可能な組織体の唯一無二の共有資源」となる。*3

このような見方をすると、データベースというものが「企業にあるさまざまなアプリケーションから使用できる」というエンティティの一つの特質を満たそうとするものであるということがわかる。

「リレーショナルデータベース」はエンティティではない

しかし、別の箇所で、アンクル・ボブはまず、データベースをエンティティと捉えることを明確に否定している。

　アーキテクチャの観点では、データベースはエンティティではない。データベースは詳細であり、アーキテクチャの構成要素として現れることはない。ソフトウェアシステムのアーキテクチャにおけるデータベースの立ち位置は、あなたが住む家におけるドアノブのようなものだ。
　ケンカを売っているように聞こえるかもしれない。実際、論争になったこともある。念のために言っておくが、今話題にしているのはデータモデルのことではない。アプリケーションのデータをどのような構造で扱うかは、システムのアーキテクチャにおいて重要な問題だ。*4

上の記述では、「データベース」を、したがって「リレーショナルデータベース」をエンティティとは認めないという明確な姿勢が示されている。しかし一方で、「データモデル」については別の問題だとし、判断を留保しているように見える。

「リレーショナルモデル」はエンティティのためのデータ構造ではない

しかし、さらに読み進めていくと、アンクル・ボブは、ビジネスルールを取り扱うためのデータ構造として、リレーショナルモデルを認めていないように読める記述がある。

さて、ここで考えてみよう。ディスクが絶滅し、すべてのデータがRAMに格納されるようになったとき、どのようにデータを扱うだろうか？表形式にしてSQLでアクセスする？それともファイルとして保存してディレクトリで管理する？もちろんそんなことはしないだろう。リンクリスト、ツリー、ハッシュテーブル、スタック、キューなどでデータ構造を表現し、ポインタや参照でデータにアクセスするだろう。だって、それがプログラマのやり方なのだから。*5

「表形式にしてSQLでアクセスする」のは、リレーショナルモデルのことだろう。上の記述においては、ディスクが絶滅した世界を前提にしているから、インメモリのリレーショナルデータベースをイメージすればよい。SQLでビジネスロジックを実装することもできるから、インメモリのリレーショナルデータベースをエンティティとしてビジネスロジックの担い手とすることもできるはずだ。しかし、アンクル・ボブはこれを否定するのである。

むすび：データ構造とデータモデル？

アンクル・ボブは、全てがメモリ上で行われる世界においては、「プログラマのやり方」が用いられるだろうと主張する。それは、「リンクリスト、ツリー、ハッシュテーブル、スタック、キューなど」のことである。これらのデータ構造は、オブジェクトモデルとの必然的結びつきを持たないと思う。

一方で、「リレーショナルモデル」は、上記のデータ構造とは異質なものとしてアンクル・ボブによって扱われている。上記で言われているようなデータ構造よりも、（リレーショナルあるいはオブジェクトといった）データモデルの方がより抽象的だと思うが、いまいち整理ができていない。Wikipediaの「データモデル」の項目には、「データ構造」という節があるが、関係性は明確ではない（単独の「データ構造」という項目も存在する。）。

データ構造とデータモデルについての明晰な整理を自分が欠いているということもあるだろうが、エンティティとしての資格をデータベース更にはリレーショナルモデルに認めないという論述に関しては、「プログラマのやり方」という語彙を含め、アンクル・ボブには誤魔化されているような感覚を覚えるというのが今のところの正直な感想である。

参考

今の時代は、RDBは単なる保存手段、オブジェクト永続化の実装に関わる選択肢に過ぎないと考えがちで、クリーンアーキテクチャ本などもそういう立場に立っているけれど、それとは異なる見方もあるということですね。むしろ素直に見れば、こちらの方がシステムの分割の論理としてスジがいいかも。

— 杉本啓 (@sugimoto_kei) 2019年1月22日

a-suenami.hatenablog.com

*1:『エリック・エヴァンスのドメイン駆動設計』におけるエンティティとは区別されなければならない。

*2:『Clean Architecture』201ページ。

*3:増永良文『リレーショナルデータベース入門　第3版』4-5ページ。

*4:『Clean Architecture』259ページ。

*5:『Clean Architecture』262ページ。強調は原文。