<p></p>
<h2 id="%E6%A6%82%E8%A6%81"><a class="header-anchor-link" href="#%E6%A6%82%E8%A6%81" aria-hidden="true"></a> 概要</h2>
<p>「ソフトウェアテストをカイゼンする50のアイデア」</p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__e0b6ffc3c18ef" src="https://embed.zenn.studio/card#zenn-embedded__e0b6ffc3c18ef" data-content="http%3A%2F%2Fwww.eijipress.co.jp%2Fbook%2Fbook.php%3Fepcode%3D2085" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="http://www.eijipress.co.jp/book/book.php?epcode=2085" style="display:none" target="_blank" rel="nofollow noopener noreferrer">http://www.eijipress.co.jp/book/book.php?epcode=2085</a></p>
<p>という本を読んだので感想についてメモする。</p>
<p>なお、かなり斜め読みしてしまったので内容が気になる方は自分で読んでみるのをおすすめします。テストに詳しく無いのであれば読む価値はあると思います。</p>
<h2 id="%E5%BE%97%E3%82%89%E3%82%8C%E3%81%9F%E3%83%8E%E3%82%A6%E3%83%8F%E3%82%A6"><a class="header-anchor-link" href="#%E5%BE%97%E3%82%89%E3%82%8C%E3%81%9F%E3%83%8E%E3%82%A6%E3%83%8F%E3%82%A6" aria-hidden="true"></a> 得られたノウハウ</h2>
<ul>
<li>抜け漏れを防ぐために他者とテストについて考えよ</li>
<li>定量化に努めよう</li>
<li>Given-When-Thenの順序は必ず守ろう</li>
<li>BDDでは以下の3つが重要となる
<ul>
<li>仕様</li>
<li>受け入れテスト</li>
<li>ドキュメント</li>
</ul>
</li>
<li>そのために、以下の3つを均衡させなければならない
<ul>
<li>仕様の簡潔さ</li>
<li>カバレッジの完全性</li>
<li>ドキュメントの統一性</li>
</ul>
</li>
<li>テストの優先順位をつけるにはAttribute Component Capabilityマトリクスが便利
<ul>
<li>理想的なACCマトリクスは「時間とお金があればどんな人でもテストできる」程度で抽象化する</li>
</ul>
</li>
<li>テストコードは書くためではなく読むために最適化せよ</li>
</ul>
<h2 id="%E6%84%9F%E6%83%B3"><a class="header-anchor-link" href="#%E6%84%9F%E6%83%B3" aria-hidden="true"></a> 感想</h2>
<p>正直抽象的なことが多くて読むのが苦痛だった。良い内容は書いてあると思うが、当たり前というか既知の内容も多く、それが抽象度高く書かれているという印象。なかなか実行可能で具体的なノウハウまでもっていくのは難しかった。</p>
<p>ただし、テストで思い悩むことがあった際にこの本に立ち返ると答えが書いてあるかもしれないので、薄く内容を覚えておいて読み返せるようにするのも手かもしれない。</p>


「ソフトウェアテストをカイゼンする50のアイデア」を読んだ

エンジニアなら自分でブログを作れ！④レイアウト変更編

エンジニアなら自分でブログを作れ！⑤タグ機能実装編

## 概要

有名な自己啓発本である 「イシューからはじめよ」

http://www.eijipress.co.jp/book/book.php?epcode=2085

を読んだので以下のような内容について章ごとにメモする。

- 得られたノウハウ、
- その他の感想。

## はじめに 優れた知的生産に共通すること
### ノウハウ

- 「悩まずに考える」 
  - 「悩む」とは、答えが**出ない**という前提 
  - 「考える」とは、答えが**出る**という前提

### 感想
仕事では答えが出ない問題は必要ないよねということでバッサリ切り捨てているが、これについてはかなり共感した。

オタクなので水槽の脳とかシミュレーション仮説とかが好きだが、こういうのも結局答えが出ないのでロマンを語る場面以外は考えるだけ無駄だよねという感覚でいる。それと似たようなことだと思った。

