これはサービス開発してる人にとっては当たり前かもしれないのですが、自分に対しての戒めでもあるので、なんとなく文章として残しときます。
どんなことかというと、自社サービスを開発・運営していると、不定期に○○をこうしてほしい、△△はユーザーが使いづらいと言っていたので直したほうがいいのではーなどの要望が上がってくるわけですが、その時の思考の入り口として、それはユーザーにとってどのようなメリットが有るのか、体験が改善されるのかというところから入るのではなくて、その言われた要望は実装的に出来そうか出来なさそうか、というところから考えてしまうという話です。
これは割と癖になりやすいかなーと思っていて、早いうちにプログラマーの仕事は言われたことを作る仕事であるみたいな感じで染み付いてしまうと、なかなか変えづらいのかなと感じてます。特に今は僕は2Bのサービスを作っていてクライアントが明確なので2Cのサービスよりダイレクトにユーザーの声を聞きやすく、故に「あ、それは実装できますね、やりましょうか」みたいな感じでほいほい言われたものを作るだけだと、容易に統一感がなく使いづらいプロダクトが出来上がってしまいます。
ユーザーのオペレーションも含めて検討した結果、その要望は実は既存の他の機能で満たせることかもしれないし、見せ方を変えるだけで解決するかもしれない。僕らの仕事はモノを作ることではなく、課題を解決することにあって、何かを開発することはその選択肢のひとつにすぎないのですよね。
というようなことをインターンの子に↓の話をしてるときに改めて思ったので、僕も意識しようと思ったという話でした。おしまい。
若者に、issueには、何を直すのではなくて、なぜ直すのか、何が問題なのかを書いてちょという話をした
— rei_m (@rei_m) May 28, 2018
- 作者: 安宅和人
- 出版社/メーカー: 英治出版
- 発売日: 2010/11/24
- メディア: 単行本(ソフトカバー)
- 購入: 48人 クリック: 660回
- この商品を含むブログ (143件) を見る