最近読んだ技術書:『システムを作らせる技術』『ドキュメント作成の基本』『セキュア・バイ・デザイン』『RustによるWebアプリケーション開発』

最近読んだ技術書の読書メモです。

『システムを作らせる技術 エンジニアではないあなたへ』

honto.jp

タイトルがやや刺激的ということで話題になった1冊です。システム構築に関するITエンジニア向けの本はさまざま出版されていますが、ITエンジニアへ発注する側にフォーカスしたものは珍しいかと思います。この手の本は「社員一丸となってシステム構築を成功させよう!」というような精神論よりの内容になりがちですが、本書はきわめて実務・実践より。SIerに発注する前の超上流工程から、実際の設計開発が始まる下流工程の間で、システムを作らせる側が具体的に何をするのか。どういう資料を作って、どのように周りを巻き込むのか。困ったときにはどういう対応策があるのか。そういった、さまざまなテクニック・Tipsがわかりやすく整理されています。自分は真逆のSIer側にいて、今後もそちら側でキャリアを積む予定ですが、そのような立場においても、お客さんの中に入っていって、いろいろとファシリテートしていかなければならないわけです。そういった意味では、ITエンジニアの自分にとっても勉強になる1冊だったと思います。

『エンジニアが一生困らない ドキュメント作成の基本』

honto.jp

自分はSIerのSEということで、実際のプログラムを触るよりExcelで資料作成している時間のほうが長かったりします。要はExcel職人として、ドキュメントを書くことが主業務なわけですが、そのわりにドキュメントの作成について真面目に勉強したことがないなと思って、本書を購入。内容としてはいわゆるパラグラフリーディング・パラグラフライティングの入門書といった感じ。タイトルには「エンジニア」とはあるものの、IT関係のビジネス文書全般に通用する内容となっています。逆にいうと、SIer的な設計書や手順書の書き方講座的なものを期待していると、ちょっと違うかもしれません。

近年はリモートワークも一般化し、メールやチャットなどのテキストコミュニケーションの機会も増えています。誰かになにかを伝えるという意味ではこれらもまた「ドキュメント」なわけですから、本書の内容が活かせるのではないかと思いました。また生成AIについても最後の方にわずかに触れられているのですが、個人的にはこれはかなり実用的であると感じました。ページ数も少なく、お仕事全般で役に立ち、しかもほとんど陳腐化しない中身ですので、読んでいて損はない1冊かと思います。

『セキュア・バイ・デザイン』

honto.jp

タイトルに「セキュア」とあるので、てっきりセキュリティ関係の本なのかと誤解しそうになりますが、本書の主眼は「デザイン」。すなわち、本書はソフトウェア設計やAPI設計の書籍になります。ソフトウェアが思った通り動かない、あるいは想定外の動きをするなどにより、システムが利用できず、ビジネスが停滞する。このシステムがちゃんと思った通り使えるかというのは可用性といい、セキュリティの世界では重要な要素のひとつとなっています。本書はこうしたシステム不具合は誤ったソフトウェア設計に基づくものも多いとし、それを乗り越える設計手法としてドメイン駆動設計を紹介します。すなわち、本書はDDDの入門書でもあるわけです。

DDDについては近年注目が集まっており、自分も何冊も入門書を読んできました。ビジネスとソフトウェアが一体になって、ビジネスを加速させるということをDDDの目的にすることが多いなか、ソフトウェアの品質に着目してDDDを導入するのは、観点として珍しいのではないかと思いました。DDDの入門書として見ると、やや分量は多いものの、全体的にわかりやすいですし、またDDD至上主義的な感じでもないので、おすすめできる1冊であると思います。

『RustによるWebアプリケーション開発 設計からリリース・運用まで』

honto.jp

本書はRustで書籍管理アプリを作りながら、RustによるWebアプリ作成の基礎を学ぼうというものです。Rustは近年注目が集まっていますが、どちらかというとシステムプログラミング領域であり、本書のようにアプリ開発に着目したものは珍しいかと思います。

