連載：グループウェア徒然草（8）

グループウェア的アプリケーションのシステム化（上）
「業務をよく知り、システム化の方向性を考える」

関 孝則
2002/2/16

　ワークフローのアプリケーションで、その承認などのプロセスの中に不明確であいまいな部分を含んでいることが多々あると、以前、連載の中で取り上げました。グループウェア上のアプリケーションといっても、インスタントに小さく作るものから、本格的な開発を必要とするものまでいろいろありますが、今回は、全社展開など本格的な開発が必要なグループウェア・アプリケーションのシステム化について考えてみましょう。そして、そこから垣間見られる、グループウェア・アプリケーションの要件定義やシステム化の難しさ、特徴について考えてみます。

■業務のルールはどこに？

　ワークフローのアプリケーションなど、グループウェアが扱いそうな社内業務をシステム化するためには、当然ながら、その業務のプロセスを理解するところから始まります。まずは、そのよりどころとなる文書類があるかどうかを当たることになるでしょう。どこの会社にでもある、「社内標準」とか「社内マニュアル」といったたぐいの文書がそれに当たるでしょうか。

Illustration by Sue Sakamoto

　伝統ある企業などだと、その業務のやり方に関してかなり詳細なプロセスが定義されていることがあります。ただ、ほとんどの企業では、それぞれの業務のやり方について基本的なルールは決めていても、すべてが記述されたものなどないのが常でしょう。どちらかといえば、その業務の最終的な処理を行う部門、よく主管部門などと呼びますが、その主管部門の担当者が業務にかかわる紙のフォームなどに、その業務の詳細な進め方を少しだけ書いたり、場合によっては担当者自身がルールブックとなって業務の詳細なやり方をガイドしたりしているのではないでしょうか。こうなると、その業務は実際にはあるガイドに従って運用されているものの、例外的なやり方や新しいやり方に変わっていく余地が多分にあります。

　本当の業務の姿を知るには、主管部門、ユーザー部門、関連部門とインタビューを行い、実際どう処理しているかということを明らかにしていかなければならないでしょう。そして、ある程度想像できるように、業務の実体はかなり幅のある、例外を含んだ姿ではないでしょうか。例えば、ある顧客でワークフロー業務の承認の代行を調べていくと、部門によって、また業務によって代行できる役職の範囲が異なるとか、同じ紙のフォーム上の項目でも、部門やそのときの業務によってその解釈が異なり、柔軟に記入が行われているというのは、実際によくある話です。

■不定形さと変化が“グループウェア的”

　このように、一見きちんと運用されていそうなワークフローの業務ですら、そのやり方に幅があります。また、グループウェアでよく扱われる報告書を共有したり回覧したりするような業務では、さらにそのやり方の自由度は増します。このようなあいまいさは「不定形業務」といった言葉で表されたりしますが、これが“グループウェア的”なアプリケーションの特徴の1つといっていいかもしれません。

　考えてみれば、社内のグループウェア的な業務は、基本的には顧客との契約や約束事を文書化していくような対外的なプロセスとは異なり、ビジネス・ニーズの発生とともに当事者間で定義され、そしてビジネスの変化とともに微調整が繰り返される成長や変化していくもの、と考えることができるでしょう。また場合によっては、その業務の主管部門の官僚主義的な体質から、現在のビジネスの実体に合っていない、昔のやり方で固定されている業務が、皆さんの周りにはあるのではないでしょうか。こうなると、実際の業務の運用にはかなりの見えない部分の例外がありそうです。このように、グループウェア的な社内業務のシステム化は、いろいろ困難が待ち受けていそうです。

■業務を調査、ヒアリング、観察

　さて、いずれにしても、システム化するためにはそのアプリケーションの要件定義を最初に行わなければなりません。このように、ややつかみどころのない部分があるグループウェア的業務にとって、この要件定義は一番注意しなければならないステップかもしれません。

　要件定義の最初のステップは、業務の定義を調査し、担当者やユーザーに意見をヒアリングすることが中心となるでしょう。上でも述べたように、社内業務の実態を把握するには、その業務の定義が明確でない場合が多いことから、勢い担当者やユーザーへのヒアリングがその中心を占めることでしょう。もちろんそれ自身は、その業務の実体を知るうえで極めて有効な手段となるでしょう。

　ただ気を付けなければいけないのは、定義が明確でないところは、本当に限られた担当者やユーザーへのインタビューだけでは、その業務の実態を正確につかむのは大変困難になるかもしれないということです。逆にその業務にかかわったことのある人、全員にヒアリングすることも現実的ではありません。ここでのポイントは、適切な担当者と適切にサンプリングしたユーザーへのインタビューということでしょうか。

