いよいよ本連載の最終回です。一目置かれるシステム屋になるための、問題発見と問題整理のやり方をお伝えします。

経営とビジネス環境を知ることから始める

企業の進む方向性や考えを知るには、経営戦略を知ることです。そのためには、経営者と話をするのが一番ですが、必ずしもそういうわけにはいきません。したがって、経営計画をはじめ、ステークホルダーとの関係、事業構造、製品やサービスの特徴を調べていきます。さらに、組織構造、社内の制度や規程など内部的な特徴も把握していきます。

現場との関係性づくり

現状調査をする際、部門外の人や社外の人が介在すると、現場が拒絶反応を示すことがあります。ITの知識や専門性だけでは受け入れてもらえません。

システム屋の理屈ではなく、あくまでもエンドユーザであるビジネス側の悩みを、“⁠本音ベースで話してもらう関係性を築くこと⁠”が大切です。そのために、まずはシステム屋がシステム以外の見地から話をしていきましょう。その際に、経営やビジネスの視点は重要な材料です。「⁠お…話がわかるじゃん！」と思われたらしめたものです。適度なアイスブレイクで心を解きほぐしながら話を進めます。

目的・ゴールはみんなで決める

「経営者やCIOが言っていたから、目的は決まっている。目的は新しい基幹システムの導入だ！」という声があったとしても、「⁠ちょっと待てよ…」と考えたいものです。上から言われたことをそのまま目的にしても、現場のエンドユーザの腹に落ちていないとその気にはなれず、無責任・無関心を招く要因となります。

現場の腹に落とすためには、目的をエンドユーザ自らが納得して決めることです。経営戦略や課題がぼんやりと見えていると、目的は「システム導入ではなく、コスト削減であり、その手段の1つがシステム導入である」と、考えられるようになります。システム導入だけではなく、業務プロセス変更などの環境づくりにも関心が広がってくるはずです。また、傍観者から当事者になり、参画意識が高くなります。

次は、自分で決めた目的やゴールを明文化し、関わっている現場以外の人にも積極的に見せていきます。

問題意識を共有する

関係性ができ、ある程度の目的やゴールのイメージを共有できたら、問題意識を共有します。この段階ではまだ、きちんと問題を整理する必要はありません。「⁠こんなのが問題だと思うんだけど…」とざっくばらんに話をしながら、システム屋のあなたは先に仕入れていた経営や組織の情報と頭の中で照らし合わせを行います。

業務の棚卸しは共同作業

現状調査の具体的行動の第一歩として業務の棚卸しを行います。よくあるのは、上司が現場に行っている業務を提出させて、それを積み重ねて部門全体の業務とするケースと、一方的にコンサルなどが現場をヒアリングして作り上げるケースです。どちらも、ダブりや抜けがあったり、名称・用語、業務単位、区分や範囲がバラバラだったりしがちです。

業務構造を把握し、階層化を行うことが必要です。「⁠どんな構造か？どの階層にあるのか？」といった視点で業務の棚卸しを共同作業として行い、相互の理解を進めます。

業務モデリングは現場が行う

ビジネスの価値に基づいてシステム開発を行うには、現状のビジネス全体像を正確に把握することが求められます。通常、業務をモデリングする作業は、ITコンサルや戦略コンサルが行いますが、彼らは現場の業務については詳しくありません。

むしろ現場の業務に精通しているエンドユーザがモデリングを行うのが一番早く確実です。そのために、システム屋がモデリングするコツやポイントをエンドユーザに伝授し、モデリングの最初の敷居をうんと下げることが大切です。該当部門の前工程・後工程の部門の人にも参画を促します。

モデリングの第一歩は超アナログでシンプルに開始！

我々は最初、模造紙と付箋紙だけを使います。記述するプロセスも4項目（名称、入力、出力、プロセス）だけです。超アナログ的です。これに、徐々にタイミング・前提条件・やり取りするデータ・必要なシステム・所要時間・ルールなどの情報を加え、イレギュラーなプロセスや情報システムなどを加えていきます。

必要項目：業務プロセス単体

