ソフトウェア工学とTRIZ(1) 構造化プログラミングをTRIZの観点から見直す (中川徹, 2004. 8)

TRIZ 研究ノート
『ソフトウェア工学とTRIZ』 (1) 構造化プログラミングをTRIZの観点から見直す
中川　徹 (大阪学院大学) 研究ノート, 2004年 8月 7日
[掲載: 2004. 8.26]

For going back to English pages, press buttons.

まえがき研究ノート『ソフトウェア工学とTRIZ』について (中川徹, 2004年 8月24日)

ここにまとめた (そしていまから順次まとめていく予定の) 研究ノート『ソフトウェア工学とTRIZ』は、私にとってはTRIZを知り始めた 7年前からの懸案に対する課題に、新しく本格的に取り組んでいくための第一歩になるものです。

1997年5月末に私が初めてTRIZを知ったとき、私は富士通研究所の企画調査室に勤務しており、それ以前から情報科学/ソフトウェア工学関連の研究をしておりました。TRIZを知り、それが技術分野全般に関わる大きな新しい思想と方法を提供することを知って、TRIZの研究所への導入に努力しました。その時に、沢山の人たちから聞かれたのは、「TRIZはソフトウェア分野に使えないのでないか?」ということでした。「すぐには使えない。TRIZの学習・研究が進まないと使えない。それには、まずハード分野 (すなわち、情報でなく「物」を主体とした技術の分野) でのTRIZを学習・習得し、適用経験を持つことが大事である」と答えてきました。

また、1998年4月に大阪学院大学に移り、(2000年4月に新設の) 情報学部で教えてきました。学生に、「情報科学序説」、「ソフトウェア工学」、「科学情報方法論」などを教えてきました。その中で (特に「科学情報方法論」の講義ノート (全13回) を公表していますように)、TRIZを、「考える方法」、「情報を整理する考え方」、「技術一般の学び方」、「技術一般での問題解決の方法」、「技術一般に対する情報科学的な寄与のしかた」といったとらえ方を主として教えてきました。また、私自身の中でTRIZを研究するのに情報科学からの観点を随分使ってきたと思います。それでも、いままではゼミでもソフトウェアそのものを対象にTRIZを適用することを、避けてきました。

しかしようやく、「本格的にソフトウェア分野にTRIZを適用してみる基盤ができてきた。恐れずに適用を試みて行かなければいけない。」という段階になりました。その一つのきっかけは、卒業研究の 4年生が「やはりTRIZの適用はソフトウェア分野でやりたい」と言いだしたことです。7月の卒業研究ゼミで実際に2回議論をしたのが、この研究ノート(1) を書くベースになっています。8月初旬に 4日間かけて書き上げました。10月の後期ゼミからこの続きに取り組みます。[やはり、私には切羽詰まらないと取り組まない悪い癖があります。切羽詰まってやれば、何かは確実に進むのですが。]

以上に述べたような個人的な経過とは独立に、この研究ノートの持つねらいとアプローチをつぎにまとめておきます。

この研究ノートには以下の 3つの大きなねらいがあります。

(1) TRIZの適用分野を、特にソフトウェア関連分野に発展させ、拡張する。

     TRIZは、「技術分野全般」を対象に、1970年代を中心にして発展してきました。そこで主たる技術分野は、機械・電気・化学・農学などの分野でした。そのため、電子工学、情報科学、遺伝子工学、などの (比較的) 新興の科学技術分野には適用事例が少なく、適用の指針が未確立であり、適用の可能性に関して疑問が出されることがあります。

    そこで、本研究ノートでは、TRIZの立場から、TRIZの知見をソフトウェア工学分野に (ソフトウェア開発の指針として) 適用することを試みます。ソフトウェア工学にTRIZを適用した事例を示し、TRIZを適用する方法を実証していくことがまず最初の大きな目的です。

(2) ソフトウェア工学にTRIZの観点を導入して、ソフトウェア工学自身をより明確にする。

     ソフトウェア工学のさまざまな考え方や発展の歴史にTRIZの観点から光を当て、ソフトウェア工学 (あるいはソフトウェア/ソフトウェア開発というもの) をより良く理解することを目指します。これによって、今後のソフトウェア関連の問題に対して、よりよい指針を持つことができるようにします。これは上記(1) でいう具体的な適用より以上に、ソフトウェア工学/情報科学に対してTRIZから寄与していこうとするものです。

(3) ソフトウェア工学/情報科学の知見を、TRIZの考え方にフィードバックする。

     TRIZにはハードウェア分野 (情報主体でなく、「物」を主体とした技術分野) の知識が豊富に取り込まれていますが、ソフトウェア工学あるいは情報科学からの知識はあまり導入されていません。そこで、ソフトウェア工学/情報科学の知識をTRIZに盛り込み、TRIZをさらに豊かに、強力にしようとするものです。

そこで、具体的なアプローチとして、当面はつぎのやり方をします。

(a) ソフトウェア工学における基本的な考え方やトピックスを一つ一つ取り上げて、それを中心テーマにして上記の(1)(2)(3) のねらいを検討していきます。

(b) ソフトウェア工学関連の具体的なテキストとして、つぎの教科書を取り上げます。

『プログラム工学 -- 実装, 設計, 分析, テスト』, 紫合治著, サイエンス社 (2002年10月)

この本は学部レベルの内容を極めて簡潔に記述している優れた教科書であり、ソフトウェア工学/情報科学での基本認識を知る上で適当であると考えて選びました。

(c) 読者対象としては、ソフトウェアやプログラミングについて基本的な知識を持っている (ただし、専門家レベルである必要はない)こと、TRIZについては簡単な解説を読んでいる (習熟していることは必要ない) ことを想定します。すなわち、両方ともに専門家のレベルを想定してはいません。この2分野のどちらかの分野に習熟した人に (すなわち、ソフトウェアの技術者か、TRIZに詳しい人かに) 読んでもらいたいと思っています。

(d) 上記の『プログラム工学』では、説明に際して、図式の他に、記述を明確にするためにプログラミング言語 (特にC 言語など) を併用しています。しかし、ソフトウェアの専門家でない人にも理解してもらうには、プログラミング言語での記述をできるだけ避けて (省略して)、もっと本質的なことを図式レベルで議論したいと考えています。(プログラミング言語も沢山の種類があり、その細部の記法にこだわったり、書ける/書けないの議論をしたくないと思いますので。)

以上の趣旨で、「研究ノート」という形式で記述を進め、不定期ですが逐次この『TRIZホームページ』に掲載して行きたいと考えています。ご意見をいただけますと幸いです。

[追記 (中川 2004. 8.26): このテーマについて、9月17日に三菱総研の知識創造研究会創造手法分科会で発表させていただくことになりました。詳しくは「中川の活動のページ」を参照下さい。ご討論をお願いします。]

目次:

『ソフトウェア工学とTRIZ』
  (1) 構造化プログラミングをTRIZの観点から見直す

1.   はじめに、構造化プログラミングとは (ソフトウェア工学の立場での説明)

[紫合] 1.4 プログラム工学の歴史
[紫合] 2.1 構造化プログラミング
[紫合] 2.2 構造化原理

2. 構造化プログラミングの補足 (ソフトウェア工学の中での説明と議論)

2.1 構造化プログラミングに至るまで
2.2 goto論争
2.3 構造化プログラミングの基本制御構造の意図
2.4 構造化プログラミングにおける追加制御構造の意義
2.5 プログラミング言語における「構文」の役割
2.6 構造化プログラミングが何を禁止 (制限) したのか?

3. TRIZから見た構造化プログラミング

3.1 複雑性の克服
3.2 「システム」の階層性と「入れ子構造」
3.3 「goto文はあるべきか、ないべきか?」 TRIZの矛盾の観点から
3.4 汎用性の原理と分割の原理
3.5 信頼性を高めるプログラミング
3.6 「goto論争」と運動

4. ソフトウェア工学/情報科学がTRIZにもたらすもの

4.1 ソフトウェアの「処理構造」や「アルゴリズム」の概念のTRIZへの取り込み
4.2 ソフトウェアの「段階的詳細化」の概念の「分割原理」への導入
4.3 「入れ子の原理」を「システムの階層性」を表現する原理として捉える
4.4 「分かりやすさ」の概念
4.5 「入れ子構造のねじれ現象」の問題
4.6 システムの「複雑さ」を克服する具体的な方法
4.7 「汎用性」の原理の拡張と「標準化/規格化」の重要性
4.8 「矛盾」を明確にするプロセスを再考する

