叡智の三猿

三猿 × 情報セキュリティ × はてな で発信します。

不確実がいっぱいのプロジェクト

前回のブログ(根回しとロジカルシンキング)では、ITプロジェクトを成功に導くために、必要な根回しは行う意味があることを書きました。
www.three-wise-monkeys.com
しかし、根回しをするしないに関わらず、プロジェクトにリスクはつきものです。

いまから20年ほど前に、情報処理で活躍する第一人者の方から教えを頂いたのが、以下に書いたリスクです。そのときは「なるほど〜こういう風にリスクは存在するんだ」と、半ば他人事のように聞いていました。

あれから20年たったいま、どのリスクも経験している自分に気がつきました😅😅

1️⃣ 外部リスク

ITプロジェクトの外側の要因で発生するリスクです。

たとえば、2020年はコロナ禍で東京オリンピックが延期され、訪日観光客が激減しています。そのため、オリンピックやインバウンドをあてにしたITプロジェクトは軒並み中止・延期しました。

外部リスクは不可抗力ですので予防は困難です。

IT革命が叫ばれた2000年、わたしの目にうつるIT業界は光しかありませんでした。しかし、その後、リーマンショック東日本大震災でいくつものプロジェクトが頓挫しました。

「外部リスク」が原因でIT業界を去った友人・知人もたくさんいます。

2️⃣ 政治リスク

プロジェクトの利害関係者の圧力や対立から起きる干渉です。

会社業務のIT化にあたり、RFP(Request for Proposal)の策定に携わった経験があります。

RFPとは

発注側企業のIT担当が、システムベンダーに対してシステム開発を依頼するにあたり、自社システムに必要な要件(何をいくらでいつまでに)を記載した書類。

f:id:slowtrain2013:20200823154236p:plain:w500
RFPと提案書

ITベンダーのA社、B社、C社から提案があり、プロジェクトオーナーの意向でA社が選定されました。しかし、プロジェクトの動きが計画通りに進まないなか、オーナーの資質を問う声が経営層からありました。

結局、そのオーナーは座を奪われました。新しいオーナーは、古くから付き合いのあったB社に委託を変えました。これにより、プロジェクトは中断・仕切り直しとなりました。

公平な手段で選定されたはずのベンダーが経営層のどろどろした争いで途中で変わるのは、いい感じがしなかったです。

3️⃣ 要求リスク

システムの要求(機能要件)が定まらない、不完全なことです。

たとえば、SaaS型クラウドサービスを提供する会社がCRM(Customer Relationship Management)を実現する企画を立てます。既存顧客をランク分けし、優良顧客にはより高級なサービスを提案し、離反しそうな顧客にはアフターフォローしようと考えます。

既存顧客に焦点をあてたこの考え方は、次のマーケティング理論に基づいています。

1:5の法則
新規顧客に販売するコストは既存顧客に販売するコストの5倍かかる。

5:25の法則
既存顧客の離脱を5%改善したら、利益率が25%改善される。

CRMのシナリオを実現するには、いつ・何のデータを・どのような手段で分析して・顧客にどうアプローチするかを要求事項として仕様化しなければなりません。しかし、仕様が具体的にイメージ出来なければ、収集するべき顧客データは定まりません。

あるいは明確な目的がないなかで、顧客データを収集します。そのようなデータは不完全で最新化がされません。情報セキュリティの観点から見ると、収集する目的のない顧客データは収集するべきではありません。

4️⃣ 技術リスク

システムのセキュリティ要件、運用要件、保守要件、将来の拡張性など、非機能要件に関わるリスクです。

利用者が使うWebアプリケーションの入力画面は、その利用者に関する情報のみが参照可能なはずです。

しかし、Webアプリケーションのセキュリティ対策がしっかりしていないと、入力値にSQL文を組み立てるアプリケーションの脆弱性を突いて、データベースに不正な操作される可能性があります(SQLインジェクションといいます)。

f:id:slowtrain2013:20200823151230p:plain:w500
SQLインジェクション

アプリケーションに脆弱性があると、開発完了後も修正対応が発生します。それによりサービスを中断せざるを得ない事態となります。

5️⃣ 要員リスク

適切な人材の確保や教育の実施に関わるリスクです。

たとえば、クラウドサービスで競合他社との差別化をはかる為、スピーディな機能追加を行い市場に提供しようと考えたとします。迅速さを実現するため、従来の開発チームと運用チームを一体化したDevOps(デブオプス)の考え方を取り入れたとします。その場合、開発要員は運用を理解し、運用要員は開発を理解する必要があります。

f:id:slowtrain2013:20200823022957p:plain:w500
DevOps

しかし、開発と運用は仕事の思想がまったく異なり、基本的に相性は悪いです。開発と運用の相互理解は「言うは易く行うは難し」で、それを育てる企業文化の形成は時間がかかります。

6️⃣ 管理リスク

プロジェクト管理の問題によるリスクです。

上記で述べた「要求リスク」「技術リスク」「要員リスク」は、それを早めに検知できれば、早めの対応策を考えることが出来ます。しかし、プロジェクトの管理がされてなければ、問題は先送りにしたまま、時間が過ぎます。

結局、それはプロジェクトのコストに跳ね返り、予算オーバーを招きます。

とどのつまり、プロジェクトは管理が出来ているか、管理が出来ていないかが、成功と失敗の分水嶺なのでしょう。