設計と構築
3-24
ストック情報中心設計
- 状況
-
kintoneの機能として、アプリのレコード、レコードのコメント、スペースのスレッド、メッセージなど様々な場所で情報が共有できるため、どの項目をアプリのレコードとすべきか悩んでいる。
- 問題
-
情報の性質にあった場所で共有、管理しなければ情報の活用、分析、再利用が難しくなる。
たとえばレコードとして登録されたデータは、集計やCSV形式でエクスポートが可能なため、分析や再利用が容易である。
一方レコードのコメントはAPIを利用しなければエクスポートができないため、分析や再利用には向いていない。また、他システムとの連携やデータ移行時についても考慮する必要があるかもしれない。
- 解決
-
特定の型で蓄積される「ストック情報」はアプリのレコードとして共有・管理し、不定形な「フロー情報」の共有・管理についてはスレッドやメッセージ機能を活用する。
まずは情報をその性質によって「ストック情報」と「フロー情報」の 2 つに分類する：
ストック情報：特定の型によって蓄積され、分析や再利用の対象になるもの
フロー情報：特定の型を持たず、一時的な共有を目的とするものその上でストック情報についてはアプリのレコードとして、フロー情報についてはスレッドやメッセージ機能を活用して共有、管理する。フロー情報の中でも特定のストック情報と紐づくものについては、レコードのコメント機能が適している。
たとえば、「顧客情報」や「案件情報」は各情報において必要な項目は一定の型を持って各項目が入力され、その後のデータ分析や再利用が予想される。ストック情報としてアプリ化しレコードとして蓄積するのがよいだろう。
一方で、その案件に紐づく個別の質問や状況確認等は後々の分析等が不要だと考えられるので、当該レコードのコメント欄でやり取りを行うのが好ましい。コメント欄に残しておくことでレコードと紐付けて集約されるので、後に新規メンバーや第三者がレコード参照する際に、メッセージで担当者に状況の個別確認をする必要がなくなる。
- 結果
-
情報の活用、分析、再利用までを踏まえて考えることで、どの情報をフィールドとして配置すべきかがわかりやすくなるだろう。
また、情報の管理場所をアプリ中心にすることにより、権限の設定や業務の引き継ぎ等が容易になる。
さらに、アプリのレコードを中心としその上でコミュニケーションを取ることで、後に再度情報を参照したい場合に「どこに情報があったか」がわかりやすくなるため、検索に要する時間の短縮にもつながるだろう。