5. おわりに

参考文献

本ページの先頭

1. はじめに (構造化プログラミングとは)

2. 補足説明

3. TRIZから見る

4. TRIZへのフィードバック

5. おわりに

『ソフトウェア工学とTRIZ』 (1)

構造化プログラミングをTRIZの観点から見直す

2004年 8月 7日 大阪学院大学 中川　徹

目標: まず第1回として、ソフトウェア工学の基本である「構造化プログラミング」の考え方を取り上げ、いわゆる「goto論争」を中心にして、TRIZの観点から再考する。そして、本シリーズ「ソフトウェア工学とTRIZ」のアプローチを明確にする。

1. はじめに、構造化プログラミングとは (ソフトウェア工学の立場での説明)

この研究ノートのシリーズのまず最初に取り上げるのは、「構造化プログラミング」である。それはソフトウェア工学 (あるいは、ソフトウェアの作り方の技術) の初期に提唱され、その後の発展に大きな影響を与えたものである。

まず、この「構造化プログラミング」の歴史的な位置づけを理解するために、「ソフトウェア工学」に関する歴史の概要を、紫合治著『プログラム工学』(p. 11-12) から引用する。[このような引用は、ソフトウェア工学/情報科学分野での認識を、非専門の読者に理解してもらうためである。]

--------

1.4 プログラム工学の歴史

プログラム作成技術が研究されだしたのは、作成するプログラムが徐々に大きく複雑になり、出荷前のテストでエラーがなくならなかったり、出荷後のエラーの修正で莫大な費用がかかるなどの問題が生じはじめた1960年代後半からである。

まず、Dijkstraが、当時のプログラムで多用されたgoto文がプログラムを読みにくくしているとして、goto文を使わないプログラムを提唱した。これをもとに、構造化プログラミングが提唱され、多くのプログラマに受け入れられた。

同じ頃、大規模ソフトウェア間発の問題を専門に研究する分野として「ソフトウェア工学 (Software Engineering)」が提唱され、「ソフトウェア工学国際会議」が開かれ、分析からテスト、さらに開発管理に至る研究が活発化した。

プログラミング技術としては、構造化プログラミングでの制御構造の扱いから、データの扱いが研究され、70年代の半ばには抽象データ型やオブジェクト指向の概念が発表された。1980年代に入ると、オブジェクト指向技術の実用が図られ、オブジェクト指向向きのプログラミング言語・環境として Smalltalkが出てきた。1990年代には、インターネット利用が急速に拡大し、それに沿った分散システム、WEBベースシステムなどが広く使われるようになった。

プログラム作成技術としては、デザインパターンに代表されるノウハウのパターン化が盛んに行われた。21世紀に入り、新しい開発工程モデルとしてXPが注目されだした。また、開発としては、インターネット利用分散システム環境が整備され、Javaの企業システム環境 (EJBなど) や分散要素間通信手段の標準としてのXML技術などの利用が広まりつつある。

本書で扱うプログラム工学は、このうち、70年代から90年代までに提唱され、現在も利用されている (生きている) プログラミング関連技術を中心にまとめたものである。

-------------

それでは、「構造化プログラミング」に関するソフトウェア工学の立場からの記述を、紫合治著『プログラミング工学』からここに引用する。この本は学部レベルの内容を極めて簡潔に記述している優れた教科書であり、ソフトウェア工学/情報科学での基本認識を知る上で適当であると考えて選んだものである。

[なお、引用に際して、テキストを手入力し、図も作り直した。原書には、図式 (今回の例ではフローチャート) に、プログラミング言語 (C言語など) での記述を併記しているが、ここにはプログラミングの非専門家にも分かりやすくするために、基本的に図式だけにした。また、ページレイアウトも左右見開き形式から、通常の形式にしている。引用中の中川による注記は [ ] 内に示す。]

---------

資料: 紫合治『プログラム工学』 2.1-2.2節 (16-21頁)

2.1 構造化プログラミング

プログラムは命令の列でできている。この命令はつぎの3つに分類される。

   (1) 定義・宣言: 変数や手続きの宣言など。
   (2) データ処理: 演算や代入、ファイル入出力など。
   (3) 制御命令: 分岐や繰り返し、手続き呼び出し、飛び越し命令など。

プログラムを理解するには、この命令の列を読んでいかなければならない。分かりやすい文章は、上から下へ、初めから終わりへ順に読めるものである。プログラムも、原則として上から下へ順に読めるようになっているべきであるというのが、構造化プログラミング (Structured Programming) の教えの一つである。

構造化プログラミングという考えが出た頃は、プログラム言語としてアセンブラやFortran などが多く使われており、そこではプログラムの制御命令としてgoto文が多用された。goto 文はプログラムを上から下へ順に読んでいくことを妨げ、思考の連続を中断し、プログラムの理解を妨げる原因になるので、それを使わずに、分岐や繰り返しだけでプログラムを作成すべきであるとの提言がなされた (図2.1)。これは今日ではほとんど常識になっており、むしろgoto文なんて使ったことがないプログラマが多いと思われる。

プログラムの制御構造としては、上から順に処理を実行する順次構造、条件によって処理を選択して実行する選択構造、条件が成立する限り処理を繰り返す繰返し構造の3つを基本制御構造という (図2.2)。これに、多分岐選択、条件判断を後でする繰返し、繰返しの中断、例外処理の記述など、いくつかの拡張を加えることもある。

構造化プログラミングでは、プログラムはこの基本制御構造の組合せ (図2.3) のみで作る。

構造化プログラミングが提唱された頃は、普通のプログラマが goto 文とラベルを多用してプログラムを書いていたので、この提唱は大きな論議を呼んだ。今日のソフトウェア工学、オブジェクト指向設計などの、いわばはしりとしてのエポックであったといえる。

構造化プログラミングでは、この基本制御構造の原理に加えて、複雑な物事を1度に詳細化するのではなく、まずは物事の概要をとらえて、徐々に詳細化していくという、段階的詳細化 (Stepwise Refinement) の原理も合わせて提唱された。これはプログラムだけでなく、一般の問題解決にも利用される原理である。ただ、全体をバランスよく段階的に詳細化するというのは大変難しく、どうしてもある部分は詳細になったのに、別の部分は概要のままであったりする。いかにバランスよく詳細化していくべきか、そもそも詳細化のバランスとはなにか、などの深い考察が、今日のオブジェクト指向に発展させたといえる。これらの意味からも、構造化プログラミングは今日のソフトウェア工学の原点であり、プログラマの誰もが常識として理解しているべきであろう。

2.2 構造化原理

どんなプログラムでも基本制御構造の組合せで作ることができることを構造化原理という。例えば、図2.4のようなgoto文を多用した、制御の流れが非常に分かりにくいプログラム (スパゲティプログラムという) が与えられたとする。これを構造化プログラミングで定められた3基本制御構造の組合せだけで表現した等価なプログラムが図2.5である。

[これらの図の変換法の説明の2段落を省略した (中川)]

構造化されていないプログラムを構造化する主な手段としては、処理をコピーする方法と、新たに制御変数を導入する方法がある (図2.6, 図2.7)。コピーする必要のある処理が小さい場合や、コピーしてもあまりプログラムが大きくならない場合はコピーが、そうでない場合は制御変数の導入が使える。

構造化原理は、この制御変数の導入によって簡単に証明できる。まず1つの整数変数 (s) を導入する。そしてプログラムのすべての命令に1から順に番号を付ける (最初の命令を1とする)。そしてプログラムのすべての命令の直後に、その命令の次に実行すべき命令の番号をiとしたとき、s=i; なる文を加える。次の命令がないとき、プログラムを終了するときは、s=0を加える。そして、全体を、sの値による多分岐命令を、sが0でない間繰り返すようにする。また、sは初期値として1を設定する。図2.8は、もとのプログラムに対して、このように制御変数を加えて構造化した例である。これによって、どんなプログラムでも、多分岐選択文の繰り返しという構造で表現できることが示せる。

このようにしてできたプログラムは、一見あまり意味がないように見えるかもしれないが、例えば、各命令の実行の度に共通の処理を加える場合、ちょうどプログラムのデバッガのように、実行時に指定した命令の直後に処理を中断したり、命令の実行順序をトレースしたりする場合は、この構造になる。

