Azureのメッセージングサービスに再入門 似ているサービスの違いを理解しよう

この記事は後ほどcloud.config techblogにマルチポストされる予定です。

はじめに

最近社内でMCP資格取得の機運が高まってきていて私の方でもAZ-203取得に向けて久々にAzureの学習を始めたところです。
AZ-203の試験範囲にはAzureのメッセージングサービスも含まれているのですが、これらのうちどういった時にどれを利用すればいいか迷ったりしませんか？
Azureのメッセージングサービスは大きく分けてQueue Storage、Service Bus Queue、Event Grid、Event Hubsの4つがあります。
今回はこれらのサービスについて特徴や使いどころについて纏めておきたいと思います。

MessageとEvent

まず、4つのメッセージングサービスを分ける大きな観点として、メッセージとして送るものがメッセージかイベントかというものがあります。
まず、メッセージとはその言葉のイメージ通り何かしら情報が入った小包のようなものです。
それ自体がデータとしてこれを受け取った側はその中に含まれるデータを使って処理を行います。
4つのサービスの中ではQueue Storage、Service Bus Queueがこれにあたります。
一方で、イベントはそのような送られた物自体を使って処理を行うものではなく、何かしらのイベントが起きたこと（例えば、Blob Storageにファイルが追加された、など)を伝えます。
付加情報として例えば追加されたBlob Storageのファイルに関する情報等が送られますが、そのファイル自体は送らず、その参照情報を送るので、イベントを受け取った側はそのファイルに対して直接操作を行うといった動作が可能になります。
4つのサービスの中ではEvent Gridと Event Hubsがこれにあたります。

MessageベースのQueue StorageとService Bus Queueの違い

Queue Storageの大きな特徴は、キューとしてAzure Storageを利用していることです。
Azure Storageは保存できる容量が莫大であるため、Queueに保持できるメッセージの合計容量の制限がほぼほぼありません。
一方でService Bus Queueは、キューのサイズに制限がありますが、メッセージをキューに入った順で確実に処理できるFIFOの仕組みなど、機能面で優れているという特徴があります。
キューのサイズは、パーティション分割の仕組みを利用して最大80GBまでで、その中に1メッセージあたり256kbのメッセージを送ることができます。
もしメッセージの合計容量がキューのサイズを超えると、後からやってきたメッセージはエラーとなってしまいます。
なので、基本的にメッセージの容量が合計で80GBを超えるならQueue Storageを利用し、それ以下であれば Service Bus Queueを利用するといった形になります。

EventベースのEvent GridとEvent Hubsの違い

Event HubsとEvent Gridの使い分けるシーンの大きな違いとしては、利用規模が挙げられます。
Event Hubsの主な利用用途はイベントの発行元が多数存在するようなビッグデータパイプラインです。
大量のイベントを高速で処理する必要がある際に利用され、Stream Analytics等を用いることでイベントを分析することもできます。
一方でEvent Hubsはよりシンプルで、イベント駆動のアプリケーションを作るのに向いています。
イベントの送信元には他のAzureサービスであるBlob Storage等を設定でき、イベントを受信したときに処理を行う側としてFunctionsなどを指定してやることで単純に○○が起きたら○○を行うといった動作の流れを作ることができます。

おわりに

今回の記事では自分のAZ-203対策も兼ねてAzureのメッセージングサービスであるQueue Storage、Service Bus Queue、Event Grid、Event Hubsとそれらの違いについて解説しました。
Azureのメッセージングサービスは大きく分けて4つあり、大きく分けるとメッセージを扱うものとイベントを扱うものがあります。
その中でさらに、メッセージの合計容量が大きい場合（80GBを越す)はStorage Queueを利用し、メッセージの容量が小さい場合やメッセージを受け取る側がFIFOでメッセージを受け取りたい場合はService Bus Queueを利用します。
イベントを扱うサービスにはEvent HubsとEvent Gridがあり、それぞれEventの発行元が多かったり分析用データの蓄積のために処理速度が必要だったりする場合はEvent Hubsを利用し、発行元が1箇所で決まっている場合等要件がシンプルな場合はEvent Gridを利用します。
それぞれのサービスの違いについてより詳しく知りたい場合はmsdnのドキュメントや、あるいはMicrosoft製品の学習サイトであるMicrosoft Learnでも取り扱っています。
Microsoft LearnではMicrosoft製品について分かりやすくて順を追って解説してくれているので入門の際の学習リソースとして便利なのでぜひ使ってみてください。
https://docs.microsoft.com/ja-jp/learn/modules/choose-a-messaging-model-in-azure-to-connect-your-services/index

