kintone

いかにしてカスタマイズの方法を選ぶか〜ふりがなを自動的に補完するカスタマイズの時の技術選択

2020-07-06

前回「kintoneのUI改善!: フィールドに入力された名前のふりがなを自動的に補完する」という内容で、名前のふりがなを自動的に補完する方法を紹介しました。

kintoneのUI改善! フィールドに入力された名前のふりがなを自動的に補完するカスタマイズ｜R3 Cloud Journey
インターネット通販のおかけで、沖縄のお店では売っていない売っていない便利なものが買えるいい時代に生まれてよかったと思っている、沖縄生まれ沖縄育ちの與那城(「よなしろ」って読みます!)です。インターネット通販をしてて、めんどくさいなーと思うことがいくつかあるのですが、その中の一つに購入者の情報を入力する。というものがあります。 ...

前回の記事ではkintoneに辞書アプリを作って漢字に対応する読みを登録する方法を紹介しましたが、実は最初の企画段階では別の方法を使って「ふりがな」の情報を取得しようとしていました。

思うところあって没にしたのですが、没にした理由等もふくめて供養もかねて紹介したいと思います。

ちょっと長いのでこの記事のまとめ

解決したい問題は何で、時間やお金というコストや、問題解決の意味を考えながら技術や手法を選定することが重要。

「プログラミングができるから、自由にプログラム書くべき!!!」とか、「PaaSを契約しているんかだからPaaS使わないといけない!!!」とか、手段にを先に考えてしまいがちにならないようにしていかないといけない…と強く思いました。

ふりがなを取得するには?

2020年6月時点でkintoneやgusuku Customineの機能を使って、ふりがなを取得しようと思った時に、僕が思いついた方法というのが

外部のひらがな化APIを使用する
ひらがな化APIを自分で作って呼び出す
kintoneにアプリを作って、漢字に対応した読みを取得する

というものでした。

いずれの方法もいいところと、ちょっと悩ましいところがあったので、それぞれ紹介していきたいと思います。

外部のひらがな化APIを使用する

はじめに、外部のひらがな化APIを使用するものです。

具体的には gooラボのひらがな化APIを呼び出して取得したふりがなを取得しようとしていました。

こんな感じのカスタマイズです。

ちゃんと動きます。

一番上の「JavaScriptを実行する」のコードは下記の通りです。

return function(keyword) {
    const url = 'https://labs.goo.ne.jp/api/hiragana'
    const app_id = '取得したアプリID'
    const request = {
        app_id: app_id,
        sentence: keyword,
        output_type: 'hiragana'
    } 
    const header = {
        'Content-type': 'application/json; charset=UTF-8'
    }
    return kintone.proxy(url, 'POST', header, request).then(function(result) {
        return JSON.parse(result[0])['converted']
    })
}

‍

ひらがな化APIを自分で作って呼び出す

CustomineからAWS Lambda Functionを呼び出すことが可能なので、ひらがな化するためのLambda Functionを作って実行することでふりがなを補完することができます。

Lambda Functionの内容は省略しますがCustomine側のカスタマイズはものすごく少なく済んでます。

このカスタマイズを実行すると…

ほぼ同じように動いているようにみえると思います。

若干Lambdaの呼び出しで時間がかかっているため、ちょっと遅いのがわかるかと思います。

kintoneに辞書アプリを作って、漢字に対応した読みを取得する

こちらは前回の記事の通りなので省略します。

以上3つの方式を検討して、blogに書いたのが「kintoneにアプリを作って、漢字に対応した読みを取得する」方法でした。

なぜ「kintoneに辞書アプリを作って対応する方法」を紹介したのか、他の2つの方法を選ばなかったのか、何を基準にして選んだかを紹介していきます。

基準となる視点

基準としたのは下記の点です

外部への依存
実装のしやすさや/改修のしやすさ
辞書のメンテナンスのしやすさ(そもそもメンテナンスが必要かどうか)
真似しやすいかどうか

外部への依存

外部への依存が悪いということではなく、それぞれのサービスを利用するにあたっての注意事項を確認しないといけません。外部のAPIに関してはそのAPIの利用規約に準拠する必要があります。AWS Lambdaなどのプラットフォームを使う場合はプラットフォームの利用規約に従う必要があります。

特に情報を外部に送信して使用するAPIの場合は、自社のもっている情報を外部に送信しても問題ないかなども含めて検討する必要があります。

実装のしやすさ・改修のしやすさ

漢字からひらがなに変換するところは、おそらく下記の選択のどれかをとることになると思います。

外部のAPIを使用して、使用するAPIに依存する
内製する(もしくは外部に開発を委託する)

内製する場合だと…

プログラミングスキルのある人が自由にプログラムを書いて実装する
kintone/Customineのようなプラットフォームに頼って実装する

になるかと思います。

それぞれの比較をしていきたいと思います。

外部のAPIを利用する

今回の例では、外部に依存する選択肢のgooラボのAPIを使用するのであれば、APIさえ呼び出せれば実装する必要すらありません。これはコスト(主に時間)面で大きなメリットです。

しかし自分たちの使いやすいように改修をすることはできません。例をあげると漢字からひらがなに変換した時に望んでいるよみがなが返ってこない場合、対応することができません。(要望を受け付けている場合も多々あるとは思いますがそれが実装される保証はありません)。

内製する(プログラムを書く)

内製する場合は自由に開発するパターンとプラットフォームに頼って開発するパターンにわかれます。

プラットフォーム・言語などを自由に選択してやる場合は、プログラミングスキルを持った人が社内にいる場合は、(その人のスキル次第で)作りたいように作れるので実装することは特に難しくないと思います(要件にもよりますが)。

