✨開発合宿の成果物を磨いて新機能にする

こんにちは、@mugi_uno です。

暑くて溶けそうです。

新機能をだしました

新機能を出したら開発ブログで何か書く、というのが自分のルーティンになりつつありますが、 先日、表計算ソフトからのコピー&ペースト機能を追加しました。

www.misoca.jp

Excelなどからコピーして、Misocaでペタッと貼り付けると一気に明細が作れるというもので、 先日開発ブログに書いた電卓機能*1と同じく、こちらも4月に実施された開発合宿の成果物がベースになっています。

とはいえ合宿の成果物でいきなりゴールしたわけではなく、リリースまでにかなりのブラッシュアップを行いました。

というわけで今回は、開発合宿の限られた時間で一人で作った機能が、新機能として正式に提供されるためにどのように磨かれていったかをご紹介したいと思います。

合宿終了時点での成果物

まず、合宿が終わった時点での状態がこちらです。 特に誰とも相談せず、思いつくままガッと実装した形です。

f:id:mugi1:20190808171413g:plain
合宿終了時点の動作イメージ

  • 行列の移動がCSSアニメーションでヌルヌル動く(合宿の成果発表時のインパクトのために作ったのは否めない)
  • タブ区切り、カンマ区切りの両方に対応できる
  • 実は全項目編集できる

などが特徴です。

UI/UXを練る

これをベースに、まずは「使いやすいUI/UXはどんなものだろう?」というのを、デザイナーの@kanizmbを中心に一緒に練ります。すると、色々と現状のままではイケてない部分が見えてきました。

列移動がパズル状態になる

貼り付けたデータの列をどの項目に挿入するかを選択するのに、ボタンをクリックでの列と列を入れ替えることで実現していました。 見た目はヌルヌル動いてオシャレですが、実際やってみると動かしたい列の隣の列も動いてしまうので、まったく直感的ではなく、かなり混乱します。

f:id:mugi1:20190808174654g:plain
列移動のややこしさに悶絶する図

まるでスライドパズルを解いているような気分に陥ります。

IQ脳トレ知育玩具 スライドパズルすうじ 15パズル

何かほかの方法で列と明細項目の紐付けが必要だな〜という話になりました。

横スクロールがつらい

表計算ソフトで作られた文書の場合、レイアウト調整などの理由から、必要のない列がデータ間に多く含まれる可能性が考えられます。(いわゆる 'Excel方眼紙' などの場合は特に顕著でしょう。)

そういったデータから貼り付けたい場合、大きく横スクロールが発生する可能性があります。

f:id:mugi1:20190808173139p:plain
横スクロールが発生して困る図

トラックパッドなどが利用できればよいですが、そうではない場合なかなかの使いづらさです。

UI/UXを見直した後のイメージ

ほかにも様々な観点からUIを見直し、次のような修正をすることで方針を固めました。

  • "列に対してプルダウンから項目を割り当てる"という形に変更する
    • 「このデータは数量だな〜」→「項目は数量を選ぼう」という操作ができた方が直感的
  • 行の移動はドラッグアンドドロップでの移動に変更する
    • 文書の明細行並べ替えUIと揃えて、操作感を統一する
  • ひと目で可能な操作がわかるようにする
    • 削除ボタンはマウスホバーせずとも常に表示して、行・列の削除できることがわかるように
    • 既存の画面で可能な操作(並び替えや削除)とUIを揃える
    • 並び替えや削除の範囲が明確になるようにレイアウトを調整する
  • 多すぎる列のデータはグレーアウトして削除だけ可能にする
    • まず不要な列を削除する、という操作をすることで横スクロールを回避する
  • Misocaのアプリケーション全体と見た目を揃える

これらを含め、修正前に一度イメージを共有し、関係者で認識のズレがないことを確認します。

f:id:mugi1:20190808175922p:plain
初期段階で見直したイメージ図

さらに使い勝手などの面から次の対応も入れることにしました。

  • データが多すぎると構築するDOMの量が多すぎてブラウザがクラッシュする恐れがある
    • 一定の列・行数で打ち切るようにする
  • 空行・空列は邪魔になる
    • 空行・空列はすべて削除する

PRレビューでの指摘の数々

見直したイメージに沿う形への修正が完了したら、PullRequestを作成し、まずは開発者でレビューしてもらいます。

コード自体に関するレビューはもちろんのこと、Misocaのレビューでは「そもそも仕様として○○は✕✕のほうがいいんじゃない?」というコメントも頻繁に見かけます。その中でも様々な意見をもらいました。

カンマ区切りいらないのでは?

