ワンランク上の“鉄板”ワザを伝授　2018年kintone hack王者が教える「アプリ作成」のコツ

「kintone」を駆使した、ワンランク上のアプリ作成

山下竜氏（以下、山下）：今日はこのように題しまして「kintone hack 王者の流儀－はじめに知っておきたいワンランク上のアプリ作成」ということでお話させていただきます。改めて自己紹介をさせてください。

Kintone Corporationの山下と申します。2回目のkintone転職を経て、現在サンフランシスコのサイボウズですね。kintoneの販売拠点で勤務をしております。昨年、ドローン + AIということで王者の座をいただきました。

今年は何をやろうかなと思っていたんですけれども、基本に帰ってきたいなと思いました。背景なんですけれども、アメリカに行って出会った言葉があります。「これからすべての企業がソフトウェア会社になっていく」と。

これ、ひょっとして世界中のすべての企業やチームとって、「kintoneでアプリを作って運用していく」というのが、グローバルスタンダードになっていくんじゃないかなと思いました。

それであれば、「kintone」をより活用していくために、もうちょっと準備をしていかないといけないと思いました。

そこで今回のフォーカスなんですけれども、ここですね。「kintoneであれば誰でも簡単にアプリが作れる」。これは「kintone」の良さなんですけれども、ここにフォーカスし直したいというところです。

アプリ作成時、業種・職種ごとの“鉄板”をレコメンド

おさらいなんですけれども、「kintone」の3大要素はデータ、プロセス管理、コミュニケーション。そして、それらをサポートするJavaScriptを含めたAPIがあります。

そして、今日もたくさん展示があるんですけれども、ノンプログラミングの領域からプラグインといった拡張機能を付けることもできますし、個別のカスタマイズでより強化することもできる。

「kintone、簡単簡単」と言うんだけれども、実は落とし穴に落ちていることもあるんじゃないでしょうか。「自由度が高すぎて、気づいたらたくさんアプリ作っちゃってた」「むちゃくちゃ動きが遅くなっている」「一度データを入れると実際修正しづらい」というようなことに遭遇された方もいらっしゃるかもしれないです。私も実際、困ったことがあります。

レコード番号でルックアップする。私が設定したわけではありませんが、これ、絶対にやめたほうがいいです。多段でルックアップした例なんですけれども、超強いモンスターで、結局倒すのにだいぶ時間を要しました。絶対やっちゃいけないやつです。

じゃあ、落とし穴に落ちないためにはどうしたらいいのか。これは、やはり理論と経験に裏打ちされた一定の知識に基づいた設計を意識していただくといいんじゃないかなと思います。

そこで今回やるのは、こういったことを考慮できる「アプリの最適化レコメンデーション」です。どういうことをやるかというと、アプリを作るときに必要な情報ですね。業種、職種、用途、もしくはすでにアプリがあったら機械学習、レコメンデーションアルゴリズムにぶち込んであげて、「こう作ってあげたほうがいいよ」と導き出してあげるものです。

こういったかたちで、主に業種や職種から「こういった鉄板アプリ、だいたい出てくるよね」というのを作ってあげて、次に「こういう業種、職種だったらこういうアプリができて、その中でそういう項目あるよね。こういうアプリ連携あるよね」という鉄板の項目を考えます。同時に、構造的にアプリの設計がそれでいいのかをレビューしてあげるものです。

パフォーマンスを考慮した設計ポイントが重要

デモに行きたいんですけれども……。このようなかたちでコマンドを実行してあげます。

レコメンドの適用が対話か強制かを選択できたり、日付のフォーマットとか通貨って、国によって異なるので国を登録したり、あと肝になる業種、職種ですね。対象のアプリの所在を入れてあげます。

このようなかたちでレコメンドの結果を受けまして、アプリが修正されたり新しく作られたりというような感じです。

「今回、織り込んだビューの観点」というのをご紹介しておきます。大きく2つです。先ほど申し上げたような「データ構造の基本的な設計ポイント」と「kintone」を使っていく上で、「パフォーマンスを考慮した設計ポイント」が時折必要になります。これらを考慮しています。

重複禁止のフィールド設定の注意点

データ構造に関するところでは、とくに注意していただきたい代表的なものを例で挙げているんですけれども。先ほど申し上げたのは、一番上の「重複禁止のフィールを設定してね」というものとなります。

従来のRDB（リレーショナルデータベース：従来のデータベースの各データ間にリレーション（関連性）を加えて、一元管理できる統合管理環境）でも似たような概念があったりするので、意識されている方もいらっしゃるんじゃないかと思います。

アプリの分割にもちょっと触れておきたいんですけども。実際のところ、今回動いた内容は、もともと「kintone」のテンプレートに入っている顧客リストを最適化し直して、SFA（営業支援システム）を作るという内容になっていました。

顧客リストは、こういう構造なんですけれども。

重複禁止のフィールドを設定して最適に作ろうとすると、まずアプリを分割して、その敷居というやつですね。設定できる分割をします。こちらでも分割した後に、顧客も担当者のマスタを設けて、こちらからルックアップをし直すことが必要ですね。

パフォーマンスもこういった考慮ポイントがありますよ、というものを挙げています。

どうやって知見を得るかですけれども、詳しい人たちがいるので聞いてください。

まとめはこちらでして、「新しい勇者の誕生にご期待ください」。以上です。ご清聴ありがとうございました。

（会場拍手）