PR

現実解に固執せず自由に発想し独創性の高い解決策を生み出す(第9回)

要求定義を正しく実施するには、業務上の問題を感知するだけでなく、その解決策を生み出せなければならない。今回は、解決策の創出に不可欠である「発想力」を解説する。

前回までで、要求仕様を作成する前提となっている問題についてそれを分析する手法について解説した。これにより、問題を明確にする手法や考え方のヒントが得られた。しかし、システム開発における要求定義ではさらに、分析によって明らかになった問題を解決に導く「解決策」が必要になる。この解決策は、有効かつ実現可能でなければならない。そうした解決策を求めるために欠くことができない能力の1つが「発想力」である。

今回は、発想力の原点となる創造的思考について考察したうえで、問題解決策の導出に至るまでのプロセスについて述べる。

発想力とは何か

日々の仕事の中で「発想力が欠けている」と感じたり、上司や先輩から「発想力が足りない」と叱責されたりした経験をお持ちではないだろうか。日常生活でも仕事でも、この「発想力」という言葉は意外によく使われる。しかし、この発想力という言葉の意味は人によってまちまちだ。「思いつく力」という意味で使う人もいれば、「想像力」に近い言葉として認識する人もいる。

そこでまずは、要求定義における「発想力」とは何を指すかを最初に共有しておきたい。「発想する」とはどんな意味を持つのだろうか。小学館の大辞泉を引くと、まず「物事を考え出すこと。新しい考えや思いつきを得ること。また、その方法や、内容」とある。さらに、「あることを思いつくこと。また、その思いついた考え。思いつき。考えを展開させたり、まとめたりして形をとらせること」という意味もあるという。

このように、発想力という言葉は一般的に「物事を考え出す力、新しい考えや思いつきを得る力」を意味する。これに基づき本コラムでは、要求仕様を作成する際に必要な発想力を、「問題の解決策を考え出す・思いつく力」と定義することにする。

問題を多角的にとらえる

発想力を発揮するには、どのような能力が必要であり、どのような態度で臨むべきだろうか。まずは発想力を発揮するための能力について考えてみよう。経験や感情に縛られずに解決策を発想するには、「問題そのもののとらえ方を再思考する能力」「発想するアイデアの質を高める能力」「発想するアイデアの量を増やす能力」という3種類の能力が必要である(図1)。1つずつ見ていこう。

図1 発想力を発揮するために必要な3つの能力

まず、問題のとらえ方を再思考する能力である。ほとんどのみなさんは過去に、会社の上司や先輩から「システムを使うユーザーの身になって考えろ」や「協力会社の立場になって考えろ」などとアドバイスされたことがあるだろう。実はその上司や先輩は、まさにこの能力の重要性を指摘していたのである。

問題を解決する際に、固定観念で問題を鵜呑みにしてしまうと、根本的な解決策を見逃してしまいがちだ。問題そのものを複数の視点でとらえる習慣をつけることで、こうした失敗を防げる。問題を多角的に眺めることにはこのほか、様々な意見に含まれる誤りや欠陥などに気づいて指摘できるメリットもある。

問題のとらえ方を再思考する能力は、さらに2種類に分けられる。「問題を再定義する力」と「問題を敏感に察知する力」である。問題を再定義する力とは、問題を異なる角度からとらえ直す能力のこと。問題を敏感に察知する力とは、ある考えに含まれる誤りや欠陥などに気づき、指摘することができる能力のことである。

創造的思考を巡らす

発想力を発揮するために必要な2つめの能力は、「発想するアイデアそのものの質を高める能力」である。独創的なアイデアを生み出すには、確立された方法や既存の考えにとらわれない柔軟な思考が不可欠である。システム担当者の場合は特に、情報技術のトレンドに固執して最善の解を見失うことが多いので気をつけたい。

ただし、柔軟で独創的な思考を巡らせるだけではアイデアの質は上がらない。せっかく生み出したアイデアを単なる思い付きに終わらせないようにするため、その考えを丁寧に発展させたり細部を注意深く詰めたりする思考も重要である。

3つめは、「発想するアイデアの量を増やす能力」である。これは、次から次へとなめらかにアイデアを出す能力をイメージしてもらいたい。「自分が考えなくても、誰かがよいアイデアを出してくれるだろう」「見当違いのアイデアを出したら恥ずかしいから何も言わないでおこう」といった消極的な思考は、アイデアを生み出すうえで大きな障害となる。

解決策をチームで考える際に、ほかのメンバーの手前を気にして格好よくスマートで論理的な解決策を求めすぎるのもよくない。アイデアがスムーズに浮かばなくなるからだ。周囲の目を気にせず多くの解決策を考えようとする積極性が、新たなアイデアを生み出す源泉となる。

これら3つの能力を高めることで、今までの経験や感情に縛られず、自由な発想に基づく解決策を考え出すことができる。

厳密性より独創性を重視する

次に、発想力を発揮するための態度について述べる。米国の心理学者で人間の知能や創造性に関する研究を残したジョイ・ギルフォードは、発想力を呼び起こす態度として以下の6つを挙げている(図2)。

図2 発想力を喚起する6つの態度
  • あいまいさに対して寛容である:
    現実的なアイデアではなく、自由な発想を歓迎する態度
  • 冒険を好む:
    安全思考ではなく、自発的でチャレンジングな態度
  • 自信がある:
    アイデアやそれを考えている自分自身に自信を持つ態度
  • 独創性を重視する:
    アイデアの個性=独創性を重んじる態度
  • 変化を好む:
    現状に甘んじることなく変化を楽しむ態度
  • 達成心が強い:
    問題解決に対する熱意が溢れる態度