[以上『プログラム工学』より引用。図は一部書き換えた。]

---------------

2. 構造化プログラミングの補足 (ソフトウェア工学の中での説明と議論)

以上のようなソフトウェア工学の立場からの説明の一部を補足して、今後の考察のための準備をしよう。これは、ソフトウェア工学に専門でない人たちのための準備になるとともに、専門家の間では常識になってしまっていてそのためにかえって見落とされることがあるものを予め補う意味がある。

2.1 構造化プログラミングに至るまで

上記に説明されているように、goto 文を「多用」したプログラムが作られた時代があったが、それにはコンピュータの発展の歴史から来る必然があった。それは、コンピュータの基本原理である「フォンノイマンのプログラム内蔵方式」に由来する。

プログラム内蔵方式は、コンピュータにさせたい処理の手順を、コンピュータが理解できる言葉 (コンピュータが理解できる命令の列) で逐一記述して、記憶させておき、その命令を順番に読み出して実行するものである。一つの命令を実行すると、通常は記述 (記憶) されている順につぎの命令に進む。しかし、それだけでは、決まり切った一直線の仕事しかできない。そこで、すぐ次の命令でなく、離れた所に記憶されている命令を実行する機能が必要であり、これが「ジャンプ命令 (goto 命令)」であり、その行き先を示すのが「ラベル」である。また、このジャンプも無条件に行うだけではいろいろな処理を表現できないので、「条件に応じてジャンプする」ことが必要であり、これが「判別命令 (とそれに伴うジャンプ命令)」である。この「ジャンプ命令」の行き先は、記憶されたプログラムの後ろの方 (順方向) の場合もあれば、前の方 (戻り方向) の場合もある。

前に戻る必要がある典型的な場合とは、「繰り返して実行する」場合である。これは度々必要になるので、「繰返し」であることを明示すると分かりやすくなる。そこで、回数を数えながらの繰返しから始まって、「条件を満たしている間中繰り返す」(前判別方式)、「条件を満たすまで繰り返す」(後判別方式) などの各種の繰返し構造が作られていった。

プログラムの作成の規模の増大に伴い、人間に分かりやすいプログラミングの必要が認識され、機械語やアセンブラ言語でなく、Fortran で代表される「(高水準) プログラミング言語」が作られていく。そこでは、数式などを直接書けるようになり、上記の判別命令や繰返し命令が整備されて、プログラムで表現する命令のまとまりが少しずつ大きくなっていく。しかし、それでも、「ジャンプ命令」という基本的な手段が維持されていて、複雑な処理を (そのまま素直に) 書いたときに、「スパゲティプログラム」と呼ばれるような複雑なプログラムができていく。

「構造化プログラミング」を提唱したのは E.W. Dijkstra (ダイクストラ) であり、1972年のことである。それは、プログラマたちが作成するソフトウェアが巨大になっていき、プログラムを作成する者にも、それを読んで (保守・改良などに) 使う者にも、制御しがたくなって、多数のバグがソフトウェアに残り、ソフトウェアの信頼性が大きな危機を迎えていたときである。

2.2 goto 論争

Dijkstraが構造化プログラミングを提唱したとき、「goto 文は有害である」というキャッチフレーズが使われ、従来のプログラマたちに衝撃を与え、大きな論争になった。最初の段階で提唱されたのは、上記 (紫合の図2.2)に示した 3基本制御構造であった。従来の立場から言えば、「判別や繰返しの構造が便利であっても、goto 文を無くすと不便でしかたがない」というものである。提唱する側は、上記に引用した『プログラミング工学』でも試みているように、goto文をなくしても同等なプログラムが作れることを理論的に示して説得を試みたわけである。

現在の段階で振り返ってみると、「goto文なしでも、任意のプログラムを作ることが可能である」という主張には、「それで便利に書けるのか、プログラムが分かりやすくなるのか?」という異議が出されたのはある意味で当然である。「goto文があるから、プログラムが分かりにくい。だから、goto文を無くそう」という主張は、「goto文を無くすと、プログラムが分かりやすくなる」ということを保証する必要があった。

この論争は、やがて、構造化プログラミングに、いくつかの実際的な機能を追加容認することで決着がついていく。その機能とは、

    (d) 多分岐選択
    (e) 条件判断を後でする繰返し
    (f) 繰返しの中断
    (g) 例外処理の記述

などである (上記の紫合の文を参照)。これらを追加することによって、その他のgoto文を無くしても、便利に書けて分かりやすいことが、認められるようになっていった。

2.3 構造化プログラミングの基本制御構造の意図

構造化プログラミングの 3種の基本制御構造が必要な理由 (それを設ける意図) を、goto文との関係に注目して簡単にいうと、次のようである。

    (a) 逐次構造:    まったく素直に必要・必須のもの。
    (b) 判別構造:    前向きのgoto文を表現する。(分岐構造を作る。)
    (c) 繰返し構造: 戻る向きのgoto文を表現する。(繰返しの構造を作る。)

すなわち、ここで大事なことは、「前に戻る」のは、(基本的に) あるプログラム部分を「もう一度やる」ためであるから、それはその部分を「繰り返してやる」のだという理解である。

このように考えると、前向きのジャンプを表現するために「条件つきジャンプ」を導入し、後ろ向きのジャンプを表現するために「繰り返し構造」を導入したということであり、「何も特別なことをしているわけでない」と思えるかもしれない。しかし、本質はもっと違うところにある。

構造化プログラミングの本質は、ひとまとまりの (複雑な) 処理を、全体として、入り口一つ、出口一つのブラックボックスとして表現することにある。このブラックボックスは、一般的な技術用語として「機能」といってもよいし、「システム」といってもよい。それは情報科学では「アルゴリズム」と呼ばれている。処理を行う権利が、決められた一つの入り口から入り、何らかの予め定められた処理をして、必ず決められた出口から出てこなければならない。

そして、構造化プログラミングは、このブラックボックスの内部を (もう一段だけ詳しく) 記述する方法として、3種の基本制御構造「だけ」を許したのである。それが、

    (a) 逐次構造:    二つの処理を、逐次 (順番に) 実施する。
    (b) 判別構造:    何らかの条件が真か偽かに応じて、異なる処理を行い、
                       その後に一つの同じ出口から出る。
    (c) 繰返し構造:    何らかの (繰返しに応じて変化する) 条件を使って判断しつつ、
                         内部のひとまとまりの処理を繰り返す。

これらの内部構造を記述するときに、上記で暗黙に想定されていて、明示されていない大事な条件がある。

・ (a)(b)(c)で共通に、内部の処理構造は、親と同じく、つぎの条件を満たす。
「一つの入り口から入り、何らかの処理をして、一つの出口から出る。」
・ (a)(b)(c) で、内部の処理構造が何も実質を持たない、「空処理」であってもよい

これらのことを明示して、図2.2 (紫合) を書き直したものを、図1に示す。

このように考えると、紫合の図2.1に示すように、構造化プログラミングが、単にgotoを無くして分かりやすくするだけでなく、標準化した3種の基本構造を導入して、プログラミングの作業の「段階的詳細化」の思想と不可分であることが理解できる。

後に吟味するように、「構造化プログラミング」は、処理 (あるいは機能) を「入れ子」として表現し、処理全体 (すなわち、「システム」を) 階層的に構成するものであることが分かる。

2.4 構造化プログラミングにおける追加制御構造の意義

goto論争において、「goto文を無くすると、処理を自由に書けないから不便だ」という意見 (反論) があった。その論争が延々と行われた結果、2.2節に示すように、つぎの機能が追加的に導入されて、ほぼ決着した。すなわち、(d) 多分岐選択、(e) 条件判断を後でする繰返し、(f) 繰返しの中断、(g) 例外処理の記述である。これらを図1に対応して模式的に描くと図2のようである。

上記の図から理解できるように、これらの追加の制御構造は、前述の3基本構造から組み立てることができる。その意味で必須ではない。しかし、多くのプログラムにおいて、作る側にも読む側 (解読する人)にも、これらの制御構造がある方が「分かりやすく、便利である」と認識されて導入されたのである。

ではこれらの追加制御構造を加えることで、どのように分かりやすくなるのかを、いままでのいくつかの例を再考することで、例示しよう。

最初の例は、紫合の図2.6の下段 (図2.7の下段も同じ) のプログラムである。これを追加拡張された構造化プログラミングの立場で解釈し直すと、もともとのプログラムは、無条件の繰返しと、繰返しの中断という考え方で作られていると解釈できる。この解釈を素直に表現したのが、図2aである。

