しんりのblog

思ってる事、好きな事、トライした事などなどを書きます。

いくらで売るか? part 2

part 1の続き。
shinri55.hatenablog.com
前回、個人的には売上より利益優先の方がいいと思うと書いたけど、その理由とここらへんはキーエンスの仕組みがとてもよく出来ていると感じたので、いいと思った事を書く。
シェアを取るためにあえて安い価格で競合を排除するという手法もあるとは思うけど、ただ安いだけだともっと安いところが出てきた時に更に安くしないといけないので、どうやって利益を取るかは考えとくべき。

いくらで売るかというのは非常に難しいけど、企業にとっては大事な事3本の指に入ると思う。

海外のプライシング

SAP時代、辞める直前ぐらいにVendavoという3rd partyのソリューションをOEMで販売し始めた。
どのくらいのプライスバンドで売るのが最適かマネージするソリューションで、製品毎、顧客毎等にどの金額範囲で販売されているのか、いくらで売った際に最大の利益が出るか分析できるようなソリューションだった。
非常に高額なソリューションだけど海外では普及しているらしく、日本は適切なプライシングが検討されていないという話を聞き、お客様にも何度か話した。

この領域のソリューションは当時プレーヤーが少なく、マッキンゼーのソリューションがExcelのようなUIだがシェアが高いという話を聞いた。(誰かとの会話の中で聞いたので本当かどうかわからないけど。。。)
そこで当時この本を読んだ。

マッキンゼー プライシング (The McKinsey anthology)

マッキンゼー プライシング (The McKinsey anthology)

プライシングはロジックと現場感両方大事で、必ずしも書いてある通りじゃないと思ったが、ロジック面ではこの本の影響を大きく受けている。

ただ価格を上げる事はよくないが、価格を上げないといけないケースは多い。
営業としては何故価格を上げる必要があるのか、現在の状況を含めしっかり話せないといけないと思っている。
そうしないとお客様の信頼を失い、本当は価格が上がってもそのお客様にとってはとても役に立つのに、お客様が離れてしまいお客様に損をさせる事にも繋がる。

自分の中でのプライシングのロジック

自分の中で価格について考えている事を箇条書きにしてみる。
売る側として書いてるけど、買う時にも同じように考えている。

価格の決め方と影響

  • 価格は価値によって決めるべきである。
  • 顧客認知価値が増えているのに価格を同じにするのは値引きと同じ効果がある。
  • 顧客認知価値を増やす事が出来ない競合は値下げで対抗してくる。結果業界全体の平均価格が下がってくる。

何故今価格を上げるのか

  • 価値が上がる際に価格は上げないといけない。そうしないと結果的に業界全体の収益が上がらなくなり、投資ができなくなる。
  • 結果、品質、サービスの質が下がったり製品自体を提供できなくなり、結局はお客様も不幸になる。
  • 価格を上げる事により離れるお客様もいるが、全てのお客様を満足させる事は不可能なので、どんなお客様の役に立ちたいのか明確にする。

プライシングにおける営業の役割

  • 提供価値と顧客の認知価値は違う
  • 実際にその製品が提供できる価値よりお客様が認知している価値は低い事が多く、それを埋めるが営業の役割の一つ。
  • 特に複雑な製品ほどその傾向が強いので営業の介在価値が高く、営業が価値を説明できないと価値より安い価格で提供しないといけなくなる。(ドリルじゃなく穴を売る話やそもそも多機能すぎて全体を理解するのが難しい)

価格を上げる事の効果

  • 販売価格を上げる事は、販売数量を増やす事、コスト削減することより利益への影響が大きい。(S&P構成企業1500の売上数量、単価、コスト比率で考えると価格を1%引き上げると営業利益が8%増え、売上数量を1%増やした時の3倍の効果があるらしい)
  • 顧客の認知価値が変わらず価格だけが変わると、相対的に競合より高くなり切り替えるお客様が出てくる。特にスイッチングコストが低い製品は切り替えられてしまう。
  • 認知価値も変わると失われるお客様もいるが、新しく獲得できるお客様もいる。(安い物はそれだけの価値しかないと思われるケースがある)

お客様の種類

  • お客様は一人一人、一社一社毎に考えが違うが、自身の状況に合わせて認知価格と認知価値の比例直線上で選ぶケースが多い。
  • 価格を最優先するお客様、一定の品質を満たす中で一番安い物を選ぶお客様、品質、スペックを最優先するお客様がいる。
  • インターネットの普及で金額情報の格差がなくなり、こだわる物は高いコストを払い、それ以外はできるだけ安いものを買うケースが増えてきている。