## 序章 この本の考え方
### ノウハウ

- 「仕事のバリューは、解の質とイシュー度で決まる」
- 「犬の道を避ける」
  - 「犬の道」とは、解の質を一心不乱に上げることでイシュー度を確保するアプローチのこと
  - まずイシュー度を高め、その上で解の質を高める方が時間効率が良い

### 感想
「斬新で革新的なものには名前をつけろ」という話が後々出てきたが、犬の道と名前をつけたのは確かに良かったんじゃないかなと思った。

言ってることは結局無駄な仕事を避けろということだが、そのためにはイシュー度を上げることが大事というのがこの本の本質だろう。
なので、第１章の内容は重要だが他の章は重要度が低い。

## 第１章　イシュードリブン
### ノウハウ
- 「スタンスを取れ」
  - 強引にでも具体的な仮説 (イシュー) を立てる
    - イシューに答えを出すため
    - 必要な情報が何か把握するため
    - 結果の解釈を明確にするため
  - とにかく言語化する
    - 言語化できない状態で明瞭な思考を行うことは難しい
- 「良いイシューとは以下の３条件を満たすもの」
  - 本質的である
  - 深い仮説がある
  - 答えを出せる
- 「一次情報を漁る」
- 「情報を集めすぎない」 
  - 集めすぎることで自分独自の視点が消える
- イシューを見つからない時は以下を行う
  - 変数を削る
  - 視覚化する
  - 最終系から辿る
  - so what?を繰り返す
  - 極端な事例を考える

### 感想
イシューを言語化すること、イシュー度が高いかどうかを定期的に見直すことが重要だと感じた。

「情報を集めすぎない」についてはエンジニア的には半分程度しか納得できなかった。確かに限界効用的に情報を集めすぎてもコスパが悪いというのはその通りだが、
独自の視点よりも車輪の再発明をしないことや仕様を見落とさないことの方が大事なのではないか？

## 第２章 仮説ドリブン①
### ノウハウ

- 「イシュー分析で解の質を高める」
  - ストーリーライン
  - 絵コンテ
- 「イシューをサブイシューに分解する」
- 「ストーリーラインを組み立てる」
  - ピラミッド構造の2つの型
    - whyの並び立て
    - 空・雨・傘

### 感想

エンジニア的には分割統治法になじみがあるのでサブイシュー云々に新鮮さはなかった。

ストーリーラインの2つの型についてはプレゼン時に使えそうなので覚えておきたい。

## 第３章 仮説ドリブン②
### ノウハウ

- 「ストーリーを絵コンテにする」
  - 絵コンテとは最終的なグラフや図表のイメージ
- 「分析とは比較すること」 
  - 定量比較の3つの型
    - 比較
    - 構成
    - 変化
- 「原因と結果から分析軸を考える」
- 「数字が入ったイメージを作る」
- 「意味合いを表現する」
  - 意味合いの本質
    - 差がある
    - 変化がある
    - パターンがある
- 「データの取得方法を明示する」

### 感想

これらもプレゼンの型として考えれば使えそうだった。
要するにプレゼン資料作りを想定して行動しろということで、いかにもコンサル出身らしい発想だなと感じた。

一方で、仕事では結局は誰かに話したり資料に残したりする必要はあるので、こういう意識は大事かもしれない。

## 第４章 アウトプットドリブン
### ノウハウ

- 「前提と洞察から取り組む」
  - ストーリーラインの中で絶対に崩れてはならない部分を潰しておく
- 「完成度を上げるよりも複数回取り組む」

### 感想

特に崩れて欲しくない実装には自動テストが欲しいよねというのと同じような感覚だった。

また、ある程度の完成度で誰かに見てもらいフィードバックをもらうというのもよく言われていることなので新鮮味は無かった。

## 第５章 メッセージドリブン
### ノウハウ