個人的によかったポイントとしては、本書がハンズオン形式であるということ。古臭いですが、自分は演習方式のほうが頭に入ってくるタイプなので、ここは好感度高いです。ハンズオン自体もよく練られており、 ライブラリの機能を紹介して終わりではなく、レイヤードアーキテクチャや依存性の注入を導入するなど、最近のトレンドを抑えています。ここはRust抜きにしても勉強になりました。Dockerを使った環境構築、GitHub ActionsによるCI/CDの導入、クラウド環境へのデプロイなどもハンズオンにあり、RustでWeb開発をするためのすべてを学べるといって過言ではないと思います。ただし、Rustの文法や特徴的なメモリ管理など、Rustの基礎についてはまったく触れられていないので、そこは別にキャッチアップする必要があります。Rustの入門書は読んで、ひととおりの文法とコンセプトを理解した初心者が中級者にステップアップするためにはもってこいの1冊であると思います。

令和6年11月のデスク事情

最近のデスク事情を唐突にさらしたくなったので、まとめておきます。

さきに断っておくと、わたしは原則有線派です。世間にはあらゆるケーブルが許せない、ケーブル・アレルギーなお方もいらっしゃるとは存じております。しかし、接続が突然切れたり、充電や電池交換が必要だったりの心配がない、電池内蔵の無線デバイスに比べて捨てるときに考えることが少ないなどの理由から、有線派を貫いています。

モニターはEIZOのEV2451｡かなり昔に買ったもので、現在はおそらく廃盤。SEという仕事柄、モニターはいろいろ使ってきたのですが、なかでもEIZOが一番好みというか、目が疲れにくい感じがしたので、中国メーカ・台湾メーカに比べて高価だったものの、ボーナスで買った記憶があります。

このモニターにはおまけ(?)でUSBハブがついていて、ここにはキーボードとマウスをつなげています。キーボードはHHKB Professional JP。池袋ビックカメラかどこかで、社会人になって初めてのボーナスで買ったはず。つまり10年近く前ですね…。古いモデルなので、モニターと同じく廃盤。日本語配列・有線・非静音と、近年のHHKB好きが聞くと卒倒しそうな仕様ですが、自分はめちゃくちゃ気に入っております。おそらく一生使うでしょう。コロナ禍になって一番良かったのは、リモートワークが増えて、仕事でこのキーボードを使えるようになったことだと思います。

自分は長らくマウス難民で、さまざまなマウスを使っては変え、使っては変えを繰り返してきました。その試行錯誤の中で、自分がマウスに求める条件は以下であるとたどり着いたのです。

• 大きめのエルゴノミクスデザイン
• 右クリックと左クリックのほかに、ホイール、そして左側に進む・戻るボタンがついていること
• たとえばDPIスイッチなど、上記以外の機能がないこと

これを奇跡的に満たしたのが、今利用しているRazer の DeathAdder Essential。値段も5000円いかないぐらいで非常に手ごろ。かちかちうるさいクリック音やぴかぴか光るヘビのデザインも気に入っています。

さて、モニターからはHDMIケーブルとUSBハブにつながるUSBケーブルが伸びています。この2本をPCに直接つなぐのではなく、ELECOMのDST-C18SVを噛ませて、ここからPCにつなげています。これはドッキングステーションというやつで、さまざまな入力を1本のUSB-Cにまとめてくれます。

自分はこのデスクで仕事とプライベート両方をこなしており、仕事用のPCとプライベート用のPCのスイッチングが頻繁に発生します。そこで、さまざまな入力を一本のUSB-Cにまとめておくことで、この一本のUSB-Cを差し替えるだけで、仕事とプライベートのスイッチングを簡単にしているわけです。

