
t0mmy
学習履歴詳細
書籍 「Design It!」 3章 読了
やったこと
- 書籍 「Design It!」 3章 読了
学んだこと
ポイント
- デザイン思考を使用した、解決策の模索方法
- デザインスイートスポットとは
リスクを活用する
学び
適切なデザインマインドセットを選択し、リスク軽減策発見に役立てる
デザインスイートスポットとは、アーキテクチャ設計に費やすべき、最も費用対効果の高い時間
リスクを以下のように活用する
- リスクを明らかにする
- 頭をよぎった「嫌な予感」を、「条件」と「結果」に落とし込む
- デザインマインドセットを使用して、リスク軽減策を発見する
- リスクを許容範囲内まで軽減出来たら、アーキテクチャ設計に専念する
- リスクを明らかにする
メモ
デザイン思考を使用することで、実験・検証を繰り返しつつ、複雑な問題の解決策を模索できる。
ソフトウェアシステムの持つリスクを考えることで、より幅広いデザイン戦略の一環としてデザインマインドセットを選ぶ方法について学んでゆく。
3.1. 満足のいく設計を見つける
アーキテクチャを設計する前に、ソフトウェアシステムで解決したい問題を定義する。
その問題を完璧に定義することは不可能に近い。
そのため、最適で合理的な設計を追求する代わりに、必要最低限のアーキテクチャを発見することを目指す。
必要最低限のアーキテクチャは、以下の活動を通して発見していく。
- 解決策を実験とみなす
- 問題の解決策を検証する実験と考える
- リスクを減らすことに専念する
- アーキテクトは、失敗する可能性を常に考慮して設計する
- アーキテクチャの失敗は、全ての失敗につながるため
- アーキテクトは、失敗する可能性を常に考慮して設計する
- 問題を単純化する
- 問題を単純化すると、解決策も単純化する
- 定型問題(既知の解決策を利用できる問題)に当てはめることで、先人の知見を活用できるようになる
- 素早く繰り返し、素早く学ぶ
- 問題と解決策を同時に考える
- 問題は、常に解決策を念頭に置いて定義される ... とのこと
- 問題を理解するためには、解決策を探る
- 解決策をうまく探るためには、問題に対する理解を深めなければならない
- => 問題と解決策を同時に考える必要がある
- 問題は、常に解決策を念頭に置いて定義される ... とのこと
3.2 どのくらい前払いの設計を行うかを決める
十分なアーキテクチャへの投資は、将来の修正コスト削減につながる。
一方で、アーキテクチャ設計に時間を割きすぎることは、実装時間を遅らせ、結果的に価値提供も遅れることになる。
ここで、「アーキテクチャ設計に費やす最適な時間いくらか?」という問題が発生する。
最適な時間は、ソフトウェアシステムの大きさと要求の多様性に応じて変化する。
この時間のことを。デザインスイートスポットと呼ぶ。
デザインスイートスポットを見つける
スイートスポットは、アーキテクチャ設計と修正作業時間の損益分岐点。
研究によって、プロジェクトスケジュールの約20%未満辺りが最適と言われている。
以下 は、100 日間の初期開発スケジュールを想定した数値
アーキテクチャに費やす日数 | 修正に費やす日数 | 合計のスケジュール日数 | - |
---|---|---|---|
5 | 38 | 143 | |
17 | 21 | 138 | ★ |
33 | 7 | 140 |
また、以下のことが分かっている。
- ソフトウェアシステムが大きくなるほど、アーキテクチャ設計への投資効果が大きくなる
- 小規模のソフトウェアシステムでは、アーキテクチャ設計への投資効果がほとんどない
- これは、コードを書きなおすほうが早いことを意味する
- 小規模のソフトウェアシステムでは、アーキテクチャ設計への投資効果がほとんどない
- アーキテクチャ設計への投資を怠ると、後半の修正コストが膨大となる
- アーキテクチャ設計へ投資するほど、必要な手直しは少なくなる
スイートスポットは、ソフトウェアシステムの大きさ、複雑さに加え、要求の変動制(要求が、将来的に変更する可能性)にも依存する。
変更される可能性が高い場合、判断を遅らせる。
3.3 リスクに道案内させる
リスクは、成功を妨げるかもしれないものを測るための優れた指標。
アーキテクチャに専念すべきタイミングを決定する指標として、リスクを使用できる。
- つまり、十分にリスクを軽減できたタイミングで、アーキテクチャに専念する
まとめると、以下の通り
- リスクを明らかにし、大きな問題を起こすリスクを特定する
- 特定したリスクを軽減するために、デザインマインドセットを選択し、対応方法を探す
- うまくリスクを軽減出来たら、パッシブデザインへと移行し、アーキテクチャに専念する
条件と結果を明らかにする
リスクを、「条件」と「結果」という二つの要素で説明する。
- 条件 : 事実である「何か」
- 結果 : 発生する「よくないこと」
明らかとなった「条件」と「結果」は、リスクに対して次のアクションを決定する良い情報源となる。
リスクを使用してデザインマインドセットを選択する
設計を通じて、リスクを軽減する。
「嫌な予感」をうまく「条件」と「結果」に落とし込むことが出来れば、設計の助けとなる。
デザインマインドセットは、リスクを軽減する戦略立てに役立つ。
以下の問いかけを参考に、試すべき適切なマインドセットを判断する。
問い | どこにリスクがあるか | 試すべきマインドセット |
---|---|---|
ステークホルダーや他のアクターをもっと深く理解するべきか | 問題 | 理解 |
十分な代替案を検討したか | 解決策 | 探求 |
ステークホルダーは、設計コンセプトを十分理解しているか、また、アーキテクチャを確認できているか | コミュニケーション | 作成 |
設計判断を行う必要があるか | 設計判断や設計の適合性 | 評価 |
リスクが軽減されたら、パッシブデザインへと移行する
リスクを十分軽減できたら、アクティブデザインからパッシブデザインへと移行する。
- アクティブデザイン ... リスクを減らすべく、フィードバックループを積極的に回す
- パッシブデザイン ... 稼働しているアーキテクチャを観察し、必要に応じて措置を講じる
パッシブデザインにて、アーキテクチャから重大なリスクを確認した場合、設計における仮定が誤っていたことを示す。
この場合、再びアクティブデザインに切り替え、新しい仮定に基づいてアーキテクチャを調整する。
3.4 設計計画を立てる
アーキテクチャに費やす時間全般について計画を立てる。
- 分析は前もって行うか?
- 後々の変化を予期出来ているか?
- いつコードを書き始めるべきか?
良い設計計画は、期待を設定し、詳細を説明する者になっている。
また、設計計画は正式なスケジュールである必要はない。
インセプションデッキのような、さっと作成できるドキュメントを使用して、計画を形にする。
- 設計を止める条件
- 必要な設計成果物
- アーキテクチャを文書化する方法を決定し、全員に伝達する
- タイムライン
- プロジェクトスケジュール内の重要なマイルストーンを記述する
- 少なくとも、アーキテクチャ上重要な要求のレビュー、設計案のレビュー、評価実施のマイルストーンは含めること
- 上位リスク
- リスク上位を設計計画に組み入れる
- 様々なタイミングで、リスク上位を見直す
- 概念的なアーキテクチャ設計
- 潜在的な解決策から始める
2023年12月17日(日)
1.0時間