はじめに

kintoneやFormBridge、kViewerを使って業務改善を進めていくと、アプリやビュー、フォーム、資料などが少しずつ増えていきます。

最初はリンク集のような形でも運用できます。
しかし、数が増えてくると、次のような問題が出てきます。

利用者がどこから目的のアプリを開けばよいか分からない
管理者向けのメニューと利用者向けのメニューが混ざる
全社共通で使うメニューと部門別メニューが混ざる
廃止予定や一時停止中の情報が画面に残る
資料などの入口がアプリとは別になり、探しにくい
メニューのIDや管理番号が後から整理できなくなる

そこで、業務メニューそのものをkintone側で管理し、kViewerでポータルとして見せる構成にしました。

この記事では、画面をきれいに作る話ではなく、増え続ける業務アプリをどう整理し、利用者向け・管理者向け・管理台帳を分けて運用できるようにしたかをまとめます。

なお、kViewerのJavaScript・CSSカスタマイズは、プレミアムコース以上で利用できます。また、JavaScriptによるカスタマイズは動作保証およびサポートの対象外となるため、実際の環境で十分に動作確認したうえで利用してください。リストビューのバージョンによって、JavaScriptカスタマイズのイベントや記述方法が異なる場合があります。実装時は、使用しているビューのバージョンに対応した公式ガイドを確認してください。

この記事で扱うこと・扱わないこと

扱うこと

この記事では、以下を扱います。

業務アプリが増えたときに起きる入口の問題
業務メニューポータルをkintoneとkViewerで作る考え方
親メニュー、子メニュー、資料、お知らせ、管理ツールを分ける理由
全社共通メニュー、部門別メニューの考え方
利用者向け画面と管理者向け画面を分ける考え方
表示区分と公開状態を分ける理由
ID体系と自動採番プラグインの考え方
kViewer上でポータル表示するときの実装ポイント

この記事でいう部門別メニューは、部門ごとに情報を分類して表示する仕組みを指します。ユーザーログイン情報から表示を制御する方法もありますが、自動判定をする認証・権限制御については、本記事では扱いません。

扱わないこと

この記事では、以下は扱いません。

kintoneアプリをゼロから作る手順
kViewerビューの基本設定手順
自動採番プラグインの作成手順そのもの
JavaScriptコード全文の解説
UIデザインの細かい装飾テクニック
認証や権限設計の詳細
外部ツール連携処理の詳細

この記事の主題は、業務アプリの入口を整理し、kViewerで業務メニューポータルとして見せるための設計です。

想定読者

この記事は、以下のような方を想定しています。

kintoneアプリが増えて、利用者向けの入口整理に困っている方
kViewerで社内向け、または関係者向けの業務ポータルを作りたい方
利用者向けメニューと管理者向けメニューを分けたい方
アプリ台帳、資料、お知らせ、管理ツールをまとめて整理したい方
メニューIDや資料IDなどの採番ルールを決めたい方
kViewer上で独自のポータルUIを作りたい方

背景：リンク集だけでは足りなくなった

業務改善が進むと、アプリや関連ビューは自然に増えていきます。

たとえば、以下のようなものが増えます。

申請アプリ
確認用ビュー
承認者向け画面
管理者向け台帳
資料、マニュアル
お知らせ、更新履歴
外部公開API
連携処理

最初は、これらを単純なリンク集に並べるだけでも使えます。
しかし、運用が進むと、単なるリンク集では管理しづらくなります。

特に困るのは、次のような点です。

利用者に見せたいものだけを出し分けたい
管理者向けの情報は別にしたい
全社共通メニューを目立たせたい
部門によって表示するメニューを整理したい
公開中、一時停止、廃止予定を管理したい
IDを後から変えずに管理したい

そこで、ポータル画面だけを作るのではなく、メニューを管理するためのデータ構造から見直しました。

全体構成

今回の構成では、メニュー表示と管理台帳を混ぜないように、アプリを分けて管理します。

アプリ構成は以下です。

アプリ	役割
親メニュー管理アプリ	業務メニューの親単位を管理する
子メニュー管理アプリ	利用者が実際にクリックするリンクを管理する
管理ツール台帳アプリ	kintone、FormBridge、kViewer、外部公開API、外部連携ツールなどの構成情報を管理する
資料・マニュアル管理アプリ	マニュアル、帳票、様式、資料ファイルを管理する
お知らせ・更新履歴アプリ	ポータルに表示するお知らせや更新履歴を管理する
採番台帳アプリ	各アプリのID自動採番に使用する内部管理アプリ

