kintone CSVインポートツール比較

今回比較したツールは以下の5つです

ある小売業のお客様で「販売管理システムからCSVを出力して、kintoneに定期的にインポートしたい」という要望がありました。
インポート作業は毎日定期的に数回発生するため手動でのインポートはNGで、自動化してほしいということでした。大きな要件としては以下の点です。

  • kintoneの管理画面を使わずに手動ではなくバックグランドでCSVを登録してほしい
  • CSVのカラム名はkintoneのフィールドコードと異なるためこれに対応してほしい
  • レコードの追加だけではなく更新にも対応してほしい
  • コストは月1万円以内

「kintoneの手動インポート」は私自身も苦手な作業でありまして、毎回CSVカラムとフィールドをマッピングするのが面倒なのと、キーを間違えるとレコードが多重登録されてしまい、データを削除してから再度登録する必要があるなど、運用中のアプリに対する作業としてはかなりストレスがかかると感じています。

この画面見ると緊張します(笑

そこでいくつかのベンダーさんからリリースされているCSVの自動インポートツールを比較検討した結果についてこちらにも書き残しておきたいと思います(2022/12時点)。

kintone コマンドラインツール(cli-kintone)

1つ目のツールは「cli-kintone」です。(これ発音は「クリキントン」でいいんでしょうか?笑)
サイボウズ社が提供する無料のCSVインポートツールです。このツールはインポートだけではなくエクスポートもできるのでkintone上のデータをやり取りするための機能が一通り揃っています。

クリキントンの操作画面

ただし、元々が開発者向けツールでもあることから、コマンドライン(MS DOSの黒い画面)で操作を行うことが必要です。このため、ある程度のコマンド知識を求められることと、今回のケースのようにCSVファイルを何度もインポートするには、このツールに対して追加の作り込み(プログラミング)をしないと、適用が難しいと判断しました。

ツール自体は無料ですが、今回の要件に合わせていくには初期の開発費用がかかってしまうのがネックとなりました。

Smart at tools for kintone CSV入出力

ここからは有料のツールです。

M-SOLUTIONSが提供するSmart at toolsシリーズです。このツールもCSVのエクスポートを含めてインポートに対応しています。
さらに、CSVのカラムとkintoneのフィールドコードをあらかじめマッピングすることができます。これによりインポートするたびにいちいちマッピングをする必要がありません。

フィールドマッピング画面

CSVを登録するタイミングですが、CSVファイルをインポートする時間をあらかじめスケジューリングできます。スケジュールされた時間になるとフォルダ上のCSVをkintoneに登録開始します。

利用コストは、kintoneのライセンス数などにより変動し、今回のお客さまは60ライセンスということで「ライトプラン」となり初期費用10万円 、年額36万円(設定数10まで)という価格感でした。

krewData

krewSheetで有名なグレープシティの製品です。フィールドマッピングやスケジュール実行などの機能はSmart at tools for kintoneと同じスペックを有しています。

ただし、CSVファイルの投入先はDropboxなどのクラウドストレージである必要があります(通常のローカルのフォルダは不可)。このため別途クラウドストレージの契約が必要です。今回のお客さまはこの点がネックになりました。

なお、CSV投入先がクラウドストレージであるメリットは、Windowsにインストールするモジュールが必要なくWeb上で完結することです。もしすでにクラウドストレージが入っている環境であれば適用できるケースも多いと思います。

コストは月額13,200円からで変換設定の数や登録データ数などでさらに課金されていきます。この点ではちょっと使いにくいかなと感じました。

 

DataSyncer for kintone
続いてクラフテクスが提供するDataSyncer(データシンカー)です。

こちらはエクスポートに対応はしていませんが、インポートに特化した構成のため、痒いところに手が届く様々な機能が実装されています。(あらかじめフィールドをマッピングできるところは他のツールと同じです)

インポート関連の機能が多く実装されていました

CSVデータの登録は、CSVファイルがフォルダに置かれると自動で登録が開始されます。このためほぼリアルタイミングでの登録が可能になります。逆にスケジュール実行する機能は備えていません。
今回はこのツールが採用となったのですが、決め手となったのは「登録時にCSVの文字列を事前変換する機能」があったことです。例えば、価格などの「数値フィールド」でありがちな「CSVデータにカンマが入っているとインポート時にkintone側でエラーになる現象」への対応が可能です。

設定画面でカンマ文字の削除設定をすれば、CSVデータの数値欄にカンマが入っていても取り除いた(10,300 → 10300)状態で、kintoneに登録してくれます。

カンマを取り除く文字列置換設定

この機能がないと、あらかじめCSVファイルを開いてカンマを取り除くことが必要が出てきてしまうため、登録作業自体に人手を介すことになってしまい、今回の要件を満たすことができませんでした。

もう一点はコストです。初期費用9万円+年間料金も9万円ということでその他のツールと比較するとリーズナブルという判定でした。

基幹連携ツールPro

最後は日立ケーイーシステムズが提供する「基幹連携ツールPro」です。機能面では他3社とほぼ同じで、事前の文字列編集機能は、四則演算、空白除去、桁合わせ、自動採番、文字列結合が可能ですが、特定の文字を削除する機能はありませんでした。
コスト面(初期費用36万円、年間12万円)もネックとなり今回は見送りとなりました。

 

番外編 その1
異なるデータ間を連携するツールは以前から「EAI / ELIツール」という分野が存在します。
これらのツールでももちろんCSVファイルをkintoneに取り込むことはできますが、コスト面で「桁が違う」ため今回は検討には入りませんでした。(一般的に企業内に多数のシステムが存在する大企業向けのツールなため機能も値段もそれなりです)

代表的なツールとしてはアステリア社のASTERIA Warp や、セゾン情報システムズのDataSpiderがあります。(ちなみにDataSpiderはセゾン情報にM&Aされる前はアプレッソという独立系のIT企業で、CEOの小野さんという方には技術者としてかなり影響を受けた一人です😊)

番外編その2
CSVをkintoneにインポートするのにRPAツールを使うという選択肢もあります。手動でのkintoneアップロード画面をRPAで操作するシナリオを書くことで実現できます。

ただし、私の経験上、APIを備えている製品(kintone)との連携ではRPAツールは使わない方が良いとの考えです(RPAはあくまでAPIが使えない製品に対してのみ、限定的な条件下で使うべきです)。

開発の初期費用はともかく、運用中のメンテナンスに掛かるコスト(RPAはその性質上さまざまな環境変化に影響を受けます)を考えると、素直にAPIを叩くか、APIを使うツールを採用する方がトータルコストを抑えることができるからです。(RPAの適用シーンについてはおいおい記事にしていきたいと考えています)

ーーー

いかがでしたでしょうか。
一口に「CSVファイルとkintone連携」といってもその用途や要件により採用するツールが変わってきますので、各社のトライアルライセンスなども試しながら最適なツールを選択していただきたいと思います。

#画面ショットは各社のH Pから転載させていただきました

士業向け開業支援パック 「カイギョウ」をリリースしました

現在、弁護士事務所や社労士事務所のIT顧問を行なっていますが、今時のお客さまは色々と勉強されていて、様々なクラウドサービスを利用されているケースが多いです。
ただ裏を返すと所内のクラウドサービスがサイロ化しており、情報管理やコミュニケーションが散在しているケースも多いです。
このような現場に途中から入って、各種サービスを整理することも多いのですが、実際に始めてみるとなかなか大変な作業です。
一通り整理し終えて所内の情報がスッキリし出すと「こんな事なら開業時に初めからお願いしたかった」との声を多くいただきます。
ということでこの度当社では新サービス「カイギョウ(士業向けの開業支援サービス)」をリリースしました。もちろんクラウド100%です。
各種アカウント設定などの初期設定、操作方法、使い分けなど、開業当初から所内のスケールに合わせてご提案します。IT専門家が顧問のようにいるつもりでいつでも相談可能です。
ただでさえ忙しい開業準備、IT周りを丸っとお任せいただけます。

「カイギョウ」の支援内容

ITインフラ(ファイルサーバー、メール、自社ドメイン管理、カレンダー)
Google Workspace を利用します。これはグーグルの各種サービスを法人向けにパッケージしたもので、マイクロソフトなどの類似サービスと比較して管理システムがシンプルで高機能。これ一つで基本的なITインフラは全てカバーできます。1名600円/月
オンライン会議
Zoomがおすすめです。シンプルな操作性と相手側の利用シェアも高いです。
TeamsやGoogle meetは多機能すぎるのと品質もZoomと比較すると見劣りします。
顧客、案件管理などのCRM/SFA
kintone がおすすめです。
よく比較される Salesforce は元々が大企業向けということもあり、機能が多すぎてかつ高価なので使いきれないケースが多いです。
契約、蔵書、備品管理などの台帳管理
kintoneがおすすめです。自社の業務に合わせた各種台帳が手軽に作成できます。
チャットや情報共有
こちらもkintoneがおすすめです。チャットワークやSlackもありますが、チャットツールはどれか一つに絞らないと情報が散在して「あれどこに書いたっけ?」という事になってしまいます。
顧客管理や台帳管理にkintoneを採用したならば、チャットもkintone上でやれば情報が集約化できますし、コストもかかりません。
kintone使用料金 1名1500円/月
「カイギョウ」サービスは、上記利用料に加えて、初期費用10万円、IT顧問料3万円/月(所員10名まで)で承ります。
初期費用内で、上記の環境設定、アカウント設定を行い、IT顧問料の中で継続的に各種設定変更やアカウント追加作業を行います。
また、自社向けにカスタマイズしたアプリを作りたい場合も、顧問料の中で相談をお受けします。
クラウドツールは利用の手軽さから手軽に始めてしまえますが、実際に運用を始めると各サービスとの整合性を取ることが難しく、開始前にきちんと整理して導入しないとせっかくの便利ツールが誰にも使われないといった状態になりかねません。
カイギョウでは自社の利用シーンや課題に合わせた提案から導入、運用までをトータルにサポートいたします。

RPAの本質を見極めて「業務プログラマ」を育成すべし

2019年ぐらいからIT業界のバズワードとなった「RPA」ですが、安易に導入すると現場の負荷を高めてしまい想定の効果が出せない結果になります。
導入当初こそうまくいったように見えたRPAも、運用保守フェーズにはいって2年目、3年目に入ると、基幹システム側の変更によるシナリオ変更や、RPAツールのバージョンアップによる再テストなど、トータルコストが見合わなくなる可能性が高いです。
社内の偉い人が「働き改革をなんとかせんといかん、RPAが効くらしい、検討せよ!」というメッセージを現場に投げて、なんだか分からないうちにRPAツールを使うことが目的化し、余計現場が疲弊してしまうという悲劇が既に日本中で起き始めているようです。
コンサルティング会社やITベンダーも、自分自身すらよく使ったことがないものを、さも最先端技術のような見せ方をして販促している例も散見されます。嘆かわしい限りです。
業務現場の自動化、というRPA自体の考え方は全く問題ありませんが、それをRPAツールという手段だけで解決しようとする今の流れは危険としか言いようがありません。
RPAという業務の自動化を進めるにはどのような手段が適当なのか、RPAツールは手段の一つにはなりえますが、本質をわかった上で利用しないと冒頭説明した運用地獄に陥ってしまいます。
ではそもそもRPAツールとはなんなのか、という話です。
RPAツールは、Windows OS上で動くエクセルや業務アプリケーションを、OSのインターフェース経由で操作を可能にしたツールです。これにより、これまではマウスやキーボードといった入力インターフェースを経由しないとできなかったアプリケーションの操作を、あたかも人が操作するように自動的に動作させることができるのです。
今まで人がパチパチと人の手で操作するしかなかったアプリが、キビキビと自動的に処理をすすめる様子を見た業務現場の人は「なにかスゴイ技術が開発され世に出てきた!」と思うようですが、これまったくの誤解です。
技術要素という面では、20年以上前から同様のことは実現可能でした。しかも無償のツールでです。
それはVBA(Visual Basic)やPythonというプログラミング開発環境です。マイクロソフトはOfficeにバンドルさせてVBAを配布していますが、これによりRPAと同等のことが行なえます。
エクセルのマクロという言葉は聞いたことがあるかもしれませんが、それをより高度化したものがVBAやPythonです。マクロがやってるのはエクセル操作の自動化ですよね?あれと同じようなことが、他のアプリケーションでもVBAを使えばできるのです。
つまりわざわざRPAツールを買うこともなく、業務の自動化はVBAを使えばできるのになぜVBAを使った自動化は広まらなかったのか。それはVBAで自動化を行うにはプログラミングが必要だからです。この敷居の高い「プログラミング」の必要性が自動化を阻んできたのがこれまでの業務現場でした。
そしてこの「プログラミング」を必要とせずに自動化を実現するツールとして出現したのがRPAツールです。RPAツールは「ノンプログラミング」で「GUIでフロー図を作るだけ」で業務アプリの自動処理を実現する、という触れ込みで昨今のRPAブームが出現したのです。
そしてこのコンセプトが働き方改革ブームとうまくマーケティング的な相乗効果が発生して今日のRPAブームに繋がったといえるでしょう。
たしかに、簡単な処理であればプログラミング経験のない人でもRPAで「自動化っぽいシナリオ」は作れます。しかし、実際の業務現場で使えるシナリオを作るには、変数の考え方、ループ処理や条件分岐、エラー処理などのプログラミングの知識が無いと、実用的な自動化ロボットは作成できないという事実があります。
実際、この概念なしに業務で使うシナリオを作成しようとして大きな壁にぶつかったか方も多いのではないでしょうか。
シナリオ作成を業者に依頼することもできますが、基幹システム側の変更やRPAツールのバージョンアップによる修正やテストなどのたびに、業者に高いコストで依頼する必要が出てくるでしょう。
そうなるとやはり自社でRPAのツールを使いこなす人材が必要になります。そしてRPAを使いこなせるスキルとは、プログラミングスキルそのものですので、わざわざRPAツールを導入するよりも、VBAやPythonで作ってしまったほうがコスト的なメリットは出せるでしょう。加えて、RPAツールに依存する部分を減らせるので運用保守に掛かるコストも減らせることができます。
職業プログラマレベルのスキル(例えばDBやWebサーバの知識)までは必要としない「業務プログラマ」を育成することが真の意味でのRPAを実現する鍵となるのです。業務プログラマであれば経営が意思入れをすれば育成のハードルはそこまで高くありません。
今後確実に到来する「RPAへの失望期」の先には、こういった業務プログラマを育成するマーケットが生まれていると予想しています。そして企業内の業務プログラマはデジタル人材として重要なモデルになっていくでしょう。

Shopify Webhookが複数回飛んでくる等のナゾ

Shopifyとkintoneを連携させて軽量なMAができる環境を構築している。

Shopifyの購買データをkintoneに連携したり、kintoneで追加した顧客や商品データをShopifyに同期するなどをお互いのAPIを使ってやり取りしている。

Shopifyは顧客や注文のイベントが発生するタイミングでWebhookを発火するので、これを拾ってkintoneに登録する。

ShopifyのWebhookを使っていて一部ナゾ的な動きがあるのでまとめてみる。

  1. 同一IDのWebhookイベントが複数回発行される
    1. 1、2分おきに3回ほど同一のWebhook(例えばorder/create)が呼ばれる
  2. イベントの時系列は保証されない
    1. order/createが呼ばれてからのorder/paidが呼ばれる、と思っていたがどうやら順不動でくるよう

Shopifyのドキュメントを読むと上記は仕様のようだ。しかも「Webhookの発行自体が保証されないので定期的に不整合ができていないかチェックしてね」とも書いてあった。

ということで、一度テンポラリのWebhook置き場を設けて、そこを定期的に見に行くような仕組みが必要そうになった。

また一定期間でShopifyとkintoneの不整合部分を監視するような仕組みも必要ですね。

DBは増やしたくないので、上記2個ともkintoneのアプリを使ってできないかお試し中。

この辺りのベストプラクティスが知りたい。

Shopify APIで商品登録

Shopify熱いですね。

当社では顧客や在庫、商品などの管理情報はkintoneで管理してそれをShopifyに連携するケースが多いです。

今回はkintoneで商品登録(編集)されたデータをShopifyに反映する機能をPython/JSで実装しました。

動作としては、kintoneの商品登録アプリが変更されるとWebhookがAWS API Gatewayに飛んで、そこからShopifyのAPI経由で商品を登録(編集)します。

Shopifyの商品登録において価格情報はvariantというオブジェクトに登録する必要があります。

ですので、一旦Productオブジェクトで新規の商品を作って、variantに価格をセットしてアップデートします。(これ、ワントランザクションでできる方法知ってる方いましたがプリーズ教えてください)

 

EventBridge経由で受けたShopifyのWebhookはVerifyすべきか

結論としては「不要」とのことです。

APIGatewayとEventBridge経由のLambdaのeventの中身が異なっており、APIGatewayで受け取ったbody部分がEventBridge経由は別物(payload)となっており、そもそも検証できずハマっていたところ、下記の回答を見つけることができました。やれやれ。

Just wanted to provide an update to this issue.
There is no need to validate HMAC with EventBridge. Only Shopify is able to produce events into the partner event source that you would have configured in the App Setup for your app.

For anyone still doing the validation and having issues with some webhooks, we’re currently trying to resolve an issue with Amazon and json encoding that in some cases causes an issue with the generated HMAC.

It’s best to simply remove HMAC validation for EventBridge and Pub/Sub deliveries as these are both considered trusted delivery channels. Only HTTP webhooks require HMAC validation.

https://community.shopify.com/c/shopify-apis-and-sdks/amazon-eventbridge-webhook-verification/td-p/891705

 

Shopify APIのトークンを取得するまで(2021/9 Python版)

kintoneを情報基盤にした業務効率化支援をしていますが、最近業務効率化のその先にある「売上向上」を目的としたkintone活用の相談が増えてきています。

今回のクライアントは今流行りのEコマースSaaSである「Shopify」とkintoneを連携させて、顧客と商品管理をkintoneとShopify間で同期させたい、ということでした。

kintoneとShopifyには豊富なAPIが用意されており、いつもの通りAWSを中間サーバーにすれば要望の機能が果たせそうです。

今回は事前調査としてShopifyのストアにカスタムアプリを導入してそのカスタムアプリを通じてデータをIN/OUTしてみましたが、最初のOAuth認証部分が想像より大変だったので今後のためにもメモしておきます。公式ドキュメントなどそこそこ文献は揃っていましたがバージョンが古かったりして手こずりました。

また認証はできたものの、謎の動きの理由が残ったままなので継続調査が必要です。とりあえずトークンだけ取れればいい、という場合は以下の手順を参考にして下さい。

Shopifyアプリの作成

shopify-cliというコマンドラインでShopifyを操作できるツールをインストールします

$ brew install shopify-cli

カスタムアプリを作成します

$ shopify node create

この時点でShopify PartnerのWeb管理画面には作成したアプリが表示されているのでそのAPIキーとAPIシークレットをメモしておきます

作成されたプロジェクトフォルダに移動します
$ cd test-app

$shopify node serve  を実行して認証用のコールバックサーバNGROKを起動します
NGROKはローカルに仮のSSLコールバックサーバを立ててくれるサービスです(雑な説明)
Do you want to update your application url? はYes と回答します

To install and start using your app, open this URL in your browser:
https://6972-240f-74-2d17-1-3927-87d0.ngrok.io/auth?shop=xxxx.myshopify.com

上記の表示が出るので、開発ストアにインストールします。

そうすると自動的にWebの管理画面のリダイレクトURL欄にNGROKのURLが登録されています(便利ですね)

OAuth認証の用意が整ったのでトークンを取得します。

トークンはPythonのShopify APIを利用します。

https://github.com/Shopify/shopify_python_api/blob/master/README.md

$ pip install –upgrade ShopifyAPI

Python
shopify.Session.setup(api_key=API_KEY, secret=API_SECRET)
state = binascii.b2a_hex(os.urandom(15)).decode(“utf-8”)
redirect_uri = “https://xxxxxxxx.ngrok.io/auth/callback”
scopes = [‘read_products’, ‘read_orders’]

newSession = shopify.Session(shop_url, api_version)
auth_url = newSession.create_permission_url(scopes, redirect_uri, state)
print(auth_url)

上記を実行して表示されたURLをブラウザから実行して、ユーザー認証します。

どハマりポイント1
このままいけばURLにcodeが表示されるはずなのですが、何回かリダイレクトした後NGROKの画面はきちんと出てくるものの肝心のcodeが取得できません。色々試行錯誤した結果、NGROKを落とした状態で再度ユーザー認証すると途中でリダイレクトが終わってcodeが取得できました。。。

どハマりポイント2
やっとcodeが取れたのであとはトークン取得するところでまたまたエラーとなってしまいました。

Python
access_token = session.request_token(request_params)  # Error

どうやらaccess_token = session.request_token(request_params)の関数の中でパラメータ(code / timestamp / hmac)のverifyがうまくいっていない模様です。

そこで、こちらのドキュメントにPOSTで取得する方法が載っていたのでやってみると。。。
https://shopify.github.io/shopify_python_api/

POST https://SHOP_NAME.myshopify.com/admin/oauth/access_token

with the following parameters:
client_id – Required – The API key for your app
client_secret – Required – The shared secret for your app
code – Required – The code you received in step 3

Python
url = “https://{}.myshopify.com/admin/oauth/access_token”.format(shop_name)
_header = {“Content-Type” : “application/json”}
PARAMS = {“client_id”:API_KEY, “client_secret”:API_SECRET, “code”:code}

resp = requests.post(url, headers=_header, json=PARAMS)
r = json.loads(resp.text)
at = r[“access_token”]

見事トークンが取得できました!

取得できたはいいものの何故動いているかが分からないので、ちょっとこのままでは使えそうにないです。継続調査が必要ですね。どなたかわかる方いれば〜〜。

なお、実ストアへのインストールは管理画面から「マーチャントインストールリンク」を発行して、ストアのアカウントでログイン後、このリンクでインストールを承認します。パートナーでログイン中のブラウザでこれをやろうとするとエラーになるので、ブラウザをあたらに起動して実行します。

参考にしたURL
https://dev.classmethod.jp/articles/shopify-with-eventbridge/

https://shopify.github.io/shopify_python_api/

 

kintoneのコメントをTeamsに連携する

kintoneを導入されている会社さんを何社かみていると「通知」をうまく使えていない企業が多いことに最近気づきます。
kintoneの通知には2種類あり、ポータル上に表示される通知(左上のベル)とメールによる通知があります。
kintone上で全ての情報のやり取りを行い、タスクが完了するたびに常にベルに表示される通知を消し込んでいく方法が理想的ではありますが、現実には企業内にはkintone以外の様々なツール(チャットワークとかSlackとかConfluence / Salesforceとか)が存在しているので、やはりメールによる通知を使うのが現実解のようです。
しかし、ただでさえメールが溢れかえっている現場にkintoneのメール通知が増えだすとそれだけで拒絶反応が返ってくることが多いようです。
こうした現場には、そもそもの「メールの使い方」からレクチャーしていく必要があります。
具体的には「受信トレイ」には自分のタスクしか残さないようにすることです。自分のタスク以外のメールはアーカイブするか他のフォルダに移動します。
特にkintoneやチャットワークなどの通知メールは「なんか来てるな」ぐらいの感覚で「DELキーで即ゴミ箱行き」が正しい使い方です。
こうすることで受信トレイはTODOリストだけになりスッキリ、kintoneにアクセスしたらベルの通知をみてタスクを処理していけるのでメールとkintoneが共存できます。
ただ最近はTeamsの存在が大きくなってきました。Teams自体は決して使いやすいツールだとは思いませんがあのマイクロソフトがガンガン世界展開しているため、ジワジワと企業内のシェアを伸ばしています。Slackのシェアを抜き去ったのも最近のことでした。
そしてこれに伴って「kintoneの通知をTeamsに連携したい」という要望も増えてきました。今回はその事例をご紹介します。
TeamsはWebhookでメッセージを受けることができるため、kintoneのWebhookとAWS Lambdaを組み合わせることで定期的にkintoneの通知をTeamsに流していくことができます。
kintoneのコメントの書き込みイベントは用意されていないため、Lambdaから定期的にkintoneレコードのコメントを取得します。
取得したコメントはそれを保存するための「コメント管理アプリ」に登録していきます。この時、コメント管理アプリのWebhookを使ってLambdaにレコード追加イベントを発火します。
Lambda側で受け取ったイベントを元に、コメント管理アプリからTeamsに必要なコメントを取得して、今度はTeamsのWebhookへそれを通知します。
今回のケースでは、kintoneのメンション宛先に従って、TeamsのどのTeamにメッセージを振り分けるかやコメント内容の変換方法など、細かい要望にも対応しました。
TeamsのWebhookはアプリを追加することで簡単に取得できます。
LambdaからTeamsにコメントを飛ばすには以下のコードでできます。シンプルですね。
title = “ここにタイトルを書きます”
text = “ここに本文を書きます(例えばkintoneのコメント)”
payload= {
   title:title,
   text:text
}
webhookUrl = “{Teamsで取得したURL}”
r=requests.post(webhookUrl, json=payload)
様々なツールの通知先を一元管理したいというニーズは多いので、より汎用的に使える”コメントハブ”のようなツールは今後どんどん出てきそうです。ただ最後はどうしても企業や業務現場に合った通知方法が求められるため、今回のような細かい要望に対応できるカスタマイズも一定のニーズは残りそうです。
ーーーーー
追記:
kintoneアプリのWebhookに「コメント書き込み時」というイベントがあることがわかりました(なんたるドジ)。
このため上記のような構成ではなく、kintoneのwebhook -> Lambda -> Teams というよりシンプルな構成で実現できました。

sam build –use-container でResolveDependenciesエラー

sam build –use-container をすると下記のエラーが発生。

Running PythonPipBuilder:ResolveDependencies
Error: PythonPipBuilder:ResolveDependencies – {protobuf==3.17.1(wheel)}

sam build –use-container –debug の結果を調べつつ色々とハマっていたが、どうやらgoogle apiの中で使っているprotobufというモジュールの互換性が合わないようだ。

protobufのリリース履歴を確認しつつrequirements.txtで指定するバージョンを下げたら

protobuf==3.15.8
でbuildが通るようになった。
お役に立てればこれ幸いです。

キントーンの受注データをマネーフォワードへ連携する(kintone to Moneyfoward)

あるクライアントさんで「キントーンの受注データをマネーフォワードへ連携して請求書を作りたい」というご要望。
kintone – MoneyForward連携はすでにプラグインサービスとして存在するのですが「初期費用10万円、年間18万円で途中解約不可」というなかなかのお値段設定のため当方に相談がありました。
キントーンはライセンス料が大変安価でお得なクラウドサービスですが、ことサードベンダーが出すプラグインはその価格差が目立ってしまうほど高く感じます。(本体よりオプションが高いんかい!という声をよく聞きます)
しかし、ベンダーサイドからすると、開発や保守コストを考慮すればこれらの価格も決して高いとは言えない実情もあります。
キントーンが安すぎる故にプラグインの高さが目立つ、という構造があるのです。
要因としては、キントーンはビジネスとしてすでに「クラウドの谷」を抜けており、あとは売れば売るだけ儲かる利益構造のため、サイボウズ社としては広く薄い商いが可能となっていることが挙げられます。いわゆるストックビジネスが完成されている。
また、サードベンダーも会社規模が大きくなるほど自社のビジネスボリュームに応じたプライシングをする必要があったりという内情もあります。(実はお安く提供できるプラグインも、社内のお偉いさんから「そんな安い金額でうちのビジネスになるかいっ!価格上げろ!」と言われるパターン)
ですので、現在キントーン界隈でウケている(売れている)プラグインは、これまで聞いたこともなかったような個人や数人規模のベンダーであるケースが多くなっています。彼らは規模は小さくてもその技術力で良質なプラグインを安価に提供できるためです。
例えば当社では、今回の連携システム規模であれば、初期費用1〜2万円、月額5,000円〜10,000円程度で提供しているほどです。
業界的にあまりにも廉価なサービス提供はITビジネス全体を阻害する、という声もありますが、需要と供給で価格が収斂されていく経済原則には逆らうことができない時代がきているのかもしれません。こうしたITの民主化により、特に図体が大きくて個々人の技術力(作る力)がないベンダーは今後ますます淘汰が進む気がしています。
今回の開発のポイントは、マネーフォワードのAPIがOAuth認証であり、キントーンとマネーフォワードの間にAWS Lambdaをかまして、認証トークンの受け渡しとトークンの有効期限をリフレッシュする機構を構成したことです。(トークンの保存場所はDynamoDB)
これにより、キントーンの受注アプリで「請求書ボタン」を押すと、請求対象のレコードにおける受注データがLambdaに飛んでいき、マネーフォワードへ請求書作成要求がされるようになります。
これまでキントーンからマネーフォワードへ受注データをコピペした作業が不要になり、キントーン上から簡単に請求ステータスが確認できるようになった事例でした。
追記:
MF連携に関して多くのお問合せいただきありがとうございます。こちらのコメント欄に記載いただければ折り返しお返事いたします。その後、Zoomで概要確認 -> お見積り -> ご発注後1.5ヶ月程度で利用開始、という流れが標準的です。
Social media & sharing icons powered by UltimatelySocial