PR

第8回 「問題とは何か」を理解し、適切な発見方法を確立する

要求定義の前提になるのが、経営上や業務上の問題の発見と解決策である。ところが、その問題の定義が曖昧なことが多い。 そこで今回は「問題とは何か」を示し、適切な定義方法を説明する。

システム開発プロジェクトの現場では時々、首をかしげたくなることが起こる。一例をあげよう。8人ほどのチームを率いるリーダーに、PMが「問題点を報告して下さい」と問う。そうすると「進捗が3日ほど遅れています」という答えが返ってくる。遅れている理由を聞くと、「仕様書の精度が低く、(メンバーが)理解するのに時間がかかっています」と言う。

そこで仕様書の精度が低い理由を問うと、「分かりません」で終わる。これではリーダーとして頼りないし、PMも手の打ちようがない。

別の例もある。プログラムの開発局面で、あるPMはプロジェクト推進チームから「用紙の消耗が増加している」と報告を受けた。通常はA4用紙500枚を一週間に10包みほど消耗するのだが、それが2倍になっているという。「プリンターが不足しているので買い増して欲しい」という要望もあった。

状況を知るため、PMは開発ルームに出向いてエンジニアたちの仕事ぶりをしばらく観察した。廃棄用紙の置き場は文字通り、溢れんばかりだった。なぜそうなのかを見ていくと、プログラムのテストを行うたびに、その結果を印刷している。テスト結果をみながら次のデバッグをやりたいのだという。

対策は簡単だった。紙に印刷するのではなく、液晶モニタを追加して、そこにテスト結果を表示しておけば済む。このようにプロジェクトの現場では「まさか」というような事件が頻発している。

問題感知力の重要性

なぜこんな例を挙げたのかというと、問題の把握について述べたかったからである。これらはひとえに「問題関知力」に関わることだ。関知力が鈍いとコストやムダを増大させ、プロジェクト遅延を引き起こす。エンジニアたちは目の前にある仕事(=デバッグ)に没頭し、プロジェクト推進チームのスタッフも数字を集計するだけに終始する−。

こうした分かりやすい開発局面の出来事に比べて、はるかに重要なのが要求定義を中心とする超上流工程である。経営上の問題を解決するための手段としてIT化を計画し、それを具現化するための要求をまとめたものが要求仕様書である。そうである以上、経営上の問題を感知し、共有できていなければ要求仕様書など作れないはずだ。しかし実際には、この工程における問題感知が不十分なケースが目立つ。

そこで今回は、まず問題とは何かについて整理・認識した上で、問題の見つけ方・捉え方を解説する。

「問題」を種類と特性で分類する

問題とは、すなわち「理想と現実との差異」である。この差異を認識して初めて問題を可視化できる。理想とは「あるべき姿」のことである。従って「あるべき姿」に無関心であれば、問題を感じることはない。

図1 問題とは、「現状とあるべき姿」の差異である

図1 問題とは、「現状とあるべき姿」の差異である

 

問題を一言で表現するとこのように定義されるが、その種類や特性は一様ではない。まず問題の種類は一般に2つある。「少知識問題」と「多知識問題」だ。あまり耳慣れない用語かも知れないが、少知識問題とは、解決するために広範な前提知識を必要とせず、一般知識の範囲で解決にあたることができる問題を指す。ヒューマンエラーに関わる事柄や企業間取引の一般的な方法などに関わる問題がその例である。小知識問題に対する解決策は、他の問題の解決に応用できる場合が多いため、「領域汎用型の問題」ともいえる。

多知識問題は逆に、解決するために多様な前提知識を必要とし、また調査による情報収集を必要とするような問題である。企業固有の生産方式や業務プロセスなどに関係する問題が、それに当たる。その解決策は、当該問題にのみ有効な場合が多いため、「領域特有型の問題」といえる。

一方、特性という面から問題を捉えると、「定義の良い」問題と「定義の悪い」問題に分けられる。

定義の良い問題とは、「問題点」、「望まれる姿」、「問題解決のために許される行為や禁止事項等のルール」という3点が明確な問題のこと。「問題の問題点が明確とは、どういうことか」と思われるかも知れないが、要するに誰の目にも明らかな問題である。この3点が明らかな問題に対しては、解決に向けた具体的な行動をとれるはずだ。

これに対して定義の悪い問題は、上記3点のいずれか一つ以上が不明確な問題を指す。例えば「望まれる姿」が明確でないために、すぐには解決に向けた具体的な行動をとれない。

図2 問題には定義の善し悪しという特性がある
図2 問題には定義の善し悪しという特性がある