　また、必ずしも業務に詳しくない人がヒアリングするということで、すべての明文化されていない業務ルールを聞き出すというのも、まさに神業です。紙ベースのワークフローですと、差し戻しのルール、事前承認のルール、場合によっては根回しでの承認のルールと、多くの見えない部分が存在しているのが常です。ここで助けになる手法が、現実の業務の書類をよく観察して、それに基づいてインタビューをするとか、もし可能な場合には、その業務の流れを実際にそばで追っていくという疑似体験などがあるでしょう。これらはある意味で、かなり時間のかかる作業ではありますが、これにより実態が見えにくい業務の本当の姿に近いものを明らかにしていくことができるでしょう。

　例えばワークフローの承認というプロセスだけを見ても、過去ほとんど一度も否認したことのない承認ステップなどは、ち密な観察とヒアリングにより発見することができるでしょう。このことは、「承認」だと広くユーザーや主管部門が認識していたステップが、実は「決済」だったり、常に賛成の意見を述べる手段だったり、あるいは単に情報を提供するための「閲覧」だったり、という分析をすることができます。これらの観察とその分析は、要件定義後のシステム化の姿を決めるうえで、極めて重要な材料となるのではないでしょうか。

■どんな業務にすべきか

　さて、インタビューの中で当然出てくるのが、今後の業務に対する「こうしてほしい」という要望です。システム化の第一の狙いは、多くの場合、業務の改善でしょうから、当然これらの要望は願ったりかなったりです。ただその業務の主管部門、ユーザー、そして異なる部門のユーザーと、その業務に対してそれぞれ立場の異なる人たちからの要望は、ある意味で対立する要素も持っているでしょう。

　主管部門からは、その処理をよりやりやすくするため、また本社的な感覚から、可能な限りその業務から情報を取り出すために、新たにたくさんの項目をその業務のフォームに加えたいということがあります。ただこれらはユーザーにとって、その項目を埋めるために新たな調査などの作業が必要になったりと、前向きな改善とは受け取れなかったりします。逆にユーザーとしては、いままでは必要だった項目を可能な限り減らしたいとか、またその業務に付随して行わなければならない確認や承認などの仕事をできるだけ減らしたい、という要望が出てくることでしょう。

　考えてみれば、外部に対する業務であれば顧客の要望を第一として、社内の人間の作業に関してはその要望を満たす範囲でコストを下げるという目標と前提が、明確となっていることでしょう。ところが社内の業務に関しては、主管部門もユーザーも同じ社内の人間であり、それぞれの要望は互いに相反する部分があっても、ある意味で同じように扱わなければならなくなります。つまり、判断すべき単一の目標と前提が見つけにくいという性質があるといえるでしょうか。

　おそらくそこで必要になる考え方は、そのシステム化による効果のうち何を第一義的に考えるかといった、経営的視点に近い意思や目標ではないでしょうか。たくさんの要望をその意思や目標に照らし合わせ、優先度を付けたり、また矛盾する要望を整理したりすることができるようになります。ワークフローであれば、意思決定の迅速化、承認責任の明確化といった大原則が一般にはよくいわれることです。これにより、とかく承認プロセスが複雑化しがちな要望に対して、不要な承認プロセスを省いたりすることも可能となるでしょう。

■そしてシステム化

　社内の非定形的な要素を内包し、あいまいさをそこに含んだグループウェア的アプリケーション。そして要件定義として、その業務の実態を調査とヒアリングなどにより明確にし、かつそのシステム化の方向性について、意見と、さらに経営的視点での目標から明らかにする。そして次にくるのが、ようやく設計などのシステム化の作業です。次回はこれらグループウェア的アプリケーションのシステム化の考え方と、グループウェアという道具を使ってのアプリケーション開発について考えてみます。

筆者プロフィール

関 孝則（せき たかのり） 新潟県出身。国産コンピュータメーカーでの経験を経て、1985年IBM藤沢研究所へ入社。大型計算機のオペレーティングシステムなどの開発、IBMの著作権訴訟、特許権訴訟の技術調査スタッフなどを担当。1994年から日本IBMシステムズ・エンジニアリングでロータスノーツの技術コンサルティングを統括。代表的な著書に、リックテレコム社『ロータスドミノR5構築ガイド』（共著）、ソフトバンク ノーツ／ドミノマガジンの連載『ノーツ/ドミノ・アーキテクチャー入門』、日本IBMホームページ上のWeb連載『SE関のノーツ/ドミノ徒然草』など。 メールアドレスはts@jp.ibm.com

「Master of IP Network総合インデックス」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）