MassTransit.RabbitMq 消えるデフォルト値の怪の巻

この記事は後ほどcloud.config TechBlogにマルチポストされます。

RabbitMq、使ってますか？
マイクロサービスアーキテクチャが流行りだしてからサービス間通信の方式として再注目され始めたメッセージキュー、そしてそのミドルウェアとなるのがRabbitMqですが、これまでもその使い方についていくつかの記事を作成してきました。
今回は、自分がそれを触っていて若干混乱した挙動について紹介したいと思います。

消えるデフォルト値の怪

C#においてクラスをシリアライズする際、通常JsonSerializerかJsonconvertを使います。
これらでクラスインスタンスをjsonにシリアライズする際は例えばこんなクラスがあったとして・・・

public class Test   
{   
    public bool IsTrue { get; set; }   
    public int Number { get; set; }   
}   

それをこんな風にしてやるとシリアライズできます。

var test = new Test();   
var jsonString = JsonSerializer.Serialize(test);   

このコードの出力結果は{"IsTrue":false,"Number":0}となります。

さて、RabbitMqにMassTransitを通してメッセージをやり取りする場合、メッセージはこのjsonの形でやりとりされます。
メッセージ取得の方法については以前の記事を参考していただくとして、そこでやりとりされるメッセージの内容はこのような感じです。

"message": {   
  "isTrue": true,   
  "number": 123   
},   

しかし、これがもしデフォルトの値だと・・・

"message": {},   

こうなります。
メッセージの中身が一見空白のようになってしまいます。 ここでいうデフォルトの値とは、IsTrueはfalse、Numberは0の値が入っている場合です。

はじめこのメッセージの内容を見たとき、パラメータが正常に送信されていないんじゃないかとも思いました。しかし例えばboolの値はTrueだとmessageの内容に含まれていたので、デフォルトの値はパラメータ名ごと省略して送信しているのだと気付きました。
次に心配になったのが、これをメッセージとして送信したとして、メッセージを受け取った側は正常にデシリアライズしてくれるのだろうか？ということでした。
結果から言えば、このメッセージをデシアライズすると正常にIsTrue=false、Number=0のTest型のインスタンスを生成してくれます。
なのでこのような挙動があったとしてもプログラムとしては正常に動作してくれます。
どうしてもメッセージの中身が何もないように見えるのが気になる場合、パラメータの中身がデフォルト値でもjsonには出力してもらうためにはどうすればいいかというと、手動でデフォルト値出力をするよう設定してやることで実現できます。
busの設定時にConfigureJsonSerializerでデフォルト値の扱いを設定できます。

var bus = Bus.Factory.CreateUsingRabbitMq(sbc =>   
{   
  //  この辺りにbusのHost等の設定が入ります   
   
    sbc.ConfigureJsonSerializer(settings =>   
    {   
        settings.DefaultValueHandling = Newtonsoft.Json.DefaultValueHandling.Include;   
        return settings;   
    });   
});   

そうするとデフォルト値も出力されるようになります。

"message": {   
  "isTrue": false,   
  "number": 0   
},   

しかし、通常はメッセージングはプロセス間でのやりとりでしか使わないのでデフォルト値は出力されない設定で問題はないと思います。
もし何らかの環境においてjsonにプロパティ名がないとデフォルト値としてもデシリアライズしてくれないということが起きた場合に改めてこの設定をするのがいいと思います。

おわりに