1. 業務プロセスの名称
2. 業務の入力と出力
3. 業務の制約条件
4. 業務の開始条件（開始するきっかけ）
5. 業務の開始タイミング
6. 業務処理そのもの（プロセス）
7. 関連する帳票・情報システム（ドキュメント、データ）
8. 処理時間

業務プロセス単体ではこの8つが必要項目となります。この業務プロセスをつなぎ合わせて業務フローが完成します。さらに下記の項目や情報を加えていきます。

必要項目：業務フロー

9. 伝達手段
10. 業務区分
11. 並列処理の記述
12. 例外処理の記述
13. 粒度の統一
14. ルールの記述
15. “⁠タテ⁠”情報の記述（決裁・承認などが含まれる場合）

最初から細かく、詳しく業務をモデリングすることはできないので、まずは必要最低限の記述から開始し敷居を下げます。次に少しずつ情報を加えて詳細なモデルに作り上げていくことが大事です。

このようなステップと同時に、場を共有することで問題意識の共有・当事者意識の醸成も高まり、精度の高いモデリングを実現できます。

問題発見と問題整理のコツ

業務モデリングができたら、問題と突き合わせを行います。問題発見のポイントは次のとおりです。

問題発見の5つのポイント

1. 目的：何のために
2. 視点：部門や立場で問題の見え方が変わる
3. 視野：どこからどこまでを対象とするのか
4. 時間：いつの時点（現在、過去、未来）の問題なのか
5. 場所：どこで起きているのか

特に「視点」「⁠視野」「⁠場所」は、業務フローを見ながら検討を行うほうが考えやすいものです。

出てきた問題は「戦略・収益・プロセス・人と組織・仕組み・CS・ブランド・品質」の8つのカテゴリで分類します。こうすることで、問題を整理しやすくなります。

問題整理の8つのカテゴリ

1. 戦略：経営理念、経営戦略、経営計画など
2. 収益：売上、コスト、利益
3. プロセス：業務プロセス
4. 人と組織：モチベーション、コミュニケーション、組織構造、風土・体質など
5. 仕組み：社内制度、規程、情報システムなど
6. CS：顧客満足
7. ブランド：企業・商品ブランド、知的財産、無形資産など
8. 品質：経営品質、業務品質

問題のカテゴリ分けでKJ法や特性要因図（フィッシュボーン図）などを用いた経験のある方も多いでしょうが、元々のカテゴリが明確に定まっていないと、分類に困って「その他」カテゴリが増えがちです。やってみるとわかりますが、この8つのカテゴリを使うと、ほとんどの問題がどこかに入ります。

システム解決との切り分け

問題整理の8つのカテゴリは、ビジネス上の課題をシステム屋の皆さんが見極める際に、非常に有効です。システムに必要な機能要件を切り分けることも重要ですが、その前に、このカテゴリに当てはめると、システムで解決できる課題か否かを判断しやすくなります。たとえば、「⁠システムが戦略から影響を受ける項目⁠」⁠ 「⁠システムが人と組織に与える影響、モチベーション⁠」⁠ 「⁠システムがCSや品質を高める要素」などを検討しやすくなります。

こうすることで、システムで解決できる課題と解決できない課題の切り分けを行うことができます。

おわりに

ビジネスの背景がわかり、エンドユーザの環境構築もでき、システム構築や導入が目的ではなく、システムをあくまでもツールとして考え、経営と現場の両方の目線で見ることができる、そんなビジネスがわかるシステム屋が今まさに求められています。BA（ビジネスアナリスト）やBABOKにもその流れを垣間見ることができます。

しかし、「⁠餅は餅屋」のように、システム屋が経営課題やビジネス要求分析を格好良く行う必要はありません。システム屋が専門性を高める分野は「IT領域」でいいのです。ただ、そこに少しだけ「経営と現場の視点」を加え、現状調査や業務分析のやり方を、現場のビジネス主導でかつ参画型に変えていくと、システムで解決できる課題、できない課題がより明確になります。

システムで解決できない課題を知った上で、システム開発や導入を行うほうが、精度の高いシステムができあがりますし、エンドユーザが当事者として関わっていることで、システムカットオーバー後の協力体制も得られます。扱うものはシステムという“⁠ハード⁠”でも、システムを使うのは人です。使う人を動かすものは“⁠ハート⁠”であることを忘れてはなりません。