LayerXのmichiru_daです。

2023年の10月から、担当しているバクラク 共通管理・認証基盤では認証方式の作り替えに着手しました。
開始して2ヶ月ほど仕様検討・設計・顧客ヒアリングを行いましたが、途中でプロジェクトをやめる意思決定をしました。

新規の機能追加ではなく既存のリニューアルに近いプロジェクトで、どう不確実性の検知や実行の判断を行っていくべきか、学びが多かったので振り返ります。

想定読者

専任でプロダクトマネジメントの仕事をはじめて半年で一番大きいプロジェクトではあったのですが、自分がハマると思っていなかった落とし穴がいくつかありました。

経験の浅いPMや、ジュニアPMの育成に取り組んでいるマネージャー、また既存機能のリニューアルに取り組まれているPMの方に読んでいただけますと幸いです。

プロジェクトをやると決めた背景

認証の作り替えをやろう、と決めたのは以下の理由からです。

• お客様の体験を落とさず、今よりもっとサービスの安全性を高められる

• 今のまま事業成長に伴う機能要望に対応すると、長期的に設計が複雑化、運用コストが高まる可能性がある

• 長期ロードマップを策定するなかで、集中して取り組める3ヶ月を確保できた

一方で、やる決定に至るまでにも多くの紆余曲折があり、特に難しかったポイントは以下です。

①潜在ユーザーや将来の事業へのアウトカムを見積りづらい
当たり前品質の認証・安全性に関することなので、顕在ユーザーの利便性が圧倒的に向上するわけではない感覚がありました。

「認証やシステム負荷につまづかず、当たり前に安心してサービスを利用できる」というプロダクトバリューを加味し、 作り替えを行う未来と行わない未来をシミュレーションしながら、やる意思決定を行いました。

②開発で考慮すべきパターンが多く、開発工数も見積りづらい
全ユーザーに使われている既存の認証方式すべてに対応が必要でしたが、これまで大きく手を入れたことはなく、全体感をわかっているメンバーがチームに居ない状態でした。

こちらは、エンジニアと対応箇所と不確実性の洗い出しを定期的に行い、都度プロジェクトの計画とスコープを見直しながら進めることにしました。

こちらの検討プロセスは、pmconf 2023でも一部発表しています。

進め方

実際のプロジェクトタイムラインは以下です。

全てのユーザーに使われる認証機能の変更だったので、 bigtechのリサーチや、当社サービスへの検討落とし込み検討は一定時間をかけて行っています。

また、できるだけプロジェクトが3ヶ月に収まるよう、開発機能を2つに分け、機能①の開発と、業務影響がある機能②の仕様検討・ヒアリングを並行して進めていきました。

作らない意思決定

全体で10社ほどのお客様に仕様のヒアリングを行ったのですが、結果として機能②はやらない決定をしました。

きっかけは、お客様の一言

ヒアリングしてみると、大きなNGを出した会社さんはいらっしゃいませんでしたが、あるお客様がぽろっと 「安全に使える選択肢が増えても、以前の方法で運用しちゃうかも（意訳）」という旨の発言をされていました。

フィードバックではなくふと漏らした言葉だったのですが、このコメントがどうもひっかかり、 「機能②は、作っても意図した通りに使われず、提供したい安全性向上というアウトカムに繋がらないのでは」という気づきにつながりました。

結論として、機能①は提供便益から予定どおりリリースするが、「機能②による安全性と運用性の向上」はやらない決定をしました。目指すより高い安全性については、今回のプロジェクトとは別で解決方法を検討する運びとなりました。

反省、学び

「想定している仕様では課題解決できない」に早く気づくべきだった、というのが今回の大きな反省点です。

「早くお客様とお話できたほうがよい」は頭ではわかっていたものの、実行できなかった背景としては以下があります。

1.全てが準備できてからヒアリングしたいと思ってしまった

「ユーザーが不要であれば使わない」という選択ができない機能だったことから、仕様の穴をなくしてからヒアリングしたいと思っていました。
今より体験を一つも落とせないという思いから、最初から体験パターン・あるべき姿を細かく考えてしまい、 またセキュリティに詳しい社員からのレビューやディスカッションする期間も設けていたので、 お客様とお話するまでに時間がかかってしまっていました。