今回はMasstransitを用いてRabbitMqとメッセージをやり取りする際にデフォルト値はデフォルトではシリアライズされないという挙動を解説しました。
Jsonの扱いは様々な言語やフレームワークを用いる際に頻繁に取り扱うことになる分野の一つですが、その挙動の癖はしっかり把握しておきたいと思います。

香川県でWeb制作企業の制作事情を共有する会 WCK第2回に参加しました

概要

先日の2月7日の金曜日の夜、香川県内のWeb制作企業が集まって情報共有を行う勉強会のWCK（仮）第2回に参加してきました。
イベントページはこちらです。
この会は元々近所のWeb制作会社で集まってゆるく情報共有しようとして開かれた会なのだそうで、参加している方々も今回の主催である株式会社ヘルツの社員さんや、登壇される他の企業の社員さんがほとんどでした。
今回のテーマは「各社の制作事情はどんな感じ？」ということで、各社で案件を引き受けてから納品するまでの制作事情を互いに共有しました。
その中で（おそらく）私だけその輪の外部からの参加で、業務内容はプログラマーで畑も違が、Web制作の現場のノウハウ、仕事の流れや県内のWeb制作企業の様子が知りたいと考えていたところだったので、その後の懇親会も含めて、たくさんのことが学べたように思います。
今回は、そんなWeb制作業界についての知識がほぼほぼない視点から気になったところをレポートしていきたいと思います。

気になったトピック色々

ディレクターの仕事って何？

今回発表された企業さんにおいて、実際にページを作るチームでの役割は大きく分けてディレクター、デザイナー、コーダー、システムに分かれている印象を受けました。
それらを明確に分けている場合もあればメンバーが持っているスキルによって分かれている場合もあるようです。
大体名前からイメージできるとおりデザイナーはページのコンポーネントのデザインをし、コーダーはマークアップを行い、バックエンドが必要であればシステムを構築する方に手伝ってもらうという体制で制作を行っていきます。
で、ディレクターは何をするのか？というと、実質なんでも屋のような役割になるようです。
少し調べた限りだと、ディレクターの役割は取引先とコミュニケーションを行ったり、進行管理を行うのがメインなのだそうです。
しかし、プロジェクトのリーダー的な立ち位置であるため、人によってはデザイナーから上がってきたデザインをレビューしたり(デザインもできる人の場合)CMS、ディレクトリ構成等の技術的な決定や設計を行ったり、手が足りなければコーディングを行ったりと、持っているスキル次第でかなり幅広い役割を兼ねる場合もあるようです。
また、制作の進め方もディレクターに依存することが多く、ディレクターによって制作フローが変わることがあるそうです。
社内で統一したやり方を取るというより、進行管理の責任を負ったディレクター毎のやりやすいやり方で制作を行うほうが全体として仕事が進めやすいのかなと感じました。

あって当たり前というわけじゃなかったソースのgit管理

プログラマーとして仕事を始めたときから社内でgitが使われていた自分としては、gitあるいはソース管理システムが使われるのは当たり前のように感じていました。
しかしソース管理システムが生まれる前はソースはファイルでやりとりされていたという歴史があるわけで、それが今でも行われているところもあるということは一つの発見でした。
現在はファイルシステムでバージョン管理しているけれども環境毎に別の個所を編集したために事故が起きた事例があり、そろそろgitを使おう！という動きを始めたそうですが、誰もが通る道とは言ってもソースを移行したりgitの使い方を学んだりと、環境の移行はかなり大変そうでした。
ひょっとしたら会のテーマとしてgitの使い方が取り上げられることもこの先あるかもしれません。

コーディングガイドラインの話

制作事情のお話の中で、多くの場合コーダーはプロジェクトに一人、二人という体制で制作が行われているというお話を聞きました。
そして、そうなると社内でコーディングガイドラインは決めるかというと決めていないところが多いようでした。
コーディングガイドラインを作ることの意義の一つは、人によって書き方が変わるコードの書き方を統一することでコードを読む際の認知負荷を下げて読みやすくし、複数人でコーディングを行う際に作業がしやすくなることだと思います。
しかし、コードを触る人の数が少ないとそのメリットも享受できなかったりもするというのがその理由なのだそうです。
ただ、そんな中でもコーディングガイドラインを作ろうとしているところがあり、その作成のために毎週決まった時間を取ってこれまで半年ほど話し合いをしながらガイドラインの作成をしてきたそうです。
そうすることで規模が大きい案件に割り当てられるコーダーの数が増やせたり急にメンバーが休んでも対応がしやすくなったりできます。
ガイドラインをメンバーに浸透させるのには時間がかかるそうですが、うまく回せたときのメリットは大きそうです。

