※この記事は、２０２２年５月に編集部で最新情報を踏まえて更新しました。
こんにちは、ライターのあだちです。以前コンサルティング会社で勤務していた頃「システム開発プロジェクト」の事例を数多く調査しました。
もちろん成功したプロジェクトも多数ありましたが、それよりはるかに多くのプロジェクトで失敗を経験していました。
企業IT動向調査報告書 2021 ユーザー企業のIT投資・活用の最新動向によると、500人以上の会社の場合、予定通りの工期で終わったプロジェクトは15.8％、予定通りの予算でおさまったが24.3％、品質に満足しているという回答は18.1％という結果がでています。
上記に該当しないプロジェクトの中には、訴訟に発展してしまうような「完全な失敗」は少ないものの、ユーザが「あそこにはもう頼みたくない」と言ったり、開発者が「あそことはもう仕事したくない」と言ったりするなど、結果としてどちらかが信用を落とし、不幸なことになったプロジェクトが多いことが予想できます。
では、なぜシステム開発プロジェクトは難しいのでしょう。原因を考えたとき、開発側の視点からは「要件が膨らんだ」「テストに十分な工数がとれなかった」「技術力不足だった」などがはっきりと思い当たるはずなのに、どうして同じ過ちが繰り返されるのか、首を傾げたくなりますね。
実はこの答えはとてもシンプルなのではないか、と私は思うのです。そこで今回は、過去に私が経験した「ECサイト構築」プロジェクトの事例を、主に発注者の視点から分析し、プロジェクトが失敗する原因と、その対策方法についてまとめます。
あるECサイト構築プロジェクトが失敗した経緯
発端はどこにでもあるような話でした。ある会社が社長のトップダウンで「ECサイトを構築したい」と言います。扱う商材はアパレルです。
開発費用には、およそ600万円の予算が用意されました。期間はおよそ6ヶ月間というのが発注側の希望です。
しかし、結局このプロジェクトは失敗しました。システムは何とか稼働したものの、中身にバグが多く、肝心の売上も予定の20％に満たない程度です。
どうしてこんなことになったのか、時系列で説明していきます。
1. 見積がバラつく
開発会社を選定するために、ECサイトの目的、扱う商品情報、想定される業務フロー、画面のイメージ、競合サイトの情報などをすべて文書化し、5社ほどの会社に見積もり依頼を出し、コンペを行いました。結果、見積の金額は最低300万円から最高2000万円ほどになりました。
困ったのは発注側のプロジェクトリーダーです。同じ情報を渡し、同じ時間を取ってヒアリングを受け、同じフォーマットで見積依頼を出したにも関わらず、これほど見積がバラつくとは想定していませんでした。中でも、一番困ったのが、見積書に入っている金額の根拠がわからない、ということでした。
プロジェクトリーダーは結局「SEの印象がよく、予算内で収まる会社」に決定し、発注金額は650万円となりました。
2. 要件定義書が読めない
さて、開発会社が決まったのはいいものの、早速、要件定義の段階で困ったことが起きました。プロジェクトリーダーには、開発側が出してくる「DB設計」や「画面遷移」などの資料がわからないのです。書いてあることは理解できても、「これで本当にECサイトが上手くいくのか？」という判断がつきません。
また、デザインなどが「イメージ図」からある程度わかっても、それが本当に良いものなのかどうかがわかりません。社長に聞いても「できたものじゃないと評価できない」と言われ、プロジェクトリーダーは困ってしまいました。仕方なく、開発側に「ある程度、形になっていないとデザインの良し悪しも判断できない」と告げ、簡単なモックアップを作ってもらうことにします。
3. デザインに修正指示が入る
開発側が持ってきたモックをみて、プロジェクトリーダーは「いいんじゃないか」と思ったものの、社長の意見は「No」でした。「では、どんな感じがいいですか？」とプロジェクトリーダーが聞くと、社長からは「もっと落ち着いた感じにしてくれ」と注文されました。
「うちのブランドイメージにあうデザインでないとダメだ」と言われ、プロジェクトリーダーは途方に暮れます。開発側もそれなりに自信を持っていたデザインを真っ向否定され、少し険悪なムードです。
結果として、いくつかのイメージ原案を開発会社が作成し、その中から社長に選択してもらうという運びになりました。すでにこの時点で2週間ほどプロジェクトが遅れています。更にデザイン案が作られるまでに1週間程度かかるということもあり、「早急にデザインを決める」ことで合意がありました。
4. サイトのコンテンツが決まらない
幸い原案の中から無事サイトのデザインが選択され、トップページの構成がほぼ固まりました。ところがここで次の問題が表面化します。「会社案内」「返品規定」など、サイトに載せるべきコンテンツの作成スピードが遅いのです。
案内の文言や、返品のフローなどの議論が社内でなかなかまとまりません。すでに遅れていたプロジェクトがさらに遅れ、1ヶ月程度の工数が追加で発生しています。また、タイミングが悪いことに、発注側の担当の1人が会社を辞めてしまい、プロジェクトリーダーの負荷が急増しました。
5. 管理画面についての打ち合わせ不足が露呈する
プロジェクトリーダーの苦労が実って、フロントエンドの画面は着々と進みはじめました。コンテンツもある程度揃ってきています。ようやくプロジェクトにスピード感が出てきた、と思われた矢先、システム開発会社から「管理画面のデザインはどうしますか？」と言われ、担当者は焦ります。もうサイトオープンの予定期日まで1ヶ月もないのに、具体的な計画がありません。
プロジェクトリーダーは苦肉の策として「必要な項目を伝えますから、それを配置した画面を作ってください」と開発側に伝えました。開発側もプロジェクトリーダーの苦労を察して「分かりました」と答えますが、これが後のトラブルを招きます。
6. 現場から予想外の要望が続出する
サイトオープン直前になり、開発サイドから上がってきた管理画面を実際にオペレートする人たちに触ってもらう、と社内の事務員に管理画面を試用してもらうと「ソート機能がない」「編集をどこのボタンでやるのかわかりづらい」「項目が多すぎてわかりにくい」など、次々と予想外の要望が続出しました。
開発側にプロジェクトリーダーが相談すると「全部は対応できない」とのこと。さらに、表画面のテスト期間も十分に取れないので、セキュリティ的な不安も払拭できない状態でした。個人情報を扱うのでそこは妥協できません。泣く泣く社長に進捗を説明すると、「なんでそんなに遅いんだ」と怒られました。社内外への告知はすでに済んでおり、プロジェクトリーダーの顔から笑顔が消えていきます。
7. サイトオープン
そして、サイトオープン当日、社内から悲鳴が上がります。「表示が崩れている」「編集機能が使えない」など、バグと思われる報告が数々ありました。なんとかオープンから1週間程度でバグは収束しましたが、今度は「サイトへの訪問者が全く増えていない」とプロジェクトリーダーが社長から責められます。
結局、これまでプロジェクトリーダーだった担当者はリーダーの役目を降ろされてしまい、代わりにマーケティング担当者がプロジェクトを仕切るようになりました。新リーダーの意見で、結局サイトの半分程度を「作り直し」して、半年後にリニューアルオープンするという決定が下りました。
失敗の原因は何だったのか
さて、この事例では、何が失敗の原因だったのでしょう？一部を除いて、システム開発プロジェクトでは、クライアントにはIT/Webにあまり詳しくない場合がほとんどです。
つまり、発注側はWebサイトを作ることにどれほど多くの時間がかかるか、あるいは変更にどれほどの手間がかかるか、ということは気にしません。あまり詳しくないのですから、これは当然です。
興味があるのはどうしても「このサイトを作ったら、売上が上がるか」「人が集まるか」に限定され、自分たちでコンテンツを作るのにも時間がかかり、デザインは納得行くまで作り直したい、と思うことでしょう。
したがって、このプロジェクトの根本的な問題は「納期が厳しかった」という他にありません。
発注側のプロジェクトリーダーは、「プロジェクト開始前に、これくらいのコンテンツ作成期間と意思決定期間を取らないと失敗しますよ、と教えてほしかった」と言います。一方、開発側は、後に「なぜ見積の時点で、半年では無理です」と言えなかったのだろう、と振り返ります。
開発をしたり、仕様を決めたりするのと同じくらい、「クライアントにも勉強してもらう」「クライアントがコンテンツのアイデアを出す」「クライアントが意思決定する」ことには時間がかかります。それらはすべて、開発側でのコントロールできない項目です。
今回のケースでは、そもそも発注側の事情を考慮しない見積であったことが、プロジェクトが失敗する原因だったと言えます。
プロジェクトを成功させるために
上記のような失敗原因への対策としては、まず、開発側が無理なことは無理だとはっきり言うことがあるでしょう。クライアントを不安にさせないためにリスクを開示しなかったり、優秀であるがゆえに「自分にはできる」と思い込んでいるケースや、そもそも開発側が頑張り過ぎというシチュエーションが多いように思われます。
無理なら無理と早く手を上げるほうが、結果的に開発側もクライアントもダメージを最小限に抑えられます。人・物・資金などのリソースを冷静に分析した上で、冷静にマイルストーンを切りましょう。
現実的にそれが不可能であれば、IT/Webにあまり詳しくない「発注側の動き方を変える」という発想が求められるでしょう。プロジェクト期間には進捗を確認するだけでなく、「そもそもなぜこのシステムが必要なのか？」「このシステムで何を実現させたいのか」などの目的を共有する打ち合わせも必要です。
ここで重要なのは、スケジュールを管理すること以上に、後で起こり得るシチュエーションにどう対応するかを明確にしておくことになります。このプロセスを事前に踏んでおくと、当事例のように「テストフェーズでプロジェクトの進捗が一気に悪化した」のような非常事態の発生を回避したり、「突然の機能追加や仕様変更依頼」についても、それが本当に必要なものなのかを発注側に問いかけやすくなるでしょう。
まとめ
システム開発の現場全体を見回しても「無理なことは無理と言う」「発注側の動き方を変える」ことが、プロジェクト成功の秘訣なのでは、と感じた次第です。それでは、また！
LIGはWebサイト制作を支援しています。ご興味のある方は事業ぺージをぜひご覧ください。
