解説

ソフトウェア工学
山 本 哲 男
Tetsuo YAMAMOTO

理工学部情報メディア学科准教授

Associate Professor, Department of Media Informatics

づけられており，多くの人たちにとってソフトウェ

1．はじめにアには無関心の領域でした．

2018 年 4 月に着任した情報メディア学科の山本・1968 年

哲男です．専門はソフトウェア工学と呼ばれる分野

1960 年代後半になるとコンピューターが扱う問であり，ソフトウェア開発における種々の問題点を題の複雑性化にともない，ソフトウェアの重要性が解決するために研究をしています．本稿では，その求められます．ソフトウェアを正しく動作させるた

ソフトウェア工学の解説と問題点を列挙し，読者のめにはどのようにしていかなければならないか等を今後のソフトウェア開発に生かせればと思います．

考える必要が出てきます．この時代に「ソフトウェア危機」と呼ばれる言葉が誕生しています．また，

2．ソフトウェア工学

NATO の第 1 回ソフトウェア工学会議もこの時期

他の理工系分野に比べて情報系は歴史が浅く，多くの問題が課題となっています．とりわけ，ソフトに開催され，ソフトウェアを工学的見地から考えていく時代に入ります．

ウェアに関する分野では，職人と呼ばれる一部の人つまり，ソフトウェア工学という分野が誕生したちによる開発に頼り切る傾向が見られます．ITて，まだ 50 年しかたっていません．50 年の間に以全盛時代になりつつある現代においてもこの傾向は下の様々な問題が起こっています．

なかなか改善されていません．ソフトウェア工学に［2］関しても多くの書物が出版されています［1］．まず・ソフトウェアの品質悪化，保守の対応

は，歴史を振り返りながら，ソフトウェアの位置づ・ソフトウェア技術者の不足けを見ていきたいと思います．

・障害が及ぼす社会的波及問題

2.1

これらの問題を工学として解決していこうという

歴史

・1960 年前半までのがソフトウェア工学です．そもそも，工学とは理コンピューター創世記においてはソフトウェアは論的に体系化された定理や科学的な定義や法則などハードウェアに付加されたサービス的な機能と位置を，実践的な工業技術へ結びつけることであり，既―７―

存の職人芸，その場しのぎの解決法を打開するためとは困難であり，100％ 不具合がないと言うことはの学問です．今後ますます重要となるソフトウェア出来ません．そのため，完璧なソフトウェア構築はを，いかに工学にするかがソフトウェア工学の研究不可能であり，バグを内包する製品を出荷してしま者の使命でもあります．

うことになります．もちろん，ソフトウェアの規模が大きくなるにつれて，含まれている潜在的なバグ2.2の数も多くなります．

ソフトウェアの一般的特性

ただし，インターネットの普及により，ソフトウ

本節では，ソフトウェアを見つめ直すことでソフトウェアならではの特性を述べていきます．

ェアの種類によっては不具合があること前提に出荷

1．ソフトウェアは目に見えない製品することがあり，出荷後不具合が発見された場合はハードウェアといった物理的に存在する物は人間速やかに修正版を配布するという開発も行われまの目に見え，その形や大きさが分かりますが，ソフす．

トウェアは目に見ません．もちろん，ソフトウェア

4．修正可能に関するドキュメントやソースコードは目に見えま

ハードウェアに比べてソフトウェアは変更や破棄すが，表現手法の一つであり，本質的にはソフトウが容易になります．実態がなく材料がいらないといェアは見えないものです．

う特徴から修正自体は簡単に実施できます．もちろ

そのため，ソフトウェア全貌を俯瞰的に理解する

ん，どのように修正しなければならないかは別の問ことは難しい問題がでてきます．例えば，建物の建題になります．そのため，修正や破棄が容易な事か築であれば，いまどの程度完成しているか目に見えらソフトウェアの改良や刷新が簡単な事であると勘て分かる場合がありますが，ソフトウェアの場合は違いする場合もあります．

見えませんので，いまどこまで進んでいるかを把握

5．複写可能ハードウェアと異なり製品の量産，流通コストがすることは困難です．
2．品質の劣化なし，向上していく傾向

