改善による疲弊をコンセプトという拠り所によって回避したいこの広告は、90日以上更新していないブログに表示しています。webサービスの改善として「機能追加」をするのは施策としてまあ普通にある事でそれに対しては特に何も思わないのだけど、今日社内のslackで開発チームがこのツイートにリアクションしてたのを見てこの「機能追加」の捉え方をどうすれば共通の認識、もしくはコンセプトまで持っていけるかなーとかぼんやり考えてた。僕の場合は内製でやっているため、プロダクトオーナーは社内の事業責任者であったりプロデューサーだったりするのだけど、開発チームとの物理的ではない距離を感じるケースを過去何度も見て来た。それは恐らく僕自身も距離を感じてしまった場合もある。プロデューサーという立場で言えば、数字に対しての責任はあるにせよ、本来、サービスをプロデュースする事が責任であるため、数字だけではなくどうあるべきかという理想の姿、もっと言えば夢を持っていなくてはいけない。それなのにKPIの改善のために安易な機能追加をしてしまう背景には、既存機能の改善や機能削除によるKPIとの相関が見えていないパターンがほとんどなんじゃないかと思っている。足し算は比較的未来予測がしやすい。機能追加により、例えばユーザーの投稿数が伸びたり、アクティブユーザーが増えたり、など分かりやすい所がある。それはあくまでその機能単体で見た場合だ。全体を通して見た時に追加した事によるデメリットまで見えていない場合がある。経験則であるが、実際に僕も似たような事はやった事がある。実際、足下の数字が伸びる事はあるのだけど、もう少し長い目で見た時に出るマイナスにまで頭が追いついていない。既存機能と新規機能を掛け合わせてどうなのか、機能の削除による効果、つまる所マイナスからのプラスへの転換の可能性、そこまで考えらていない時は安易に機能を追加してしまいがちである。苦労してリリースした機能がユーザーに望まれなかった場合、その機能に何が足りなかったという事を考え、ますますゴテゴテとした機能が追加されていく。時を経て負債と成り下がった悲しみ(機能)はそっと息を引き取る、サービスの想定改善率と共に。人間は悲しみを往々にして繰り返していくものだ。それでも同じ悲しみを味わいたくないと思うのもまた人間だ。こんな時、チームとして、組織として必要な物というのはやはり「コンセプト」という言葉、共通の言語だと思っている。不要な物は削除するという考え方は大前提として。これは別にプロデューサーが定義しなくてもいい、ディレクターだって、エンジニアだって、いや、そもそもがチームに浸透するレベルで関わる人間が集まって定義するのが一番良いと思っている。そのためにエレベーターピッチでもストーリーテリングでもどんな方法を使っても良いと思うが、大事なのはコンセプトの浸透である。何かプロジェクトが暴走しそうになった時、パッと振り返られる物があるといい。寄り添える物とも言える。コンセプトはプロダクトの方向性を示し、そしてコンセプトを元にチームは出来上がっていく。極端な話をすればここがしっかりしていれば多少の事では動じないチームが出来ると思っている。文化を根付かせるには体力も精神力もいる。言えばとても地味な仕事だ。誰に感謝されるわけでもないし、むしろ理解されないうちは何をやっているんだと思われるかもしれない。一朝一夕では難しい事だ。最初は少ない人数でもどんどん巻き込んでいかなければ大きな渦は生まれない。後ろ指を刺されても何をされてもいつか賛同してくれる人が現れるという希望を捨ててはいけない。サービスを、数字を、改善するという事はひたすらに上乗せすれば良いものではない。ロジカルに考えた上でロジカルじゃない事をしなくてはいけないのかもしれない。目に見えない事をしないといけないのかもしれない。時にはただひたすらにユーザーの声を聞かないといけないかもしれない。黙って殴られなくてはいけないかもしれない。それに耐えるための一つの方法がコンセプトという拠り所であり、強いてはそこから生み出されるチーム力なんじゃないかと思う。機能数にブレーキをかけるっていうのは決してネガティブな事じゃないんだぞという理解を得るというのはこういう事だったりしないかな。MEはてなブログをはじめよう!pantuneさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。