キーエンスのプライスコントロール

私が新卒で入ったKeyenceという会社は、2018年の営業利益率55.6%と製造業としてはダントツで平均年収も2,088万とこちらもこの規模の会社ではダントツ高い。
私がいた頃より共に大きく伸びているので仕組みも更によくなっていると思うが、転職してみてプライスのコントロールが非常にうまかったと思ったので共有。

  1. 営業の成績が売上じゃなくて利益。
  2. 値引き承認が厳しく、競合より安い値段は承認されない。競合が値引いたから以外のしっかりした理由が必要。
  3. 営業は機能ではなく、価値を伝えることが徹底され、毎日ロープレを実施する。

色々仕組みとしてすごいと思うところはあるんだけど、営業のプライスコントロールという観点では上の3つが大きかったと思う。

プライシング戦略を決めた後に、その価格でお客様が購入するかどうかは、お客様がその価格を払うに値する価値があると納得する必要がある。
その価値や価格を伝えるのは営業の仕事で、営業現場に浸透(腹落ち)させないといけない。
でも営業は売上を上げたいし、利益がなくても売りたいと考える。(自分もよくあります)

キーエンスの特徴の一つに成績が利益というのがあり、これが大きく貢献していると思う。
FA業界では場合によっては7割引、8割引というのが当たり前にある世界で、競合の定価もあってないようなものである。
キーエンスの場合製品毎に仕切り価格(材料費、人件費等の原価)が決められており、それを超えた金額が営業の成績になる。

例えば10,000円の製品の仕切り価格が2,000円で2,500円なら100個買うという人と8,000円で15個買うという人がいた場合、それぞれに売上と利益を比較すると

売上

100個の場合:250,000円
15個の場合:120,000円

利益

100個の場合:50,000円
15個の場合:90,000円

と成績は逆転するので安易な値引きが減る。

更に競合より安い値段や、競合が値引くから値引くという承認は通らない。
これは値段だけで判断されている場合、更に競合が値引くとまた値引かねばならず、業界にとってもよくないという考えがあると思う。

更に本当にどれだけの価値があるか、お客様の状況に合わせて具体例で説明する練習をたくさんするので、実際の価値とお客様の認知価値のずれがなくなり、正当な価格で購入してもらえるのだと思う。

いくらで売るかというのは非常に難しく答えのないものだと思うが、営業としては何故その価格なのかはしっかり説明できないといけないと思い自分の考えを整理してみた。
また企業としてはプライシングは現場に浸透していなければならず、その理由を全員が腹落ちしており、かつそう動きやすいよう目標KPIにも反映させることが大事だと思う。

いくらで売るか?part 1

先日Amazonプライムの年会費が3,900円から4,900円に値上げになり、Twitterでは賛否両論渦巻いていた。
togetter.com

個人的にはこの値上げはそれぐらい全然払うよと思った。
Primeビデオをよくみるので、それだけでも元が取れるし、送料無料とかお急ぎ便が使えるとか便利すぎて、提供価値的には月4,900円でも安いじゃないかと。

それでも値上げをすると不満はでる。
コストを最重要視するお客さんは安ければ安いほうがいいし、今回のように事前にコミュニケーションがないとレピュテーションリスクが非常に高い。
でもそのリスクを判断した上で、企業として利益を追求するという観点であれば値上げしたほうがいいケースは多いし、業界、日本の為にも値上げすべきケースは多い。
そもそもAmazonが(値上げしたとしても)この金額だと、有料動画サービス、ECサイト、小売等は、価格勝負は厳しいからよっぽど尖った強みがない限り収益性はどんどん悪くなると思う。
で収益性が下がると、投資も出来ないのでサービスの質が悪くなり、更に客離れが続くという悪循環が続いちゃうんじゃないかなーと危惧する。

いい機会なので、一度自分の値段に対する考えを整理しておこうと思う。

何故価値より安すぎる価格で売ると良くないのか?

ご存知のように先進国の中でも日本はダントツでデフレが続いており、物価が上がっていない。
物価が上がらない理由は、人口が増えておらず需要が伸びないなどいろんな要因があるが、企業が値上げをしなかった、低価格で市場シェアを取る選択をした企業が多数あった事などに起因していると思う。
f:id:shinri55:20190504235632p:plain
資料:GLOBAL NOTE 出典:OECD