- 「ストーリーラインを磨き込む」
  - そのための3つのプロセス
    - 論理構造を確認する
    - 流れを磨く
    - エレベーターテストに備える
      - 偉い人とエレベーターで一緒になった時に説明できるか？
- 「チャートを磨き込む」
  - 優れたチャートの条件
    - イシューに沿ったメッセージがある
    - 軸の広がりに意味がある
    - 図表がメッセージを支えている

### 感想

このあたりもコンサル的だなと感じた。 プレゼン技術としては有用そう。

## まとめ

「イシューからはじめよ」のノウハウと感想をまとめた。

名著とされているイメージだったが内容が薄いように感じた。というか学者的なアプローチを期待していたらコンサル的なアプローチだったのでガッカリしたというような感想だった。

一方で、本文でも以下のように書かれている。

> 「僕は今、自分にできる限りの深いレベルまで、知的生産におけるシンプルな本質を伝えた。あとは、あなたが自分で経験する以外の方法はないはずだ」
> (中略)
> 「経験しないとわからない」と書くと「じゃあ、この本は何のためにあるのか？」と言われそうだが、
> この国では論理思考や問題解決において、新しいツールの紹介のようなものばかりが行われ、本質的な知的生産についての議論が足りないように思う。
> この本が共通の議論のベースと実践の手がかりとなればと願っている。

ということで、起こせる行動の変化としてはノウハウを意識に入れつつ自分で試行錯誤してみるくらいだろうし、それを目指しているようにも読めた。

時間が経ってこの本の内容を思い返した時に印象が変わるといいなという期待と共にレビューを終える。

「イシューからはじめよ」を読んだ

## 概要

「ソフトウェア見積もり 人月の暗黙知を解き明かす」

https://www.amazon.co.jp/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E8%A6%8B%E7%A9%8D%E3%82%8A-%E4%BA%BA%E6%9C%88%E3%81%AE%E6%9A%97%E9%BB%99%E7%9F%A5%E3%82%92%E8%A7%A3%E3%81%8D%E6%98%8E%E3%81%8B%E3%81%99-%E3%82%B9%E3%83%86%E3%82%A3%E3%83%BC%E3%83%96-%E3%83%9E%E3%82%B3%E3%83%8D%E3%83%AB-ebook/dp/B00KR96M6K

を半分程度読んだのでノウハウについて章ごとにメモする。

残り半分を読んだ段階で記事を更新する予定。

## 第1部 見積もりの考え方
### 第1章 見積もりとは

- 「見積もり」「ターゲット」「コミットメント」の違いを意識する
  - 見積もり：そのままの意味
    - 「この機能の実装は何人日」
  - ターゲット：実現したいビジネス上の目標
    - 「何日までにこの機能を提供したい」
  - コミットメント：機能を一定のレベルで期日までに納品するという約束
    - 「何日までにこの機能を提供します」
- 見積もりと計画の違いを意識する
  - 見積もりは正確性が重要
  - 計画は結果が重要
  - 偉い人にターゲットを達成するための計画を聞かれているのに見積もりを単に答えてはいけない
    - 「このプロジェクトは何人月？期限は３ヶ月なんだ」
    - 「見積もってみたところ５ヶ月かかります」
    - 「ふざけるな！」
  - 開発と期日どちらが優先かどうか尋ねる
- 良い見積もりとは偉い人の意思決定に寄与する見積もりのこと

### 第2章 見積もり能力のチェック

- 直感で「90％確か」な見積もりは、実際には「30%確か」
  - なので直感で90%とか言ってはいけない
- 見積もりなんて幅があって当然。無理に狭めようとしない

### 第3章 正確な見積もりの価値

- 意図的に過小に見積もることはすべきではない
  - 過大見積もりよりも深刻な被害が起きる
  - では過大にすれば良いかというとそうでもなく、それなりに大きくしてあとは計画とコントロールで対処せよ

### 第4章 見積もり誤差はなぜ起きる？

- 見積もり期間を増やしても見積もりの不確実性は上がらない
  - プロジェクト自体があやふやなのではどんなに頑張っても上がらない
  - 見積もり期間を増やすのではなく、要件定義や設計を固めることでしか上がらない
- 休暇、病欠、トレーニング、ミーティング等は必ず発生する。そのためのゆとりをもたせる
- 開発者の見積もりはすでに必ず楽観的であるので削ってはいけない
- 見積もりに「コントロールノブ」を持たせてはいけない
  - コントロールノブとは見積もりに入れる主観的判断のこと
  - 見積もりの客観性と共に正確性も落ちる
- 即興の見積もりはしない
  - たった15分の見積もりでさえもっと正確になる

## 第2部 見積もりの技法の基礎

### 第7章 数えて、計算して、判断する

- できるときはまず何かを数える
- 数えられない場合にのみ計算する
- 計算すらしないのは最終手段

### 第9章 専門家の判断

- タスクで分解して見積もるときは長くても2日程度の粒度にする


## 感想

「技術者の見積もりは常に楽観的」というのはその通りだと思った。
幅がある見積もりの中で最小の部分を提出する傾向があるような気がしているし、
実際過小に見積もる圧力があるということも書かれていた。

一方で、数えるだけの方がよほど正確に見積もれるというのは不思議だった。さすがにコード行数で数えるのはどうかと思うが。

過去の開発にかかった工数と関連データの保存および可視化が出来ていないと不可能な手法ではあるので、これらの重要性はかなり高い。

生産性向上とか言っておいて生産性を測る指標を可視化していないなんてことがザラにある状態では正確な見積もりなんて望めないということかもしれない。

「ソフトウェア見積もり」を読んだ

## 概要

技術書展13で公開されていた「Nuxt3 + Firebase 捨てられるWebアプリケーション設計」

https://techbookfest.org/product/m4KEUzinvmSZhPSaWYHetH?productVariantID=jC3wRJsbgwuJJQ05JtumXe

を読んだので、感想をまとめる。

以前こちらの記事を読んで著者に興味を持ったというのと

https://shiodaifuku.io/articles/17638219-f1ef-406c-b20c-7f426d61b2af

設計部分を読みたいという動機で購入しており、メインパートと思しきNuxt3およびFirebaseの部分は大胆に斜め読みしたので、意図と違う解釈をしているかもしれない。

## 第1部
### 第1章 SOLID
よく言われているSOLID原則についてまとめられていた。わかりやすくまとまっていたし、Vueとの関連も述べられていたので使いやすいかもしれない。

https://ja.wikipedia.org/wiki/SOLID

### 第2章 結合度と凝集度
こちらもよく言われている結合度と凝集度についてまとめられていた。同様にVue (特にComposition API) との関連も述べられていた。

https://ja.wikipedia.org/wiki/%E5%87%9D%E9%9B%86%E5%BA%A6

https://ja.wikipedia.org/wiki/%E7%B5%90%E5%90%88%E5%BA%A6

Vue3.0のComposition APIの威力についてはReact hooksと似たようなもんだろうくらいで深く気にしていなかったが、旨味についての理解が深まった気がする。 

私はVue2.0の経験があり、そのときは経験が浅いのもあってスパゲッティコードと化してしまっていた。Composition APIの影響で書きやすくなっているというのもあり、機会があれば使ってみたいと思った。

### 第3章 契約による設計: Design by Contract

契約プログラミングについてまとまっていた。

https://ja.wikipedia.org/wiki/%E5%A5%91%E7%B4%84%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0

Nuxtのどこで契約を意識する必要があるのか等もまとまっており、後々おそらく実例もあるのだろう。

## 第2部, 第3部
コンポーネント分割の基準等についても書かれていたが、 VueおよびNuxt, Firebaseの割合が大きいので割愛。序盤の設計原則に従ってNuxtアプリを作成するという内容となっていたようである。

## まとめ
個人的には設計部分で既知の内容が多く得られる物が少なかった。 ただ、これは私が不純な目的で本書を購入したからで、Vue, Nuxt, Firebaseというスタックで何かを作りたい人には良い本だと思う。

