kintone hive
開発者の異動や退職によって、誰もシステムの中身がわからなくなってしまうことを「ブラックボックス化」と呼びます。
システムにトラブルが発生した時、復旧できない、あるいは、システムに新しい機能を追加したくても追加できない等の致命的な支障が出ます。
いま、システム開発、特に、プログラムコーディングの分野で、AI利用が物凄い勢いで拡がっているとのことです。
しかし、AIコード生成の「70％問題」が指摘されていて、AIは素早くコードの大部分を生成できますが、最後の30％（デバッグ、エッジケース【想定外】の処理、保守性の確保）には、まだ人間の専門知識が必要だそうです。
しかしながら、今後は、AIによるコーディングやテストが当たり前になり、人間が直接関与しなくなる、あるいは、関与できなくなる時期が来るのでしょう。
現在のJAVAやPhysonで書かれたプログラムは、いつしかAIが勝手に、人間には理解できない言語に置き換えてしまうかもしれません。
それは、新しいタイプの「ブラックボックス化」だったりするのでしょうか^^;
AIにプロンプトを投げかけて、dbSheetのプロジェクトファイルが生成されるようにならないかと
夢想する今日この頃（笑）
kintone hive
「kintone hive」はkintoneユーザー主体のイベントです。
筆者は、４月に名古屋、５月に仙台、広島と、イベント会場へ足を運びました。
kintoneは、ユーザー部門が自ら業務の効率化を図るためにシステム開発する、いわゆる「内製化」を支援するために登場したノーコードツールです。
ノーコードツールとは、「コード」（プログラム）を書かないでシステムを作ってしまえるツールです。
dbSheetも、「内製化」を支援するツールのカテゴリーに入っているので、kintoneは、競合する製品と言えるかもしれません。（圧倒的に、市場シェアで負けていますが^^;）
「kintone hive」では、今まで、ITベンダーや情報システム部門に、蔑ろにされてきたエンドユーザーたちの雄叫びが聴ける熱いイベントです。
「kintone hive」に参加して得られるメリットの一つが、システム開発における「引き出しを増やせる」ということです。
この引き出しは、dbSheetでシステム開発するに当たっても、気付きとなることが多々あるでしょう。
今回は、「kintone hive」に参加して得た、いくつかの気付きについて、ご紹介いたします。
削除権限を付与する代わりに削除フラグを利用
これは、筆者も昔から使っていた手法です。
目的は、ユーザーの誤操作でレコードが削除されないようにするためです。
実際には、レコードは残しておいて、レコード一覧や検索結果には表示されないようにします。
考慮すべき機能として、レコードを復活できるように削除フラグを外す仕組みを実装する。
また、削除フラグを立てたレコードの再利用は、できるようにする。
あるいは、一定期間経過後、完全にレコードを削除する機能を実装する等です。
今回の気付きは、削除フラグを立てる位置でした。
レコード一覧の左端先頭に堂々と設置されていました。
dbSheetのIOTGで生成されるタスクセットと同じ位置です。
これは、業務によっては、「アリ」なんだと気づかされました。
まるで、不要なメールをゴミ箱に入れる感覚で、気軽に（笑）レコードを削除できる仕様です。
いま、流行りの「心理的安全性」でしょうか。
ユーザー情報はユーザー本人が更新する
グループウェアやECサイト、SNSでは、ログインすると、ユーザー情報をユーザー本人が書き換えられるようになっています。
例えば、パスワードの変更やプロフィールの編集等です。
事例では、通勤車両の管理でした。
地方都市では、通勤に自家用車を使うのが当たり前になっています。
自家用車を使う上で、運転免許証や任意保険加入状況等の更新が適切に行われているか管理する部署があります。
この部署には、更新を督促して、関係書類を保管・管理する等の作業負荷がかかっていると想像できます。
これらの更新作業をユーザー独自のページを用意して、ユーザー自身に実行させるシステムです。
個人情報が絡んでくるため、セキュリティ上の課題はあると思われますが、センター部門の業務負荷は飛躍的に軽くなると思われます。
クライアントへのリーチ
ＤＸが新しいビジネスモデルへの転換と捉えると、社内の業務効率化だけに留まっていると、限界に達します。
いかに、クライアントを巻き込んで、新たなビジネスモデルを構築するかが、未来の企業の競争力を左右します。
事例では、セレモニーホール運営会社が、お祝いのケーキを受注するサイトを構築、あるいは、データ入力代行会社が、プロ野球球団のファンクラブの運営サイトを立ち上げ等のプレゼンがありました。
いまや、特別な技術、ノウハウがなくても、スマホ、ブラウザ、データベース、電子決済等の仕組みが、ノーコードで実現できてしまうことを目の当たりにしました。
新鮮な情報をポータルに表示
飲食業（某市内で３店舗展開する焼き鳥店）の事例は、圧巻でした。
日報を電子化したことによるシフト表（勤怠管理）の改善が図られ、アルバイトの人件費が抑えられた。
あるいは、店舗単位で仕入を分けることにより、発注ミスを減らし、フードロスを削減した。
また、顧客情報の共有（来店する顧客の風貌や注文する品、来店時間や人数のデータベース化）による店舗間人事異動時のスムーズな対応など、ある意味、飲食業は、製造業なんですね^^;
凄まじい業務効率化が図られている印象でした。
システムのポータルには、リアルタイムに３店舗の売上や客単価が表示されるように作られていて
従業員は、指示されてやるのではなく、自ら気付いて行動するようになったとのこと。
わかってはいるけど、実現は、なかなか難しい仕組み作りです。
ターゲットの選び方
ほとんどのユーザーは、今までの慣れ親しんだ手順から新しい手順へ変えることを嫌がるものですね。
新しい手順は、できないのではなくて、やりたくないのでしょう^^;
この「鬼滅の刃」に出てくるラスボス「無惨」の「私が嫌いなものは変化だ」をどうブレークスルーするか？
システム普及のキッカケ作りとして、皆がうんざりしている業務「うんざり業務」を圧倒的に簡単にしようとした事例が紹介されました。
「うんざり業務」は、手間暇がかかる割に誰からも感謝されない後ろ向きの業務でした。
説明を聞くと、劇的に業務改善されているシステムでしたが、最初は、誰も使わなかったそうです。
一人一人に当たってメリットを説明する地道な働きかけの継続が、やがて、口コミとなって拡がっていったそうです。
人の適用力を信じる
システムを入れ替える時、新システムと旧システムを併用する移行期間を設けて、切替による不具合で業務に支障が出ないようにするのが、一般的ではないでしょうか。
紙で運用している業務をペーパーレス化する場合も同様で、一定期間は、「紙でも可とする」のが当たり前と思っていました。
しかし、併用期間を設けないで、いきなり、全面切替された事例がありました。
それほど大きくない組織の事例でしたが、社長＝開発者ということもあったかもしれません。
そして、新しいシステムの開発に当たって、シンプルな操作性を追求する努力を惜しまなかったのが、成功の要因だったようです。
いかに、操作の手間を減らすか（自動入力、自動制御）、これがクリアされていれば、どんなユーザーでも慣れてしまうということです。
そして、その先にある利便性に気がつくのでしょう。
dbSheetの優位点
さて、最後に、kintoneとdbSheetを比較した時のdbSheetの優位点について、３点に絞って書きます。
まず、dbSheetは、機能拡張するためのプラグインが不要だということです。
kintoneでは、見栄えのする文書として印刷する必要がある場合、別途印刷用のプラグインが必要となります。
また、アプリ（テーブル）間で連携させて、データ参照、集計を行うような複雑なアプリを作成する場合も、別途データ連携用プラグインが必要となります。
プラグインは、システム拡張を実現するメリットとコストアップ（サブスクの料金体系）や属人化の温床となるデメリットを内在しています。
そして、頻繁にアップデートされるkintoneでは、アップデート後にプラグインが動かなくなるリスクも抱えています。
次に機能の汎用性です。
dbSheetは、汎用データベース（MSSQL、mysql、oracle）やexcel（関数やマクロ）の機能をほぼ制限なく、すべて使うことができます。
SQLやexcelは、汎用性があるため、取り扱える技術者や参考となる情報が豊富です。
ノーコードを謳ったツールは、何かしらの制限があるため、ユーザーが期待する「痒いところへ手の届くシステム」に仕上げることができない場合が出てきます。
最後は、やはり、excelとの親和性です。
kintoneにもexcelに似せた操作を実現するプラグインがあります。
excelに慣れ親しんだユーザーは、新しいシステムに対して、違和感を覚えるのでしょう。
そのようなプラグインがあるのは、その証左です。
共有、肥大、属人化というexcelの弱点が克服できれば、本当は、ユーザーはexcelのままが良いのです。
皆さん本日もお疲れ様でした！
おやすみなさい（挙手）