なぜプロジェクトが炎上してしまうのか

SHIFTでは、以下のような状況に陥り、プロジェクトが予定通りに進まない状態を「炎上」と定義しています。これは、ソフトウェア開発における生産管理や業務改善の枠組みである「QCD」にのっとったものです。

・スケジュールの遅延
・メンバーの高負荷稼働
・不具合が収束しない　など

櫻井：現在のITプロジェクトの成功率は3割程度で、以前よりは炎上しなくなったというデータもあります。しかし私としては、システムの複雑化や外部連携先の増加により、より規模の大きな炎上が増えている印象です。

そもそも、なぜプロジェクトは炎上するのでしょうか。主な理由として、下記が考えられます。

・要件が不明確である
・役割が不明確である
・スケジュールや進め方に関して、見積もりが甘い
・知識、スキルが足りない
・テストが不十分である

こうした背景で発生してしまった炎上案件に対して、SHIFTはどのように対応してきたのでしょうか。

事例1：「品質に問題があり、リリースが大幅に遅延中」の案件

内藤が品質PMOとして参画したあるプロジェクトでは、あるシステム開発をベンダーに依頼していたものの品質に懸念があり、リリースが半年あるいはそれ以上遅れることが見込まれていました。

内藤：我々の役割は、網羅的なテスト項目を作成して品質を担保すること。加えてプロジェクトの管理体制を強化し、リリースの遅延を半年以内に収められるかどうか判断することでした。

内藤が参画して1週間がたったころ、詳細設計工程が予定通りに進んでおらず、レビューや修正の回数が増えるなど事態の収束が見込めないことが判明。

また、進捗報告の内容が定性的なタスク完了に偏っており、報告回数が少ないといったこともわかりました。

そこで、SHIFTは大きくわけて3つの活動をしました。

1、標準テスト観点から、各種ドキュメントを見直し

SHIFTはテスト計画書やテスト方針書の作成に加えて、標準テスト観点から既存の各種ドキュメントの見直しも行いました。

具体的には、SHIFTクオリティフレームワーク（通称：SQF）を適用しました。

これはソフトウェアテストの国際規格「ISTQB」と、SHIFTが手がける年間4,000件もの品質保証実績によるナレッジをまとめてつくり上げた、SHIFT独自のフレームワークです。

SQFに含まれている900以上の標準テスト観点から、そもそものシステム設計に漏れが多発していることが判明しました。

2、レビュー内容の分析・横展開

要件定義や基本設計、詳細設計といった設計の各プロセスで発生していた設計漏れ。これらの原因を追究したところ、一番大元の原因と私たちが捉えたのが、定義した要件を基本設計へ落とし込めていない、という点でした。

また、類似する指摘が複数のドキュメントに見受けられたことから、各ドキュメントのレビューはできていたけれど、その分析や他フェーズへ横展開での改善ができていなかったと判明しました。

内藤：今回は我々の参画タイミングが後ろだったこともあり、全行程の指摘事項をまとめて分類し、お客様と原因について協議していきました。

本来であれば、プロジェクトの工程ごとにレビュー内容を一覧化・分類しながら進めていくとよいと思います。

3、プロジェクトマネジメント支援

PMOとして対応するのは、ドキュメントレビューだけではありません。ベンダーからも開発状況に応じて課題が報告されるので、課題の優先順位づけやドキュメントの変更管理が非常に重要です。

課題管理や変更管理についてはルールが整備されていなかったので迅速に対応。プロジェクトの進捗管理も支援しました。

内藤：品質面での課題も把握したうえでの進捗管理になりましたが、優先順位づけを誤らないよう慎重に進めました。

ブラックボックス化しがちなベンダーの開発状況については、より解像度の高い状態で可視化するマネジメントを行いました。

ここまでの支援を通じて、本プロジェクトはドキュメントの質が向上し詳細設計工程で発生していた課題が無事に収束。そして定量的な進捗報告を実現し、リリースまでの予定をしっかり立てることができました。

事例2：「受入テストの段階まで、お客様が炎上に気づいていなかった」案件

2つ目の事例は、基幹システムのリニューアルプロジェクトの支援です。これまでお客様はシステムを熟知しているSIerに開発を依頼していましたが、このプロジェクトではじめてグループ子会社にリニューアルを依頼しました。

しかし、グループ子会社はシステムを熟知しておらず、受入テストを外部に依頼する必要が出てきたのです。

長友：相談をいただいた時点では、受け入れのシナリオテストを作成する案件だろうと思っていました。

ところが実際にヒアリングしてみると、詳細設計工程の完了間際にも関わらず要件が決まっていないと、ビジネス部門も開発部門も口を揃えます。一抹の不安を抱きました。

画面数は不明、機能の一覧化は一部完了しているなど曖昧な状況です。WBS（Work Breakdown Structure：作業分解構成図）が存在しないので、プロジェクトの進捗状況を把握する術もありません。

マスタースケジュールはPowerPointで作成されていましたが、同ファイルに遅延状況の記載はなく、ただ「オンスケ」と記載されていたのです。長友は「非常にまずい」という感覚を抱きつつ、支援を開始しました。