おわりに

今回は県内でWeb制作を行っている人たちで集まって交流するイベントに参加してきてWeb制作の制作事情について学んできました。
普段はバックエンドのプログラミングをメインで行っていますが、今回のイベントを通してフロントエンドコーディングやWeb制作の現場という視点からのコーディングや体制づくり、制作フローについての視点を得ることができたと感じます。
今回お話した主催の方、参加された方々、どうもありがとうございました！

IoTを実際に攻撃してみようの勉強会セキュリティうどん(かまたま)17杯目 #secudon

概要

2月の頭に再び1週間程度の休暇を取ることができ、2月1日に香川に戻ってきました。
これから9月ごろまで忙しくなりそうなので、その前にということで。
遅くともクリスマスには帰れるさ、ﾊﾊﾊ...
さて、そんなわけで帰って来て早々に参加したのが今回レポートする勉強会、セキュリティうどん(かまたま)の17杯目です。
Twitterのハッシュタグは #secudon ですので、イベントの様子が気になる方はTwitterで検索してみてください。

セキュリティうどん（かまたま）でIoTセキュリティのハンズオン勉強会に参加しました。WebカメラやLEDライトをRaspberryPiから制御してみましたよ。#secudon pic.twitter.com/BBWEcTxTiI

— Hiroki (@taniokah) 2020年2月1日

おやつありがとうございます🍘
#secudon pic.twitter.com/0UI67GsXDI

— Tomohiro Kobayashi (@kobatomo3H) 2020年2月1日

↑当日の様子

告知用のTwitterアカウントもあります。
この勉強会はこれまでも16回+α開かれているそうで、過去にはゲーム形式のHardeningをやったり、マルウェア判定についてハンズオン形式で学んだりと、かなり「実際に触ってみる」という雰囲気の強い勉強会になっています。
私はこの会への参加は初めてで、今回のテーマであるIoT機器耶蘇のセキュリティについても実はこれまであまり触ったことのない分野です。
ただ、踏み台攻撃やWebカメラの盗聴などの話で話題に上ることも多くなってきた分野なので、そろそろ何か触れるところから学んでおきたいなという思いで参加しました。
ちなみに私のセキュリティ能力は去年秋のセキスペの午後2試験がギリギリ67点で落ちたレベルです。
今年の秋にもう一度リベンジする予定です。

やったこと

今回はIoT機器を脆弱性情報を参考にして実際に攻撃するという内容のハンズオンが行われました。
詳しい実際のやり方を書くと書く方向から怒られるそうなのでアウトラインだけ書いておくと、ラズベリーパイを通してIoT機器に接続し、IoT機器へのログインに必要なパスワードを盗み出したり機器のOSに侵入したりといったことを体験しました。
こういったことが、ネット上に存在する脆弱性レポートのとおりに実行すれば攻撃できてしまう！ということを実感できるハンズオンでした。

所感

私自身セキュリティどころかネットワークまわりもそこまで知識があるわけでなく、初めに会場に入った時は機器と配線を見て「これはいよいよ背伸びしすぎたかな」と思ったりしました。
というか、ネットワークの攻撃もラズベリーパイも初めての攻撃実践についてはペーペーの状態での参加です。
しかし、ハンズオンで共有された講師の方が作られた資料の内容はかなりしっかりしていて、最低限そこに書いてあるとおりにコマンドやコードを打てば実行できるようになっていたのでなんとかついていくことができました。
「高度な知識がなくても攻撃を実行することはできてしまう」という話がハンズオン中何度か出ましたが、実際にその通りだと感じました。

