第2回 「バグをなくす」には、「バグのない世界」を文章で示せ
前田卓雄
2008/10/15
| ソフトウェアを創造するエンジニア。しかし、その仕事は本当に「創造的」だろうか。仕事を創造的なものに変え、価値を生むための発想法を紹介する。 |
いまの仕事を「創造的なもの」に変える、と切り出されても、突拍子もない話だと思うに違いない。ブレーンストーミングの創始者であるアレックス・F・オズボーン氏は、その著書『創造力を生かす』（注1）で、「創造力を持たぬものはない、そして多くの人は自分の創造力を埋もれたままにしている」と指摘している。だから、もし自分に創造力がないと思っていても、創造力を発揮するように変えることは可能なのだ。
第1回『プログラムは「どう書くか」の前に「何を書くか」』を読んで、自分自身に成長の可能性が眠っているかもしれない、と思った方は多いだろう。実際に成長する過程は、自分なりのシナリオを描き、目標達成を目指して実践するプロセスである。このプロセスを面白く創造的なものにするに限る。面白くて創造的であれば、成長は加速するだろう。創造力と成長意欲は、自分の中に眠っている自分だけの貴重な財産だ。
| （注1）『創造力を生かす』Alex F. Osborn著、豊田晃訳、創元社発行（旧版1969年10月、新装版2008年1月） |
■問題を集める
とはいえ、何から始めてよいやらと考えてしまう。最初のステップは「問題を集める」ことである。簡単なプロセスである。
しかし、われわれは誰しも、問題に遭遇すると気が重くなり、厄介で面倒なことが降りかかったと感じる。ところが、この問題がわれわれに新たな可能性を与えている。いわば「宝の山」なのだ（図1）。
 |
図1 問題は「宝の山」 |
これは、誰もが知っている過去の社会問題とその克服結果を見れば明らかだ。例えば、ヘドロや有害物質で汚れた河川や海とその再生、喘息（ぜんそく）を引き起こした「大気汚染」という公害問題と環境再生、石油危機というエネルギー問題と省エネの実現、大量のごみという環境問題とリサイクルシステムの確立、などである。もちろん、その当時問題発生を予見できていたのであれば、発生を予防しなければならなかった。予見や予防の欠如もまた、それ自身、大きな問題であったといえよう。
このように、われわれは問題と問題解決の歴史を共有している。被害者には途方もない苦痛であった。しかし、われわれはこれらの問題に立ち向かった人々の尽力のおかげで、価値回復や価値創生につながったことを知っている。
「問題」とは、われわれをスタートさせる何かである。読者はどんな問題を抱えているだろうか。公害被害者が経験したような途方もなく大きな問題、あるいはもっと小さな問題。仕事上の問題、あるいはプライベートな問題。そして、問題の山に打ちひしがれているだろうか。あるいは、解決に向け問題に立ち向かっているだろうか。いずれにせよ「問題」が日常のわれわれの最大の関心事であり、自分自身の歴史を形づくる素材であり、良くも悪くも生きていることを体感させてくれる貴重なものだ。だから、問題への対処法を学び、願わくは問題から新たな何かを生み出すことを学んでほしい。
われわれソフトウェア／IT関連の技術者の周りにも、嫌というほど問題がある。どんな問題があるのだろうか。いくつか挙げてみよう。
- いつまでもだらだらと続く開発やテスト
- いつまでもなくならないバグ
- 出荷時期の厳守
- あいまいな仕様書や設計書
- よく発生する仕様変更や仕様追加
- チーム内の意思疎通不足
- 新しい技術への追随
読者の問題もどんどん付け加えていただきたい。そして、思い出す限りの問題をすっかり紙に書き込んでしまったら、しばし自分をとらえて離さなかった問題を俯瞰（ふかん）しよう。「なーんだ。こんなことが自分を苦しめ、悩ませていたのか」と、困惑してきた自分をしばし思い返し、ゆったりと自分をいたわっていただきたい。
こうしてリストアップできる身近な問題の多くは、品質・納期あるいは出荷時期・コスト問題に始まり、仕事の確保、生産性、市場あるいは顧客価値の創造、新しい製品やシステムの企画、他社との競争など、さまざまなカテゴリに分類することができるだろう。
■問題をとらえ直す
問題が宝の山というと、「そんなばかな」という読者も多いことだろう。しかし、ある人には問題であっても、ほかの人には何ら問題でないことも多い。例えば、病人は病気という問題を抱えているが、医者は問題の存在、すなわち病気を抱えた患者が存在することで成り立っている。
つまり、問題を単に問題というだけでは何かが足りない。問題をとらえ直すことが必要なのだ。もし自分が問題だというのであれば、病人の立場である。病人には、症状にもよるが、医者（自分以外の誰か）が必要である。自分で問題を解決しようとすれば、自分が病人であった場合、同時に医者の視点も必要であろう。
つまり、問題に立ち向かう立場である。この視点を持つためには、自分の抱える問題を（自分だけにでも）明らかにすることが欠かせない。そこで、われわれは問題を列挙し整理し俯瞰するのである。そして、問題解決や自分の成長と結び付けるのである。
図2は、第1回の図1に、黄色い部分を追加したものである。もし問題を集め、とらえ直すことができれば、（A）や（C）を加速することができるだろう。問題をとらえ直すには、問題の原因を掘り下げたり、分析したりすることが必要になる。
 |
図2 問題に立ち向かう |
例えば、ソフトウェアにバグが発生すれば、ただバグを直すだけでは創造につながらない。バグの発生原因を追求するのだ。
なぜバグが発生するのだろう。原因は、誤って実装してしまったからだ。では、なぜ誤ったのか。仕様の記載があいまいであったため、要求側の意図がはっきり理解できずにプログラムを作成してしまったから。では、なぜ要求側の意図が伝わらなかったのか。当初の要求仕様はあいまいであったが、その後に仕様決定されたものが開発者に伝わっていなかったから。なぜ伝わっていないことが分からなかったのか。要求変更のような意思疎通を確実に行うことを保証する仕組みがなかったから。このような具合である。
原因の掘り下げを通じて、問題への対応や問題発生の防止策にさまざまなアイデアを出すことができる。
| 「理想的に解決された状態」をイメージする |  |
 |
＠IT自分戦略研究所は2014年2月、＠ITのフォーラムになりました。
現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。
これからも、＠IT自分戦略研究所をよろしくお願いいたします。
