1. 疎結合な設計とは...
1.1. 「疎結合」っというキーワード
1.1.1. 広義の疎結合
1.1.1.1. ITワールドのお話
1.1.1.1.1. EAとか
1.1.1.1.2. MicroServiceとか
1.1.1.1.3. MVCモデル
1.1.1.1.4. e.t.c...
1.1.2. 狭義の疎結合
1.1.2.1. FileMaker村のお話
1.1.2.2. 本日は主にこちら
1.2. IT用語辞典からの引用...
1.2.1. 各要素が互いに深く結びついてはおらず
1.2.2. 一部分の変更が他の要素に影響を及ぼす度合いが小さい
1.2.3. メリットとして...
1.2.3.1. 互換性や拡張性、担当や責任の分担のしやすさ
1.2.3.2. 不具合発生時の原因追及のしやすさなどで優れるが
1.2.4. 弱点として...
1.2.4.1. 要素間の連携や通信にかかる負荷が大きく
1.2.4.2. 性能や必要な容量などで不利になることがある。
1.2.5. さて、ここで重要なこととして
1.2.5.1. 「疎結合な設計」には明確な定義があるわけではない！
1.2.5.2. 疎結合とは「絶対的定義」ではなく「相対的な状態」
1.2.5.3. なので
1.2.5.3.1. 「これは疎結合じゃない！」っとかdisるのは
1.2.5.3.2. 事の本質から外れているっていう認識が重要
1.2.5.4. 大切なのは
1.2.5.4.1. 「疎結合な設計」はソフトウェアライフサイクルを円滑に管理するための「手段」である
1.2.5.4.2. あくまでも「手段」なので、様々な環境変数、例えば...
1.2.5.4.3. これらのことを考慮して「各要素間の結合度」を調整することが重要
1.2.5.4.4. 「疎結合な設計」で実装することが目的ではない
1.2.5.5. なのでこれから話すことも...
1.2.5.5.1. あくまで「私」とか「私と一緒に開発している開発チームのメンバーさん」が
1.2.5.5.2. 心地よい状態の「疎結合度」であって
1.2.5.5.3. 絶対的な正解ではない
1.2.5.5.4. ...っということを前提にお聞きください。
1.2.5.6. それでは
1.2.5.6.1. 中身に入っていきます。
1.3. 「疎結合」の解説にある各要素の「要素」とは？
1.3.1. FileMakerのソリューション構成要素
1.3.1.1. fmp12ファイル
1.3.1.2. テーブル（ベーステーブル）＆フィールド
1.3.1.3. レイアウト
1.3.1.4. スクリプト
1.3.1.5. テーブルオカレンス
1.3.1.6. カスタム関数
1.3.1.7. テーマ
1.3.1.8. ユーザアカウント
1.3.1.9. e.t.c...
1.3.1.10. これらの各要素が「深く結びついていない」=FileMaker的疎結合？
1.3.2. 個人的「FileMaker的疎結合な設計」の３本柱
1.3.2.1. コンテクストフリーなスクリプトとカスタム関数
1.3.2.2. 論理的なファイル分割
1.3.2.3. モジュール指向なテーブルオカレンスグループ
1.3.2.4. あとなにか「これも加えたほうがええんちゃう？」っというのがあったら
1.3.2.5. ご指摘お願いします。
2. 疎結合な設計のメリット・デメリット
2.1. メリット・デメリットはFileMakerでも同じ...？
2.2. 互換性や拡張性、担当や責任の分担のしやすさ 不具合発生時の原因追及のしやすさなどで優れる
2.2.1. FileMakerの一番大きな「要素」であるファイルを分けての疎結合化を考察してみる
2.2.2. なんでファイルを分割する？
2.2.2.1. トラブル対応時
2.2.2.1.1. １ファイルで構成されるソリューションで30のテーブルが保存されているファイルが壊れた
2.2.2.1.2. 10ファイルで構成されるソリューションで、とある2テーブルが保存されているファイルが壊れた
2.2.2.1.3. （一概には言えないが）影響範囲は当然後者のほうが小さい
2.2.2.1.4. （一概には言えないが）トラブルシューティングに要する時間も後者のほうが小さい
2.2.2.2. バージョンアップ時
2.2.2.2.1. 特定のファイルのみをfmDataMigrationToolでデータ移行すればOK
2.2.2.2.2. データ移行は一般的に管理者のローカルPCで実施
2.2.2.2.3. 移行対象ファイルが適切に分割されていれば、移行作業が短時間で済む
2.2.2.2.4. 短いシステム停止時間でバージョンアップ作業が完了する
2.2.2.3. ...っと、こんなメリットが考えられる
2.2.3. では実際の分割手順を...
2.2.3.1. インタフェースとデータファイルを分ける
2.2.3.1.1. 一般的に「分離型」とか「SeparationModel」と呼ばれる
2.2.3.2. データファイルを役割や特性によって分ける
2.2.3.2.1. 想定される分割軸
2.2.3.2.2. 実際に分割してみた例
2.2.3.3. インタフェースファイルを...
2.2.3.3.1. サブシステムで分割する
2.2.3.3.2. 実行プラットフォームで分割する
2.2.3.3.3. 開発担当者で分割する
2.2.4. 具体的に分けた結果を見てみる
2.2.4.1. LucidChart
2.3. 要素間の連携や通信にかかる負荷が大きく 性能や必要な容量などで不利になることがある
2.3.1. うーん...
2.3.1.1. 一般論的には
2.3.1.2. WebAPI等で接続すると、こういう問題出るかも
2.3.1.3. ClarisConnectをソリューションに取り入れた場合でも、恐らく同じ課題が出る
2.3.2. んじゃFileMaker的には？
2.3.2.1. 単純に開発者の作業や管理が面倒くさくなる
2.3.2.2. でもチーム開発するのであれば、むしろ適切に分割されていた方が作業しやすい
2.3.2.3. 疎結合な設計にした場合のFileMaker的な課題
2.3.2.3.1. fmp12ファイルが主なスコープという仕様の課題
2.3.2.3.2. リレーションシップグラフ課題
2.3.2.3.3. ...っということで
2.3.2.3.4. ...でも
3. まとめ
3.1. キーワード「疎結合」
3.1.1. 絶対的な定義や正解があるわけではない
3.1.2. 各々の環境変数に応じて最適な「結合度」は変わる
3.2. FileMaker的疎結合な設計のキモ？
3.2.1. 疎結合な設計の３つの軸
3.2.1.1. コンテクストフリーな
3.2.1.1.1. スクリプト
3.2.1.1.2. カスタム関数
3.2.1.2. 論理的＋戦略的なファイル分割
3.2.1.3. モジュール指向なテーブルオカレンスグループの設計
3.2.2. 適切にファイルを分割することで...
3.2.2.1. 機能の追加・修正に対して影響の出るファイルが限定される
3.2.2.2. 限定される結果、デグレード等の機能追加・修正に伴うバグを仕込んでしまう
3.2.2.3. リスクを軽減できる
3.2.3. 例えば...
3.2.3.1. 今回のLIFE加算機能を実装するときも
3.2.3.2. 必要な機能だけを、全く別ファイルで実装し
3.2.3.3. 既存のソリューションから必要な時に、必要な機能を呼び出す設計にすれば
3.2.3.4. 現バージョンのソリューションに対するインパクト（修正量）は小さくてOK
3.2.3.5. 結果的に開発工数（特にテスト工数）をへらすことができる
3.2.4. ただし...
3.2.4.1. 戦略なきファイル分割は、かえって泥沼化を招く危険性がある
3.2.4.2. どのようなファイル分割が最適なのかは
3.2.4.3. 様々な環境要因によって変わるので一概には言えないけど...
3.2.5. 少なくとも、おじさん的には
3.2.5.1. データファイルとそれ以外は分ける
3.2.5.2. インタフェースファイルは、サブシステム毎に分ける
3.2.5.3. ただしインタフェースファイルを分けるのであれば
3.2.5.3.1. FileMakerの仕様制限対策が必要
4. 自己紹介
4.1. 現在
4.1.1. 株式会社ライジングサン・システムコンサルティング
4.1.2. 代表取締役
4.1.3. 株式会社だけど、雇用している社員さんはいません
4.1.4. 俗に言う「一人親方」です。
4.1.5. 仕事をするときには、開発パートナーさんと一緒にプロジェクトチームを組むようにしています。
4.2. 事業内容
4.2.1. FileMakerプラットフォームを主軸とした内製化支援
4.2.1.1. ←これがメイン
4.2.2. プロトタイプアプリケーションの開発
4.2.3. 他言語プログラマさんの技術移行支援
4.2.4. 裏メニュー
4.2.4.1. 一般的な受託開発もやっている
4.2.4.2. ※ただし準委任契約専門
4.2.4.3. 稀に「内製化ギブアップ」な企業さんが出るため
5. FileMaker的疎結合を乗り切る工夫
5.1. アンカーブイモデルを採用する。その心は...
5.1.1. TOG=モジュール
5.1.2. TOGを一つの「モジュール」として考える
5.1.2.1. 「モジュール」なのでできるだけ小さく
5.1.2.1.1. ←移植作業が大変になる...
5.1.2.2. 「モジュール」なのでポータブル
5.1.2.2.1. 仮にファイル間に重複して同じTOGを保つ場合でも
5.1.2.2.2. 比較的簡単に移植作業が可能
5.1.3. 参考動画
5.1.3.1. 改めて考えるアンカーブイの操作方法と実践
5.1.3.2. 【FileMaker△アンカーブイ】でYouTubeを検索！
5.2. リレーションシップグラフは秩序を持って管理
5.2.1. 命名規約の死守
5.2.1.1. 自作ツールをつくるなら必須
5.2.2. 同じようなリレーション設定をあちこちに作らない
5.2.2.1. 非保存の計算フィールドを有効活用する
5.2.2.2. fmdAPIのメリットも活きるようになる
5.2.3. リレーションシップグラフがタブ分けできるとよいのに...
5.3. サポートツールの導入
5.3.1. サードパーティ
5.3.1.1. fmPerception
5.3.1.1.1. ←ファイル間のdiff（差異）を取るのに優れたツール
5.3.1.2. BaseElements
5.3.1.2.1. 最近使ってないけど、FileMakerでカスタマイズできるのが魅力！
5.3.1.2.2. DDRが自動出力できるようになると最強のリバースエンジニアリングツール？
5.3.1.3. Clip Manager
5.3.1.3.1. FileMakerの共通ライブラリ管理ツール
5.3.1.3.2. XMLエディタでもある
5.3.1.3.3. 最新バージョンがコケまくる
5.3.2. プラグイン
5.3.2.1. MBS Plugin
5.3.2.1.1. 色々便利
5.3.2.2. 2empower Develoepr Assistant
5.3.2.2.1. 色々便利
5.3.3. 自前ツール
5.3.3.1. デモ