低くなります．ソフトウェア自身の複写はいくらでソフトウェアはハードウェアと違い経年劣化といも可能ですが，ソフトウェアを配布する媒体を量産う概念が存在しません．作成後の品質は一定で何年する必要が出てきます．ただし，配布媒体もイン経過しても下がりはしません．もちろん，不具合はターネットの普及により低コスト化してきており，存在しますが，その不具合を修正することで品質は物理的な商品の流通網を利用することなく，配布が向上していく傾向にあります．劣化しないというこ可能になります．ただし，これらは違法コピーを容とは，一度導入すると，永遠に利用できる可能性が易にしてしまうという危険性につながり難しい問題あるということです．もちろん，社会情勢の変化等となっています．しかし，ソフトウェアのコピーがによりソフトウェアが使い物にならない場合はあり容易であるということは，新規に開発する際にソフますが，そうでない場合はソフトウェアのライフサトウェアの再利用化を促進させる面もあり，一概にイクルはハードウェアに比べ長くなります．

複写出来ないようにすることは避けなければなりま

3．潜在的バグが潜んでいるせん．

ソフトウェア開発は機械を用いて作成する工程は6．要求される機能は社会情勢とともに絶えず変化すくなく，人手の作業による作成がほとんどです．

ソフトウェアに求められる機能拡張，性能改善，そのため，開発者の能力に依存する傾向が高く，潜環境適合に関する要求が当たり前となり，常にソフ在的な不具合を含む可能性が高くなります．不具合

トウェアが進化できる状態で開発しておかなければがないソフトウェアかどうかを定量的に評価するこなりません．例えば，税金に関するソフトウェアの―８―場合，税率や仕組みが変わる前提でソフトウェアを2.3

よいソフトウェア構築しておく必要があり，そのように開発をしておそれでは，良いソフトウェアはどのようなソフトくべきです．つまり，ソフトウェア進化が前提な開ウェアなのでしょうか．以下に説明していきます．

発をすることが求められています．

1．ユーザの要求仕様が正しく反映されているソフ

7．波及効果が分かりにくい

トウェア

ソフトウェアのある箇所を変更すれば，他の部分どんなに高度な技術を駆使して作成されたソフトに新しいバグが作り込まれる可能性も大いにありま

ウェアでも，ユーザニーズを満足していなければ価す．その多くの原因は，あいまいな仕様，構造化さ値効果がありません．ユーザのニーズをいかに正しれていない設計によるものですが，本質的にソフトく形式化し，ソフトウェアとして構成できるかがポ

ウェアは複雑であり，修正箇所からの影響波及が多イントになります．

岐にわたります．さらに，この波及した箇所の特定

2．潜在的なバグが少ないソフトウェアが困難であるため，ソフトウェアの大幅な修正を困開発の初期の段階から極力不具合を少なくすると難なものとしています．動作しているソフトウェアいう方策があるソフトウェアが良いソフトウェアにの改善をすることで，新たな不具合が生まれてしまなります．開発体制や各開発工程（ソフトウェアプうのもそのためです．

ロセス）が事前に定義してあり，その通り実施でき

8．バグは本人より第三者のほうが見つけやすい

る場合は不具合が少なくなる傾向にあります．ソフ

ソフトウェア開発者の多くは，自分がコーディン

トウェアのテスト工程においても，ある基準に従いグしたプログラムに完璧さを望んでおり，エラーがテストを実施し信頼度を高める必要があります．

ないよう心がけてきた心理的安心感とプライドを持

3．見積もりコスト以内のソフトウェアっています．そのため，思い込みがあり不具合が発

商用ソフトウェアにおける重要な要素として開発生せいた場合もその修正箇所の特定に時間がかかるコストが上げられます．開発コストとは単純に考え場合が多いです．第三者の開発者の方が発見を短時るならば，開発人数と開発日数の積で求まる値にな間に行える場合もあり，テストや不具合修正行程をります．もちろん，開発コストを費やせば費やすほ

どのような体制で実施するかは難しい点となってい

どよいソフトウェアができる可能性がありますが，ます．

ソフトウェアの規模と機能内容の複雑さに対して，9．作成者の思想適切なコストを設定しなければ商売として成り立ちソフトウェア自体が複雑なものであり，また，そません．想定された見積もり工数内のコストでソフの構築には様々な方法があります．多くのソフトウトウェアが完成し，納期内に開発が完了することがェアは，人間のノウハウ，経験，技能，考え方などよいソフトウェアと言えます．に依存した部分が多く作成者しか解読できない場合

