はじめに
こんにちは、IT本部IT戦略部テクニカルオペレーショングループの松本です。
DeNAグループにおけるITシステム・ツールの導入企画から運用管理、運用改善などを担当しています。
DeNAグループでは、物品の購入申請や新規ツールの利用申請など、日々発生するさまざまな業務に「kintoneアプリ」を利用しています。 現在DeNAグループで稼働しているkintoneアプリは、全社で広く使われるものから特定の部署内だけで利用される小規模なものまで含めると、その数は700を超えています。
このブログでは、DeNAグループがどのようにkintoneアプリを管理・運用しているかをご紹介します。すでにkintoneを導入している方、これから導入を検討している方にとって、この情報が活用の一助となれば幸いです。
この記事の流れ
- 「ハイブリッド型」kintoneアプリ作成フロー
- アプリのリリースと「kintoneアプリマスタ」による管理
- アプリ運用において発生してしまう運用課題
- アプリ管理を健全に保つ2種類の「棚卸し」
「ハイブリッド型」kintoneアプリ作成フロー
kintoneの魅力は、誰でも手軽に業務アプリを作成できる点です。しかし、その「自由さ」と、企業として必要な「統制（ガバナンス）」をどう両立させるかが、kintoneを運用していく上での大きな課題となります。
たとえば、アプリの作成や修正を誰でも自由にできるようにすると
- 気軽に作れる反面、アプリが無尽蔵に増殖してしまう。
- 作成したものの完成に至らず、テスト用のアプリなどが放置される。
- 作成者が異動・退職すると管理者が不明になり、修正や削除ができない「野良アプリ」と化す。
といった問題が発生しやすくなります。
一方でアプリ作成や修正をkintoneの主管部門がすべて担う形になってしまうと
- アプリ作成や修正の依頼が主管部門に集中してしまう。
- 要件定義やヒアリングなど、依頼部門との間で多くのコミュニケーションコストが発生する。
- 結果として主管部門がボトルネックとなり、kintoneの強みである「スピード感」が失われてしまう。
といった問題が発生しやすくなります。
そこでDeNAグループでは両者の「良いとこ取り」を目指した、以下のようなハイブリッド型のフローを採用しています。
kintoneアプリ発行のフロー
1.【利用部門】「kintoneアプリ発行依頼」を申請
新しいアプリが必要になった場合、利用部門はまずIT戦略部に「kintoneアプリ発行依頼」を申請します。この申請自体も、専用のkintoneアプリで行われます。
2.【IT戦略部】テンプレートからアプリを作成して引渡し
依頼を受けたIT戦略部は、あらかじめ用意しておいた「テンプレートアプリ」を複製して、新しいアプリを作成します。このテンプレートには、アクセス権限など、IT戦略部がアプリを管理するために必要な最低限の設定があらかじめ組み込まれています。
3.【利用部門】アプリを自由にカスタマイズ
払い出されたアプリのその後のカスタマイズは、利用部門が自由に行います。これにより、現場のニーズに合わせた柔軟な改修が各自で可能となります。
このフローにより、「主管部門による統制」と「現場の自由度」という、相反するように思える2つの要素を両立させています。
すべてのアプリは主管部門(=IT戦略部)の管理下にありながらも、現場のスピード感を損なわない形を実現しています。また、kintoneには業務に適したアプリをテンプレート化している「アプリストア」もあるので、申請時に希望があればそれらをコピーし、必要なアクセス権限などを付与して利用することも許可しています。
アプリのリリースと「kintoneアプリマスタ」による管理
利用部門でのkintoneアプリ開発が完了したら、次は利用者に向けてアプリを公開（リリース）します。
DeNAグループでは、kintoneアプリを社内向けに公開する作業も、IT戦略部が担っています。 kintoneアプリリリースのフロー
開発を終えた利用部門は、アプリ発行を申請したkintoneアプリを使い、今度は「リリース依頼」を申請します。これを受けて、IT戦略部が最終的な公開設定を行います。
アプリ開発後、利用部門ですぐにリリースするのではなく「リリース依頼 → リリース」というプロセスを設けることで、誰が・いつ・どのようなアプリを公開したのかを、IT戦略部が確実に把握できる体制を築いています。
そして、このリリースプロセスにおける最も重要な作業が、「kintoneアプリマスタ」への登録です。
この「kintoneアプリマスタ」も、kintoneで作成した管理用のアプリです。これはDeNAグループに存在する700以上のアプリ管理台帳として機能しており、kintoneにおけるガバナンスの心臓部とも言える存在です。
「kintoneアプリマスタ」には、主に以下の情報が登録されています。
- アプリID・アプリURL： アプリを一意に特定するための情報
- アプリのタイトル・概要： どのような目的のアプリであるかを明確化
- アプリのオーナー（管理者）・オーナー所属部署： 誰がそのアプリの責任者であるかを明確化
- アプリの利用ステータス： 利用中、廃止予定など
- 過去の記事で紹介した承認者リマインダーや作業者アサイン通知の設定状況など
一部しかお見せできませんが、kintoneアプリマスタには下記のような内容で情報が登録されています。
kintoneアプリマスタの例1 kintoneアプリマスタの例2
IT戦略部がアプリをリリースする際に、これらの情報を必ず登録することで、「このアプリの管理者および管理部門が誰なのか？」という典型的な“野良アプリ”問題を未然に防いでいます。特に「利用ステータス」と「アプリのオーナー、オーナー所属部署」は、後にご紹介する「アプリの棚卸し」において極めて重要な情報となります。
このように、DeNAグループではアプリを「作って終わり」にせず、リリース時に必ず管理台帳へ登録することで、その後の継続的な管理につなげています。
アプリ運用において発生してしまう運用課題
kintoneアプリを公開（リリース）する前にアプリマスタに登録することで、アプリの管理を実現できますが、それでも発生してしまう課題があります。
組織変更や人の異動による、マスタ情報の「風化」
1つ目の課題は、時間経過とともに必ず発生する、人と組織の動きです。
- アプリの管理者として登録されていた担当者が、退職・異動してしまった。
- 組織変更により、アプリを管轄する部署が変わってしまった。
といったように、時間の経過とともに「kintoneアプリマスタ」と「運用の実態」との間に少しずつズレが生じてしまうケースです。アプリ自体は問題なく動き続けており利用できるため、実際の運用で困ることはありませんが、情報が古くなっていくことでしだいに管理が難しくなっていきます。
リリース前に放置された「休眠アプリ」の存在
2つ目の課題は、「kintoneアプリマスタ」の管理対象外のアプリです。
DeNAグループの運用では、アプリは「リリース」されるタイミングで必ずマスタに登録されます。 これはつまり、リリースに至らなかったアプリが管理台帳に登録されず、放置されてしまう可能性があるということです。
- 検証目的で一時的に作成し、そのまま忘れ去られたアプリ
- プロジェクトが途中でなくなり、開発途中のまま放置されたアプリ
これらの「休眠アプリ」は徐々に増加し、kintone環境で利用できるアプリの数を圧迫します。（kintoneは契約内容に応じて作成できるアプリ数に上限があります）
また、これらを放置することでアプリの作成・リリースで構築した管理の仕組みが形骸化してしまう恐れがあります。
そのため、定期的に「kintoneアプリの棚卸し」を行うことでこれら管理の問題を是正しています。
アプリ管理を健全に保つ2種類の「棚卸し」
「マスタ情報の風化」と「休眠アプリの発生」という2つの課題を解決するために、目的が異なる2種類の「棚卸し」を定期的に実施しています。
「アプリマスタ」を対象とした“情報の風化”を防ぐ棚卸し
1つ目は、社内に公開済みのアプリを対象とした棚卸しです。その目的は、組織変更や人の異動によって発生する、管理者情報などの「風化」を防ぎ、マスタの正確性を維持することにあります。
1. 対象アプリの絞り込み
稼働している700以上のアプリすべてに対して都度、棚卸しをするとかなりの工数がかかってしまいます。したがって「kintoneアプリマスタ」の情報に基づき、以下の条件で棚卸しが必要なアプリの数を絞ってリストアップします。
- 利用ステータスが「運用中」であること
- 「前回の棚卸実施日」から一定期間（およそ1年程度）が経過している、または一度も棚卸しされていないこと
アプリが作成されたタイミングや棚卸しの実施時期によりますが、毎回200〜300程度のkintoneアプリを対象に棚卸しを実施します。
2. 具体的な作業内容
- アプリオーナーの在籍確認： マスタ上のオーナーが在籍中の従業員かを確認します。
- 棚卸し依頼： 在籍者には棚卸し依頼を一斉通知します。退職者が出ている場合は、部署の連絡先を元に後任者、または上長を探し出し、個別に棚卸しの確認依頼をします。
- オーナーによる作業：継続利用する場合は、「棚卸実施日」を更新してもらいます。利用しない場合は、アプリの削除可否を回答してもらいます。
- 回答後のアプリ削除：オーナーからの回答でアプリを削除してよい場合は一定の猶予期間を設けた後、アプリの削除を実施します。
アプリマスタへの棚卸結果入力例
「開発中」で放置された“休眠アプリ”の発見と整理
2つ目は、リリースされずに開発段階で止まっているアプリ、すなわち「休眠アプリ」を発見し、整理するための棚卸しです。
1. 対象アプリの発見方法
こちらは「アプリマスタ」ではなく、アプリの新規発行時に利用する「アプリ発行依頼（リリース依頼）アプリ」に蓄積されたレコードに着目します。ステータスが「開発中」のまま、一定期間更新されていないレコードを抽出します。
2. 具体的なフロー
- ステータスの変更： 抽出したレコードを、通常のフローでは通らない棚卸し専用のステータス（例：「棚卸確認中」）に変更します。
- 担当者への確認依頼： ステータス変更をトリガーに、アプリの発行依頼者（開発担当者）に通知が飛びます。
- 担当者による作業：開発を継続する場合は、その旨を回答し、ステータスを「開発中」に戻します。開発を中止・放置している場合は、不要である旨を回答してもらい、アプリ削除の合意を得ます。
この仕組みにより、検証用に作成されて放置されたアプリや、プロジェクト中止によって宙に浮いたアプリを確実に捕捉し、不要なkintoneアプリを整理できます。
まとめ
本記事では、700を超えるアプリが稼働するDeNAグループのkintone環境を、どのように管理・運用しているか、その具体的な取り組みをご紹介しました。
現場部門のスピード感と自由度を尊重しながら、主管部門としていかにガバナンスを両立させるか。その答えが、今回ご紹介した「作成からリリースに至るアプリ管理」と「アプリの棚卸し」です。
この仕組みによって、
- 主管部門がアプリの「ひな形」を用意することで、すべてのアプリの存在を初期段階から把握し、責任の所在を明確にする。
- 「情報の風化」と「休眠アプリ」という、時間と共に必ず発生する問題を定期的に洗い出し、是正する。
ことが可能となり、アプリの作成から運用、そして定期的な見直しまで、ライフサイクル全体を網羅することができます。
kintoneは、誰でも手軽に業務を改善できる素晴らしいツールです。そのメリットを最大限に活かすためには、自由な開発を許容しつつ、定期的に手入れ・管理する役割が不可欠だと私たちは考えています。
本記事でご紹介した取り組みが、kintoneの運用に携わる皆さまの参考になれば幸いです。
最後までお読みいただき、ありがとうございました。
最後まで読んでいただき、ありがとうございます！
この記事をシェアしていただける方はこちらからお願いします。