具体的には「プロダクト品質」と「プロセス品質」という2つの観点から支援したといいます。

1、プロダクト品質

プロダクト品質を担保するために実施したことが以下です。

まずは、仕様書の完成度などを把握するためにインスペクションを実行。

具体的には上流工程でつくったドキュメントについて、定義した要件を基本設計に落とし込めているか、抜け漏れはないか、不整合や矛盾はないかなどを調査しました。

インスペクションを60ページほど進めたところ、膨大な数の指摘が上がっていたのでお客様にご報告したところ、「全ページをインスペクションしてください」とご依頼いただきました。

幸いテスト設計のために人的リソースは準備していたので、インスペクションのスペシャリストを追加で投入し、全員で一斉にとりかかりました。

その結果、すべてのドキュメントのうち約半分に修正が必要なことがわかったのです。

長友：本来であればインスペクションが終わったらテスト設計にとりかかる予定でしたが、指摘事項が多すぎてベンダーは修正に対応しきれない状態でした。

そのためSHIFTは基本設計書と詳細設計書の修正完了を待たずにテストを設計する必要があります。そこで、基幹システムを利用するお客様のビジネス部門に直接ヒアリングしてテスト設計書をつくりました。

加えて利用マニュアルを作成し、ビジネス部門に確認してもらいました。

もちろん、このタイミングで利用マニュアルをつくっても、基幹システムが完成したときには修正が入ります。

しかし利用マニュアルをつくることで、ビジネス部門に対してすべての要件が確定しているか確認することもできると考えたのです。

そして、テスト設計の完了間際にはBacklogをカスタマイズし、テスト実行でみつかった不具合を管理しやすい状態を整えました。

加えて、誰がいまどの不具合に対応しているかを互いに共有できるよう、対応を開始した時点でSlackにメッセージが自動的に飛ぶ仕組みを導入。

これによって、複数のメンバーが同じ不具合に対応してしまうことを防げます。

最後に、不具合の検知件数と改修件数を数値化し、日次の夕会時にて共有するようにしました。

日々増えていく不具合に対応する際、報告のタイミングによっては状況が変わっていることがあります。現状を把握するために、リアルタイムでの数値化と共有に取り組みました。

2、プロセス品質

SHIFTはプロセス品質を担保するために、さまざまな取り組みを実施しました。

まず、プロジェクトの進捗状況と課題のグラフ化。これはステークホルダーにドキッとしてもらうためです。グラフ化することで状況をリアルに感じやすくなります。

次に、現実的なマスタースケジュールを図示しました。プロジェクトの現状を考慮してローンチできる具体的なタイミングを、ステークホルダーに突きつけたのです。

これはプロジェクトマネジメントにおいて重要な「ステークホルダーマネジメント」の一環といえます。

なおこの場合のステークホルダーとは、お客様の役員陣です。SHIFTに依頼したのは本部長クラスですが、エスカレーションの過程では報告が端折られてしまいがちです。

役員陣に現実を知ってもらうためには必要な工程でしたし、役員陣のSHIFTに対する信頼を高めることもできました。

長友：さらに、責任の所在を明確化するための体制図を作成しました。

この人は何をする人なのか、どのような役割を担うのかなどを書いていったところ、ある機能やインフラなど特定の領域のリーダーが欠けていることがわかりました。

そして、SHIFTはタスクごとにゴール（成果物）を定義しました。プログラムは書いたら終わりではありません。その後にテストを実行し、質の担保された成果物を提出するのがゴールだと説明し、お客様に実行してもらいました。

また、前述の通りWBSがない状態だったため、各リーダーにWBSの書き方をレクチャーしてSHIFTが定義したステータスにのっとった進捗報告を行ってもらいました。

最後に、プロセス品質でも開発の進捗状況を日次で報告することをルール化しました。

内容が不明瞭だったり矛盾があったりする報告はありましたが、品質向上のためにそれを細かく指摘して、その日のうちに確認をとることをルール化しました。

品質を意識したプロジェクトマネジメントは上流工程からはじまっている

ビジネス部門やステークホルダーなどを巻き込む際のコツは、プロダクトの品質向上を目的とした活動であることを理解してもらうことです。

長友：巻き込みの際には開発側やビジネス側、企画側など、さまざまなステークホルダーに対して『SHIFTはこのシステムの品質を向上させたい』と訴えています。

品質を向上させる自負があるからこそ、わからないことを聞きにきているのだとステークホルダーに理解してもらうのです。

そもそもプロジェクトを炎上させないためには、「管理」「テスト」「ノウハウ」の3つの品質軸を意識する必要があります。

櫻井：PMのみなさんは、一つ一つの工程の進捗状況やドキュメントなどはきちんと確認していることでしょう。しかしプロダクトやプロセスの品質に目を向けてマネジメントをしている方は案外少ないように感じます。

品質向上には、テストそのものだけではなくよりよいテストをするための「準備」が必要です。テスト観点の網羅された機能設計、詳細設計になっているか。ドキュメントの段階で機能の整合性はとれているのか。

テストに依存するのではなく、上流工程で品質を担保することが非常に重要だと我々は考えています。

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです）