kintone Advent Calendar 2023の21日目の記事です。
皆さん、kintone使ってますか！？
このページをご覧になっていると言う事は使っているはずですよね。
ユーザーとして利用する方、業務改善の道具として使う方、開発者として沼っている方、メシの種にしている方。それぞれだと思います。
システム開発に共通ですが、kintoneを使っていると、なんでや？と言うはまりポイントがあります。そのはまり方と、そこからの抜け出し方について、先日二つほど良い事例に出会いしました。
なお、本稿の内容は技術者として豊富な経験を積んでいらっしゃる方にはたわいもないものかもしれません。
が、システム開発に携わるのがkintoneが初めて、という方もいらっしゃるはず。そういう方向けに本稿を書いてみました。
２．cli-kintoneではまる問題
一つ目の事例はcli-kintoneです。
皆さん、cli-kintoneは使ってますか？
コマンドラインからkintoneのデータを任意の場所に出力できます。添付ファイルも。
また、任意の場所のcsvファイルをkintoneにインポートもできます。もちろん更新も。
バッチ処理もできるのでとても重宝します。
cli-kintoneサイト
普通の環境であれば、cli-kintoneはすぐに使えるはずです。
が、とあるお客様の環境では、これが全くつながらなかったんです。
このようなエラーに弾かれていました。
[2023-12-01T09:00:00.000Z] ERROR: error: Client network socket disconnected before secure TLS connection was established
[2023-12-01T09:00:00.000Z] ERROR: AxiosError: maxContentLength size of Infinity exceeded
[2023-12-01T09:00:00.000Z] ERROR: error: 403: Forbidden
[2023-12-01T09:00:00.000Z] ERROR: error: unable to verify the first certificate
そのお客様の環境は、ビルから外に出る通信はまず設置されたファイアウォールによって制限されます。さらにインターネットを経由する通信は離れた場所にある情報センターを必ず通ります。そこではProxyサーバーが設置されています。
kintoneにはBasic認証、id/pw認証に加え、ipアドレス認証またはセキュアアクセスも使っています。要するに厳重な防備が敷かれているのです。
これらのパラメーターの値を変更することで、上記のエラーは変わります。
こういう場合、通常ならば情報センターに問い合わせをします。エラーになった時間帯のパケットの調査を依頼し、何の設定値がおかしいのか、何がパケットの通信を阻害しているのか。
端末からkintoneサーバーまでとその逆の通信経路を追っかけます。
ところが、膨大なパケットを日々扱っている情報センターに対し、ログを取って欲しいと安易に調査依頼をすることはできません。
かといってこちら側のエラーメッセージも原因を追求するにはあまりにも不十分なものです。コマンドプロンプトからpingコマンドやtracertコマンドやnslookupコマンドを打っても根本的な解決にはなりません。
そのため、解消にかなりの時間をかけました。五里霧中を歩むがごとき。
３．問題解決のケース１
この時に私が採った問題解決手法は総当たりです。
問題解決の手法では山登り法と呼ばれるものに近いかもしれません。
cli-kintoneにはたくさんのオプションが設定できます。ユーザー認証情報、basic認証情報、proxy設定情報、証明書情報。
それらを全パターンの組み合わせで調べ、どの組み合わせパターンだとうまくいがないかを一つ一つ潰しました。
もちろん、そもそもの設定値が間違っているとつながらないので、それらは可能な限り知見を持つ方に事前に聞きました。
その甲斐あって、無事にcli-kintoneで接続に成功しました。
ただ、ここで言っておくべきは無闇矢鱈に試したわけではないことです。
上に書いた通り、cli-kintoneの公式サイトには接続にあたってのオプションが全て載っています。（–helpオプションに出てくるコマンドのうち先頭の二つはサイトには載っていませんが）
つまり、最初から試すべきパターンの上限枠は用意されているのです。後はこれらに基づいて組み合わせを試すだけ。
こうした総当たりを試すしかないパターンは、システム開発ではたまに起きます。
もし、五里霧中でどうしようもなくなった時も、ありうる組み合わせを全て試せば、必ず答えがあります。
総当たりを試す場合の判断基準は以下のとおりです。
・有識者から正しい設定情報を入手できること。
・パターンの上限を見定め、実行可能であること。
・自らのリソースで実行可能であること。
・システムに負荷がかからないこと。
・失敗によるデータ破損紛失の恐れがないこと。
それらが満たせれば、あとは根気よくパターンを試すのみです。
kintoneはプラットフォームです。幸いなことによほどのことがない限り壊れません。安心して試してください。
そして、kintoneもcli-kintoneもきちんとテストされた上でリリースされています。
設定値さえ正しければ、必ず何かのオプションで状況が打開できるはずです。
ぜひ頑張ってください。
ここでの問題解決の方法は、
・有識者から正しい設定情報を入手する。 ・・・正しい情報
・パターンの上限を見定める。 ・・・解決手段の見積
・システム負荷、データ破損を防ぐ。 ・・・影響範囲の確定
４．kMailerではまる問題
続いて二つ目の事例は上の件と同じ日に問題解決しました。kMailerについてです。
トヨクモさんのkMailerはkintoneからメールを送ることのできるサービスです。
メールテンプレートアプリを設置し、メール履歴アプリを設置し、アドレス帳アプリを設置します。
メールテンプレートアプリや送信履歴アプリ、ログアプリはトヨクモさんがテンプレートを用意してくださっています。
テンプレートアプリについて
あとはそれらをkmailer専用の管理画面から設定し、生成されたJavaScriptをkintoneのアドレス帳アプリに組み込むだけ。
メールテンプレートアプリは、各レコードにメールのテンプレートを保存できます。
メール送信画面で、設定したメールテンプレートを呼び出し、必要に応じて手を加えれば、アドレス帳のレコードに応じた送信先にメールが送信されます。アドレス帳アプリの任意の項目の値をにタイトルや文面に差し込むこともできます。
とても便利なサービスです。
製品サイト
お客様が送りたいメールはビジュアルを整えた形。クリスマスメールが送りたいの！
当然、メール内には季節感あふれる画像も添付します。つまり、HTMLメールです。
メールテンプレートを設定する際も、HTMLメールを前提にビジュアルを整えたい。それは当然ですよね！
ところが、トヨクモさんにご用意いただいたメールテンプレートアプリの中にある本文を格納するフィールドは＜文字列複数行＞フィールドです。
＜文字列複数行＞フィールドだと、見栄えが整えられません。そこで私はフィールドコードを変更した上で本文を＜リッチテキスト＞フィールドに格納するように変更しました。
これにより、お客様がメールテンプレートアプリで見栄えを整えられるようにしました。あとはメール送信画面からテンプレートを呼び出し、必要に応じて微調整を行ってもらえます。
お客様のご要望を満たせてばっちり！
・・・とは、いきませんでした。
まず、一つ目の問題。
お客様のご要望は、ビジュアルのメール本文に画像を含める事でした。
ところが、kintone上の画面上では画像が添付できるのに、保存すると画像が消えてしまいます。＜リッチテキスト＞フィールドを普段使っていない私の無知がばれてしまいました。
ということは、お客様は毎回メール送信画面上で画像を添付し直さなければなりません。これは大変。
しかもテストメールを送ってみたところ、添付されている画像の代わりにエンコードされた文字列が延々と連なっています。
いやぁぁぁぁぁぁぁ！！もはやホラーです。
ホラー以前にそもそもメールとしての根本からあり得ない状態です。それでいながら、宛先によってはきちんと画像付きのメールが送信できているのが謎。
二つ目の問題は、項目の差し込み機能がうまく動かないことが発覚したことです。
メール送信画面ではアドレス帳アプリの任意の項目を画面から差し込めます。
項目を差し込むことによって同じ文面のメールを送っても、差し込み項目の値に応じてメールの文面は変わります。名前とか。
差し込み機能は多くのお客様にメールを送信するお客様にとっては欠かせない機能。ところが、この差し込み機能がうまく動かなかったのです。
メール送信画面上で差し込み設定するときちんとレコードの値が差し込まれるのに、メールテンプレートアプリから持ってきた本文の差し込み設定が効かず、メールのプレビューにはカッコつきのまま表示されてしまうのです。
{{姓}} {{名}} 様
のような感じで。
これだと、メールテンプレートアプリが活用できません。そして、お客様は毎回メール送信画面から差し込み設定と画像添付設定をし直さなければならない。これは問題です。
５．問題解決のケース２
この疑問をXにポストしてみたところ、トヨクモのとある方が拾ってくださいました（感謝！！）。そしてしばらくやりとりさせてもらいました。すると、理由が解決しました。
要するに、私がメールテンプレートアプリ上で本文を格納するフィールドを＜文字列複数行＞から＜リッチテキスト＞に変えたことが一連の不具合の理由のようです。
私の失敗としては、以下の文章を読み逃していたことです。
「メールテンプレートアプリは、アプリテンプレートの構成のまま利用することを想定しており、変更を加えた場合の挙動は保証しておりません」
ちゃんと書かれてる！ 私がここを見逃していたことが全ての敗因でした。
なお、一連の不具合については、メールテンプレートアプリの本文を格納するフィールドを＜文字列複数行＞にもどしたことで解消しました。
ただし、まだ問題が残りました。
それは、メールテンプレートアプリにビジュアルのメールを設定できなければ、お客様の効率が著しく落ちる点です。
お客様はHTMLタグが分かりません。そのため、お客様によるメールテンプレートの設定は不可能です。
また、kMailerの「ホーム > メールテンプレート一覧」からはHTMLプレビューも可能です。が、お客様にはできる限りkintone内で完結していただきたいと思うのは人のサガ。
送信予約を見るときはkMailerを使わざるを得ないとしても、kintone側でメールテンプレート作成から送信先のレコード抽出、メール送信までを一気通貫でやり切りたい！
そこで、今回は、私の方でメールテンプレートアプリのレコードを保存したタイミングで、
＜リッチテキスト＞フィールドの内容を＜文字列複数行＞フィールドにHTMLタグ付で転記するJavaScriptを作りました。
それによって、お客様がビジュアルのメールをご自身で構築できるようになりました。
また、画像についてはレイアウトがだいたい決まっていました。そのため、オンラインストレージ上に該当する画像を格納してもらい、メールテンプレートアプリの本文の <img src=””> タグにそのurlを設定することで解決しました。
このファイル名は常に同じにしてもらうか、または、下図のようにメールテンプレートアプリのリンク項目を入力してもらうようお客様に依頼しました。ストレージから得られた共有urlはそのままでは使えないため、変更してもらうための注記を加えた上で。
まずは無事にクリスマスメールが送れそうです。よかったよかった。
さて、反省しなければ。
私の反省は、
・kMailerのサイトを熟読していなかった。
・予断に基づいた構築に走っていた。
・kintoneの柔軟性を過信していた。
でしょうか。
ここでの問題解決の方法は、
・基礎となる情報ソースを読み返す。 ・・・基礎情報の重視
・自らの予断を見直す。 ・・・認知バイアスの修正
・有識者からの助言を得る。 ・・・多面的な視野
この３点です。
６．kintoneで一度開発してみてください
他にも、kintoneでトラブるケースはたくさんあります。
・ユーザーの要望をまとめないままに実装に走ってしまい、ヒアリング不足で変更・追加要望が土壇場で相次ぐ。
・kintoneの性能を甘く見積もっていて、特定の端末でしか限界値テストをせず、本番でトラブる。
・ユーザーの要望に対して過度なカスタマイズをしてしまい、あとで自分の首が絞まる。
どれもが、かつてやってしまったことのある失敗です。
全て、ひいひい泣きむせびながらリカバリーしました。汗顔のいたりです。
ですが、これからkintone開発に入っていただく方は、安心してください。
kintoneはプラットフォーム上で動きます。自分でハードウエアや基盤を用意する必要がないのがkintoneの良さ。簡単には壊れません。いろいろと試して、経験値をためていける環境がすでに用意されているのです。
ただし、ドキュメントはきちんと読んでくださいね。
さらには、システム構築の思考フレームワークというべき「kintone SIGNPOST」もあります。
kintone SIGNPOSTページ
この考えはkintoneだけでなく、既存のシステム開発でも活かせます。システムが無縁でも業務改善に役立ちます。
また、なんといってもkintoneには多くの開発者やユーザーがいます。そうした方々が豊富な知見を日々あちこちでアップしてくださっています。つぶやきで動画でブログでセミナーでユーザー会で。
たまに、この記事のようにしくじり先生よろしく失敗談を書いてくれる人もいます。
ぜひ、kintoneを使って業務改善の当事者として、システム開発の当事者として楽しさを味わってください！
西山さんの登壇内容も、真鍋さんの登壇内容も、小林さんの登壇内容も、山田さんの登壇内容も、佐藤さんと服部さんの登壇内容も、そして最後の私の登壇内容も共通する点は同じ。
その後の座談会では、事前の控え室の会話では良い感じの話ができたような気がするのに、スタジオでは私の振る舞いは少し怪しかったようです。