図2a. 拡張した構造化プログラミングによって書き換えた例

ここで注意すべきは、「無条件繰返し」という概念は、もとの3基本制御構造だけでは表現できないことである。単純な無条件繰返しは、「処理が有限回で終了しなければならない」という「アルゴリズム」の要求に反する。繰返しの中断という機能が許されて初めて、無条件繰返しを導入できる。また、繰返しの中断の形式をとれば、繰返しを終了するための条件の記述を、繰返しの最初 (すなわち前判定形式) か、最後 (すなわち後判定形式) かに限定する必要がなく、上記のように繰返し本体中の適切な任意の位置に置くことができる。

この説明では、もとの (上図左の) プログラムの意図を尊重することを強調した。では、右側に書き換えることに何の意味があるのか? なにが分かりやすくなるのか? それは、このプログラムを解読するときに、処理P1に入る前の段階で、P1以下P2までが無条件繰返しになっていることを、明瞭に知ることができることである。紫合も述べているように、プログラムを前から順に理解できるようにすることが、最も重要なことなのである。

ここに書き換えた図と、3基本制御構造だけで表現した図 (紫合の図2.6下右と図2.7下右) とを比べて考察することも意味がある。処理のコピーによる変換例 (紫合の図2.6下右) は、処理P1が小さいものなら確かにこれでもよいだろうが、P1が大きくなると分かりにくくなる。制御変数による変換例 (紫合の図2.7下右) は、この制御変数の意味がこのプログラムの処理の本来の意図と適切に対応していない限り、非常に分かりにくい。「処理論理を分かりにくくしている」と批判されてもしかたがない。これらに比べて、拡張した制御構造で表現した例 (図2a右) がずっと分かりやすくなっているといえる。

つぎに、もっと複雑な例として、紫合の図2.4の例を見よう。この図2.4も複雑だが (実際の紫合の教科書では誌面の関係で途中で折り返して2列で表現されていてもっと複雑に見える)、率直に言って、構造化プログラミングで書き換えた紫合の図2.5が少しも分かりやすくなっているようには思えない。本来、処理論理を分かりやすくするには、図2.4を導いた論理そのものを再考することが重要であるが、それができないから、図2.4の処理論理そのものは正しいと前提して、それをどう表現するとよいのかを議論することになる。その表現の手段として、goto文を用いず、(初期に提唱された3制御構造だけではなく) 拡張した構造化プログラミングの規約を用いて表現し直してみようというのがいまの課題である。

紫合の図2.4のプログラムの論理を素直に読むと、ラベルL1への戻りが無条件繰返しで、C4がその繰返しの中断であること、ラベルL2への戻りは条件C3での後判定繰返しであり、C1がその繰返しの中断条件であることが分かる。この解釈のもとに、拡張した構造化プログラミングで書き直すと、つぎのようなプログラムが得られた。

この書き換え例で、もとのプログラムよりも分かりやすくなることの要点は、制御が戻ってくる所に、繰返しの条件と繰返し範囲を明示して、予めその意図を明示しておくことであることが分かる。また、繰返しの中断という形での制御の飛び出しが、繰返し範囲のブロックの直後になっているのだという規約が、プログラムを読んでいく者にとって分かりやすくなっていると考えられる。

さらに、多分岐選択文を使うと、紫合の図2.8右の図をもう少し分かりやすく書ける。それはほぼ自明であると思うが、念のために書いておくとつぎの図2cのようである。

図2c. 紫合の図2.8右を拡張した構造化プログラミングの記法で書き換えた例

2.5 プログラミング言語における「構文」の役割

ここで、上記の図式表現 (フローチャート表現) では必ずしも十分に表現されていず、プログラミング言語のレベルで考えるべきことがある。それは紫合が2.1節の最初で言っていることで、「分かりやすい文章は、上から下へ、初めから終わりへ順に読めるものである。プログラムも、原則として上から下へ順に読めるようになっているべきである」という論点である。このために、構造化プログラミング (およびその拡張版) で導入した制御構造は、すべてその制御構造を明示するための「構文」で表現する。

「構文」は、例えば 3基本構造に関してはつぎのような形式を取る。
        逐次構造:         P1; P2;                             処理P1 のつぎに処理P2
        選択構造:         if ( C ) P1; else P2;            条件C が真なら処理P1、偽なら処理P2
        繰返し構造:    while ( C ) P;                      条件C を満たしている間中処理P を繰り返し

ここで、if、while などのプログラミング言語で規定したキーワード (「予約語」という) が出てくると、その後ろにはある一定の形式での記述が現れ、それがいままでの図式で示した意味を持つと約束されている。これらのキーワードを先頭にした構文で、その構文の終了を示す記号を (この例では、セミコロン ';') 約束しておくことが大事である。この「約束」は、プログラミング言語の「文法」の形で強制力を持ったものにする。これに違反する書き方は正しいプログラムとしてコンピュータに認められず、実行前に誤りを指摘され排除される。

また、上記では単純に横書きしたが、プログラムの構造をさらに分かりやすくするために、改行と字下げによって、処理記述の階層を表現することが、通常「よい慣習」として行われる。

この「構文」に対応することをフローチャートの図式に表現するなら、特に繰返しの制御構造に対して、繰り返し構文の始まる位置に「前判定繰り返し」「後判定繰り返し」などの説明をつけることであろう。上記の図2bにはそのような説明をつけてある。

2.6 構造化プログラミングが何を禁止 (制限) したのか?

それでは、構造化プログラミングがあくまでも許容しないものは何か?これを考えると、構造化プログラミングの本質を浮き彫りにできる。構造化プログラミングが許容しないのは、「入れ子構造のねじれ」現象である。その端的な例は、紫合の図2.6および図2.7の上段左側に示されている。これらのままでは、プログラムの制御構造が構造化プログラミングの規範に一致しない。この事情をもう少し具体的に示すとつぎの図のようである。

すなわち、「構造化プログラミング」とは、完全な (ねじれのない) 「入れ子」による「階層的なプログラミング」であるといえる。また、「一つの処理は、入り口一つ、出口一つ」の規律を守ることであるといってもよい。

3. TRIZから見た構造化プログラミング

さて、では以上のような「構造化プログラミング」の考えかたやその歴史をTRIZの観点から見てみよう。ここでTRIZと言っているのは、その中の最も有名な「40の発明原理」だけでなく、「76の発明標準解」、「進化のトレンド」、「理想性」など、 TRIZのさまざまな要素を含む。また、これらの背後にある「システムの考え方」、「矛盾を解決するプロセス」、その他の思想的な要素がある。このような思想的な要素の場合には、特定のTRIZの項目を参照しにくいが、やはり大事なことである。

3.1 複雑性の克服

この「構造化プログラミング」が目指したものは、膨大になってきたプログラム (ソフトウェア) の「複雑さ」を克服して、「分かりやすく」することであった。技術の発展におけるこのような「複雑化」の進行と、それを克服して「単純にする」ことによる一層の発展は、さまざまな技術システムにおいて知られていて、それはTRIZにおける重要な認識の一つになっている。

この点に関するTRIZの認識を端的に示すものは、Darrell Mann 著『TRIZ 実践と効用 (1) 体系的技術革新』(中川　徹監訳, 2004年6月) の図13.6 である。

図4.

TRIZの観点から見れば、(「技術システム」の一つの例である) ソフトウェア (＝プログラム) が、どんどん発展して巨大化・複雑化した段階において、その複雑さを減少させることによりさらに発展させることは、「必然的な」試みであると言える。

このような試みは、ソフトウェア開発方法の歴史において、繰り返し試みられた。プログラミングに用いる言語をより分かりやすくする (「高水準化」する) ことがその試みの中心にあった。「構造化プログラミング」もまた、そのような「複雑さを減少させることによる発展」の一つの動きであると理解できる。

3.2 「システム」の階層性と「入れ子構造」

TRIZにおいて、「システム」の概念はその理論の根底にある。「システム」とは、「いくつかの構成要素を持ち、それらが互いに関係をもって、一つの機能を実現するもの」である。もちろんこれはTRIZに固有の認識ではない。「システム」をブラックボックスとして見る見方は、つぎの図式で表現できる。ここの「システム」の代わりに、「機能」と書いてもよい。

図5. システム (または機能) のブラックボックス表現

