Future Tech Blog
フューチャー技術ブログ
Programmingカテゴリ

ソフトウェア設計のトレードオフと誤りを出版しました

すでに多くの方々にお手に取っていただいておりますが、オライリージャパンから「ソフトウェア設計のトレードオフと誤り」の翻訳をフューチャーのメンバーと一緒に出版いたしました。好評なようで、発売一カ月ほどで増刷も決定いたしました。みなさまご購入いただき、ありがとうございます。初版をお買い求めになられたい方は今すぐ書店にダッシュ！

トレードオフこそが設計である

良い設計とか読みやすいコードみたいな話題はTwitterではバズりやすい話題です。

読みやすいコードの話題ではいろいろなレイヤーの話が出てくるのですが、因数分解すると、だいたいいくつかのカテゴリーに分かれるように思います。

  • 命名規則とか書き方のルール
  • 従うべきクラス構造、アーキテクチャ構成の導入
  • サービスの境界をどこに引くか、どのようなときに設計手法を選ぶか、どのアルゴリズムを選ぶか

名前や命名規則の統一とか書き方の統一とかは用語のリストを作って、命名規則を作って・・・など、コードフォーマッターとか、バリデーターを入れたら全自動だか半自動で解決する話題です。

クリーンアーキテクチャとかレイヤードアーキテクチャの話題もよくあがります。昔もデザインパターンが話題になったり、MVCが話題になったり、みんなお手本が欲しいんだな、という感じです。ただ、この手のものって、型にはめるためにある程度冗長であることを要求されるというか、コード量は増える傾向にあります。あと、オブジェクト指向はネジや釘として残っているが、ウェブフロントエンドはどのフレームワークもsignalやhooksによるリアクティブな設計に向かっていて、stale when revalidate戦略を活用したり、20年前のオブジェクト指向のアーキテクチャ議論はもう完全に過去のものだなぁという実感があります。

最後の残るものは、その時々によって意思決定の結果が変わる生ものです。結果が毎回変わるのであれば、あまり参考にならないかというとそういうことはなく、「どのようなトレードオフを考えて意思決定をしたのか」という思考の流れは参考になります。そのような意思決定こそがソフトウェア設計の醍醐味と言えます。

本書も、そのような「トレードオフ」を扱った本です。リーダブルコードのような「当たり前のコード品質は守れる前提」で、また錆び付いたアーキテクチャの話もなく、最後の意思決定のトレードオフの議論が中心です。

単なる正解集ではない

本書は、日付処理、サードパーティライブラリ、設定回りの設計、分散処理などさまざまな分野を取り上げて、そのトレードオフをいくつか紹介しています。ページ数もあり、扱っている内容も幅広いのですが、我々の設計対象は無数にあります。例えば、開発環境の構築1つとっても、ローカルに構築するのか、仮想PCでやるのか、Dockerコンテナを活用するのか、さらにVSCodeのDevContainerを使うのか、VDI環境（クラウドのワークスペース）を使うのかなど、多くの選択がありますし、その話題そのものは出ていません。本書は丸暗記するような本ではなく、トレードオフの考え方を鍛える本であると思います。

例えば、Appendixとして翻訳オリジナルのコンテンツとしてマスタデータのトレードオフについて取り上げましたが、議論をしようとすればいくらでもネタはあります。訳者あとがきにも書きましたが、1995年ごろからブームを巻き起こしたパターンランゲージというものも、本来は正解集ではなく、「自分でその場に必要なものを選択して適用する」ものでした。「場」はフォースと呼ばれ、パターンにおいては重要な概念でした。リファクタリングではA⇔Bの両方のパターンがあり、まさにどちらを選ぶかはトレードオフである、というものですが、近年ではフォースを考慮せずに「こういうコードにすべき10ヶ条」みたいな使われ方をしていたりします。DDDも、本来はパターンランゲージであり、僕が読む限りは「境界づけられたコンテキスト」でドメインを分割していくだけではなく、「継続的な統合」をしていくものですが、マイクロサービスを念頭に置いて議論をする人が多いせいか、分割ばかりが話題になります。

