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

現在、弁護士事務所や社労士事務所の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ヶ月程度で利用開始、という流れが標準的です。

VSCodeのAWS Toolkitで特定のパッケージが読み込めなくなってしまったメモ

VSCodeのプラグインであるAWS Tookkitを使ってlambdaのローカルでバッグやデプロイを快適にしていたのだが、特定のパッケージが読み込めなくなってしまった。かなーーりハマったのでメモ
エラー内容
Building SAM application…
Running command: (not started) [/usr/local/bin/sam build –build-dir /tmp/aws-toolkit-vscode/….
Building codeuri: . runtime: python3.8 metadata: {} functions: [‘funcname’]
Running PythonPipBuilder:ResolveDependencies
Build Failed
Error: PythonPipBuilder:ResolveDependencies – {python-docx==0.8.10(sdist)}
今回はたまたまpython-docxでつまづいたがググるといろいろなパッケージでも同じような現象が起きている模様。
解決策は「AWS Toolkitを使うのをやめてコマンドラインで実行」でOK。(おそらくToolkit内のバグ)
ビルド
sam build –use-container
[–use-container] が超ポイント。Docker コンテナ内でビルドをしてくれるようになる。
ローカル実行
sam local invoke funcname
デプロイ
sam deploy -g
その他のsam関連のコマンドがこちらにとってもわかりやすくまとまっていましたのでシェアしておきます。
今回の教訓:
複雑なコマンドをうまく隠蔽してくれるツールはとっても便利ではあるが、一枚レイヤーが被さるということはそのレイヤーの中身にも責任が生じる、ということ。
ツールの開発者も「なんかあったらコマンドでやれや」という心理があるやなしやで問題も放置されがちなんでしょうね。
おそらくRPAも同じ問題内包しているはず。ノンプログラミングで〜はいいけど、いざ何かあったらRPAツール自体のバグに苦しむケースが多そう。
RPAをバージョンアップしたらしたで全シナリオのテストどうすんの?などいろいろ闇が深そうである。
できるだけネイティブで行こう。
Social media & sharing icons powered by UltimatelySocial