気になったトピック

IoTセキュリティのしっかりした機器を買おう！という話

今回サンプルとして使用したIoT機器は、どれも実際に購入できるものでした。
しかし、そうして入手できる機器の中にはセキュリティ対策の不十分なものが多くあるようです。
これから購入しようとしている機器に脆弱性がないかどうかは購入する前に十分に調べる必要があります。
そもそもそんな脆弱性のある機器はメーカーの責任で改善されないのかという話もありますが、メーカーが海外のものであることやその機器が安全であるとする基準が国によって異なるため、あまり期待はできないようです。
そういった背景から、IoT機器のセキュリティの強度は大部分が利用者の側に依存するのかもしれないなと感じました。
差し当たりまだ自分の部屋にIoT機器を導入し足りすることは考えていませんが、何かやってみようと考えたときは機器選びから設定まで強く意識する必要がありそうです。

おわりに

今回は休暇を取って香川に帰省したその日に参加した勉強会のセキュリティうどん(かまたま)の17杯目に参加したレポートをしました。
初めてのラズベリーパイ、初めてのIoT機器の攻撃でしたが丁寧否説明で攻撃の手法やその周りでIoT機器を利用する際に気を付けることなどを学ぶことができました。
また、その後のおやつ会やLT、希望者で集まっての懇親会などを通してたくさんの方とお話しすることもできてとても参考になることも多く何よりめちゃくちゃ楽しかったです。
当日参加された方、主催者の方々、どうもありがとうございました！

Firebase再入門! Firebaseハンズオンに参加してきました

概要

ついに休暇から東京に帰る前日になってしまいました2月8日ですが、Firebaseのハンズオンに参加してきましたのでレポートします。
今回のテーマは表題の通りFirebaseのハンズオンです。
connpassのイベント紹介ページ
主催は四国で主にgoogle系の技術勉強会を頻繁に（ほぼ毎月）開催していらっしゃるGDGShikoku、講師の方はsansan株式会社所属で現在徳島でリモートワークをしていらっしゃる辰濱健一さんです。
Twitterでのハッシュタグは #gdgshikoku および #firebase なので、その時の様子が気になる方は調べてみてください。
当日の様子

もうすぐ始まります！#gdgshikoku pic.twitter.com/ZzkyNDlqPo

— Kenichi Tatsuhama (@tatsuhama50) 2020年2月8日

参加するにあたっての私のレベル感

実は、私自身はFirebaseは業務でも使った経験があります。以前は社内向け決済アプリの開発チームに参加してFunctionを作ったり、自分のポートフォリオサイトを作ってそれをホスティングしてもらったりしていました。
今回は主にその時に習得したことを思い出したり何かしらノウハウを共有できればと考えて参加してきました。

Firebaseとは

Firebase
FirebaseはWebアプリケーションを作るのに便利な機能をまとめたようなサービスで、Googleから提供されています。
認証機能やデータベースなどWebアプリケーションを作成するのに必要な要素が豊富に取り揃えられており、それらをSDKを用いて簡単にWebアプリケーションに組み込むことができます。
また、それぞれの機能を連携させることもでき、例えばAuthの機能を使ってログインしている状態でしかデータベースのFirestoreにはアクセスできない、といったことも簡単に実装できます。
そしてそうして作られたアプリケーションをHostingの機能を使ってホスティングするところまで、必要な機能を全てFirebase内で完結させることができます。

やったこと

今回のハンズオンはgoogleから提供されている学習サイトのCodelabsで解説されているFirebaseでのWebアプリの作り方についての内容に沿って行われました。
ユーザー登録をしてサイトにログインができ、その登録名でコメントを残すことができます。
このアプリケーションを作成するにあたって行ったこととしては、
- firebaseで用意されている認証機構を使って認証機能を実装
- DBにはfirestoreを使用
- firestoreにセキュリティルール設定
- Hostingを使ってWebサイトをHosting
辺りになります。
これらを大体2時間半と少しかけて解説やQ&Aを行いつつこなしました。
↑開発中の様子です。 ちなみにcodelabsでは全体で1時間程度で終わることが想定されているそうです。（codelabs上側の予想完了時間より）
どういう状態で始めればそれくらいの時間で終わるのかはかなり疑問でした・・・
最終的にはfirebaseと連携してデプロイまで行い、公開まで行うことができました。

