前回のブログ（根回しとロジカルシンキング）では、ＩＴプロジェクトを成功に導くために、必要な根回しは行う意味があることを書きました。
www.three-wise-monkeys.com
しかし、根回しをするしないに関わらず、プロジェクトにリスクはつきものです。
いまから２０年ほど前に、情報処理で活躍する第一人者の方から教えを頂いたのが、以下に書いたリスクです。そのときは「なるほど〜こういう風にリスクは存在するんだ」と、半ば他人事のように聞いていました。
あれから２０年たったいま、どのリスクも経験している自分に気がつきました😅😅
1️⃣ 外部リスク
ＩＴプロジェクトの外側の要因で発生するリスクです。
たとえば、２０２０年はコロナ禍で東京オリンピックが延期され、訪日観光客が激減しています。そのため、オリンピックやインバウンドをあてにしたＩＴプロジェクトは軒並み中止・延期しました。
外部リスクは不可抗力ですので予防は困難です。
ＩＴ革命が叫ばれた２０００年、わたしの目にうつるＩＴ業界は光しかありませんでした。しかし、その後、リーマンショックや東日本大震災でいくつものプロジェクトが頓挫しました。
「外部リスク」が原因でＩＴ業界を去った友人・知人もたくさんいます。
2️⃣ 政治リスク
プロジェクトの利害関係者の圧力や対立から起きる干渉です。
会社業務のＩＴ化にあたり、ＲＦＰ（Request for Proposal）の策定に携わった経験があります。
ＩＴベンダーのＡ社、Ｂ社、Ｃ社から提案があり、プロジェクトオーナーの意向でＡ社が選定されました。しかし、プロジェクトの動きが計画通りに進まないなか、オーナーの資質を問う声が経営層からありました。
結局、そのオーナーは座を奪われました。新しいオーナーは、古くから付き合いのあったＢ社に委託を変えました。これにより、プロジェクトは中断・仕切り直しとなりました。
公平な手段で選定されたはずのベンダーが経営層のどろどろした争いで途中で変わるのは、いい感じがしなかったです。
3️⃣ 要求リスク
システムの要求（機能要件）が定まらない、不完全なことです。
たとえば、ＳａａＳ型クラウドサービスを提供する会社がＣＲＭ（Customer Relationship Management）を実現する企画を立てます。既存顧客をランク分けし、優良顧客にはより高級なサービスを提案し、離反しそうな顧客にはアフターフォローしようと考えます。
既存顧客に焦点をあてたこの考え方は、次のマーケティング理論に基づいています。
新規顧客に販売するコストは既存顧客に販売するコストの５倍かかる。
５：２５の法則
既存顧客の離脱を５％改善したら、利益率が２５％改善される。
あるいは明確な目的がないなかで、顧客データを収集します。そのようなデータは不完全で最新化がされません。情報セキュリティの観点から見ると、収集する目的のない顧客データは収集するべきではありません。
4️⃣ 技術リスク
システムのセキュリティ要件、運用要件、保守要件、将来の拡張性など、非機能要件に関わるリスクです。
利用者が使うＷｅｂアプリケーションの入力画面は、その利用者に関する情報のみが参照可能なはずです。
しかし、Ｗｅｂアプリケーションのセキュリティ対策がしっかりしていないと、入力値にＳＱＬ文を組み立てるアプリケーションの脆弱性を突いて、データベースに不正な操作される可能性があります（ＳＱＬインジェクションといいます）。
アプリケーションに脆弱性があると、開発完了後も修正対応が発生します。それによりサービスを中断せざるを得ない事態となります。
5️⃣ 要員リスク
適切な人材の確保や教育の実施に関わるリスクです。
たとえば、クラウドサービスで競合他社との差別化をはかる為、スピーディな機能追加を行い市場に提供しようと考えたとします。迅速さを実現するため、従来の開発チームと運用チームを一体化したＤｅｖＯｐｓ（デブオプス）の考え方を取り入れたとします。その場合、開発要員は運用を理解し、運用要員は開発を理解する必要があります。
しかし、開発と運用は仕事の思想がまったく異なり、基本的に相性は悪いです。開発と運用の相互理解は「言うは易く行うは難し」で、それを育てる企業文化の形成は時間がかかります。
6️⃣ 管理リスク
プロジェクト管理の問題によるリスクです。
上記で述べた「要求リスク」「技術リスク」「要員リスク」は、それを早めに検知できれば、早めの対応策を考えることが出来ます。しかし、プロジェクトの管理がされてなければ、問題は先送りにしたまま、時間が過ぎます。
結局、それはプロジェクトのコストに跳ね返り、予算オーバーを招きます。
とどのつまり、プロジェクトは管理が出来ているか、管理が出来ていないかが、成功と失敗の分水嶺なのでしょう。