ポイントは、利用者が見るメニューと、管理者が保守する構成情報を分けることです。

親メニューと子メニューを分ける

業務メニューを整理するときに、まず分けたのが親メニューと子メニューです。

親メニュー

親メニューは、利用者が最初に見る大きな入口です。

例：

申請メニュー
確認メニュー
承認メニュー
資料メニュー
管理メニュー

親メニューには、以下のような情報を持たせます。

親メニューID
親メニュー名
概要
検索キーワード
管理部門
全社共通フラグ
初期表示フラグ
管理者向けフラグ
表示区分
公開状態
表示優先度
画像（メニューのアイコン用）

子メニュー

子メニューは、実際にクリックするメニューです。

例：

休暇申請
備品申請
申請状況確認
承認一覧
操作マニュアル

子メニューには、以下のような情報を持たせます。

子メニューID
親メニューID
子メニュー名
表示名
説明
遷移先URL
リンク種別
メニュー区分
区分表示順
表示優先度
対象者
表示区分
公開状態
強調表示
新着表示フラグ

親メニューと子メニューを分けることで、ポータル画面では「大分類から探す」構成にしながら、実際のリンクは子メニュー側で柔軟に管理できます。

共通メニューを作る

今回の設計で重要なのが、共通メニューです。

業務メニューには、特定部門だけで使うものもあれば、全社共通で使いたいものもあります。
これらを同じ一覧にただ並べると、利用者が探しにくくなります。

そこで、親メニューに 全社共通フラグ を持たせ、共通メニューとして表示できるようにしました。

共通メニューを分けると、次のような見せ方ができます。

すべてのアプリ
全社共通アプリ
利用者向けメニュー
管理者向けメニュー
部門別メニュー

このように、同じ親メニュー管理アプリのデータを使いながら、表示の切り口を変えられます。

表示区分と公開状態を分ける

メニュー管理では、表示区分と公開状態を分けることが重要です。

最初は「公開中」「非公開」だけでも良さそうに見えます。
しかし、実際には以下のような状態があります。

利用者向けに表示したい
管理者向けに表示したい
管理台帳にだけ残したい
一時的に非表示にしたい
いずれ廃止するが、すぐには消したくない
下書きとして準備中にしたい

そこで、次の2つを分けて管理します。

項目	役割
表示区分	誰に見せるか、どこに出すか
公開状態	今使える状態か、運用上どの状態か

表示区分

表示区分	意味
利用者向け	一般利用者向けポータルに表示する
管理者向け	管理者、承認者、担当者向けに表示する
管理台帳のみ	利用者には表示せず、管理情報として保持する
非表示	作成中、検証中、一時停止などで表示しない
廃止予定	今後廃止予定だが、一定期間管理上残す

公開状態

公開状態	意味
下書き	作成中
公開中	利用可能
一時停止	一時的に利用停止
廃止	利用終了

kViewer側では、たとえば利用者向け画面なら以下のように絞り込みます。

表示区分 = 利用者向け
公開状態 = 公開中

管理者向け画面なら、以下のように考えます。

表示区分 = 管理者向け
公開状態 = 公開中

このように分けることで、管理台帳としては残しながら、利用者には出さない運用ができます。

管理ツール台帳を分ける

管理ツール台帳は、利用者向けメニューとは分けて管理します。

管理ツール台帳で扱う対象は、たとえば以下です。

kintoneアプリ
FormBridgeフォーム
kViewerビュー
外部公開API
外部連携ツール
リマインドメール
マスタ

これらは、利用者が日常的にクリックするメニューとは役割が違います。
利用者向けポータルに出すよりも、管理者が保守するための台帳として管理した方が分かりやすいです。

管理ツール台帳には、以下のような項目を持たせます。

管理ツールID
親メニューID
種別
管理名
管理URL
kintoneアプリ番号
外部連携ツールのプロジェクト
連携識別子
環境区分
表示区分
公開状態

これにより、ポータル表示とは切り離しつつ、裏側の構成情報を追えるようになります。

資料とお知らせも同じ仕組みに入れる

業務メニューポータルでは、アプリへのリンクだけでなく、資料やお知らせも同じ入口で探せるようにしました。

資料・マニュアル管理

資料管理では、以下を管理します。

利用者マニュアル
管理者マニュアル
帳票
様式
FAQ
手順書
参考資料

資料にも親メニューIDを持たせることで、特定の親メニューに関連する資料を一緒に表示できます。

お知らせ・更新履歴

お知らせでは、以下を管理します。

