プロジェクト炎上の火種「漏れ」の原因と対策について
見出し画像

プロジェクト炎上の火種「漏れ」の原因と対策について

システム開発プロジェクトにおける「炎上」とは、計画から大きく遅延している、要件実現度や品質基準が目標に遠く及ばない、予算が大幅に超過している、このような状況のことを指します。SNS界隈で「炎上」というキーワードが流行るよりはるか昔から「炎上」してきたシステム開発プロジェクトは、今でもいたるところで発生しています。この炎上の原因でよくあるのが、「漏れ」という理由です。「なんで漏れてしまったのか?」と発覚したタイミングで問い詰めても時を戻すことはできません。炎上するプロジェクトは、「漏れ」の連続で、もぐら叩きを永遠にやり続けることは、さすがに疲れます。
今回は、炎上原因の一つである「漏れ」に注目して、その発生原因と漏れないための対策について解説します。

■かんたんイラスト(記事を読む時間のない人へ)

画像1

画像2

1.炎上の火種となる「漏れ」とは

メールの返信忘れや経費の付け漏れなど漏れにも様々ありますが、システム開発における重大な漏れは、「機能」と「工程」の2つです。作るべき機能がごっそり抜け落ちていた「機能」の漏れ、必要な工程が行われずに進んでいった「工程」の漏れ。例えば、ボリューム調整機能のないラジオ、1週間使ったら壊れてしまう耐久性検査が不十分な車など、製品として考えた場合には、必要な機能や検査工程が漏れていたら、不良品となってしまいます。システム開発でも同様に、機能や工程に漏れが発覚したシステムは良品として合格出来ないため、計画変更を余儀なくされることは言うまでもありません。一つ漏れていたら、大抵の場合、他にも漏れが潜んでいます。漏れが次々と発覚する状況になれば、炎上プロジェクトのレッテルを貼られることは時間の問題です。

2.漏れが発生する理由

なぜ、漏れが発生してしまうのでしょうか。そもそも炎上するようなプロジェクトは、スケジュールがタイトだったり、仕様が詰め切れていない状態で開発に入って刺身状態で進めていたりします。刺身のスケジュールは、システム開発では良く使われる言葉で、スーパーで売られている刺身が少し重なっている様子から、タスクとタスクを少し重ねて進めることです。刺身のスケジュールは、次工程への影響を完全に出しきれずに進めてしまうため、重大な漏れを引き起こす可能性が高いです。
ですが、漏れの原因は、刺身スケジュール以外にもあります。これまでに経験した漏れの発生理由を3つご紹介します。

① 最初から漏れている
一部の「機能」が設計段階から漏れていた。
システム全体を把握しておくべきプロジェクトマネージャーが全体像を把握しきれていないことが原因のひとつです。全体像を把握するドキュメントがない、ドキュメントはあるが陳腐化している、あるいは正しくない、描かれた全体像からそもそも漏れている、といったことが理由です。
この機能の漏れは、実行計画や全体設計の時点では誰も漏れていることを認識できていない可能性が高いです。
システム開発プロジェクトは、工程が進んでいくと、作業単位がどんどん細かくなっていきます。設計工程以降は機能単位で進めていくため、一つの機能を担当しているエンジニアは、その機能の事はわかるものの全体の漏れはわかりません。そのため、開発が終わり、機能間の結合試験をする段階ではじめて漏れに気が付くのです。
家を作る時に、設計段階でトイレがなければ気が付きそうなものですが、実際には、このような漏れも起こります。最初が肝心とは良く言いますが、システム開発でもその通りで、機能に分解されてしまった後で漏れに気が付くことは困難です。上流工程が大事と言われるのは、仕切りの問題だけでなく、システム全体を把握したうえで、もれなく機能が抽出できているかという点でもとても重要です。

② 必要性を感じなかった
機能に漏れはなかったけれど一部の「工程」が漏れていた。
例えば、機能は開発してテストもやっているが、性能面の検証が漏れてしまった。あるいは、テストデータを使った検証は実施したが、実データ使ったテストが漏れてしまったなどです。
この工程の漏れは、総合テストやユーザーテスト、場合によっては試運転などプロジェクトの終盤で発見されることが多く、機能の漏れよりも発見が遅くなりがちなため、どちらかというとクリティカル度はこちらの方が高いです。
工程の漏れが起こる理由は、そのようなテスト工程は知ってはいたが、必要と思わなかったことに尽きます。あるいはスケジュールや予算の都合上、意図的に省くこともありますが、結果として不良となってしまえば、漏れと言われても仕方ありません。システム開発におけるテストは実際に使われる状況を模して行うことが基本的な考え方であるものの、「そこまでやる必要があるか?」「普通はやりません」などといったシステム開発における常識が邪魔をして、テスト工程が漏れてしまう場合があります。予算も納期も余裕があれば、全ての機能について、あらゆるテスト種類を実施すれば良いですが、同じようなテストを繰り返し実施しては非効率なので、必要なテストに絞り込んで進めていくのが普通です。この普通という言葉によって、必要性を感じることができずに漏れが発生してしまうことがあります。