そして平均年収もG7で推移を見ると、軒並み上がっている中、日本とイタリアだけがあがっていない。

昔のように人口が増えていく局面では、需要も増え値上げしても販売量が増えるという状況だったと思うが今は勝手に需要が増えるというケースは少ない。
売上が上がらないとコストを抑えるしかないので、給料も下がっていく。
給料が安くても物価が安いなら別にいいんじゃないかと一瞬思うけど、海外と比較して相対的に低いと優秀な人材が外資に取られ、日本の会社の競争力がどんどん落ちていく。
また国内でも人の取り合いになって人件費が高騰すると、利益率の低い会社は赤字になるか質を下げるしかなくなる。
性能、品質、サポート等で劣ると値上げは難しく、更に値下げでしか対抗できなくなる。

値上げは出来るのか?

じゃあ値上げをすればいいじゃんと思うけど、値上げをするのは難しい。
自分は今まで所属した全ての会社で値上げのタイミングがあり、営業としてお客様に説明する立場だったから説明には非常に苦労したし、折角価値を理解いただき導入してもらったお客様に値段を上げますというのはとても心苦しかった。
特に値段のロジックが自分でも腹落ちしていないと説明は苦しく、外資の会社にいた時にヘッドクォーターから消費者物価指数に合わせて毎年値上げをするという話が来た際にはお客さんにどうやって説明しようかずっと悩んでいた。

でもうまく値上げしてるなという企業、業界はある。
先日日経で、外食業界はデフレから抜け出せていないが、カフェチェーンはうまく単価を上げているという記事を読んだ。
www.nikkei.com
カフェ業界を引き上げてきたのはスタバだと思うけど、自分も行くと1000円弱使ってしまうし、コーヒーだけでなく、快適なスペースや色んなメニューでうまく客単価を引き上げてるなと思う。
ただコーヒーの値段を上げているわけではないので納得度は高いし、それが高い思うお客さんはターゲットにしていない。
カフェチェーンは客単価や収益性を常に意識している企業が多く、各企業だけでなく業界としていい流れになっているのだと思う。

一方、ちょっと前に吉野家が最終赤字に転落という記事も見た。
limo.media
人件費や原材料費が上がる中で、客単価が上げられておらず売上は好調なのに赤字になってしまっているとの事だった。
コストを自分達でコントロールできないかつ変動費が大きいので、構造的に赤字になっており売上が伸びるほど赤字が膨らんでしまうため、値上げ以外に手の打ちようが無いように感じる。

でも値段をあげると今までのお客さんが離れて売上が落ちるので、中々踏み切れなかったのかなーと思う。
全てのお客さんをターゲットにして利益をあげるという事は、高品質な製品を低価格で提供しコストも非常に安いという事なので、限りなくハードルが高いと思う。
AmazonGoogleといった一部の企業を除いては、誰をターゲットにするのかを明確にして値付けをしたほうがいい。
売上を増やしてシェアを取るのか、利益を取るのかはどの会社にとっても大きな問題だと思うけど、個人的には利益を取るほうがいいと思う。

part 2ではなんで利益を取るほうがいいと思うのか、あと昔所属していたキーエンスはこれが非常にうまかったと思うのでそこら辺を書いてみようと思う。

平成と埼玉

さっき令和を迎えた。

この1ヶ月令和を掲げる菅さんをなんども見たけど、個人的には平成おじさんと呼ばれた小渕さんの方がしっくりくる。大学の合気道部の先輩で、ちょうど大学に入った年に小渕さんが亡くなったので、当時何度も映像を見て親近感を持ってたのかな。
f:id:shinri55:20190430215907j:plain

人生で2度目の時代の移り変わりだけど、平成の時は小学生2年ぐらいでニュースしかやってなくてつまんないなーと思ってた事ぐらいしか覚えていない。

話は変わるけど昨日「翔んで埼玉」を見た。
埼玉を愛を持ってディスってる映画で、羽生は出てこなかったけど知ってる場所が多数出てきて楽しめた。
エンディングではなわの「埼玉県のうた」が使われていて、アジア一の大きな団地が埼玉にあると歌ってたので調べたら松原団地の事だった。
www.tondesaitama.com

で今日ちょうど帰省で東武線に乗ったので、松原団地どこらへんだったかなと思って路線図を見たら存在しない!
いつの間にか獨協大学前という駅になっていた。変わってからも何回か通ったはずなのに気づいてなかったな。

