養殖業特化の業務用SaaSを開発して感じたサービスデザインの鉄則6選
僕たちの開発は進んでは戻るプロセスの連続でした。粒度は大きいものから小さいものまでさまざまですが、仮説を立てて機能を作っては生産者さんから率直な考えや意見を聞いて修正してきました。まだ全然完成していませんが、画面を作りデザインする過程で何度も何度も小さく失敗してきました。その過程でごにょごにょと考えたことがいくつかあったのでアウトプットしてみます。
1.デザインとは複雑性を管理すること
UXを考える自分としてはこの期間によく考えていたのは「デザインとは何か」ということでした。思うにデザインというのは「複雑性をコントロールし、自由度を意図的に下げる」という営みだと思うのです。
知れば知るほど、養殖の世界って複雑なんですよ。養殖は個体管理できる養豚や養鶏とは決定的に違います。それは個体管理ができないことです。1尾1尾に合わせて給餌することも、投薬することもできません。だから群で管理するしかない。そして群は混ざったり、分けられたり、場所を変えたりします。何より魚は水面下を泳いでいるので目では視認できない個体がたくさんいます。
しかもエサひとつとっても、給餌方法はたくさんあります。ペレットでの給餌もあれば、生のエサをそのまま給餌するパターンもあります。冷凍された魚をミンチにするモイストペレットという方法もあります。袋やkg、冷凍された魚のブロック数など、仕入量の単位はバラバラです。
医薬品なんて粉だったり液体だったりします。だから単位もLとkgが混在します。10kg、2kg、500g、150mLなど様々です。箱買いしちゃうパターンだってあります。
仕入の記録は給餌や在庫の記録とつながっているべきだし、給餌の記録は生簀の記録とつながっているべきです。その生簀が動いたり分割されたりしてもデータは引き継がれるようにすべきです。同時にやりたいことがたくさんあります。デザインとはこの複雑さを下げ、予測可能性が高い状態をユーザに提供することだと思っています。
2.見えないデータ構造がデザインを規定する
そう考えると、デザインするということは情報を整理し、構造化する作業であるとも捉えられます。見た目がオシャレかどうかは些末な枝葉の話で、まあそういう細部の技術も大事ではあるのですが、今作っているプロダクトについては構造を正しく捉えることがとても重要です。
データに価値があるのは意思決定が変わることで価値を生みだすことができるからです。そのためにはデータは意味のある形で繋がりを持ち、蓄積されることが重要です。ただただ記録が付けられることをゴールにするのは明確に違います。
そう考えると、デザインを握る影の立役者は実はぱっと見ではわからない裏側のデータベース設計にあるということに気づきます。この設計が仕様になり、制約を生み、全体のUXを規定します。
生産者さんの行動や魚の様子を想像し、起こり得る可能性とシナリオを整理した上で、可能性を制御するために足りる画面を設計するという作業が実はプロダクト開発におけるデザインではとても大事なのではないかと考えています。
だからサービスの機能や画面を考えるとき、僕は時間の8割くらいを思考することに使っています。ああでもない、こうでもないと思考していて画面が1枚もできていないという時間がとても長いです。画面を作る時間は残りの2割くらいです。それだけUXの骨格となるデータ構造を正しく捉えることに時間を使います。
3.抽象化して共通項を取り出す
作りながら新たな要件がどんどん追加されるというのはもうどうしてもSaaS開発の宿命のようなものです。時には開発済の機能が一部のユーザには微妙にフィットしないことがあります。この気持ち悪さをユーザ側に微塵も感じさせないようにするためには、どうすればいいでしょうか。この答えはやはり交通整理です。もっというと抽象化・構造化です。
たとえば、養殖での給餌方法には生の魚（生餌といいます）を使うものが複数パターンあります。まずは生餌をそのまま給餌するパターン。ヒラメとかマグロはこれです。他にも生餌と配合飼料や栄養剤を一緒に混ぜ込んでペレット状にまとめてから給餌するMP（モイストペレット）という給餌方法があります。このMPは船の上で作るパターンと工場で作ってもらうパターンがあります。
生産者さんがやっている業務は一見するとそれぞれが全く別のものに見えます。生餌だと漁獲した魚や冷凍された餌を買ってきて、給餌用のケースに詰め替えていますし、船の上でMPを作るパターンだと冷凍された餌を船の上に積みこんで必要な分だけを生簀ごとに給餌します。工場の場合は勝手に工場の人が混ぜてくれているので、生餌の仕入を生産者さんが行う必要はありません。
だから当初、僕たちは生餌給餌のための生餌の在庫管理機能と、船の上でMPを作るための生餌の在庫管理機能の二つを持っていました。さらに工場でMPを作る場合は製造されるMPの中に生餌が埋め込まれているという、なんともめちゃくちゃいびつな構造になっていました。それぞれを別のタイミングで増改築したことで、全体を俯瞰してみるとなんだか変なことが起こってしまったのです。
これらの機能は生産者さんの業務フローを抽象化することで突破口が見つかりました。
1.全体量を把握する
生餌：解凍したり、給餌用ケースに開けたときに全体量が把握できる
工場MP：製造時に全体量が計算できる。
船上MP：船に積み込んだ時に全体量が把握できる。
2.独自の箱が給餌単位となる
生餌：詰替え後のケースや給餌用ケースでざっくり何杯分を給餌したか
工場MP：混込済のMPが入ったケースでざっくり何杯分を給餌したか
船上MP：船に備え付けのMP製造用の窯でざっくり何杯分を給餌したか
3.仕入量から給餌単位のkg数が決定される
生餌：ケースの利用数と仕入量から決定される
工場MP：ケースの利用数と仕入量から決定される
船上MP：船に備え付けのMP製造用の窯数と仕入量から決定される
4.全体傾向から誤差を調整する
生餌：1ケースあたりの平均重量には上限値がある
工場MP：1ケースあたりの平均重量は購入時に指定している
船上MP：1窯あたりの平均重量には上限値と下限値がある
こう考えると、大きな流れは4ステップでどれも変わりません。このことに気づいたことで生餌機能は単一機能として統合することが可能になり、付随して全体UXもわかりやすくなりました。
4.全ての要素に意味と哲学を持つ
情報構造が整理されたらレイアウトが決まります。あとは画面に落とす作業です。この段階で大切なのは全ての要素がなぜそのワーディング、文字サイズ、文字色、背景色で配置されているのかを説明できるように意識することです（これがなかなか難しい）
画面に意味のない要素は一切必要ありません。そこには必ず意図があり、達成したいことがあるはずです。無意味な装飾にこだわる必要はありません。
画面は何度も画面を作り直してきましたが、ルールを決めていないとだんだん揺らぎが目立ってきます。たとえば細かいですが、「確定ボタン」なのか「OKボタン」なのかとか、背景色を敷いていたり敷いていなかったりとか…
デザインは思考の幅を絞り、自由度を下げることに本質があるので、些末なところで「ん？」「あれ？」とつまづくポイントを残すようなことがあってはなりません。
その画面にユーザがきたタイミングで達成したいことは何かを複眼的に考える必要があります。流入の文脈・シナリオをすべての画面で想像し、事前に整理します。各シナリオでユーザはやりたいことを本当にすぐに達成できるか、すべての画面で点検することが重要です。画面においてあるすべての要素はそのいずれかのシナリオにリンクするようにします。そのうえで太くすべき導線を見極め、優先度をつけていきます。その積み上げがUXを形作ります。
5.心理の機微を捉える
人がどう現場で動くと、一番生き物も快適で成長できて、人間も働きやすくて、事業も儲かるのか。検索ボックスがあるとキーワードをいれてしまうように、UIやUXが人間の行動を規定していく部分はわりと大きいです。 ただ使いやすいだけではなくて、どう人間の動きをデザインするか、というのがソフトウェア開発における醍醐味であり、それが僕の原動力にもなっているってところはあります。
やはり生産管理というのは続けてナンボです。基本的には人間は怠惰な生き物なので、心理学的な見地からも工夫を仕込んでおくことが必要です。そこで僕たちが作ったのがこの記事で取り上げているgithub型のホームです。ちゃんと記録を付けた日は濃い色がつくという仕組みです。
人は一貫性を大切にしようとする傾向があります。過去自分がエネルギーや時間を投資してきたものには高い価値を感じやすく、その行動を継続する内発的なモチベーションがわき起こりやすくなります。どうせ同じ作業をやらないといけないのであれば、ユーザ側もその業務自体に意味や価値を感じられる方が幸せなんじゃないかなと思っています。
6.作らない機能に誇りと哲学をもつ
理論上正しいことをそのまま実装するのが常に正しいわけではありません。大切なことは現場が求めることやシステムとして達成すべき目的に応じて必要なものを見極めるということです。
見極めるということは時には捨て、割り切る引き算が必要だということです。むしろ、明確な哲学をもって決断された引き算の意思決定は、適当なノリで追加された謎機能よりも価値があります。
たとえば、僕らは魚の生産管理サービスを作っているわけですが、餌の在庫管理もできるように機能開発しています。でも餌の先入れ・先出し機能は開発をしないことを意思を持って決めています。
それは完璧な在庫管理を実装してしまうことに弊害があると考えているからです。もし完全に正しい在庫管理を実現すると、在庫量を下回っている給餌記録は一切記録できなくなります。ユーザは給餌記録をつけたいのに「まず仕入記録をつけましょう」という全く嬉しくない要求をしなくてはいけません。仕入単価を記録者であるユーザ全員が正確に理解しているとも限りません。そうすると、正しくやろうとすることで却って記録が全くつかなくなるリスクもあるのです。
何をやるか以上に何をやらないかを意思を持って決めることで道が開ける場面が多分にあると僕は思っています。
8月にサービスローンチします！
いろいろ開発が追い付いていなくて大変ではありますが、現時点においてすでに少なくても日本一の生産管理サービスに仕上がっていると思っています。なによりサービスに期待していただいている方と本気で養殖業と向かい合って、成功事例を一緒に作りたいと思っています。経験や勘も活かしながら、データを上手く使っていきたいと熱量高く思ってくださる方の力が必要です。一緒に悩み一緒に考え、一緒に未来を切り拓いていきたいです。
もし少しでも興味をもっていただける方は是非、資料請求でも無料トライアル（正式リリース後からですが）でも構いません。お気軽にお問合せください！
Twitterもやってます！
Twitterもやってます。プロダクトやサービスに興味を持っていただいた方はフォローいただけると嬉しいです。気軽にメッセージもいただければ！
この記事が気に入ったらサポートをしてみませんか？