FileMakerで簡易ワークフロー

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

ポータルサイト（FileMaker簡易ワークフロー）Ver.2.1 を公開

  10月 25, 2022    

カスタムApp + アドオン のセットである、ポータルサイト（FileMaker簡易ワークフロー）のセットを公開しました。

ひとりで github flow などしてみながら。


しかし、github クライアントの GitKraken って使い易くないですか？ 



   /

  No Comments

数字の根拠がすぐわかるシステムは良いシステム

  10月 05, 2022    



帳票からデータ構造を考える。今回は「避難者の健康状況調査シート」。（岩手県「市町村避難所運営マニュアル作成モデル」より）

これは一見人数の記録に見えますが、恐らく該当者は誰だ？という話に必ずなる訳で…

数字の根拠が知りたくなる。となると避難者の名簿とリンクして、名簿から該当者を選択するUIがあればいいかな？

 


  1. 症状をクリック＞人を追加＞２名に変わる。
  2. カレンダーをクリック＞６月２８日を選択＞全件表示をOFF＞該当者が表示され、５歳未満１名が誰かがわかる。

症状がある人の数字だけでは、その人をフォローはできないので、数字に該当する人は誰かがわかるようにしました。 



そしてこれに例のアドオンを貼り付けると、受付ポータルシステムの一部として機能する。動画は、担当者が起票した調査シートを管理者がチェックして承認する流れ。こんな風に必要なデータベースを後から追加していく。チケット駆動型プロジェクト管理ツール的なメタ業務システム。 



   / / /

  No Comments

敢えて帳票そっくりの画面にする

  10月 04, 2022    


 これは、岩手県が公開している「市町村避難所運営マニュアル作成モデル」の中の、「様式17　避難所における要配慮者名簿 （PDF 52.6KB）」です。こちらのサイトで公開されています。


この帳票は「名簿」なのに「対応」欄があります。しかし対応を記録するのであれば、履歴がないと何かあったときの経緯がわからない。これはもう「名簿」という名の「対応」記録簿です。


今回は、敢えて帳票そっくりに画面を作りました。帳票が（県）指定の様式なので、結局は様式を作らなければならないし、帳票のレイアウトと画面のレイアウトが同じであれば、急場で集められた避難所のスタッフでも分かりやすいと考えたからです。

次の図はテーブル設計です。「事象」画面は、「日付・特定の人」の一部を表示する。
「特定の人」画面は、「人」の一部を表示する。というテーブル設計にしました。





 データ構造が似ている別のカスタムAppからほぼほぼコピーしてできました。カレンダーは標準のボタンバーでできています。(Webビューア＋JavaScriptではありません。)

  1. カレンダーで日付を選択して、その日の対応を記録する。
  2. 対象者は、人マスターから要配慮者を選択して登録する。



これで最低限のカスタムAppができました。
この画面にポータルサイトとの連携を取るFileMakerアドオンを貼り付ければ、ワークフローシステムとの連携も簡単に実現します。



   / / /

  No Comments

サービスが使えるグループを（値一覧のような）チェックボックスで選択する

  10月 03, 2022    

 


最初は標準の値一覧で実装していましたが、双方向にリレーションを持ちたくなったため、テーブルに変換しました。画面はデバック中の動きです。編集用のポータルは見えないようにレイアウトの領域外に置いて隠したものを本番レイアウトとしました。

値一覧をテーブルにしたもう一つの理由は、選択した値のリストをキーにして、イメージデータをExecuteSQLで取ろうとしてだめだった（ExecuteSQLではFileMakerデータベースのオブジェクトフィールドを取得できない）こと。

しかし、テーブルへ値を追加したいときの実装が、FileMakerだととっても簡単。ポータルの最終フィールドに何か値を設定するだけでリレーションのキーが自動で設定されたレコードがCreateされます。この軽さがローコードの真骨頂。

   / /

  No Comments

実行権限のないボタンが押されたらヘルプメッセージを表示する

  10月 02, 2022    


 

実行権限のボタンは非表示にしていましたが、権限がある人はどんな機能を使えるのかを敢えてガイドするようにしました。

しかし、このような仕様に限らず、スクリプト、カスタム関数、フィールド設定、スクリプトトリガー、条件付き書式などというように、あちこちに依存関係の強い実装をすると、メンテナンスに苦労します。

ということで、カスタム関数に処理機能だけでなく、使用者へのポップオーバーメッセージ用のテキストも持たせて、メンテナンスがしやすいように実装を工夫しています。

仕様を局所化する＝あちこちに依存関係のある実装をしない。



   / /

  No Comments

ワークフローを動的に変化する値一覧で実現する

  10月 01, 2022    



ログインユーザーによって、選択できる値一覧の値を限定できるようにしました。いわゆるワークフローです。 

これをマルチユーザーで実現するには、ユーザー別のスコープとなるグローバルフィールドを使用します。

   / / /

  No Comments

FM-1グランプリに応募しました〜[アドオンがのっかるで賞]いただきました〜

  11月 14, 2021    

