0. 時代背景
・企業のDXの推進
・ITおよびシステムの市場ニーズの増大
・IT人材不足
・セキュリティの脅威の拡大
1. スクラッチ開発の現状
1.1 スクラッチ開発の定義
・コーディングをイチから行うシステム開発
・開発言語・フレームワークを自由に選べる。たとえば、以下のような感じ。
| フレームワーク | 対応言語 |
|---|---|
| Django（ジャンゴ） | Python |
| Spring（スプリング） | Java |
| React（リアクト） | JavaScript |
| Unity（ユニティ） | C# |
1.2 スクラッチ開発の限界・デメリット
・開発工数・期間・コストが大きい
・要件変更に弱い（柔軟性に欠ける）
・保守が属人化しやすい
・フレームワークがEoL時に再度開発コストがかかる
1.3 セキュリティ面の課題
・実装者のセキュリティ知識に依存
・脆弱性（例：SQLインジェクション）が入りやすい
・アップデートや脆弱性対策を自前で対応する必要あり
・フレームワークがEoLを迎えた時の対応が非常に困難
2. ローコード開発について
2.1 ローコード・ノーコード開発とは
・ローコード：少量のコードで開発できる
・ノーコード：GUI操作で完結、プログラミング不要
2.2 代表的なプラットフォーム
| 製品 | ノーコード可能か | 概要 |
|---|---|---|
| kintone | ○ | 業務アプリ構築向け |
| Power Platform | ○ | Microsoft製。Power Appsなど |
| Salesforce | ○ | CRM分野に強い |
| ServiceNow | ○ | ITサービス管理（ITSM）を中心に、業務プロセス全般を自動化できるプラットフォーム。 |
| OutSystems | ローコード | エンタープライズ向けの大規模対応 |
| Pega Platform | ローコード | BPM（ビジネスプロセスマネジメント）に特化。複雑な業務フローの自動化やルール管理に強み。 |
2.3 ローコード開発のメリット
・短期間で開発できる
・非エンジニアでも開発可能 →現場にて業務に精通している人が開発できる。
・標準的なセキュリティ機能が初めから備わっている
2.4 ローコード開発のデメリット
・本格的な業務アプリには向かない（制約あり）
・JavaScriptなどでカスタマイズ可能だが、できることには限界がある。
2.5 セキュリティ面のメリット
(1) 初期開発
・標準で認証・認可・監査ログなどの機能あり。標準でセキュリティ機能が備わっているので、一定のセキュリティレベルを保ちやすい
・セキュアコーディングが保たれたプラットフォームなので、SQLインジェクションなどの脆弱性は入りにくい
(2) 運用
・パッチ適用やセキュリティ更新はベンダー側で実施
・クラウド・SaaSの前提により安全性・メンテ性が高い
2.6 セキュリティ面のデメリット
・SaaS環境（クラウドサービス）であり、サービス提供会社のセキュリティ対策が、どれほどしっかりやっているかわからない。
・仮に脆弱性があったとしても、自力で修正できない（サービス提供者の方針や考え方に依存）
・ISMAP対応が求められる場合など、組織のセキュリティ基準と合わない可能性あり
・実質的にプラグインの活用が必須だったりするものもあるが、そのプラグインベンダのセキュリティ対策も気にする必要がある。
・OWASPが発表しているノーコード/ローコードで開発されたアプリケーションへのセキュリティリスク
https://jpn.nec.com/cybersecurity/blog/220826/index.html
・クラウドのリスクと同じですが、ノーコードだけに簡単な操作で設定ミスが起きることがある。
・サービスと利用者との責任分界点が明確に決まっているが、その点を確認せずに自分たちがどこまで責任を持つかを明確に理解せずに運用を進めてしまう可能性がある。
・以下、落とし穴というテーマで解説があります。
www.nri-secure.co.jp
↑に記載がありますが、NRIセキュアさんが「ローコード／ノーコード開発基盤 セキュリティ評価サービス」を提供されています。開発前および開発後の両方で評価をしてもらえるように思います。
2.7 セキュリティ面は、ぶっちゃけどうなの？
・上記のようにメリットデメリットはあります。では、ノーコード、ローコード開発は、セキュリティ面では、正直おすすめなのでしょうか？どうなのでしょうか。もしかすると、お客様やシステムによるかもしれません。非常にクリティカルなシステムであれば、個別開発が向いているのかもしれません。
・とはいえ、汎用的であったり社内システムなどの場合は、SaaSやノーコードでの構築が望ましいというのは多くの人が感じているところだと思います。
3.kintoneについて
3.1 kintone概要
(1)会社概要
1997年に創業したサイボウズ株式会社。グループウェア「サイボウズ Office」をはじめとする業務アプリケーションを提供。社名の由来は「サイエンス＋ボウズ（坊さん）」。
(2)kintone開発の背景
2011 年、ノンプログラマでも業務アプリを自由に作れるクラウド基盤として「kintone（キントーン）」をリリース。
(3)kintoneの概要
kintoneは、クラウド上で動作するローコード／ノーコード型の業務アプリ開発プラットフォームです。Web ブラウザやモバイルアプリからアクセスでき、フォーム設計からワークフロー、レポート、外部連携まで一気通貫で提供します。プログラミング不要で、部署横断の業務システムを迅速に立ち上げられる点が大きな特長です。
(4)kintoneによるローコード開発の利点
・PIVOTで公開されています。
https://www.youtube.com/watch?v=bidwYxQMd0A
3.2 kintoneの機能概要
(1)機能概要
・基本機能は、データベース、ワークフロー、コミュニケーションが軸で、それ以外にアクセス権の設定やリマインダーの通知などなど。メールアプリケーションはなく、メールに通知するところまでかな。
・kintoneが向いているのは、堅牢な基幹システムよりは、スピードや柔軟性が求められるような業務システムが向いているだろう。
・実際の操作手順
たとえば、顧客管理システムを作るにあたり、ユーザ登録から顧客管理、帳票などの出力まで。問合せ管理も同様に、顧客からの問合せ登録、問い合わせをDBで管理、アウトプットまで。
Q.公開Webサーバとしても使えるの？ユーザログインをしない問合せフォームなども可能？
→基本的にはできない。フロントエンドは別途構築し、API等でサイボウズと連携する必要がある。
(2)kintoneにおけるローコード開発/個別開発
・プラグインを使う選択肢もあれば、個別開発をすることもできる
・プラグインを使う場合、追加でプラグインの利用料がかかる。
・個別開発は、kintoneの画面上からプログラムを配置したりするのではなく、別のプラットフォームで開発し、API連携を実施する。
【開発例】※これらはプラグインで対応可能
・画面の見た目の修正
・条件（期限が過ぎているなど）に応じて画面表示のレコードの項目の色を変えるとか
・バックアップを実施したいなどの機能追加
(3)プラグインの例
・基本機能で不足している分は、プラグインで追加機能を実装できる。
・以下からプラグインを検索することができる
https://kintone-sol.cybozu.co.jp/integrate/search/
・トヨクモ社のプラグインの場合
（出典：https://contents.kintoneapp.com/tkalp）
| 機能名 | 詳細 |
|---|---|
| FormBridge | Webフォームを作成してkintoneにデータを入力できます。お問い合わせ受付や各種登録フォームなどに最適です。 |
| kViewer | 公開したいデータを選んでWebページを作成できます。kintoneユーザーではない組織外の人にも情報共有できます。 |
| kMailer | kintone上のアドレス宛に自動でメールを配信します。テンプレートを作成して件名や本文にkintoneの情報を引用できます。 |
| PrintCreator | 既存の帳票デザインに、kintoneのデータを引用できます。はがきやラベルなど各種サイズに対応しています。 |
| kBackup | kintone上のデータや添付ファイルをバックアップします。人的ミスや災害によるデータ消失に対しても安心です。 |
(4)バックアップ機能の追加
・バックアップを例に考える。BCPの観点では、kintoneとしてバックアップデータを取得している。だが、ユーザが任意のタイミングでバックアップデータから復元するなどはできない。
・kintoneでは、GUIの画面からデータを出力できるので、バックアップを取ることはもちろん可能である。
・「ファイル入出力やAPIで取得できない情報」が以下に記載されている。これは、APIを利用しているプラグインでも同じであろう。
https://cybozu.dev/ja/kintone/tips/best-practices/colum/kintone-backup-and-migration-guide/#information-that-cannot-be-obtained
・ユーザーが任意のタイミングでバックアップを取るには、プラグインを活用する方法がある。たとえば、トヨクモのkBackupがあり、他にも2から3社のバックアップソフトがある。
・または、無料でクライアントツールがあって、CLIでコマンドラインで取ることもできる。→API連携なので個別開発になると思われます。
| 「kintoneコマンドラインツール（cli-kintone）」 https://cybozu.dev/ja/kintone/sdk/backup/cli-kintone/ |
具体的なバックアップの方法は、以下に記載あり。
https://cybozu.dev/ja/tutorials/hello-cli-kintone/backup/
3.3 kintoneのセキュリティ
・セキュリティ対策状況
・ISMAPに登録されている。※ただし、プラグインは別と考えた方がいいでしょう。
・基本的なセキュリティ機能として、二要素認証や送信元IPアドレス制限などができる
・BCPの観点でのバックアップが取られている。ユーザがデータ消去した場合などの個別対応は実施されないが、大規模災害があったときなどは、ユーザデータ含めて復旧がされる。
・プラグインのセキュリティ
以下のYoutubeでは、若干、弱気な発言をしている。
https://www.youtube.com/watch?v=bidwYxQMd0A
・責任分界点
（出典：https://www.cybozu.com/jp/support/data/cybozucom_boundary.pdf）
・参考：開発環境からのデプロイの注意点
https://kintone.cybozu.co.jp/kintone-signpost/guide/development_environment.html