活動局面に応じた問題

問題を、種類と特性で説明したが、企業活動、あるいは社会活動の局面から分類することもできる。以下に、それを列挙しよう。

(1)あるべき姿に満たない

通常の企業活動や社会活動を行う中で、あるべき姿の再認識、あるいは現状の再認識によって明確化される、比較的、意識しやすい問題である。それまでは問題でなかったことが、環境の変化によって問題になることも多い。この種の問題は、すぐに解決する必要が高いのが特色である。解決を優先するがゆえに、ミスを犯しがちであることと、発想力を十分に発揮できない状況に陥り易く、誤った判断をしがちになることに注意が必要である。

(2)日常業務に潜在している

問題として認識されていないが、日常的業務やルーチンワークに潜むものである。「無駄」なものはないか、「無理」をしていないか、「ムラ」は生じていないかといった視点で業務を点検すると、多くの場合、かなりの問題を発見できる。「無駄」・「無理」・「ムラ」に着目した問題検知手法を「3ム主義」と言い、一般的に広く知られている業務改善手法である。「3ム主義」については後で触れる。

(3)目標が違っている

現状では問題として認識されていないが、望まれる姿をより高いレベルに設定し、望まれる姿と現実のギャップを意識的に拡げることで認識される。現状より高いレベルを目標とした場合に見られる問題である。

問題点と到達点の発見

問題を解決しようとする場合には、現状を把握した上で望まれる姿を的確に描き、その間にある差異を正しく認識することが求められる。現状を把握しないままだったり、望まれる姿を正しく描けない中で解決に取り組んだりした場合、問題を拡げてしまったり、新たな問題を生み出してしまうことが起こり得るからである。本来は問題ではないものを、問題と認識してしまうこともある。

「それは当然のことでは?」と思う読者も少なくないかも知れないが、筆者がトラブルの起きたプロジェクトを調べると、原因が上記のようなことである場合が多い。“問題は何なのか“を正確に把握する前に、解決策を出してしまうことは、超上流工程において意外に多いのだ。

例えば、あるシステムの開発途中に、操作画面を業務担当者に評価してもらうと、「受注データをまとめて入力できるようになっていないと使えない」というクレームがあったとする。あるいは複数の業務システムで顧客企業名が違っているため、集計処理がスムーズにできないという問題があったとする。

前者の問題に対しては一括入力の画面を追加開発する、後者には顧客名の変換テーブルを用意するといった解決策を単純に思いつくが、本当にそれは正しいのか。安直にそう考えるのではなく、本当の原因はどこにあり、解決すべき真の問題はなんなのかを考えるべきである。問題を正しく認識できなければ、望まれる姿など、得られるはずがない。

問題発見のアプローチと留意点

次に問題を正しく認識しようとする際に有効な考え方と、留意すべき事項を紹介する。

(1)3ム主義の活用

前述の通り、「3ム」とは無駄、無理、ムラのことであり、オーソドックスな問題感知の手法である。

無駄な作業を改善すべきであることは論を待たないが、その際に着目したいのが小さな無駄を見落とさないことである。大きな無駄は通常、それほど存在しないし、大きな無駄に着目することで小さな無駄が見落とされがちになるからだ。

例えば「1日5分の作業改善」は、小さな無駄をなくすことだが、月20日あるとして、一人当たり1ヵ月で100分、1年で20時間の改善効果がある。20時間といえば2.5人日程度の改善になる。全社的に捉えた場合、その改善効果は大きなものになるだろう。このように、小さな改善であっても数値として的確に捉えることが重要である。

小さな無駄を見つける場合は、固定概念を捨てて自分の周りを見渡すことが重要である。自分が置かれている環境に慣れてしまうと、それが当たり前に思え、小さな無駄を見つけられない。人間の認知行動の特性として、知識や既成概念が無意識に新たな創造の妨げをするからである。この特性を認識した上で、業務経験の浅い者や自分とは立場の違う者の意見を尊重すると、何気なく見落としていた小さな無駄に気付く。

作業に無理がないか、あるいはムラがないかを感知する際にも、固定概念を捨てて自分の周りを見渡す。「無駄」の洗い出しの際に合わせて「無理」と「ムラ」の観点で点検するのが良いだろう。

(2)利害関係者の明確化

問題を認識し、解決策を検討する際に利害関係者を明確化することは、当然である。しかし十分に留意する必要があるため、ここで少し触れておく。