ソフトウェアの作成において、一つのプログラムを、なんらかの処理をする一つの機能であると見なすことは、自然であり、初期からそのように認識されてきた。

システムには、その構成要素として「下位システム」があり、また一方当システムを構成要素とする「上位システム」があって、このような上位/下位による「システムの階層性」の概念もまた広く (TRIZを含めて) 認識されている。ソフトウェアを、階層的に構成することは、ある意味で広く行われてきたことである。

TRIZには、「発明原理 7. 入れ子の原理」がある。そのサブ原理は以下のようである。

    A. 一つの物体あるいはシステムを別のものの内部に入れる。
    B. 複数の物体あるいはシステムを他のものの内部に置く。
    C. 一つの物体あるいはシステムが、別のものに開いた適当な穴を通り抜けられるよう
         にする。

MannのTRIZ教科書の諸例には、バードウェア的なものばかりが並んでいるが、この「構造化プログラミング」でやっていることは、この「入れ子の原理」のサブ原理A, Bにそのまま当てはまる。すなわち、「一つ (あるいは複数) のシステムを、別のシステムの内部に入れる」ことである。

上記で述べたように、構造化プログラミングでは「完全に内部に」入れることを重視しており、それによって、すっきりした「システムの階層性」を実現しようとしているのである。従来も、ある程度の大きさごとには「入れ子」を守っていたが、その内部の構造には「ねじれた入れ子」の現象が許容されていた。プログラム中のすべての部分で、この「ねじれた入れ子」をやめて、正規の「入れ子」にしようというのが、構造化プログラミングであると言える。このように、「入れ子の原理」は、システムの階層性を表現する原理として、今後重視していくのがよいであろう。

3.3 「goto文はあるべきか、ないべきか?」TRIZの矛盾の観点から

goto論争は、TRIZでいう典型的な「矛盾」をめぐる問題であるといえよう。その矛盾を簡単に表現すると、

「処理のさまざまな論理を表現するためには、goto文は必要である。
処理の論理が複雑になるから、goto 文はないほうがよい。なしにすべきである。

この論争は、goto文がふつうに多く使われていた段階で、「goto文はない方がよい。なしにすべきである」という主張が提示されたために、「あるべきか、ないべきか?」という極端な矛盾の形式をとることになった。

この矛盾の提示のしかたは、TRIZでいう「物理的矛盾」の形式である。

「物理的矛盾」＝「技術システムの一つの面に対して、
正逆の相反する要求が同時にある状況」

ところで、このgoto文論争においては、「(結論として) あるべきだ」と「(結論として) ないべきだ」の二つの逆の要求が同時にあるという「物理的矛盾」の形を取っている。だが、それらは人間の間での論争によくあることとして、両者の論理にいくつかの飛躍があるように思われる。この論理の飛躍を明確にして、より客観的な議論にすることが、この場合の矛盾の解決につながる。そのような意図から、この場合の矛盾とその解決をより深く考えてみよう。

TRIZでは、「物理的矛盾」は、「要求を再吟味する」ことによって解決できるのだという。その吟味はつぎのような質問をすることによって行う。

(a) 「goto文がある」ことを望むのは、どこか?
「goto文がない」ことを望むのは、どこか?

(b) 「goto文がある」ことを望むのは、いつか?
「goto文がない」ことを望むのは、いつか?

上記の3対の質問は、それぞれの要求 (あるいはこの場合には「主張」) が、どのような「空間」、「時間」、および「場合」について、言っているのかを明確にする。これらの質問について、両者の要求の答えに違いがあるとき、その違いを利用して、一見矛盾した要求を両立させるような方法を考えるのが、TRIZが編み出した矛盾の克服法である。TRIZではこれを「分離原理」という。「分離原理」では、この後につぎのように進める。

「分離原理」: 「物理的矛盾にある両者の要求について、
                     空間/時間/場合のどれかに関して両者に違いが見出されたら、
                     その違うそれぞれの状況で各要求を完全に満たす解決策を作り、
                     その上で両解決策を統合して用いる方法を見出す。」

このgoto文の矛盾において、両者の当初の主張はつぎのようなものだったといえる。

(a) 「goto文がある」ことを望むのは、プログラム中のどこでも。
「goto文がない」ことを望むのは、プログラム中のどこでも。

(b) 「goto文がある」ことを望むのは、プログラムを作るとき、いつでも。
「goto文がない」ことを望むのは、プログラムを作るとき、いつでも。

要するに、この当初の段階で (の一般的な理解) は、「goto文がない」という側の要求が、goto文の「全否定」の形を取り、それに対して従来の方式を支持する側からの反対 (反発) が起きたということである。空間/時間/場合について、両者の主張が極めて広く、細分化されていない (吟味されていない) ことが特徴である。

「矛盾の克服」というのは、本来、対立しているレベルよりも上位のレベルでの、目的/目標の共有がなければ成り立たない。より上位に同じ目的/目標を持って初めて、矛盾が克服でき、新しい解決策が意味を持つ。このようなより上位の目的/目標を明確にして初めてつぎの段階に進める。

このケースの場合に、上位の目的/目標は
「プログラムの書き方を、分かりやすく、間違いを起こしにくいようにすること」
である。この目的/目標を強く掲げたのは、「goto文をなくす」ことを提唱した側であり、それは従来からの方法を使っている一般のプログラマたちにとっても異存のないことであった。この目的にとって、「goto文が害になる」というDijkstraの主張が、「goto文をなくせ」になった点にもっと検討が必要である。

「構造化プログラミング」の主張は、当初、逐次構造、判別構造、前条件判定の繰返し構造という3基本制御構造だけを使い、goto文を一切やめることを主張した。これらの構造は理解しやすい構造であること、そして、これだけで (goto文なしで) プログラムが書ける (処理論理を表現できる) ことを、理論的な立場から示して論拠にしたのである。しかし、「プログラムを書くことができる」のは当然必要なことであり、その上で「より分かりやすく、間違いを起こしにくくなる」ことが、提唱する側のが本来主張すべきことであった。 3基本構造だけで表現したために、制御変数などを多用してプログラムが「分かりにくくなった」ということが起こるのなら、その主張を再吟味・修正すべきであろう。

goto論争についての理解が深まっていった段階で、上記の3対の質問に対して、より明確な回答を両者ができるようになっていった。すなわち、特に(c)について、

「goto文がない」ことを望むのは、どんな場合か?
--> 基本制御構造において「入れ子構造にねじれ現象が起こる」場合。

このような段階になって、つぎのような解決策が作られたと言える。

    「3基本制御構造の他に、つぎの構造を追加する。
         多分岐判別、後判定の繰返し、繰返しからの飛び出し、例外処理の記述
      これによって、goto文をなくすことができ、
                   「入れ子構造のねじれ現象」を生じないことを保証できる。

これが、「goto文はあるべきか/ないべきか?」という「goto論争」を乗り越えて、一つの「矛盾を克服した」後の「構造化プログラミング」の姿である。

だから、構造化プログラミングを教える場合に、3基本構造は初期の提唱と考えるべきであって、追加構造を含めた形で教え、「入れ子構造のねじれ現象」が起こらないように保証するのだという点をもっと強調するのがよいと考えられる。

3.4 汎用性の原理と分割の原理

プログラミングが複雑になり、スパゲティプログラムが多くでてきたとき、それをもっと分かりやすく、簡単にするための指針は何であったろうか? これをTRIZの中から見出そうとすると、汎用性の原理と分割の原理に思い至る。

TRIZの発明原理6の汎用性 (Universality) はつぎのように述べている。

    「発明原理 6. 汎用性
                   A. 一つの物体やシステムが複数の機能を実行できるようにし、
                        他のシステムの必要性をなくす。」

プログラミングの方法を考えるときの「汎用性」には、ここのサブ原理Aの記述とはやや違ったニュアンスがある。それをつぎのように表現しよう。

「基本的で標準的な機能単位のものを作り、広い範囲に一般的に使えるようにする。」

この考え方はプログラミングに限らない。ネジであっても、乾電池であっても、すべてこのような観点から、「汎用性」のものが作られていて、それは技術の世界では当然のあるべき姿であるとして知られている。あるいは「汎用性」の代わりに、「標準化」、「規格化」と呼ばれることも多い。TRIZの発明原理6をこのような意味も含めて解釈することは、自然なことである。

