FileMaker Advent Calendar 2015のTODOリストシリーズ、今回で最後です。
今回は、おさらいです。
まず、ヒアリングをしました。
開発者の方は分かっていると思いますが、ユーザの要求はコロコロ変わるものです。
最初にヒアリングしたものは、リリースした時にはすでに形が変わっていることがほとんどです。
なので、ヒアリングの時には話し半分で聞いておき、開発期間に余裕を持つことをお勧めします。
「余裕」は、最初の要求が変更になったり追加になった時の分です。
絶対、ギリギリの予定を立ててはいけません。
そして、動作する機種を選定しました。
何で動かすかで、FileMakerの場合はレイアウトの数が変わります。
レイアウトはコピーで作れますが、それぞれの機種(iPhoneやiPadなど)のサイズにリサイズするには時間が必要です。
動作確認やiPadでは動かない関数やスクリプトなどの確認や配慮も必要です。
時間が倍増します。
ヒアリングと動作環境が決まったら、さぁ開発！ではありません。
業務設計でしたね。
業務はコンピュータ化されていないシステムです。
それをFileMakerを使ってコンピュータ化するということは、「業務＝FileMakerで構築したシステム」という形態になっていないとシステム化した意味がありません。
ここを端折って開発を進めると、出来上がってテストをしてもらった時に「全然違う」と言われてしまうのです。
それっていやですよねぇ。
なので、「おたくの業務はこうですよね」「これを今回FileMakerでやっていきますよね」ということを（UMLなどで）絵的に表し、お互いに理解をしていく必要があるのです。
そして、業務設計が決まったら、いよいよ開発設計や本開発に入っていきます。
このシリーズでは開発設計についてさらっと書いてしまいましたが、開発設計では、共通で使う部品（関数）やエラー処理のやり方の共通化、コメントの書き方、など開発に必要な共通認識を合わせておきます。
必要であれば、これら開発設計方針を文書で残しておきます。
FileMakerの開発現場ではなかなかここまでやらないところが多々あるようですが、小さい開発現場だからこそコンパクトな開発設計を残しておき、開発者が退場し運用やメンテナンスの人が入った時の共通認識の資料として利用してもらうのです。
短期間開発が多いかと思いますが、ぜひ習慣化していきたいところです。
開発がひと段落し、いよいよユーザにテストをしてもらいます。
「いよいよ」と書きましたが、できれば製作途中でステップ分けし、都度動かしてもらう時間をとってもらうと、最後の最後でどんでん返しがおこらないと思います。
テスト仕様書はここで初めて作る、もしくは作らない現場も多いかと思いますが、業務設計をした資料がテスト仕様書として活用できます。
「業務設計書＝テスト仕様書」を意識して設計書を仕上げられるといいですね。
ユーザは、動作確認をすると、「やっぱりここは。。。」ということが殆どです。
なので、業務設計の範囲を超えない範囲で修正やバージョンアップをしていきます。
「業務設計の範囲を超えない」ことが原則です。
開発はこの範囲で終わらせます。
そして、次回の開発に向けて、ユーザもあれこれ考えていくし、開発者側も「あそこをこうすると、お客様はもっと使いやすいかも」という提案をしていくことで、システムがスパイラルに良くなり大きくなっていきます。
実際、そんな風にうまくいくわけではありませんが、どちらも気持ち良くシステムを開発し使っていきたいと思う気持ちは一緒だと思います。
なので、できる限り疲弊しないシステム開発をFileMakerでもしていく必要があります。
Advent Calendarでも他の記事で書いたように開発環境を整えたり仕様書を残しておくなども気持ち良く仕事をする上で必要です。
開発言語に限らず共通概念だと思います。
来年度は私もいままでやってきたことを見直して、もう少し気持ち良くFileMakerで仕事をしていきたいと思っています。
これで、TODOのシリーズは終わりです。