自治体DX kintone活用実践編【13,000字】
ノーコード・ローコードツールを活用したアプリ開発を行う、ワークログ株式会社の山本です。
自身が開発会社を5年経営し、神奈川県のDX推進アドバイザーとしても活動しており、大小様々な自治体のDX支援を行う中で得られた知見を書き留めました。
読んでほしい方
kintone導入の工程と4つの壁
kintoneに限らず、何らかのツールを導入するためには下記の通り大きく4つの工程を踏むことになります。
①調達の工程では、予算要求に伴い効果測定やセキュリティ調査、類似サービスとの比較など、財政課や情報セキュリティ部門からの厳しい審査が入ります。この時点で導入を断念する自治体も少なくありません。
②業務分析の工程では、そもそも既存業務が属人的に行われていることや、どこで使われているのかよくわからないような帳票が散在しているケースもあり、体系的に業務フローが整理されていないことがほとんどです。
③開発の工程では、kintoneやその他プラグインの活用経験や技術的な知見がないと前に進みません。特に自治体の場合は通常業務と兼務で進めていることもあり、他自治体での導入事例を参考にするのが早いことが多いです。
④運用の工程では、運用体制を内製化するのであればルールを定める必要があります。
それぞれの工程に関して、1つずつ説明します。
[調達]導入時に検討すべき3つのポイント
kintoneのセキュリティガイドライン
kintoneは既に150を超える自治体で活用されていることから、基本的にセキュリティに関しては問題ないことがわかります。
サイボウズのHPでは、kintoneのセキュリティガイドラインについて公表されています。
具体的には、ISMAP、ISO/IEC 27001、ISO/IEC 27017を取得しており、SaaSとしては充分にセキュリティを担保されていると判断できます。
また、コロナを機にkintoneを導入した自治体も多いですが、医療情報をkintoneで扱うことについては、令和1年7月に「医療機関向け『cybozu.com』対応セキュリティリファレンス」が公開されています。
公開されている医療情報システムの安全管理に関するガイドラインにおいて、医療機関等は、記憶(ID・パスワード)以外の認証を加え、二要素認証を実施することが望ましいとされています。
また、ログイン情報が流出した場合に備え、kintoneではIPアドレス制限をすることが可能です。
アクセスを許可するIPアドレスを予め登録しておくことで、それ以外のネットワークからのアクセスはシャットアウトされます。
有料になりますが、クライアント証明書を発行し、接続できる端末を制限する「セキュアアクセス」という機能も提供しています。
LGWAN環境での利用
kintoneはLGWAN環境での利用も可能です。
両備システムズが提供する「R-Cloud Proxy for kintone」を利用することで、LGWAN環境でkintoneを利用できます。
しかし、外部プラグインについてはサービス対象外になるという懸念がありました。
これに対し、令和5年9月にリリースされた「moconavi LGWAN クラウドゲートウェイサービス」は、kintoneだけでなくトヨクモ社が提供するkViewer、フォームブリッジや、CustomineやkrewDataなど、kintoneと合わせて導入すると非常に便利な外部プラグインも利用可能になります。
これにより、インターネット環境でも、LGWAN環境でも、どちらでもkintoneの導入がしやすくなったと言えます。
kintone導入の効果測定
予算要求において最もハードルが高いのは「kintoneの導入コストに見合った効果は得られるのか?」という点だと思います。
後段で記載する業務分析を行い、効果を予測するのが正しいアプローチではありますが、別の方法について記載します。
kintoneは自治体に対して積極的にキャンペーンを打ち出していますので、それを積極的に利用するのが良いです。
例えば、コロナ禍においては期間限定で無償提供していましたし、2022年6月1日から2023年5月31日までの期間、50の自治体に限定し無償提供するキャンペーンを打ち出していました。
今後も同様のキャンペーンを行う可能性もありますので、サイボウズからのリリースを定期的にチェックするのが良いでしょう。
また、kintoneのアプリ開発についても、簡易的なものであれば無償にて開発を行う開発会社もあるので、まずは無償にて検討するというのも手段の1つかと考えます。
[業務分析]目的と進め方
kintoneなどシステム導入や開発を行う際に、まずやるべきことは「業務分析」です。
本章では、業務分析の目的と進め方について解説します。
なぜ業務分析が必要なのか?
システム開発の多くは『要件定義』と呼ばれる工程で失敗すると言われています。
この要件定義とは、開発会社がシステム開発を行う際の仕様を決める工程で、例えば、
・会員情報として名前とメールアドレスとパスワードを登録する
・登録が完了すると会員にメールが送信される
・会員情報は名前で検索できる、など
システムに求める機能を列挙していきます。
では、なぜ要件定義で失敗するのでしょうか?
実は、そもそも発注者が自分たちの業務を理解していないことが多いのです。
イレギュラーケースが多かったり、いろんな帳票や紙が煩雑に管理されていたり、担当によってやり方が異なっていたり…。
とにかく理由は様々ですが、他社に伝えられるほど業務が整理されていないことが多いのです。
そこで業務分析には主に3つの目的があります。
まず、既存業務を知ること。
1つの業務を完遂するために、誰が関わっていて、いつ、どのような作業をしているのかという流れを整理します。
イレギュラーケースや帳票類等も明確にする必要があります。
次に、業務の課題を明確にすること。
複雑な工程やミスの多い作業、または1つの業務がどのくらいの頻度で発生し、どのくらい時間がかかっているかも洗い出します。
システム化する際には、この課題を解決できるかどうかがポイントになるため、課題の洗い出しは重要です。
そして、業務の理想形を考えること。
どのような業務の流れにすれば、課題を解決できるのか、これを発注者側もイメージでできていないと、開発会社に依頼することもできません。
この3つのポイントを整理するため、システム開発の前に業務分析は非常に重要です。
既存業務の棚卸し
業務分析の工程においては、業務の流れを可視化する「業務フロー図」を作成します。
ただし、何も情報がない中で業務フロー図を作成することはできません。
まず、既存業務を理解するところから始めましょう。
整理すべき内容は次の通りです。
それぞれ整理のフォーマットを用意しているので、それを参考に業務分析を行います。テンプレートをご確認ください。
尚、作成するにあたってのポイントは、あまり細かくしすぎないことです。
kintoneの良さの1つに、一度作ったアプリを改修しやすいという点が挙げられます。
故に、一発で完璧なものを作るのではなく、運用しながらより使いやすいように、より現場の業務に即したものに改修していく方がDXを進めやすいです。
そのため、業務分析をする際にも、大まかに8割程度理解できるレベルに落とし込めれば充分です。
業務フロー図の作成
整理した情報を基に、業務の流れや担当を図示した「業務フロー図」を描いていきます。
業務フロー図の作成方法は色々ありますが、本記事でご紹介するのは、ノーコードツールの導入を前提とした、簡易的な方法について記します。
まず業務フロー図を作成するにあたって、ポイントをご説明します。
下記の点を抑えて作成していきます。
各種アイコンには次の意味がありますので、それも確認してください。
はじめに、アクターごとにレーンを作成します。
この時、上部に組織外のアクターを並べ、その下に庁内の担当者を並べ、一番下に必ず「システム」のレーンを置きます。
まだシステムが導入されていない場合であっても、kintoneを導入前後の業務フローの変更箇所がわかりやすくなりますので、システムのレーンは用意してください。
次に、最初に作業を行うアクターのレーンに、トリガーを置きます。
例えば県民からの問い合わせを機に始まる場合は、県民のレーンに「問い合わせをする」といったトリガーを設置します。
尚、週次・月次で定期的に行う業務の場合は、「月初の到来」のような内容でも良いです。
トリガーを設置したら、業務の流れに従ってアクティビティを並べていきます。
並べる際には、必ず実行者のレーンに置いてください。
PowerPointの整列機能を使うと視認性が良くなります。
次に、アクティビティを実行する際に利用するシステムを一番下のレーンに記載していきます。
Excelなどの帳票を活用している場合は、その帳票名を記載しておくと良いです。
この帳票を今後kintoneに置き換えることを検討できます。
業務の終わりは、必ず「アロー」または「完了」のアイコンで完結するようにします。
必要に応じてメールや帳票のアイコンや、吹き出しで課題等を追記してください。
業務フロー図を描いてみると、業務が複雑な箇所や、何度も同じ情報を入力している箇所など、課題が視覚的に表れてきます。
この課題について、どう解決するかを検討するのが、DXの第一歩なのです。
将来像を明確にする
描いた業務フロー図を基に、どのように改善するかを検討します。
ここでは、よくある業務改善のポイントについて記します。
電子化によるペーパーレス
帳票をkintoneアプリに置き換えることや、紙面による申請書をWebフォームにすることが検討できます。Excelからの脱却
Excelを利用している場合は、kintoneアプリ化することで同時編集が可能になることや、検索性も高まります。データの一元管理
Excelや紙面で情報を管理していると、同じ情報を様々な箇所に入力しているケースがあります。
kintone上にマスターとなるアプリを用意することで、一元管理することができます。データの集計
議会などに提出するために、定期的に集計を行いレポートを作成している業務については、自動化することができます。
kintoneのグラフ機能やCustomine・krewDataなどのプラグインを活用することで、業務効率化が期待できます。デバイス配布によるどこでも電子化
kintoneはモバイル端末でも利用できますので、外出先で情報を入力することも可能です。
改善の方針が決まったら、改善後の新しい業務フロー図を作成します。
このようなドキュメントは、kintoneアプリ開発を外部事業者に委託する場合においても、エンジニアとの認識齟齬が起きづらくなります。
口頭での説明のみですと、開発されたアプリが全く期待と異なる場合もよくありますので注意してください。
[開発]kintone導入事例
ここでは、実際に自治体向けに開発したkintoneアプリについてご紹介します。
多くの場合、他の自治体で業務が共通していますので、各アプリを流用できると思います。
車両管理
【課題】
■ 公用車の予約を紙で管理している
■ 公用車の空き状況を調べるのに時間がかかる
【システム構成】
kintoneでは、車両管理アプリと、利用申請アプリの2つを作成しています。
車両管理アプリでは、車両の管轄・車種・ナンバーなどの基本情報に加え、現在の予約状況を登録しています。
利用申請アプリは、利用する車両・日時・用途などを管理します。
また、返却登録を容易に行うために、kViewerとフォームブリッジを作成しました。
車両管理アプリイメージ
車両管理アプリには、予め車両の情報とMyページビューのURLを登録しておきます。
予約状況は、利用申請がされるとJavaScriptで動的に登録されるようにしています。
利用申請アプリイメージ
申請者や利用日時、用途を登録の上、上長による承認をできるように設定しています。
【本アプリの使い方】
車両管理アプリから空き状況を確認の上、利用申請を行います。
返却時には使用した車両のMyページにアクセスし、Web上から返却受付を行います。
鍵や車両などに、Myページの二次元コードを貼っておくことで、利用者は自身の携帯端末から容易に返却することができます。
【使用しているプラグインなど】
■ kintoneの基本機能
■ フォームブリッジ
■ kViewer
■ JavaScriptによるカスタマイズ
粗大ごみ収集申請
【課題】
■ 粗大ごみの申請が全て紙で行われている
■ 粗大ごみの申請をするために窓口に行かなければいけない
■ 粗大ごみの申請をする時間帯が限られている(24時間受付ができない)
【システム構成】
粗大ごみの申請フォームを用意し、それを受け付けるkintoneアプリを作成します。
管理する情報としては、申請者・連絡先・収集場所・粗大ごみの内容が挙げられます。
申請した情報については、kViewerのMyページビューを活用し、申請後も内容を確認できるようにしています。
kViewerとフォームブリッジを連携することで、一度申請した内容をキャンセルする機能についても追加実装が可能です。
また、粗大ごみの費用については、マスタデータとしてアプリを1つ作成し管理しています。
【本アプリの使い方】
都道府県・市町村民はWebフォームにアクセスし、粗大ごみの申請を行います。
Webフォームになりますので、申請する時間帯に縛りはありません。
申請内容について、職員はkintoneアプリで確認し、必要情報を記載した上でレコードを更新します。
その内容はMyページビューを介してユーザにも伝えることができます。
【使用しているプラグインなど】
■ kintoneの基本機能
■ フォームブリッジ
■ kViewer
時間外業務申請
【課題】
■ 時間外業務申請が全て紙で行われている
■ 時間外時間の集計に時間がかかる
■ 時間外時間を人事会計システムに入力する手間がかかる
【システム構成】
構成はシンプルで、時間外業務申請アプリと、その内容を月次で集計するためのアプリの2つで構成されます。
月次集計アプリから、JavaScriptで時間外業務申請アプリを参照していますが、これはCustomineでも代用可能です。
月次集計アプリは、会計システムにインポートできるフォーマットで出力するために用意しています。
尚、職員マスタアプリは職員IDを管理するために作成していますが、申請時に自身で入力させる方針でも運用可能です。
【本アプリの使い方】
時間外業務申請をする職員は、申請アプリに日付・時間を入力し登録します。
申請アプリにはプロセス管理を設定しており、職員→上長→人事担当という流れで承認フローが設計されています。
人事担当は、月初に月次集計アプリにアクセスし、年月を選択すると自動的に集計結果が登録されます。
月次集計アプリからCSVを出力し、そのまま会計システムにインポートが可能です。
【使用しているプラグインなど】
■ kintoneの基本機能
■ JavaScript(またはCustomine)によるカスタマイズ
通勤届管理
【課題】
■ 通勤届が全て紙で行われている
■ 通勤時の交通費計算が手間である
■ 人事課との承認プロセスが全て紙で管理されている
【システム構成】
kintoneアプリとしては、通勤届申請をするアプリ1つのみです。
ただ、本アプリでは交通費計算を動的に行いたかったため、NAVITIMEのAPIを利用しています。
【本アプリの使い方】
申請者である職員は、通勤届申請アプリで駅を選択し経路を登録します。
NAVITIME APIを利用し、駅名は検索できるようになっています。
経路を検索すると、サブテーブル形式で候補が表示されるので、該当の経路を選択の上レコードを登録します。
プロセス管理機能にて、上長、人事課に対して承認申請をすることができます。
【使用しているプラグインなど】
■ kintoneの基本機能
■ JavaScriptによるカスタマイズ
■ NAVITIME API
転院調整支援
【課題】
■ 病院間の転院調整が全て電話・FAXで行われている
■ 転院希望の患者を受け入れられる病院がわからない
■ 転院実績のない病院の連絡先がわからない
【システム構成】
大きく3つのアプリから構成されています。
医療機関のマスターデータとなるアプリには、医療機関名称や医療機関コードなどの基本情報に加え、受け入れ可能な患者の条件について登録しておきます。
転院の対象となる患者情報は搬送調整依頼アプリに登録し、ここでは患者の病状や基礎疾患などの情報を登録するだけでなく、調整ステータスも管理しています。
受け入れ可能な医療機関を検索するためのアプリでは、検索結果が地図上にマッピングされるように実装しています。
転院支援アプリイメージ
搬送元となる医療機関の情報と、患者の入院日・病状・転院先の条件などを画面に従って入力していきます。
医療機関検索アプリイメージ
該当の患者を受入可能な医療機関を検索します。
検索結果は地図上に表示され、選択すると詳細の情報を確認することができます。
尚、受け入れ可能な医療機関を、クリック1つで自動的に検索する機能についても別途開発しています。
【本アプリの使い方】
利用する医療機関は、まず自院の施設情報をマスタアプリに登録しておきます(転院元の医療機関、転院先の医療機関共に)。
転院元の医療機関は、転院したい患者について転院支援アプリに情報を入力し、医療機関を検索の上レコードを保存します。
開設されたチャットルームで、転院先の候補となる医療機関と個別にやり取りを行い、転院先が決定したら再度転院支援アプリに転院先の医療機関の情報について入力し更新します。
【使用しているプラグインなど】
■ kintoneの基本機能
■ JavaScriptによるカスタマイズ
■ CSSによるカスタマイズ
■ Google Map API
会員管理(コミュニティ運営)
【課題】
■ 会員の管理を全て紙で行っている
■ 会員への連絡の手段がメールしかない
■ 会員が常に情報を確認できるポータルサイトがない
【システム構成】
kintoneアプリは会員管理・お知らせ管理の2つを作成しています。
それぞれのアプリはkViewerでビューアを作成し、さらにそれをまとめるダッシュボードビューを用意しています。
初回の会員登録については、フォームブリッジで作成した会員登録フォームから登録します。
【本アプリの使い方】
まず申請者は、Webフォームから申請を行います。
申請内容は会員管理アプリに登録されるので、職員は内容を確認の上承認します。
承認時に自動的に申請者にメールが送信され、会員用のダッシュボードへのログイン画面が送られます。
申請者はメールからダッシュボードにアクセスし、会員向けの情報を閲覧することができます。
ダッシュボードビューは複数のビューを1つの画面にまとめることができるので、必要に応じて画面を追加することも問題ありません。
【使用しているプラグインなど】
■ kintoneの基本機能
■ フォームブリッジ
■ kViewer
■ kMailer
■ JavaScriptによるカスタマイズ
補助金申請
【課題】
■ 補助金の申請を全て紙で行っている
■ 申請書の記載ミスの修正対応に時間がかかっている
■ 申請の承認プロセスを全て紙で管理している
【システム構成】
kintoneには申請内容を管理するアプリを用意し、それに紐づくフォームとMyページビューを作成します。
また、Excelでの帳票を出力できるように、RepotoneUを設定しておきます。
PDFで出力する場合は、プリントクリエイターでも問題ありません。
【本アプリの使い方】
申請者は、Webフォームから申請情報を登録します。
補助金を申請する場合の多くは、Excelの帳票に情報を入力してファイルまたは紙面で提出していますが、入力ミスを防ぐために今回はWebフォームからの入力に統一します。
kintoneで申請内容を確認し問題なければ、職員の方で帳票を作成しレコードに保存します。
申請情報はMyページから確認できるようにし、押印が必要な場合はそこから帳票をダウンロードの上提出します。
【使用しているプラグインなど】
■ kintoneの基本機能
■ フォームブリッジ
■ kMailer
■ RepotoneU
kintone活用掲示板
【課題】
■ 各課からkintoneに関する質問対応に追われている
■ 個別対応をしているため、庁内に知見が蓄積されていない
■ 同様の問い合わせに対して、毎回調査を行い回答をしている
【システム構成】
kintoneのスレッド機能を活用し、各課からの問い合わせ窓口を用意します。その上で、問い合わせの対応内容を管理するアプリを作成し、スレッドアクション機能でスレッドと連携を行います。
活用掲示板アプリイメージ
アプリ内には、問い合わせに対する回答内容を登録できるようにします。いつ、誰が、どのように回答したのか、またその際に参考にしたサイトや記事があればそれについても登録しておくと、後で振り返った時に出処を再検索せずに済みます。
また、庁内での活用事例として、kintoneアプリのURLも記載しておくと、具体の利用イメージを伝えることができます。
【本アプリの使い方】
回答内容を取りまとめておくことで、庁内における"kintone Wiki"のように利用します。
kintoneを利用する職員はこのアプリを参照することで、デジタル推進室に問い合わせをする前に解決方法を知ることができます。
【使用しているプラグインなど】
■ kintoneの基本機能のみ
[運用]ガイドライン作成
kintone開発および運用を庁内で内製化する場合、運用ガイドラインを定めておくべきです。
本章では、ガイドラインを作成するにあたり検討すべきポイントについてまとめておきます。
kintoneを管理する管轄を決める
アカウント管理という観点でも当然管轄を決める必要がありますが、重要なのはダブルチェックができる体制を用意しておくということです。
kintoneをはじめとするノーコードツールの良さは、開発スキルのない職員であっても自由に業務アプリを作成できることです。
一方で、どこの課で、どのようなアプリを運用しているのか、庁内で把握できていないのは大きなリスクを抱えることになります。
アプリの実運用を開始する前に、設定に漏れがないか、開発のバグがないか、個人情報の漏洩は問題ないかなど、チェックできる管轄を定め、実運用前に承認するフローを定めるべきです。
またプラグインの利用申請や導入依頼についても、庁内で一元管理すべきです。
プラグインを利用する際にもログインが必要になるケースがありますので、承認フローを設けるのが良いでしょう。
テスト環境を用意する
Excelの帳票がフォルダ内に大量に散在され、それらが一体何のファイルなのか、そもそも使われているのかどうかさえもわからない、という経験はどの組織においてもあると思います。
kintoneにおいても、各課で自由にアプリを作成していると、同様の事態が起きます。
そこで、テスト用のスペースと実運用のスペースを分けておいた方が良いです。
テスト環境で自由にアプリを作成してもらい、管轄の承認を得て実運用のスペースに移していけば、実運用のスペース内が不明なアプリで溢れることはありません。
また、テスト環境は定期的にアプリを見直し、一定期間更新のないアプリについては削除する運用をすることが好ましいです。
ドキュメントのフォーマットを用意する
複数のプラグインやJavaScriptなどによるカスタマイズが入っている場合、1つのアプリを見ただけでは全容が把握できないことも少なくありません。
システムの全容がわかるドキュメントがないと、改修や引き継ぎの時に誰も仕様を把握していないという状況に陥ってしまいます。
ここでは、kintoneアプリの開発に伴い作成しておくべきドキュメントの一例を示します。
アプリの命名規則を定める
アプリの数が増えてくると、一覧で見た時に内容を把握することが困難になります。
そこで、アプリの命名規則を定め、管轄が把握・管理しやすいよう運用するのが良いです。
一例を示すと、
「担当課名_アプリ名称_リリース日」
のように定めておけば、庁内でも管理がしやすいです。
プラグインのガイドラインを作成する
kintoneと同様に、プラグインの運用ガイドラインも用意しておくべきです。
特にkViewerやじぶんページなど、kintone内のレコードの内容を外部に公開する場合、個人情報が一般公開されてしまうリスクがありますので、実運用がされる前にチェックできる体制が必要です。
[応用編]ChatGPTを活用したカスタマイズ方法
JavaScriptによる開発経験がない方は、ChatGPTを活用すると比較的容易にカスタマイズを実装することが可能です。
ChatGPTにで実装する時は、大きく2つの情報を伝えます。
イベント
処理を開始するトリガーとなる動作のこと。kintoneの場合、詳細画面を開いた時、保存ボタンを押した時など、複数のイベントハンドラーが用意されています。(参考:kintone JavaScript API一覧)処理内容
イベントを検知した時に行う具体的な処理の内容のこと。基本的には、どのフィールドに対して、何の処理を行うかという内容を記載します。
例えば、レコードを保存する時に、サブテーブルの行数をカウントし数値フィールドに格納する処理について、カスタマイズしてみます。
次の通りChatGPTに依頼すると、サンプルコードを書いてくれます。
(function() {
"use strict";
// 保存ボタンを押したときのイベントを登録
kintone.events.on('app.record.edit.submit', function(event) {
var record = event.record;
// サブテーブルのフィールドのコード名を確認してください。以下は 'subTable' と仮定しています。
var subTableRows = record['subTable']['value'];
// サブテーブルの行数をカウント
var rowCount = subTableRows.length;
// 「件数」フィールドに行数を格納。'itemCount' を「件数」フィールドのコード名と仮定しています。
record['itemCount']['value'] = rowCount;
return event;
});
})();
上記サンプルコードについて、フィールドコードを修正することで、kintone上で動かすことが可能です。
また、kintoneでJavaScriptによるカスタマイズを行う際には、「JSEdit for kintone」というプラグインがおすすめです。
ソースコードファイルを毎回アップロードしなくても、kintoneの画面上で実装することができます。
さいごに
いかがでしたか。
5年間の自身の開発会社経営経験、および、神奈川県でのDX推進アドバイザーを務める中で、気付いた知見を書き留めました。
ぜひ自治体DXの推進にお役立て頂けますと幸いです。
最後に一つ当社の営業をさせてください。
DXで成果が出せるか出せないかは「業務理解度が高いか?」に帰着します。
ワークログという会社は、ここまで顧客(ここでいう自治体さま)の業務を把握しているんだという事をアピールしたく本記事を執筆しました。
kintone導入の依頼を検討したいという方はぜひご連絡頂けると嬉しいです。
無償でのデモアプリ開発も行っております。
メールでもFacebookでもTwitterでも構いません。
長文にお付き合い頂きありがとうございました。
◆メール
ワークログ株式会社
代表取締役 山本 純平
jumpei.yamamoto@worklog-inc.com
会社アドレス
info@worklog-inc.com
◆Facebook
Jumpei Yamamoto
https://www.facebook.com/jumpei327
※プライベートの投稿の方が多いです笑
一度メッセージを頂けた後で承認後、ご確認ください。
◆Twitter
https://twitter.com/jumpei_worklog
◆ 会社URL
https://www.worklog-inc.com/municipality_lp/