改めて獨協大学前を通過すると何と団地が全然ない。
20年以上前だけどこの駅にある高校を受けて、松原団地に降りた時には団地だらけだったはず。
これも調べてみると15年ぐらい前から建て替えが始まってたらしい。
意識しないと気づかないもんだなー。

なんて考えながら電車が鷲宮駅に停まったら降りていた。
自分は25年以上前ここにある「わし宮団地」という団地に住んでいて平成もここで迎えた。

引っ越してから一度も来ていなかったが松原団地がなくなったのを見て、わし宮団地もそのうち無くなってしまうかもと思って思わず降りた。
わし宮団地は規模としては約2,500戸と松原団地の半分程度。
当時家賃は2万円ぐらいで家族4人で住んでいた。通っていた小学校も全員団地の住民だったので周りも裕福な家庭がない不思議な環境だった。

わし宮駅を降りてみると駅に併設していたスーパーが何もないスペースになっていた。
f:id:shinri55:20190501001022j:plain
更に歩いて団地まで行ってみると当時住んでた1-12-104はポストに蓋がしてあり誰も住んでなかった。
f:id:shinri55:20190501001257j:plain
この小さな扉を開けたとこを秘密兵器にしてたな。
f:id:shinri55:20190501001409j:plain
更に歩いて商店街に行くとほぼ閉店。何故かドラえもん激似の像が建っており太郎くんと書かれていた。
f:id:shinri55:20190501001557j:plain
そんな中でも子供のころ毎日行った「だるまや」は健在。当時の佇まいのままで、30年以上前遊んだお菓子を掴むクレーンゲームや10円を弾くゲームがそのままあったのは感動した。
f:id:shinri55:20190501001757j:plain
帰りに通っていた小学校の前を通ると廃墟と見間違う程古くなっており、廃校したのかと思いきや
f:id:shinri55:20190501001856j:plain
f:id:shinri55:20190501001935j:plain

調べてみるとまだ健在だった!
でも昭和50年代は1,000人ぐらいいた生徒が今は60人ぐらいで今年の新入生も5人しかいないらしい。

そういえば団地を歩いても、人とほとんど会わず特に子供とは全然会わなかった。
自分が住んでいた頃は外出すれば誰かしら友達と会うし、もっと人がたくさんいて活気があった。

少子化は何となく感じていたけど、ここまで実感を持って感じたのは初めてだったな。
今後の日本を考えると少し怖くなったけど、昭和から平成への移り変わりを思い出してノスタルジックに浸った平成最後の一日。

freee APIを使って資金繰り表を作るときに苦労した事 part 1

先日freeeのAPIを作って資金繰り予定表を作った話を書いてから時間たっちゃったけど、これからfreee API取り組む人のためにどんな所に苦労してどうやって解決したか書いておこうと思う。

【前提】Web API めちゃくちゃ概略
Web APIについての詳細はいろんなBlog、サイトがあるのでそちらを見てもらえれば。
自分はバリバリの文系人間なので、専門的な事は分からないが、今回の説明に必要なので超簡単に自分が理解してるイメージを書いておく。

  1. Web APIWebブラウザでホームページを見るのと同じように、HTTPを使ってサーバーとやり取りをしている。
  2. ホームページの場合URLにアクセスするとHTMLが返ってくるので、それをWebブラウザが読み替えてホームページを表示している。
  3. Web APIも同じようにURLに何かしらの指示を送るとJSONXMLなどのデータ、ファイルが返ってくる。
  4. 指示の仕方はGET(取得)、POST(作成)、PUT(変更)、DELETE(削除)などのメソッドと呼ばれる指示とURI(URL or URN)を指定する。
  5. 返ってきたJSONなどを、プログラムで自分が見たいように加工してあげる。

現在会計freeeのAPIで公開されているのはこちら
developer.freee.co.jp

こちらに記載してあるAPIエンドポイントの
https://api.freee.co.jp
の後にapi/1/と行いたい内容のURIを書くと実行できる。

BSを取得したい場合、さっきのリファレンスで試算表の取得を見ると、
/reports/trial_bsと書いてあり、Parametersに絞り込むためのパラメーターが書いてある。

例として事業所IDXXXXXXの2019年1月のBSを取得したい場合、
Parametersの中に事業所IDが「company_id」、会計年度が「fiscal_year」、開始会計月(mm)が「start_month」、終了会計月(mm)が「end_month」とあるので、