構造化プログラミングでは、複雑な処理論理を、goto文を使ってその場その場で考えて書くよりも、より汎用的な機能単位である「3基本制御構造 (+ 追加の制御構造)」で書くことを提唱しているのである。この場合に、新しい「機能単位」がどれだけ一般性があり、広い範囲に使いやすいかが、新しい提唱の生命である。

複雑性を克服するためのもう一つの原理は、TRIZの発明原理1を見るとよい。

    「発明原理 1. 分割
                  A. システムを分離した部分あるいは区分に分割する。
                  B. 組み立てと分解が容易なようにシステムを作る。
                  C. 分割の度合いを増加させる。」

この原理は、ハードウェア的な実際のものからなるシステムにも適用できるし、人間の思考に関すること、社会組織に関連することなどでも適用できる。広範な分野でその有効性が知られているものである。

複雑になっているプログラム (あるいは処理論理) を取り扱いやすくする基本的な方法として、「分割」の原理は広く適用されてきた。ソフトウェアの世界では、「分割統治」(Divide and Conquer) と表現されていることも多いし、「段階的詳細化」という言葉で表現されていることもある。すでに述べたように、構造化プログラミングは、処理論理を (入れ子構造を厳密に守りつつ) 階層的に細分化して構成していく方法であるということができる。

なお、人間が一時に同時に扱える情報は7±2個までであると言われている。この意味で構造化プログラミングが提唱した、3基本制御構造 + 4追加構造というのは、7個だからうまく納まっているといえる。

3.5 信頼性を高めるプログラミング

「構造化プログラミング」の提唱は、ソフトウェアの開発において、処理の速さや必要記憶容量の小ささなど「性能」を重視する観点から、「信頼性」を重視する観点への転換を主張したことに大きな意義がある。

最近のTRIZにおいては、多数の技術システムの発展の歴史から「技術システムの進化のトレンド」を抽出しているが、その中でMannはつぎのトレンドを記述している。

「進化のトレンド (23) 顧客の購入の焦点
性能 --> 信頼性 --> 便利さ --> 価格」

ここでいう「性能」とは、その技術システムがともかく最初に意図した機能を提供することであり、その機能を表現する主要パラメータについてよりよい値を出すことである。そういった「性能」に顧客が十分満足して来ると、つぎに顧客の焦点が「信頼性」に移行していくのだという。

プログラミングにおける「性能重視」から「信頼性重視」への転換は、構造化プログラミングを初めとした多くの運動で徐々に進行した。初期のコンピュータは、記憶容量が小さく、処理速度が遅く、処理命令が単純であったから、その上で動くプログラムを作るのに多大の努力を必要とした。できるだけ使用する記憶容量を少なくし、できるだけ無駄な処理を省いて処理速度を上げることが、「良いプログラミング」であり、そのようなねらいで、プログラミングの教育が行われた。また、凝った「職人肌」のプログラムが作られていき、それはgoto文を多用したものになって、「スパゲティプログラム」と言われようと、高速で縦横無尽に処理を行うものであった。

プログラムを作る立場で単純にいうと、「プログラムをきちんと作ればよいのであって、goto文を使っていようといまいと、うまい人は間違いなく作り、下手な者が間違うだけのことだ」ということであろう。そこには熟練技術者がいつも陥りがちな、「自分は間違わない」というプライドからくる独善が潜んでいる。もっと広く、多数のプログラマ (今後のプログラマ予備軍も含めて) のことを考え、ソフトウェア業界が全体として、性能から信頼性に重点を移していくための、一つの大きな運動が「構造化プログラミング」だったのである。

3.6 「goto論争」と運動

「goto論争」を振り返るとき、「3基本制御構造だけを使い、goto文をなくせ」という初期の提示が適当だったのだろうか? という疑問が湧く。あまりにも極端だったのではないか? という疑問である。

これに関して想起されるのが、TRIZの発明原理16である。

    「発明原理16. 部分的な作用または過剰な作用
                    A. 正確に正しい量の作用を達成するのが困難な場合には、
                         「少し少ない」または「少し多い」作用を施して、
                         その問題を減少あるいは除去する。」

この発明原理を模式図で表すと、つぎのような図になるだろう。この図はシステムの応答を表す図としてしばしば見られるものである。

図6. 発明原理16. 部分的な作用または過剰な作用 (模式図)

いま、「構造化プログラミング」を提唱しようとする段階のことを、提唱者の立場で考えてみよう。そして、「世界のソフトウェア業界」を対象として、「構造化プログラミング」の理想を実現させるにはどうすればよいか? どのような提唱のしかたをすると、この「ソフトウェア業界」という対象システムはどのように振る舞うだろうか? と考える。すると、「徐々にシステムを変えていく」ことをねらうよりも、もっと早くシステムを変えるためには、「過剰な作用を与える (いわばオーバシュートさせる)」ことが効果的だろうという判断は、十分にあり得ることである。社会とか業界全体とかの大きなシステムに影響を与えようとするような一種の「運動」においては、当然考えるべき戦略であると思われる。この意味で、3基本制御構造の提唱は、衝撃を強くするための「目標値よりも少し極端な提唱」、すなわちTRIZの発明原理16にいう「過剰な作用」であったと理解できる。

なお、この理解は、「現在普通に使われている追加の制御構造を加えたプログラミングの規約が、妥協の産物なのではなく、本来の最終目標であった」という理解である。ただし、提唱者のDijkstraが提唱の最初においてこのような理解であったかどうか、そして現在の状況を妥協の産物と考えているかどうか、に関してTRIZは関与しない。TRIZがいう技術の進化は、個々の発明者や提唱者の意図を越えたはるかに大きなスケールで考えているからである。

4. ソフトウェア工学/ 情報科学がTRIZにもたらすもの

さて、いままでは、ソフトウェア分野の問題に対してTRIZの観点から考察を加えてきて、TRIZがソフトウェア分野に対しても随分本質のところで発言ができることを見てきた。TRIZは特定分野の理論というのではなく、あらゆる技術分野を見回してそのエッセンスを抽出して一般化しようとしてきた理論であるから、ある意味で当然である。ソフトウェア分野自体が、その発展において、さまざまのハードウェア的な技術分野、そして人間や社会に関わるものをモデルとしてきたのだという歴史もある。

そこで、つぎに、ソフトウェア分野での考察がTRIZにもたらすものをもっとよく考えてみよう。 TRIZが確立したのは1970年代の旧ソ連であったから、それ以後の研究活動を含めてもまだまだ、ソフトウェア分野や情報科学分野の事例や原理が TRIZに反映されていることが少ないのである。その作業の全体を試みることはすぐにはできないから、今回の「構造化プログラミング」に関わることに関して、本論文の2節、3節で出てきているいくつかの論点をまとめ直してみることをその手がかりにしよう。

いままでの論点で、上記の観点から特に注目すべき項目を取り出すと以下のものがある。

   (1) ソフトウェアの「処理構造」や「アルゴリズム」の概念を、
         TRIZにおける「システム」や「機能」の概念にもっと取り込む。
    (2) ソフトウェアの「段階的詳細化」の概念を、「分割原理」に取り込む。
    (3) 「入れ子」の原理が「システムの階層性」を表現していることの認識。
    (4) 「分かりやすさ」の概念をTRIZに取り込むことの必要性。
    (5) 「入れ子構造のねじれ現象」の問題を考察する必要性。
    (6) システムの「複雑さ」を克服する具体的な方法の考察。
    (7) 「汎用性」の原理をより広く解釈すべきこと。「標準化」「規格化」の重要性。
    (8) 「矛盾」を明確にするプロセスの再考。
            人間の論争における矛盾の扱いと「より上位の目的」の重要性。

4.1 ソフトウェアの「処理構造」や「アルゴリズム」の概念のTRIZへの取り込み

TRIZでは「システム」や「機能」の概念を非常に重視してきており、ソフトウェアにおける「処理構造」や「アルゴリズム」にも同様に適用できるものであることを知っても、ある意味でなにも驚くに当たらない。ただ、ソフトウェア分野での概念が、その他の技術的分野と異なることは、「システム」や「機能」を定義・作成する場合の柔軟性と豊富な構成力にあるといえる。いろいろな「処理機能」を簡単に、かなりの程度思いのままに、作成することができ、その内部構造を随分いろいろな形式で作成できる。