また、技術書展の本は他にも1,2冊購入したがどれもレイアウトや構成が凄くちゃんとした本になっていて驚いた。私もそのうちなんか書いて出してみたいと思っていたがハードルが上がってしまった。

「Nuxt3 + Firebase 捨てられるWebアプリケーション設計」を読んだ

Raycastでローカルのパスワード管理をしちゃおう

## 概要

オライリーから出ている 「ソフトウェアアーキテクチャ・ハードパーツ」

https://www.oreilly.co.jp/books/9784814400065/

を読んだので、重要な章を抜き出してノウハウをメモする。

と言いたいところだが、重要な部分が多すぎるのでこの記事では書きやすい部分だけを抜き出している。

書籍の内容を拾いきれているとは到底言えないので、是非読んでもらいたい。

ある程度システム設計に明るく、アーキテクチャに課題を抱えている人にはぴったりな内容になっていると感じた。

## 1章 「ベストプラクティス」がないとどうなる？

全ての解決策はトレードオフである。

> アーキテクトは、自分の問題に対する「銀の弾丸」を探し求めてはならない。

アーキテクトの問題はそれぞれユニークなため、ベストプラクティスが存在しない。

だからこそ「ハード」パーツである。

- 難しい問題
- 堅い、システムの土台となる部分

> 決して最善のアーキテクチャを狙ってはいけない。むしろ、少なくとも最悪でないトレードオフの組み合わせを狙おう。

多くのアーキテクチャにおいて、データこそが全てである。

アーキテクチャデシジョンレコード（Architecture Decision Records：ADR）（https://adr.github.io）を記入せよ。

アーキテクチャ統制のため、アーキテクチャ適応度関数を設計、運用せよ。

## 2章 ソフトウェアアーキテクチャにおける結合の見分け方

結合の定義

> 一方の変更が他方の変更を引き起こす可能性がある場合、ソフトウェアシステムの2つの部分は結合している。

結合を発見、分析し、トレードオフを評価せよ。

アーキテクチャ量子の定義

> アーキテクチャ量子とは、高度な機能的凝集、高度な静的結合、同期／非同期による動的結合を持つ、独立してデプロイが可能なアーティファクトを指す。アーキテクチャ量子の一般的な例には、あるワークフロー内の整ったマイクロサービスなどがある。

これはすなわち、データベースを共有しているアプリケーションは全て1つのアーキテクチャ量子である。

## 4章 アーキテクチャの分解

モノリスからサービスベースアーキテクチャを経てマイクロサービスへ移行していく上で、2つのアプローチが紹介されている。

- コンポーネントベース分解
  - まずはリファクタリングし、モジュールを分けていく。
  - 分けられたモジュールをサービスに切り出す。
- 戦術的フォーク
  - まるっと別アプリケーションとしてコピーして立て、それぞれ1部の機能しか使っていない状態にする。
  - その後、不要な機能をリファクタリングによって削除していく。
  - コンポーネントベース分解と比べて
    - メリット
      - 事前の分析が不要なので作業開始が早い
      - コードは抽出するより消す方が簡単 (と書かれていたが本当か？)
    - デメリット
      - 不要なコードを消す努力が必要
      - ロジックは汚いまま

## 6章 業務データの分解

データベースを分けるか？分けないか？もトレードオフである。

データを分解する要因として以下のようなものがある。

- 変更制御
  - カラムの変更等の影響が多岐にわたる
- コネクション管理
  - 1つのデータベースだけを使うとコネクション数の管理が難しい
- スケーラビリティ
  - コネクション数
  - 容量
  - スループット
  - パフォーマンス
- 耐障害性
  - 1つのデータベースだけを使うとデータベースが単一障害点となってしまう
- アーキテクチャ量子
  - 1つのデータベースだけを使うと1つのアーキテクチャ量子となってしまう (つまり独立してデプロイできない、等)
