FileMakerで簡易ワークフロー

チームワークに必要なワークフロー。オンプレもOKなFileMakerで。

FileMakerで簡易ワークフロー

これは何をモチーフにして作られたもの？

  • 入力フォームが簡単に作れて、Redmine（チケット駆動型プロジェクト管理システム）のようにチケットと連携するようなシステムが出来ないだろうかと思って作りました。
  • 一般企業であれば、社内の様々な申請や問い合わせをチケットのように受け付け、対応遅れや対応漏れがないように状況を管理する、申請受付業務の支援に応用できるし、避難所であれば、避難者名簿、物資の管理簿、公的機関へ提出する資料作成といった、避難所運営の支援へ応用できるかなと。
  • 同時アクセス数が10程度のトランザクションを想定しています。クライアント側はブラウザでアクセスすることを前提にWebDirectが基本。
  • Redmineであれば、申請の様式に合わせてカスタムフィールドを追加して対応するところでしょうが、フィールドの数や様式の数、入力時のエラーチェックを考えると、CSSやプラグインの作成が（多分）必要となります。このようなRedmineを拡張して運用するのは、私にはハードルが高過ぎでした。
  • 思い付いたのは、申請書の様式に合わせたFileMakerのフォームへ入力し、アドオンのボタンを押すと、別システムにチケットを登録するという仕組み。最も手作業がかかるのは、様式に合わせた入力画面と入力時のエラーチェックの作り込みです。これを１様式ごとに１つのカスタムAppを作ることにしました。１様式に必要な要件を１つのカスタムAppに収めることにより、開発の難易度を低く抑えることができます。また、１人が１つのカスタムAppを作成すれば、複数人での並行作業ができると考えました。
  • 各申請書の様式ごとに作られたカスタムAppに貼り付けるアドオンは、cURLを使ったRESTによる通信でチケットを登録します。
  • ちなみに、本システムでは、チケットに相当するものを「ログ」と呼びます。

これは何のためのシステム？

  • 申請・受付のワークフローを可視化し、申請者の（現在どのような状況なのかわからない）承認待ちでのストレス低減や、受付が滞っている案件を発見しやすくし、申請・受付をスムーズに運営するためのシステムです。
  • 入力画面を１様式１カスタムAppとしたことで、システムがシンプルとなり、数ある申請書の入力画面の製造を複数名による並行開発で対応することが可能となります。システム開発の効率を上げたり、保守できる人を増やして、プロダクトを維持するエコシステムを作り易くするといった、特定の開発者に依存せずにサービスを継続するためのシステムです。
  • インターネットを必要としないので、災害時にインターネットが使えなくなった避難所など、閉塞されたネットワークでの利用が可能です。
  • １つの申請様式を１つのカスタムAppとしているので、様式が追加になったとしても、サービスを止めずに機能を追加することが可能です。

どんな動き？

  1. 管理者は、色々なカスタムAppをサービス一覧として登録しておく。
  2. 利用者は、サービス一覧からカスタムAppを起動する。
  3. 起動したカスタムAppのアドオンが、ログを送信し、ポータルが受信する。
  4. 管理者は、ログを確認して状態を変更する。（例：「申請中」から「審査中」など）


どうやって作る？

  1. カスタムAppを作る。
    1. 入力用のレイアウトを作成する。申請書と同じ入力画面を作る場合、PDFを背景イメージとして読み込み、フィールドを追加していくと楽。
  2. アドオンを貼り付ける。
    1. 入力用のレイアウトにアドオン（Reception for FileMaker）を貼り付け、設定画面で連携するワークフローサイト（portal）サーバの設定等を行う。
  3. カスタムAppをFileMakerServerへアップロードする。
  4. カスタムAppのファイル名と入力に使うレイアウト名をワークフローサイト（portal）の「サービス」メニューで追加する。
  5. ワークフローサイトとアドオンを紐付けるための設定を追加する。

ここまでのまとめ

