ソフトウェア工学 知能情報学部 新田直也
先週ネット上で広がった話題
みずほ銀行次期システムの破綻 4000億円の損失 20万人月（クフ王のピラミッド建造と同規模!!） 日立，IBM，NTTデータ，富士通が1次受け． 7次受けは時給910円． 問題の本質は? 開発体制 顧客 組織 人員 見積り 技術
ソフトウェア開発の大規模化 カーナビ 300～500万行 原子力制御 600万行 レクサス 700万行 携帯電話 1200万行 カーナビ 300～500万行 原子力制御 600万行 レクサス 700万行 携帯電話 1200万行 スペースシャトル 2560万行 メガバンク勘定系 システム 2000～6000万行 Windows XP 4000万行 Windows Vista 5000万行 Windows 7 1億行
大規模ソフトウェア開発の現状 全開発プロジェクトの約1/3が途中で中止，残る2/3が予算の倍の経費と時間で何とか完成． ある調査では，2009年度の全世界におけるプロジェクト失敗による損失は6兆ドル!! ソフトウェア危機は解決されていない．
ソフトウェア工学は何をしてきたのか? 本質的な問題はまだ解決されていない． 狼人間を撃つ銀の弾は未だ見つかっていない． 複雑性： 大きさの割には他のどの人工構造物より複雑．（似た部分が少ない．） 同調性： ハードウェア，人間の習慣，社会制度などの環境に順応させなければならない． 可変性： 頻繁に変更を要求される． 不可視性： 目に見えない． 狼人間を撃つ銀の弾は未だ見つかっていない．
アジャイル開発はどうか? 優秀な技術者が必要． 中，小規模開発では成功． 少しずつ機能を付け足しながら，動くソフトウェアを改良していく． 設計も必要に応じて改良していく．（リファクタリング） 機能が増えてきても大丈夫か? 最初の方に加えた機能と後で加える機能が競合してしまう場合どうすればよいか? 後から大規模な設計変更はできない． 全体の設計は最初から慎重に行わなければならない．
再利用はどうか? オブジェクト指向は再利用のための技術． アプリケーションフレームワーク： 構造化指向ではライブラリ単位で部品を再利用． オブジェクト指向ではフレームワーク単位で全体設計を再利用． アプリケーションフレームワーク： 親クラス（抽象クラス）の集合． 多相性によってフレームワーク側からアプリケーション側が呼び出される（制御の反転）． ハリウッドの原則：「俺に電話するな．必要ならこちらから電話する．」 アプリケーション ライブラリ アプリケーション フレームワーク
再利用の現状 フレームワークは一定の成果を生んでいる． ただし，最初から良いフレームワークを設計することは困難． たとえ良いフレームワークを開発できたとしても，開発者以外がそれをうまく再利用することは困難． 再利用の方法が複雑． 適用可能範囲が複雑．
複雑性への対処 ソフトウェアの複雑性への対処ができていないことが本質的な問題． 大規模で複雑なソフトウェアを適切に抽象化し管理する技術が確立されていない． 構造化指向もオブジェクト指向も抽象化の技術． 複雑すぎて事前に適切な抽象化を行うことができない． 開発が進んだ段階で適切な抽象化を思いついたとしても手遅れ． 適切に抽象化されていないソフトウェアは再利用できない．
まとめのまとめ 結局，特効薬（銀の弾丸）はまだ存在しない． 技術の地道な積み重ねによってのみ発展する? → 新しい技術をチェックしておくこと． ただし，ソフトウェア工学分野には使えない技術も多いので注意が必要． 「ここが明るくて探しやすいからですよ。」 現段階では人（特に技術者）だけが頼り． 失敗の経験をすること． 後で楽できるように今苦労しておくこと． チームワークが大事．