【コラム】

"本当の顧客要求"のつかみ方

4 脳裏にモデルをもって臨む

 

4/6

企画段階で必要なスキル

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

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

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

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

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

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

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

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

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

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

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

図1: 業務とITの関係

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[an error occurred while processing this directive]

4/6

インデックス

連載目次
第6回 合意の形成 - 同じ基準をもつ
第5回 ユーザの要求を鵜呑みにしない
第4回 脳裏にモデルをもって臨む
第3回 ステークホルダーを正しくつかむ
第2回 共通の目的意識をもつ(プロジェクト定義書)
第1回 シナリオをもって臨む

もっと見る

執筆者紹介

山岸耕二(YAMAGISHI Koji)
- メソドロジック代表取締役社長。要求開発アライアンス理事長


京都大学工学部修士課程を卒業し、1982年にシャープ入社。超LSI研究所にて次世代デバイスの研究開発に従事する。1989年にオージス総研入社。以後、一貫して、オブジェクト技術を適用したシステム開発や方法論の導入など、ITによるビジネス創出に携わる。その後、ウルシステムズのCTOとして立上げに参画、2004年に豆蔵に移籍し、代表取締役副社長に就任。同社代表取締役社長を経て、2009年に株式会社メソドロジック設立。

現在は、株式会社メソドロジック代表取締役社長を務めるかたわら、現役のコンサルタントとして顧客企業を支援する。また、「リフォーマブル・プラットフォーム・アーキテクチャ」というコンセプトを提唱しており、「もはや更地からの構築はない、継続的リフォーム前提の基盤構築が必要」という見地から、今後を見据えたエンタープライズシステム構築・移行手法の策定を進めている。

近著に「要求開発」(日経BP社)、訳書に「ユースケース実践ガイド」(翔泳社)、「適応型ソフトウエア開発」(翔泳社)などがある。



転職ノウハウ

あなたが本領発揮できる仕事を診断
あなたの仕事適性診断

シゴト性格・弱点が20の質問でサクッと分かる!

「仕事辞めたい……」その理由は?
「仕事辞めたい……」その理由は?

71%の人が仕事を辞めたいと思った経験あり。その理由と対処法は?

3年後の年収どうなる? 年収予報
3年後の年収どうなる? 年収予報

今の年収は適正? 3年後は? あなたの年収をデータに基づき予報します。

激務な職場を辞めたいが、美女が邪魔して辞められない
激務な職場を辞めたいが、美女が邪魔して辞められない

美人上司と可愛い過ぎる後輩に挟まれるエンジニアの悩み

人気記事

一覧

イチオシ記事

新着記事

[今週の新刊]「重版出来!」が登場 「火ノ丸相撲」や「僕のヒーローアカデミア」も
[18:30 8/28] ホビー
[中野杏]アイドルでパンクロッカー? ミスFLASHが“初心者目線”でNBAをPR!
[18:13 8/28] エンタメ
シチズン×モンベル、プロユース「PROMASTER」とアウトドアのコラボ時計
[18:08 8/28] スマホとデジタル家電
[美少女戦士セーラームーン]うさぎの布団が商品化 布団カバーと枕カバーがセットに
[18:04 8/28] ホビー
[ディーン・フジオカ]イベントで清野菜名とケーキ入刀 結婚式の思い出語る
[17:51 8/28] エンタメ

求人情報