気になったトピック

アプリケーションを公開した後どうやって停止させる？

Firebaseを自分で触ってみたりポートフォリオサイトを作っていた時も感じていたのですが、一度公開したサイトを一度非公開にして手直ししたいということは多いです。
あるいは、サンプルなどを使ってFirebaseを触ってみた後もう後悔したくないかなーけどプロジェクト自体は残したいなーということもありました。
こういう時サイトを公開停止する方法はというと、知る限りだとFirebase CLIを用いてfirebase hosting:disabledを使うか、Firebaseのダッシュボード上からアプリケーション/プロジェクトを削除するかの2択になります。
やりたいこととしては、ダッシュボード上でアプリケーションを公開/非公開みたいな感じでスイッチすることを考えているのですが、やり方はまだ見つからず。
知ってる方いたら教えてください！（切実）

うどん食べました

勉強会の前にお昼のうどんを綿谷さんで食べてきました。
ぶっかけ小250円でもそこそこ量がありました。素敵！

やっぱり作りながら学ぶのが一番だと思うの。「Vue.jsのツボとコツがゼッタイにわかる本」

この記事はcloud.config tech blogにマルチポストされる予定です。

Vue.jsのツボとコツがゼッタイにわかる本

はじめに

以前にVue.jsでポートフォリオサイトを作ったのですが、その時からそろそろフロントエンド開発を一度基礎から学びたいと思うようになりました。これまでVue.jsを用いてフロントエンド開発に業務として携わったり、自分で1からサイトを作成したりすることを通してフロントエンドフレームワークの使い方についてはある程度理解できてきたのですが、まだそれらの意義や基礎についてそこまで学んできていませんでした。

なので、フロントエンドフレームワークとは何か？それを使うと何がどうよくなるのか？について、Vue.jsを扱ったものの中で何かしら1冊入門書を買ってフロントエンド開発に再入門したいと思い、見つけたのがこの本でした。 今回はそんな本書を書評したいと思います。

なぜこの書籍を選んだか

今回Vue.js入門書を買った目的は前述のとおりです。その中で買う本を選んだ基準としては、 - サイトでの実装例がある（最重要） - フロントエンドフレームワークの基礎についてのトピックがある(重要) - ユニットテストのトピックがある（できれば) これらの3点です。

多くのエンジニアにとってそうだと思うのですが、技術を学ぶ際は実際に手を動かしながら学ぶことが最も効率がいいと考えています。そういった意味で、なるべくサンプルが多いものを、そしてサンプルで取り扱う範囲が広いものを、と考えて選んだのがこの「Vue.jsのツボとコツがゼッタイにわかる本」でした。 というのも、この書籍においては全6章のうち3章から6章まで商品ページと自動見積もりページをテーマとしたサンプルを用いてVue.jsを用いた実装の解説がなされています。 その内容についても後述したいのですが、そのサンプルの解説の量の多さを見て、本書をフロントエンド再入門のための学習リソースとして選択しました。

目次

第1章 Vue.jsとフレームワークの基礎

第2章 Vue.jsをはじめよう！

第3章 Vue.jsで商品一覧を描画してみよう！

第4章 Ajaxで商品データを外部ファイルから読み込もう！ 第5章 Vue.jsで自動見積フォームを作ってみよう！

第6章 Vue.jsのコンポーネントをモジュール化してみよう！

フレームワークを使わなかったらどうなる？と対比して学ぶVue.js

この書籍の特徴的な点として、サンプルのサイトを作る際にまずはHTML,CSSとJSを用いて一通りの機能を実装している点があります。

例えば、第3章ではECサイトの商品一覧ページを作成するのですが、まずは表示内容をHTMLで記述したり、そのページの機能として商品の絞り込み機能や並び替え機能といった機能をJavascriptで実装しています。そして、その後でそのページにVue.jsを導入し、内容をVue.jsの機能を用いて書き換えていきます。

