設計はメリット・デメリットを分析して考えよう

この記事は[レコチョク Advent Calender 2024](https://qiita.com/advent-calendar/2024/recochoku)の24日目の記事となります。

## はじめに
こんにちは、株式会社レコチョク新卒1年目エンジニアの清水と申します。
普段はフロントエンドエンジニアとして、主に[レコチョク](https://recochoku.jp/)、[dミュージック](https://dmusic.docomo.ne.jp/)、[Music Store](https://musicstore.auone.jp/s/)といったサービスに関わっています。

好きな音楽はEDMで、最近は[Aiobahn](https://www.youtube.com/@Aiobahn)や[TeddyLoid](https://www.youtube.com/@TeddyLoid)といったアーティストの楽曲を聞くことが多いです。
こういった音楽を聞くために渋谷や新宿のクラブに行くこともあるので、もし会ったらお酒奢ってください。(最近ドリンクの値上げがやばいです...)

少し脱線してしまいましたが、今回は11月に参加したアーキテクチャConference2024という勉強会で学んだことを知識共有と備忘録を兼ねて記事にしようと思います。

## 行ってきたのはどんな勉強会?
![アーキテクチャConf2024 (1).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3891278/33be4185-dd82-0326-c79d-3783f0bb957b.png)
 (画像引用元: https://findy.co.jp/2405/ )

今回行ってきた[アーキテクチャConference2024](https://architecture-con.findy-tools.io/)という勉強会ですが、こちらソフトウェアやインフラなど、ITシステムに関わる様々な要素における設計知識を学ぶためのイベントとなっています。

こちらのイベントに参加した経緯としては、趣味でWebAPIを作成している中で「クリーンアーキテクチャ」や「オニオンアーキテクチャ」といったモダンな設計概念に出会い、本イベントはそれらを深く学ぶ良い機会だと思い参加を決めました。

当日は多くの内容を学んだのですが、その中でも基調講演としてニール・フォードという方が発表していた内容が特に勉強になったと感じたので、そちらについて記事にしていこうと思います。

## 設計を考えるときはメリット・デメリットを意識する
まず結論として、ニール・フォード氏が発表を通して伝えようとしていたことは、
"**アーキテクチャとは、すべてがトレードオフである**"ということでした。

こちらの[トレードオフ](https://ja.wikipedia.org/wiki/%E3%83%88%E3%83%AC%E3%83%BC%E3%83%89%E3%82%AA%E3%83%95)という言葉ですが、Wikipediaでは以下のように説明されています。

> トレードオフ（英: trade-off）とは、何かを得ると、別の何かを失う、相容れない関係のことである。平たく言うと一得一失（いっとくいっしつ）である

つまり、"**設計における全てはトレードオフであり、各選択肢のメリット・デメリットを分析し、適切な決断を行うことが重要である**"というのが彼の主張であるように思います。

メリット・デメリットを分析し、決断を行うとは具体的にどういうことなのでしょうか。
こちらについて自分の理解をもとに、具体例を挙げて説明していきたいと思います。

## 動的型付け言語 vs 静的型付け言語 
例えば、ごく単純な設計の一例として、開発言語に**動的型付け言語**と**静的型付け言語**のどちらを採用するかという判断があります。

このトピックに関しては、ここ数年で動的型付け言語の流行が落ち着き、今の潮流としては静的型付け言語を採用することが望ましいというような論調になっているように思います。

特にフロントエンドの分野でJavaScriptからTypeScriptへの移行が起こっていることは、それを裏付ける事象であると言えるでしょう。

であれば今から開発を始める場合には、静的型付け言語を選べば正解なのでしょうか。

**いいえ、必ずしもそうとは限りません。**

論調に流され短絡的に考えるのでは無く、すべての設計判断はメリット・デメリットの分析のもとに行われるべきです。

## メリットとデメリットを分析する
従ってここからは、動的・静的型付けの長所と短所を考えていきましょう。

まず動的型付け言語ですが、一つメリットとして**少ない記述量でコードが書ける**ことを挙げられると思います。

動的型付け言語では、型宣言や型変換の処理を書く必要がないため、必要な記述量が減る傾向にあります。これはソフトウェア完成までの工数を削れるという観点から見ると良い点であると言えます。

ではデメリットはどうでしょうか。こちらも一つとして、**コードの安全性が実行するまで保証されない**ことが挙げられると思います。

動的型付け言語ではビルド時の型チェックが不要なため、不正な値が入らないことを言語仕様としては一切保証してくれません。そのため動的型付け言語で作成されたコードは、比較的に安全性が低いと言うことができるでしょう。

ここで勘の良い方ならば既にお気づきかと思いますが、動的型付け言語の長所短所は裏を返せば静的型付け言語の長所短所になります。

つまり静的型付け言語には**コードの安全性が高い**というメリットがあり、一方で**コードの記述量が多くなる**というデメリットがあると言えるでしょう。

## 状況によって最適解は変わる
分析によってメリット・デメリットが明らかになりました。しかしながら今のままでは、それぞれの長所短所がわかっただけで、どれを選ぶべきかの判断基準がありません。ここから決断できるようにするためにはどうすれば良いのでしょうか。

そこでやるべきことは、**自らが置かれている状況を分析すること**です。

例えばあなたが納期一ヶ月の緊急プロジェクトにおける開発担当であれば、できるだけ工数少なく、早期に完成させることを求められている状況であると分析できます。

このような状況においては、動的型付け言語の少ない記述量でコードが書けるという点が魅力的に映り、コードの安全性が低いことは無視すべき観点であると考えることができるでしょう。

同様にあなたが銀行システムの開発担当であれば、高いコードの安全性が求められ、そのためには開発に時間がかかっても問題がない状況であると分析できます。

こうした状況において、静的型付け言語の高い安全性は非常に魅力的であると映るでしょう。そして、コードの記述量が多くなり工数がかかるというデメリットは大した問題ではないと考えられます。

このように自らの置かれた状況を分析すると、各選択肢における**メリット・デメリットの影響度**が見えてきます。

自らの状況を分析し、メリット・デメリットがもたらす影響を適切に評価することができたならば、選ぶべき選択肢は自然と決まることでしょう。

## まとめ
**設計における判断をする際のフロー**

1. 他人の意見に流されるのではなく各選択肢の長所と短所を分析しましょう
2. 自分の置かれている状況を分析し、各選択肢における長所短所の影響度を評価しましょう
3. 最後に、影響度をもとに最適な決断をしましょう

**この流れを守って決断を行えば、きっと後悔しない選択をすることができると思います。**

## 結びとして
最後まで読んでいただきありがとうございます。
今回は自分が勉強会で学んだ内容を皆様に共有させていただきました。

書き終わってみると、ある意味で当たり前の話になってしまったかもしれません。
しかしながら、こうした基礎こそ重要なものですから、初心に立ち返るという意味でも今回の記事の内容を覚えておいてもらえると嬉しいです。

明日の[レコチョク Advent Calender 2024](https://qiita.com/advent-calendar/2024/recochoku)はついに最終日です！！
最終日の記事は、**SwiftUIでレコチョクマを描いてみた**になります。お楽しみに！

それではメリークリスマス。楽しい時間をお過ごしください♪

## 参考資料
- 書籍
    - [ソフトウェアアーキテクチャの基礎―エンジニアリングに基づく体系的アプローチ](https://www.oreilly.co.jp//books/9784873119823/)
- 発表資料
    - [アーキテクチャConference2024: ニール・フォード氏資料](https://speakerdeck.com/findyinc/modern-trade-off-analysis)
- Webサイト
    - [静的型付けと動的型付け：開発者が知っておくべき選択のポイント](https://odigo.jp/%E9%9D%99%E7%9A%84%E5%9E%8B%E4%BB%98%E3%81%91%E8%A8%80%E8%AA%9E%E3%81%A8%E5%8B%95%E7%9A%84%E5%9E%8B%E4%BB%98%E3%81%91%E8%A8%80%E8%AA%9E%E3%80%82%E3%83%A1%E3%83%AA%E3%83%83%E3%83%88%E3%81%AB%E3%81%A4/)

---

この記事はレコチョクのエンジニアブログの記事を転載したものとなります。 
 
https://techblog.recochoku.jp/11625