作って終わりにならないシステム開発チーム (ウォーターフォール編)
これはEDOCODE Advent Calendar 2022、12月15日の記事です。
EDOCODEの田村です！
会社の中では、CEO兼Product Manager(プロダクトマネージャー)の役割で仕事をしています。
EDOCODEでは、2つの事業を展開しています。
クレジットカード会社を中心とする国内約20社の大規模会員組織に対するポイント還元サイトの運用・システム提供「ポイントモール」
WEBサイトからプッシュ通知を配信できるWEBプッシュ通知のSaaSサービス「PUSHCODE」
今回は、ステークホルダーも多く、ウォーターフォール型のシステム開発にならざる得ない「ポイントモール」事業の話です。
(ちなみに、「PUSHCODE」チームは、リーンXPという手法でプロダクト開発を行っています。)
課題と背景
EDOCODEが「ポイントモール」と読んでいるポイント還元サイトとは、そのサイトを経由してショッピングすることで、ポイントが還元されるお得なサービスです。
国内のクレジットカードは、カード会員がクレジットカードを利用して決済すると、0.5%〜1%程度のポイントを還元しています。
「ポイントモール」は、ポイントモールを経由して対象のオンラインショップで買い物することで、+0.5%〜+19%ほどのポイントを追加で獲得できます。
「ポイントモール」はステークホルダーが多いことやクレジットカード会社など大手企業のサービスになるため、メンテナンスの告知時期やセキュリティ診断、予算など様々な観点から、作るものを決めて、設計し、開発・テストを行い、決められたタイミングにリリースするという、ウォーターフォール型のシステム開発になります。
EDOCODEが過去にやっていたい開発フローでは、「先に作るものと決める」「決められたタイミングにリリースする」という納期優先だったため、以下のような状況でした。
エンジニアに伝えるのは、システム要件がメインだったため、「誰が使う機能で、どんな課題を解決したいのか」がわからない
「ちゃんと動くものをリリースすること」が重要だったため、「解決したい課題が解決できたか」計測していない
要するに作ったシステムが「解決したかった課題が解決できたのかわからない」&作るシステムに「興味を持てない」という状況でした。
取り組み概要
そんなEDOCODEでは、ウォーターフォールをアジャイル化しようとしたり、ユーザーリサーチ・ユーザビリティテストなどをたくさんやって機能自体の精度を磨いたりといろいろな取り組みをしましたが、ステークホルダーが多く、柔軟な変更ができなかったり、リサーチ結果を共有するための資料作りなどで逆に仕事が増えたりと、悪戦苦闘していました。
その過程で、どんなフローであっても必ずやったほうが良いと思う、シンプルな取り組みがあるのでまとめてみました。
ウォーターフォールからアジャイル、スクラム、XPなどへ移行させるような高度な話では全くありません。
チームで機能開発のことを考え、ディスカッションができるようになるキッカケが生まれるシンプルな取り組みです。
取り組み①：
機能開発の背景と解決したい課題を共有する
昔の開発フローの場合、作るものが決まったあとにディレクターがシステム要件+簡易的な仕様をエンジニアに共有して、詳細設計→開発という流れで開発が進んでいました。
このとき発生した問題としては、ディレクターがテストをする段階で、「なんでこんなシステムになってるの？」ということが発生していましたが、「システム要件に書かれてないから」という返答がエンジニアからありました。
良い悪いの次元を超えて、仲が悪くなりますよね。
それを改善するために行ったことが、開発チームに「背景」と「課題」をできるだけ詳しく伝えることです。
「ポイントモール」はユーザーがショップへ遷移し、ショッピングすることで、いつもよりも多くもポイントをGETすることができるWEBサービスです。
「ポイントモール」に初めて訪れたユーザーが、利用したいショップを見つけることができるような機能を追加する場合を例に、「背景」と「課題」を共有する大切さを説明します。
例①：システム要件のみ伝えられた場合
システム要件
検索バーにサジェスト機能を追加したい
例①のように開発したいシステム要件のみが伝えられて場合、要件に書いていることを開発することになります。
このような情報のみで開発することが日常になっているチームでは、この機能で誰かの課題を解決できるかもしれないというワクワク感を感じることは難しく、無駄なものを作っていたとしても気がつくことが難しいです。
もしこの機能を2ヶ月かけて開発したとして、誰も使わなかったら、このプロジェクトに関わったメンバーの2ヶ月間は無駄になります。
例②：システム要件のみ伝えられた場合
(実在する内容ではないので、適当な数字を入れています)
システム要件
検索バーにサジェスト機能を追加したい
背景
サービスを利用しているユーザーの85%はリピーターである。
新規ユーザーのアクセスは、既存ユーザーの2倍以上あるが、離脱率が75%以上。
課題
ユーザーリサーチの結果、新規ユーザーの離脱理由は、「利用したいショップが見つからない」ことだった。
例②のように開発したいシステム要件に加え、背景と課題が開発チームに伝えられたとします。
新規ユーザーの離脱理由が「利用したいショップが見つからない」だったとして、新規ユーザーは検索機能を利用しているのか？という疑問が湧きます。
また、新規ユーザーの直帰率は？滞在時間は？アクセスしているページは？など、Googleアナリティクスで簡単に調べることができるデータも知りたくなります。
もし、チームに背景と課題を共有することで、「検索バーにサジェスト機能を追加する」ことでは新規ユーザーの課題が解決できないことがわかったとします。
開発チームの2ヶ月分のリソースが無駄にならなかったことは、大きな成果です。
さらに誰のどんな課題を解決するための機能なのかエンジニアが知っていることで、要件漏れに気がついたり、レスポンス速度やセキュリティなどクリティカルな設計ミスを防ぐことにも効果的です。
課題を解決することのできる機能を発見することは、もちろん簡単ではありませんが、「背景」と「課題」をチームに共有することができただけでも、無駄を減らすことができます。
しかし、取り組み①だけでは、「決められた機能を作る」組織を変えることは難しのが現実です。
そのためには取り組み②を同時に行っていくことが必要です。
取り組み②：
「成功の基準」を設定し、必ずチームで振り返りを行う
この取り組みを行っていないチームでよく発生している問題は、「作りっぱなしの機能がたくさんある」という状況です。
この問題は、「成功の基準を決めていない」ために発生しています。
「成功の基準」=「計測可能な目標」を決めることが必要です。そして、成功・失敗を判断し、振り返りを行いましょう。
特に失敗したことを振り返ると、チームが行った行動や判断に対しての改善点が見えてきます。
改善点はたくさん出てくることが多いですが、すべてを一気に改善しようとしないでください。
重要かつ実現可能な改善点を1〜2つだけピックアップして改善することをおすすめします。
取り組み②を1〜2回行うことですぐに何かが変わるわけではありません。
チームの文化を変えるのは、時間がかかる作業です。
しかし、5回、6回と繰り返していくうちに改善も増え、どうやったら成功するのか？成功させたいと思うメンバーが増えてきます。
なぜなら、自分たちが作った機能がユーザーの課題を解決したほうが良いと思うほうが自然で、ウォーターフォールだと数ヶ月のプロジェクトになることも多く、数ヶ月かけて作った機能が誰にも使われてないことが喜ばしいはずがないからです。
「継続可能な目標」を設定し、「成功の基準」を明確にすることで、たとえ失敗しても、チームは大きな学びを得ることができます。
最後に「成功の基準」を設定するときポイントを説明します。
取り組み①で紹介した例のように、新規ユーザーが利用したいショップを見つけられる機能をリリースした場合、以下のような「計測可能な目標」が考えられます。
新規ユーザーのショップ遷移率：3%UP
新規ユーザーのアクセスが、10,000UUだった場合、機能を追加したことで300ユーザーが利用したいショップに遷移できるようになる計算です。
このときに特に注意するポイントとしては、以下の2点です。
「計測可能な目標」をボリュームで設定しないこと
Before Afterで比較しないこと
この2点に注意せず、目標設定してしまうと、正しく判断することが難しくなります。
新規ユーザーのショップ遷移UU：300ユーザー増加
外部要因などにより、単純に新規ユーザーのアクセスが増加した場合、ボリュームで目標設定していると、成功したことになってしまいます。
機能リリースの前週・前月・前年比で数値を計測
こちらも外部要因が強く影響します。比較する期間にキャンペーンをやっていて、新規ユーザーが多かったなどがあると、ノイズが大きくなるため比較できません。
またオンラインショッピングは季節や曜日にも大きな影響を受けるショップも多いため、同じタイミングで計測するためにもA/Bテストを実施しましょう。
まとめ
EDOCODEは、自分たちが時間をかけて一生懸命作ったシステムが無駄にならないように、開発方法の改善を常に行っています。
今回紹介した2つの取り組みは、決してレベルの高い話ではないと思いますが、「決められた期間内に決められたシステムを作る」ことが仕事になっていた数年前の状態が改善した取り組みの一つです。
「決められた期間内に決められたシステムを作る」ことが仕事になっているチームの方には、是非試してみてほしいです！
感想、フィードバックもお待ちしてます！
最後に
現在EDOCODEでは、エンジニア・デザイナー・プロダクトマネジャーを募集しています。ご興味のある方は、こちらの採用ページも是非ご覧ください！
この記事が気に入ったらサポートをしてみませんか？