4．運用，保守が容易も多く存在します．開発者が 10 人いれば，10 通り要求仕様通りの機能が実現出来ているソフトウェの実現方法が存在し，同様に動作するソフトウェアアでも，運用しやすいソフトウェアであることや利も中身は全く異なる事があります．つまり，ソフト用が簡単であることがよいソフトウェアと考えられウェアを構築する過程に置いて，その制作者の思想ます．運用・保守も含めて考えられたソフトウェアが反映されるため，他人の作成したソフトウェアのを構築することが求められています．不具合が存在読解が困難となるため，作成者がいなければ変更がしないソフトウェアを作成することが困難な状況で出来ないという状況が生まれます．

あるため，障害回復がしやすいソフトウェアを開発することが重要になってきています．
―９―

5．安全性が高いことする必要があり，場合によっては，操作に必要なチソフトウェアにおけるセキュリティ対策を実施しているかも重要な要素となります．重要なデータを扱う場合の機密保護対策や障害が発生した場合の安ュートリアルを作成する必要も生じます．

3．ソフトウェア開発における問題点
ソフトウェア開発を取り巻く環境の変化は速く，全対策を事前に組み込んでいるソフトウェアはよい

世の中で提案・実施されている開発手法や技術は絶ソフトウェアと言えます．
さらに，一昔前と現在では「よい」という観点がえず進化し続けています．数年前の技術が過去の物変化してきています．例えば，コンピューターのということはよくあることです．常に新しい技術がCPU やメモリといったリソースが高価で性能の低提供される一方で，ソフトウェアを発注する顧客のい時代においては，処理効率性が求められていまし要望は日々高くなっています．開発コストの増大やた．処理効率を求める箇所では，アセンブリ言語とソフトウェアの複雑化に伴い，当初の計画通りに完呼ばれる低級言語でソフトウェアの記述を行うこと了しないことも多々見られます．まだまだ人間に依が多くありました．計算時間効率を高めるために，存している部分が多く，決定打となる解決方法は見ファイルやデータベースへのアクセス時間の短縮化

つかりません．ソフトウェアに開発に「銀の弾丸」や処理手順の最適化し，資源効率を求めるために，は存在しません［3］．

CPU やメモリやディスクを効果的に利用するソフ

また，そもそも「何をすべきか」を決めることがトウェアを作成する必要がありました．また，プロ非常に困難なソフトウェア開発の中で，高度な IT

グラム の 保 存 領 域 の 圧 縮，プ ロ グ ラ ム 実 行 時 の技術者不足から多段下請け構造に走っているソフト

CPU メモリ領域の最適化といった，ソフトウェアウェア開発の世界にも問題があります．これには，の本質的なでない処理に時間をかけていました．

ソフトウェアの本質的な難しさビジネス構造上の問

しかしながら，現在のソフトウェア開発では理解題があります．情報系以外の他の工学分野において容易性を求める傾向にあります．ソフトウェアを管は，これまでの経験と研究成果からやるべきことが理する工程では，わかりやすさが第一に要求しま明確になっており，それをいかに達成するかというす．複雑なソフトウェアを長期に渡って管理維持し視点から実施され，それだけの基盤ができていまていくためには，多大な労力と経費が費やされるたす．しかし，ソフトウェアは何をどこまでやるかのめ，構成や設計構造が分かりやすいソフトウェアが合意形成を関係者間で取ることが本質的に困難な状よいソフトウェアになります．第三者が見ても理解況です．それは，人間が本来持っている曖昧な部分しやすいよう作成することが重要な課題です．まとソフトウェア開発等に必要な明確な部分とのギャた，検査がしやすいソフトウェアを目指すことも重ップが原因と考えられます．この本質的な問題が常要になってきています．品質検査は必須な工程であに存在し，この解決を図るために様々なソフトウェり，見やすくわかりやすいソフトウェア記述であるア工学の試みがあります．

ことや部品化が行われ機能の独立性が保たれている

ソフトウェア開発プロジェクトの実態を風刺した

ことが現代のソフトウェアにとっては重要な要素と有名な画像があります．図 1 にその風刺画を示しまなります．さらに，高品質のドキュメントがあるこす．とも重要になりますが，ドキュメントがなくとも利用できるソフトウェアの方が望ましくなってきています．
人間の直感的に分かりやすいソフトウェアを作成― １０ ―