③ 出来ないと思っていた
「工程」の漏れが発生するもう一つの原因が、環境などの制約から実施できないという思い込みです。例えば、別のシステムと接続する機能を作っていたとしても、相手のシステムにテストする環境がないため、勝手にテストが出来ないと思っていたなどです。相手のシステム担当者と、制約を取り除いた思考で十分に話が出来ていれば、本番環境を使っていないダウンタイムやシステム保守のタイミングなどでテストデータを使って出来ることもあります。仮にテストが出来なかったとしても、リスクとして管理して、クライアントやマネジメントと共有しておくことは当然です。

3.漏れをなくす対策

システム開発のプロジェクトマネージャーには、論理的思考が必須です。論理的思考のベースとなるのは構造化です。機能も工程も分解したひとつの要素にすぎません。システム全体を「機能」という要素に分解する時、完成までのスケジュールを「工程」という要素に分解する時、そのタイミングで漏れに気が付けるかにかかっています。そのために、システム全体の責任を持ち、ゴールまでの道筋を付けるプロジェクトマネージャーに構造化するスキルは必須です。
・「機能」の漏れ対策
「機能」の漏れを起こさないためには、システム全体の把握が必須となります。特に大規模なシステムでは、幾つものサブシステムをつなぎ合わせ、また複数の関連システムと接続して構成されます。システムを利用するプレイヤーの種類や利用デバイスも多くなります。これらの要素(サブシステム、関連システム、プレイヤー、デバイスなど)を網羅してシステム全体像を整備することが何よりも大切です。このプレイヤーが使う機能は何で、どのデバイスを利用して、関連システムとはどのような情報をやり取りするかなど、システム全体像と機能一覧を照らし合わせることで漏れの確認はある程度できます。システム全体像はプロジェクトマネージャーが作成すべきドキュメントで、システム全体像を美しく描けないプロジェクトマネージャーは、そのポジションを担ってはいけないとさえ思います。システム全体像の精度を高めるためには、クライアントや有識者など多くの目で見て、原始的ではあっても、二重三重にチェックを行うことが必要です。何人かで見れば、家にトイレがないことには気が付くはずです。
少し話が飛躍しますが、このシステム全体像は、システムの完成図として必要不可欠なドキュメントであり、システム全体図がないプロジェクトは、既に炎上に向かっていると言っても過言ではありません。
・「工程」の漏れ対策
「工程」の漏れを防ぐ方法は、2つあります。
ひとつは、機能の種類(画面、IF、バッチ、帳票、管理機能など)毎にテスト観点との対比表を作って、今回のシステムでは、各機能種類に対して、どのようなテストが必要かを常識を取り払った目線で確認していく方法です。
もう一つの方法が、システムの特性を考慮して、テスト観点を抽出することです。一言にシステム開発と言っても様々あり、担う役割も違います。
例えば、会計システムであれば、数字の確からしさが最重要です。単にインプットできて集計機能が動作するだけではなく、値の正しさを確認するために、本番データを使った全件データ検証や、現行システムリプレースであれば、現行システムの値と突合する現新一致試験などのテスト工程も必要になります。
他にも、大規模なECサイトであれば、決済漏れや課金ミス、支払い漏れなど、お金の流れが重要なので、流れをいくつかに分断して、その各断面でお金の整合性を確認するテスト観点が必要です。
他にも、ライバルが乱立しているコンシューマー向けサイトでは、画面の応答速度が重要なため、いかにハイレスポンスな仕組みを作るかの検討が要件定義や設計時の重要なタスクとなります。加えて、性能検証もシステムが出来上がったプロジェクト後半に実施するのではなく、機能の単体テストが終わった時点で単体性能検証の工程を置くことも必要です。
このように、開発するシステムの何が肝かを理解したうえで、システムの特性を考慮した「工程」を洗い出すことが大切です。

4.まとめ

システム開発における「機能」と「工程」の漏れは、プロジェクトの炎上を引き起こす可能性が極めて高いです。漏れを出さないためには、システム開発の知識と経験に加えて構造化するスキルも必要となるため、プロジェクトマネージャーの力量が問われるところです。鏡となるテンプレートやフレームワークに頼ることも良いですが、システムの特性を考慮した工程を洗い出すには、結局は、多くの人の目を通して確認すること、そして、それをクライアントやマネジメントと合意することが大切だと思います。

この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!
システム開発のプロジェクトマネージャー専門会社 株式会社ARAKADO 代表取締役 柴田 秀夫 https://arakado.co.jp