上記の態度が欠けている場合を考えてみよう。例えば、システム開発では性能の観点を考慮することが重要であるが、正確な性能は要求定義段階では定義できないことがある。それにもかかわらず、非常に厳密な現実的解決策を求められたとしたらどうだろう。システム開発の提案書は白紙のままでしか出せなくなってしまうのではないだろうか。

このような例を考えれば、現実解に気を取られていると発想力が発揮されなくなることを容易に理解できるだろう。

発想力を妨げる5つの要因

発想力の妨げになる要因もある。第1は「機能的固着」だ(前ページの図3)。これは、過去の成功体験に固執するあまり新しいアイデアを考えない傾向のこと。「とらわれ」とも言う。第2は、会議や打ち合わせにおいて場の雰囲気に流されてしまう「同調傾向」である。

図3 新たな発想を妨げる5つの要因

発想力を妨げる第3の要因は、権力のある人の指示につい従ってしまったり、他者を従わせたいあまり高圧的な態度で決定を迫ったりする「権威主義的雰囲気」でなる。このほか、ほかの仕事に追われることによる「ゆとりのなさ」、上司や先輩といった周囲の人間が発想する前に解決策をあらかじめ与えてしまう「与えすぎ」も発想力を阻害する大きな要因となる。

発想力を発揮するには、これら5つの要因を思考から排除することを常に意識する必要がある。これにより初めて、真の問題解決策を見つけられるのだ。

問題解決への一般的プロセス

発想力を発揮するための能力や態度について説明した。それでは、そうした発想力を生かして問題を解決に導くまでに、私たちはどのようなプロセスをどう進めたらよいのだろうか。英国の政治・社会学者であるグラハム・ワラスによると、人は4つのプロセスを踏んで問題解決に至るという。これを、「ワラスの4段階説」と呼ぶ。

第1段階は、創造しようという意欲を持ち、必要な情報を集めたり技術を備えたりして問題解決に熱中する「準備期」である(図4)。問題のほとんどは、この準備期に解決策が導き出されることが多い。準備期で解決できなかった問題は、第2段階の「あたため期」に入る。この段階において人はいったん問題から離れ、問題とは一見無関係なことをしながら、考えが熟して自然に出てくるのを待つ。

図4 要求定義における問題解決は時間が限られているため、簡略化したプロセスを素早く回す訓

すると突然、創造的な問題解決法がひらめく。しかも、その考えは強い確信を伴う。これが第3段階の「ひらめき期」である。非常に難解な問題については、このひらめき期で解決策が生み出されるケースが多い。そして最後に、ひらめいたアイデアを吟味し、それが正しいことを検証する段階が「検証期」である。

要求定義における問題解決プロセス

要求仕様の作成段階において問題解決策を求める場合は、上で述べた一般的なプロセスを変更して実施する必要がある。なぜなら、システム開発の要求定義は限られた期間内で解決策を見出さなければならないからである。そこで筆者は、要求定義においては「あたため期」「ひらめき期」を除いた2つのプロセスで早く解決策を発想することを提唱する。

具体的には、現実にとらわれず自由にアイデアを発想する「発想工程」と、考え出されたアイデアの実現性やコストを評価する「収束・検証工程」を繰り返し実施することである。ワラスの4段階におけるあたため期とひらめき期が省かれているため、早い解決策を決定できる。

ただし、プロセスを簡略化することには、その過程で出てくるアイデアが乏しくなるというリスクが伴う。この点については、アイデアを出す要員がこのリスクを踏まえ、日ごろから自由な発想をする訓練や他社の解決事例を調べておくといった地道な努力が必要になるだろう。

今回は、発想力の土台となる能力や態度について述べた。これらを踏まえて次回は、問題の原因を追究して解決策を考える際に有効な発想技法を取り上げる。具体的には、「ブレーンストーミング法」「KJ法」「NM法」「マインドマップ」という4つの発想技法を紹介する。

加えて、これら4つの技法を駆使することによって得られた解決策を評価する方法についても詳しく説明する予定である。

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

助詞を正しく使いこなそう

私たちは普段、日本語を話したり書いたりするとき文法をあまり意識しません。実は、日本語の文法は意外に定まっていないのです。例えば、「丘へ登る」「丘に登る」「丘を登る」「丘まで登る」。あなたは、これら4つの文の意味の違いを説明できますか?

これまで、この問題に正確に答えられたSEは1人もいませんでした。無理もないでしょう。だれも文法を教えていないのですから。「日本語ではこのように言えば/書けば、このように伝わる」ということを体系立てて教わる機会がないのです。しかし、だからと言って日本語が持つこうしたあいまいさを野放しにはしておけません。特に、ITの世界ではほんのわずかな言葉の行き違いが大きな問題を起こす場合があります。

考えるきっかけはあります。例えば、「東京に行く」と「東京へ行く」とはどちらも使えますが、微妙に意味が違います。その違いを明確にするには、文末の述部を違うものに代えてみることです。「東京に居る」とは言えても「東京へ居る」とは言いません。このことから、助詞の「に」は場所を示し、「へ」は方向を示していることが分かります。つまり、日本語における助詞は述部の振る舞いやありようを説明する働きをします。これまでの日本語文法は英語の文法にならって「主語に助詞がつながる」と教えますが、これはそもそも誤りです。

開発中の誤解をなくしてシステムの品質向上を目指すには今後、ITの世界に共通する日本語文法を我々の手で作る必要があるのかもしれません。

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

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

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

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

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