こんにちは。
ライジングサン・システムコンサルティングの岩佐です。
このブログ記事では、FileMakerプラットフォームを用いたシステム開発における「チーム開発」の要点についてお伝えします。
一般的に（？）、FileMakerプラットフォームはチーム開発がしづらいと認識されているようです。
確かに、これまでのようなウォーターフォールモデルにおける「分業」を前提としたチーム開発だと、これを機能させることは困難です。
しかし、FileMakerプラットフォームでも、適切な工夫をすることでとても強力なチーム開発を実現することが可能です。
この記事では、このチーム開発を機能させるために必要な３つの要点をお伝えします。
目次
要点１：水平分担ではなく垂直分担でチーム編成する
水平分担とは、一般的なウォーターフォールモデル開発で見られる、フェーズごとに役割分担を設ける方法です。
例えば要件定義と基本設計はAさん＋Bさん。
その後の設計フェーズはCさんとDさん。
プログラミングと単体・結合テストはEさん＋Fさん＋Gさん。
システムテスト以降はHさん＋Iさん。
…と、このように、開発フェーズ毎に担当者を設ける方法です。
一方の垂直分担とは、スクラム等のアジャイルソフトウェア開発で求められる「多能工」を前提としたチーム編成です。
1-1.開発者に求められるのは「多能工」
例えばスクラムでは、「コンサルタント」「DBエンジニア」「NWエンジニア」「プログラマ」といった職能による担当分けは推奨されません。そして技術者は「多能工」として、あらゆる技術タスクを担当できるスキルを要求されます。
水平分担と垂直分担は、製造業における「ライン生産方式」と「セル生産方式」に例えると分かりやすいかもしれません。
水平分担はライン生産方式、垂直分担はセル生産方式ですね。
FileMakerプラットフォームで開発する場合は、このセル生産方式に似た垂直分担によるチーム編成をすべきです。
なぜなら、水平分担では、FileMakerプラットフォームの持つ柔軟性や開発生産性の高さを十分に活かすことができないからです。
1-2.サブシステム毎に開発担当者をアサイン
弊社がチーム開発を行う場合、システム全体を幾つかのサブシステムに分割します。
そして担当者AはサブシステムAを、担当者BはサブシステムBを、それぞれアタマからオシリまで全て担当します。
ひとりの担当者が、サブシステム全体を担当するので、その技術者には当然「多能工」であることが求められます。
すなわち「私は設計書が無ければプログラムはかけません」では、垂直分担のチームでは機能しないということです。
担当した人間は、顧客との対話によって導き出された要求を、自分で咀嚼しながら、設計、実装してテスト、更にはリリース前のユーザトレーニングや、リリース後の運用・保守までをも担当します。
もちろんこの間、チームメンバー同士で活発にコミュニケーションを取りますが、こと「具体的な作業」に関しては、ひとりの担当者がひとつ、もしくは実力次第で複数のサブシステムを担当します。
このような垂直分担のチーム編成をすることで、複雑で変化の激しいソフトウェア開発プロジェクトでも柔軟に対応できるようになります。FileMakerプラットフォームを選択する理由のひとつは、仕様変更に柔軟に対応できることです。
しかし、その柔軟性を発揮するには、それにふさわしいチーム編成が必要です。
そのためには、従来のような「変化に弱い」ウォーターフォールモデルを前提とした水平分担によるチーム編成ではなく、変化に強いアジャイルソフトウェア開発モデルを前提とした垂直分担によるチーム編成が最適なのです。
要点２：システムの「要」となるDB設計（ER設計）は全員で行う
弊社でチーム開発を行う場合、このシステムの心臓部というべきDB設計は、チーム全員で行うようにしています。
その理由は、FileMakerプラットフォームを用いたソフトウェア開発の最重要課題が、このDB設計だと考えるからです。最も重要なドキュメントであるということは、設計ミスがあった時の影響範囲がそれだけ大きいということです。
ですので、DB設計については複数人の知見に晒すことで、より洗練するように心がけています。
2-1.ER図が70%完成するまでは実装に着手しない
また、私たちはER図が７〜８割程度完成しないかぎり、FileMakerを使った実装作業には入りません。そもそもこのレベルまでER図が完成していないうちから、具体的な実装に入っては行けないと考えています。
中には、ER図を書くこと無くいきなり実装を始めてしまう「無謀な開発」を繰り返す自称FileMakerのプロフェッショナルもいらっしゃるようですが…
私たちは洗練されたER図が出来上がれば、そのシステムは概ね半分はできあがったと考えています。さらに、ER図の良し悪しで、そのシステムの将来の拡張性、保守性が決まると考えています。
拡張性、柔軟性が高いシステムということは、将来に渡ってビジネスに貢献し続けられる寿命が長いことを示します。
ですので、これは単なる技術論ではなく、ビジネスという側面からみても極めて重要な事なのです。
2-2.最新のER図はクラウド上で共有する
最近は、チーム開発を行うにも、メンバーが異なる場所で働いているケースがほとんどなので、ER図の最新版は常にクラウド上でシェアするようにしています。私たちは、この設計ドキュメントの共有に、Lucidchart.comを使っています。
そして、新たなエンティティが発見・追加されたり、テーブル間の関係性に変化が生じる場合は、ER図に手を入れる前にメンバーがSkypeやZoom等を用いてオンラインミーティングを行い、その内容を議論してから最終的な意思決定を行って、ER図を「全員が見ている前で」更新します。
ER図はクラウド上で共有なので、印刷して配布し直したり、最新版をファイルサーバ上に保存し直したりする必要はありません。
後は、その追加・修正内容に合わせて、影響の出るサブシステムは、それぞれの担当者がレイアウトやリレーションシップグラフ、そしてコード（スクリプト）を変更するといった感じで開発を進めていきます。
要点３：緩やかな開発ルールを設ける
FileMakerプラットフォームを用いたプロジェクトに限らず、複数で開発をする場合は開発ルールを設ける事が極めて重要です。
しかし、ことFileMakerに限ってはあまりに「厳密」なルールは必要ないと思っています。
その理由は、FileMakerプラットフォームのデベロッパーフレンドリーな仕組みが、緩やかな開発ルールで生じる幾つかの問題を解決してくれるからです。
例えばレイアウト名やスクリプト名などは、「ネーミングルール」という形でガチガチのルールに則って命名されることが一般的です。
しかし、FileMakerプラットフォームにおいては、それぞれの開発者がまず「自分が心地よい」と思って命名したまま実装を進め、その後の「リファクタリング」のフェーズで名前を変更するという順番で作業をしても、その影響はほぼゼロです。
3-1.リファクタリングはソフトウェアの寿命を延ばす
リファクタリングとは、ソフトウェアの外部から見た振る舞いは一切変えること無く、内部的な構造を、拡張性・柔軟性の向上という観点から、理想的な構造に洗練することです。
もちろん後からテーブル名やフィールド名を変えることになるので、これらををハードコードしないというルールが守られていることが前提です。ですのでやはり最低限のルールは必要です。
しかし、過度に開発ルールを意識しすぎて開発者の「瞬発力」を殺してしまうぐらいなら、最低限のルールを守った上で、まずは開発者の瞬発力を第１優先に開発を進め、その後にルールから外れた「デコボコ」をきれいに「ならす」という方法で良いと考えています。
ですので、弊社ではこの「リファクタリング」は非常に重視しています。
リファクタリングを経ないソフトウェアは、その後のメンテナンスが極めて困難になります。
一方、リファクタリングが適切に行われたソフトウェアは、極端な話になりますが詳細な設計書は必要ないほど、内部構造がスッキリとした構造になります。
特にFileMakerにはDDR（データベース・デザイン・レポート）という強力なリバースエンジニアリングツールがありますし、これをさらに高度に解析してくれるFMPerceptionやBaseElementsというサードパーティもあります。
ですので、適切な開発ルールとリファクタリングで洗練されたソフトウェアがあれば、詳細設計書は必要ないと私達は考えています。
3-2.カスタム関数・汎用スクリプトの共有
カスタム関数や、特定のソリューションに依存しないコンテクストフリーなスクリプトは、ライブラリ化してチームで共有することが重要です。
このことで、システム全体の振る舞いに一貫性を保つことができます。
例えば日本の商慣習では常に求められる月末・月初日の計算ロジック、また官公庁系のシステムでは重要となってくる和暦による日付の入力機能などはライブラリ化し易いロジックの代表例です。
それ以外にも、ログイン認証や、エラーハンドリングロジック、モーダルウインドウ制御等、どんなプロジェクトでも使いまわせる機能の固まりは、できるだけコンテクスト（テーブルオカレンス）に依存しない形に洗練して、部品化しておくと開発生産性を上げることができますし、何より開発担当者間での実装方法の差異も小さくなります。
ある共通の機能を実現するときは、必ず決まったライブラリを使うというのも、重要な開発ルールのひとつになります。
まとめ
このブログ記事では、FileMakerプラットフォームを用いたチーム開発における３つの要点をお伝えしてきました。
「FileMakerってチーム開発には向きませんよね？」
「FileMakerってどうしても属人化しやすいですよね？」
このようなご質問を受けることはたくさんあります。
特に、汎用開発言語・データベースでの開発経験が豊富な技術者さんからは、この質問を受けることが多いです。
しかし、こちらのブログ記事でお伝えしてきたような３つの要点を意識して実行することにより、FileMakerプラットフォームを用いたチーム開発は可能です。
また、FileMakerプラットフォームは小規模なシステムしか対応できないという誤った認識も、FileMakerプラットフォームにマッチしたチーム開発の方法論が確立されていないことが大きな要因のひとつのような気がしています。
ぜひ、あなたもチーム開発に挑戦してみましょう。
＊
最後に、記事の中で紹介したツールのリンクです。
・美しいER図をクラウド上で共有できるLusidchart.com
・FileMakerのリバースエンジニアリングが可能なFMPerception/BaseElements
・FileMakerプラットフォームのライブラリ管理ツール、Clip Manager
＊
受注からたった３ヶ月しかない２つのプロジェクトを、双方ともに納期の３週間前には開発を完了させ、お客様からも高い評価をいただいたチーム開発の成功事例にご興味はございませんか？
いますぐこちらのフォームから、動画URLをご請求下さい。
※通信は暗号化されているのでご安心下さい。
