「ITプロジェクトへのリスク予防への実践的アプローチ」の紹介

エンジニア TS
2021年06月07日

IPAが公開している「ITプロジェクトへのリスク予防への実践的アプローチ」というリスク予防のガイドラインを読んでみましたので、その内容を紹介します。

Contents

概要
ガイドの使い方
システム化の目的が明確でない
現行機能の調査・確認が不足している
性能の検討が十分でない
可用性の検討が十分でない
運用要件の検討が十分でない
要件を獲得すべきステークホルダーが網羅されていない
ユーザーによる仕様の確認が充分でない
要求の優先度が曖昧になっている
経営層のサポート不足
十分なコミュニケーションが取れていない
まとめ

概要

私は普段の開発では事前にリスクをリストアップしたり、リスク対策について考えるのですが、体系的なリスク管理プロセスは取れてなくて、感覚的、定性的なアプローチを取っています。もっと理論的な裏打ちを知りたいなと思ってこの資料を読んでみました。

ガイドラインの概要に書かれているガイドの目標をざっくり言うと以下のような内容です。

情報システム開発のリスク事象予防モデルを記述するテンプレートを作った。
テンプレートを使って委員の事例をまとめた。
事例を通して情報システム開発に関して問題が発生するメカニズム、実践され効果を上げている予防策を知ることができる。
ガイドを使ってユーザー企業、ベンダー企業間の対立の防止に役立ててほしい。

このガイドを読むことで情シス開発のリスクの考え方や事例を知ることができるということですね。

ガイドに挙げられた事例を見てると「あー、あるある」とうなずいてしまう情シスあるあるが多数載ってて共感できます。これ作った委員も「あるあるー」「だよねー」などとウンウン頷きあいながら事例を出し合ったに違いありません。

ガイドの使い方

ガイドを読んでみて思ったのですが、このガイドの使い方として、情報システム開発のリスクが体系的に網羅されているわけではない、とみなして利用すべきかなと思います。掲載されている事例は委員が遭遇した事例を挙げているという作り方をしているため、実際のプロジェクトではここに載っている以外のリスクが発生することもあるでしょうし、逆にガイドにリスクとして掲載されているが自身の開発プロジェクトでは対策の必要がないリスク事例もあるでしょう。そのためガイドに載っている予防策をすべて対策しようという使い方ではなく、自分たちの開発案件でリスク対策するときの、考え方を学ぶ資料として使うのが良いかと思います。

以下、ガイドに載ってる事例で個人的に面白かったものをピックアップしていきます。

システム化の目的が明確でない

システム化の目的が明確でない → 要件の増大、もしくは絞り込みの不全が発生し、プロジェクトが統制できなくなる。

予防策として以下の内容が挙げられています。

企画プロセスの結果に基づき、システム化の目的を具体的なレベルで文書化し、複数の目的がある場合は優先度を明確にする
各システム化目的の責任部署を明記
仕様が膨らんだ場合（コストや納期の超過が見込まれる）のエスカレーションルールと判断基準を定める

システムの目的を明文化した資料を作っておくことは大事だなーと思います。個人的にはビジネス目標を踏まえた言語化になるように気をつけています。また、システムの目的の文書は開発における最優先の文書と位置づけて、誰でもいつでも参照できる状態にしておき、また途中から参加した関係者には読み合わせるなど周知して、システムの目的が関係者全員の共通認識になるように気をつけてます。

現行機能の調査・確認が不足している

現行機能の調査・確認が不足している → 受け入れテスト時に不具合指摘が多発しプロジェクトの中断または大量の仕様変更が発生してコストが超過

このリスクの予防策に

「現行どおり」という記載はないか

というものがありました。これ、すごいわかります。

「今と同じ動きにする」という方針で作業してシステム化がうまくいかなかったことが実際にいくつもあります。

これがやっかいな点は、「現行通り」という方針で作業することの何が問題なのかプロジェクト関係者が理解できていないことが多いことです。「現行通り」はユーザー目線の言葉ですが、システム構築に必要な複雑さが削ぎ落ちてしまっているために、できあがったシステムは機能不足のシステムになってしまいがちです。「現行通り」というだけでは足りなくて、「現行通り」を達成するにはどういう仕様が必要かを十分に理解すること、言語化することが必要だと思います。

でもその言語化が必要な理由を理解してもらえなくて、「なんで細かい挙動まで定義しないといけないの？今と同じ動きをしてもらいたいだけだよ。」と言われてしまいがち。でもそのとおりにすると、結局後でみんな困ってしまうんだよなー。難しいなー。

性能の検討が十分でない

性能の検討が十分でない → 利用に供する性能が出ないため、稼働不能や大規模改修に繋がる

どのくらいの速度で動かないといけないのか事前に想定しておかないと、業務に耐えられないくらい処理時間のかかるシステムができあがってしまう危険があります。この点に関して自分でもそんなにうまく事前の性能予測ができているとは思わないんですけど、一応問題ないか事前に検証はしますね。

どの程度の性能を出さないといけないのかをまず決めて、
計算量が問題ないかを検証。DBのデータの持ち方やindexの張り方がボトルネックにならないようDB設計する。
アルゴリズムを設計/レビューする。

これくらいのことをやってる感じですが、体系的なアプローチではないので、これでいいのかなーと思いながらやってます。

可用性の検討が十分でない

可用性の検討が十分でない → 安定稼働の保証がないため、稼働不能や大規模改修に繋がる

可用性というのは稼働率のことですね。「障害が発生しない時間」「障害が発生してもシステムが停止しない時間」「障害発生でシステムが停止してしまったとき、どれくらい速く復旧できるか」で決まる指標です。

特にシステム停止時にどれくらいの時間で対応するかを事前に決めておかないとユーザーとのトラブルになってしまうため、認識合わせは重要だと感じます。