このような柔軟性と構成力は、従来のシステムの概念では (理論的には想定していても) 実感として持っていなかったような、新しい考え方や新しい方法に導く可能性がある。その例は、後で説明する「入れ子による階層的システム構成」であり、「システムの階層の再帰性」であろう。

TRIZを人間や社会などの問題に適用したときにも、もちろん新しい側面が出てくるであろう。それと比べたときに、ソフトウェア分野への適用が持つ意義は、ソフトウェアという対象が論理性を持った対象であり、一つの科学として「情報科学/コンピュータサイエンス」が構築されてきている対象であることだろう。その意味でソフトウェア分野の原理や認識をTRIZに取り込むことは大きな意義を持つのである。

4.2 ソフトウェアの「段階的詳細化」の概念の「分割原理」への導入

ソフトウェア分野、情報科学の分野においては、複雑な問題 (顧客の要求など) を解明して、具体的なソフトウェアとして実現していくために、「段階的詳細化」が中心的な指導原理になっている。もやもやした問題を、部分部分に分けることによって、より扱いやすい小さな問題の集まりにして行こうとするのである。このときに各部分への分割のしかたが問題になり、それらの各部分を適切に定義することと、それらの部分の間の関係を明確にすることが課題になる。

TRIZの「発明原理1. 分割の原理」は、3.4節に述べたように、ちょっと考えるとこの段階的詳細化の原理を含んでいるようにも見える。しかし、もっと踏み込んで、下記のサブ原理D.を追加するとさら明確になり、応用性が広いものになるだろう。

    「発明原理 1. 分割
                  A. システムを分離した部分あるいは区分に分割する。
                  B. 組み立てと分解が容易なようにシステムを作る。
                  C. 分割の度合いを増加させる。
          (追加:) D. 問題をいくつかの部分に分け、各部分とその関係として考える。」

これは、技術的問題一般、ソフトウェア分野、人間や社会分野一般という、すべての分野の問題解決にとって、非常に基本的な指導原理を表現している。

4.3 「入れ子の原理」を「システムの階層性」を表現する原理として捉える

TRIZの「発明原理7. 入れ子の原理」は、具体的なものを扱う世界では必ずしも大きな位置を占めていない。この原理の別名は、ロシア伝統の「マトリョーシカ (入れ子人形)」である。それは非常に印象的ではあるが、もっともっと多くの例を含んでいるという印象は少ない。

ソフトウェア分野で明確になった「システムの入れ子によって表現される階層構造」というアイデアを盛り込むには、やはり、下記のような追加のサブ原理はどうであろうか?

     「発明原理 7. 入れ子の原理
            A. 一つの物体あるいはシステムを別のものの内部に入れる。
            B. 複数の物体あるいはシステムを他のものの内部に置く。
            C. 一つの物体あるいはシステムが、別のものに開いた適当な穴を通り抜け
                 られるようにする。
(追加:) D. システムを入れ子構造の階層的な連鎖の形で実現する。」

ここで少し躊躇があるのは、「何らかの概念をTRIZに持ち込もうとするときに、TRIZの発明原理を拡張強化するのが適当な手段か?」という疑問である。別の言葉で言えば、「TRIZにはシステムの階層性の理解は (思想レベルでは) 十分に備わっているのだから、たとえ発明原理にその表現が十分でなくてもかまわないではないか」ということである。そうかもしれないが、TRIZの初心者に対して「TRIZの発明原理」が非常に大きな存在として教えられていることを考えると、やはり「強化するとよいところは、強化するとよい」と思う。

[この点に関して、中川が主張している「やさしくした TRIZ」としての「USIT法」では、TRIZの発明原理だけでなく、TRIZの発明標準解や進化のトレンドなどの概念などをすべてまとめ直したものにしている。本稿では話の本質を横に逸らさないために、USITをあまり表てに出さないようにする。]

4.4 「分かりやすさ」の概念

TRIZでは、システムの「複雑さ」の概念は重要なものであった。システムはその発展 (「進化」)の中で、さまざまな構成要素 (部品) や機能を取り込み、複雑化していく。その複雑化がある限度に達したとき (すなわち、複雑さの弊害が明白になってきたとき)、システムの単純化が始まると考えてきた。またこの「複雑さ」の分析は (技術分野一般に当てはまるような定義が) 必ずしも明確ではなく、大雑把に「部品点数 (構成要素数)」でおきかえられたりしてきた。

一方、ソフトウェア分野や情報科学の分野では、「複雑さ」の概念と「分かりやすさ」の概念がともに、非常に重要な問題として考えられてきた。例えば「計算の複雑性」については、さまざまなアルゴリズムに緻密で定量的な議論がある。それは、単にプログラムの行数ではなく、さまざまな場合の繰返し実行などを考えたときの総実行命令数に関わる議論である。

一方、「分かりやすさ」の概念は、ここの構造化プログラミングでの議論の中心になっていることでも分かるように、ソフトウェア分野/情報科学の中心的な論点である。だから、「分かりやすくする」ためのさまざまな方法が具体的に提出され、実地に適用されていった。現在主流になって使われている諸方法の多くは、以前の諸方法よりも「より分かりやすい」ものが多いであろう。(だからこそ、多くの人々がパソコンを使い、メールやインタネットを使えるのである。)

しかし、「分かりやすさ」の概念が情報科学でも十分明確になっているとはいいがたい。例えば、「分かりやすく」するために提唱された「構造化プログラミング」を使って書き換えた、紫合の図2.5がもとの図2.4よりも「分かりやすい」ことを実証することはできていないからである。

「分かりやすさ」の概念をTRIZに導入することは大きな意義を持っているに違いない。「分かりやすさの向上」は、TRIZでいう技術システムの進化のトレンドの一つとして考えるに値することであろう。おそらく、新しいトレンド項目を立てるとすれば、「使いやすさの向上」のトレンドを立て、その一つの側面として「分かりやすさの向上」があるのだと思われる。-- ただし、この「分かりやすさ」の問題はずっと奥が深いと考えられるので、本稿ではここまでにしておき、今後折にふれて考察を加えたい。

4.5 「入れ子構造のねじれ現象」の問題

この問題はまだ検討を要する問題といった方がよい。通常の技術システムにおいて、それがいろいろな構成要素 (簡単には部品) から作られている場合に、そのシステム内の「下位システム (サブシステム)」をどのように区分する (あるいは区分して作る) かには、いろいろな自由度がある。例えば、システム内を機能に関して区分して作ろうとする場合に、サブ機能Aに属するものとサブ機能Bに属するものとが、部品という目で見ると一部に重なりあっていることがあるだろうし、空間的に見たときにも重なり合うことがあるだろう。それを「重ならないように作る方がよい」というべきだろうか?

この構造化プログラミングでは、処理の論理のブロック (要するに機能のブロック) が「入れ子のねじれ構造にならない」ことを良しとしている。これは、機能で分けた下位システムが互いに重ならないことを要請していることであり、それが「分かりやすい」からであるという。

ハードウェアの技術の領域でこれに対応する指針としては、Nam Suhの「公理的設計」がある。そこではつぎの二つのガイドラインがある。

    公理的設計のガイドライン
      (1) 良い設計は、異なる機能的要求の間に独立性を実現する。
      (2) 良い設計は、機能的要求を最小限の複雑性で実現する。

Mannはこれらには重要な例外があるけれども、基本的には有用なガイドラインであると評価している。

上記の「構造化プログラミング」における提唱を、機能のブロックの間の重なり合いを避ける (独立に作る) ことであると解釈すると、この公理的設計のガイドライン (1) と良く対応する。情報科学における「構造化プログラミング」の提唱は、機械などのハード技術分野での「公理的設計」の提唱よりもずっと早いことは注目すべきである。ソフトウェア分野、情報科学の分野が、技術一般の分野に寄与できる一つのしかたが、この例のような抽象化したレベルでのシステムに関する考察であることを心に留めておきたい。

ただ、システムでの「入れ子構造のねじれ現象」の問題はさらに考えていく必要があると思う。

4.6 システムの「複雑さ」を克服する具体的な方法

TRIZでは、システムの複雑さを克服していくことが、ある進化段階以後のシステムの進化にとって重要であることをよく認識している。それでは、その複雑さを減少させるために、どのような方法を提示しているだろうか? Darrell MannのTRIZ教科書では、システム内の部品数の減少に関連する発明原理として、番号順に以下の7原理を挙げている (文献2, p180)。以下にそれらの簡単な説明を ( ) 内に示す。

