スモウルビーでMADRを採用しました
スモウルビーの開発でもADR(MADR)を採用して、意思決定の記録を残すことにしました。
Google広告
ADR はArchitectural Decision Record(s)の頭文字をとったもので、日本語では「システム構成に関する意思決定の記録」とでも表現すればいいでしょうかね。
例えば、スモウルビーの開発時に、xxxというライブラリを使うことに決めたとします。そのときに、
- なぜそのライブラリが必要になったのかという背景
- ライブラリの選択肢としては他にどのようなものがあったのか。そして、それぞれの良い点と悪い点。
- 数ある選択肢の中から、そのライブラリに決めた理由
- その結果、課題は解決できたのか
といったことを頭の中で考えたり、手元にメモしたりしますが、それを、ある一定のフォーマットに従ってドキュメントとして残したものが ADR です。
さらに、それをマークダウンで記述し、システム構成に限らず、なにかしら(Any)の意思決定を行った記録を残すためのものが MADR:Markdown Any Decision Records です。
スモウルビーでも当然のように様々な意思決定をしています。直近では、 self.when をやめて別のメソッドにすることにしました。これまでは、なぜそのような考えにいきついたのか、そして、その結果、どうするのか、といったことは、意思決定した私だけが知っている状態でした。これまでの経験で、近い将来、「なんでこうしたんだっけ？」と、疑問に思うのが容易に想像できます。
そこで、スモウルビーでもそういった意思決定の記録を MADR で残していこうと思い立ったわけです。
さっそくですが、 MADR を作成しました。
MADR を記述することで、
- 他の選択肢についても良い点と悪い点を考えておくことで、開発中にやっぱりあっちがいいかな、それともこっちがよかったかな、という迷いが少なくなる
- こうやってブログなどで公開することで、(いちおう) 他人にも確認してもらっているという安心感がある
というメリットはあるかなと思っています。
ただ、すべての意思決定を MADR として記録することは続けられそうにありません。なにを記録して、なにを記録しないのかも決めないといけませんね。そして、その意思決定も MADR に記録することになるでしょうね (笑)
いまのところ、MADR として記録したほうが、記録しない場合よりも開発効率が良さそうなもの、という基準で MADR として記録する/しないを判断していこうかなと考えています。
いつまで続けられるかどうかは未知数ですが、スモウルビーの開発に MADR を採用しました、という報告でした。