【本】確かに、ずっと受けたかったかも知れない授業

　コンピュータ・サイエンスではなく、ソフトウェア・エンジニアリング。
　「IT系企業で働いてみたいなー」と考えている学生さんにオススメしたい、「実際のソフトウェア開発ってどういうことをするの？」ってことがよくわかる1冊。

ずっと受けたかったソフトウェアエンジニアリングの授業1 増補改訂版

ずっと受けたかったソフトウェアエンジニアリングの授業2 増補改訂版

　学者・研究者ではなく、実際に開発に携わった現場の方が書いているだけあって、抽象論・一般論に留まりません。
　たとえば、各テスト工程におえるテスト項目数の目安を、

図6.13　単体テストのテスト項目の作成方法
項目数の目安は、経験的におよそソースコードの行数の1/5程度である。
図7.5　結合テストのテスト項目作成方法
項目数の目安は、経験的におよそソースコードの行数の1/20程度である。

と言い切ってしまいます。
　多くのプロジェクトはこれらの基準を、自分の組織の経験知を元に定めていることでしょう。もちろん一意には決まらないのですが、「ざっくりいえば、こんなもんですよ」と言い放った本書はスゴイと思います。

　『授業1』は、「ソフトウェアとソフトウェアエンジニアリングとは」という概説に始まり、「プロセス」という言葉の意味や、提案書・計画書の書き方を経て、設計工程の解説へ。
　概説では、1990年には300ks程度だった携帯電話のプログラム規模が、200年には5Mstepを超えているといった例とともに、ソフトウェアが世界に与える影響の大きさが語られます。5Mstepといえば、500万行。1kstepをA4用紙30枚くらいとすると、実にA4用紙15万枚。アマゾンの森林が危ない・・・。

　『授業2』は、内部設計からテストの終わりまで。これに加えて、プロジェクトマネジメント、産業全体についての概観、オフショア開発、ITSSなどへの幅広い言及があります。
　つまり、提案→要件定義→設計→実装→テストという一般的な開発の流れと、それを統括するプロジェクトマネジメントが一通りわかることになります。触れられていないのは、保守の話くらいでしょうか。

　ところで本書で、A.P.Ershovが1972年に発表したという「プログラミングに必要な才能」が掲げられています。

• 第一級の数学者の論理性
• エジソンのような工学の才能
• 銀行員の正確さ
• 推理作家の発想力
• ビジネスマンの実務性
• 協同作業をいとわず、経営的な関心も理解する性向

　わたしがプログラミングに向いていないことだけはよくわかりました。

　なお、「授業」と銘打っているだけあって、突然、仮想学生との問答が始まります。

先生　スタブ、ドライバはわかりますか？
学生　聞いたことはありません。
◆◆◆
先生　みなさんが学生生活をしている中で、プロジェクトに参加したことはありますか？
学生　わかりません。
◆◆◆
先生　時間は資源の1つです。あとは何がありますか？
学生　わかりません。
◆◆◆
先生　プロジェクトを行っているときには、どういうリスクがあると思いますか？
学生　わかりません。

　・・・学・・・生・・・・・？