あとはシステム停止時に業務が止まることが許容できないシステムであれば、一時的にシステムを使わない代替業務手順を作っておくなどでもリスクを減らせますね。システムが無いときでも代替手順がとれる業務体制になっていると、自分たちに手出しできない障害発生時であってもダメージを抑えられるので、真に高可用な業務体制といえます。こういう手段が取れていると安心ですねー。

運用要件の検討が十分でない

運用要件の検討が十分でない → 実現できない、矛盾を含んだ要求仕様ができる

運用手順の相談ができてなくて、リリース時点になってから現場ユーザーから反発されてしまうのは私も経験あります。こうなってしまうと関係者全員が辛いんですよねー。

導入したシステムを使ってどう業務を進めるか決まってないというのは、導入のためのコストが無駄になってしまうリスクがあるということです。

低コストで導入を試せるのであれば、まず一度使ってみてから運用手順を考えるという手法もありですが、システム開発するのであれば、運用にフィットするかの検証は先にしておくべきだと思います。

要件を獲得すべきステークホルダーが網羅されていない

要件を獲得すべきステークホルダーが網羅されていない → 要件の漏れが発生する(後になってステークホルダーから指摘される)

システム部門による要件とりまとめが十分でない → 要件がいつまでも確定しない、あるいは要件が想定以上に膨らむ。

ステークホルダーからの聞き取りが不足すれば必要な機能が漏れてしまう危険があり、ステークホルダーの言うことを聞きすぎると要件がまとまらなくなってしまう、というジレンマがあります。ガイドではジレンマについての言及がありませんが、個人的にはこのジレンマこそがこの2つの問題の解決を難しくしている障害だと捉えています。

ジレンマを解消、軽減するために有効な方法としては、仕様決定の責任者を決めておき、ステークホルダーからの意見は十分聞き取りますが、どういう仕様にするかは仕様決定責任者に一任する、という手法はかなり有効なやりかただと感じています。

難点としては仕様決定責任者には大きな責任と判断能力が求められてしまうので難しい仕事になってしまいます。かといって責任者を複数に増やすと一貫しない意思決定が起こる危険があります。

ユーザーによる仕様の確認が充分でない

ユーザーによる仕様の確認が充分でない → 要件の漏れや認識の齟齬が生じる

ユーザーによる仕様確認はトラブルを避けるために重要だと感じます。これに関して考慮しないといけないことがいろいろとあって毎回悩んでます。↓以下のような点です。

仕様を確認する時間がない、と言われる
仕様確認に参加してないステークホルダーがいた
仕様を確認してもらったが理解が浅かったり勘違いして、動くものを見せたあとに仕様変更が発生する。
- 仕様に情報が不足していた
- ユーザーが理解しにくい仕様だった
- 動きがないと理解しにくい仕様だった
- 仕様読み合わせの機会を設けるべきだった
ユーザー自身にもあるべき仕様がわかっていない

ソフトウェアは形がないプロダクトなので、実際に完成したプログラムを確認するまでは、動きのイメージが難しいものです。そのために後になって仕様の不備が発覚してコストが膨らむリスクがあります。

事前に丁寧に仕様を説明しつつ、認識違いのありそうな機能を先に実装、早めに確認してもらうなど、リスクを小さくするよう気をつけてます。

要求の優先度が曖昧になっている

要求の優先度が曖昧になっている → 開発規模が膨張する

「全部の機能が必要なんだ」と言われてしまうケースですね。QCDのすべてを満たすことはできないので、どのくらいのコスト、期間がかかるか見積りを提示することで、スコープを減らしたり優先度を設定してもらうのが大事ですね。

経営層のサポート不足

経営層によるプロジェクト運営の関与が十分でない
経営層によるスコープ決定への関与が十分でない
経営層がパッケージ導入の意図・目的を明示していない

経営層のサポートが不足しているとビジネスに対して有効かどうかの視点が欠けてしまったり、メンバーのモチベーションが削がれる、とのこと。へー、そうかもしれないなと感じました。
経営層を説得して協力を取り付けるスキルを身につけたいですね。

十分なコミュニケーションが取れていない

十分なコミュニケーションが取れていない → 作業効率の悪化により工程の進捗が遅れる

コミュニケーションが取れてないために作業効率が悪化してしまうということもありますし、コミュニケーションに時間が取られすぎて、開発スタッフが十分に作業時間を確保できないということもあります。質の高い(コスパの良い)コミュニケーションを十分に取ることが重要ですが、コミュニケーションの質を高めるのは難しいことです。コミュニケーションの時間を取るだけでは質の高いコミュニケーションは達成できないので、時間をかければ良いというものでもありません。

メンバー間でどの程度のコミュニケーションをどういう手段でいつ取るか、そういうことを制御するコミュニケーションのデザインが必要だと思います。朝会やふりかえりを使って相談の機会を確保したり、ステークホルダーに直接相談できるチャネルを作ったり、といったことに気をつかってますね。

まとめ

「ITプロジェクトのリスク予防への実践的アプローチ」の内容を紹介しました。

普段の開発作業で遭遇する事例が数多く掲載されていて面白かったです。貴重な知見を無料で公開していただいてありがたいかぎりです。

自分でも気をつけている内容もありましたし、自分が気にしていなかった視点や予防策もありました。今回の記事では私が面白いと感じた内容を中心に紹介しましたが、私が気づかないことでも重要な視点はたくさんあるでしょう。誰か一人がすべてのリスクに気づくことは無理なので、複数の視点でリスク洗い出すこと、それを評価し、共通認識にするための仕組みづくりが重要だと思います。

リスクについての考え方や事例を知りたい方は、ぜひ「ITプロジェクトのリスク予防への実践的アプローチ」を読んでみてください。