一方通行にしてしまえば、あとはそれを考えずに適用していくだけですので、確かに楽にはなりますが、パターンにハマった実装を量産する場合でなければ、良い設計やコードはそのような流れ作業だけでできるものではなく、何度も繰り返し試行錯誤が必要です。

試行錯誤を繰り返すにあたっても、ある程度選択肢が絞られていれば時間が節約できます。また、「こんな選択肢もあったんだ！」というのに後から気づくこともあるでしょう。本書は即効性があるわけではありませんが、そのような選択肢を絞ったり、未知の選択肢に気づくヒントが得られると思います。

裏ミッション：出版にかかわるメンバーを増やす

僕としてはかれこれ14冊目だか15冊目だかの本（第二版とかを除く）になるのですが、他のほとんどのメンバーは1冊目の出版です（実用Goを一緒に書いた辻さんは2冊目）。

本って、「翻訳したい」「書きたい」という気持ちを持って一歩踏み出せる人はなかなかおらず、最初の一歩の背中を押してあげる、というのが大切である。僕も、最初は大学時代に日本XPユーザーグループの運営をしていたときに、当時アジャイルやオブジェクト指向の書籍の翻訳の監訳をよくしていて、かつグループの代表であったテクノロジックアートの長瀬さんから声をかけてもらってこの道に入りました。最初はXPのテスト本の書き下ろし、次に、アジャイルソフトウェア開発スクラムの翻訳です。

書籍の翻訳や執筆の敷居が高いということは、積極的に若い人を増やしていかないとそれをやる人の年齢がどんどん上がってしまうということにもなります。なるべく若い人ほど、これからの業務で得る経験値も多くなるわけで、そういう人が増えていけば魅力的な本も増えていきます。

翻訳は原文側が持っている価値があるので、経験がまだそれほどない人でも、巨人の方に乗って価値のある本が出しやすい、というメリットがあります。もちろん、本書でもやった通り、いろいろ注釈を足したりしてその原文の価値をさらに高めるという楽しみもありますが、（翻訳の日本語の質が一定以上あれば）だれでも最低限のクオリティは出せるため、僕自身は労力を書き下ろしの僕にしか書けない本に注いで、翻訳はこれから名前を売っていくことになる若者にまかせよう、というスタンスでいたのですが、未経験の人の背中を押す、というも大切なので、旗振り役になってメンバーを募って一緒に翻訳することにしました。

チャンスをたくさん作りたいという気持ちがあったため、手を挙げてくれた人全員OK出して開始したので人数はそれなりに多くなってしまいましたが、僕が一通り全部の下訳に手を入れるという力業で、章ごとに日本語の調子が大きく変わるということはなく、それなりに読みやすい訳にはなったんじゃないかな、と思います（その後、全員で内容に関するレビューを何度も回しました）。

ぜひ読書会のネタに

本書はいくつかのトレードオフを扱っていますが、特定の分野ごとに、本書で触れていないトレードオフというのもあるでしょう。コスト削減のためにEC2/Compute Engineで作り込むのか、FaaSを使ってサーバーレスでやるのか、ストレージはKVSを使うのか、RDBを使うのか、など。ぜひ、本書を片手に読みながらいろんなトレードオフについて語っていただけると良いかと思います。

できれば、 #ソフトウェア設計のトレードオフ タグでもつけて、「こんなトレードオフもあるぞ」とか、「本書の説明にはなかったが、こういう注釈を俺ならつけたい」でも語っていただければと思います。楽しみにしています。

また、次の出版プロジェクトを進めていたりもします。そちらも半年ぐらいしたらお知らせできるかも？ また、翻訳者の宮永さんには「また次のチャンスがあったら参加したいです！」と言われたのでまた翻訳を立ち上げたいな、と思っています。

https://www.oreilly.co.jp/books/9784814400317/
https://www.amazon.co.jp/dp/4814400314/