ドッキングステーションにはさきほどの2本にくわえて、電源とUSBマイクを接続しています。使っているUSBマイクはRazerのSeiren V3 Mini。コロナ禍になり、リモートワークが増えてわかったのは、リモート会議ではマイクの音質がけっこう重要であるということ。マイクの音質が悪いと、聞く側にかなり負担がかかります。自分がしんどい分にはまだいいですが、相手に迷惑をかけるのは避けたい。仕事で利用しているPCのマイクはそこまで低品質というわけではありませんが、こういう事情もあり、専用のマイクを導入しました。

ちなみに数あるUSBマイクの中で、これを選んだのは、デザインが気に入ったのが一番ですかね。自分で録音したり、YouTubeの紹介動画をチェックしたりした程度ですが、音質は問題ありません。少なくとも、このマイクを導入してから、リモートワークで聞き返されるようなことはなくなりました。本当はオーディオインターフェースも導入したかったのですが、オーディオインターフェースはたいていデバイスドライバの導入が必須。仕事用のPCに変なソフトウェアインストールは厳しいため、これは断念。またスピーカーについては、接続方式がUSBのもので、なかなか気にいったデザインのものがなく、これも絶賛頓挫中です。

最後にPCを乗せている台ですが、これは無印良品のスチールモニタースタンドです。PCの位置を上に上げることで目線をあわせ、肩こりを防ぐだけでなく、デスク上の収納を増やす効果もあります。この手のモニタースタンドは各社いろいろ出していますが、無印良品のものはだんとつでデザインが好み。引き出しがついているのもGood。というか、引き出し付きのモニタースタンドって以外にないんですよね。なお下の隙間ですが、仕事中はプライベートPCを、逆にプライベート時間は仕事用PCをしまっています。

---

PCの横にあるのは、無印良品のファイルボックスとアクリルペンスタンド。ここには文房具を入れています。

ノートは無印良品の5mm 方眼です。最近は方眼ノートに凝っているのですが、意外に方眼ノートって種類がなく、自分が探した中だと、安くて比較的入手しやすいものが無印良品でした。まあ今後変えるかも。なおこのノートは主に仕事用です。10年近くSEで生計を立てているくせに、仕事上のメモや記録は紙のノートに書くのがもっとも楽で手っ取り早く感じがち(´・ω・｀)

プライベートでものを書いたり、あるいは仕事でもノートに取るほどでもない場合、メモ帳を使います。これはAmazon Basicのリーガルパッドです。こだわりはあんまりなくて、安売りのときになんとなく買ってなんとなく使っているだけです。ちょっぴりアメリカンな気分を味わえるだけで、可もなく不可もなくという感じ。リピートするかは微妙。

ノート・メモ帳ときたら、これに字を書く筆記具ですが、最近はPILOTのライティブを手に取ることが多い気がします。透明軸で中字、長期間ほったらかしにしていてもインクが乾かず、書き味もさほど悪くありません。インクは色彩雫シリーズからブルー・ブルーブラック系のものをカートリッジで補充しています。

ちなみにLamy safariにパイロットのブルーブラックを入れて使うこともあります。これも透明軸・中字・インクが乾きにくいから使っているという感じですね。万年筆マニアからすると発狂ものの選定理由ですが、まあものぐさな自分にはぴったりな万年筆運用です。

最近読んだ技術書『SQL緊急救命室』『Javaエンジニアのためのソフトウェアテスト実践入門』

最近読んだ技術書の読書メモです。

SQL緊急救命室 : 非効率なコードを改善せよ！

honto.jp

テーマごとに、効率的で読みやすいSQLを作成するためのアイディアを紹介した1冊です。「さまざまな問題を抱えた患者(SQL)が緊急治療室に担ぎ込まれてきて、それをベテランSQL医師と新人SQL医師が対話しつつ、治療にあたる」というフィクション形式のため、非常に読みやすいですし、扱われるテーマも現実に即していて、学ぶべき点はとても多いです。

個人的な感想ですが、CASEとウィンドウ関数について、これだけの分量でわかりやすく解説している本は珍しいのではないでしょうか? 実行計画とからめて解説しているところも親切だと思います。個人的な印象では、SQL初心者はこのあたりで苦労しているイメージがあります。逆にいうと、使いこなせればSQL中級者というわけです。