FM-1グランプリ2021結果発表が、2021.11.27にありました。[アドオンがのっかるで賞]いただきました。どうもありがとうございました。Apple Storeギフトカード（提供：株式会社イエス ウィ キャン）いただけるとのことで、何か記念になりそうな使い方を検討中です。

振り返ると、実装・テスト・手順書までの全体を完成させてから提出せずに、第一回の予選に照準を合わせるべきだったんだろうなと思っています。最後の締め切りに間に合えばいいのではなく、完成度はさておき、審査員の方々とのキャッチボールを楽しめばよかった。

それはそれとして、応募作品を全部レビューするというのは恐らくどこもやれないのではないでしょうか。これを企画されたiC株式会社さん、合同会社イボルブさん、株式会社未来Switchさんの、参加者との関係性も重視しようとした熱い思いが伝わってきました。

これをまた一つの機会として何かにつながることを期待しています。

レビューいただきありがとうございました。

私は下記に書いてある今後の予定を一つ一つ進めていきたいと思います。

   /

  No Comments

仕事の効率化

  10月 23, 2021    

 Reception for FileMaker (レセプション・アドオン,レセプション・ポータル) を使うとどのような効果が期待できるか考えてみました。

ユーザ視点

  • ワンストップサービス効果
    • 申請先の窓口が別々でもポータルから全様式を提出できるので、窓口はどこか気にする必要がないし、問い合わせでたらい回しにされることもない。
  • ワークフロー効果
    • 進行状況がリアルタイムでわかり、今どのような状況なのかという問い合わせが減る。
  • ペーパーレス&ファイルレス効果
    • 申請用ワークシートをダウンロードして入力し、添付資料として提出するというようなファイルの取り扱いがなくなる。　　

スタッフ＆管理者視点

  • ワークフロー効果
    • メールでのやり取りと異なり、申請状況の管理がしやすい。
    • 審査承認待ちのものはないかなど一括管理がしやすい。
  • 分散管理効果
    • データベースが様式別に分離しているので、様式変更作業などデータベースの一時停止といった保守作業が楽。
  • ペーパーレス&ファイルレス効果
    • 資産管理の面で個人情報や要配慮情報の特定がしやすく、管理策や管理策の実施状況のチェック、リスクアセスメントがやりやすい。

開発者視点

  • 分散開発効果
    • 様式の設計・製造とワークフローを完全に分離でき、並行して開発が可能。
    • 様式の追加によるカスタマイズがしやすい。取りあえず1様式から始めて、様式ができたらサービスに追加する。ものによってはノンカスタマイズで、画面からサービスを追加設定するだけで運用可能。スモールスタートアップ
  • ローコード開発効果
    • 様式の設計・製造にあたるメンバーは、スキル・経験が浅くとも可能。内製化が進めやすい。

しかし、本当の業務改善はこれからです。今までと同じ様式、業務フローで、手間が少なくなるだけでは抱えている問題は解決されないかもしれません。
そのことについての私の呟きはこちら。



   / /

  No Comments

サンプル導入手順

  10月 22, 2021    

Reception for FileMaker サンプルカスタムAPPの導入手順です。
ここを修正しなければ動かないという箇所だけ説明します。

1. 環境

  • FileMakerServer 19~
  • FileMakerPro 19~

2. 用意するファイル

  • portal.fmp12
  • 介護休業申請書.fm12

3. 導入手順

3.1 サインイン

  1. ファイルをホストサーバにアップロードします。
  2. portal.fmp12 を開くと、サインイン画面が表示されます。
  3. "サインイン"を選択し、アカウントID：fm1、パスワード：fm1 でサインインします。
  4. 個人情報の取り扱いについての画面が表示されます。
  5. 説明を読んで同意する場合は、スクロールして"同意する"を選択し、閉じます。
2.サインイン


3.個人情報の取り扱いについて

4.同意する


3.2 環境設定

  1. 画面左上の歯車アイコンを選択すると、環境設定画面が表示されます。
  2. REST APIの設定をします。
    • url_domain 
      • 現在のドメインのURLを設定します。（例：https://byictnet.local）
      • 他の項目は設定済みです。

3.REST APIの設定

3.3 サービス設定

  1. "サービスリスト"を選択し、サービス名＞介護休業申請書＞設定 を選択します。
  2. 外部連携のための設定をします。
    • fmnet
      • FileMakerネットワークで連携する場合に選択します。
  3. 開く
    • FileMaker Server domain
      • カスタムAppが共有されているホスト名を設定します。（例：byictnet.local）
      • 他の項目は設定済みです。
  4. アドオン
    • "アドオンの設定"ボタンでカスタムAppが開きます。
  5. カスタムAppの設定に続きます。
1.サービスリストでサービス設定

2.外部連携のための設定

6.アドオンの設定


3.4 カスタムAppの設定