- データベース種別の最適化
  - 1つのデータベースだけを使うと1つの保存方法だけしか使えない (つまりデータ特性ごとに最適な選択肢が取れない)

逆に、データを統合する要因としては以下のようなものがある。

- データ関係
  - 密結合な外部キー等があるか？
- トランザクション
  - 単一のトランザクション単位が必要か？

モノリスなデータベースを分解するには5段階のプロセスを踏むと良い。

1. 分析し、ドメインを特定する
2. ドメインごとにテーブルを割り当て、移動する
3. コネクションをドメインごとに分離する
4. スキーマをそれぞれのデータベースに移動する
5. コネクションを切り替える

## 7章 サービスの粒度

マイクロサービスの粒度を大きくするか？小さくするか？もトレードオフである。

粒度を小さくする要因としては以下のようなものがある。

- サービスの範囲と機能
  - 凝集性が高い状態になっているか？
- コード変動率
  - 一部のコードだけ変更頻度が高くないか？
- スケーラビリティとスループット
  - 一部だけスケールする必要があるか？
- 耐障害性
  - 一部の故障で全体が故障してしまわないか？
- セキュリティ
  - 一部だけ高いセキュリティが必要か？
- 拡張性
  - どの程度拡張されるか？

粒度を大きくする要因としては以下のようなものがある。

- トランザクション
  - サービスをまたいだトランザクションが必要か？
- ワークフローとコレオグラフィ
  - サービス同士がやりとりする必要はあるか？
- 共有コード
  - サービス同士がコード共有の必要はあるか？
- データ関係
  - データは分解できるか？

## 9章 データの所有権と分散トランザクション

サービス間で共有するデータが存在するとき、どちらのサービスが所有権を持つのか、どのように共有データを管理するのかをトレードオフによって決めなければならない。

分散トランザクションはACID特性をサポートしないため、代わりに結果整合性を検討せよ。

## 10章 分散データアクセス

所有していないデータにサービスが読み取りアクセスするためには様々な方法があり、その間にもトレードオフがある。

- サービス間通信パターン
  - サービス間がWEB API等で通信してDBを隠蔽する
- 列スキーマレプリケーションパターン
  - 非正規化する
- レプリケーションキャッシュパターン
  - 分散キャッシュする
- データドメインパターン
  - 愚直に一緒にDBを見てしまう

## 11章 分散ワークフローの管理

分散システムどうしを調整する方法については基本的には2種類あり、トレードオフがある。

- オーケストレーション
  - 調整役を別途立てる
- コレオグラフィ
  - 最初のサービスが調整役となる

## 12章 トランザクショナルサーガ

通信、整合性、調整についてそれぞれ2パターンあり、組み合わせると合計8パターンのサーガ (アーキテクチャの大別) がある。

| パターン名       | 通信  | 整合性   | 調整         | 結合度   | 複雑さ   | 応答性/可用性 | スケーラビリティ |
|-------------|-----|-------|------------|-------|-------|---------|----------|
| エピックサーガ     | 同期  | アトミック | オーケストレーション | とても高い | 低い    | 低い      | とても低い    |
| 伝言ゲームサーガ    | 同期  | アトミック | コレオグラフィ    | 高い    | 高い    | 低い      | 低い       |
| おとぎ話サーガ     | 同期  | 結果整合性 | オーケストレーション | 高い    | とても低い | 中程度     | 高い       |
| 時間旅行サーガ     | 同期  | 結果整合性 | コレオグラフィ    | 中程度   | 低い    | 中程度     | 低い       |
| ファンタジーサーガ   | 非同期 | アトミック | オーケストレーション | 高い    | 高い    | 低い      | 低い       |
| ホラーストーリーサーガ | 非同期 | アトミック | コレオグラフィ    | 中程度   | とても高い | 低い      | 中程度      |
| パラレルサーガ     | 非同期 | 結果整合性 | オーケストレーション | 低い    | 低い    | 高い      | 高い       |
| アンソロジーサーガ   | 非同期 | 結果整合性 | コレオグラフィ    | とても低い | 高い    | 高い      | とても高い    |

