こんにちは、新幹線降りる時によく座席戻すのを忘れるPMのKaihoです。今回はまた、名前の通りプロジェクトがバッドエンドに終わったケースを紹介します。ゆめみという会社で仕事をするからと言って、良い事ばかりでもないよ、と思ってもらえれば。

概要

　とあるプロジェクトにて、無事リリースまでできたのですが、その後いくつかの要因によりベンダースイッチされてしまいました。経緯こちら

（2017/春）PMと企画、デザイナーが一丸となって受注できた
（2017/夏）設計したものの中、一部要件定義しきれなかった部分が残った（2017/秋〜冬）死に物狂いで開発、幸い死亡事故とはならず　　　　（2018/冬） 結合テスト 　１週間延期
（2018/春） 公開先を限定してリリース
（2018/秋） 正式リリース
（2018/冬） 顧客から別ベンダーに切り替えると連絡があり、死亡（心が）

原因１：細かいレベルでのアプリの品質が低かった

　具体的には、デザイン上の不自然や、誤字・表記ゆれ等(例：「買う」「かう」）が頻発し、よく言われる「神は細部に宿る」の逆が発生してました。その理由として、テスト・チェック・レビューが限られたメンバーで行われており、第三者による客観的・中立的な視点が入れられなかったためです。

原因２：使いづらい機能をリリースしてしまった

　検索機能が使いづらい、画像一覧の表示順が意図通りではない等、仕様通りに実装したものの、明らかに使いづらい機能となってしまっていたケースがありました。UX/UIの観点からのレビューが不足していました。

原因３：抜本的な対策に取り組めなかった

　ここまで説明してきた品質や機能の低下には気づいていたにも関わらず、追加開発のリリース頻度、パートナーさんと開発していた事から、体制やプロセスを変える根本的な解決を試みる事ができなかった点も挙げられます。

原因４：プロフェッショナルとしての信頼を得られなかった

　原因１、２でによりお客様の信頼は低下、さらに原因３で記したように有効な対策も打てなかったため、お客様との関係もギクシャクしてしまいました。この結果、信頼を得て長期的な展開を共有しながらサービスを成長させる期待に応えられませんでした。お客様からの指示だけ待つ「受託意識」に陥ってしまいました。

原因５：長時間のサービスダウンを発生させてしまった

　５番目に挙げつつ、ほぼトドメなんですが、まあ発生させてしまいました。（詳細は割愛）

原因６：メンバーの入れ替えに関する説明が不充分

　１年近くのプロジェクトとなり、メンバー交代が発生したのですが、ちゃんと理由・経緯が説明できなかった。特にお客様からすれば自分は一番だと思うので、この点ちゃんと安心させなければいけなかったです。「医者にとって患者は沢山いるけど、患者にとって医者は一人しかない」と言う言葉を思い出しました。

原因７：高い（金額が）と思われた

　難しく言うと「期待値と実績と金額のバランス」に失敗した、と言う事ですが。これについてはミクロ経済学とか持ち出して難しく語るまでもなく、受託開発で発生する永遠のテーマなのですが、バッドエンドの要因としては大きいのではないかと。

もしセーブデータからやり直せるなら

　ここまで記した原因に対し、個別の対策を考えましたが、要は一言で言うとこう言うことかな、と。

PMや限られたメンバーだけで進めるのではなく、広く社内のノウハウ（品質、UX/UI、管理など）を統合し、会社としてプロジェクトを進め、（高額でも）顧客が安心・信頼できるように進める

　「口で言うのは簡単だけどな」と思いますが、書いてみて思ったのは、以前投稿した記事である「ゆめみにおけるPMとは」と表裏にあります。

　この記事で、ゆめみにおけるPMの範囲は上流から下流工程まで幅広いと主張しました。しかし、これだけ広い範囲をカバーしている（しかも期限がある）と、どうしてもそれぞれの工程において、いわゆる「独りよがり」になってしまいます（自分一人の裁量で進めたほうが早い）。ところがその結果、ここに書かれているようなバッドエンドのルートに入ってしまうリスクがあります。

　なので、ゆめみでのPMは各プロセスで（優れた）メンバーの力を統合・結集してグッドエンディングを迎えましょう！みんな、仲ようせんとあかんよ。という事で（その自戒を込めて）この記事を書かせていただきました。

（ちょっとエモくなりましたが）気になる事などあればお気軽にフィードバックください！