要件定義は、ユーザー様の業務内容をヒアリングして、どのような業務を行っているかや、どこに時間や人的作業が多く使われているかをまとめる工程です。
要件定義の詳細は、Webで検索すれば細かく説明したサイトがみつかりますので、情報収集して自分の知識としてください。
ここでは、eDocArrangementを使った業務改善をテーマとしていますので、一般的な要件定義の説明とは少し違ったものになるかもしれません。
一般的なシステム開発では、受注後に要件定義となりますが、eDocArrangementを使ったシステム提案では、簡単に設定が作成できることから、受注前にユーザー様の要望を聞き、そのうちの一部(少量であれば全部)の設定を作成してしまい、デモを見せることが可能です。
デモを見せることができれば、ユーザー様はイメージが膨らみ、これができるなら、こういうこともやりたいと、要件が広がって行きます。
最初から複雑な仕組みを考えても、時間を要してしまい、受注に至らない場合は、無駄となってしまいます。
まずは、業務の中で、大量の紙やファイルを手動で処理している部分を探して、その部分のみの自動化を行う提案をすれば良いと思います。
弊社では、eDocArrangementのデモ設定を作成するサービスを行っております。
内容でお受けできるか判断いたします。監視フォルダが1～3程度の簡単な設定であれば数日で作成することができます。
デモ設定の作成は、案件が成約しない場合は無償とさせていただきます。案件が成約した場合には、設定作成時にお見積もりした費用を頂いております。
eDocArrangementで作成可能な自動処理は限られていますが、DocuWorksの機能をAPIを使って呼び出すことができるため、DocuWorksを使って手動で行っている作業はほとんど自動化できます。
要件定義では、自動化したい作業を確認していきますが、いくつかのポイントがあります。
業務改善を行いたい業務で使用している帳票を、ユーザー様に提供していただき入手します。
現在、印刷して使用している帳票は、電子化できないか検討し、電子化できる場合は、スキャンして取り込むのか、Excelや既存システムからDocuWorkプリンタに印刷してXDW文書を作成できるのか、などを検討していきます。
自動処理を行うためには、帳票から情報を取得する必要があります。
スキャンしたイメージ文書の場合、OCRやQRコードで情報を読み取ったり、ユーザー様が貼り付けたアノテーションから情報を取得できないか検討します。
アプリケーション文書の場合、帳票中の文字情報を読み取ることができます。但し、ページ内のすべての文字が全て繋がった状態(改行は削除される)でしか取得できないため、取得したい情報の前後に、特徴的な文字が必要となります。
現在利用中のシステムから出力される帳票をXDW文書とできる場合、文書中から情報を取得することができますが、前述した、全ての文字が繋がってしまうという仕様のため、情報を取得しやすいように、出力される情報を変更可能かをユーザーに確認します。
変更可能であれば、「00001」を「管理番号:00001」のように先頭に固有のキーワードをつけてもらうようにすると、正規表現を使って「管理番号:」の後ろに続く5桁の数字を取得するなどの処理が可能です。
また、既存システムのデータベース等から、CSVファイルを出力できれば、eDocArrangementで、そのCSVファイルを読み込んで情報を取得することもできます。
扱っている帳票毎に、その帳票がどのくらいの期間、使われるかを調査します。日単位の処理なのか、週単位の処理なのか等をまとめて、その帳票をどのようなフォルダに格納して管理するのが最適かを検討します。
扱っている帳票の枚数が多い場合、時間当たり、一日あたりの処理量を把握します。
その数によっては、サーバーを複数台にして分散したり、データを軽量化するなどして、処理の高速化を検討する必要があります。
また、文書を保管フォルダに保管する際のフォルダ構成を検討します。例えば、保管される文書(ファイル)が、月に数十、数百の単位であれば、年、月のフォルダ構成で十分ですが、毎日、数百増えていくような業務では、年、月、日までのフォルダに細分化するなどの構成が考えられます。
要件定義や、システム設計の工程では、ユーザー様の業務で使用している用語や帳票の名前等を扱うことになります。
要件定義は、その内容を基にシステム設計を行うため、用語に表記揺れ等があると、関係者間での情報共有に支障がでます。
一つの物を表現する用語は必ずユニークになるように、定義、命名するようにすることが重要です。
例えば、ユーザー様で扱っている、ある帳票を「申請書」と呼んだり、「申請用紙」と呼んだりしていたとします。この2つの帳票は同じものなのか、それとも違うのかを明らかにして、同じものであれば、「申請書」のみを使うようにしていく提案をします。(少なくとも要件定義書、仕様書等では、「申請書」と表記するように統一します。)
別の例では、「見積もり番号」と「見積番号」のような表記ゆれがあると、自動処理の過程で、文書属性に見積番号を登録したい場合、どちらの表記で登録すればいいのか、曖昧になります。
これは当たり前のことかもしれませんが、作成する要件定義書や、仕様書、または関係者間でやりとりするメールの内容は、必ず見直しを行い、誤字脱字、表記揺れ等をなくすように心がけます。
システム開発で扱うドキュメントは、複数の人で共有して、意思疎通を行うための重要なものです。そのドキュメントに不備があると、仕様の再確認や、誤解、設定の作り直しや、修正等の様々な問題が発生することになります。
完璧でなくても、少し気を遣い、作成後にセルフチェックを行うだけでも、大きな効果が期待できます。