発明原理 2. 分離       (システム内の複数機能のうち、有害/不必要のものを分離する)
発明原理 3. 局所的性質 (既存の一つの構成要素を修正して、複数の機能を実現する)
発明原理 5. 併合        (複数の物体、機能などを、一つに併合する)
発明原理 6. 汎用性      (一つの物体またはシステムに複数の機能を実行させる)
発明原理 20. 有用作用の継続 (無駄な/非生産的な動作あるいは仕事を除去する)
発明原理 25. セルフサービス (物体/システムがそれ自体で機能を実行する)
発明原理 40. 複合材料   (複数の構造/機能を組合せ、一体の合成構造にする)

この他にTRIZの方法として考えられるものは:

  トリミング：システムのある構成要素をまず無くしたと仮定し、それが持っていた
                    機能を別の (または新しい) 構成要素に担わせて簡単化する。
    適応型材料 (賢い材料) のトレンド:
    エネルギ変換回数の減少のトレンド:

これらを読んでも、本稿で扱った「構造化プログラミング」で考えているような、「分かりやすさ」の向上を鍵として、標準的な構造を導入することによる簡単化のアプローチはあまり感じられない。「汎用性原理」を拡張すべきことは次節に再度述べる。「どのようにして、システムの複雑さを克服するのか?」はもっと大きな問題として今後考えていくべきことであると感じる。

4.7 「汎用性」の原理の拡張と「標準化/規格化」の重要性

本稿3.4節で述べたように、標準的なものを作って個別の設計/制作を置き換え、「分かりやすくする」そして「作りやすくする」ことが、構造化プログラミングの大きなねらいであった。この考え方はTRIZの発明原理6.に含まれているものであるが、もっと明示的にする、拡張する必要があると考える。

TRIZの発明原理 6. をつぎのように拡張することを提案する。

「発明原理 6. 汎用性
                 A. 一つの物体やシステムが複数の機能を実行できるようにし、
                      他のシステムの必要性をなくす。」
          (追加) B. 基本的で標準的な機能単位のものを作り、広い範囲に一般的に
                      使えるようにする。
                      (例: ネジ、乾電池、プログラミング言語などの標準化、規格化)」

このような追加が必要になった理由を考えてみると、TRIZが「特許の分析」を土台にしてきたことの一つの盲点に気がつく。標準化や規格化は技術の発展にとって非常に重要なことであるが、それ自体は「特許」にならない。また、特許には標準化・規格化したものを使ったことの利点を書くような部分はない。このため、技術の発展を支え、技術的な問題を解決する大きな要因であるのに、TRIZの中に適切に取り入れられていない。

この事実に注意することは、意外と大きな意味を持つことであり、今後のTRIZの発展にとって大事なことである。(TRIZを簡易化した) USIT法を開発した Ed Sickafus は、その方法の適用の重点を「発明のため」ではなく、「技術における創造的な問題解決のため」と規定した。「発明」に重点を置きすぎると、「新規性」を強調しすぎることになり、企業現場での実際の問題解決に適当でないからだという。「標準化」「規格化」を目指すことは、世界的なスケールで問題を解決するために非常に重要なことであり、今後のTRIZの発展の方向として、それをも含めた (「発明的」でないからとして排除しない/忘却しない) 「創造的問題解決」の目標を掲げるべきであると考える。

4.8 「矛盾」を明確にするプロセスを再考する

ソフトウェア分野における「goto論争」を考察したことは、「矛盾」の問題、特に「矛盾」を明確に定義するプロセスに関して、技術的な分野でのTRIZの「矛盾」の扱い方に一つの再検討のヒントを与えることになった。そのきっかけを考えると技術の世界と人の世界との扱いの違いであることに気がつく。

TRIZを使って技術分野での矛盾を突き詰めていくとき、それは一人の問題解決者 (あるいは共同の意思を持つグループ) が対立する矛盾を同時に考える形を取っていた。対立する要求が同時にあるとはいっても、なんらかの大きな目的があって、その中での要求の対立であったといえる。例えば、「コーヒーカップは、コーヒーを熱く保つためには熱くなければならないが、一方持って飲むためには冷たくなくてはならない」といった例である。このような、システムの一つの側面に関して真正面から対立するような要求であっても、それらは当然理性的に出されてきたものであって、「対立」は論理的に出てきているのである。

ところが、「goto論争」の場合には、複数の異なる立場の人々が関与していて、それぞれに要求を主張して、それが対立している。その対立は、一つの提案に対して全く反対の結論を持つから、見かけはTRIZでいう「物理的矛盾」の形を取っているが、それは論理的に突き詰めてその「矛盾」に至ったというよりも、もっと初期の段階から結論同士は真反対で対立していたと考えた方が適切であろう。だから、「物理的矛盾」の導出が、問題解決の目標地点にあるのではなく、問題解決の随分初期の段階にあるといった方が、正しいであろう。

3.3節で述べたように、TRIZの分離原理を使うための3対の質問が、問題の状況を明確にするのに役立った。それぞれの主張を、空間と時間と場合とに関して、明確化することを当事者に要求し、両者の要求を客観的に並べて比べる。各当事者が自分のものが明確になっていないという自覚ができれば、もう一段階状況の明確化を促すことが有効になる。

さらに、より上位にある共通の目的/目標を明確にすることが有効であると考えられる。そのようなものが見出されない限り、対立は続くであろう。ソフトウェア分野の場合には、関係者の立場に違いがあるといっても、ソフトウェアという技術システムを開発するという目的は共通だから、(人間や社会分野での対立に比べると) まだ対立の克服は客観的に行うことができる。

goto論争の場合に、対立する要求が、空間/時間/場合について明確になった段階で、その解決策はほとんど自明であったといえる。goto文がないとどうしても不便だという場合を限定して明示し、それぞれの場合に、構造化プログラミングの本当の基本を守りつつ、goto文に代わる自然な構文を作成・導入したのであった。

ソフトウェア分野でのこのような事例を深く考察することは、人間や社会分野の問題へのTRIZの理解の拡張の一つの前段階として、大いに有効であることが分かった。

5. おわりに

以上、この第1回では、ソフトウェア工学の初期に提唱され、その後に大きな影響を与えた「構造化プログラミング」について、TRIZの観点を加えて考察してきた。

この『ソフトウェア工学とTRIZ』という研究ノートのシリーズのねらいは、「まえがき」に書いたようにつぎの3点である。

(1) TRIZの適用分野を、特にソフトウェア関連分野に発展させ、拡張する。

(2) ソフトウェア工学にTRIZの観点を導入して、ソフトウェア工学自身をより明確にする。

(3) ソフトウェア工学/情報科学の知見を、TRIZの考え方にフィードバックする。

今回の「構造化プログラミング」を主題とした議論が、これら3つのねらいに対して、それぞれ非常に多くの有用な論点を提供し、新しい認識を要請するものであることが分かった。すなわち、『ソフトウェア工学とTRIZ』というアプローチが、ソフトウェア工学にとっても、TRIZにとっても、当初予期していた以上の新しい観点と知見をもたらすことが分かった。今後もこのアプローチを、ソフトウェア工学のさらいくつかの主題に適用して考察を深めていく計画である。

参考文献:

[1] 紫合治著: 『プログラム工学 -- 実装, 設計, 分析, テスト』, サイエンス社 (2002年10月)

[2] Darrell Mann: "Hands-On Systematic Innovation", CREAX Press, Ieper, Belgium, (2002); 中川　徹監訳, 知識創造研究グループ訳, 『TRIZ 実践と効用 (1) 体系的技術革新』, 創造開発イニシアチブ刊 (2004年6月)。[同出版案内と資料: 『ＴＲＩＺホームページ』, 2004年6月 (和・英)]

本ページの先頭

1. はじめに (構造化プログラミングとは)

2. 補足説明

3. TRIZから見る

4. TRIZへのフィードバック

5. おわりに

総合目次	新着情報	ＴＲＩＺ紹介	参考文献・関連文献	リンク集	ニュース・活動	ソフトツール	論文・技術報告集	教材・講義ノート	フォーラム	Generla Index
ホームページ	新着情報	ＴＲＩＺ紹介	参考文献・関連文献	リンク集	ニュース・活動	ソフトツール	論文・技術報告集	教材・講義ノート	フォーラム	Home Page

最終更新日 : 2004. 8.26 連絡先：　中川徹 nakagawa@utc.osaka-gu.ac.jp