図1

顧客が本当に欲しかった物（http : //www.projectcartoon.com/cartoon/ より引用）

・アナリストのデザイン

図の左上の図から説明していきます．

アナリストが分析した結果のデザインになりま・顧客が説明した要件
顧客自身がソフトウェア開発担当者に言った説明

す．になります．もしくは担当者が聞き出した結果にな

機能的にはブランコという点は満たすようになりります．この段階では板のブランコが欲しいというましたが，半ば強引にブランコに仕上げた状態にな要求と見て取れます．ただし，よく絵を見るとブラっています．要求から振り返らず，都合良く改変しンコにしては板の枚数が多く，乗りにくい気もしまたものと考えられます．

す．

・プログラマのコード
確かに「木の板」木に付けられてブランコのようこの段階ですでにずれているというところでしょうか．

なものに仕上がっています．その点では間違っては・プロジェクトリーダの理解いませんが，そもそも機能要求を満たしているのか聞き出した要求をプロジェクトリーダーが理解しと考えると満たしていない事になります．なんとかた図です．たしかに形はブランコになっています

作成はしたが，まったく使い物にならないというこが，木の幹が邪魔をしてこげない状態になっていまとを表しています．

す．プロジェクトリーダーは表面上の要求を理解し・営業の表現，約束往々にして営業は過大な表現を顧客に説明して仕ますが，その中身まで深く考えないことが見て取れます．

事を取ってきます．その様子を表す一枚になっています．自分の所でソフトウェアを開発してもらえる― １１ ―と，こんなにも素晴らしい物が出来ますよというア

4.1

マイヤーズの三角形問題

マイヤーズの三角形問題とは，「ソフトウェアをピールをするということです．

テストするのに十分と思われる一連のテストケース

・プロジェクトの書類（ドキュメント）ドキュメント化の状態を表しています．そんなも（すなわち十分なデータのセット）を書いてくださのはまったく存在せず，後回しにした結果，結局作

い．このソフトウェアは 3 つの整数を入力とし，こ成されていないとうことです．の 3 つの値はそれぞれ三角形の 3 辺の長さを表すも・実装された運用のとする．ソフトウェアは三角形が不等辺三角形・結局木の枝にロープが付いた状態までしか実装されておらず，ブランコとして運用はできていない状

二等辺三角形・正三角形のうちどれであるかを決めるメッセージを出力する」という問題です．

態を表しています．

さて，このソフトウェアが不具合なく動作するこ・顧客への請求金額とをテストするためには，どの程度の入力を考えて開発を重ねた結果，最終的にはジェットコーステストしていかなければならないのでしょうか．以ターが作れる程度の金額だった事を表しています．

下にその解答例を列挙していきます．なお，3 辺の多くの時間と人件費がかかり，請求が膨大になって入力をそれぞれ A, B, C として説明していきます．

しまうことが見てとれます．

1 ．有効な不等辺三角形として成立するかのテスト（A と B と C がすべて異なるとき）・得られたサポート
作成したソフトウェアに対して実際に得られるサポートはこの程度であることを表しています．ほと例 ［A＝3, B＝4, C＝5］2 ．有効な正三角形として成立するかのテスト（A＝B＝C のとき）

んどサポートが得られない状態です．

例 ［A＝1, B＝1, C＝1］

・顧客が本当に欲しかった物
実は顧客が本当に欲しかった物は，木の枝にロー3 ．有効な二等辺三角形として成立するかのテスト

プを下げて，その先にタイヤが付いているものが欲（A と B が同じとき）しかったというオチです．木のブランコ程のもので例 ［A＝2, B＝2, C＝3］はなく，タイヤで十分だったということです．これ

4 ．有効な二等辺三角形として成立し，2 つの等辺は，顧客自身も何が欲しいのかうまく伝えられないを含む 3 種類の組み合わせのテスト（A＝B, B事を意味しており非常に重要な観点となっていま＝C, C＝A のとき］
例 ［A＝3, B＝3, C＝4］［A＝3, B＝4, C＝3］［Aす．

＝4, B＝3, C＝3］

