今回は、FileMakerにて業務用のAppを開発していく際に必要になってくるノウハウの一つである、設計手法について解説していきます。FileMakerはシステムをDIYできる方法として浸透しつつありますが、その手軽さゆえに軽視されがちな部分にスポットを当てていきたいと思います。
App作りの流れ
業務用のApp・システムを構築していく場合の流れとして、まず既存の書類・帳票類を洗い出し、業務の流れを一通り洗い出します。また、現在何かしらのソフトを使っているとか、Excelファイルで管理しているものがあれば、それも出していきます。この辺りまでは、当然の流れです。
この後が、最も重要なフローになっていきます。App作りにおいて最も重要なのは、FileMakerの経験でも技術でもなく（もちろんある程度はありますが）、業務の内容も合わせて見直すということです。
最もありがちなのは、業務の見直しをせずに、現在の業務の流れ、やり方をそのままAppに落とし込んでしまうということです。
仕事に限らず、なんでもそうですが、本当は変えたほうがいいけど、何となくそのままやってきたことが、世の中には多くあると思います。このAppを作る時というのは、絶好の業務を改善するチャンスなのです。
すでにAppを作り、そのあとで業務の流れを改善するには、Appの内容を変える必要性が出てくるかもしれません。しかし、一から作る、作り直す前の段階であれば、いくらでもAppの内容を変えることができます。
また、業務の内容を見直したほうがいいという理由がもう一つあります。Appを業務に合わせてだけ作ると、無理が生じてくる、開発に時間がかかる、運用中の機能改善や変更が難しくなってくるケースがある、という側面もあります。
業務に合わせないほうがいい実例
ここでは、一つ紙で行っていた業務をそのままAppに移し替えると、無理が生じてしまう例をお伝えしていきます。
業種としては、卸売業ですが、いわゆる仕入れたものをそのまま販売するようなものではなく、改造したり、協力企業に別なものとして改良してもらったりという形でした。
販売と仕入れの管理と報告を行っている台帳があったのですが、それが取引ごとに1枚の台帳を作成するのではなく、簡単な取引の場合は、いくつかの取引をまとめて記録していました。また、1つの台帳に複数の取引先が混在することも多々あります。
納品書・請求書も紙だけで行ってソフト等使っていませんでしたので、これもAppで作成したいとの要望がありました。この台帳をそのまま落とし込むとどうなるでしょうか？
無理が生じたり、業務としては入力したりする項目が増えたり、手順が増えたりする可能性があることは想像できます。
同じ台帳上に複数の取引先との取引が混ざっていると、この販売商品は、どの取引で販売したものなのかをユーザーが入力する必要が出てきます。入力しなくても、何かしらの操作で、それをはっきりさせる必要性が出てきます。これは無駄です。
台帳は、取引先ごと、取引ごとに分けて作成する必要があります。こういった部分で、業務内容そのものを見直していく必要性が生じてくるわけです。紙ではよかったことが、システム化すると非常識になることも多々あります。
そもそも、今はやっていなくても将来的に何か分析をしたいというようなことがあった場合も、そのまま移行していた場合、分析を行う機能を付与するのが簡単ではなくなるケースも多いでしょう。
まとめ
基本的には、Appを作成するときに、今の業務の形をそのまま行うことはありえない、ということが基本です。
システム開発において、基本的なことは、できるだけ早く、シンプルなものを作成するということです。無駄な手順をできるだけ省き、自動化できるところは自動化する。こうして、システムとして洗練されたものになっていくのですが、業務に合わせてシステムを作ろうとすると、なかなか「洗練」にたどり着けません。
まずは、その業務の試作品を簡単に作ってみることをおススメします。すると、FileMakerでは、簡単に実現できないこともあるでしょう。ある機能を実現するために、リレーションシップが増えてしまう。スクリプトが複雑になりすぎてしまう。こういったことに気づけるはずです。
もしかしたら、複雑になってしまう原因は、業務フロー、仕事のやり方に原因があるのかもしれません。今の業務をそのまま落とし込んだ時に、Appで行ったときに手順が増えてしまうのであれば、業務を見直したほうがいいでしょう。これが一つの業務を見直す基準となるはずです。
