この記事はハワイアンAdvent Calendar 2020 10日目の記事です。「日曜月曜あいてるじゃん。完走失敗では。」という突っ込みをうけて説明をうっかり忘れていたのですが、日曜月曜はリアル都合で本当に無理なのでノーカンです。ノーカン。なので継続中です。Advent Calendarのルールやら文化はもちろん知っていますがこのAdvent Calendarにおいては日曜月曜はノーカンです。それでも、もし、もし穴が気になるようでしたら、ご参加、お待ちしております！脊髄で何書いてもよいです！別に技術的な話でなくても良いです。それもまたハワイアン。

昨日に引き続きDesign It!です。意思決定マトリクス(Decision Matrix)とは、書いて字の通り、意思決定の際に評価軸と選択肢を並べた図を用意し、視覚的に比較して意思決定を下す為のものです。ソフトウェア設計においては選択の根拠を残しておく意味で貴重なドキュメントになります。難しい言葉に聞こえますけど、フレームワークを並べて完全性がどうだとか可用性がどうだとかパフォーマンスがどうだとかとかスケーラビリティがどうだとか学習コストがどうだとか比較しますよね。そういうやつです。

ではこの意思決定マトリクスですが、選択肢そのものの変化だったり成長の可能性について考慮されているでしょうか。評価基準に対する選択肢のパラメータって時によって変わると思うんですよね。なまものなので。フレームワークの実装だったり思想だったりメンテナンス状況を見た感じ、1年後2年後にはこうなってるだろうな、 まあでも期待はできないので選択肢を補うツールでも作っておこうかな…というのをぼんやり考えていると思います。近年ではロードマップを示してくれる丁寧なプロジェクトもありますよね。とても役立つので、結果としてリリースが遅れてもいいから是非やってくれという気持ちでいます。話を戻すと、多くの場合は意思決定マトリクスにそういった予測が考慮されていると思うんですよね。それは意思決定の根拠をより明確にする意味でも、後のアーキテクトが当時の判断を分析するためにも、「現在」「n年後」をマトリクスに残して欲しいし、そもそも考えているはずなのでただ可視化するだけです。選択肢の列をふやして○+-を書くだけ。ほんの一手間。特別やることでのデメリットもなさそうに思います。

どうでしょうか。これは本の内容の発展した個人的な気付きなので、ご意見お待ちしています。