サーバサイド開発の仕事をしていて、SQLレベルを初級から中級にレベルアップさせたい人、とくにCASEやウィンドウ関数というワードを聞いてぴんとこない人は、ページ数もそれほど多くないですし、ぜひ読みましょう。

Javaエンジニアのためのソフトウェアテスト実践入門 : 自動化と生成AIによるモダンなテスト技法

honto.jp

実は発売日から楽しみにしていた1冊です。

中身の大半は、Javaの世界でよく利用されるテストフレームワークやテストライブラリの紹介です。とりあえず本書を読んで、手元においておけば、どんなJava開発の現場でも通用するかなという感じ。それぐらい、網羅的かつよくまとまっているという印象を受けます。逆にいうと、単体テスト is 何・E2Eテスト is 何というレベルのことを勉強したいのであれば、本書は不向きですし、Javaエンジニア以外が手に取る必要もありません。

個人的に好感度が高いのは、JUnit5が紹介されているところ。本書と近いコンセプトの本に『JUnit実践入門』という本があり、これはこれで名著なのですが、ちょっと古い本のため、JUnit4がベースになっており、さすがにJUnit5がデファクトスタンダードになって久しい昨今、人に勧めずらかったんですよね。本書はそこをアップデートしてくれただけで、非常に価値があります。

しいて欠点をあげるのであれば、AssertJのようなJUnitを補足するようなライブラリについても解説があればなお良かったのですが、それを差し引いても良書であるという評価はゆるがないです。テストに関心があるJavaエンジニア必携の1冊といって過言ではないかと思います。

夏休みの課題図書: ã€Žå¤§è¦æ¨¡ãƒ‡ãƒ¼ã‚¿ã‚»ãƒƒãƒˆã®ãŸã‚ã®ã‚¢ãƒ«ã‚´ãƒªã‚ºãƒ ã¨ãƒ‡ãƒ¼ã‚¿æ§‹é€ ã€ã€ŽDesign It!』『ドメイン駆動設計をはじめよう』『実戦で役立つ C#プログラミングのイディオム／定石＆パターン』

夏休み前後に読んだ技術書の感想文です

『大規模データセットのためのアルゴリズムとデータ構造』

honto.jp

主に確率的データ構造・ストリーミング的データ構造・外部記憶データ構造の観点から、大規模データを扱うためのアルゴリズムを紹介しています。この手の本はどうしても数式が多くなりがちですが、本書は数学的な話は控えめ。かわいい図表が多く、内容を直感的に理解することができます。説明自体もわかりやすいですが、翻訳もかなりこなれていて、読みやすいと思います。アルゴリズム関係の話は好きで、おもに競技プログラミング中心に取り組んできたのですが、そこではなじみのなかったデータ構造やアルゴリズムがたくさん紹介されていて、勉強になりました。アルゴリズムをばりばり使う仕事はしていないので、お仕事に直結はしないのですが、知的好奇心が満たされたのでOKです。

『Design It! : プログラマーのためのアーキテクティング入門』

www.oreilly.co.jp

デザインシンキングをベースにした、アーキテクティングの入門書です。個人的に思う特徴として、マインドセットやマネジメントの話が多めというところでしょうか。人によっては技術書ではなく、ビジネス書に分類するかも。また、設計を漸進的に改善し、それをチームに伝播させるために便利な、さまざまなアクティビティが後半部には紹介されています。これはテクニカルスキルばかりに注目していると、なかなかお目にかからないところだったので、勉強になりました。ここは仕事で実践できればよいかなと思いました。ちなみにデザインシンキングとは創造的かつ実践的な問題解決の手法のひとつで、少し前に流行っていた印象があります。自分はエンジニアですが、コンサルティングファームに勤務しているので、研修等でこのトレーニングはさんざんやらされました(余談)。

『ドメイン駆動設計をはじめよう : ソフトウェアの実装と事業戦略を結びつける実践技法』

www.oreilly.co.jp