このサンプルの解説の仕方の何がうれしいかって、「普通だったらこう実装するけど、フレームワークを使うとこう便利になる」ということが一目瞭然になることです。フレームワークを用いた例のみでサンプルが解説されていると、フロントエンドフレームワークの学習の初めの段階だと「フレームワークを使うとこんな風に書けるんだな。で、それがどう便利なの？」といった点が疑問として残ってしまいます。それを、先にフレームワークを使わない例を示すことによってv-forやv-onが何に置き換わってどう便利になるのかといったことを分かりやすくしています。

おわりに

この書籍はVue.jsの入門書としてだけでなくフロントエンドフレームワーク自体の入門書としても役立つように思います。 どのようなフレームワークを用いて実装するにしろ、そのフレームワークを使わず素のJSで書いたらどうなるか？を考えることはそのフレームワークの利点を把握するのに役立つと考えています。本書ではHTML,JSで書いたコードをVue.jsを用いて書き直していましたが、それがAngularやReactで書くとどうなるか？といったことを考えてみるとフレームワーク間の違いを理解したりそれぞれのフレームを用いた実装の仕方を理解したりするのに役立つのではないでしょうか。

「Design It!」書評

はじめに

これからの業務の中でアーキテクチャ選定の知識も必要かなと考えていたところ、「こんな本があるよー」と言って教えてもらったのがこの本です。
しかしここしばらく忙しかったりクレジットカードの今月の利用上限（私はクレカ破産が心配なので普段10万円に設定してます)に引っかかったりしていてこれまで読めていませんでした。
この度年末で実家帰りして本を読む時間が作れたり利用上限が無事引き上げられたり（やっぱり不安なので来月は元に戻します）したため、書籍を購入して読むことができたので、書評して内容を共有したいと思います。

Design It!とは

皆さん大好きO'reilly本です。
原著は2017年に出版され、2019年11月に日本語の訳が出版されました。
この書籍はソフトウェアアーキテクチャのデザインについて述べられた本で、アーキテクチャを決める際の考え方から、アーキテクチャデザインを行う際の方法論まで幅広く扱われています。
これまで作っているソフトウェアやサービスのアーキテクチャについてあまり深く考えたことがなくて「あーそろそろアーキテクチャについても考えられるようになっといたほうがいいな」とか考えている方や、既にアーキテクチャを決めるような業務に携わってはいるけれどもどのように設計を行うべきかといった考え方が固まっていなくて何かしら確固とした基準を持てるようになりたい方にはぴったりの一冊だと思います。

目次

第Ⅰ部 ソフトウェアアーキテクチャ入門
- 1章 ソフトウェアアーキテクトになる
- 2章 デザイン思考の基礎
第Ⅱ部 アーキテクチャ設計の基礎
- 3章 デザイン戦略を立てる
- 4章 ステークホルダーに共感する
- 5章 アーキテクチャ上重要な要求を掘り下げる
- 6章 アーキテクチャを選ぶ（君がアーキテクチャに選ばれる前に）
- 7章 パターンで土台を作る
- 8章 意味のあるモデルで複雑さを扱う
- 9章 アーキテクチャデザインスタジオを開く
- 10章 設計判断を可視化する
- 11章 アーキテクチャを記述する
- 12章 アーキテクチャに通知表をつける
- 13章 チームのアーキテクト力を強める
第Ⅲ部 アーキテクトの道具箱
- 14章 問題理解のアクティビティ
- 15章 潜在的な解決策を探るアクティビティ
- 16章 設計をタンジブルにするアクティビティ
- 17章 設計の選択肢を評価するアクティビティ

デザインマインドセットの話

この書籍は、「デザインマインドセット」という言葉を中心に展開していきます。
この言葉は本のほぼほぼ最初に出てくる言葉で、それ以降の章のアーキテクチャ設計の方法論の中心となる概念です。
これはソフトウェアシステムのアーキテクチャを設計する際の観点で、「理解」「探求」「作成」「評価」の4つがあります。
大雑把にそれぞれのマインドセットを説明すると以下のようになります。