## 13章 コントラクト

ハードパーツとしてのコントラクトの定義は以下である。

> アーキテクチャの部品が情報や依存関係を伝えるために使用するフォーマット。

コントラクトとして例えば以下の様なものがあり、トレードオフがある。

- 堅い
  - 例
    - gRPC
  - メリット
    - 型
    - バージョニング
    - 検証が用意
    - ドキュメント
  - デメリット
    - 密結合
- 緩い
  - 例
    - JSON
  - メリット
    - 疎結合
    - 進化しやすさ
  - デメリット
    - 型がない
    - コンシューマ駆動契約等の適応度関数が必要

帯域幅は無限だと思うな。

## 15章 独自のトレードオフ分析を構築する

MECEに分析せよ。

技術の過度な売り込みを避けよ。

> 何かを伝道する立場をとってはいけない。トレードオフに立ち返ろう。

> 銀の弾丸を追い求めるのではなく、トレードオフを分析するスキルに磨きをかけることで、アーキテクトは組織に真の価値を提供できるのだ。

## まとめ

アーキテクトというふわっとした分野において地に足ついた良い本だった様に感じた。

全てはトレードオフである、というのは自分も読む前から感じていたことではあったため、裏付けが取れて嬉しい気持ちになった。

そして、そのトレードオフをこれでもかと投げつけてくる本書は実際にアーキテクチャを考える上で非常に参考になるだろう。

最近「マイクロサービスって間違いだったんじゃね？」等が話題になったりもしたが、そういうことに振り回されず淡々とトレードオフを分析できるエンジニアになりたい。

「ソフトウェアアーキテクチャ・ハードパーツ」を読んだ

## 概要

このブログのドメインを含む2つのドメインをGoogle DomainsからCloudflareに移行した。

## はじめに

昨年10月に[ドメイン管理サービスをお名前.comからGoogle Domainsに移行した](/posts/domain-service-change)ばかりだったが、なんとGoogle Domainsが事業売却されるとのこと……

https://www.itmedia.co.jp/pcuser/articles/2306/16/news083.html

仕方ないので、今回はCloudflareに移ることにした。ちょうどWorkers等も話題になっていたし。

## 移行時のTips

### 移行作業

特に何も言うことはない。Cloudflare側のサイトとしてドメインを登録しておけば、後は案内に従ってネームサーバーの変更、移管を進めるだけで良い。

あまりにも簡単だった。本当にこういうのは嬉しい。

### ERR_TOO_MANY_REDIRECTS

移管後、ブラウザでドメインにアクセスすると、ERR_TOO_MANY_REDIRECTSというエラーが発生した。

オリジンがhttpsであるにも関わらず、CloudflareのSSL設定がFlexibleになっていたことが原因だった。オリジンにはhttpでアクセスして戻されてを繰り返していたらしい。

Fullにすることでオリジンまでhttpsで通信するように設定できるので、それで解決した。

![Cloudflareの設定画面](/domain-service-change-2/img.png)

## 移行後の感想

Google Domainsと比べると以下の不満はある。

- Google Cloudとの連携がない
- ドメイン管理以外の機能が多い

まあ前者は仕方ないし、後者はそれはそれでメリットもあるので良しとした。

## まとめ

ドメインをGoogle DomainsからCloudflareに移行した。

正直Google Domainsが事業売却されるのは寝耳に水で、今後何を信じてサービスを選べば良いかわからなくなる……。

上手くいかなかったサービスを手放すのはGoogleのお家芸ではあるが、そんなに採算取れてなかったんでしょうかね？

Cloudflareも今は波に乗っているが、いつかはGoogleと同じ道を辿るのかもしれない。そういう意味では日本企業のサービスを使う方が安定性は高いのかも。

何はともあれ皆さんのドメイン管理サービス選びの参考になれば幸いである。