スケジュールやリソースを整理していると自ずとそのプロジェクトのリスクが見えてきます。
今回は，そのリスクを回避する施策を見ていきます。

【３つのリスク回避方法】

リソースを増やす
教育コストも掛かるので早い段階なら採用もあり
緊急的なときには社内で探す

期限を伸ばす
会社の計画による
ステークホルダーによる
プレスリリースによる

開発項目を絞る
まずは一番シンプルな最低限使えるラインを考える
そこから足していく
最低限なことは意外とたくさんあります。

今回は，特に開発項目を絞るの部分を見てみましょう。
例えば，名前を登録するだけのシステムが必要だとする。

名前を入力するページへの遷移ボタン
↓
名前を入れられるテキストボックスを配置
↓
決定ボタンを配置
↓
ボタンを押されると名前が登録される

これだけのように思えますが，ここからユーザーストーリーを引いてみるともっといろいろな過程があることが見えてきます。

名前を入力するページへ行く
↓
名前を入れられるテキストボックスに名前を入れる
↓
決定ボタンを押す
↓
打った名前があっていたか確認したい
↓
確認したら間違っていたので編集したい
↓
無事に登録した
↓
登録した名前を検索したい
↓
漢字のよみが特殊で検索できない

などなど
ユーザーからは色々な課題が生まれます。

その中から，「あると便利だけれど，なくても目的を果たせる機能」を探します。
先程のユーザーストーリーから考えると，

名前を入力するページへ行く
↓
名前を入れられるテキストボックスに名前を入れる
↓
決定ボタンを押す
↓
打った名前があっていたか確認したい  → 確認画面がでると便利だけど，マイページなどで確認・編集が行えればよい。
↓
確認したら間違っていたので編集したい
↓
無事に登録した
↓
登録した名前を検索したい
↓
漢字のよみが特殊で検索できない

このように削除できる部分を探していくと，一枚まるごと新規の画面を作る必要がなくなり，大きな工数削減につなげられることもあります。

他にも，「ユーザーターゲットを考えると，一旦はリッチではなくなるが、なくても影響が少ないことにより決められる機能」なんてものもあります。

たとえば，今回私が新規で行っているプロジェクトでは，AとBという機能を実装するが，AとBの両方を同時に使うユーザーは限りなく少ないことがわかっています。そのため，AとBの機能を両方使える仕様にするという部分は今後の実装に回し，AかBしか使えないという実装を行うように提供するサービスの前提条件を決めました。

こうすると「最もシンプルに一番早く開発する」という目標に近づくことが出きます。まずはシンプルなものをリリースして，ユーザーの声より改善，機能追加をしていくのがもっとも使いやすく，コストの低い開発をめざすことができるしょう。