新規追加
更新
停止予定
障害
重要案内

お知らせには、表示開始日時と表示終了日時を持たせます。
これにより、kViewer側で「今表示すべきお知らせ」だけを出せます。

ID体系を先に決める

メニューや資料が増えてからIDを整理しようとすると、単純に大変です。
そのため、最初にID体系を決めました。

対象	ID形式	例
親メニュー	MENU-0001	MENU-0001
子メニュー	SUB-0001	SUB-0001
管理ツール	TOOL-0001	TOOL-0001
資料	DOC-0001	DOC-0001
お知らせ	NEWS-YYYYMM-001	NEWS-202608-001

IDを分けることで、レコードの種類が見ただけで分かります。

たとえば、問い合わせで「SUB-0012のリンクが開けない」と言われた場合、子メニュー管理アプリを確認すればよいとすぐ判断できます。

自動採番プラグインを使う

ID体系を決めても、手入力でIDを管理するとミスが起きます。

そこで、自動採番プラグインを使い、各アプリのIDを自動で発行する構成にしました。

採番の基本方針は以下です。

運用項目	方針
採番方法	自動採番
欠番	許容
番号再利用	禁止
ID変更	禁止
既存番号	正式IDには使用せず、旧管理番号として任意保存

重要なのは、きれいな連番を維持することよりも、一度発行したIDの意味を変えないことです。

採番台帳アプリの考え方

採番台帳アプリは、自動採番プラグインが参照・更新する内部管理アプリです。

採番台帳には、以下の項目を持たせます。

フィールド	用途
numberingKey	採番単位のキー
prefix	MENU、SUB、TOOL、DOC、NEWSなどの接頭辞
yearMonth	NEWS用の年月
lastNumber	最後に発行した番号
digit	ゼロ埋め桁数
description	採番用途の説明

採番キーは重複禁止にします。
これにより、同じ採番キーが複数作られることを防ぎます。

採番台帳の例です。

採番キー	プレフィックス	年月	桁数	説明
MENU	MENU		4	親メニューID用採番
SUB	SUB		4	子メニューID用採番
TOOL	TOOL		4	管理ツールID用採番
DOC	DOC		4	資料ID用採番
NEWS-202608	NEWS	202608	3	202608 お知らせID用採番

NEWSだけは、月別に採番キーを分けます。
月が替わると、採番台帳に新しいレコードを自動作成し、最終番号が0の状態から採番を開始します。

これにより、NEWS-202608-001のように、年月単位でお知らせIDを管理できます。

kViewerでの表示設計

kViewer側では、親メニュー、子メニュー、資料、お知らせ、管理ツールを外部公開APIから取得し、JavaScriptでポータル画面として組み立てます。

実装上は、以下のような流れです。

kViewer画面に描画用の領域を用意する（kViewerのダッシュボードビュー）
外部公開APIから各アプリのレコードを取得する
公開状態と表示区分で表示対象を絞る
表示優先度で並び替える
トップメニュー、分類メニュー、検索結果、詳細表示を組み立てる

利用者向けポータルで表示するもの

利用者向けポータルでは、利用者向けかつ公開中の情報だけを表示します。

const isPublishedRecord = record => {
  const statusText = toText(getValue(record, FIELD.publishStatus));
  return statusText === '公開中';
};

const isUserVisibleRecord = record => {
  const displayText = toText(getValue(record, FIELD.displayCategory));
  return displayText.includes('利用者向け');
};

const isUserPublishedRecord = record => {
  return isPublishedRecord(record) && isUserVisibleRecord(record);
};

このように、公開状態と表示区分を組み合わせて表示対象を決めます。

管理者向けダッシュボードで表示するもの

管理者向けダッシュボードでは、管理者向けのメニューや管理ツール台帳も扱います。

const isAdminVisibleRecord = record => {
  const displayText = toText(getValue(record, FIELD.displayCategory));
  return displayText.includes('管理者向け') || isCheckedLike(record, FIELD.adminFlag);
};

const isAdminPublishedRecord = record => {
  return isPublishedRecord(record) && isAdminVisibleRecord(record);
};

利用者向けと管理者向けを分けることで、利用者画面はシンプルにしつつ、管理者は必要な情報を確認できます。

トップメニューと分類メニュー

ポータル画面では、トップメニューと分類メニューを分けています。

トップメニュー

作成したトップメニューは、これまでの流れを踏まえて作成したデモのトップメニューです。

トップメニューは、利用頻度の高いメニューを表示する領域です。

親メニューの初期表示フラグを使って、トップメニューに出す対象を決めます。