現在使っている申請書（PDFなど）をそのまま入力画面（カスタムApp）化し、入力したらアドオンを経由してワークフローサイトに送信します。１様式１カスタムAppなので、ワークフローサイトを止めることなく様式を追加できます。データの正規化やワークフローの見直しは運用しながら考える。そんな現場でのプロジェクト管理を素早く立ち上げたいチームのためのカスタムAppです。最もハードルの低いDXの導入方法です。

５コマで表現するとこんな感じ。



要件は？

このシステムは、申請を受け付けるワークフローを想定したフレームワークです。このワークフローを使って、様々な申請を受け付ける現場へのDX導入が可能となります。

申請を受け付ける現場の汎用的な要件を列挙してみます。

グループとユーザー、サービス、ログの関係について

  • グループには、メンバーが含まれる。
  • グループのメンバーは、管理者か利用者として登録されている。
  • グループには、メンバーが利用できるサービスが登録されている。
  • グループの利用者は、グループで利用できるサービスにアクセスし、データを入力する。
  • グループの利用者は、データを入力したことを管理者宛にログとして通知する。（申請）
  • ログには、申請状況（例：申請中、審査中、承認済み、差戻し等）が含まれる。
  • ログには、申請した人が、コメントを入力できる。
  • グループの利用者は、自分が入力したサービスのデータを修正できる。
  • グループの利用者は、自分が入力したサービスのデータを修正したことを管理者宛にログとして通知する。
  • グループの管理者は、グループの利用者が入力したサービスの内容を確認できる。
  • グループの管理者は、グループの利用者が入力したサービスの内容を確認した結果をログとして追加できる。
  • グループの利用者と管理者が登録した申請に紐付いたログは、利用者本人とグループの管理者が一覧できる。
  • グループの管理者は、申請状況を一覧し、受付業務が滞っているものを検索し対応する。（プロジェクト管理機能）

    リレーションシップの設計

    テーブルオカレンス（TO）図を一部作成しました。実テーブルを左に縦に並べて、右にリレーションを伸ばします。


    セキュリティは？

    データ保護のための管理策アレコレ

    個人情報や機微な情報を扱うことを前提にすると、個人情報保護、プライバシー保護の観点での設計が必要となります。 そこで、アカウントの属性に応じた、各場面での制限事項を予め決めておかなくてはいけません。
    1. 個人情報の取り扱いについて同意を得る。
      • 個人情報の取り扱いについて通知した内容に同意していなければ、データが表示されないようにする。
    2. 使えるメニューを限定する。
      • アクセス権セットにより、必要以上にFileMakerの基本機能についての操作権限を与えないように、使えるメニューを限定する。
    3. グループで使えるサービスを限定する。
      • アカウントが属するグループという概念を導入し、グループが利用できるサービスを限定することにより、必要のないサービスを使わせないようにする。
      • アカウント権セットやグループにより、非活性となるメニュー項目を定め、必要のないメニューを起動させないようにする。
    4. 使えるステータスを限定する。
      • 個々のデータ（ログ）のステータスを変更する際、グループ内でのその人の権限により、変更できるステータスの範囲を限定し、権限のない者が、勝手にステータスを変更できないようにする。

    アクセス権セットの設計

    FileMakerのセキュリティ管理画面で設定するアクセス権セットは、スクリプトでコントロールできないので、[完全アクセス]のメンバーが個別に手作業で割り当てる必要があります。アクセス権セットを割り当てるタイミングは、このシステムの最初の画面でメンバーが「アカウント作成」した後に行います。


    セキュリティ関連の処理シーケンス

    1. ログインシーケンス
      • 個人情報の取り扱いについて、同意されているかをチェックし、同意されていなかったら、同意画面を表示する。
    2. メインウィンドウ表示シーケンス
      • メニュー表示時に、アカウントに割り当てられているアクセス権セットと、自分が管理者として属するグループにより、表示するメニューを限定する。
    3. ログウィンドウ表示シーケンス
      • ログの詳細ウィンドウを表示する際に、自分が管理者か利用者かを判定し、権限に応じたステータスの値一覧を取得し、変更可能なステータスを制限する。
    登録: 投稿 (Atom)