LiBz Tech Blog

LiBの開発者ブログ

エンジニアが仕様書を書き始めてつまずいた4つのポイント

f:id:taisuke_i:20191113211641p:plain 目次

はじめに

エンジニアの磯部です! これまでの記事では開発業務でつまづいたポイントシシリーズをいくつか書かせていただきました。

入社2か月間で駆け出しエンジニアがつまずいた15のポイント - LiBz Tech Blog

入社6か月間で駆け出しエンジニアがつまずいたポイント - LiBz Tech Blog

最近は開発だけではなく企画や仕様策定を少し担当させてもらっています。 そこで今回は仕様策定を経験してつまづいた(フィードバックを頂いた)ポイントを4つ厳選してご紹介したいと思います!これから仕様策定に携わる可能性のある方々の知見になれば嬉しいです。

そもそも仕様策定が何を指しているかというと、自分の所属する事業部では以下のような観点から施策を落とし込むことを仕様策定としています。

■ 機能概要
何を作ろうとしているか概要を書く

■ 機能の目的
どんな課題を解決しようとしているか詳細を書く

■ 進め方
今後の設計や開発のスケジュールを書く

■ 分析する数値
KPIとしてリリース後に確認する数字を書く

■ 機能一覧
開発する機能の概要を一覧で書く

■ ユースケース
ユーザーさんが機能を使う際の想定動作を書く

■ 画面遷移
機能の画面遷移図を書く

■ 画面仕様
画面の構成をページごとに詳しく書く

念のため注釈いたしますと、LiBではエンジニアが企画や仕様決めを担当することが強制されているわけではなく、開発に集中したい、企画を中心としたいといった本人の思考に合わせて携わるチャンスがあります

詳しくはこちら tech.libinc.co.jp

仕様書を書き始めてつまずいたポイント

1.施策目的があいまいになる

問題

機能開発の目的を考える際に「UX向上のためメッセージ画面を使いやすく~」など漠然とした目的を考えていました。施策を考えているとあれもこれも機能を盛り込みたくなってきます。全てのユースケースに対応しないといけない気がして分岐パターンが増えてきます。気づくと仕様モリモリになり、実装工数が現実的ではなくなってきます。何を基準にして作る機能、作らない機能を選んだら良いのか悩んでいました。

学んだこと

目的がシャープで具体的になっていると目的に照らし合わせて必要なこと、必要ないことを判断できます。目的が漠然としているとどの機能も必要そうに思えてきます。「UX向上のためメッセージ画面を使いやすく~」だけではなく「スマホからメッセージを送りやすくするため~」や「スマホからメッセージを閲覧しやすくするため~」など迷った時に立ち返ることができる目的をキチンと設定することで無駄のない仕様につながると学びました。

2.数値目標を忘れる

問題

「早くリリースしたいのでとにかく作って後から結果みよう!」と急ぎ足で開発した際、目標を立てないままリリースしてしまいました。

学んだこと

フィードバックを頂いたのが「目標を決めずに後から結果を振り返ると意図せずとも自分に都合の良い結果を探してしまう」ということです。ボタンの文字を変えるだけでも、クリック率やクリックした後のユーザーの行動が変わったりと、様々な数値に影響を与えます。あらかじめ目標がないとその中から自分たちに都合のよい変化を探してしまいがちです。どの数値が改善して、どの数値が悪くならなければ施策が成功したと言えるのか、事前に数値目標を決めることで冷静に現実と向き合うことができると学びました。

また話はずれるのですが、数値というと冷たいニュアンスがありますが、数字はユーザーさんにどれだけ価値を提供できているかの指標で、適切な数値が改善すればそれだけ良い体験をしているユーザーさんを増やすことができていると捉えるととても意味がある指標に見えてきます。

3.また聞きの情報をうのみにする

問題

社内の営業の〇〇さんから「多くのお客様から『××画面の文字が全体的に小さくて見辛い!』とフィードバックもらっているのですぐに改善してください!」と要望を受けたとします。使い辛いのは大変だ!と「××画面の文字を大きくする」という施策を短絡的に考えていました。

学んだこと

本当にユーザーさんが「××画面の文字が見辛い!」と言っているのを確認したわけではありません。もしかしたら「スマホで見た時に××画面の文字が見辛い!」と言っていたけど、営業の〇〇さんはスマホで見づらいんだったら、PCなど他の端末で見ても見づらいはずだ、と解釈して『××画面の文字が全体的に小さくて見辛い!』と伝えたかもしれません。実は「多くのお客様」というのは営業の〇〇さんが担当している中での「多くのお客様」であって、全体からすると数パーセントかもしれません。

事実を確認しないでふわっとした情報で施策を進めてしまうと、ユーザーさんが本当に困っていることが分からずに見当違いな施策になってしまう恐れがあります。影響範囲を正確に認識できないと優先順位を間違ってしまうかもしれません。また聞きや、温度感の強い意見などに対して冷静に事実を確認する大切さを学びました。

4.一人で進めすぎてしまう

問題

自分はこれで大丈夫!と考えてもレビューして頂くと想定外のユースケースや懸念事項が出てきます。そもそも施策がボツとなるレベルの懸念であったり、修正が発生してしまうこともありました。

学んだこと

考えが及んでいないのが良くないのですが、早め早めに自分以外の意見をもらうことが大切だなと感じています。ついついもう少し完成度を上げてから...とレビューを先延ばしにしてしまいたくなるのですが、施策が遅れてしまってはユーザーさんに本来提供できるはずであった価値が届かなくなってしまいます。慣れないうちは一緒に作ってもらうくらいの気持ちでフィードバックをもらっていくと手戻り少なく進められるのではないかと感じる日々です。

最後に

仕様策定段階で特に印象深かったつまづきを共有させていただきました!企画や仕様決めも開発と同じように奥が深いなと感じる毎日です。企画も同じく始めたのですがさらに難しく歩くことも出来ないような状態なので、つまづけるようになったら企画編もまた共有できたらなと思っています!