kintone(キントーン)構築・伴走会社のペパコミ株式会社です。
こんにちは。kintone(キントーン)活用ちゃんねるのハルクです。
今ちょうど、ペパコミ社内の発注システムをkintone(キントーン)で作ろうと思っていて、「どういう設計にするか」の社内打ち合わせをしていたんですけど、動画に撮った方がおもしろいかなと思ったので、これから流していきます。
ということで、話の途中からなんですけどやっていきます。
発注システム作成についてミーティング
ハルク：いいよ、OK。どうぞ
竹谷：発注書のところに、このアプリにさっき言った新規登録っていうのを、このじぶんページの入り口で作って、もう1個代理店、新規、顧客登録用kintone(キントーン)っていう…
ハルク：顧客登録用じゃわかりづらいから、代理店用(kintone(キントーン)ライセンス用)、代理店用(プラグイン)っていうふうにした方がいいと思う
竹谷：なるほどね
ハルク：そうすると考えなきゃいけないのが、最初のkintone(キントーン)ライセンス発注をするときに、他のプラグインに必要な情報は、全部網羅的に確保しておきたいわけじゃん。そうするとATTAZoo+だったら住所が必要です。みたいな感じで、各プラグインごとで必要な要素があると思うんだけど、他になんかある？このプラグインだったら、これが要るみたいな。
ユウ：住所、郵便番号は、どっかに書いた方がいい？
ハルク：書いた方がいいね。それ結構あるんだったら。その中で情報として集めるのが結構大変なのある？お客さま側、代理店側からしたら・・・
ユウ：いや、ないんですがMoneyForwardとかだと、●●の事業者番号とかも入力してもらわないと駄目なんです。
ハルク：それはさすがに、要らんな。それは項目あると、多分、入力するとき迷うから。マネーフォワード自体がイレギュラーだから。それはいいんじゃないかな。
竹谷：これをコメントで来たときには、コメントで「事業者番号もください」って。
ハルク：そうだね。問題が、コメントでこっちから促して、じぶんページ上からお客さま側がコメントを入れたときって、俺らに通知を飛ばすようにできる？
竹谷：通知は飛ぶんだけど、今ここでやっていたみたいに、通知メールの共通設定っていう形で、ここに入れたメールアドレスに届くっていう形になっちゃうのね。
そうすると現状だと宮田が担当になるんだけど、宮田フォルダ入っちゃうから、はっきり言って宮田が気付かないと、他が気付かないっていうふうになっちゃうから。
ハルク：それはあかんな！
竹谷：そこだよね、次の問題は。私が今、竹谷のアドレスで、ここに管理登録はしているけど、ここで返信用のメールアドレスを設定できるから、ここどうするねんっていうとこはある。
ハルク：結局、このじぶんページに入れたものって、一時的な受け皿的なアプリで保管されるわけでしょ？
だから発注担当っていうのは、このアプリで未処理っていうのを0件にするっていうのが、まず1次ミッションなわけじゃないですか。
さらにそれが発注管理アプリに移って、発注管理アプリでも一件も未処理をなくすっていうのが、2次ミッションじゃないですか。
そのミッションを遂行していく上で、どうしたってMoneyForadとかの情報が要るなって、なって探すから、通知来なくても・・・、いっか最悪。コメント探しにいきゃいいから。0件にするってミッションを達成するために、絶対に必要な項目でしょ？
課題の再確認と共有
竹谷：私が思ったのは例えばもし来たっていって、今になったら基本アイとユウ君がやるときもあるわけじゃん。そしたら今来たってときに、ここ空白にしておいて処理をする人が自分でちゃんと名前を入れてした方が、いいかなと思ったりしたんだけど、最初から入っていると、ここ触らなくなるから。
ハルク：その名前は、誰が入力するの？
竹谷：処理する人間が、自分がやりましたって言って、やった方がいいのかなと思ったの。それとも更新者にする？
ハルク：それは、いや微妙だな。だって俺が懸念しているのは、とにかく漏れないことなんですよ。漏れないために、一件も未処理をなくすっていうふうにしたいんだけど。
懸念点を共有して相談
ハルク：そもそもの話なんだけど、ここに処理者っていうのは要るの？こんなのただの受け皿のアプリでしょ？無駄な処理増えるし、あくまでただの受け皿アプリなのに、これを処理したのが誰かみたいな情報って、何に使うんやろう？みたいな。通知飛ばすわけでもないし。
竹谷：このまま入ってきましたって、なるとするじゃん。何も入れる必要がなかったら、このままポチっといけちゃうわけよ。そうするとここの進捗変えるのを忘れるじゃん。
ハルク：いや待ってwww。処理者が入っているから、漏れないってわけではなくない？それはそもそも進捗に〇(チェック)を付けない人だったら、処理者だって入れないから、処理者入れるからといってそういう話にならんと思うけどな。
竹谷：2つ付いているから、そうなんだけど。実は最初は進捗がなくて、処理者だけだったのね。
ハルク：ユウ的にはどうなの？俺はどっちでもいいよ。俺は傍から見ていると処理したかどうかとか、責任問題のところは発注管理アプリでやればいいと思っていて、ここはただの受け皿であって、そこから発注管理に展開して、これを誰がやったかっていうのはもちろん大事なんだけど。
ハルク：それは発注管理アプリで、やればいいかなと思っていて。ただ客観的に見て俺は要らないのかなと思ったけど、ユウとかの視点が、どうなのかっていうのは聞きたいかな。
ユウ：このアプリに対して、レコードが入っているじゃないですか。ここにどんどん蓄積されていくと思うんですけど、この時点で誰が最初に手を付けたかっていうのは必要かと思っていて…
業務内容についてスタッフの認識を確認
ユウ：進捗の発注済みにチェックを付けるときって、発注した後・・・
竹谷：私のイメージは、ここまず入ってくるじゃん。未処理一覧がありますっていって、こうやって中身見るじゃん。見たときに一回開いて、発注済みにして、それでこのままここに行くっていう。
ユウ：なるほど、そうしたら大丈夫です。発注書のアプリの方で、誰がやったかっていうのは確認すればいいかと思います。
竹谷：あとはここで、更新者が出ればそれでいいんだったらOKだよね。
ハルク：確かにね。そこ更新者変わるのかな。
竹谷：そしたら今の手順的に、未処理がきています→開きます→もう一回開いてこれを発注済みに変えて保存して、ポチっと押すっていう動きをやれば、元のレコードは更新者が表示されるってことになるもんね。
ハルク：じゃあ、いいんじゃない？
竹谷：そしてコメントが来たときには、更新者に通知っていう形でしておけば・・・
ハルク：いいね。
竹谷：そうすれば本人にいくよね。
ハルク：いいね。いいね、それで。
竹谷：一回ここを編集で開けば、これで竹谷になるかな？
ハルク：どうだろうね、これワンチャン俺が間違えて、なんかの関係で……まあないかな？
そういう意味でいうと、確かにコメント入れたものを、あるフィールドにのっとって通知が確かにできたから、そうするとのぶえさん(竹谷)が、さっきやっていたユーザーフィールドを置いておいても、いいかもしれないよね。その目的だったら。
ハルク：でもどうだろう？更新者で十分？どっちがいいかな？
俺は一手間発生させるのが、アレかなと思ったんだよね。発注側がわざわざユーザーを選ぶっていうのが、結構な数来るだろうし・・・
竹谷：アプリの条件通知。コメントの書込みがあったら、更新者に行く。
ハルク：それでOK！いいんじゃない？
ユウ：進捗の発注済みは、kintone(キントーン)と連動しているってことでいいんだよね？
竹谷：そう。さっきのここのフィールド。
ユウ：わかりました。
ハルク：え？そこ？それじゃ駄目じゃね？
竹谷：ちょっと待って、これ・・・
ハルク：ごめん。これ、だって、受注じぶんページでしょ？発注しているわけじゃないじゃん。受注じぶんページから発注管理アプリにデータを移したら、進捗を発注済みに変えるっていう認識だったんだけど・・・、違うの？
竹谷：そうだよ。
ハルク：そしたら、発注管理アプリに登録したけど、発注しているとは限らないじゃん。なのに、お客様側に発注済みって見えたらまずくね？
竹谷：それをだから、さっき私が発注管理アプリからkrewDataを1個動かして、ここのステータスを、こっちに戻せばいいんじゃない？って言ったのはそこの経由。
ハルク：そしたら、今のこの状態じゃまずいっていうことでいいの？
竹谷：ここでまずいかどうかは検討して？って形。
ハルク：まずいね
竹谷：お客様に見せたい項目は何ですか？っていうのは、今から要相談。
ハルク：お客様側から結局は聞かれることって「これ発注しましたか」とか「どういう状況ですか」っていうのがあって、要はステータスとしては、まだそもそも発注していない・発注しているけどまだ納品待ち・発注済みって大きく3つのステータスがあるじゃん
ハルク：この3つのステータスを、一覧に表示させるのは理想だけど、そのためにはこっち側の運用として、この3つのステータスを持たせなきゃいけないよね。それがどう？こっちの運用的には。でもこれ全部が、納品確認来るわけじゃないもんな。
竹谷：そう納品確認来ないから、難しいと思う。
ハルク：むずいよね。
竹谷：それでいちいち全部、発注書開いてとは、やらないもん。
ハルク：そうすると、どうなんだろうな？例えば、受注から発注管理に移したら、少なからず発注をしようとしているわけじゃん。発注する一歩手前ぐらいなわけでしょ？だからその感じで、この進捗を発注手続き中にしたらいいんじゃない？
手続き中から、発注済みにしてあげたらいけない？
竹谷：そうか！確かに。なるほど。
ハルク：これでまず問題ないじゃん。発注管理アプリで発注にステータスを変えたら、krewDataで発注手続き中を発注済みに変えたらいいんじゃない？
竹谷：これを発注済みにもし変えたら、これが完了になっちゃうんだな。完了になるんだけど、ステータスが完了になったら、こっちのレコードを……
ハルク：そうそう、発注済みにするってやったら、3つのステータスでお客様側はじぶんページで見られるから。そしたら今、発注手続き中なんやなってなるからよくなるかなと思って
竹谷：なるほどね。それはいいかもしれない。これは・・・
ハルク：じゃあそれでいこうか。取りあえず。だからさっきの一覧も変えておかないと駄目だね。未発注一覧とか・・・
竹谷：こっちのね
ハルク：発注手続き一覧・・・、そこはやっていきながら勝手にあれするだろうけど
竹谷：今は、ほぼほぼ取りあえず作りました状態だから。この辺は足りてない部分は、足しながらやっていけばいいと思うから、流れとしては今の感じでいいかな？
ハルク：いいんじゃないですか？これでいったん簡単なマニュアルっぽいのは作った方がいいかもしれないけど、それで何社さんか試して……
●●さんとかは、もう試していいかもしれんな。新規でプラグイン追加になるところとかから試して、問題なさそうだったら、全社、全案件分のお客様分のライセンスを取ってやろうか。
竹谷：お客様の方でレコード追加で選ぶときって、これ出ないんだね。要はこっちでいうところの種別とか、品名入れているじゃん・・・
ハルク：じゃあ、いいんじゃない？
竹谷：これがお客さまの方では、ここしか出ないから、欄とかここの1行でわかるようにしないと駄目だよね。
ハルク：そうだね。
竹谷：ここで選んだら金額は出るけど、選ぶまで金額出ないと思う。
ハルク：これ並び順も登録順なの？名前の並び順とかできないの？
竹谷：できるかな？ここで名前が変わるのかな？
ハルク：そう品目の昇順かな。だけどリンクしてないね。もしかしたらじぶんページは、あかんのかな。結構でかいな、変わって欲しい。
竹谷：確認
ハルク：どうだろう変わってほしいな、それ変わってないですねw
竹谷：登録順か
ハルク：それ変えられないの？じぶんページの設定で。
竹谷：新規追加か
ハルク：製品名検索、できそうだけどな・・・
竹谷：これはそうさっき、エンドユーザーとかってつけていたじゃん？
ハルク：変えられないんだ。でもこれ代理店のだけ見せるようにするっていう、条件設定しているんでしょ？それどこでやっているの？
竹谷：それはアプリの入口を、変えているんだよ。だから今ここエンドユーザーって書いてるじゃん。左側はこれがアプリのフィールド名なんだけど。
ハルク：わかった。そもそもルックアップの設定自体を設定2つして、それぞれの設定を変えているってことね。
竹谷：そうだよ。
ハルク：ということは、ルックアップの設定を変えたらいいんじゃないの？じぶんページのルックアップの並び順を変えたらいいんじゃね？下並び替え・・・
竹谷：昇順が「あおいうえお」
ハルク：じゃあ昇順やな。で、品名の昇順。これでいけるんじゃね？もう1個も変えといて、エンドユーザーだけじゃなくて、代理店も・・・
竹谷：ここに標準価格を足して、検索用にするか。
ハルク：価格順にするってことな。
竹谷：価格順っていうか、価格も見えるように、選択できるように。値段選ぶときには、千諾できるように。変わったけど、これめっちゃ見づらいな・・・
ハルク：これ微妙じゃね？メーカー順じゃなくて、名前順じゃね？いや、めっちゃ微妙。なにこれ・・・
竹谷：品目の方に、並び順を入れるキーワードを作るか・・・
ハルク：自動採番？だってそれ駄目だよ。途中で追加するってことがあるもん。
竹谷：例えば、メーカーがないのはあるんだ。この辺はメーカーがないからきているんだ、この空白が。
ハルク：バグってるな、しかも「？」になっている。
竹谷：これもうちょっと、見やすくしないと駄目だね。
ハルク：番号を振ってもいいかもしれないね。例えば、増える場合は同じ番号でやるしかないんじゃない？間に挟みたいときは。
竹谷：kintone(キントーン)からスタートするものは、kintone(キントーン)は「1」にして、そういうルールを作っておけば、間にもし挟んだとしても、その下に来るじゃん。
ハルク：まあ、そうですね。
竹谷：そういうのも駄目なら、じゃあ「11」「1」・・・
ハルク：これ多分kintone(キントーン)を「1」にして全部統一したら、1カ月、2カ月、3カ月の順番に並ぶはずだから。名前順に変えたらね。
竹谷：そうだね。年額と月額も…
ハルク：そう！これもそろえたいよね。年額と月額も！例えばkintone(キントーン)の月額だったら”1-1”で、kintone(キントーン)の年額だったら”1-2”にするとか、そういう感じじゃない？
竹谷：そうだね。とにかく番号でソートできるような・・・
ハルク：やった方がいいよね、これカッコ悪いもん。
竹谷：カッコ悪いね。ちなみにだけど今、ちょっとだけ話変えていい？これ見ていて思ったんだけど、更新連絡あるじゃん。これ更新連絡を・・・
別件の相談をヒアリング
竹谷：その日付になったら、ここに自動発信できないかな？できそうな気がするんだけど。
ハルク：できたとしても、ややこしいな。契約管理もあって、発注もお客様側がわからなくなるな。
竹谷：このレコードの一部だけを見せて更新しますってコメントが来れば、コメントが来たことに対しては、通知を飛ばすことができるから。お客様の方から更新しますって連絡がここに入っていれば、更新していいんだなっていう判断はできるよ。
ハルク：それ、一回やってみようか。通知飛ばせるか、確認してもらって・・・
竹谷：そうだね。一部でできるか確認して、試してみる。
ハルク：試しでな。でもそれで更新の手間が減れば、ちょっといいよな。
竹谷：取りあえず一回そんな感じで、じぶんページ使うわけだったら、それをフルに活用して、更新の連絡が出来ないか確認してみるよ。
ハルク：そうですね。
竹谷：発注レコードが新規に作成されたら、契約内容の更新で、テーブルにデータが入ればいいんだよね？
ハルク：発注内容で新規で作ったら、契約内容に……そうだね。ただ……
竹谷：ただ、プロセス管理のステータスは・・・
ハルク：そこもそうだし、ダイレクトに契約管理登録した場合も、発注内容を作られると再度作られちゃうとかってあるから、微妙な気がするな。
竹谷：そしたら、何らかのステータスで、お知らせできるようなことをするしかない。
ハルク：めっちゃ、漏れそうなんだよな。
竹谷：発注担当者がじぶんページから発注書を作りました。「この内容が契約内容で。この契約について追加発注がありましたよ」、「確認してくださいね」っていうのが必要なわけでしょ？
ハルク：ん？
ユウ：もう絶対に最初は「契約完了を開く」みたいなやつにした方が、いいとは思っています。
竹谷：ここから？
ユウ：そうです、そこから。
ハルク：俺もそうなんだよね。そっち派なんだよね。どっちかっていうと。だって、契約管理っていうのが、請求に関わるから・・・
竹谷：変えたとして、発注内容とは違うじゃん。
ユウ：違います。
竹谷：そうすると……
ハルク：契約管理の下の方に隠しておいて、全部必要なものを放り込んでおけばいいんじゃないかなと思って。
竹谷：この内容を？
ハルク：契約管理に入ってくれれば、最終的に俺が確認するから。これが発注しているかどうかって。発注履歴の関連を必ず見るような運用になっているから、漏れないんですよね。そっちスタートだったら・・・
竹谷：もう一回言って。ハルクは、ここで発注履歴を見るってこと？
ハルク：契約管理が登録されたときに、発注履歴を見ているよ。発注履歴と照らし合わせて、契約開始日が合っているなとか、更新日が合っているなとか見ているから。
竹谷：発注書が、作成されたとき？
ユウ：自分が契約管理で発注済みっていうのを押すんですけど、それを押していただいたら、ハルクさんがこの契約内容のやつを確認しています。
竹谷：そしたら、ここで発注書を作ったときに、このステータスをフィールドにして、発注済みになったらハルクに連絡が行くっていう仕様にしておけば、そこは一緒なんじゃないの？やることは？
ハルク：それはさっき、のぶえさん(竹谷)の言った問題点は解決しているんだけど、俺が言った問題点は解決してないんですよ。発注管理アプリでやると、新規の発注の場合に、契約管理アプリにダイレクトで登録することもあるわけですよね。発注作ったときに、ダブって契約管理とか作られたりとかしないかな？みたいな。そこが不安なんですよ。
竹谷：今の話はアカウント追加とかではなく、新規の契約管理を作るときの話？
ハルク：そう
ユウ：自分も一気に全部の発注は、こういう形にした方がよくて、こういう流れでやるみたいな形の方がいいとは思っています。追加の場合は発注書に飛んで、そのまま発注書にしちゃうっていうのと、新規の場合は契約管理に一回来て、発注書作ってみたいな流れがあまりよくないんじゃないかなと思います。
竹谷：どちらにしても、ここで発注書を作成にしているけど、これを契約管理にアクションで持っていくっていう形？
ハルク：そうそう。
ユウ：そうです。その場合だと、もともと追加の場合、5のレコードをじぶんページのアプリから取れないじゃないですか。
竹谷：取れないね
ユウ：アクションでこの契約内容に飛ばすっていうのも、あまり意味ないんじゃないかなと思っています。なので、どうしようかなって感じなんですけど。じぶんページに入ってくるアプリがあるじゃないですか。
発注書にアクションで情報を飛ばすんじゃなくて、いったん契約内容に飛ばそうって話だったと思うんですけど、それは新規追加の場合は問題ないと思っています。
ハルク：新規追加って……、じぶんページ・・・、ちょっともう書くわ！
竹谷：言葉の認識がね。
ハルク：
①じぶんページから契約管理に行って発注パターン
②契約管理から発注管理で発注パターン
この2パターンの認識が、まず俺はあるのね。
竹谷：②は、お客様が注文するってことがないパターンだよね
ハルク：そうそう、初期構築・案件発生時。
竹谷：契約管理の前に、案件管理っていうところか。じぶんページではなくて、案件管理から来る方だよね。
ハルク：じぶんページは、既存顧客の追加申し込み。俺がさっきからずっと定義付けで言ってるのが、②が新規っていう定義だよねって、ずっと確認しているんですよ。この②のパターンが。
竹谷：私はずっと①のことを、言っている。
ハルク：wwwユウはどっち？
ユウ：自分は、①の方のことです。
ハルク：そうだよね。だから俺②だよねって言って、「そう」って言って進むから、②だっていう前提で聞いていたからね。つまり①の話をしていて、新規って言っているのは、この①のパターンの中で新規がライセンス追加。
竹谷：①の新規は、プラグイン追加。つまり、新規プラグイン。
ハルク：ここで新規と、追加って分ける意味が全然わからなくて、ライセンスの追加だろうがプラグインの追加だろうが、既存顧客の追加申し込みじゃんなんだから、文言として新規追加ってここで分けているのがよくわからない。
竹谷：手順だよね。っていうことは、じぶんページに入力してもらうじゃん。そしたらそこでアクションボタンで発注書までは作成しないと、意味がないとは思うのね。
ハルク：言っていることは理解できるけど、俺が気にしているのは運用面なんで、結論、発注のお2人ができるんだったら、どっちでもいい。俺はやってないから発注を！
やっていないから、いろいろパターンがあると混乱するかなって、勝手に思っちゃうんだけど、実際にやるのは2人だからね。どうですか？どっちがいいです？
竹谷：難しいのは、さっきユウ君が言ったように、追加を発注管理に飛ばして、他のものは契約管理っていう手順で分かれるとやりづらいって。それが問題になるんじゃないかってユウ君は心配したわけで・・・
ハルク：いや俺もそれを言っているのよ、さっきからずっと。
竹谷：新規追加を契約管理にアクションで飛ばすのはOKなんだけど、ライセンス追加はアクションで契約管理に飛ばせないのね。飛ばしちゃったら、1個新しくレコードできちゃうんだから。だから困るよね、どうしよう？っていう話になっているの。
ハルク：それがわかった上で、元々この話がすごい白熱しているのが、発注に作ってkrewDataで契約管理自動作成は怖くね？っていうところになっているから。俺的にはそこがいったんクリアになったんであれば、あとは発注担当がやりやすいやり方で、こっちの方がいいんですって決めた方がいいんじゃないのって、思っているんだけど。
竹谷：まあ、そうね。
ユウ：取りあえず、いったん絶対に契約管理は、開いた方がいいと思うんですよ。
竹谷：何かしらでね。
ユウ：何かしらで。
竹谷：そしたらデータが入ってきた時点で、じぶんページのレコードに顧客番号はあるよね。その顧客番号をキーに…
業務の方向性を共有
竹谷：それは任せるよって、いう感じだな。
ユウ：それが、いいかもしれないです・・・
業務の方向性を確認
竹谷：今まで通り、ユウ君がちゃんと使える？
ユウ：はい！
竹谷：であれば、ハルクは安心ってことで良いんだよね？
ハルク：もうガソリン切れしていましたねww
ユウ：今までと同じやり方で、全然、大丈夫です
竹谷：そっちはね。じゃあこれでいい？
ユウ：うん
ハルク：OK！アイさんも入ったし、もうばっちりでしょww
アイ：頑張りますww
ハルク：www
竹谷：そんな感じでお願いします。
ハルク：じゃあ抜けます。お疲れさまです。
竹谷：お疲れさまです。
ミーティングを終えて
ということで、だいぶ白熱した議論になりました。
今回ペパコミの発注管理を簡素化、かつお客様にも見える化をしていこうということで、今回じぶんページとかを入れて、どういうフローにするかとか、決めていった感じですね。
どこまで使えるかわからないですけど、参考にしてみてください。
僕らも常に自分たちの運用目線と、お客様目線での運用ができるかどうか！
特に、自分たちのkintone(キントーン)環境を構築する上で意識しているところが、やっぱり漏れない仕組みなんですよね。
”人力で、漏れないように頑張ります”なんて、全然、話にならなくて、ここを見たら漏れないよねとか、誰もがここを見たら漏れていることがわかるよねって、シンプルにしてあげることが大事なんですね。
どこを見たらわかるかっていう、ボトルネックをはっきりさせるっていうか。そういった設計も踏まえながらアプリの設計をしていく。
①自分たちの運用の部分
②お客様の運用の部分
③人力ミスを極力なくす/人力ミスが発生したとしても、すぐに分かる仕組み作り
③については、自分たちの漏れとかミスとか、そういった人力ミスを極力なくし、発生したとしても、すぐにわかるような仕組み作りです。
この3つの軸から、どういう設計・どういうフローにするべきかっていうところです。
今日はかなり難しいフローの設計だったんですけど 、ある程度は運用でカバーしていきながらという事になるんですけど、取りあえずこれで走ってみて、やっていくというそんな感じですね。
ということで、以上となります。
コメント