考える技法——解決策を議論する前に、まず問題を見よう

• ビジネスアナリシスは、「ニーズ」を考える仕事

久しぶりに、「わたしのプロフィル」 を変更した。前回の更新から、気がつくと数年経っていた。もともと、「マネジメントのテクノロジーを考える」という、一種のアーカイブサイトをWordPressで作ろうとしたのだが、いろいろな経緯からしばらく放置していた。「わたしのプロフィル」は、その中に置いていたので、 ずっと手を入れるのを忘れていたのだ。

ちなみに、わたしの今の肩書は、「 チーフエンジニア（ビジネス・アナリスト）」と名刺に書いてある。もちろん名刺の肩書きなど、しょっちゅう変わるのだが、とりあえず職場では、ビジネスアナリシスを専門に見る立場、と言うことになっている。

ビジネスアナリシスとは、どんな仕事か。それは、「コンテキストを考慮しながら、ニーズを定義し、ステークホルダーに価値を提供するソリューションを推奨することにより、エンタープライズにチェンジを引き起こすことを可能にする専門活動である」と、BABOK (A Guide to the Business Analysis Body of Knowledge) Ver. 3は定義している。

（・・ずいぶん、カタカナが多い説明文だ。「エンタープライズ」とか「チェンジ」とかは、「企業」や「変化」ではだめなのか？　でも、この方がかっこいいと、訳した人たちは思ったのだろう）

ビジネスアナリシスとは、通常、IT分野の人たちが、いわゆる「上流工程」で行う仕事に分類される。ただし、わたしの勤務先はエンジニアリング会社なので、提供するソリューションは、工場のハードなども含む。もちろん、ソフトだけの場合もあり得る。顧客のニーズに応じて、より良いソリューションが決まる。そういうことを考えるのが、わたしの仕事だ。

でも、『ニーズ』とは何か。クライアントのニーズを引き出して定義するとは、どんな仕事なのか。 顧客が「あれが欲しい」「これがしたい」と口にしたことが、ニーズなのか。

こういう仕事を続けていくうちに、最近ずっと悩みの種になっている問題に突き当たった。人はなぜ、わたしと同じように考えないのか。いや、むしろこう言い直そう。わたしはなぜ、人と同じように考えられないのか？

• MES『標準11機能』の謎

たとえば、その1つの例が、MESの『標準11機能』である。ご存じの読者の方も多いと思うが、MESとは製造実行システム（Manufacturing execution system）の略で、工場の製造オペレーションをマネージする、スタッフ層の人たちの業務を、支える仕組みである。 90年代頃から登場し、一部の先進的業界では早くから導入されたが、日本ではようやく最近になって、広く注目されるようになった。

昔は各社がMESを手作りしていたが、 欧米を中心にパッケージソフト化が進み、現在では複数のソリューションを比較検討して導入することが普通になってきた。そこで導入を考えるユーザ企業は、RFP（Request for Proposal）を作成して、MESパッケージベンダーに配り、提案を依頼する事になる。

問題は、そのRFPの中身なのだ。RFPの中核部分は、ユーザがしたいこと、「ニーズ」が書かれている。そのシステムを使って、どのような業務を実現したいのか、現在の業務をどのように変えたいのか。システムにどのような機能を期待するのか。こうしたニーズが明確でないと、RFPを受け取ったベンダー側は、何を提案したらいいかわからなくなる。

ところがMESのRFPの中核部分に、『MESの標準11機能』のリストがついてくるケースを、しばしば見かけるようになったと、大手ベンダーの人たちは口々に語る。標準11機能とは、米国のMESA Internationalという団体が90年代に策定した、リストに基づいている。念のため具体的に書くと、こんな感じだ：

• 生産資源の配分と監視 Resource Allocation & Status
• 作業のスケジューリング Operations/Detailed Scheduling
• 差立て・製造指示 Dispatching Production Units
• 仕様・文書管理 Document Control
• データ収集 Data Collection Acquisition
• 作業者管理 Labor Management
• 製品品質管理 Quality Management
• プロセス管理（工程品質管理） Process Management
• 設備の保守・保全管理 Maintenance Management
• 製品の追跡と製品体系の管理 Product Tracking & Genealogy
• 実績分析 Performance Analysis

昔、最初に見たときもそうだったが、あらためて今読み直しても、わたしにはこのリストがさっぱり理解できない。個別の項目は一応、分かる。だが全体として、なぜ機能がこの体系なのか、どういう切り口なのかが、見えないのだ。特に、日本の製造現場での業務をイメージした場合、どこがどう対応するのかピンとこない。

だから、このリストをRFPでもらって、「貴社のMES製品の機能に○×をつけろ」と言われたベンダーの人たちが絶句するのも、無理ないと思う。ユーザ側がやりたいこと、ニーズが理解できないのだ。RFPを出すユーザ企業は、なぜ、このリストを使うのか、よく分からない。多分、ネットでMESを調べるとこの11機能が出てくるので、海外の標準ならば、と使うのかもしれない。

• わからないことは分からないと言おう