最近なにかと注目されているドメイン駆動設計(Domain Driven Design; DDD)の入門書です。「そもそもDDDとは何か」というところからはじまり、DDDのメソトロジーやコアコンセプトなどを紹介したあと、応用編として、DDDでよく利用されるさまざまなデザインパターンまで紹介されています。DDDの入門書や入門記事はいくつか読んできましたが、本書がいちばんわかりやすかったです。DDDは現代のさまざまなフレームワークやライブラリに影響を与えているので、設計手法として採用するかしないかは別として、教養として知っておいた方がよいと考えています。その観点でも本書はばっちりだと思います。翻訳も日本語として自然になっており、現代版DDD入門書の定番になると思います。なお読みやすさのため、ユビキタス言語→同じ言葉とするなど、定番の単語の訳を一部変更しているとのことです。どの単語の訳をどのように変更したのか、本書内でまとまっていますが、別のDDD本を読むときは注意したほうがよさそうです。

『［改訂新版］実戦で役立つ C#プログラミングのイディオム／定石＆パターン』

honto.jp

最近読んだ技術書のC#採用率が高く、自分の中でC#熱が再燃してきたこともあって、読んだ本になります。かなりよかったです。C#は長い歴史を持つ一方、意外にも進化が早いという特徴があります。つまりインターネットで調べて出てきた記事の内容が古く、現代的な観点から本当に最適化どうかよくわからないということがありがちでした。わからないことがあるたびにググって勉強してきたタイプとして、本書のように現代的なプラクティスがまとまっている本は貴重です。C#最新の知識を体系的に整理できるいい機会になりました。わからないことが出てくるたび、辞書的に活用する本になると思います。もっともC#についてはサンデープログラミング状態で、お仕事として使う予定は全くありませんが…。

おまけ

ちなみに今年の夏休みは8/10(土)-8/18(日)までの1週間。記録的な猛暑ということもあり、外に出て活動的に何かするのは控えて、実家のある大阪でのんびりしていました。近々の仕事が超ストレスフルということもあり、あまり眠れていなかったということもあって、とにかくたくさん寝て過ごしました。食って寝て技術書読んでという感じ。ジムで筋トレが趣味なのですが、あいにく手首を痛めており、休養していました。

