こんにちは！
FileMaker（ファイルメーカー）でいざ、アプリを開発しようとして、新しいファイルを作成するわけですが、ある程度使い方は変わってきていても、実際に開発するとなると、まったく勝手が違ってきます。
今日は、アプリ開発をするうえで、まず何をすればいいかを解説していきます。
一般のシステム開発では
FileMakerではない一般のシステム開発では、まず要件定義を行います。
要件定義とは、簡単に言うと「したいことをまとめる」です。
例えば、見積書を作成するアプリを開発したいとします。
- 見積書を作成
- 見積書をPDFで出力
- 見積書をメールで送信
- 見積書を検索したい
- 電子帳簿保存法に適合させたい
- AIを使って内容を分析したい
こういった内容を文書化します。
この要件定義と仕様の策定が最も重要な工程です。FileMakerの場合は、この工程を飛ばして、いきなり作成される傾向がありますが、ある程度は行った方がいいでしょう。
要件定義書の実際は、かなり複雑な文書構造となっているケースが多く、手軽さを売りにしているFileMakerにはそこまでする必要はないかもしれません。
ただし、簡易的なものは作成しておくといいでしょう。上記のような箇条書きのリストでも構わないと思いますが、しっかりとリスト化しておくことは必要です。
テーブル・フィールドの定義が最初じゃない
これは、FileMakerで作成した販売管理アプリのメインメニューです。
メインメニューは、起動したときに必ず表示される画面で、すべての機能の起点となります。
言い換えれば、機能の一覧といってもいいでしょう。
これをまずは作成していきます。これを作成することで、どんなテーブルを作ればいいか、フィールドを作ればいいか、レイアウトを作ればいいか、スクリプトを作ればいいかが見えてきます。
また、社内で使用されるものの場合、このメインメニューをまず作り、使用するユーザーなどに見せることによって、イメージも湧いてきます。
最もダメなのが、これを作らずにユーザーに意見を求めることです。
ユーザーは、これから作成されるアプリがどんなものか作る人以上に想像できていません。ですから、こういったビジュアルで分かりやすいものをまずは作成することで、これからどんなものが作成されるのか、こういった機能は入れられないかなどの提案もしてもらえる可能性が高くなりますし、開発側と使用側の不一致もなくってきます。
機能の漏れが見つかる
メインメニューをまず作成すると、これが設計図代わりになります。要件定義書も兼ねます。
まず最初にやるべきことを提示されたわけです。
本来入れるべき機能が漏れている場合も、ここで発見される可能性が高いです。本来は要件定義書で見つけるべきなのですが、実際要件定義書を作って、ユーザーに見せても機能の漏れはなかなか見つからないでしょう。
こうした、ビジュアル化は本当に重要です。
また、メインメニューに表示されている機能をひとつひとつ作っていくことで、リストに入っていたけど、機能として漏れていた、ということもなくなりますし、テストの段階でそれに気づけるでしょう。
いきなりテーブル・フィールド定義を始める危険性
アプリ開発は、ある程度先を見越して開発をしなければなりません。
簡単に言うと拡張性を担保して開発を進めなければならないということです。
将来的に機能追加がある程度可能な余地を残しながら、アプリを作成するということです。
いきなりテーブル・フィールド定義を始めてしまうと、今定義しているテーブル・フィールドにフォーカスされてしまいます。本来であれば、将来的に何か機能的に追加したくなった場合に備えて定義していかなくてはいけないのですが、いきなりこれを始めるとそれを想像しながら行うのが難しくなってしまいます。
そこで、メインメニューを作っておくのです。作っておくことで、「余白」も感じることができるようになります。
メインメニューを作っていくと、この機能もほしい、ということが想像できるようになってきます。最初の段階では、機能に入れる必要がないものでも、レイアウトの余白に将来的に追加されそうな機能などをメモしておくこともできます。
また、将来的に追加されるものでなくても、いきなりテーブル・フィールド定義をしてしまうことで、本来入れておくべき機能が入れづらくなってしまうことも起きるかもしれません。
まず、今回搭載する全機能をメインメニューを作って書き出しておくことで、テーブル・フィールド定義した時にその後定義するものを想像しながら作成することができます。
こうすることで、全体として、スマートなアプリが出来上がることにもつながります。
特に社内導入する場合には、このメインメニューを最初に作ることが成功ポイントになるということは覚えておきましょう。