顧客自身もそもそもの要求を理解しておらず，その要求を使える時点で待ち上がっており，その後，

5 ．入力した項目が 0 の場合のテスト
例 ［A＝0, B＝3, C＝4

多くの関係者にその要求が伝わる中で，各担当者の他 1 つが 0 の場 合 の 3パターン］［A＝0, B＝0, C＝1

理解のずれやスキル不足等から全く異なるものが出

他 2 つが 0 の場合の 3 パターン］

来上がってしまうという問題を表現しています．

6 ．入力した項目がマイナスの場合のテスト（入力4．ソフトウェアテストにおける問題点が整数であるためマイナスも考慮してテストす

次にソフトウェアの具体的な難しさを説明するたる必要がある）
例 ［A＝−1, B＝3, C＝4めにテスト工程の例を挙げて説明します．テストの他 1 つがマイナスの［4］底で有名な話として「マイヤーズの三角形問題」

場合の 3 パターン］［A＝−1, B＝−1, C＝1というものがあり，その例を用いたいと思います．

他 2 つがマイナスの場合の 3 パターン］［A― １２ ―つ が 空 欄 の 場 合 3 パ タ ー ン］，［A が 空，B＝−1, B＝−1, C＝−1］
7 ．全ての項目が 0 を超える整数だが 2 つの項目の和が残りの 1 つの項目と等しい場合のテストが空，C が空］
14．13 種類のテストパターンを試さなければならない（A＋B＝C のとき）
例 ［A＝1, B＝2, C＝3］

また，入力した値に対して期待される表示結果と8 ．「7」の項目において 3 種類の組み合わせのテス実際の表示結果が合っているかも必要になってきます．

ト
例 ［A＝1, B＝2, C＝3］［A＝1, B＝3, C＝2］［A＝3, B＝2, C＝1］以上のように三角形の状態を確認するだけの問題においてもいくつものテストケースを準備して検証

9 ．全ての項目が 0 を超える整数だが 2 つの項目のしなければなりません．どこでミスを犯しているか和が残り 1 つの項目より小さい場合のテスト

事前には分からないため，様々なパターンを準備し（A＋B＜C のとき）てテストをする必要があります．

例 ［A＝1, B＝2, C＝4］
10．「9」の項目において 3 種類の組み合わせのテス

5．おわりにト（A＋B＜C, B＋C＜A, C＋A＜B）

ソフトウェア開発の特性やソフトウェア開発にお例 ［A＝1, B＝2, C＝4］，［A＝1, B＝4, C＝2］，［A＝4, B＝2, C＝1］

ける問題点を説明してきました．今後，皆さんがソフトウェア開発にたずさわる場面になりましたら，11．全ての項目が 0 の場合の テ ス ト（A＝B＝C＝0）

少し立ち止どまり，これらの事について今一度考えてみてはいかがでしょうか．ますます高度かつ複雑

例 ［A＝0, B＝0, C＝0］ 0 のテストは特別視す化する情報化社会において，ソフトウェアの重要度べき項目であり，必ずテストする必要がありが増していくのは間違いありません．ソフトウェア

ます．なぜなら，ソフトウェア内部の判定箇

エンジニアを目指す際は，よりよいソフトウェアの所で 0 を含めるか復命内科の判定は人間が間開発を目指していただければ幸いです．

違えやすい点の一つです．
12．半角数字の整数ではない値が入力されている場
合のテスト（整数以外が強引に入力されたと

参考文献［ 1 ］ シャリ・ローレンス

学−理 論 と 実 践，ピ ア ソ ン エ デ ュ ケ ー シ ョ ン，き）例 ［小数点，制御コード，半角／全角スペース，2001.
［ 2 ］ ロジャー S. プレスマン，実践ソフトウェアエンジ

半角／全角英大小文字，半角／全角カナ，全角数字，かな，漢字等］

Jr.，人月の神話，

丸善出版，2014.

他 1 つが空欄の場合

3 パターン］，［A が空，B が空，C＝1

ニアリング，日科技連出版社，2005.
［ 3 ］ フレデリック・P・ブルックス

13．入力されている値が 3 個に満たない場合
例 ［A が空，B＝3, C＝4

プリーガー，ソフトウェア工［ 4 ］ マイヤーズ，J.，ソフトウェア・テストの技法，近他2― １３ ―

代科学社，2006.