今回は、2回にわたって「kintone開発における情シスの役割」について書いていきます。
kintoneは、現場主導で業務改善を進めやすい一方で、運用ルールや権限管理、開発体制などをどう考えるかによって、使いやすさも定着しやすさも大きく変わってきます。
その中で情シスは、単なる管理者でも、何でも全部引き受ける部署でもなく、現場と全体最適のあいだをつなぐ重要な役割を担います。
また実際には、そうした役割をすべて社内だけで抱えるのは簡単ではありません。
そのため、情シスが担うべきことを整理した上で、必要に応じて外部のプロに任せる、という考え方も大切になってきます。
そこで今回は、cybozu社の kintone SIGNPOST を参考にしながら、
1回目で kintone開発における情シスの役割
2回目で その中でプロに任せると負担軽減しやすい仕事
を整理してみたいと思います。
kintone SIGNPOST
まず今回は、「kintone開発における情シスの役割とは何か」から見ていきます。
kintone開発における情シスの役割とは？
kintoneで業務改善を進めるとき、「現場が作るもの」「情シスが管理するもの」という二択で考えてしまうことがあります。
ただ、kintone SIGNPOSTを見ると、実際はそう単純ではありません。SIGNPOSTでは、プロジェクト開始時に現場メンバーとIT部門の双方が参画すること、それぞれの役割を明確にした上で進めることが示されています。現場メンバーは業務課題のインプットや、プロトタイプの利用・フィードバックを担う立場として整理されています。
つまり、kintone開発における情シスの役割は、「全部自分たちで作ること」でも「現場に全部任せること」でもなく、現場が業務改善しやすい状態を整え、全体最適の観点で支えることだと考えられます。SIGNPOST全体も、企画・設計・運営・継続企画まで含めた流れで、開発後の運用やルール整備まで見据える構成になっています。
現場の声を拾いながら、前に進める役
まず大きいのは、現場と一緒に進める役割です。
現場だけで進めると、業務課題は集まりやすくても、他システム連携や社内ツールとしての位置付け、運用面の整理が弱くなりがちです。逆にIT部門だけで進めると、業務実態から離れたものになる恐れがあります。SIGNPOSTでも、IT部門が参画しない場合、社内の公式ツールとして認知されにくかったり、他システム連携時の協力や許可を得にくくなったりするリスクが挙げられています。
ただし、ここで大事なのは「現場の全員が毎回打ち合わせに出ること」ではありません。
SIGNPOSTは現場メンバーの参画を重視していますが、実務上は、まず現場内で課題や要望を洗い出し、その内容を持った現場代表者と情シスで整理していく進め方の方が回しやすいはずです。これは「現場の声を反映させる」という考え方を、実際に運用しやすい形にしたものです。現場の業務を一番理解しているのは現場であり、現場主体で改善を進めること自体は、kintoneの公式コンテンツでも繰り返し紹介されています。
自由と統制の線引きをする役
kintoneは、思いついた改善を素早く形にできるのが魅力です。
一方で、利用部門やアプリ数が増えると、管理部門を明確にし、運用ルールを整備する必要があることも公式ガイドで示されています。主に管理部門向けの「アプリ運用ルール策定ガイド（基本機能編）」でも、複数部門・複数業務でkintoneを利用する際には、メンテナンス性を保つためにルール整備が必要だと説明されています。
ここでの情シスの役割は、全部を禁止することではなく、どこまでを現場の裁量に任せ、どこからを管理対象にするかを決めることです。
たとえば、部署内の小さな改善は柔軟に進められるようにしつつ、全社利用アプリや基幹データに関わるものは、権限や変更手順、責任者を明確にする。この線引きがあることで、現場のスピード感を損なわずに、後から管理不能になるのを防ぎやすくなります。SIGNPOSTの「アプリ作成ルール」も、アプリや情報が煩雑になることを抑えながら、現場メンバーが業務改善を進められる状態を目指しています。
守るべきデータを見極める役
kintoneはクラウドサービスですが、それだけで「何もしなくてよい」わけではありません。
SIGNPOSTの「守るべきデータ」では、表計算ソフトやオンプレミスからkintoneへ移行することで、データバックアップが不要になると考えてしまうケースに注意を促しています。特に、ユーザーの操作やカスタマイズによるデータ損失は、自動的に元通りにできるとは限らないという前提で考える必要があります。
だから情シスには、何を重点的に守るべきかを決める役割があります。
すべてのデータを同じ重さで扱うのではなく、消えると困るデータ、変更影響が大きいアプリ、慎重に扱うべき連携や権限設定を整理する。これは現場だけでは決めにくく、全社視点を持つ情シスだからこそ担いやすい仕事です。
安全に試せる環境を整える役
kintoneでは、簡単なアプリならアプリの動作テスト機能でも十分な場合があります。
一方で、SIGNPOSTでは、複雑な設定、アクセス権、JavaScriptカスタマイズ、プラグイン設定を伴う場合は、本番とは別の開発環境でテストした方がよいとしています。さらに、開発環境で事前確認してから本番適用することで、不整合によって業務を止める恐れを減らせると整理されています。
ここで情シスに求められるのは、単に作ることではなく、安全に変更できる仕組みを作ることです。
誰が検証するのか、どの段階で本番へ入れるのか、どんな変更は事前テスト必須なのか。こうした開発・反映のルールを整えることは、現場が安心して改善を続けるための土台になります。
トラブル時の受け皿になる役
運用が始まると、開発以上に重要になるのがトラブル対応です。
SIGNPOSTのSTEP5は、運用開始後こそ本番であり、保守やトラブル予防、発生時の対応が必要だと整理しています。また「トラブル対応フロー」では、事前に対応フローを制定・把握しておかないと、切り分けに無駄が発生し、復旧が遅れ、二次トラブルにつながる可能性があると示しています。
このため情シスには、困ったときの最初の受け皿を作る役割があります。
「誰に連絡するか」「まず何を確認するか」「社内で切り分けるのか、ベンダーやパートナーへ相談するのか」を決めておくことで、現場は安心して使えます。開発そのものだけでなく、運営を成立させる仕組みまで含めて情シスの役割だと言えます。
増えても回る状態を作る役
kintoneが広がるほど、現場が自分たちで作れることは強みになります。
一方で、放っておくと似たアプリの乱立や責任者不明、ルール不統一が起こりやすくなります。SIGNPOSTのSTEP6には「担い手を増やす」「アプリ作成ルール」「定期的な棚卸し」などが並んでおり、継続的に使い続けるための体制づくりが重視されています。
情シスは、現場の改善意欲を止めるのではなく、増えても破綻しない仕組みを作る役です。
命名ルール、責任者、作成・変更の手順、拡張機能の管理方針などを整備することで、kintone活用が一部の属人的な取り組みで終わらず、社内に定着しやすくなります。拡張機能の管理ルール策定ガイドも、主にIT部門向けに作られており、利用部門やユーザーが増える際の運用保守の円滑化を目的にしています。
まとめ
kintone開発における情シスの役割は、開発を全部引き受けることではありません。
現場の声を拾い、全体最適の観点で整理し、安全に運用できる状態を作ることです。現場が業務改善の主体になりやすいkintoneだからこそ、情シスには「止める人」ではなく、「回る仕組みを作る人」としての役割が求められているのだと思います。
そして実際には、これらを情シスだけで抱えるのは大変です。
次の記事では、この役割のうちどこを社内で持ち、どこをプロに任せると負担軽減につながるのかを、SIGNPOSTの考え方を踏まえて整理してみます。