こういう状況だったので、わたしが幹事を務める「次世代スマート工場」の研究会では、有志を募って、MES/MOMに関する『MES/MOM導入のためのRFP作成用標準テンプレート』を一緒に策定することにしたのである。（その使い方の詳細については、10月22日に開催する「第4回 ENAAスマート工場シンポジウム」 で無料のワークショップを開くので、興味ある方はご参加いただきたい。なお前回の記事でもこのシンポジウムを案内したが、リンク先が誤っていたので訂正させていただいた）

でも、話を元に戻そう。わたしが不思議なのは、海外製の標準リストだからといって、あまり疑わずに自分の要求資料に引用する人たちの、ものの考え方である。「知らない」というとバカにされるとでも思ったのか？　だが理解できない用語を並べるより、自分の言葉で伝える方が良いではないか。

言葉を知っているという事と、理解して使えるのとは別だ。だから、自分がピンとこない・分からない事を、ニーズとして人には要求しないし、すべきではない。だって実感として分からない事は、自分では実現できないのだから。

もちろん、わたしの理解力が低いから、よく分からないのだ、という見方もあるだろう。わたしが物事を納得し理解するのに、人一倍、時間がかかる。別にそれは否定しない。だがわたしは、世の中の人の頭の良さ、頭の回転の速さが、かえって奇妙に感じられることが多い。

もう一つ、例を挙げる。7月に、同じ次世代スマート工場の研究会で、人材育成のためのセミナーをやった。そのプログラムでは、研究会仲間である渡辺薫さんが演習を担当された。その一つ目の問題は、工場における納期問題がテーマだった。、

当該工場での生産は、半数とはいわないが、1/3以上は納期に遅れていると思われる。製品（10種類）によって状況が異なるようだ。少数だが、大幅な納期遅れになるものがある・・こんな状況下で、納期問題の「正確な現状把握と目標設定に向けた『見える化』の方法を検討」せよ、という出題である。なかなか良い演習だと思う。

ところで、このテーマを出題した後、渡辺薫さんが参加者に注意を呼びかけた。「考えてほしいことは、納期問題の解決方法ではありません。原因の究明でもありません。現状把握のためには、どんな『見える化』をすべきか、検討してほしいんです」と。

• 解決策を議論する前に、まず問題を見よう

この注意は、とても印象的だった。というのも、わたし自身の職場における議論でも、よくこういう傾向が見られるからだ。プロジェクトのスケジュールに遅れが出る。じゃあ、どうするか。あの手を打つべきだ、いやそれよりこの方策が良い・・

みんな、頭が良すぎるのだ。だから、現状把握も、原因分析もすっ飛ばして、解決策の議論をしたがる。だがそれでは、建物の土台も1階もすっ飛ばして、2階から建築しようとするのに似ていないか。それで本当に、有用な議論になるのか。

問題が起きたら、まず問題のあり方を注意深く、客観的に、できれば定量的に見る。事実の正確な認識から、議論をスタートする。これがわたしには、基本に思える。定性的で曖昧な問題認識から出発すると、雰囲気や思い込みや、感情に支配されやすい。そうなると自由で闊達な発想が出てこない。

議論するときには、お互いに了解できる、誤解の余地のない、客観的事実から出発するべきである。そうしないと、出発点からかみ合わないからだ。

こうしたことは、議論をする上での基本中の基本だと思うのだが、どうやらわたし達は、これを学校で習うのを忘れてしまったらしい。そもそも、日本の学校というのは、議論の仕方を習う場所ではない。学校では、正解は天から降ってくる。議論して作り上げるものではないとの論理で、動いている。

だからわたし達は、本当の意味で問題解決を、そのための議論と衆知の集め方を、学んでいない。これでは、日本社会が様々な問題状況から、上手に脱出できる訳がないではないか。頭の良い人は大勢いるのに、社会がうまく機能しないのは、じつは皆、頭が良すぎるためなのである。

「ソリューション」とは解決策であり、「ニーズ」とは期待である。《ニーズを定義し、ソリューションを推奨することで変革を可能にする活動》が、ビジネスアナリシスだと主張する人たちは、その定義の中に『事実（ファクト）に基づき』の一語を、入れておいてほしかった。

上流工程を担えるビジネス･アナリストへの、ニーズは今も高い。だが、この社会に「チェンジ」を引き起こすには、できあいの「ソリューション」に飛びつくだけではダメなのである。まずは問題事実を客観的に、多面的に理解する。その上で、一人だけの狭い視点では気づかない、すぐれた発想を得るために、衆知を集める。それが必要な手順なのだ。

わたし達が議論という営為を実りあるものにしたかったら、頭が良すぎることの弱点に、もっと気がつくべきなのである。

＜関連エントリ＞

「「頭がいい」ということは、本当にそんなに「良い」ことだろうか」 https://brevis.exblog.jp/21816699/ (2014-03-14)

「IoT時代のMESをもう一度考え直す 〜 (2) MESの機能と階層を理解する」https://brevis.exblog.jp/26007261/ (2017-08-27)