次回につながる学びとしては、「業務にフィットするか不確実と思う仕様」にもグラデーションをつけ、 不確実なところから優先して早くからヒアリングするという判断をすべきでした。

2.期限までに実装が終わる見込みがほしかった

後続のロードマップを鑑みて、3ヶ月で一定の結果が出せるようにスコープを定めたプロジェクトだったこともあり、 スケジュールの遅延リスクを下げたいと思っていたことも要因です。

認証領域の全体感をわかっている人がいなかったので、実現性や見積りを行うための調査・検討にも一定リソースがかかる状態で、期限に間に合わせるためには検討より早いタイミングで着手が必要な状況でもありました。

タイムラインを検討する際に、チーム全体でフォーカスするのはいつまでか決める/細く長く続ける選択肢も含めて計画する、ができれば異なる進め方があったと思います。

3.まさか、Problem Solution Fit しないと思っていなかった

また、正直「体験と安全性が両立する仕様を考えられれば、作らないことはないだろう」と思ってしまっていました。

いわゆる業務フローそのものと離れた認証領域なので、悪くない体験が設計できればNGはないのでは？というバイアスがあったせいです。

実態としては、意図した通りには使われないという罠があったので、機能の良し悪しだけではなく、想定するアウトカムが達成可能か？という観点でお客様とお話すべきでした。

「やらない」意思決定により得たアウトカム

一方で、チームでぶち上げた大規模リニューアルを、1ヶ月半取り組んだタイミングで撤退を決められたのはポジティブだったなと思います。
実際3つのアウトカムが生まれました。

なぜ「使われないものを作らない」決定をできたか

また、自分がなぜ「やめる」を決められたのか振り返ったのですが、言い過ぎではなく「LayerXのPMチームにいたから」だと思います。

口酸っぱく説かれる「使われないものを作らない」

弊社には「使われないものを作らない」というカルチャーがあります。

CPOの榎本のスライドにも記載されていますが、「作ったものは必ず負債になり、作るほど後の”開発速度を落とす”」という前提共有や、「作るなら、作るに値するものを作る」推奨が徹底的に行われています。

週に1度、開発した機能をデモするレビュー会と、そのあとにPMやデザイナーでフィードバックしあう会があるのですが、そこでも「これって本当に使われるのかな？」「言われた通りに作ってないかな」という会話が当たり前のようになされます。

自分がLayerXで仕事をしていなければ、「時間をかけて検討したし、色んな人の力も借りたし、やり遂げないと・・・！」と社内を向いて意思決定していたかもしれません。

LayerXの「使われないものを作らない」を耳にタコができるくらい見聞きしていたおかげで、ヒアリングでの一言に違和感を感じとり、ユーザーさんを向いた判断をすることができたな、と思います。

まずはお客様の声を聞くこと

同時に、LayerXではお客様・ユーザーさんの声を聞くことも当たり前のアクションとして推奨されています。

新規プロダクト立ち上げの際はもちろんですし、既存プロダクトの機能改善・開発を行う時も、LayerXのPMチームでは息を吸うようにヒアリングを行っています。

社内では「裏のニーズ」といわれていますが、直接お話することで、お客様が要望をあげた背景や本当のお困りごとを一緒に明らかにしていくことができます。

今回も、弊社で当たり前のように行われているヒアリングを一定数自分で行うことで、今回の意思決定のきっかけを得ることができたと考えています。

キックオフ時に、チームでも大切にしたいことをすり合わせておいた

また、今回はチームのエンジニアメンバーにもかなり設計・調査周りを一緒にやっていた背景があるので、「こんなに手伝ってもらったのに止めて良いのか」や、「メンバーがやめたくないと言った時に説得できるか」などの不安がありました。

しかし、実際にはプロジェクトのキックオフでこのプロジェクトで大事にしたいこと、やる/やらないリストを事前にメンバーで 話し合っておいたので、リストと照らし合わせ、「徹底的に体験にこだわれない」「そもそも今回の手段だと、想定していた提供価値がデリバリーできないので、やめたい」という話を前向きに行うことができました。

おわりに

以上、「一度やると決めたけど、やっぱりやらないことにした認証基盤作り替えプロジェクト」について、そのもののアウトカムや学びを記載しました。

長期のアウトカムはあった、と書いていますが、実際短期的には調査兵団状態です。

悔しすぎるので、今度はちゃんと使われるものを作りたいです。