https://api.freee.co.jp/api/1//reports/trial_bs?company_id=XXXXXX&fiscal_year=2019&start_month=01&end_month=01
と書いてあげる。

1、月次推移表APIがないので、試算表APIから自分で作らないといけない。

freeeはオープンAPI戦略を取っているので、他の会計ソフトと比べるとかなりの種類のAPIが公開されており、最近もどんどん追加されてるけど、月次推移表はまだ用意されてない。

そこで試算表APIで月毎の試算表のデータを取ってきて、自分で試算表を作る必要がある。

 やり方は色々あると思うけど、自分がやったのはURIの年と月を変数にして12回for文で繰り返すことにより配列に12ヵ月分入れるやり方。
12回APIを呼び出さないといけないので、結構時間かかる。
ここは詳しい人にもっといい方法があれば教えて欲しいところ。

for(var r = 0; r<12 ;r++){

var requestUrl_3 ="https://api.freee.co.jp/api/1/reports/trial_bs?company_id="+ companyId+"&account_item_display_type=group&breakdown_display_type=account_item&fiscal_year="+ prf_year[r]+"&start_month="+ prf_month[r]+"&end_month="+ prf_month[r];
res3[r] = UrlFetchApp.fetch( requestUrl_3 , options ).getContentText();
//レスポンスのデータを配列に格納
bsResponse_3[r] = JSON.parse( res3[r] );
data_3[r] = bsResponse_3[r].trial_bs;

parent_account_category_name_3[r] = [];
account_category_name_3[r] = [];
account_item_name_3[r] = [];
hierarchy_level_3[r] =[];
closing_balance_3[r] = [];
debit_amount_3[r] = [];
credit_amount_3[r] = [];
opening_balance_3[r] = [];

for ( var q = 0 ; q < data_3[r].balances.length ; q++ ) {
account_category_name_3[r][q]=[ data_3[r].balances[q].account_category_name ];
closing_balance_3[r][q]=[ data_3[r].balances[q].closing_balance ] ;
hierarchy_level_3[r][q]=[ data_3[r].balances[q].hierarchy_level ] ;
account_item_name_3[r][q]=[ data_3[r].balances[q].account_item_name ] ;
debit_amount_3[r][q]=[ data_3[r].balances[q].debit_amount ] ;
credit_amount_3[r][q]=[ data_3[r].balances[q].credit_amount ] ;
opening_balance_3[r][q]=[ data_3[r].balances[q].opening_balance ] ;
}

2、月毎に勘定科目、タグの数が違うのでそのまま配列に入れるとずれてしまう
 これは例えば1月に使ってなかった勘定科目を12月に使ってると、1月の試算表には出てこないが12月には出てくるのでそのまま配列に入れると位置がずれてくる。
またfreeeの試算表は残高が多い順にタグが並ぶので、タグで集計する場合はそのまま配列に入れるとこれも同じくずれてくる。
そこで年度の試算表から勘定科目一覧を持ってきて勘定科目で比較して一致した列に残高を入れるようにした。
イメージはこんな感じ。
集計用の列の勘定科目が同じなケースがあるので、下の列も合わせて比較することによってユニークになるようにした。

/*******
 月次の残高を科目に合わせて並び替え
 *******/ 
    
    bs_closing_balance[r] = [];//月次の期末残高用配列
     bs_debit_amount[r]=[];
     bs_credit_amount[r]=[];
     bs_opening_balance[r]=[];
    
    var arrData3 = Array.prototype.concat.apply([], account_category_name); 
    var arrData5 = Array.prototype.concat.apply([], account_item_name); 
    var arrData7 = Array.prototype.concat.apply([], hierarchy_level); 
 
    var arrData4 = Array.prototype.concat.apply([], account_category_name_3[r]); 
    var arrData6 = Array.prototype.concat.apply([], account_item_name_3[r]); 
    var arrData8 = Array.prototype.concat.apply([], hierarchy_level_3[r]);
    
    
  /*******
 アカウントアイテムはユニークなので入ってる時はそのまま挿入。入ってない場合はアカウントカテゴリー、アカウントアイテム、ヒエラルキーレベルが一個下も一致した場合にアカウントカテゴリーを入力
 *******/    
    
 var dd =0;
  for(var s = 0; s < account_category_name.length ; s++){
     for(var t = 0; t < closing_balance_3[r].length ; t++){  
 
       if(!arrData5[s]){ 
    if(((arrData3[s]==arrData4[t])&&( arrData7[s]==arrData8[t])&&(arrData5[s]==arrData6[t])) && ((arrData3[s+1]==arrData4[t+1])&&(arrData5[s+1]==arrData6[t+1])&&( arrData7[s+1]==arrData8[t+1]))){ 
         bs_closing_balance[r][s]=closing_balance_3[r][t];
         bs_debit_amount[r][s]=debit_amount_3[r][t];
         bs_credit_amount[r][s]=credit_amount_3[r][t];
        bs_opening_balance[r][s]=opening_balance_3[r][t];
         break;
    }else if(arrData3[s+dd]==arrData4[t+1]){
      for(dd=1; dd<100 ;dd++){
        bs_closing_balance[r][s]=closing_balance_3[r][t];
        bs_debit_amount[r][s]=debit_amount_3[r][t];
         bs_credit_amount[r][s]=credit_amount_3[r][t];
        bs_opening_balance[r][s]=opening_balance_3[r][t];
      break;
      }
    }
  }
       else{
         if(( arrData7[s]==arrData8[t])&&(arrData5[s]==arrData6[t])){
         bs_closing_balance[r][s]=closing_balance_3[r][t];
         bs_debit_amount[r][s]=debit_amount_3[r][t];
         bs_credit_amount[r][s]=credit_amount_3[r][t];  
           bs_opening_balance[r][s]=opening_balance_3[r][t];
           
         break;
    }
       }
  if(!bs_closing_balance[r][s]){
   bs_closing_balance[r][s]=[0]; 
   bs_debit_amount[r][s]=[0];
   bs_credit_amount[r][s]=[0]; 
   bs_opening_balance[r][s]=[0];
   }       
      
  
  }
  }
  }
  }catch(e){
    Browser.msgBox("その期間のデータがfreeeにありません");
  }

 
