ユーザーと開発者の幸福論
概要
チームでドラッカー風エクササイズを実施した際、私の価値としてユーザー第一主義的なことを書いた。
メンバーから開発者としての幸せも大事にしたい的なコメントを頂いたので、その事について考えるページです。
幸福の定義
定義は色々あるだろうが、今回は以下のような事とする。
ユーザーの幸福
- バグがなく安定して使える
- マニュアルを見なくても直感的に使える
- いつでも好きな時に使える
- さくさく動いて気持ちが良い
- 洗練されたデザインでかっこいい
- 欲しい機能がすぐに追加される
- 苦労しなくても目的を達成できる
開発者の幸福
- 新しい技術に挑戦できる
- 外部要因に振り回されることなく開発できる
- 勤務時間以外に働かなくてよい（深夜or早朝リリースしなくてよい）
- 過去の仕様に囚われずに、より良い製品にする自由がある
- 大変なテストや承認手続きを経なくてもリリースできる
- 安全性が機械的に保障され、安心して開発できる
- 苦労しなくても目的を達成できる
幸福の四象限
それぞれの状態について、私が同意できるかどうかと、最悪から素晴らしいへ移行する経路について考える。
第1象限：ユーザーが幸せ＆開発者が幸せ
みんな幸せで何も問題がない。約束の地。
誰が見ても良い状態なので特筆することはない。
第2象限：ユーザーが幸せ＆開発者が不満
ユーザーの利便性のために、開発者に苦労がしわ寄せされている状態。
短期的にはユーザーの満足度を上げることができるが、長期的には技術的負債を負っているので、どこかで返済をしなければいけない。
第3象限：ユーザーが不満＆開発者が不満
みんな等しく不幸で、ある意味平等である。お家に帰りたい。
誰が見ても悪い状態なので特筆することはない。
第4象限：ユーザーが不満＆開発者が幸せ
開発者の怠慢やエゴのために、ユーザーの利便性が犠牲になっている状態。
開発者側に改善が必要な状態であり、仮にこの状態の物を世に出そうとしているなら止めざるを得ない。
例外としては開発者＝ユーザーの開発支援ツールが考えられるが、長期的に使うものであれば出来るだけ使い易く作っておいた方がよい。
なぜならば、久しぶりに使う時に使い方に困ったり、同僚に横流しする時に説明するのが面倒くさいからだ。
ルート1：まずは開発者が幸せになる
開発者のモチベーションが危機的に下がっている状態なら、このルートもありえると思う。
ただしユーザーの満足度は引き続き低いままであり、開発者のモチベーションが上がる前に市場から見放されるリスクは考える必要がある。
ルート2：まずはユーザーが幸せになる
まずは製品価値を市場に認めてもらわないと製品の存続が危うい状態であれば、こちらのルートになるだろう。
新製品の開発や、ライバル製品にシェアを奪われている場合はこちらのルートを辿ることが多いのではないだろうか。
このルートを辿る場合は、開発者に体力的・精神的に負荷がかかる事が想定されるので、離職されないようにケアする必要があるだろう。
今の状況を正直に説明し、今の状態が続くわけではないことを伝えたりするのは大事かなと思う。
まとめ
まとめてみるとユーザーの幸せだけではなく、チームのことも考えなければいけないのが分かる。
この事に気づかせてくれたメンバーに感謝🙂
Discussion