最低限やらないといけないラインを見誤った話
全ての開発あるあるだと思うんですが、常にリソースがないですよね。やりたいことに対して使える開発期間が短いし、人も少ない。なので普通はやりたいことに優先順位をつけて、なくてもまあ大丈夫かなという部分は、泣く泣く落としていくことになるかと思います。今回はその優先順位を見誤った話をします。
ちなみに見誤った箇所は、エラーの表示です。Excel/CSVファイルをインポートすることで情報を登録するという機能のエラー表示だったのですが、リリース直後に改善の必要があるとわかり、再検討して実装＆リリースしました。（関わった皆さんありがとうございました🙏）
これについて最近、開発チームやプロダクトマネージャー、他のデザイナー等いろいろな人と話していたのですが、そのときに出てきたことや自分の中で思った反省点について書きます。
同じような機能でも、扱う情報の内容や数が変わると状況が変わる
該当の機能のエラー表示は、すでにあった類似機能である、案件登録のエラー表示に合わせたものでした。
現在のShippioのプロダクトは、基本的に輸入や輸出の案件を管理するものです。案件をアプリケーション上に登録し、情報を入力したり、ファイルを共有したり、チャットをしたりします。案件の登録はExcel/CSVファイルのインポートで行います。今回作った機能は、案件に対してその中で輸送される貨物の情報（輸入・輸出する商品の一覧）を、同じようにExcel/CSVファイルのインポートによって登録するというものです。
案件登録のエラー表示は、インポートに成功した数と失敗した数、その理由を合わせて1行で出します。下記は、元ファイルに10行の案件情報があり、そのうちの5件は入力が必須である「名称」もしくは「案件識別番号」のどちらかがないために登録できなかったことを示しています。
いやこれでエラー出されてもわからんだろとは思うのですが、案件登録に関してはこれでなんとかしています。（自分の入社前のことだったので、詳しい経緯は把握できていないのですが、色々な事情があったはずです）
案件登録は顧客がサービス利用開始時に必ず行うことであり、案件登録数が事業成果と結びついているので、人力によるガチガチのサポート体制が敷かれています。これによってギリギリどうにかなっているのです。
それに対して、今回の貨物登録ではそこまでの体制になっていません。基本的にユーザーが自力でインポート用のファイルを作り、登録作業をします。
また、貨物情報は1案件に対して複数あることが多いので、数が多くなります。さらに、貨物登録機能のリリース直後、使ってくださったユーザーが、私たちが想像していた200倍ぐらいの情報量のファイルをインポートしたので、一気に問題が顕在化することになりました。
その上さらにエラーメッセージに関するバグも発生しており、ユーザーにとって何が起きているのか全くわからなくなってしまいました。
さすがにこれは…となったので、急遽エラー箇所とエラー事由を表示する変更を行いました。以下のように、エラーが発生したExcel/CSVの行と、エラー内容を表示するような形です。これによって何が登録されたのか、登録されなかった行は何が原因だったのかがわかるようになりました。
他の機能でどうにかなっているUIも、利用状況や扱う情報量によって上手くいかなくなります。これはシンプルに考慮が足りなかったので、反省しています。
良くない仕様に合わせても良くない、そこの一貫性に意味はない
既存のエラー表示がベストでないことはわかっていたのですが、なぜそれにしたかというと、一つは一貫性を持たせるべきだと思ったからです。既存機能と同じ画面で、同じようなものとして提供するので、一貫性が必要であり、改善する場合は両者同時にやるのがよいと考えました。
でもUIに一貫性が必要なのは、ユーザーにとってアプリケーションを理解・予測しやすいものにするためですから、一貫性を持たせることでユーザーが混乱するなら意味がないですよね。
一貫性がなくても、部分的に部分的に良くしていったほうがいい
良くないところは踏襲せず、一時的に一貫性がなくなっても、少しずつ直していく方向で考えていく方が正しいと思います。（ちなみに、改善後のエラー表示は、案件登録でも早くこうしてほしいとすごくリクエストされています。ですよね）
実際のデータや利用シーンで試す
もちろん開発中にQAと並行してそういったことはやっていたのですが、前述の通り実際のユーザーが想定の200倍ぐらいの情報量をインポートしたりしたので、利用状況の想定が足りなかったなと思っています。想定の200倍と書きましたが、後から考えると普通にあり得る範囲でした。反省しています。
また、どのようにインポート用にファイルを作るのか、それが最大でどのぐらいの情報量になるのか、顧客ごとにもばらつきがあるはずなので、エッジケースも考慮しておく必要があったと思います。
（可能なら）段階的に開発して、早いうちから社内で試せるようにする
これは開発内容によっては難しいかもしれませんが、できる限り段階的に開発し、デザイナーやプロダクトマネージャー、他の開発メンバーがリリース前に部分的にでも機能を体験できる状態にすることも大切です。
そのように開発を進めるケースもあるのですが、今回の機能はとても複雑だったので、そのような手順を踏むことは難しいと考えられました。でも開発チームの振り返りの時間で「何かやりようがあったのではないか」と話していたので、今思うとやりようはあったかもしれません。
よく「良いMVPとは何か？」という話で、「荒くてもコアとなる体験が実現されていること」と言われたりしますが、似たようなことがここでも言えると思います。
ただし、段階的に作ることで、実装やQAの作業が増えるかもしれません。また、現在Shippioでは開発サイクルを６週間と定めており、そんなに長期間ではないので、段階的に作ることでより手間が増える可能性もあります。でも、手間になるような複雑な機能の時ほど、開発のプロセスを全員でよく議論し、できたものを少しずつ試すことで、明らかになっていなかった課題を見つけていくことが大切だと思いました。
どんなタイミングでも懸念があったら言う
個人的に、一度決めて動き出したものは変えてはいけないという気持ちが強くありました。もちろんコロコロ言うことを変えるのは普通に迷惑ですが、最近は懸念や不安があったらいつでも言ったほうがいいんだなと思いました。
相談してみればちょっとした変更で済むかもしれないし、またその時に開発計画を変えることができなくても、サポート体制を考えたり、注意事項をユーザーにアナウンスしたり、何かやりようはあるかもしれません。次の開発計画に改善作業を入れることもできるかもしれません。
また、一度決めたことを疑うことも必要だなと思いました。自分は一度決めたら次！みたいになりがちなのですが、いつまでも覆していこうと思いました。作っていく中でユーザーの利用シーンについて理解が深まって、前は気づけなかったことが気づけるようになっていることもあります。どうなるかはわからないけど言うだけは言う。
その時だから気づけることもある
無駄な複雑さのない仕様にする
最初の方で「エラー表示を1文の表示から一覧にした」と書きました。後でわかったのですが、大変悲しいことに、一覧の方が開発工数が少なかった可能性が高いのです。いろいろなエラーを集計して一つの文章にまとめるのは面倒で、QAの手間もかかっていたのですが、変更後のエラー表示はサーバーから返ってきたものをほぼそのまま出すだけなので、だいぶシンプルになりました。最初からそっちの案でいっていれば、開発も少し楽だった可能性があります。
これを防ぐためには、エンジニアとよく議論をして、不要な複雑さのある箇所がないか、もっとシンプルな実装にできる部分はないかを検討することが必要だと思います。
ちなみに開発途中でいろいろあったので、スケジュールがかなり押していました。「多少の問題はあれど、とにかくリリースをしなければ」という状況なので、機能のチェックをしていく時も、機能全体を冷静にレビューするというよりは、リリースを妨げる大きなバグがないか、想定した通りの挙動をしているかという思考になります。ゼロベースで懸念がないかをチェックしたり、仕様をもっと良くできるかもみたいなことが考えられる状況ではありませんでした。
次同じ状況になったら…と考えますが、そもそも落としたらいけないラインを守れていたら、とにかくバグだけ潰してリリースするでも大丈夫な気がするので、「そういう状況になる前に仕様をちゃんと考える、中間チェックできるようにする」のがいいのかなと思います。
限られた顧客にだけの先行リリース
これは必ずやろう、というよりは選択肢として持っておきたいというものですが、リリース内容によっては限られた顧客にだけ公開し、状況を理解してもらった上で丁寧にサポートしながら使ってもらって、重要な課題を発見するというのもあると思います。
これについても他の開発では類似のことが行われているのですが、今回は検討されませんでした。自分に関して言えばあまりそういう計画を立てた経験がなかったので、検討をしなかったというのが正直なところだと思います。
そもそもユーザーが自分で入力の間違いを直せないエラー表示など言語道断
そもそもですが、いかなる事情があっても、ユーザーが入力した値の間違いについてユーザーが自分で解決できないようなエラー表示などあってはいけません。いろいろな背景があったと上で書いてきましたが、ユーザーにとって役に立たないエラー表示なら意味がないのです。常識です。
というわけで
みんな大好き失敗談でした。読んだ人はスキとかして供養してください。
引き続きがんばっていきましょう。
この記事が気に入ったらサポートをしてみませんか？