3、売掛、買掛レポートはAPIがないので取引APIから自分で集計をしないといけない。
売掛レポート、買掛レポートはAPIがないので取引を取得して決済期日から集計した。
100件づつしか取り込めないので100件取り込んだら、+100 件目から取り込むように書いてみた。

 while(i != 10000){
    
  var requestUrl ="https://api.freee.co.jp/api/1/deals?company_id="+ companyId +"&status=unsettled&offset="+ i +"&limit=100";
  //特定の事業所の未決済取引を100件づつ取得  
  var res = UrlFetchApp.fetch( requestUrl , options ).getContentText();
  //レスポンスのデータを配列に格納
  var mikessaiResponse = JSON.parse( res );
  var data = mikessaiResponse.deals;
  var length =data.length;
   
  for ( var j = 0 ; j < data.length ; j++ ) {
    id.push( [ data[j].id ] );
    issue_date.push( [ data[j].issue_date ] );
    due_date.push( [ data[j].due_date ] );
    
    partner_id.push( [ data[j].partner_id ] );
    type.push( [ data[j].type ] );
    amount.push( [ data[j].amount ] ); 
    due_amount.push( [ data[j].due_amount ] ); 
    due_year[j] = [due_date[j].toString().substr( 0,4 )]; //決済期日の年切り出し(最初から4文字)
    due_month[j] = [due_date[j].toString().substr( 5,2 )];//決済期日の月切り出し(5文字目から2文字)
    due_ym[j]= [Number(due_year[j]+Number(due_month[j]))];
  };
    
//100件づつ取り込みなので次の100件用にインクリメント。取り込みが100件以下ならブレイク。    
  if (data.length != 100){
  break
  }
  i = i+100;
}

あとは取引先、年月毎に集計して表にしてみた。
ここら辺は下記プログラムの未決済取引取得モジュールを参考にしてみていただければ。
docs.google.com


続きの最後資金繰予定表を作るところはまた今度書きます。
 

非エンジニアがfreeeからAPIで資金繰予定表を作るのにどれくらい時間がかかるか試してみた

最近WEB APIがビジネスソフトでもかなり普及してきてるなーというのを感じる。

WEB APIとは、簡単にいうとWEBサービスクラウドソフトの情報を読みだしたり、書き込んだりする仕様が公開されてて、自分で作ったソフトで活用できるというイメージ。例えば下の記事のようにtwitterに自分のソフトから書き込んだり、投稿されたデータを読み込んだりできる。

qiita.com

2017年に改正された銀行法でオープンAPI導入に係る努力義務が盛り込まれて銀行がAPIを公開したり、私が働いてるfreeeも、APIエコノミー形成に向けてfreeeオープンプラットフォーム戦略を進め、freeeアプリストア」を公開したり、API界隈の動きが大きくなってきている。

 

