kintoneこうしておけばよかった
はじめに
kintoneの効果的な活用のために、こうしておけばよかったメモ。
kintoneの価値とは
触ってみて感じているkintoneの価値。これの最大化を目指す構成にするべきだったが、いろいろな事情でそうなっていない。
メリット1. 台帳+ワークフローがセットとなっている
主要な台帳は必ずワークフローとセットとなっており、ワークフローから台帳への転記が容易になっている。それによってワークフロー→台帳、台帳→ワークフロー(例：業務委託契約台帳アプリ→業務委託契約更新申請アプリ)がスムーズに作業できる。手作業による転記ミスや抜け漏れを防ぎ、業務効率を大幅に向上できる。
メリット2. 細かいアクセス制限がかけられるデータベース
例えば社員台帳では採用媒体、生年月日など、一部のチーム以外には見せたくない項目に制限をかけられる。この機能があるため社員の概要は全員が参照でき、情報共有や集計に貢献でき、同じアプリ内で複数の権限のアクセスが共存できる。情報の透明性を確保しつつ、セキュリティが強化されたデータベースの構築が可能になっている。
メリット3. 誰でも編集しやすいUI
以下サイトにまとまっている。 ただし、誰でも編集しやすいためガバナンスも重要になってくる。
こうしておけばよかった
スペース設計
kintoneには通常のメンバーよりも安価なゲストユーザーがある。ゲストユーザーは招待されたゲストスペースでのみアクセスできる。
そのため、スペースは部門(または業務パッケージ)単位でまとまっている方が望ましい。ゲストユーザーとして招待しやすいため。
アプリ設計_1 ヒトのDB
現状、以下のように雇用形態や契約フェーズごとにアプリが分断されている。
- 社員DB
- 業務委託契約DB
- 業務委託契約開始DB
- 業務委託契約更新DB
- 業務委託契約終了DB
問題①
「社員DB」では社員番号が個人のIDとして機能するが、「業務委託契約DB」では契約IDが主キーとなる。これにより、同一人物であるにもかかわらず、複数(複数期間)契約がある場合IDが異なり、データの関連付けが困難になる。
正社員から業務委託へ、といった雇用形態の変更が発生した場合、手動でのデータ転記作業が必要となり、工数を要する。また、新しく発行された業務委託の契約IDを無視し、以前の社員番号を使い続けるといった、本来の運用ルールから外れたイレギュラーな対応が発生してしまう。
こうできたら
そこで、以下のように「人」そのものの情報と、「雇用契約」に関する情報を分離・統合する構成のほうが良かったと考えている。
人DB
個人の普遍的な情報を一元管理するアプリ。雇用形態の変更に影響されない、その人固有の情報を管理する。
ただし、他SaaSへデータを更新する場合は人DB+雇用DBをjoinしてとる必要がある。また、雇用開始のときの2アプリを追加しないといけない。
雇用DB
できれば社員DBの一部と業務委託契約DB + 業務委託契約開始DB + 業務委託契約更新DB + 業務委託契約終了DBを統合できればよい。
その場合、DBとしてステータスを持つことになり
- 雇用前
- 雇用中
- 雇用終了
となる。正社員と業務委託契約によって分ける必要があるかもしれない。
終わりに
どんなツールも千差万別であり、そのツールを最大限活用できる運用方法があると思っている。「こうすればめっちゃうまく運用できるのでは？」という閃きは事前検証中に思いつくと最高だけど、だいたい運用に慣れてきたときに思いつくことが多い。そう考えると、「失敗したな」と思ったタイミングもエンジニアリングにとっては貴重な瞬間になる。
Discussion