コンサルタントが語る FileMaker ソリューション開発の提案から納品まで - ある旅行会社のビジネスの効率化をサンプルケースとして - 有賀 啓之 著 ©2008 FileMaker, Inc. All rights reserved. FileMaker、ファイルメーカー及びファイルフォルダロゴは、米国及び その他の国において登録された FileMaker, Inc. の商標です。その他の商標はすべて、それぞれの所有者の財産です。 FileMaker は、個々の独立した提供者により製造されここに紹介される製品の性能や信頼性について、明示的であれ、 黙示的であれ、なんらの保証をもおこなうものではありません。協定、合意、または保証は、たとえ交わされるとしても、 すべて提供者と将来のユーザの間において交わされるものとします。製品の仕様や提供の可能性は、予告なく変更される 場合があります。 本書類は、一切の保証なしに 現状のまま 提供されるものであり、FileMaker は、黙示の商品性の保証、特定の 目的についての適合性、非侵害の保証を含め、一切の明示あるいは黙示の保証を否認します。FileMaker ならびに FileMaker の供給者は、直接的損害、間接的損害、偶発的損害、結果的損害、営業利益の損失、懲罰的損害、特別損害 を含め、このような損害が生じる可能性についてたとえ知らされていたとしても、いかなる損害についても一切の責任 を負わないものとします。法域によっては、無保証あるいは責任制限を認めない場合があります。FileMaker は、本書 類を予告なくいつでも変更できるものとします。本書類はいずれ時代遅れとなるかもしれませんが、その情報を最新の 情報にすることを約束するものではありません。 2 目 次 目次 .......................................................................................................................................................................................... 3 目的 .......................................................................................................................................................................................... 4 プロジェクトの始まり ........................................................................................................................................................ 4 ユーザへのヒアリングの開始 ............................................................................................................................................ 6 調査結果の報告と方向性の確認 ........................................................................................................................................ 8 ソリューションの提案と構成の確定 ............................................................................................................................ 10 データの移行 ...................................................................................................................................................................... 12 プロトタイプの作成 .......................................................................................................................................................... 13 スタンドアロン環境での試用 ......................................................................................................................................... 16 ユーザの意見や反応をプロトタイプに反映 ................................................................................................................ 17 実際の環境でテスト運用 ................................................................................................................................................. 18 運用開始 .............................................................................................................................................................................. 18 今後の改善のためのヒアリング ..................................................................................................................................... 19 まとめ： 次のステップへ向けて ................................................................................................................................... 19 著者紹介 .............................................................................................................................................................................. 20 ソリューション開発のチェックポイント .................................................................................................................... 21 3 ■目的 このドキュメントは、以下の方々を対象としています。 組織内での情報化を担う情報担当社員や職員、あるいは図らずも情報環境の効率化を担当したり、そうした状況に直 面してしまった方。 業務として開発を請負い、これからソリューションの開発を始めようとしている方。 このドキュメントは以下の内容を記しています。 コンサルタントであり開発者でもある筆者が、実際に取引のあった旅行代理店のソリューション開発案件をサンプル ケースとして、実際にクライアントとのミーティング時期やその内容、開発の進め方、導入の前後でのケアなどを時 系列に添って紹介しています。 読むにあたって このドキュメントの内容は、必ずしも全てのケースに対して有効ではないかもしれません。が、現在のビジネスが存 在する所にあっては、必ず FileMaker Pro が有効に活用できる局面が存在しています。つまりこの世にビジネスが 存在する限り FileMaker Pro の活躍するマーケットは必ず存在するということです。数あるソリューションの中か ら FileMaker Pro らしいソリューションを提供して、コンサルタントとしてもしくは開発者として、クライアント と共同して新たなビジネスのステージに上がることを考えることは非常に楽しいものです。このドキュメントを通じ てその楽しみを、お読みいただいているユーザとも共有できたら非常に嬉しく思います。 ■プロジェクトの始まり それは、とある中堅旅行会社の社長からの電話で始まりました。 「システム開発・導入の話を知人から聞いたのですが、そのノウハウが、弊社の環境にも反映、適応できるか一度話を聞 いてもらえないだろうか」 旅行会社としてのシステムは既に小規模とはいえ開発したことがあったために早速お伺いすることにして、まずはこの クライアントの現状を概略でお聞きすることから始めました。 この会社の規模は従業員にして 10 名程度の事務社員と開催するツアーによってはアウトソースで添乗員を手配するス タイルの会社でした。この社長自身が 20 年ほど前に創業して、非常に大きく業績を伸ばしてきていた会社でしたが、 業績の伸びに事務処理が追いつかず現在に至っても業務を一元管理できる仕組みは存在していませんでした。 営業は営業向けの市販パッケージソフトで業務を管理し、会計は会計向けの別の市販パッケージソフトで業務を管理し その内容を外部の会計会社に提出。一方、様々な事務書類に関しては表計算ソフトやワープロソフトで各々がその都度 作っている状況でした。 パソコンは、事務所で働く全員に配備されており、ネットワークも構成されて、相互に共有フォルダなどで情報のやり とりをしていました。勿論プリンタなども共有されてそれぞれのパソコンから出力できるようになっていました。 社長の思いは「パソコンを入れて営業管理をするというのは、この程度のことなのか？」といまだ納得のいかないもの でした。社長のお話を聞くうちに、 4 ● 折角パソコンを購入したのに依然として報告が上がってくるタイミングが遅い。 ● 細かい日ごとの報告や日報、旅行ツアー報告書などはあるが、全社レベルでの営業業績やツアー、企画の進捗状 態を確認できる書類がない。 ● その都度いろいろな書類を作成して集計しているようで書類に一貫性がなく、作業が効率的ではない。 というような思いを現状に対して、社長はお持ちになっているようでした。 10 名程度の人数の社員構成ですと、システム専任となるような人材を配置することができる会社は私の知る限りあま り多くなく、また全社の IT 全体を把握している人もパソコンのことが好きだったり、多少判るので見様見真似で IT 環 境を構築してきている、というのが多くのケースです。使うソフトウェアも、その都度パソコンをあてがわれた人ごと、 または IT を担当していた人が独自の判断で使い易いソフトウェアを選択することが多く、大半の場合は、既にインストー ル済みの表計算ソフトであったり、ワープロソフトであったり、場合によっては住所録ソフトであったりします。そし て今回も状況としては同じようなものでした。 このようなケースの場合、それぞれの社員に対してコンピュータ知識の向上のために、会社として一環した教育やレッ スンを提供できればまた状況は違ったりするのですが、残念ながらそうしたことは稀です。また、社長自身もコンピュー タを使用するにあたってレッスンが必要とはあまり思っていないケースが多いようです（ 仮に思っていたとしても時間 的にも、財政的にも余裕はないといのが、10 名ぐらいの会社の現状ではないでしょうか？）。 今回の場合この段階で社長からの指示としてあったのは概ね次の内容になります。 ● 社長が必要とする帳票類の提示が可能になる ● システム開発に関する大局的な方針は、社長に確認すること ● 現行の仕組みについては社員に確認 個人番号（ID ＝識別番号） 電話番号 ラベル印刷 姓 / 名 / 振仮名 / 性別 履歴の集積 生年月日 住所 7000 データ 個人識別番号 ツアー識別番号 オプション 申込日 グループ情報（代表者） メモ 入金方法 入金確認 キャンセル ポイント ツアー番号（ID ＝識別番号） 集計 個人集計 名称 ○料金 ツアー合計 最小催行人数 日別合計 ○催行月日 月別合計 オプションメニュー 固定要素 全体観 5 履歴の集積 おそらく社長は、現状に不足感があり、 「業務」の仕組みとしては十二分に把握しているが、 「IT を活用」した有効な仕 組みは今一つ不明ということなのだと思います。 こうした最初の打ち合わせでは、誰に何を聞き、誰に何を決定してもらうか、あるいは決定権はどこに存在するかを把 握したり確認して、コンサルタント（またはデベロッパ）とクライアントの担当者との間でしておくことは非常に重要 なポイントと感じています。 FileMaker Pro のシステムに限らず業務に非常に近い関係にあるシステムは業務の変化とともに変わっていかなければ ならないものだと思います。その一方で、システムを常に使用して業務を遂行しているユーザと、そのシステムの情報 をもとに意思決定をするユーザが同じ視点で業務を見つめるわけではないので、どの視点に軸足を置いて開発して行く のかを見極めることは非常に重要になります。 細かい仕様などを意思決定者（今回は、社長）に伝えることは、この段階では必要ないと思いますが、全体観として、 現在のシステムとこれから作ろうとしているシステムをイメージとして描ける程度にお伝えすることができれば、何が 変わり、何が変わらないかを、意思決定者は大枠として把握することができます。この段階では、大枠であっても、意 思決定者が把握することができるということが、システムを開発して行く上では必要なことと思います。また、データベー スソフトや FileMaker Pro を使ったことのないクライアントの場合、データベースソフトの特性や、FileMaker Pro の特徴や機能も大枠として、この段階で理解していただくことも重要なことです（特にデータベースには馴染みがない 場合が多いので）。 ［ プロジェクトの始まり ］におけるチェックポイント □ 意向と経緯の確認 □ 目的と成果物（ 目指したい方向 ）の確認 □ タイミングをはずさず現状確認 □ 規模の把握とハードウェア、ソフトウェアの使用実態の把握 □ 決定権の所在とヒアリング先の把握、確認 □ 可能であれば、方向性のラフイメージを伝えて全体観を把握してもらう □ 使うソフトウェアの仕組みや特徴を概略で伝える ■ユーザへのヒアリングの開始 意思決定者の社長との打合せの後、これから開発するシステムを実際に利用するユーザへのヒアリングを始めました。 システムを作る際にわたしは、ユーザを次の 2 種類に分類してニーズをまとめています。 Type 1: 部、課、職種など、各現場でのコンピュータ利用の中核になるユーザ （ システムを作成するユーザがいる場合もある） Type 2: Type 1 の人に教えられて、実際に入力を中心にしているユーザ 特に今回の旅行会社の場合、ツアーに添乗する方や運転手の方の精算の仕組みも取入れることになっていましたので、 こうしたユーザは Type 2 のカテゴリに属することになりました。 まずは、Type 1 のユーザに現行の仕組みをお聞きしました。 この場合、どうしても既にあるファイルや画面を見ながら「この値はこれを意味します」とか「この値はこことここを 足したものです」とか非常に細かい部分になりがちです。現場で実際に業務に接しているユーザは、表計算ソフトなど 6 を日常的に使用して、そこを通じて業務をみていることが多いので必然的にこうした展開になってしまう場合が多いで す。一方で、今回のようなシステム構築の場合、どうしても業務フローを確認しながらのシステム再開発という意味合 いが強いので、いきなり細かい部分から入るのではなく、業務フローの大枠を捉えることが先決となります。 そこで、こうした細かい部分に配慮しつつも大きな業務のフローを確認しながら、ソリューションの全体構成図を作成 していくのがいいのではないでしょうか。 ここまでの時点で既にわたし（コンサルタント側）は、FileMaker Pro と FileMaker Server との連携を基盤とした形 を想定していました。ヒアリングする際にはその特性を、クライアントに少しずつ明かしながらどのようなファイル構 成やテーブル構成が運用上望ましいのかを探りました。 また、表計算ソフトやワープロソフトで作成するファイルの現在の名前の付けかたや、業務フローのどの時点でそれら を作成しているのか、過去に作成したファイルのルール（あまりルール化はされていないかもしれません）なども確認 しました。いずれもどのようなタイミングでどのようなファイルが作成され、出力されているかを確認しました。 この段階で Type 1 のユーザに確認すべき大事な点がもうひとつあります。実際に入力している Type 2 のユーザに比 べて、作成したり集計したりすることも多い Type 1 のユーザは、既存のソリューションに格納されているデータの精 度についての情報も合わせて持っている場合があります。例えば、「半角全角が区別なく入力されている」とか、「ひら がなとカタカナの区別をしていない」とか、入力値の整合性に関する既存のソリューション上での問題点も合わせて確 認します。この確認で、今後開発する際に、「プルダウンメニューを使用したほうがいい」とか、 「ルックアップで制限 を掛けよう」とか、 「カレンダーにしよう」などユーザの使用状況に合せたソリューションのインターフェースを実現す る要素を把握することが可能になります。 次に実際に入力作業をされている方 Type 2 のユーザへのヒアリングをしました。 場合によっては、Type 1 と Type 2 とでは、明確な差がない場合もあります。そうした場合であっても比較的、その組 織の中でコンピュータに詳しくイニシアチブを取っているユーザは必ずいます。環境によって細かな違いはあるにせよ、 大きな枠で考えてそれぞれのユーザの意向を把握しておくことが必要です。 また、この段階では、その会社で使われている様々な名前や言葉についても理解しておくことが必要になります。独特 の言い回しや専門用語、あるいは一般的な意味とは異なる意味で使用される言葉なども可能な限り洗い出しておきます。 こうした言葉は業界用語の場合もあれば、その会社独特の言葉もあるでしょう。意味を確認せず言葉だけで判断して、 あとで大変なことになることもありますのでヒアリングの際には細心の注意を払いながら確認していきます。 さらに確認すべき大事な点は、現行のソリューション上で「ストレスのある入力操作」があるかどうかという点です。 特に今回の会社のようにツアーの添乗員など社外の業務が多いユーザだと、外勤務が終わってからの入力や、会社に立 ち寄ってから出て行くまでの僅かな時間での入力というパターンが多くありました。そうした業務背景を踏まえて、確 認するべきことは、入力ミスが発生しやすい操作になっているとか、項目が判りにくく入力先や選択に間違いやすい項 目があるかなどになります。現状のソリューション上で制約があるのであれば、それはなるべく低減したいものです。 低減する部分が多ければより使ってもらえる新しいソリューションを開発することができます。 一方で、FileMaker Pro では実現できない部分がありそうかどうかも、それとなく確認します。できないとは言っても 千差万別ですが、困難が予想される部分があるかどうかを確認しておくことは必要です FileMaker Pro オリジナルの機 能として即座に実現はできそうにないなと言う部分が、どこかを把握できればいいとは思います。 7 可能であるならば、実際に入力している様子や帳票を作成したり印刷するタイミングなども業務に合わせて確認すると、 ユーザのソリューションの利用法をより把握しやすいのではないでしょうか。つまり、コンピュータ使用に慣れている ユーザを対象にソリューションを開発していくのと、全く慣れていないユーザ向けに開発するのとでは、データの構造 に大差はなくとも、インターフェースのデザインや設計にとっては大きな差になります。 いずれにしても、この段階で必要なことは、現状のソリューションをユーザはどのように使っているかを、できるかぎ り正確に把握することです。 ［ ユーザへのヒアリングの開始 ］におけるチェックポイント □ 聞くべき内容と聞くべき対象を区分してヒアリングする □ いきなり細かい部分でのヒアリングはせず、大枠で業務フローを捉える □ 現在のファイルの名付け方や作成のタイミングのルールを把握 □ 現在発生しているトラブルやその原因を現状のソリューションの使用実態と合わせて可能な限り把握する □ FileMaker Pro オリジナル機能でのカバーエリアとエリア外を把握 ■調査結果の報告と方向性の確認 さて、現状把握のためにどれほどの時間をかけるかはその案件ごとに異なりますが、一通り把握ができた段階で、その 概略をまとめ、一旦ここでクライアントに報告をします。 今回は、社長にしました。 ここまでの調査の中でわたしとして理解した、一連の作成書類の旅行業務の中での位置づけ やその内容、処理方法、処理時期等も合せて報告しておきました。 ここで社長の感覚とずれているようであれば、何故ズレが発生しているのかも確認しておく必要があります。 管理者には、大きな枠で捉えつつも細かい部分まで気にする方や、大枠が合っていればそれで良いという方など、様々 いらっしゃいます。そこは、コンサルタント（ソリューションを開発する側）のスタンスでどのような立ち位置をクラ イアントとの間でとるのかを判断しつつ、クライアントの意向とそれに対するコンサルタントの提案を報告書に盛り込 みます。 8 入力型 対象選択と絞込み Web 予約 直接予約 シリーズ プラン Flight（往 / 復路） 対象ホテル レンタカー JR 対象プラン Entry （一覧 / 詳細） Rec. 進捗管理 参加対象 ステータス管理 -- 進捗管理 -- 手配管理 -- 決済管理 ラインナップ管理 -- 発送管理 -- 空き状況 -- ラベル管理 -- 金額 画面 -- 運行 Personal Rec. 履歴管理 -- 申込本人 集計 -- 日報 -- 申込数（Report_daily_Entry） -- 決済数（Report_daily_Status） -- ツアー管理 -- ツアー別進捗（Report_plan） Report_daily_Entry Report_daily_Status Report_plan 日別の集計レポートを個別の Entry 単位で表示 手配の一覧レポートを個別の Entry 単位で表示 現在募集中のプランを登録マスター毎にその募集数を集計 集計項目 対象日付 集計項目 対象件数 集計項目 対象件数 対象数（申込 Entry 数） 未完了状態の Entry 一覧を表示 募集状態の plan 一覧を表示 以下一覧表示 ( 選択行により個別 entry 情報を閲覧 ) 申込日付 出発日付 名前 選択シリーズ選択プラン 出発日付 選択シリーズ選択プラン 申込数 完了数 名前 選択シリーズ 選択プラン 申込金額 決済状態 手配状態 申込金額 決済状態 手配状態 配送 概略を流れとともに報告 この段階であまりに細かい帳票ひとつひとつまでを拾って報告することはあまり良策とは言えないと感じています。こ こは、あくまで概略としてどのような仕組みを発注者が望んでいるのかを確認しながら、これから開発するソリューショ ンの方向性の確認に終始するべきタイミングだと思います。従って、各種レポートにしてもどのタイミングでどのよう な種別のレポートがあればよいのかを現在の業務フローと対比しながら報告します。勿論、社長に報告するまでの段階 では、実際にヒアリングをした各社員の方々にも再度確認し、理解に食い違いがないかもチェックしておくことを忘れ ないようにします。 今回の旅行会社の場合、これまで全社的な視点でソリューションをつくった経緯もなかったことから、現状では、同じ ようなレポートが何度も作成されたり、都度集計したりするものも数多く、現状よりも早いタイミングでの集計が必要 なのに、それができていないものもありました。また対外的には、何度も来訪いただいているお客様の情報が簡単には 確認できなかったりしている状態でもありました。 例えば、 ● 申込の際のお客様情報を、過去履歴から参照できにくい、あるいはできなかった ● 各種発送の処理や管理などが一元的にできていなかった ● 計画しているツアー毎での損益分岐点を算出するための集客人数が明確になっていなかった ● 日報や週報などの特定のタイミングで売り上げの集計ができなかったため、会計から上がってくる試算表が届く まで各自の成績を把握できなかった というものです。 つまり、現状の問題として、旅行者の趣向の多様化が加速していくのに、そのビジネスの変化に対応するソリューショ 9 ンや業務の仕組みを作ることができないまま、パソコンだけを全社員に割り当てた結果、業務の効率化を社員一人一人 のパソコン処理手法に依存するだけにとどまっていたことを、この段階で明確にして、かつ社長に理解していただく必 要がありました。 社員に能力が無かったわけでも、管理者の指示が悪かったわけでもなく、現状に適ったソリューションや仕組みが単に 無かっただけのことだということの理解と、そのソリューションや仕組みをこのあと作りあげていくことに対する了承 とその方向性の確認をここでしました。 これができればこの段階では十分となります。 従って上記実情を踏まえてこの段階で ● 計画する各ツアーの損益を計画時、集客時、実行時で概算で算出することができるようにする ● 一度でもご利用いただいたお客様の情報は、担当者がいつでもスムーズに確認できるようにする ● 各ツアー情報を踏まえた全社的な営業成績を日報、週報、月報など特定のタイミングで把握できるようにする という大枠で方向性を定めソリューションの開発を進めていくことを確認し、社長からの了解も問題なくいただくこと ができました。 ［ 調査結果の報告と方向性の確認 ］におけるチェックポイント □ 大枠での報告を踏まえて方向性を確認 □ 現在の問題点の理解とその解消を目指す新しいソリューションへのアプローチを報告 □ 新しいソリューションでは既存の問題点がどのように解消されるかを報告 ■ソリューションの提案と構成の確定 日常的に FileMaker Pro を使用している方や、かつて使用した経験がある方（この場合は多少違うケースもあります）、 もしくは既に FileMaker Pro ベースでのソリューション開発を決めている方には、このソフトウェアの有効性は簡単に 理解してもらえます。ただし、FileMaker Pro が随分と広まりを見せているとはいえ、全てこのようなケースばかりで はありません。また、大手オフィス系ソフトウェアにバンドルされているデータベースソフトであれば、既に持ってい るけれども使ってはいないというケースもありますが、FileMaker Pro に関していえば、そのようなケースはまずあり ません。従って、この点に関しては FileMaker Pro でのソリューション開発提案には、まず新たに採用することになる FileMaker Pro というソフトウェアと、その機能や特徴をクライアントに知っていただかなければなりません。 また、クライアントが現在使用している OS のバージョンで、現行購入できる FileMaker Pro が動作するかの確認も必 要です。OS が古い場合は、OS のバージョンアップも検討する必要があります。クライアントが現在使用しているハー ドウェアによっては、OS のバージョンアップのために、買い替えの検討をする必要がある場合もあります。 現行の FileMaker Pro 9 で構築しようとした場合、特に Windows OS では、まだまだ現役として使用頻度の高い Windows 2000 もその動作対象から外れています。FileMaker Pro でのソリューション導入が OS のリプレースもセッ トとなるわけですから、コンサルタントとして、クライントが納得するだけの報告、プレゼンテーションをすることが 必須条件となります。 今回のケースの場合、クライアントは、全社的な視点からソリューションを開発した経験が一度もありませんでした。 個々人のハードウェアのハードディスクが全社的にも重要な書類の管理場所としても扱われ、どこに何のファイル（書類） があるか本人にしか把握できない状況が頻発していました。そこで、FileMaker Pro の特徴や機能を活用すれば、すべ ての情報を一カ所に集約でき、全社的に一元管理が可能なソリューションを開発できるということを説明し、その結果、 10 どれだけ業務が効率化するかをクライアントに理解していただきました。 具体的には ● 共有フォルダに様々なファイルを保存するこれまでの情報共有ではなく、ネットワーク共有にすることにより、 情報やファイルを一カ所に集約し、情報の全社的な一元管理が可能になる ● ひとつのソリューション上で複数人での共同・同時作業が可能になる ● 最新情報が反映された結果の確認が、いつでも可能になる などに加えて ● FileMaker Server でネットワーク共有を構築することによって、導入するソリューションのパフォーマンスを あげ、定期的なバックアップをソリューションの利用中でも可能にすることで、信頼性と安全性の高いソリュー ションになる バックアップついては、他の手段でもできないことではないのであまり説得力はないかもしれませんが、ライブバック アップが FileMaker Server の持つ基本機能として使えるということは、他のサードパーティ製品との組合せにはない 安心感があります。特にデータベースソリューションの場合、この安心感は非常に重要な点だと思います。 そして、FileMaker Pro という一般の市販ソフトウェアを採用し、開発側とクライアントユーザ側との責任範囲を明確 にしておきさえすれば、現場での修正もある程度は可能なのでその後の追加投資を抑えることができる場合もあるなど も、合わせてご提案しました。つまり、FileMaker Pro ならではのアクセス権設定などを使用することで、レイアウト やフィールド定義、スクリプト定義や値一覧など、ここまではクライアント側で修正可能にしますという取り決めがあ る程度は可能です。結果、ささいな変更は開発側に負担を掛けることなくクライアント側で修正ができますので、追加 投資の抑制となります。どなたか社員の方が FileMaker Technical Network（FileMaker TechNet）メンバーになるこ とを勧めておきました。 開発元の FileMaker, Inc. からの最新情報が入手できるので仮に基幹系に近いソリューション であっても ソフトウェア利用における安心感が高まります。 また、「FileMaker Pro によるデータベースのネットワー ク共有」と「共有フォルダにファイルを保存して共有」することの違いは、これを知らない人には非常に理解し辛い部 分です。この違いを理解してもらえる提案が正にこの段階で重要になりました。 今回の場合、経営者の方（社長）がこうした提案と FileMaker Pro が他のソフトウェアと比較してコストパフォーマン スが高いことを理解していただくことができ、私どもコンサルタントの提案を受け入れていただくことができました。 ［ ソリューションの提案と構成の確定 ］におけるチェックポイント □ 共有フォルダ型のファイル共有の利便性と問題点の明確化 □ FileMaker Pro データベースのネットワーク共有の仕組みと利便性の明確化 □ ソリューションのパフォーマンス、信頼性、安全性、柔軟性の確保 □ FileMaker Pro を取巻く環境とコミュニティ FileMaker TechNet への参加 11 ■データの移行 可能な限りデータ移行を試みる 誰でも、一度入力したことのあるデータを再度入力しなければならないのは嫌なものです。そこで極力古いデータは、 可能な限り新しいソリューションに移行します。FileMaker Pro は、非常に多くのファイル形式に対応していますが、 それまで使用していたすべてのソフトウェアのファイルをそのままインポートして適切な形に変換してくれるほどでは ありません。 様々なソフトウェアを活用している場合でも、一定の規則のもとシステマチックに運用されている体系からのデータ移 行であれば、何らかの法則に則って既存データを移行することも可能ですが、今回のケースはそれに当てはまる要素は ありませんでした。様々な項目や内容のある情報が、様々な形の表計算ファイルの状態で保存されています。どれが移 行しなければならない情報で、どれが破棄すべき情報か、その重要性の判断は、外部のコンサルタントではできないので、 可能な限り、クライアントの会社側で取捨選択を予めしてもらうことが重要です。これらの作業は、実際にそうしたデー タを扱っていた方々と共同作業で進めます。特に顧客情報などの場合、ユニークな顧客 ID などが振られているケースは 稀でしょう。一方で、一元管理はできていなくとも過去の情報は企業にとって宝とも言える情報なのは明らかです。様々 な形式のデータを形を整えながら FileMaker Pro のデータベースの内部で相互に関連レコードとして集約していく作業 は、その企業の資産そのものを扱っている瞬間にほかならないので非常に神経のすり減る工程になります。 なるべくこの作業を実際に現場で作業をしてもらっているユーザに手伝ってもらうために、日頃使い慣れている表計算 ソフトを使用してもらうことにしました。関連する情報は、表計算の同じ１行に入れる方法で整理していただきました。 その時に同じ列には同じ情報が入るように予め話をしました。何故そうるべきなのかを説明する際に、表計算ソフトと データベースソフトの構造の違い、考え方の違いも合わせてお伝えしておくことで、その後のソリューション運用の際 のユーザの理解が格段に深まりました。 このように整理された表計算ソフトのファイルのデータは、FileMaker Pro のデータベースに簡単に挿入できます。こ の手順により、クライアントの会社のユーザには、表計算ソフトと FileMaker Pro の親和性の高さを実感していただけ ます。さらに、ソリューションが開発・運用開始されたあとに、FileMaker Pro のレコードの表示形式を表形式にすれば、 スプレッドシートのようにデータを表示でき、表計算ソフトのような操作もできます。この操作をする時、データ移行 の時の表計算ソフトを使用した作業が、正に実体験として結実することになります。こうした制作過程を通じて、現場 でのコンピュータリテラシーの向上を図ることも重要ですし、ユーザのソリューション開発への参加が、次のステップ へと繋がる大きなくさびにもなります。そして、データを FileMaker Pro のデータベースに集約した後は、作業効率は 格段に上がります。 12 ［ データの移行 ］におけるチェックポイント □ 過去のデータはその会社の宝なので極力移行に努める □ 移行の際の情報の取捨選択はクライアント側でその重要度を判断してもらう □ 移行作業はクライアント側で使い慣れたソフトウェアを使用してもらう □ 表計算上の同じ１行に関連情報を集約して移行を促進する □ 移行作業の処理内容と理由を説明してデータベースと表計算の違いを説明 ■プロトタイプの作成 MS_Person ファイル名 項目名 属性 タスク memo 確認事項 MS_Personal 個人ごとに登録 timestamp_c tmestamp 作成timestampを記録 timestamp_m timestamp 修正timestampを記録 Person_ID 主キー 表示用_ID text pswd text 名前 text 名前（読み） 生年月日 性別 text 個人特定用IDに使用 電話番号（携帯番号） text 個人特定用IDに使用 ローマ字 date 個人特定用IDに使用 yyyymmdd形式 郵便番号 text 郵便番号で以下の住所の入力補助 住所 text 各種送付先情報 メールマガジンの購読 text 緊急連絡先メールアドレス text 緊急連絡先代替電話番号 text ホテルメンバーズ種別 text ホテルメンバーズ番号 text 航空機メンバーズ種別 text 航空機メンバーズ番号 text 選択式 選択式 公開Flag 先方からの情報削除依頼が来た場合に、名前と電話 番号、メールアドレスを削除して公開フラグを外す スプレッドシートで概要把握 FileMaker Pro でソリューションを開発するのは結構楽しいことなので、どんどん開発してしまうことが多いのですが、 ここで一旦どのような項目が入力項目として必要で、それはどのような入力形式にするのかなどを（直接入力なのか、プ ルダウンがいいのかなど） 、ユーザとまとめておきます。移行してきたデータもそれぞれの項目の種別を確認する大きな手 がかりになります。実際には、2 度手間になってしまうかもしれませんが、ユーザとの間でこの項目を整理しておくと後 ほど大きな変更になることが少ないように思います。計算式ひとつとっても、 「業販価格はこの数字とこの数字の掛け合わ せ」とか、 「日報レベルで集計するのはこのレベル」とか、 「提携先との間での取り決めにはこの数字が表示される」など、 日常の業務をシステム化する正にその基盤作業となります。この作業は FileMaker Pro で実際に作りながら確認するより は、事前に、表計算ソフトなどで一覧表に素早く書き込んでいくと効率がいいように感じています。シート単位でテーブ ルやファイルのくくりにしておくと、複製作業なども楽ですので、この作業には表計算ソフトをあえて使っています。 13 またこうした項目一覧を確認する中で、どの項目が、他のレコードと区別するための他に２つとない項目（主キー）と なりうるか、あるいはどの項目が、他のレコードからの接続を受け付けるための項目（外部キー）となりうるかも確認 していきます。 同時に業務上での入力タイミングや使用タイミングも合わせて確認していきます。例えば、この旅行会社の場合、「お客 様からの電話を受け取り、その電話番号を使用して個人を特定していく」作業から一連の事務処理が進むという事情が ありました。その点からまずは、電話番号検索がひとつの重要なインターフェースになるということも理解できました。 仮に、メールやフォームからの送信フォームが一連の処理の始まりとなると、如何にその部分と FileMaker Pro のソ リューションとの間でシームレスな連携を実現するかが大きなポイントとなります。こうした各入力項目の扱いを確認 していくことで、実際に FileMaker Pro でソリューションを開発していくにあたって、どのような構造にすれば将来的 なメンテナンスやレコードへのアクセスの管理などが、しやすくなるかを見極めます。また、仮にデータの入力の順序 などで業務フローなどに変更が及ぶ場合は、ユーザにも大きなストレスを与えることになりかねませんので、別の局面 で相応の入力の効率化や改善が図れるように開発することが、実際に使用されるユーザの評価を得ることになります。 一連の項目整理が実際の業務フローとも合わせて確認することができたら、ここで初めて FileMaker Pro で、ソリュー ションを一気に開発していきます。既に項目（フィールド）の整理はできていますので、それほど多くの時間は要しな いと思われます。 また、現在作成しているものは、あくまでプロトタイプの位置づけになりますので、まだまだ再構成ということは十分 にあります。一方で、あまり変更しない、あるいはしたくない部分を明確にしておきます。これは、単に今回の旅行会 社の案件だからというわけではありません。例えば、それぞれのテーブルでのレコードの持ち方、基本的なリレーショ ンの構造などは、基本的な部分だからこそ、その後の基盤となりうるので変更は大きな影響を持つことになります。逆 にそれ以外は、プロトタイプでの運用を見極めていく中でより良い形が見えてくる場合も多いです。 ＜ファイルの基本的な構成の決定＞ デベロッパとユーザが異なる場合は、データのみを格納するファイルと、レイアウト、スクリプト、リレーション シップなどを含むインターフェース用のファイルとに、ファイルを分ける場合があります。このような分離モデルは、 FileMaker Pro 7 以降でデベロッパに採用されるようになりました。 データとインターフェースを分離 14 たとえば、ユーザがソリューションを実際に利用しはじめてから、デベロッパが新たな機能を追加する場合でも、開発 期間中に実際の業務をとめるわけにはいきません。分離モデルであれば、デベロッパは、インターフェース用のファイ ルのコピーに変更を加えた後、ソリューションの同じファイルと入れ替えるだけで、ユーザのソリューションに機能を 追加できますので、開発期間中でもユーザはソリューションを利用できます。インターフェース用のファイルを入れ替 えても、開発期間中にユーザが入力したり変更したデータは、データ用のファイルに保存されているからです。一方で、 全てが同じファイルに存在していると、デベロッパは、ユーザが使用中のソリューションに直接変更を加えるか、ユー ザがソリューションを使用していない間に変更を加えることになります。もしくは、既存のデータを削除したファイル のコピーに機能追加をおこなうことになります。この場合は、開発後、すべてのデータを機能追加されたファイルにイ ンポートする必要があます。 この分離モデルであれば、ソリューション導入後のメンテナンスが容易になると一概にはいえませんが、分離モデルを 採用するかどうかは、このタイミングで検討します。ある程度、開発が進んでからでも分離モデルへの変更は可能ですが、 その時は、かなり手間がかかる作業になります。 今回の場合、納入先のクライアントが弊社からかなり離れていたこともあり、データ用のファイルとインターフェース 用のファイルに分けることにしました。分離モデルを採用したとしても、データ用のファイルでフィールドの変更を加 えるほか、ソリューションの構成自身に手を加えた場合はインターフェース部分だけの差し替えでは対応できなくなる 場合もありますので、極力フィールドに手を加えることのないように事前に細かい取り決めをしました。 ＜命名のルール化＞ テーブル名、フィールド名、テーブルオカレンス名、レイアウト名、スクリプト名などの命名のルールについて、この 段階で決めておきます。開発が進めば進むほど、ルールの良し悪しが作業効率を左右しますので、この段階でしっかり と命名をルール化することをお勧めします。ルールは、人それぞれだとは思いますが、フィールド名については、名前 でソートしたときに狙った順番で並ぶような名称のつけ方が、開発作業を効率化すると、わたしは感じています。名前 で狙った順番にソートできるように命名しておくと、フィールドの複製をした場合、複製元の直下に複製されたフォー ルドが作成されますので、仮に数百のフィールドがあったとしても、複製されたフィールドを見失うことはなく、フィー ルド定義が楽になります。 名前のクリックで並び変わる命名方法 以上の内容を踏まえ、まずはスタンドアロン環境で実行可能なプロトタイプを作成し、お客様に納入します。 15 ［ プロトタイプの作成 ］におけるチェックポイント □ FileMaker Pro での作業を始める前に必要な項目（フィールド）を整理 □ 表計算ソフトを使うことで効率良く項目を整理 □ 構造を将来のメンテナンス性と合わせて確認、設計 □ リレーションの基本構造（主キー・外部キー）を確認 ■スタンドアロン環境での試用 表計算ソフトしか使ったことのないユーザの場合は、FileMaker Pro の操作方法だけでなくデータベースの操作体系自 体に慣れていないことが多いようです。まずは、ユーザの現在の業務の流れと、用意したプロトタイプを利用した業務 の流れとの違いを概略で説明します。表計算ソフトと FileMaker Pro との操作方法の違いも、明確に伝える必要があり ます。たとえば、ちょっとした計算やメモを、覚え書きのためにドキュメントのはじの任意のセルに書き込むことが、 日常的になっているユーザがいらっしゃいます。データベースの場合は、覚え書き用に用意されたフィールドに書き込 んでいただくようにお伝えします。こうしたソフトウェア自身が持つ差異についても合わせて説明しておきます。 説明が終わったら、スタンドアロン環境で、ユーザにプロトタイプを試用していただきます。デベロッパが想定してい ないような使われ方をされることもありますので、ユーザの操作を後ろに立って見ることは、プロトタイプの改善すべ き点を探るためには、とても有効な方法ではないでしょうか。 業務は検索から始まる また、ネットワークや電源まわりもこの段階でチェックをしておくことをお勧めします。今回のケースではありません が、かつて電気の配線のおかしなオフィスに納入したことがありました。サーバー機を配置してテストを始めたのです が、なにかの拍子にいきなりサーバーがシャットダウンしてしまいました。一方、同じ LAN 内に接続されているノー トパソコンは全く問題なく、またコピー機や電話など他の電気製品も通常通り動いていました。サーバー機の電源だけが、 不定期に切れてしまったのでした。一旦サーバー機を持ち帰り、様々な負荷テストを行いましたが、サーバー機には全 く問題がありませんでした。結果的には、クライアントの会社での電源管理に不具合があったのが原因でした。その整 備と無停電電源装置（UPS）を設置することで、この問題を解決しました。これは珍しいケースだと思いますが、電源 やネットワークは比較的検証が後回しになりがちだと思いますので、 「何かおかしいな」と感じたら、早めにチェックす るに越したことはないでしょう。 16 またこのプロトタイプの試用段階では、ユーザの意向がソリューションにしっかり反映されているかどうかも確認する 必要があります。マスタ系の登録に違和感はないか、レイアウト上でのタブ順を含むフィールド間の移動はスムーズか、 配置してあるボタン類に誤解を生じさせる要素はないかなどを確認します。 恥ずかしい話ですが、かつて、登録間違いの顧客情報を削除するためのボタンをゴミ箱の絵にしたことがありました。ユー ザから「お客様の情報を扱っているのだから、削除とは言ってもゴミ箱は .....」というコメントを頂き、慌てて修正した ことがありました。機能的には全く問題のないことですが、ユーザのこうした感性にも応えることで、心地よく使って いただけるソリューションになります。こうしたことをなおざりにしてしまうと、日々使用するソリューションですから、 大きな問題に発展することもありますので、この段階で、ユーザのソリューションに対する違和感などもしっかり確認 します。 ［ スタンドアロン環境での試用 ］におけるチェックポイント □ ユーザの後に立って実際の操作を見るのも有効な確認方法 □ 画面の雰囲気なども含めてユーザが違和感を感じていないかの確認 □ 後回しになりがちなネットワークや電源まわりもこの段階で確認 ■ユーザの意見や反応をプロトタイプに反映 プロトタイプをユーザに試用していただくことで、多くのことがわかりました。次は、ユーザの意見や試用時のユーザ の反応をプロトタイプに反映します。たとえば、プルダウンで値を選択するようにしていたのだが、別画面を表示して そこで値を選択するほうが効率的で視認性が良かったなど、実際にユーザが使用することで初めて確認できる要素も反 映します。ここまでは、あくまでもプロトタイプとして作成してきているので、かなり無駄のある作りだったり、力任 せの処理をさせている部分もあったりするかもしれません。デベロッパとしては勇気ある決断といえるかもしれません が、この段階で再度最初から作り直した方が、かえって良い場合もあります。実際、プロトタイプの試用で集まった情 報をもとに最初から開発したソリューションは、稼働後のメンテナンスが非常に効率的になる場合も多いのです（単 に初期設計が甘かったという場合も多分にありますが…）。 他のデータベースの開発環境に比べて開発スピードの速い FileMaker Pro であれば、プロトタイプによる試用後に再開発する体制が、取りやすいように思えます。 今回のケースでは、集計項目の算出にかなり無理がかかる仕組みをプロトタイプに作成してしまっていたために、ほぼ全 面再開発の決断をしました。FileMaker Pro Advanced であれば、スクリプトデバッガ、データベースデザインレポート、 テーブルのコピー & ペースト、フィールドのコピー & ペーストなど、開発を効率化する機能がバージョンアップごとに 追加されています。古いバージョンを使用していた時と比べると、比較にならないスピードで再開発することが可能です。 また、プロトタイプの開発・試用の段階で、ソリューションの導入後にビジネスの変化にあわせてユーザが変更を希望し そうな要素がどこにあるかなど確認できていますので、再開発の場合、メンテナンスに関することにもとてもよく目が届 くようになります。 「レコードとして格納したほうがいい」 「テーブルで分けたほうがいい」 「ファイルを分けたほうがいい」 または「スクリプトで処理しよう」など、ユーザの感覚を大切にしつつ、運用後の管理にも配慮した構成とします。 機能強化が進む、FileMaker Pro Advanced 17 また、ソリューションの導入後、ユーザが変更を多く希望するレポート・印刷部分に関してもこの段階で再検討して構 成を整えます。 ［ ユーザの意見や反応をプロトタイプに反映 ］におけるチェックポイント □ プロトタイプでのリクエストをどのように反映するかを決断する □ 完全に再開発だとしても、2 回目は比較にならない速さで仕上げることも可能 □ 実運用時のメンテナンス性も合わせて本番環境に反映させる □ 後回しになりがちなネットワークや電源まわりもこの段階で確認 ■実際の環境でテスト運用 プロトタイプ試用でのユーザの意見や反応を反映して完成したソリューションを、実際の運用環境にセットアップして、 運用を開始します。ここでは、ネットワークを経由して活用した場合のソリューションの動作を念入りに確認します。 レコードを扱うユーザ管理をネットワーク上にある LDAP や Open Directory といったユーザ管理サーバーが行う場合 もありますから、それと連携する操作も想定して確認します。また多量の集計作業など、相当の高負荷がネットワーク にかかることもありますので、ネットワーク上の他のソリューションの影響も含めて、ネットワーク運用を確認するこ とが必要になります。ネットワーク上のボトルネックの把握はこのタイミングで完了し、問題点は解消します。 プリントアウトを含めて出力帳票系の調整がここで必要になります。セグメントを越えたプリンタで出力しなければな らない場合など、集計時間や出力時間が実際に実用に堪えうるかどうかの確認が必要になります。作成したスクリプト やフィールド定義（グローバルフィールドや変数）などが、スタンドアロン環境とネットワーク環境とでは大きな違い が出てくる場合もありますので、実際の運用が始まるまでに確実に問題点は解消しておきます。 ［ 実際の環境でテスト運用 ］におけるチェックポイント □ 実際のネットワーク環境での運用テスト □ ネットワークプリンタへの出力調整 □ ユーザ管理方法によっては実際のネットワークで始めてテスト可能 □ レコードのエクスポート／インポートなどを実際のネットワーク上でテスト ■運用開始 運用開始してからは、まずはじめに、確実に毎日正常運転がされているかどうか確認します。OS の各種エラーログや FileMaker Server のログファイルを確認のために利用します。場合によっては、予め FileMaker Pro ファイルでエ ラーログを収集できるように準備したり、最終エラーを格納するファイルを作っておくのも有効です。更に、納入先と の協議も必要にはなりますが、エラーが発生したり、バッチ処理が終了したタイミングで、レポートをメール送信する 仕組みを、運用が安定するまでの間だけでも組み込むことができれば、デベロッパとしては安心です。いずれにしても、 FileMaker Server でホストされているファイルが確実に開いて、ネットワーク上のクライアントから問題なく利用さ れていることを確認します。 次に、月替わりや年替わり、年度替わりなど、期間をまたぐタイミングでは、集計処理の間違いが発見し易いので、処 理や動作に問題がないか確実に把握でき、問題に対処できるような準備と体制を整えておきます。 特に集計処理の場合、間違った索引設計やフィールド設計が問題の原因の場合は、ソリューションの修正にとてつもな い時間を要すことになりかねません。それぞれの値をどのように保存して、どのように更新していくかについて実行時 18 間を計測しながら開発を進め、パフォーマンスが稼げる設計を心がけます。集計処理でパフォーマンスが出ないと、「遅 いねぇ」などと言われかねないので、デベロッパの頑張りどころともいえます。 ［ 運用開始 ］におけるチェックポイント □ 確実に動いていることを確認する手段を確保 □ 期間をまたぐタイミングでの集計トラブルには対応体制を予め準備 ■今後の改善のためのヒアリング 実際にユーザが使用しはじめると、ユーザビリティや出力された帳票やレポートの微妙な位置修正や文言修正などの細 かい部分から、大きな変更に至る部分まで、様々な修正要望が出てくることが予想されます。逆にこれが出てこないよ うだと、実は、ユーザに有効に使用されていないとも考えられます。多くの各種修正要望は、今回納入した新しい仕組 みへの期待の表れととって、作業を進めることが大切なように思います。 また、ユーザそれぞれの修正要望をばらばらのフォーマットで提出されると、受け取る側の作業が煩雑になります。ま た、レポートされる項目も統一されていたほうが、効率的です。ソリューションの各レイアウトや要望をレポートする ユーザ名などを自動で差し込みながらレコードが生成できる「リクエスト・ソリューション」のようなものを作成する のも一案です。また、ソリューションが正常に動作しないことをユーザがレポートできる「バグ報告・ソリューション」 も同じように作成して、ユーザからのフィードバックを受け取りやすい（報告してもらいやすい）環境を作っておきま す。このソリューションへのレコード追加もメールなどと連動して、レポートが作成されたらメールで自動送信された り、同じような内容には追記ができるようにしておけば、要望事項やバグなどについての見通しの良いレポートが、ユー ザの手で半自動的に作成できるようになります。 要望やバグに対応した後、その内容を書き込んでいけば、この仕組みは、オンラインヘルプに上手に転用できる場合も あります。ドキュメントベースのマニュアルを、こうしたユーザとともに作成していく FileMaker Pro ベースのオンラ インヘルプにすることができれば、ユーザに喜ばれるだけでなく、ユーザの作業効率が向上したり、マニュアルを作成 するための手間、時間、コストなどの削減にもなります。 また、こうした、ヘルプ、バグ報告、リクエストなどのソリューションを手を抜かずに一度開発しておけば、デベロッパは、 他のクライアントの案件でもカスタマイズするだけで流用することも可能です。 ［ 今後の改善のためのヒアリング ］におけるチェックポイント □ 修正要望は期待値の現れ □ 修正要望、バグ報告、などをも FileMaker Pro ファイルに格納できる仕組みを作って、クライアントが書きやす い環境も考慮 □ ヘルプも FileMaker Pro ファイルで実現を検討 ■まとめ： 次のステップへ向けて ここまで既に触れてきた内容ではありますが、FileMaker Pro ベースでのソリューションに限らず、まずはクライアン トとの意思疎通、コミュニケーションが非常に重要な点だと思います。最も良くできたソリューションは、使う人が作っ たものと古くから言われています。FileMaker Pro をベースにしたソリューションがユーザに喜ばれるのは、使う人と 作る人が近い関係にあることが多いからではないかと思っています。 組織内で作り手と使い手の 2 つの役割を担う人が、 FileMaker ソリューションを作る場合もあります。 また FileMaker Pro は、 デベロッパとクライントのコミュニケーショ ンの結果を反映させやすい開発環境を備えているとも感じます。根っからのプログラマで無くとも、業務利用に十分堪 19 えうるソリューションを作れる開発環境が、FileMaker Pro なのだとも私は思っています。 わたしはコンサルタントとして、FileMaker Pro のマーケットは、そこに商取引がある限り必ず存在する無尽蔵のマー ケットだと思っています。どんな小さな要望にも素直に耳を傾けて、小粒でも確実にユーザのニーズを反映させていく 仕組みを作り続けることが大切と感じています。FileMaker Pro のソリューションは、最初は小粒でも最終的には、ク ライアントの業務に欠かすことのできない効率的な仕組みに育ちます。今回の旅行会社では、最初は顧客管理の仕組み だけから話は始まりましたが、それが次第に、ツアー管理、営業管理、精算管理、収益管理と当初は想定もしていなかっ た仕組みが相互に補完しあう形のソリューションへと成長していきました。市販パッケージでは、それぞれの流儀があ るために、ユーザの望む全ての内容に対処可能にはなりません。そんなときに、こうした FileMaker Pro によるソリュー ション開発は、小回りが効き、かつリーズナブルでスピーディな開発方法のひとつとして非常に有効なものとなること と考えます。 ■著者紹介 有賀啓之（あるが ひろゆき） 株式会社 DBPowers 代表取締役 鉄鋼メーカーで ファイルメーカー Pro 2.1 に触れ、Macintosh 漢字 Talk 7.5.1 + ファイルメーカー Pro 2.1 による利 益管理が最初に組んだシステム。 普通の人がやりたいことを実現できる、またはその可能性を感じることができる FileMaker Pro の魅力に引き込まれて、 このソフトウェアを事業の中心に置く現在の会社を設立。FileMaker Pro のことを、人を成長させてくれるアプリケー ションであると信じて疑っていない。根っからのプログラマではなかったのが功を奏してか、あくまで使う側の立場で システムに携わることになったのが今の会社の基盤となり、ユーザサイドにたったシステム提案、構築を心がけている。 システムベンダと発注者との間に入り、相互の橋渡しの役を担うことも主要な事業内容となっている。 北海道の FileMaker ユーザコミュニティ [FM-Hokkaido（www.fm-hokkaido.net）を創設、主催 FileMaker Excellence Award for Evangelist of the Year を受賞（2007 年） FileMaker 8 Certified Developer FileMaker Business Alliance 主な著作物 「FileMaker Pro 実践ビジネス活用テクニック」 （株式会社ビィー・エヌ・エヌ新社） 「ファイルメーカー Web パブリッシング FileMaker API for PHP コンプリートガイド」 （株式会社アスキー） 20 ソリューション開発のチェックポイント（1/3） プロジェクトの始まり □ 意向と経緯の確認 □ 目的と成果物（ 目指したい方向 ）の確認 □ タイミングをはずさず現状確認 □ 規模の把握とハードウェア、ソフトウェアの使用実態の把握 □ 決定権の所在とヒアリング先の把握、確認 □ 可能であれば、方向性のラフイメージを伝えて全体観を把握してもらう □ 使うソフトウェアの仕組みや特徴を概略で伝える ユーザへのヒアリングの開始 □ 聞くべき内容と聞くべき対象を区分してヒアリングする □ いきなり細かい部分でのヒアリングはせず、大枠で業務フローを捉える □ 現在のファイルの名付け方や作成のタイミングのルールを把握 □ 現在発生しているトラブルやその原因を現状のソリューションの使用実態と合わせて 可能な限り把握する □ FileMaker Pro オリジナル機能でのカバーエリアとエリア外を把握 調査結果の報告と方向性の確認 □ 大枠での報告を踏まえて方向性を確認 □ 現在の問題点の理解とその解消を目指す新しいソリューションへのアプローチを報告 □ 新しいソリューションでは既存の問題点がどのように解消されるかを報告 ソリューションの提案と構成の確定 □ 共有フォルダ型のファイル共有の利便性と問題点の明確化 □ FileMaker Pro データベースのネットワーク共有の仕組みと利便性の明確化 □ ソリューションのパフォーマンス、信頼性、安全性、柔軟性の確保 □ FileMaker Pro を取巻く環境とコミュニティ FileMaker TechNet への参加 21 ソリューション開発のチェックポイント（2/3） データの移行 □ 過去のデータはその会社の宝なので極力移行に努める □ 移行の際の情報の取捨選択はクライアント側でその重要度を判断してもらう □ 移行作業はクライアント側で使い慣れたソフトウェアを使用してもらう □ 表計算上の同じ１行に関連情報を集約して移行を促進する □ 移行作業の処理内容と理由を説明してデータベースと表計算の違いを説明 プロトタイプの作成 □ FileMaker Pro での作業を始める前に必要な項目（フィールド）を整理 □ 表計算ソフトを使うことで効率良く項目を整理 □ 構造を将来のメンテナンス性と合わせて確認、設計 □ リレーションの基本構造（主キー・外部キー）を確認 スタンドアロン環境での試用 □ ユーザの後に立って実際の操作を見るのも有効な確認方法 □ 画面の雰囲気なども含めてユーザが違和感を感じていないかの確認 □ 後回しになりがちなネットワークや電源まわりもこの段階で確認 ユーザの意見や反応をプロトタイプに反映 □ プロトタイプでのリクエストをどのように反映するかを決断する □ 完全に再開発だとしても、2 回目は比較にならない速さで仕上げることも可能 □ 実運用時のメンテナンス性も合わせて本番環境に反映させる □ 後回しになりがちなネットワークや電源まわりもこの段階で確認 22 ソリューション開発のチェックポイント（3/3） 実際の環境でテスト運用 □ 実際のネットワーク環境での運用テスト □ ネットワークプリンタへの出力調整 □ ユーザ管理方法によっては実際のネットワークで始めてテスト可能 □ レコードのエクスポート／インポートなどを実際のネットワーク上でテスト 運用開始 □ 確実に動いていることを確認する手段を確保 □ 期間をまたぐタイミングでの集計トラブルには対応体制を予め準備 今後の改善のためのヒアリング □ 修正要望は期待値の現れ □ 修正要望、バグ報告、などをも FileMaker Pro ファイルに格納できる仕組みを作って、 クライアントが書きやすい環境も考慮 □ ヘルプも FileMaker Pro ファイルで実現を検討 23 www.filemaker.co.jp 2008.6
© Copyright 2024 ExpyDoc