で、打ち合わせの中でもAPIの話が出てくるので、エンジニアでないお客さんが自分で開発出来るのか、どのくらい時間かかるのか等、自分で肌感持ってた方がいいと思うのでGoogle Apps Scriptを使って資金繰予定表を自動で作れるプログラムを作ってみた。

 

作ったプログラムの動作イメージはこちら(3分半ぐらいの動画です)

freeeからAPIで資金繰予定表を自動作成

 

スプレッドシートはこちら

docs.google.com

※趣味で作ったので、テストあまりしてませんし、動作保証してません。スクリプトも整理せず書きっぱなしなので参考程度にしていただければ。

 

感触としては、Google Apps Scriptは、OAtuth認証用の「OAuthライブラリ」があるのでAPIでデータを持ってくるところまではかなり簡単。

土日でGoogle Apps Script の本を読んで、freeeのヘルプページのサンプルを参考にすればすぐ出来る。

でも自分の見たい形に自動でするのは結構大変で、整理せずに必要な処理を付け足していったら1500行ぐらいになってしまい、(プログラミングに慣れてる人ならもっと減らせると思います。)時間も15時間くらいかかってしまった。

例えば月次推移表のAPIはないので、試算表APIで各月分で12回取って来ないといけないんだけど、月によって勘定科目の数が変わるので、一致させるよう処理したり、債権債務の情報はレポートから取れないので未決済の取引を取得して集計したり結構手間がかかる。

ここら辺は、今度どんなとこが大変だったか書こうと思う。

 

結論としては、APIでデータを取って来るのは簡単なので、エンジニアではなくても取り組んでみてもいいと思う。でもこだわりすぎて自動化しようとすると、複雑になってプログラムのメンテナンス性が下がるので、そんなに手間じゃない作業は手作業を組み合わせた方がいいと思った。あとは会社として導入する際は、誰かが勝手に作ったプログラムが乱立しないように、管理する仕組みや体制も合わせて考えないと属人化リスクが発生するので、そこら辺も注意喚起してあげた方がいいなと思う。

個人的世田谷区おすすめカレー

趣味がカレー食べ歩きという事で好きなカレーを紹介していきたいと思います!

一口にインドカレー、欧風カレーなど同じカレーでも味が全然違い、更にはインドカレーの中でも北インド南インド東インド、西インドでそれぞれ違いがあり奥が深いのですが、好きなのは南インドカレーとスリランカカレーなので、*1好きなお店にも偏りがあります。

 

今回はご近所世田谷区の好きなカレー。

 

第5位

馬来西亜マレー@祖師ヶ谷大蔵

tabelog.com

祖師ヶ谷大蔵駅から徒歩 10分ぐらいの住宅街にあるカレー屋。近くまで来るとスパイスの匂いが漂ってきてお腹が減ってくる。色々珍しい料理も多く、量もあるので複数人がいいけど広くはないので4人ぐらいで行くのがおすすめ。名物のバクテー・バビは辛くないけど八角が効いてて美味しい。 

第4位

シバカリーワラ@三軒茶屋

tabelog.com

三軒茶屋で本格的なカレーを食べたいと思ったらここ。ダバ系*2と呼ばれるダバインディア系列で働いてた人が出した店の一つで、ここも他のダバ系同様チーズクルチャがうまい。サイドメニューも豊富でビール飲みながらティッカとかチキン系のメニューを食べると最高。

第3位

サンバレーホテル@三軒茶屋

tabelog.com

 昼はビリヤニしかないお店。昼しか行った事ないけど夜のカレーも美味しいらしい。突発的にビリヤニ*3が食べたくなると、いつもここを思い浮かべる。予約出来なくて、お店の前にあるノートに名前を書くスタイルなので、中々行きにくいけど、それでもここのビリヤニは食べに行く価値がある。

第2位

beet eat@喜多見

tabelog.com

ジビエカレーが食べれる店。しかも南インドカレーのミールスになってて完成度が高い。ジビエは女性店主が自分で猟をしてるらしい。薬莢が飾ってあったりする。初めて行ったときは出店したばかりで並ばなかったけど、最近はかなり並んでる&喜多見でちょっと遠くなかなか行けてないので是非また行きたいと常々思っている店。カウンター数席しかないので一人か二人ぐらいじゃないと厳しいかも。

第1位

旧ヤム邸 シモキタ荘@下北沢

