Design It! 輪読会 3章 「デザイン戦略を立てる」
Design It!を輪読して2回目になります。前回は1,2章を輪読しまして、今回は3章をおこないました。3章はソフトウェアシステム開発の中のアーキテクチャ設計に対するリスクを取り上げる章で、この章から部も変わり第2部ということで「アーキテクチャ設計の基礎」の話に入っていきます。
この章で伝えたいことを整理する
この章で伝えたかったことはリスクとうまく付き合っていくことの大切さと、その方法について述べられている章に感じました。 はじめに「時間・コスト・スキル・知識などの面から生まれる障害によって完全性のある合理的な設計はできない」ことが述べられており、そういった中でもソフトウェア開発においてアーキテクチャは組まなければいけないし、また合理的な設計ができない中でも適当なアーキテクチャを組むようなことはしてはいけないことが述べられていました。本の中でのおすすめは自分たちが解決したい必要最小限のアーキテクチャをゴールとしてそれだけに集中したほうが良い事が書かれていました。
ソフトウェアのアーキテクチャ設計にかけていい時間と、規模に応じたアーキテクチャ設計をするメリット・デメリットについても丁寧にまとめられていました。他にも実際にアーキテクチャ設計をしたあとの成果物の確認や設計をとめる時の条件といったアーキテクチャ設計について話されるタイミングで見落とされがちのことについてもまとめられていました。
疑問になった点
この章で疑問になった点は、「上位リスク」という言葉で、この言葉は48Pで初めて出てきました。本文中に出てきた説明を引用します。
リスク駆動の設計アプローチを採用しているので、設計計画には上位リスクを組み入れよう。リスク一覧は、ソフトウェアシステムの寿命のあらゆるタイミングで見直す必要がある。特に、前払いのアーキテクチャ設計を行っている間には、あらゆるタイミングで見直そう。*1
自分はこの説明を読んでも理解できず、輪読会にて参加者の意見を聞いてみたかった点でした。
輪読会の中では、「ソフトウェアを作るということはビジネス活動としてなのでビジネス側のリスクも考慮に入れないと、より詳細な部分が崩れていく」という結論に至りました。改めて精読すると、文章中の「ソフトウェアシステムのあらゆるタイミング」という記述から、ソフトウェアライフサイクルで取り上げられる「開発・運用・保守」といったタイミングで見直されるべきものであると考えられ、「要件定義レベルで決められるべきものが変化してしまうようなリスクを考慮しておこう」のような注意喚起に聞こえてきました。自分としては、このあたりも踏まえて輪読会での解釈の方向性は間違っていないと考えました。
