はじめに
こんにちは、Amaです。今回は最近読んでいる本を通じて得られた「思考の整理」について書きたいと思います。
私はWebサービスのエンジニアとして働いています。エンジニアとしてWebサービスに対する機能の追加や修正を行う際は、納期を守ることや、要件・品質・保守性の担保された実装をすることに注力しています。もちろん、苦労して実装した機能が動いた時の達成感はひとしおです。
しかし、時々ふと「虚しさ」のようなものを感じることがありました。
「一生懸命作ったこの機能、本当にユーザーに届いているんだろうか？」
「リリースすること自体がゴールになってしまっていないだろうか？」
「「KPIが改善した」と言うが、それは本当に喜んで良い改善なのだろうか？」
「この機能をリリースすることで悪化したUXはないだろうか？」
そんなモヤモヤを抱えながら、なんとなく手にとったのが『Running Lean ―実践リーンスタートアップ』でした。
「ビルドトラップ」という言葉との出会い
本を読み進める中で、ある言葉に出会いました。
それが「ビルドトラップ」です。
あとひとつ機能を作ればブレイクスルーしそうなのに、いつまでもそこに到達できないという状態です。
誰も欲しがらないものを作るために、手持ちのリソースがなくなるまで、いつまでもムダな時間、お金、労力を費やすことになります。
いくら技術、特許、景品があっても、製品が顧客の大きな課題を解決していなければ、ビジネスモデルは成立しません。
顧客には無数の選択肢があるため、中途半端な製品を見せられてもフィードバックを提供することはない、...(中略)...ただ立ち去るだけです。
これを読んだ瞬間、点と点が線で繋がる感覚がありました。
私が時折感じていた「要求・要件通りに作ったけれど、これでいいんだっけ？」という不安の正体はこれだったのか、と。
機能を作ること（Output）は手段であって、目的（Outcome）ではない。
頭ではわかっていたつもりでしたが、この言葉を知ったことで、改めてその重要性を突きつけられた気がしました。
「How」だけでなく「Why」を問う
もちろん、言葉を知ったからといって、明日からすぐに開発スタイルを劇的に変えられるわけではありません。
日々の業務には締め切りがありますし、「まずは作りきる」ことが求められる場面も多々あります。実行に移す難しさは、現場にいるからこそ痛感しています。
それでも「今、自分たちはビルドトラップに陥っていないか？」という視点を持てたことは、私にとって大きな収穫でした。
- 顧客に提供する・している価値は何か？
- なぜ顧客はお金を払ってでも我々の製品・機能を選ぶのか？
- 我々が認識する提供価値と顧客が感じている利用価値にズレはないか？
- 顧客が価値を感じている状態は、どのKPIで測るのか？
コードを書く手を止めて、一瞬でもこの「Why」に考えを巡らせる。
そんな「芯を食ったOutcome」を生むための姿勢を大事にしたいと思いました。
おわりに
まだ本は読み途中ですが、まずは「初めて知った概念を実行に落とし込む」ための第一歩として、このブログに残しました。
「システムの作り手」であると同時に、「価値の創り手」になれるよう、視座を上げていきたいと思います。
Discussion