tabelog.com

もともと大阪のカレー屋さんで一昨年東京に進出。一時期大阪出張してた時に毎回食べに行ってて、新幹線で向かう時から 味を思い浮かべるぐらい好きだったカレー屋なのでできたときはすごい嬉しかった。今もメニューあるのかわからないけど、当時大阪の中之島店にはジャンさんというスリランカ人が作ったカラワンスペシャルっていう混ぜカレーがあって、このカレーは当時日本で一番うまいカレーだと思っていた。だしが効いてるヤムカレーというスープをかけて食べる独特のスタイルで旨味がすごく、シモキタ荘もおすすめ。土日の昼は結構並んでのでコアタイムを避けたほうがいいかも。

その他

砂の岬@桜新町

本格的な南インドミールスを出してくれる。長期インド修行に行って休んでる時もある。金額はちょっと高め。

三茶カリーZAZA@三軒茶屋

シバカリーワラのすぐ近くで、前住んでた家からすぐだったので昔は週一ぐらいで行ってた。インドカレーではないけど玉ねぎがたっぷり入っててうまい。ポークカレーは大きな豚バラが入ってて焼きチーズトッピングすると更にうまい。

ガラムマサラ@経堂

しっかりしたインド料理だけどオリジナルメニューも多い。牡蠣パクチーとかサバ缶(にスパイスと玉ねぎとか入れて和えたもの)がうまい。そしてコスパがいい。

 

 

書ききれなかったけど近所だけに好きなカレー屋が多くて迷う。あと千歳船橋のカルパシは行きたいと思いつつタイミング合わなくて行けてないのでなんとか行きたい。

 

goo.gl

*1:

南インドカレー

シャバシャバした液体に近いカレーが多く、お米で食べる。北インドカレーより油少なめで魚介のカレーも多い。

スリランカカレー

ココナッツミルクを使ったカレーが多い。トゥナパハという複数のスパイスを炒めて砕いたものを使うので香ばしい。いろんなおかずとカレーを一皿に持って混ぜて食べる。

*2:日本一有名な南インド料理店ダバインディアの系列で働いてた人が出した店。他に大塚のカッチャルバッチャル、木場のカマルプール、ディルセなどがある。どこもレベルが高い。

*3:インドの炊き込みご飯。こんなの。スパイスとご飯を重ねて炊き込む。家で作ると難しいし時間もかかる。

ブログ始めます

初めまして。

しんりです。

実は年初に今年の目標としてアウトプットをするというのを設定していて、早くも3月になってしまいましたがとりあえずブログを始めてみます。

 

なぜこんな目標を設定したかというと、自分は自己開示が苦手でジョハリの窓でいうところの解放の窓が狭く、結果、話しにくいと感じる人がいたり、本音を話しにくいと感じる人がいるんじゃないかなーと思ったから。

 

私が勤める会社には価値基準とペルソナというのがあって、この中で自分が全然実現できてないなーと思うのが「あえて、共有する」「ジブンゴーストバスター」「アソビゴコロ」という3つ。

「あえて、共有する」

人とチームを知る。
知られるように共有する。
オープンにフィードバックしあうことで一緒に成長する。

「ジブンゴーストバスター」

自分の思い込んだ自分の姿(ゴースト)とは違う「ありのままの自分/弱い自分」を恐れず、勇気をもって向き合い、フィードバックを貪欲に求め、咀嚼し、立ち向かっていける人

「アソビゴコロ」

ユーザーや周りの人を気持ちよくする工夫をしたり、難しいことを簡単に・楽しくするような遊び心を持って何事にも取り組める人また、他のメンバーの遊び心を「やるやん」「ナイストライ」と前向きにとらえる人

 この3つは言葉は理解しつつも腹の底では、どーでもいい話だなと思われるのが嫌で重要な事だけ共有すればいいかなーと思ってたり、仕事も慣れて今のやり方が楽だなーって思っちゃったりしていた。でも大きな仕事をするには自分だけじゃできないし、今のやり方だとその延長線上での成長しか出来ないと思い、自分を変える第一歩としてチャレンジしてみます。

そんなわけで収益化みたいな事は全然考えてなくて、自分の考えてる事、好きな物、トライしてみた事などを書きみます。

書いて問題ない範囲で仕事に関連する事もふれるかもですが、全て仕事としてではなくプライベートとして個人的な意見になります。

そして挫折しないよう目標は低めに、週末に出来るだけ書く事を目指しまーす。