7. D-Case 10箇条

1. ゴールは命題の形をしていなくてはいけない

基本の一つです。「システムは安全である」など、はい、いいえで答えられることをゴールに書きます。

2. トップゴールに、システムのスコープを前提としておく

システムのディペンダビリティを議論するときは、まずそのシステムがどの範囲にあるのか、 明確にする必要があります。そうでないと、何について議論しているのかわからなくなったり、 議論が発散したりします。トップゴールの前提に、明確にシステムのスコープを書きましょう。

3. ライフサイクル、各フェーズの入出力ドキュメントを整理する

D-Case は、システムのライフサイクルで作られるドキュメントをもとに作られます。 これらを整理してから、D-Case を書きはじめましょう。

4. 前提は必要な場所のみにできるだけおく

前提には、議論をするときの前提となるドキュメントが置かれます。 議論の前に置いてあればどこでもいいのですが、なるべく必要な場所だけにおきましょう。 そうしないと、前提の影響が及ぶ範囲が広くなりすぎ、議論の構造が見えにくくなります。

5. D-Case の構造を大まかに把握する

D-Case は時として大きくなり、関係するドキュメントも多くなります。 おおまかな構造を把握しながら、議論をしたほうがいいです。 木だけに注目せず、D-Case 全体の森を意識しましょう。

6. 典型的な議論構造を用いる

他の人に一所懸命に説明しても、なかなか伝わらないことがあります。 そういった場合は、自分勝手なやり方で議論をしている場合があると思います。 D-Caseも同じで、できるだけ、誰にもわかりやすい、当たり前な議論の仕方を心がけましょう。

7. 他のシステムとの関係を考えながら記述する

一つのシステムは、単独で存在することはありません。必ず他のシステムと関係します。 システムのスコープの外にある、他のシステムを常に意識しながら書きましょう。

8. 常に想定外なことを考えながら記述する

D-Case に書かれている議論が、その外にあるスコープを前提にしたものであることを常に認識したほうがいいです。 オープンな世界では常にスコープから外れた想定外のことが起こります。 記述するということはなにかを想定することになりますが、 常にその外にあることを意識して書きましょう。

9. 完全なD-Case は存在しない。常によりよいD-Case を目指す

システムのディペンダビリティを完全に正しく記述することは不可能です。 正しさ自体、人によって違うし、時間と状況に応じて変わっていきます。 スコープを完全に正しく設定することも、前提を完全に正しく設定することも、 すべてのリスクを尽くして議論することも不可能です。 不完全さを認めた上で、よりよい、わかりやすいD-Caseを書くことを心がけましょう。

10. ほかにもいろいろ大切なことがあります。みなさんのお考えをぜひお教えください。