const topMenuParents = parents.filter(record => includesFlag(record, FIELD.initialFlag));

トップメニューが多くなりすぎる場合は、一定数まで表示し、残りは「もっと見る」で表示する構成にできます。

分類メニュー

分類メニューでは、以下のような切り口でメニューを探せるようにします。

すべてのアプリ
全社共通アプリ
利用者向けメニュー
管理者向けメニュー
部門別

親メニュー詳細で子メニュー・資料・お知らせをまとめて表示する

親メニューを開いたときには、その親メニューに紐づく情報をまとめて表示します。

概要
お知らせ
資料・マニュアル
トップメニュー
新着
メインメニュー

親メニューIDをキーにして、子メニュー、資料、お知らせを関連付けます。

親メニューを中心に関連情報を集約すると、利用者はその業務に必要な情報を1か所で確認できます。

検索機能の考え方

ポータル上では、キーワード検索も用意します。

検索対象は、以下のように分けます。

親メニュー
子メニュー
資料
管理ツール

検索用の文字列は、複数フィールドを連結して作ります。

const searchTextForChild = record => [
  getValue(record, FIELD.childId),
  getValue(record, FIELD.childName),
  getValue(record, FIELD.displayName),
  getValue(record, FIELD.childDesc),
  getValue(record, FIELD.searchKeyword),
  getValue(record, FIELD.parentName),
  getValue(record, FIELD.menuCategory),
  getValue(record, FIELD.linkType),
  getValue(record, FIELD.targetUsers)
].map(toText).join(' ').toLowerCase();

このようにすると、表示名だけでなく、説明や検索キーワードでも探せます。

この設計で得られた4つの効果

1．利用者向け画面をシンプルにできる

利用者向け画面には、利用者向けかつ公開中のメニューだけを表示できます。

管理者向けメニューや管理台帳を混ぜないことで、迷いにくい画面になります。

2．全社共通・部門別を分けられる

全社共通フラグ、管理部門の情報を使うことで、同じデータから複数の切り口でメニューを見せられます。

これにより、全社で使うものと、特定範囲で使うものを分けて探せます。

3．管理台帳として保持しながら、画面には表示しない運用ができる

表示区分と公開状態を分けることで、利用者には表示しないが管理上は保持する、という運用ができます。

廃止予定や管理台帳のみの情報を消さずに残せるのは、保守運用上かなり重要です。

また、アプリや画面の棚卸にも活用できます。

4．IDがあるので問い合わせや保守がしやすい

MENU、SUB、TOOL、DOC、NEWSのようにID体系を分けているため、問い合わせや調査がしやすくなります。

また、自動採番にしているため、手入力による重複や表記ゆれを防ぎやすくなります。

注意点

最初から細かく作りすぎない

表示区分、公開状態、対象者、管理部門などを持たせると、柔軟な運用ができます。
一方で、項目が多すぎると入力負荷が上がります。

最初は、運用に必要な最小限の項目から始めるのがよいです。

表示区分と公開状態の意味を揃える

表示区分と公開状態は、似ているようで役割が違います。

表示区分：誰に見せるか
公開状態：今使える状態か

この意味を運用者間で揃えておかないと、設定がぶれます。

採番後のIDは変えない

IDは、後から変えない前提にした方がよいです。

画面表示名や説明は変わっても、IDは同じままにしておくことで、過去の問い合わせや関連情報を追いやすくなります。

また、CSVなどを使ってレコードを一括登録する場合は、採番の整合性が崩れないように注意が必要です。

外部公開API利用時の注意

外部公開APIで取得する項目やレコードは、公開して問題のない情報に限定します。認証、アクセス制御、APIの公開範囲については、実際の運用要件に応じて別途設計が必要です。

まとめ

kintoneやkViewerで業務アプリを増やしていくと、アプリそのものよりも、入口の整理が重要になります。

今回のポイントをおさらいします。

親メニューと子メニューを分ける
利用者向けと管理者向けを分ける
管理ツール台帳は利用者向けメニューから分離する
資料やお知らせも親メニューに紐づける
全社共通、部門別の切り口で探せるようにする
表示区分と公開状態を分ける
ID体系を最初に決める
自動採番プラグインでIDを発行する
kViewerでは外部公開APIのデータを組み合わせてポータル画面を作る

業務メニューポータルは、単なるリンク集ではなく、業務アプリを継続的に管理するための仕組みです。

画面を作る前に、データ構造、表示区分、公開状態、ID体系を決めておくと、後からアプリが増えても整理しやすくなります。