9月は仕事の関係上、祝日稼働する必要があって、連休がとれません。いまから夏休みが恋しいです(´・ω・`)

最近読んだ技術書: 『入門 継続的デリバリー』『アーキテクトの教科書』

最近読んだ技術書のうち、よかった2冊を紹介します。

『入門 継続的デリバリー』

www.oreilly.co.jp

本書は、さまざまなシナリオ・物語をベースに、継続的デリバリーの基礎知識や導入する際のポイントを丁寧かつわかりやすく紹介する入門書です。GitHub ActionsやJenkinsなど、継続的デリバリーを支援するツールはさまざまありますが、本書はそういった具体的なツールに依存しない内容になっています。

全体を通して、イラストや漫画が多く、文体も基本的に口語体ということで、非常にカジュアル、かつ親しみやすいつくりになっていることもあり、自分のような継続的デリバリー初心者でも楽しく勉強することができました。もっとも、内容はしっかり詰まっているので、継続的デリバリーの知識を体系的に整理したい人にとってもおすすめできる1冊です。ロートルな現場で働いているということもあり、なかなか機会には恵まれていませんが、今後、継続的デリバリーを推進する立場になった際は、本書を片手に仕事したいなと思います。

『アーキテクトの教科書』

honto.jp

本書は、アーキテクトになって活躍するまでのロードマップをまとめ上げた力作です。教科書と名乗るにふさわしく、アーキテクトのふるまいから知っておくべき基礎知識、キャリアモデルにいたるまで、アーキテクトの役割のすべてが体系的にまとめられています。さまざまな参考文献や推薦図書も紹介されており、本書を起点に学びを広げていくこともできるところも、本書のいいところです。

自分はアーキテクトと名乗って働いたことはないのですが、業務や管理よりは技術よりのキャリアを積んできたということもあって、とあるシステム開発プロジェクトにて、アーキテクトチームに投げ込まれたことはあります。そのときは、何もわからないまま、手探りで仕事を進めたのですが、あのとき本書があれば、当時の自分はかなり助かったはずです。今後そういう仕事をする機会があれば、本書を教科書としてかたわらにおきたいなと思います。

『なぜ依存を注入するのか DIの原理・原則とパターン』を読んã

honto.jp

「なぜ依存を注入するのか」←ここだけ見ると、サイケでスピリチュアルな本かと身構えますが、もちろんそんな内容ではなく、「依存性の注入」について書かれた本になります。「依存性の注入」とは、モジュール間の結合度を下げるためのデザインパターンで、英語ではDependency Injectionといい、この頭文字をとってDIと略することもあります。その特徴はオブジェクトの生成と利用を分離すること。

たとえば、商品IDが与えられたら、商品レポジトリからその商品IDに該当する商品情報を取得する、商品サービスクラスがあるとします。これをナイーブに実装してみると、以下のようになります。

class ProductService:
    def get_product_by_product_id(product_id):
        product_repository = ProductRepository()
        for product in product_repository.get_all_products():
            if product.product_id == product_id:
                return product
        return None

これはモジュール結合度が高い状態で、たとえば、単体テストなどでProductRepositoryをモック化したい場合、このコードではそれを簡単に実現することはできません。そこで、依存性の注入を採用し、以下のようにリファクタリングします。

class ProductService:
    def __init__(self, product_service):
        self.product_service = product_service

    def get_product_by_product_id(product_id):
        for product in self.product_repository.get_all_products():
            if product.product_id == product_id:
                return product
        return None

あとは、すべてのプログラムのエントリポイントで、ProductServiceクラスを初期化します。

if __name__ == '__main__':
    product_repository = ProductRepository()
    product_service = Product_Service(product_repository)

こうすることで、モジュールの結合度が下げり、単体テストにモックを使うなどが容易になりました。またオブジェクトの生成と利用を分離し、オブジェクトの生成を一元化することで、たとえばシングルトンにするかしないかなど、オブジェクトのライフタイム管理がしやすくなったり、プログラム全体の見通しが良くなったりと、さまざまなメリットを享受することができます。

上記の例は依存性の注入の一部を示したにすぎません。本書では「そもそも依存性の注入ってなんだっけ?」というところから始まって、そのメリットやデメリット、実装のテクニックからアンチパターンまで、こと細かに解説しています。また、共通的な関心事をうまく取り扱うためのアスペクト志向プログラミング、オブジェクトの生成部分を自動化するDIコンテナといった、依存性の注入に関連したトピックについても、かなりの紙幅がされています。依存性の注入について、ありとあらゆる内容が体系的に学べるといって間違いないでしょう。

ちなみに本書の分量ですが、B5判で656ページもあります。しかも、字は小さい方で、スマートフォンだと読むのがつらいぐらい。それだけの分量を依存性の注入にだけ費やしているわけですから、中身のつまり具合は半端ではありません。逆にいうと、単なるデザインパターンのひとつについて、それだけ書いているわけで、ある意味サイケでスピリチュアルといえるかも(´・ω・`)

サンプルコードはC#で書かれていますが、C#や.NET特有の知識はそれほど求められないので、オブジェクト指向プログラミングとC系言語の経験があれば、まったく問題ないと思います。現に自分はJavaメインのSEで、C#はホビープログラミング以上の経験はありませんが、それでも困るということはありませんでした。ただし、最後の3章「第13章: DIコンテナ: Autofac」「第14章: DIコンテナ: Simple Injector」「第15章: DIコンテナ: MS.DI（Microsoft.Extensions.DependencyInjection）」については、.NETのライブラリを解説しているだけなので、ここはC#や.NETに関心がない人は読み飛ばしてもよいと思います。

