その3「作家に精算する」を書き終えてから、大事なことをひとつ書き忘れていることに気づきました。
作家に精算するのであれば、販売精算書を作家に提出しなければなりません。
銀行口座をどう扱うか、個人情報をどこに保存するか、認証をどうするか。そんなことばかり考えていたら、肝心の精算書について書くのを完全に忘れていました。
これだけ機能を追加していると、何をつくったのか自分でも忘れ始めるようです。
販売精算書くらい、人がつくってもいい
aLくらいの規模であれば、一度の展示会で作成する販売精算書の数はそれほど多くありません。
作品が売れたら販売内容を確認して、作家ごとに金額をまとめて、精算額を計算してPDFにする。多少の作業はありますが、「ここまでシステム化しなくてもいいんじゃない？」と思えるくらいの仕事量です。
実際、手間だけを考えるなら、そのままでもよかったと思います。
ただ、今回いろいろな業務をシステム化していく中で、少し考え方が変わりました。
システム化する意味は、必ずしも「時間を短縮すること」だけではありません。
販売された作品を確認して、金額を転記して、計算して、精算書に反映する。作業量が少なかったとしても、人間が数字を移し替える工程があれば、そこには入力間違いや見落としが起こる可能性があります。
だったら、そもそも人間が転記しなければいい。
そういえば、Squareに全部入っている
その2「作品を販売する」で、aLのWebサイトとSquareを連携させました。
Webサイトに登録された作品情報をSquareへ送り、販売されたらその情報をWebサイトへ戻す。そこまでつながっているのであれば、当然その逆もできます。
Squareから販売データを取得すればいい。
販売された作品、価格、作家など、精算書をつくるために必要な情報を取得できれば、人が売上を見ながら精算書へ転記する必要はなくなります。
ここまでは、わりと簡単な話です。
問題は、そのデータをどう使うかでした。
出したいものから逆算すると、登録方法まで変わる
Squareからデータを取得できたとしても、そこに必要な情報が正しい形で入っていなければ、販売精算書にはできません。
もちろん、取得したデータをプログラム側で無理矢理加工して、必要な形に整えることもできます。でも、それをやりすぎると、普段の運用で少し違った登録をしただけで、間違った内容がそのまま精算書へ出てしまう可能性があります。
そこで、精算書から逆算して「Squareに作品をどう登録するか」というところまで見直すことになりました。
WebサイトからSquareへ作品を送る。その作品が販売される。販売データをSquareから取得する。そのデータを使って販売精算書をつくる。
一周して戻ってくるデータが正しく使えるようにするには、途中だけではなく、最初の登録方法から考えなければならなかったわけです。
こういうところは、実際に運営してみないとなかなか分かりません。
AIでつくるのは楽になった。でも、何をつくるかは別の話
aLを始めて約4年。今回、Webサイトと運営システムを大きく改修していて感じるのは、以前と比べて開発そのものはずいぶん楽になったということです。
特に現在はAIも使えます。コードを書いたり、調べたり、実装方法を検討したりする速度は明らかに上がりました。
ただ、その一方で強く感じたことがあります。
「何をつくるのか」は、結局こちらで考えなければならない。
販売精算書に何を載せるのか。Squareにどの情報をどう登録するのか。作家にどこまで入力してもらうのか。何を自動化して、何を人間が確認するのか。
プログラムを書くことが楽になっても、こうした要件まで勝手に決まるわけではありません。
特にギャラリーは、それぞれ運営方法が違います。同じ「作品を預かって販売する」という仕事でも、作品情報の管理方法、販売方法、作家との精算方法まで、ギャラリーごとの文化や会社ごとの考え方があると思います。
以前なら、その文化をシステムに合わせる必要があったのかもしれません。
でも今は逆に、その場所の運営に合わせて仕組みをつくることが、以前よりずっと現実的になってきた。
開発する側としては、嬉しい悲鳴です。
実は、銀行口座の仕組みも一度やめています
そして販売精算書を考えていたことは、前編で書いた銀行口座の仕組みにも影響しています。
実は作家が銀行口座を登録する機能は、開発途中で一度「いらない」と判断していました。
それまで事業で扱ってきた請求書などでは、PDFの中に振込先の銀行口座が記載されていることも珍しくありません。その感覚で考えれば、販売精算書にも作家の銀行口座を記載することになります。
でも、ここで少し引っかかりました。
PDFとはいえ、銀行口座がそのまま平文で入る。
それをメールに添付して送ったり、Web上に置いたりするのであれば、せっかく銀行口座の扱い方を考えているのに、結局PDFの中にはそのまま書いてあることになります。
それはちょっと違うな、と。
だったら、そもそも銀行口座を登録してもらう仕組み自体がいらないんじゃないか。
一度はそう考えました。
ところが精算業務全体を整理していくと、やはり振込先を管理する仕組みは必要です。そこで前編で書いたように、銀行口座はaLの通常のWebサイトには保存せず、マネーフォワード側で扱う形へと設計が変わっていきました。
すると、もうひとつ気づきます。
販売精算書に銀行口座を書く必要もない。
振込先は別の仕組みで管理されているのだから、精算書は「何が売れて、いくらを精算するのか」を伝える書類として切り離せます。
一度「いらない」と判断した銀行口座登録機能が復活して、その結果、今度は販売精算書の方をシンプルにできました。
設計というのは、なかなか一直線には進まないものです。
だったら、作家ポータルで見られるようにする
ここまで来ると、販売精算書を毎回メールに添付して送る必要もなくなります。
その1でつくった作家ポータルも、当初と比べてかなり機能が増えました。
作品を登録する。プロフィールを管理する。預かっている作品を確認する。返却を依頼する。
そこに販売精算書も加えて、作家自身が必要なときに確認し、PDFとして取得できるようにする。
最初につくった「作品情報を入力してもらうページ」から考えると、ずいぶん遠くまで来ました。
でも、それぞれ別々の機能を思いつきで追加しているわけではありません。
作家が作品を登録し、その情報がWebサイトとSquareにつながる。作品が売れれば販売データが戻り、そのデータから精算書がつくられる。そして精算書を作家ポータルから確認できる。
最初から最後まで同じデータが流れていくことで、人間が途中で転記したり、数字を写したり、PDFを一枚ずつつくったりする工程を減らすことができました。
「人間が気をつける」ことで防いでいたミスを、そもそも人間が作業しなくていい形に変えていく。
今回の改修で大きかったのは、そこなのかもしれません。
で、実際どうだったか
ここまで、Squareのデータ構造だ、要件定義だ、個人情報だと、のらりくらりと書いてきました。
実際に使えるところまでつくってみて、一番最初に思ったことはもっと単純です。
販売精算書が自動で出てきて、そのままPDFになる。
めっちゃ楽です。
販売されたデータを確認して、転記して、計算して、PDFにする。今まで人がやっていた作業が減ったので、楽なのはもちろんですが、人間が見落としたり入力を間違えたりする場所そのものを減らせたことの方が大きいのだと思います。
そして、一度楽になると次のことを考えます。
販売データがあって、作家ごとの精算額まで計算できている。
だったら。
この楽を、会計ソフトまで持っていけないだろうか。
……次はそこをつなぎます。
企画・原文：aL
構成・編集協力：ChatGPT
原文：880文字 → 編集後：3,250文字
（さすがに編集後多過ぎ！こちらの文章の密度が高かったらしい…ということは読みやすい文章を書けていないってことですね…）