問題の感じ方は組織や役割、経験、性格によって人それぞれである。関係者が10人いれば、感じ方の差の大きい小さいはあるものの、10通りの感じ方があると考えるべきである。利害関係者の洗い出しが不十分なまま考えた解決策は、ある者にとっては好都合だが、別の者には新たな問題になる恐れがある。これでは解決策とは言えない。

問題の整理と解決策を検討する中で、新たな利害関係者が現れるケースもある。問題が問題を生むという事態を避けるには、まず利害関係者を洗い出し、関係者毎に問題に対する認識と解決策を整理する必要がある。

(3)問題を置き換える

利害関係者の明確化とも関係するが、他の人(部署)の問題を、自分(自部署)の問題に置き換えて考えてみることも重要である。個人や一部署に留まる問題は少なく、形を変えて他の部署に波及していることが多いからだ。問題を認識した場合には、他者の問題は自分の問題に置き換え、自分の問題は他者の問題に置き換える。それによって問題の本質を浮かび上がらせることができるはずだ。

(4)客観的に捉える

問題を正確に把握するためには、関係するデータの収集と問題の可視化、および事実と推測の明確化が重要なポイントとなる。つまり客観的に問題の実態をとらえることだ。最後にこれらの点をまとめておこう。

  • 問題の可視化

    問題の解決にあたっては、定義の悪い問題を定義の良い問題に置き換える必要がある。すなわち、問題を正しく見える形に可視化することが肝要である。

  • データの収集

    「納期が遅れる」、「失注が増えている」。これらの事実は事実として、具体的に納期が何日遅れているのか、案件数に対する失注の割合はどの程度か、といったデータを極力多く、具体的な数値で把握することが重要である。

  • 事実と推測の明確化

    問題の整理・検討にあたっては、推測を織り交ぜがちである。推測があたかも事実であるかのように思い込むケースもある。問題解決に際して推測が有効に働く場合もあるが、推測と事実は異なる両者を混同しないよう明確に区分けしておくことが重要である。

図3 問題を正しく認識するためのアプローチ
図3 問題を正しく認識するためのアプローチ

ドクター福田の「文章力アップ」処方箋

体系的な理解が語彙力の向上を促す

今月号では、「問題」という2字熟語を多く使いました。数えると99回です。上手な文章を書くためには、同じ言葉を繰り返して使わないようにするのが原則です。それを逸脱しているわけですが、今回はテーマが「問題」なのでお許し下さい。

ところで前回、語彙数を豊かにすることが文章力を高めるコツだと書きました。その方法の一つに、「似たような言葉について、意味の違いを考える」というものがあります。そこで「問題」に近い意味を持つ言葉を考えてみましょう。読者の皆さんは、どんな言葉を思いつくでしょうか。答えを挙げると、設題、課題、本題、論題、難題などがあります。

もともと「題」という字は、人間の「額」(ひたい=頭の正面に突き出た額)を表したものです。ですから彫題(ちょうだい)は、ひたいに入れ墨をすること。そこから転じて、書物や絵画の上部の空欄に入れる名(タイトル)を意味するようになります。同様に「問うもの」が「問題」であり、「課するもの」が課題、「設けるもの」が設題となります。「では題と額は同じなのか」という疑問が生じますが、題は髪を整えてまっすぐに広く見えるようにした表面、額は頭蓋骨に守られた叩けばこつんと弾く部分という違いがあります。

漢字には一定の「形」と「音」と「義」という、3つの要素が備わっています。「形」とは漢字を構成している点画であり、「音」は読み方、「義」とは意味です。これは漢字が表意文字であるゆえんです。アルファベットのような表音文字は「音」と「義」のみです。このように体系的に理解するようにすれば効率よく語彙を増やせます。

福田 修ふくだ・おさむ

CSK、日本インフォメーション・エンジニアリングを経て、1997年にテクノロジー・オブ・アジアを設立、代表取締役に就任。適切な情報技術の動向把握に長け、 2000年問題の効果的解決、インドのSI会社との提携、Webアプリケーションへの取り組み、オブジェクト指向設計/開発の導入などに早期から対応し、後発システムベンダーへの指導的立場にもある。関連論文多数あり。
http://www.toasia.co.jp/

 

IT Leaders 毎月無料でお届けいたします

本誌は、読者登録いただくことにより、毎月無料でみなさまのお手元まで直接お届けいたします(書店などでは販売していません)。

企業の情報システムを担当する方々や事業部門のIT担当の方々、およびIT関連プロフェッショナルの方々を対象に、実践的に役立つ情報を掲載、幅広く業務にご活用いただけます。

IT Leaders新規購読お申し込みはこちらから
Ads by Google