「3.3 サービス設定」より続く
  1. サンプルカスタムApp・介護休業申請書 が開き、仮レコードを作成して良いかダイヤログが表示されるので、"OK"で続行する。
  2. 設定値の一部を自動で設定したことがダイヤログで通知される。"OK"で続行する。
  3. "件名"にどのフィールドを設定するか決める。例えば介護休業申請書の"名前"フィールドを設定したい場合は、"[氏名]"&介護休業申請書::氏名 を選択する。
  4. "状況"の初期値を選択する。
  5. "詳細"にどのフィールドを設定するか決める。例えば介護休業申請書の全てのフィールドを設定したい場合は、全ての値を選択する。
  6. 設定画面を閉じる。
  7. 介護休業申請書のカスタムAppを閉じる。
  8. 「3.3 サービス設定」の画面に戻るので閉じて設定終了です。
1.仮レコード作成ダイヤログ
2.設定値の一部を自動で設定
3.件名フィールドの設定

4.状況の初期値を選択



5.詳細の設定

6.設定画面を閉じる

7.介護休業申請書を閉じる

8.アドオンの設定画面へ戻る

以上がサンプルの導入手順です。

プリセットされているアカウントは以下となります。
  • fm1 （[Full Access]）
  • user01（一般ユーザ）
  • user02（アカウント管理者）
  • user03（サービス管理者）
  • user04（一般ユーザ）
  • user05（ログ管理者）
アカウントIDのパスワードは、アカウントIDと同じものが設定されています。（例：アカウントuser01のパスワードは、user01）

   / /

  No Comments

業務フロー例

  10月 13, 2021    

 業務フローを２つスイムレーンで書きました。

ケース【申請・稟議】

登場人物
  • Aさん　従業員
  • Bさん　担当者，審査者
  • Cさん　責任者，承認者
概要
  • 従業員が申請し、担当者が審査し、責任者が承認するというシンプルな業務フローです。
  • 申請をアドオンが貼り付けられたカスタムAPPで操作し、審査・承認をポータルサイト（またはカスタムAPP）で操作します。
ケース【申請・稟議】


ケース【不特定多数からの受付】

登場人物
  • ゲスト　申請者
  • スタッフ　担当者，審査者，承認者
概要
  • 不特定の人（アカウントを持たないゲスト）が申請し、スタッフが受付・審査・承認する一般的な受付のフローです。
  • 申請をアドオンが貼り付けられたカスタムAppで操作し、審査・承認をポータルサイト（またはカスタムAPP）で操作します。
  • 申請者は、全員ゲストアカウントでサインインするので、他の人の申請内容を見れないようにするため、ログの一覧画面はスタッフにしか表示されません。
  • また、アドオンが貼り付けられたカスタムAppをダウンロードしてもらい、FileMakerGoでゲストアカウントとして起動し、申請してもらうことも可能です。
  • 本人への連絡は、別の手段（メールなど）を想定しています。
    ケース【不特定多数からの受付】

   / /

  No Comments

こんな機能もあります

  10月 12, 2021    

 Reception for FileMaker の隠れた機能です。

レセプション・ポータル

ゲストによる受付

アカウント登録しなくともゲストでサインインし、サービス＞追加　から申請することができます。申請された内容は、審査・承認するスタッフだけが閲覧可能です。申請者とのやり取りはメールなど別の手段を想定しています。

個人情報保護の管理策

個人情報を扱う場合、個人情報保護法の遵守が必要なので、以下の機能を標準で持たせました。
  • 個人情報の取り扱いについての通知
    • 組織名、個人情報保護管理者
    • 個人情報の利用目的とお預かりする項目
    • 個人情報の第三者への提供について
    • 取得した個人情報の開示等およびお問い合わせ窓口について
  • 同意いただけなかった場合の機能制限
    • サービスが非表示となりデータ登録できなくなる
    • データが非表示となり閲覧できなくなる

レセプション・アドオン

ステルス更新

標準では、アドオンのボタンを押さないとデータを送信しませんが、他のスクリプトやトリガーからステルス更新するスクリプトを呼ぶことで、自動でデータ送信するようにカスタマイズすることが可能です。

言語切り替え

レセプション・アドオンだけの機能ですが、外国人のユーザ向けに、表示する言語を切り替える機能があります。現在は、日本語、英語の２ヶ国語に対応しています。実験的に実装してみました。需要があればレセプション・ポータルにも実装してみようと思います。

言語切り替え・日本語

言語切り替え・英語
 

分散データの紐付け

カスタムApp側から見て、RESTで送信した先の（レセプション・ポータルの）データを更新するにはどうするか考えました。答えは、「レセプション・ポータル側で追加したレコードの主キーをレスポンスで受け取る」でした。
DataAPIのscript.presortパラメータ仕様（Claris）を参照してください。
データを送信したあとレセプション・ポータル側で実行するスクリプトにより主キーを返してもらうという実装をしています。
これによって、分散した複数のカスタムAppでデータを持っていたとしても、レセプション・ポータル側の主キーを付けて送るため更新時にキー重複が起こりません。


   / /

  No Comments

登録: 投稿 (Atom)