技術リスクを識別するための入口は「要求の実現性」だ。「要求とアーキテクチャーをぶつけて検証すること」が技術リスクを発見する王道となる。筆者がお勧めするシナリオベース分析を用いた簡易的な方法を紹介する。
技術リスクは、いつ、どのようにして識別すべきなのだろうか―。技術リスクの検証が「これで十分」と言えるレベルは、状況によって異なる。だが、どのような状況でも、重大な技術リスクはプロジェクト開始前に識別し、その後に大きな影響が出ないようにしておくべきだ。
プロジェクトの企画や提案の際、いくつかソリューション案が出てくる。そのソリューションの姿が見え始めた時点から技術リスクへの対応は始まる。そして計画と予算、体制が確定してゴーサインが出る前に、検証や代替案の準備といった主要な対処を終えたい。
アーキテクチャー設計の主目的
まず、誰が技術リスクを識別すべきなのか。技術リスクは、適切なアーキテクチャーを探索する、いわゆるアーキテクティングの過程で見つかる場合がほとんどだ。つまり、重大なリスクは主にITアーキテクトが識別する。
開発に先立ってアーキテクチャーを準備する目的は、開発工程での試行錯誤を少なくすることだ。開発チームはアーキテクチャーによって統制される。チームが本格的に開発を始める前に試行錯誤を終わらせることが、重要なマイルストーンとなる。そしてその試行錯誤の原因が技術リスクにある。
全く新規のプロジェクトであれば、アーキテクチャーの入力となる要求の整理に2週間、アーキテクティングと技術リスクの識別に2週間を割り当てるよう推奨している。その際、アーキテクティングにはアーキテクトに加えてアシスタントのエンジニアが1人いるとスムーズだ。
2週間という短い期間で重大な技術リスクをもれなく識別するには、体系的なアプローチが必要だ。場当たり的な検証は時間の浪費でしかない。IT業界では適切なアーキテクチャーの構築のために研究が重ねられ、「ADD」「ATAM」「ACDM」といったアーキテクチャー設計・分析手法が確立されている。これらの手法の根底には、「シナリオベース分析」と呼ばれるアプローチがある。「構造をシナリオで検証する」という活動原理だ。
ここからは、筆者の実践しているシナリオベース分析を用いた簡易的なアーキテクチャー設計手法と、その中での技術リスク識別方法を紹介していこう。