• 「理解」のマインドセット
  ソフトウェアで解決しようとしているビジネス上の問題や品質特性について積極的に理解しようと働きかけるマインドセット。

• 「探求」のマインドセット
  より良いソフトウェアアーキテクチャを求めて探求を行おうとするマインドセット。

• 「作成」のマインドセット
  ドキュメントやプロトタイプといったものを作ってアーキテクチャのアイデアを積極的に人に伝えようとするマインドセット。

• 「評価」のマインドセット
  今考えているアーキテクチャが問題に対して妥当かどうかを判断するマインドセット。

第Ⅱ部では、アーキテクチャのデザインの考え方について、これらのマインドセットを用いて解説されています。
そして、第Ⅲ部ではアーキテクチャデザインを行うにあたって実際にすることをアクティビティとして、マインドセットごとに解説されています。

特に有用だと思った「作成」マインドセットのアクティビティ3選

第Ⅲ部においてはアーキテクチャデザインを行うにあたって実際にやることが解説されていると書きましたが、その中で「作成」マインドセットを用いて行うアクティビティの内容はアーキテクチャデザインを説明する際に必要な作成物そのものです。
その中で、書籍を読んでいて自分が現状のアーキテクチャを説明する際にまず作っておきたいなと感じた作成物をいくつかピックアップします。

まずはこれを読もうリスト

これは、ステークホルダーや新参の開発者が現状のアーキテクチャについて素早く理解することを助けるリンク集です。
ほとんどのプロジェクトにおいてどこかしらにWiki等の形で作られているとは思いますが、ここをうまく整理、管理しておけば（書籍では「キュレーション」と呼ばれている）アーキテクチャを知るための出発点として確実な情報が提供できるため、かなり重要だと考えます。
例には「放置され気味だけどまだ使える」とか「このドキュメントは最新」といったコメントも加えられており、自分が作るときはマネしたいなと感じました。

アーキテクチャデシジョンレコード

アーキテクチャを設計してから時間が経つと、「あそこなんであんな設計になってるのだっけ？」という話をする機会が増えます。
新しい開発者が開発チームに参入してきたときや新しい要件が追加される際などはなおさらです。
その際に、過去の設計を変更するべきかどうかといった判断を迫られるわけですが、その際に有用なのがこのドキュメントです。
内容としては、設計判断ごとにタイトル、背景、内容、ステータス、影響といった項目を埋めてレコード上にしたもので、それぞれの設計判断を後から振り返りやすくすることができます。
設計判断の背景や理由、影響範囲を記述しておくことによって、将来的に設計を変更するべきかどうか判断する際にその変更を行う理由が過去の設計判断より重要かどうか比べることが出来たり、アーキテクチャの変更の履歴が追いかけやすくなったりします。
アーキテクチャについて記述するとき、普段私たちは現状の設計だけを記述しがちですが、それに加えてどんな背景や理由があったかについても記述しておくべきだと感じました。
また、書籍内ではこれをレコードとして記録するような説明がなされていました。
イメージとしては、excelのようなスプレッド形式で列ごとに背景、内容、ステータス・・・といったカラムを作るものです。
これについては、特に全体のアーキテクチャについて説明することを考えるとこの形式は網羅性としてどうなのという疑問を感じています。
私がこれを作るならば、設計判断についてレコード形式で時系列に記録するものとは別に、現状のアーキテクチャについて全体図、各部の設計、それらの背景や設計判断の理由をまとめたものを別に作るかなぁ等と考えながら読んでいました。

選ばなかった道

前述のような「アーキテクチャを変更すべきかどうか」問題を解決するもう一つの方法がこれになります。
過去に下そうとして却下した設計判断について、その理由とともに記録しておきます。
これによって、過去に却下した設計判断が後になって急にチーム内で湧き上がって採用されるような事態を防いだり、あるいは過去に却下した設計判断でも当時の背景と現状が変わったということを根拠として改めて採用するといった判断を下す際の根拠として使うことができたります。