企画段階で必要なスキル

システムの企画段階では、様々な形式でのヒアリングが必要である。

前回示したステークホルダーリストから重要度の高いヒアリング対象者を抽出したら、相手に応じて、戦略や業務の内容、ITの現状などのトピックスを聞き取りながら、その全貌を把握して、課題を理解し、攻略ポイントを絞った上で、課題の解決策を導き出す、という流れになる。ここでは、経営者、業務管理者、業務担当者、システム利用者などを総称して、ユーザと呼ぶことにする。

さて、上流工程ではとかく業務知識の多寡を問われることが多く、提案活動や案件に際して書籍などから付け焼刃的に業務知識を得ようとバタバタしてしまう場面も多々あるだろう。

確かにその領域で仕事をした経験があれば、ある程度頭の中に体系ができあがっているであろうから、未経験にくらべるとアドバンテージは大きい。少なくともユーザから「そんなことも知らんのか」という扱いを受けることはないだろうし、ユーザにとっても一から説明する必要がなく同じ言葉で話せるというのはありがたい話だ。

しかし、ある特定の業界の狭い領域に特化したコンサルタントでもない限りは、結局のところユーザ以上に専門家でありうるはずもない。すべての分野で専門知識をもつというのも現実的ではない。それならば、個別専門知識で戦うのではなく、上流工程での汎用知識やスキルによって、バリューを打ち出していくべきであろう。

筆者が上流工程においてもっとも重要視しているのは、「プロジェクトファシリテーション能力」と「モデリング能力」である。前者は、この連載の初回で述べたように、企画工程の進め方のプロセスなどを身につけてシナリオをもってプロジェクトに臨み、状況に応じて適切に舵取りする能力である。後者は、対象とする領域や課題について、全体構造や本質をとらえて表現する能力である。

今回は、このモデリングについて触れてみたい。

業務を上位システムととらえる

システム開発の世界でモデリングというと、UMLなどを使ったオブジェクト指向の分析・設計モデルの構築、ER図やデータフロー図によるシステム設計あたりをイメージされるだろう。

かたや「業務」というと途端に人系の話になってしまい、システムとは別の世界として扱われがちだが、本来、システム化を対象とするような業務は、それ自身がシステムとして表現される必要がある。

図1にその一例を示す。顧客からの「商品を発注する」というサービス(ビジネスユースケース)に対応するために、事業体のシステム内で、それぞれの役割を担った人や組織、そしてITシステムが協調して活動する。スコープの違いはあれ、その様子は、ITシステムが提供するサービス(システムユースケース)を実現するために、内部でそれぞれの役割をもったオブジェクトが協調して活動するモデルと同じである。

図1: 業務とITの関係

このように「業務」をまず上位のシステムとしてとらえて、「ITシステム」をそれを構成するサブシステムとしてとらえることで、業務とITの関係を位置づけることができるようになる。業務やITの課題や攻略点を正しく把握していくためには、まずは業務をこうした業務フローのような動的モデルや(ここでは示していないが)概念モデルのような静的モデルで表現して、システムとして全体構造をとらえていくことが非常に重要である。

大小さまざまな話を同様に扱っていては"コンサル失格"

ユーザ、特に現場担当者は、日頃、構造化、抽象化といった活動にあまり慣れていないこともあり、彼らの話は概して平面的である。現場で困っている話を、大きな話も小さい話も、本質的な話も詳細な話も、まぜこぜのまま浴びせかけてくることが多い。

業務知識をもとに現場と同じ目線で話を理解できること自体はいいことだが、同じレベルで混乱したり、傷をなめ合うような話に同調していてはコンサルタントとして関わる意味がない。

システムにディープに関わってきたバックグラウンドがある方は、当たり前のように構造化や抽象化といった行為を行ってきたはずである。そのスキルを活かして、ばらばらに入ってくる情報を、つなぎ合わせて全体像を見せたり、抽象化して本質的な課題に迫るなど、彼らとは違った視点を提供してこそ、真価が発揮できるというものである。

