従来、部門ごとの人の作業を支援してきた個別システムが、部門横断的なシステムへと連携される流れになって久しい。

機動力の高い"サイボーグ"を作るために

もともとは、企業内での人とITの関係は、営業から、受注、調達、生産、在庫管理、物流、会計などが人系の伝票の流れで作られていて、それぞれの作業をシステムが支援するという構造を元にしていたが、今は情報システムがその流れを作っていて、そのコンベアに対して営業や製造、経理などの担当が作業をしていると見えなくもない。

今となっては、主客の判別は困難である。中枢を成すコンベアの役割はすでにコンピュータが担っているし、人がやっていた作業の中でパターン化できるところや、大量の処理は、当然、CPUの方が正確かつ効率的なので、そちらに置き換えた方が、全体のパフォーマンスは高くなる。

こういった、IT系と人系が絡まり合って動作する今どきの業務形態を、筆者は、メカと生身を組み合わせた「サイボーグ」のメタファで表現している。業務そのものはきわめて複雑なシステムであり、定常的な作業とともに、日々発生する例外的な悩ましい案件も処理しなければならない。

マニュアル化できて、比較的長期に変化がない処理は、コンピュータ化して効率化をはかり、逆に短期で変わってしまうところや予測不可能なところは生身の柔軟性に任せるというサイボーグの最適設計が必要なのである。

生身に残すべきところをへたにITで固めてしまうと、今度はそれが業務の足枷になり、かえって機動力が落ちてしまう。業務という上位のシステムから、人系とIT系の特性の違いに基づいて、最適なIT化の範囲を切り出すという方針で対処していけばいい。

企業としての仮想的に1つのシステムがイメージできたら、企業によっては、既存の陳腐化システム群をすべて更地にして、一気に新システムに刷新するような再構築ビッグバン・プロジェクトを起こすこともあるが、多くの場合は、さまざまな制約から、既存の個別システムをEAIやESBなどで連携して、なんとかそれらしく整えようというアプローチを取るようである。

現場からの"総すかん"を防ぐための道具

いずれにしても、システムは、個別ではなく、エンタープライズのスコープで企画すべき時代になっている。エンタープライズワイドの話をするときは、個別システムのときとは違って、関連する部署も多く、立場のちがう多数の利害関係者を扱わなければならなくなる。

全体最適の観点で導入するシステムは、個々のユーザや部署の視点からみると、何かと不都合や面倒を強いることにもなる。業務の現場は、ただでさえギリギリの状況で操業していることも少なくない。システムの都合でデータの入力の作業が増えたり、作業の導線が変わったりすると、業務が混乱して、破綻するケースもある。

事前の十分な説明もなく、業務のやり方を変えさせるなどは、感情的にも受け入れられないだろう。現場からの総すかんという状態はこうしたプロジェクトでは、もっとも避けるべき事態である。ステークホルダーへの適切なケアはプロジェクトの成否に直結するといっても過言ではない。

そのため、筆者は、プロジェクトを開始した早い段階で、図1のようなステークホルダーリストを作成することを強くお勧めしている。

ステークホルダーリストの例

これは、プロジェクトに関わる人にはどのような立場の人がどれだけいて、プロジェクト自体、あるいは、プロジェクトの結果によって、どのような影響(プラスもマイナスも含めて)を受けうるのかを整理した一覧表である。

声の大きい人に引きづられないために

こうした用意なくプロジェクトを進めると、つい声の大きい人の話を重視しがちで、それに引きずられて不本意な結果につながることになりかねない。事前にプロジェクトの趣旨に照らして、重要度などを冷静に決めておくと、後から惑わされずに済む。

また、上掲のリストは、ヒアリングや様々なモデリングセッションで具体的に誰を巻き込むべきなのかを計画するための基礎資料になる。現場の方々はともかく忙しい。早め早めにアポを取っていかないと、セッションの時間調整に手間取って間延びしたスケジュールになってしまう。

ここで重要なのは、「想定される影響」とその手当をするための「確認ポイント」である。特にマイナスの影響が想定されるときには、それに対しての説明をし、理解を得る機会を設け、慎重に対応しておく必要があるだろう。

紙面の都合上、図の例では端折っているが「確認ポイント」には、「どのような視点が重要であるか」と「どのタイミングで、どういう対応をしておくか」を記載するようにしている。

根回しを怠ると、思わぬところが火種になって、高転びに転ぶことがある。適切なタイミングで合意を得て、言質をとっておくことに心がけたい。このタイミングやレビュー内容は、相手がスポンサーなのか、直接画面で入力する人なのか、現場の業務の人なのかによって大いに異なるので、決して「全体会議で1回やっておけば」というものではない。それぞれの視点に立ってみて、何を確認したいと思うかをイメージしながら設定していかなければならない。

特にシステムが導入されたときの業務へのインパクトは、ある程度機能が明確になった時点、かつ、システム開発の手戻りが大きくならないうちに、シミュレーションして現場で許容可能であることをいっしょに確認しておくことである。

「ひどく悪く言っている人がいない」というのが重要

プロジェクトの成功を語るには、ゴール記述として具体的な成功指標を掲げてクリアするのが本筋だが、言外にある「ステークホルダーの納得感」を忘れてはならない。

みなが口をそろえて大成功と言ってくれる状態が作れればよいが、そんなプロジェクトは見たことがない。それぞれが、そこそこに納得していて、誰に聞いても「こんなもんじゃないの」くらいの反応が返ってくれば、これはかなり成功のほうである。極論すれば「ひどく悪く言っている人がいない」というのが重要で、そのためには、ステークホルダーを正しく認識して、要所、要所でそれらの人々の視点でみて問題がないことを確認し、合意を取って、一定の納得感のもとにカットオーバーを迎え、結果としても大きなサプライズはない、という状態を作ればいい。

こうした事前の整理のもとに人間系の力学を踏まえてプロジェクトを進めれば、余計な内部エネルギーを使わずに本筋の議論に集中できるだろう。