ただし、プログラミングスキルを持った人が開発に専念できる時間を確保できるかが鍵になってくると思います。
(そのためにプログラミングスキルを持った人を雇用する。という方法も取れると思います。)

内製する(プラットフォームに頼る)

プラットフォームにある程度頼って内製する場合は、プラットフォームの理解があればその範囲でできるので、「プログラミングスキル」への依存度が減る(はず)です。
ほとんどのプラットフォームではより実装の手間を省くように作られているので実装にかかる時間が短縮できるはずです。

プラットフォームに頼る場合はプラットフォームの範囲で改修することはできますが、なんでも自由にできるわけではありません。

ただし、外部のAPIを呼ぶ時のように、プラットフォームを提供している事業者に要望を出すことはできるかもしれません。
(gusuku deploit・Customineなどgusukuシリーズについてはについては要望をチャットサポートで受け付けています!)

辞書のメンテナンスのしやすさ(そもそもメンテナンスが必要かどうか)

漢字に対応していない読みを登録したり、漢字が登録されていない場合に辞書をどうメンテするのか…という点です。

外部APIに頼る場合は対応できません(事業者によっては要望を受けてくれるかもしれません)。

自分達で(Lambdaとかで)内製した場合は、内製した担当者に依頼するか、開発した人が辞書メンテナンス用の画面とかを用意してくれていれば簡単にできるかもしれないです。プラットフォームで開発するも同様です。

真似しやすいかどうか

こちらは単純にblogの記事を見て真似しやすいかどうかです。Lambdaで実装するパターンはAWSのアカウント開設からはじめないといけないので敷居が高いかな…と思ったりしました。 (Lambdaを使ったことある人であればこの記事を見れば大丈夫かと思います)

3つのやりかたの比較

外部のひらがな化APIを使用する

「外部への依存」は、外部のAPIを使うので当然発生します。gooラボの利用規約の範囲の中で使用することになります。また、APIが提供終了した場合は以降使えなくなります。また、送信する情報の取り扱いに関する扱いも気にする必要もあります。

「実装のしやすさ・改修のしやすさ」については、漢字→ひらがな変換に関しては実装の必要はありません。APIを呼び出す部分のみ作れば大丈夫です。改修はできません。

「辞書のメンテナンスのしやすさ」は、メンテナンスできません。

「真似しやすいかどうか」は個人の主観ですが、Customineのカスタマイズはそんなに複雑なことはしていないですが、Customine内で「JavaScriptを実行する」を使用しているのでちょっと大変かもしれないです。

ひらがな化APIを自分で作って呼び出す

「外部への依存」は、自分で作るので、APIを動かす環境(今回の例でいえばAWS Lambda)の規約の中で自分の作ったAPIを動かすことになります。またAPIを動かす環境がサービス提供終了したら動かなくなります。

「実装のしやすさ・改修のしやすさ」については、プログラム書けるのであれば実装はできると思います。プログラムを書けなかったり、書くのが苦手だったりすると敷居が一気にあがります。

「辞書のメンテナンスのしやすさ」は、作ったAPI次第です。別途辞書メンテナンスのためのツールがあったり、ExcelファイルやCSVファイルを作って特定に場所にアップしたら更新される…といったような作りになっていたり、Webアプリでメンテができるようになっていたりすると楽ですが、そのための開発コスト(時間/お金/etc…)がかかるはずです。ただし、自由度は一番高いです。

「真似しやすいかどうか」に関しては…真似しづらいかな…と思います。自由にLambdaを使いこなせるレベルのプログラミングスキル・AWSに関するスキルがある人であれば苦労はないかな…と思います。

kintoneにアプリを作って、漢字に対応した読みを取得する

「外部への依存」は、kintone(cybozu.com)とCustomine以外は特に依存していません(Customineを使わなくても作れます)。

「実装のしやすさ・改修のしやすさ」については、kintoneアプリは特に難しいことはしてないですし、Customineでのカスタマイズもそこまで難しいことはしてません。改修に関してはCustomineでできる範囲のカスタマイズで対応可能です(取得した読みをカタカナに変換したいとかそういうことはできます)。

「辞書のメンテナンスのしやすさ」は、kintoneの辞書アプリにレコードを追加したり、編集するだけなので簡単です。

「真似しやすいかどうか」は、kintoneとCustomineについての理解があれば、この3つの中では一番真似しやすいかと思います。

比較した上で…

3つのやり方を比較したうえで、なぜ「kintoneにアプリを作って、漢字に対応した読みを取得する」を紹介したのかというと、一番大きな要素としては「真似がしやすい」「実装のしやすさ」を重視したためです。

あとは「外部の依存」について、実運用する時に外部APIに個人情報を送信することになるところで躊躇することがあるのではないか…と思ったため、gooラボのAPIを使用する方法の紹介をするよりはkintoneの中で完結する方法があればそのほうがいいのではないか…と思ったためです。

どちらの手法を使ったとしても、良い点・大変な点があるのですが、今回は「真似のしやすさ」と、技術的な容易さという意味での「実装のしやすさ」で選択をしました。

「ふりがなを自動的に補完する」ということを通して、解決したい問題は何で、時間やお金というコストや、問題解決の意味(プログラミングの学習も兼ねている場合はプログラムを書かないといけないし、業務の改善が目的であれば業務が改善できないと意味はない&必要以上に難しくやる必要はない)を考えながら技術や手法を選定することを日々意識しなが技術を選定しています。

「プログラミングができるから、自由にプログラム書くべき!!!」とか、「PaaS(Platform as a Service: kintoneのようにアプリやプログラムを構築するためのプラットフォームをサービスとして提供している形態)を契約しているのだからPaaS使わないといけない!!!」とか、手段にを先に考えてしまいがちにならないようにしていかないといけないな…とblogを書きながら思ったので、この後日談的なblogを書きました。