現場は目先の視角範囲でしか見当がつかず、局所最適な窪地でホフク前進していることが多い。システムを扱うプロとしては、全体地図と彼らの居場所、可能ならば行くべき場所を航空写真のように示すというところで力量を問いたいところである。

仮説を持ってヒアリングすれば前向きな展開に

さて、具体的なヒアリングの場面で心掛けておきたいのは、事前に自分なりのモデルを仮説として作っておくということである。

その際に基本となるモデルは、プロセスを表す業務フローと、その業務を構成する構造を表す概念モデル(筆者の場合は、UMLのクラス図)である。

そもそも、その業務領域の知識が豊富であれば、形式化されているかどうかはともかく、その体系がある程度頭の中にできあがっているであろう。その業務領域が初めての場合でも、似たような業態の案件を経験していれば、想像力でおおよそのモデルは描けるはずだ。まったく未経験の分野であったとしても、ビジネスとして成立しているものであれば、遠目に見れば、同じに見える構造が至るところに見つかるものである。

世の中には、これらを巧みに抽象化して表したアナリシスパターン※1などもあるが、そこまで極めなくても、例えば、およそ「注文」や「受注」であれば、「顧客」、「受付者」、「商品」などをひとセットとした基本パターンがある。

※1 参考文献
「アナリシスパターン―再利用可能なオブジェクトモデル (Object Technology Series)」

そうしたビジネス常識の裏付けさえあれば、素人ながら得たその分野についての知識を加えて仮説的なモデルを作るのはそれほど無理なことではない。完成度は低くても、手元にモデルをもっていれば、ヒアリングは、その不足を補い、仮説を検証する場となる。このモデルを完成させるように情報を入手していけば、自身の中に確かな知識・情報体系が確立できるのである。

その領域の業務は初めてだからと言って、まったく白紙で話を聞き始めると、行き当たりばったりの質問をしてしまいがちだ。ユーザからすると脈絡がつかめず、何に力点をおいて答えていいかがわからない。思いつきの質問をするうちに「それはさっき話したでしょう」とかと言われようものなら、この先ユーザの積極的協力は得にくくなる。

モデルに沿って仮説を確認するように話を聞いていけば、ポイントを突いた質問ができるようになる。ユーザにとっても一連の流れを感じとることができ、それに沿った受け答えをすることで、自身の知識の整理もできてくるはずだ。

モデルを念頭においてある程度当たりのつくところを「きっと○○ですよね」とか確認してみると、「何でわかるんですか?」とか、「そうなんですよ」といった反応を受けることがよくある。ユーザとの間でそうしたリズムあるやりとりができれば、ユーザは話しがいを感じて、前向きに協力してくれるだろう。

ユーザと一緒にモデルを作るのも有効

もっと直接的手段としては、ユーザとセッション形式で一緒にモデルを作るというやり方がある。筆者はもっぱらその手法を取る。

「クラス図などはおよそユーザには理解できない」という意見が大多数だが、面倒な説明はほどほどにして、実際にユーザの話したことを、写生をするように図にのせていくと、ユーザは「ほう」という感じで、それらが全体像を作っていくのを感心しながら眺めてくれる。

そのうちに、要領をつかんで、自ら図に手を出してくれたりもする。ここで多少整理を進めて、抽象化してみせたり、共通部分をくくりだしたりして、「要するに」といったレベルの理解にまで導ければ、畏敬の念でみられることもある。

こうしてユーザを巻き込みながら、かつユーザ主導を演出しつつ、一緒にモデルを構築すると、そのモデルを共通の地図として議論ができるようになり、そこからの検討作業は非常にスムーズになる。

ただし、この場合もユーザと向き合ってから、初めてひと筆目を置くのではなく、事前に、予習として自分なりのモデルを作っておいて、それを念頭に、あたかもユーザとともに一から作ったかのようにモデリングすることを強くお勧めする。

先にも述べたようにユーザと向き合うときには真っ白な状態ではらちがあかない。事前に自分なりのシナリオとモデルをもった上で、一定のリズム感を保ちながらプロジェクトをファシリテートしていくことが重要なのである。