ところでは自分はJavaメインのSEと書きましたが、Javaの世界ではSpring Frameworkというアプリケーションフレームワークがデファクトスタンダードになりつつあります。実はこのSpring Frameworkですが、依存性の注入の考え方をふんだんに取り入れたフレームワークになっています。要するにJavaでお仕事をする以上は依存性の注入からは逃れられない可能性が高いわけです。自分のキャリアが今後どうなるかは不透明ですが、当面はJavaを利用しそうなので、Javaと関連が深い依存性の注入についてしっかり勉強できたことはよかったかなと思います。

『関数型ドメインモデリング』を読んã

www.e-hon.ne.jp

関数型プログラミングでドメイン駆動設計を進めるためにはどうすればよいのかというちょっとマニアックな切り口の本です。

読者層に関して、関数型プログラミング初心者でもOKという前提にはなっていますが、正直なところまったく触れたことのないレベルだと読むのは厳しいかもしれません (初心者に対してかなりわかりやすい記載にはなっていますが)。ただF#については、関数型プログラミング言語の一例として利用している感じなので、ほかの関数型プログラミング言語の経験があれば、なんなく理解できると思います。F#特有の知識が特別必要だったり、そればかりが紹介されたりもありません。

関数型プログラミング初心者だと厳しいとしましたが、ドメイン駆動設計初心者に対しては、むしろおすすめできるレベルだと思います。いくつかドメイン駆動設計に関する本を読んできましたが、そのなかではもっとも簡潔でわかりやすいと感じました。ドメイン駆動設計導入にはぴったりでしょう。

読んでみての感想として、本書の内容すべてをビジネスに取り入れることは難しいが、しかし多くの示唆に富んだ本であると思いました。現代のプログラミング言語やフレームワークには、関数型プログラミングやドメイン駆動設計のパラダイムが取り入れられていることも少なくないので、純粋な関数型プログラミングやドメイン駆動設計を指向しなくとも、本書にて紹介されるエッセンスを現場のソフトウェア開発で導入できるのではないでしょうか。

多くの示唆に富んだ本と書きましたが、個人的に感心したのは、ワークフローを型で表現する点。たとえば、顧客から注文があり、その注文の内容を検証するというワークフローがあったとします。このワークフローでは注文伝票の製品コードをチェックしたあと、顧客住所をチェックする場合、本書のやりかたにのっとれば、まず次のような関数型を定義します。

type ValidateOrder =
    CheckProductCodeExists  // 依存関係
     -> CheckAddressExists  // 依存関係
     -> UnvalidatedOrder    // 入力
     -> ValidatedOrder

そのあと、この関数型を満たす関数を実装します。

let validateOrder : ValidateOrder =
    fun checkProductCodeExists checkAddressExists unvalidatedOrder -> ...

このやり方のよいところは、型宣言を見ればワークフローで何をするのかが一目でわかること、そして仕様変更に強いことです。たとえば、仕様変更が発生して、注文の内容を検証する際に、顧客のメールアドレスをチェックする必要が増えたとします。この場合、まず型宣言を修正します。

type ValidateOrder =
    CheckProductCodeExists  // 依存関係
     -> CheckAddressExists  // 依存関係
     -> CheckEmailExists    // 依存関係
     -> UnvalidatedOrder    // 入力
     -> ValidatedOrder

すると、この関数型の実装関数であるvalidateOrder関数はコンパイルエラーになります。これはつまり仕様と実装に差異があることをコンパイラによって機械的に検出できているといえます。自分の仕事柄「Excel仕様書の中身とソースコードの実装が違って困る」ということが多々あるので、こういう仕様と実装の一致を強制できる仕組みには本当に感動しました。

これ以外にも本書にはソフトウェア設計に役立つさまざまなアイディアが紹介されています。全293ページと分量はほどほど。図表も多くてわかりやすく、なにより翻訳がこなれていて、非常に読みやすいので、自分のソフトウェア設計の持ち駒を増やしたい、新たな風を取り入れたい人は読んでみて損はないかと思います。