最初は、表計算ソフトからの貼り付けに加えて、CSVファイル(カンマ区切り)も使えました。 合宿時点では「使えるファイルの種類多くて色々できたほうが便利でしょ!」という軽い考えでしたが、レビューの中で次の意見をもらいました。

f:id:mugi1:20190809102534p:plain

できることが増えることは一見良いことに感じますが、選択肢があれば操作時に思考や迷いを生みます。 あらためてカンマ区切りの是非について検討しました。

  • なんとなく対応してたけど、CSVファイル貼り付けるシチュエーションはかなり稀
  • 暗黙的な挙動が増え、ユーザに戸惑いを与える恐れがある
  • サポートしていることで実装が複雑化し、メンテナンスコストも増える

議論した結果、「最初のリリース時点ではカンマ区切りはサポートしない」とすることにしました。

空列・空行を勝手に削ってほしいとは限らない

「データの中の空列・空行を貼り付けた後にいちいち消すのは手間だから、こっちで除去しておこう!」 と空データをフィルタリングしていましたが、これに対して貰った指摘が次のものです。

f:id:mugi1:20190809105150p:plain

例えば普段は次のような請求書を利用していたとします。

f:id:mugi1:20190809105645p:plain:w400

貼り付ける際には「品目→単価→数量」の順番で左からセットされるのを期待し、実際にもそのように動きます。 しかし、「まったく同じレイアウトで単価は入っていない」といったデータを考えてみます。

f:id:mugi1:20190809110320p:plain:w400

単価に該当する列には何もデータがありません。 この場合、空データのフィルタリングによって「空列」と判断されて削除されてしまいます。 同じファイルから同じ範囲をコピー&ペーストしたにも関わらず、画面上で見えるデータが別のものになってしまうと、 「あれっ?なんで違う項目になるの??」と戸惑うことが予想されます。

便利だと思って入れた空データの除去フィルターでしたが、実際のユースケースを考えると混乱を招く要因になり得ることがわかりました。

除去するのは末尾の空行・空列のみとする」という方針に見直しました。 不用意に除去するより、常にある程度同じ挙動をするほうが使いやすく戸惑いが少ないという判断です。

さまざまな視点からの意見をもらう

開発者やデザイナーだけではなく、マーケティングやコールセンターの方などにも触ってもらいました。違った視点での意見がとても貴重です。

モーダルが狭い

f:id:mugi1:20190809131037p:plain

貼り付ける際に開くモーダルが小さくて使いづらいという意見です。 こちらも取り入れ、デフォルトのサイズを少しだけ大きくし、かつ拡大・縮小を可能にすることにしました。

f:id:mugi1:20190809132418g:plain
拡大・縮小を可能にした状態

数値しか入ってないとはかぎらない

確認してもらっている中で、とある意図しない挙動が発覚しました。

f:id:mugi1:20190809135135p:plain

表計算ソフトで作られた文書の場合、こちらが数値を期待している項目だとしても、本当に数値が入っているかはわかりません。

単純に単価が「10000」だとしても、一般的には次のようなバリエーションが想定されます。

  • 10000 (数値のみ)
  • 10,000 (桁区切りを含む)
  • ¥10000 (金額を示す文字付き)
  • 10000円 (金額を示す文字付き)
  • 10000(全角)
  • 10,000(全角で桁区切りを含む)

このあたりについて一部考慮が漏れていたため、うまく反映されないという動きになっていたのです。

これは、1件ずつ画面で入力する際であれば、リアルタイムで注意喚起や自動的な変換を行ってくれる仕様になっています。

f:id:mugi1:20190809134302g:plain

今回の機能の場合には一括で大量のデータが挿入されることもあり、サービス側でいい感じに変換しないとかなりの手間になることが予想されました。

最終的には、サービス側で数値変換を自動的に行うように対処しました。

f:id:mugi1:20190809135406g:plain
数値の変換を行うようになった状態

Before→After

上記以外にも細かな修正をリソースの許す限り行いました。

開始時点(合宿での成果物)と完成品(リリースされたもの)を改めて比較してみましょう。

Before

f:id:mugi1:20190808171413g:plain
合宿での成果物

After

f:id:mugi1:20190809140118g:plain
最終的にリリースされたもの

こうやって比べてみると、かなり変わっていますね。

最初の状態はパッと見ではスタイリッシュですが、使いづらいところをたくさん抱えていました。 実際のユースケースを想定し、様々な視点からの意見を参考に使いやすさを追い求めていった結果、大きくUIが変化したのは興味深いな〜と思いました。

Misocaにアカウントをお持ちの方は、ぜひ請求書の作成画面で試してみてください。

採用

Misocaでは、より良いものを作っていきたいエンジニアを募集しています

www.wantedly.com