Recordsを使って、検討の経緯も含めて文書化するとよい。このADRをレビューするにあたっては、コンテキストのセクションもよくよく議論すべきで、意思決定が妥当かだけ見ても、「実はコンテキストに誤りやあやふやなところがありA案よりもB案の方が良かった...」みたいなことが発生するし、十分にコンテキストが理解されていない第3者や有識者をまじえてのレビューでは、レビューアに意思決定の構造を理解してもらいにくい、ということもある。このとき、デシジョン(代替案とその中から1案選択する過程)とコンテキストは使う思考法が異なる。コンテキストは水平思考(ラテラルシンキング)デシジョンは垂直思考したがってレビュー/議論の観点は以下のようなものになる。「データ同期するのにSQSのメッセージサイズ上限を超えるので、IDだけ送って実際のデータはデータベース共有して、相手先システムからSELECTしてもらおうと思うのですが、それって疎結合といえますか?」という下図の最下層の意思決定だけが、アーキテクチャ相談として持ち込まれることがよくある。この妥当性をみるには、まず検討のプロセスを図のように可視化し、代替案を客観的評価する必要がある。https://gyazo.com/5655e8b46c4b53024277f3fac84e643c加えて、そもそもの前提条件を疑うことも必要で、それが前述のラテラルシンキングによりコンテキストを議論することになる。https://gyazo.com/d013c4330c4cf881d47589db21db6debコンテキストの議論によって「更新データを送る」前提がただの代替案にすぎず、他の代替案を選んだほうが、組織にとっては良い決定になることも多い。現実のプロジェクトには、コンテキストがあやふやだけど、わからないながらも最小限の手数で、とりあえず意思決定して先へ進まなきゃいけない、というケースもある。いってコンテキストをしっかり書かず、代替案だけ並べて議論しても、コンテキストが明らかになってきたときに、その決定の妥当性を見返すチャンスを失う。いう場合でも、仮定で良いのでコンテキストはしっかり書き出し、関係各位の共通認識を作るようにしよう。