ネットで学ぶソフトウェア工学

もくじ

ソフトウェア工学一般 デスマーチ

仕様記述 ソフトウェア設計 実装、プログラミング ソフトウェアテスト

プロジェクト管理 工数見積もり 外注開発 アジャイルソフトウェア開発 メトリクス

ソフトウェア工学学会 ソフトウェア工学研究機関 ソフトウェア工学よみもの ツール プログラミング言語チュートリアル

前文:ソフトウェア工学って、なんでしょう?

Wikipediaによると、
ソフトウェア工学は、コンピュータのプログラム、およびその作成行為であるプログラミングを対象とした工学である。
お行儀がよい説明ですが客観的過ぎてぐっと来ない説明です。
ソフトウェア工学とは (主に学部生を対象とした説明) - Kusumoto Laboratoryによると、
品質の高いソフトウェアを低コストで期限通りに開発し,効率よく保守するためのさまざまな技術を扱う学問分野
こちらはわかりやすい。品質よく、低コスト、期限通りにを全て同時に達成するのは難しいものです。
参考になるソフトウェア工学のまとまったリンク集が存在しないのででソフトウェア工学のリンク集を作ってみました。

ソフトウェア工学は知識だけでは足りないし、開発経験だけでも足りない。
ソフトウェア工学の実践すべき場所は、とても忙しい場所だろう。そんな忙しいところで、ソフトウェア工学を学べるだろうか。
ソフトウェア工学を学んだ人がその忙しい場所に行けばいいのか? そこの人じゃなくても、たとえば、コンサルタントでも、ソフトウェア工学は実践できるのか。指導すればいいのか。
ソフトウェア工学は知識だけではない。ソフトウェア工学は経験だけでも足りない。

ソフトウェア工学の名前はあまり聞かなくなってしまった。いや、昔から聞かないかも。Googleが優秀な開発者を高額な報酬で集めた。そこにはGoogleのソフトウェア工学があった。従来のソフトウェア工学とは違ってみえる。 思えば、いつもソフトウェア工学の技術を輸入してきた。他のITでも同じだが。オブジェクト指向、アジャイル、プログラミング言語、データベース。日本はフォロワーなんですかね。まあいい。フォロワーならフォロワーであることを認め、よいソフトウェア工学は取り入れよう。 そして今、日本のソフト開発は、後ろを走っていると思っていた後続者たちにも追いつかれて追い抜かれている。日本のソフトウェア開発は迅速と言えるだろうか?品質は良いといえるだろうか?開発コストが安いといえるだろうか?  他の国と比べて、何も優位でないなら、ソフトウェア開発をする価値はあるだろうか?その国でソフトウェア工学は学ぶ価値は?  ソフトウェア開発にとって、ソフトウェア工学の研究、勉強は重要だろうか?

 しかし、ソフトウェア開発は人類にとってまだ十分なレベルにないのも事実だろう。いたるところで不具合が明らかになる。ソフトウェア開発の残業は多く存在するうだろう。 まずは勉強から。真剣にソフトウェア工学に取り組んだなら、その先に今はまだソフトウェア工学になっていないソフトウェア工学がある。 これは、ネットで読める、ソフトウェア工学文書のリンク集です。


twitter(ソフト工学のくつろぐ部屋)
ブログ(ソフトウェア工学なんて忘れて)
『プログラマのためのWEB』に戻る


ソフトウェア工学

ソフトウェア工学の基礎(PDF)
東京大学から法政大学に移られた玉井哲雄先生のソフトウェア工学のまとまったPDF文書。いいですね。
『ソフトウェア工学の基礎』はよい日本語のソフトウェア工学の教科書。PDFは、この元ネタでしょう。この教科書はよくまとまっていると思います。ソフトウェア工学を学ぶなら、一冊良い本を持つとよい。日本語で選ぶなら、基本に忠実であり、大御所が執筆しているし、格調の高さから言ってもこの本だろう。スタンダードと呼びたい。
ずっと受けたかったソフトウェアエンジニアリングの授業
ソフトウェア工学の教科書。こちらがとっつきやすい人もいるかも。
SOFTWARE ENGINEERING 9
わたしの持っているソフトウェア工学の教科書の最新版。公開スライドあり。なかなかいい本。英語。
Top 10 SW Engineering Concepts, V13
Ed Yourdonによる。日本語訳:ソフトウェア工学で最も大切な10の考え方
従来のソフトウェア工学が決定的に間違っている点 - kなんとかの日記
従来のソフトウェア工学は、属人性を排除して開発者の能力を均一化しようとしている。この点に置いて、従来のソフトウェア工学は決定的に間違っている。
と主張。たしかに属人性を認めて、開発者の個性を伸ばす、というスタンスもあるかもしれない。ソフトウェア工学は20世紀の学問だった。20世紀は大量生産、大量消費の時代だから、均一な労働力を必要とした。だから、属人性を排除しようとしたのだ。しかし、個性や能力差を考慮した開発体制のほうが良い可能性が高い。なぜなら、細やかだということだからだ。そして、そっちのほうが楽しい。しかし、能力のない開発者がいる場合、まず能力を並に底上げが必要だろう。それは属人性の排除とは違う。
Google のソフトウェア・エンジニアリング
ソフトウェアエンジニアが信用されている状況でのソフトウェア工学。エンジニアによる会社だからだな。エンジニアは管理する対象ではない、というところがいい。エンジニアが信用されていない会社では、軍隊や学校のようにルールでがんじがらめになる。
Classic Programmer Paintings
プログラマやソフト開発、ソフトウェア工学的な状況が歴史の中で描かれてきました。その紹介。というかパロディ。
残業プログラマのためのスキルアップリンク集
正攻法でソフトウェア開発力を向上させるリンク集。成長のためには努力と犠牲が必要だ。

デスマーチ

デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか
古典。デスマーチ - Wikipediaに内容の説明がある。
ヨードンは、その著書『デスマーチ:なぜソフトウエア・プロジェクトは混乱するのか』で、デスマーチの定義を「プロジェクトのパラメータが正常値を50%以上超過したもの」もしくは「公正かつ客観的にプロジェクトのリスク分析(技術的要因の分析、人員の解析、法的分析、政治的要因の分析を含む)をした場合、失敗する確率が50%を超えるもの」としており、具体的には以下のいずれかに該当するものと定めている。
古典。現代的に再定義したほうがよい。
夜20時以降の残業後に心臓発作による死亡した事例を知っている。デスマーチでは毎日深夜残業になり体力の限界まで働くことになる。体調に異変があってもおかしくない状況だ。睡眠不足や心労は命に関わる。ソフトウェア開発者への影響や体調の変化は不可視だ。ソフトウェア開発プロジェクトの状況の悪化も気づきにくい。デスマーチへの対策はソフトウェア工学の本務のはずだ。
カプコンに学ぶデスマーチにならない仕事術
デスマーチを避ける方法は一つではない。いろんな失敗を全てしなかったときだけ、デスマーチは避けられるのではないか?
デスマーチを回避するのに大事な“3つのこと” - @IT情報マネジメント
「コミュニケーションの肝は勇気を持って“なあなあ”をやめること」はいいこと言ってるみたい。最後に「重要なのはPMBOKに肉付けすること」p
プロジェクト管理者が1人でできるデスマーチ・プロジェクトの対処法
冷静な記事。見積もりなおして、必要ない機能は捨てる。これだけでうまくいくかは疑問だ。見積もりは難しい。これで解決するなら、最初から見積もり、デスマーチにならないはず。
デスマーチとは (デスマーチとは) [単語記事] - ニコニコ大百科
ニコニコのほうが、wikipediaよりリアルな説明だ
ほんとにヤバくなってギリギリになるまで相談しない人々
そういう組織は、人が内部から壊れていく。鬱になったり、病気になったりする。まあ、発展性のない業務に長時間据えられて、強いストレスに晒されながら安い給料で働くわけだからねえ。一個一個のデスマーチは、マーチである限り終わりはあるわけだけど、デスマーチは仕事の様態ではなく企業の仕事のとり方に起因するから、その業界や企業や経営者の考えが変わらない限りチェーン状に無限連鎖になってる。
たしかに、仕事のとり方が重要だ。例えば、仕事量が未定のまま、仕事を受けるとか、見積もりが甘ければ、慢性的なデスマーチになるだろう。
デスマーチ大作戦 - YouTube
レコード一個の追加が大変って、プログラムもうよくわからんことになってるでしょ!

仕様記述

[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?
USDMによる仕様記述の本。知り合いからきいたところ、内容はよい。しかし著者の本は難読とのこと。内容紹介によると以下。
好評既刊の改訂第2版。開発の根本であり工程すべてに関わってくる「要求の仕様化」について、その重要性からじっくりと解説。「要求」とは何か「仕様」とは何かという本質から説き、仕様書作りの考え方や表現方法を具体的に提示します。第1版では、要求を表現する際に「振る舞い」に注目し、分割・階層化により振る舞いの範囲を狭くして仕様漏れをなくしていく方法を提唱しました。第2版ではその方法論をさらに深め、上位要求の表現や分割・階層化したときの下位層の要求を表現する際に「動詞」を意識する視点を全面的に打ち出しています。
USDMを活用した要件定義の改善
適用例。UMLのユースケースもそうだが、フォーマットを決めることは、それぞれの設計者が記法をばらばらに考える手間を省ける。これは実に大きい。
「派生開発」を成功させるプロセス改善の技術と極意
内容紹介より。
ロングセラー『[入門+実践]要求を仕様化する技術・表現する技術』の著者が渾身の力で放つ第2弾がいよいよ登場! 開発現場のほとんどはいわゆる「派生開発」です。そしてトラブルが頻発する「派生開発」の現状を改善するために、著者自身が現場で長く培ってきた方法論をまとめあげました。この派生開発プロセスにより、確実にプロジェクトを成功させることができます。本書でその真髄に触れ、「派生開発」のあり方を探求し失敗のない「派生開発」を目指してください。現場で抱える問題の解決に必ず役立つ、「定番」となる一冊です。
内容(「BOOK」データベースより)
いつまで「派生開発」で疲労し続けますか?派生開発にはそれに適したプロセスがある!合理的なプロセスと成果物で構成された「XDDP」でデスマーチから脱却を!確実に派生開発プロジェクトを成功させる実践的方法論の登場。
XDDPという派生開発プロセスをまとめ上げたのがすごい。プロセスと成果物の流れを定義するPFD(プロセスフローダイアグラム)や改造内容と改造部位トレーサビリティマトリックスという記法を利用する。
Z言語 - Wikipedia
仕様を記述する言語の一つ。
Z言語 (ぜっどげんご) は、Z記法 (ぜっどきほう) ともいい、形式仕様記述言語であり、コンピュータシステムの記述とモデリングを行うために使われる。 ZはZF集合論から名前をとって命名された。
数学的記法で定義される。集合で定義したいときに使える。
B-Method - Wikipedia
これも仕様記述言語。
Z言語に比較して抽象化レベルが低く、単なる形式仕様記述というよりもコードへの詳細化に重きを置いている。そのため、B で書かれた仕様はZ言語の場合よりも実装が容易である。
Bメソッドによる形式仕様記述―ソフトウェアシステムのモデル化とその検証 (トップエスイー実践講座)
Bメソッドの解説書。とっつきやすいだろう。Bメソッドの特徴は、仕様から実装へ段階的に詳細かしていく点です。
プログラム仕様記述論 (IT Text)
ホーア論理、Z、VDM等、全体感がうすく分かる感じの入門書かな。未読。
Event-B: リファインメント・モデリングに基づく形式手法
Event-BはBメソッドをもとにした言語で、並行性やリアクティブ性に対応したようです。

ソフトウェア設計

独習UML
UMLは設計記法の統一規格。設計記法がバラバラなプロジェクトだと、図の意味の説明に時間がかかる。また、設計者も表現の仕方の検討に時間がかかる。しかも、既に先人に考えれた記法があるのだから、それを学び利用すれば、随分楽になる。
独習シリーズは、厚いが、よくまとまっている感じがする。この『独習UML』と『独習C++』がよい。
UMLチュートリアル オージス総研
丁寧なチュートリアルがある。
フローチャートがダメな3つの理由
悪い点は、人の思考を表現するほどの表現力が無い点、いい点は、表現力を犠牲にして、わかりやすい点。ダメだと言っても、設計書がないより、全くマシだよな。
アジャイルモデルのエッセンス: アジャイルに作れる成果物
UML図の説明あり。オージス総研による、http://www.agilemodeling.com/の翻訳のようだ。ページの対応関係が不明。
オブジェクト指向における再利用のためのデザインパターン
GoF本として有名。オブジェクト指向やるなら、これを抑えておくとよい。でも難しい。オブジェクト指向って秘伝の技術みたいになる嫌いがあるが、それは他の技術でも同じか。各種流派の独特な言葉に惑わされないことが重要と思う。オブジェクトはインターフェースつきのデータに過ぎないと思う。それはそれで重要なことだが。
増補改訂版Java言語で学ぶデザインパターン入門
GoF本は難しいので、結城浩の入門はこちらがおすすめ。
Why OO Sucks by Joe Armstrong
『なぜオブジェクト指向はだめなのか?』なぜ、オブジェクト指向がポピュラーなのか。理由を挙げている。「Reason 1 - It was thought to be easy to learn.Reason 2 - It was thought to make code reuse easier.Reason 3 - It was hyped.Reason 4 - It created a new software industry.」みんなの反応:Twitter Trackbacks for Why OO Sucks by Joe Armstrong [cat-v.org] on Topsy.com Matzにっき(2007-04-12)

実装、プログラミング

CODE COMPLETE 第2版 上 完全なプログラミングを目指して
コーディングは仕事で初めて実践的な経験を得られるが、それでは効率がわるい。また師匠や同僚のアドバイスはその人独自のものである。本書では、実際の例を見ながら、効率よく実践的なノウハウが得られる。
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
意図のわからないコードは本当に読むのに苦労する。捨ててしまったほうがいい場合もある。そんな不良資産のソフトウェアを作らないための指南書。
新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)
リファクタリングとはプログラムの外部から観察できる振る舞いを変化させず、内部を改善することだ。本書は、リファクタリングの基本的文献。
スパゲティプログラム - Wikipedia
スパゲティプログラムは、設計と実装のどちらを失敗しても発生するだろう。それだけ起こりやすい現象だ。危険性の一つの指標としては構造の質を上げてもいいだろう。しかし、保守性の低いプログラムはスパゲティプログラムだけではない。見た目は良さそうだが、保守性の低いプログラムは存在する。例えば、変数の用途が不明なものなど。そもそも大規模なプログラムはそれだけで、保守は困難になる。スパゲティプログラムは初歩的な問題だが、さらに一見大丈夫なプログラムの保守も課題がある。

ソフトウェアテスト

『マインドマップから始めるソフトウェアテスト』
テスト計画とかなんでもマインドマップでやろうという感じです。テスト初心者にはまあいいのかな。レビューが大事だという趣旨。
知っておきたいテストの“イロハ” ITpro
C0網羅(命令網羅),C1網羅(分岐網羅),C2網羅(条件網羅)の解説図。定義がいろいろ異なるが。
Modified Condition/Decision Coverage - Wikipedia, the free encyclopedia
テストカバレッジの基準、Modified Condition/Decision Coverage (MC/DC)。 ソフトウェア品質技術の開発と適用に日本語の説明がある。
直交表、MCDC、GAで現実的な網羅
MCDCの詳しい説明あり。CATS。
Pairwise Testing
ペアワイズテストのツールがいっぱい載ってます。MicrosoftのPictも。
HAYST法
HATST法、これもペアワイズテスト技法のひとつかな。本買って、勉強したけど、理解できてない。ペアワイズテストについては、All-pairs testing - Wikipediaをみてください。日本語ない。
Tom Gilb & Kai Gilb : Testers Bill of Rights テスターの権利章典
「Testers have the right to sample the process and document inputs, and to reject inputs of poor quality.」が気に入りました。
テスト戦略、設計、手法、技法などなどのリンクをまとめてみた - うさぎ組
まじめにテストを考えるときに、時間はかかるけど、参考になるスライドとかがある。
逆引きソフトウェアテスト関連技術まとめ
こちらは、テストの基本的な説明へのリンクがたくさんありますね。

プロジェクト管理

CCPMとは?なぜCCPMなのか?-遅延のメカニズムとは?CCPMのプロジェクト管理とは!? TOC-CCPM
クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?
ゴールドラットによるCCPMの本。CCPMはTOCという問題解決手法をプロジェクト管理に応用した。商品説明から引用する。
ベストセラー『ザ・ゴール』に続くゴールドラット博士によるシリーズ待望の4作目。テーマはTOCによるプロジェクトマネジメントである。
本書でも一連の作品と同様に、既存の手法が通じない経営問題に直面する主人公がTOCに出あい劇的な成果をあげるという、「コストワールド」から「スループットワールド」への転換を興味深く描き出している。その「世界」を体験させてくれる大きな役割を果たすのが、定番の小説スタイルといえよう。
ストーリーは、大学のエグゼクティブMBAのクラスを舞台に繰り広げられる。主人公の教授と、各業界から現行のプロジェクトの納期短縮といった使命を帯びて集まったプロジェクト・リーダーらが、議論を戦わせながら現実的なソリューションを求めていく。
プロジェクトの問題点はここで総ざらいされる。納期直前まで作業を始めない「学生症候群」、結局は無駄になる「セーフティー(時間的余裕)」、あるいはクリティカルパス以外の作業の開始時期、プロジェクトの評価基準などだ。TOCはそれらを見事に解決するが、同時に、クリティカルパスの変化やマルチタスク(掛け持ち作業)による人的リソース不足といった実行段階の問題を解く新たな視点も要請する。それが「クリティカルチェーン」である。
カスタマーレビューから引用。
「なぜ、プロジェクトは予定通りに進まないのか?」
この副題に興味をそそられないビジネスマンはいないだろう。ルーティーンの仕事は徐々に外部委託されたり、パートの仕事となっている。残された正社員の仕事に占めるプロジェクトの割合は確実に増えている。
本書では、・所要時間が大幅に伸びてしまう「掛け持ち作業」・必要以上に見積もられる「セーフティ」・時間があっても、ギリギリまで何もしない「学生症候群」を上げている。
TOCは、問題構造を明らかにし、根本原因への施策を打つ。施策の副作用にも、手を打つ。よく考えられた手法だ。CCPMに応用すると、鮮やかな解決手法が求められた。
知っておきたいIT経営用語 - CCPM とは:ITpro
ドラクエXはこうして作られた、大規模ゲーム開発におけるマネージメント方法 - GIGAZINE
4Gamer.net ― [CEDEC 2012]「ドラゴンクエストX」における開発進捗管理法とは? セッション「大規模開発のプロジェクト管理 ~ドラゴンクエストXにおけるマネージメント事例~」レポート
人月の神話【新装版】
今のプロジェクトは、開発に焦って、外注人員を追加しまっくている。記念にこの本を貼っておこう。2016/06/16

工数見積もり

今でも簡単に適用できる30年以上前の見積もり技法
ソフトウェア見積り
未読。
ソフトウェア見積りのすべて 第2版 ―現実に即した規模・品質・工数・工期の予測―
未読。Caper Jonesは名前をきいたことがある。興味あり。
本当に使える見積もり技術 改訂第3版
著者は日本ファンクションポイントユーザ会会長。ファンクションポイント法のユーザ会があったのは知らなかった。

外注開発、オフショア開発

My Job Went To India オフショア時代のソフトウェア開発者サバイバルガイド
同僚に薦められ読んだらすごくよかった。監訳者あとがきを引用。
従来、製品としてのソフトウェアを輸入することはあっても、ソフトウェアの開発を海外で行うというのはまれであった。しかし本書でも繰り返されているように、IT 技術のすさまじい進歩による通信コストの低下、インドや中国といった新興国の技術レベルの上昇などといった理由から、人件費の安い海外でソフトウェア開発を行う「オフショアリング」が活発になってきている。日本においても、製造業の生産拠点が海外に移転する「産業の空洞化」がマスコミなどで報道されたが、IT 業界でも同じことが起きているといえよう。
そうした状況にあって、プログラマは、予算やスケジュール、限られたチームメンバーなど、さまざまな制約の中でソフトウェアを開発しなければならない。スケジュールを守るために長時間作業を行うのはよくあることだ。その一方で、IT技術の進歩によって自分の技術や知識が時代遅れになるのではないかという不安にさらされている。
このようなさまざまな問題に、プログラマはどうやって対処すればいいのだろうか? 残念ながら、劇的に解決する特効薬は存在しない。ただ、本書にはオフショア開発者とのコミュニケーションのヒントや、プログラマがキャリアを積み重ねる上でのヒントがたくさん含まれている。現役のプログラマはもとより、プログラマ志望の方や、オフショア開発者を日本からマネジメントしなければならない立場にあるマネージャの方にも大いに参考になったはずだ。本書が皆様のお役に立てば、監訳者としても幸いである。
再読したい。
日本のソフトウエア産業、衰退の真因 松原友夫 松原コンサルティング
これはいい記事。だいたい、プログラマが優秀でなくていいはずがない。
下も同じような指摘。考えてみると、派遣プログラマとか請け負いプログラマは、いいプログラムを書こうとするだろうか。最低限のプログラムを書いて、早く家に帰りたいというのが本音ではないか。長期的な信頼関係なくして、いいものを作りたいと思えるか?また、プログラマをすぐ変えるようでは、引継ぎの問題がある。プログラムは簡単に引き継げないだろう。自分が書いたプログラムでさえ、数ヵ月後に理解が難しくなるのだから。プログラマは簡単には交換できない。
ソフトウェア最前線―日本の情報サービス産業界に革新をもたらす7つの真実
教科書的なソフトウェア工学から進んで、日本のソフトウェア開発の問題点について分析した良書。
お大師様を訪ねて(2) 菊と刀
PDFの最後の部分。以下の部分が秀逸。
「プログラマ予備軍を大量採用したメーカ子会社に対しメーカ本体は仕事を発注せざるを得ず,その結果自分は管理業務と称する雑務を行いプログラミングの現場から遠ざかった.子会社は地元取引先に発注し,やはり管理業務に専念することとなり,結局メーカのプログラマはプログラムを開発しなくなり,実力がどんどん低下してしまったのが空洞化の原因である.こうして出来の悪い人間の作ったプログラムから無尽蔵に発生するバグの管理を出来の良い人間が行うというパラドックスが日常となった.」
プログラムって製品の大事な部分であり、難しいにもかかわらず、外注するってのがまず間違いな気がする。ソフト工学の取り組みって、プログラマがだめなのに、それに目をつむって何か改善するパターンがある気がするけど、結局、実力(設計力とか実装力とか)がないと、だめな気がするよね。
Life is beautiful: 「ファミレス型ソフトウェア開発」ではアップルには勝てない
これもいいことを言っている。
「自らバリバリとソフトウェアを開発したことがないメーカーの正社員が仕様書を書き、実際の開発は子会社や関連会社に任せる上に、その子会社においても実際のコーディングは派遣社員が行うというゼネコン型ソフトウェア開発。これでは、本社から送られて来たレシピどおりにパートの人たちが料理をしているファミレスと同じだ。
一流シェフたちが腕を競う高級レストランのように、シリコンバレーのトップクラスのソフトウェア・エンジニアたちが、自ら仕様を決めながら魂を込めたコーディングをしているアップル。圧倒的な差がつくのは当然だ。」
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
非常に重要なことを言っている。
これに関しては、自信を持って言えるのだが、「どんなに優秀なエンジニアでも、決してプログラムを自分自身で書かずに良い詳細仕様を作ることは出来ない」という絶対的な法則があるのだ。私の知っている優秀なエンジニアは、皆それを知っており自ら実行している。もちろん、彼らはプログラムを書き始める前に大まかな設計をするのだが、十分な経験を積んだエンジニアは、その段階でのものが「仮設計」でしかないことを良く知っている。だから、その段階で詳細設計書を書くような時間の無駄使いはせず、すぐにプログラム(もしくはプロトタイプ)の作成にかかるのである。
実際にプログラムを書き始めて初めて見えてくること、思いつくことが沢山あるので、それを元に柔軟に設計を変更しながらプログラムを書き進めるのである。作っているプログラムが予定通りに動き始めてやっと、設計も完成に近づくのである。(ただし、そんな作り方で作ったプログラムはソースコードが汚くなってしまうケースが多いので、この段階から出来上がったプログラムを、読みやすさ・メンテナンスの高さを重視して大幅に書き直すことを強く薦める。エンジニアによっては、ここで一度作ったプログラムを全部捨ててしまってもう一度全部作り直す人もいるぐらい、この作業は重要だ。)
Life is beautiful: SEはメニューのないレストランのウェイターか?
こちらも重要。
少し誇張した書き方になってしまったかもしれないが、これが私なりの解釈である。SEの役目を、本来の「客が何を欲しがっているか、何を作れば喜んでもらえるかをソフトウェアエンジニアに伝える(要求仕様)」ところにとどめておけばよかったのに、ソフトウェアエンジニアの不足を補うために「どうやって作るか(詳細設計仕様)」という所まで踏み込ませてしまったのが間違いの始まりだったのではないだろうか。そのために、ソフトウェアを作ったことのないSEが詳細仕様を書く→ソフトウェアエンジニアが単なるコーダーになり地位と賃金が下がる→労働環境が悪化する→優秀なエンジニアがやめてしまう→やむなくソフトウェアの基礎を身に付けてない人たちを雇う→ますます良いソフトウェアを作るのが難しくなる、という悪循環に陥ってしまったのではないだろうか。
NTTデータ委託社員の不正事件、下請け依存に重いツケ

アジャイル開発

ソフトウェアは完成しても価値はない ~ アジャイル開発は何を解決するのか | Social Change!
なかなかおもしろい。
いいアジャイルと悪いアジャイル
Scrumに関する無料の日本語資料のまとめ
読んでないけど、とりあえず、リンク。
アジャイルソフトウェア開発 - Wikipedia
最近、アジャイル気になり始めたし。「アジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。 」ほう。
「アジャイルソフトウェア開発手法の多くは、反復 (イテレーション) と呼ばれる短い期間単位を採用することで、リスクを最小化しようとしている。 1つの反復の期間は、プロジェクトごとに異なるが、1週間から4週間くらいであることが多い。アジャイル開発手法においては、開発対象を多数の小さな機能に分割し、1つの反復 (イテレーション) で1機能を開発する(⇒反復型開発)。」

メトリクス

Cyclomatic complexity - Wikipedia, the free encyclopedia
ソフトの複雑さの尺度。
循環的複雑度 - Wikipedia
日本語版の方が情報量が少ない。線形的に独立した経路の数って何だろう?互いに含まれない?

ソフトウェア工学学会

Software Engineering Conferences
海外に投稿するなら。
ソフトウェア工学研究会(情報処理学会)
ソフトウェア工学の基礎研究会 (FOSE)
日本ソフトウェア科学会

ソフトウェア工学研究機関

玉井哲雄のホームページ
東大から法政大学に移られた。個人のページ。研究室のページとかなくて、さびしい。研究内容はむかし東大のページに書いてあったんんだ。
適応型オブジェクト指向計算モデル(Epsilonモデル,McJavaなど)/分析/設計のためのモデル化技法/形式手法(形式仕様記述,検証,モデル検査など)/ソフトウェア要求工学/オブジェクト進化論,ソフトウェア保守,など
Software Engineering Laboratory 井上研究室
「ソースコードに含まれる「複製(クローン)」を検出するツール CCFinder および一連のクローン分析ツール,ソフトウェア部品検索エンジン SPARS,メトリクス計測フレームワーク MASU,Java プログラムの実行時情報分析ツール Amida 」など。
Kusumoto Laboratory
大阪大学 大学院情報科学研究科 コンピュータサイエンス専攻 ソフトウェア設計学講座 ソフトウェア設計学講座 楠本研究室 「ソフトウェアの高度化、大規模化とこれに伴う開発コストの増大に伴い、ソフトウェア開発において、生産性の向上と品質の確保が重要な課題となっています。そのための有用なアプローチとして、ソフトウェア開発の分野において、他の科学、工学分野と同様に、計測、定量化と評価、そしてフィードバックによる改善という実証的手法(エンピリカルアプローチ)が注目されています。」とのこと。具体的には、「食品流通等におけるトレーサビリティの概念を,ソフトウェアの開発過程に応用することで,「いつ、どこで、誰が、どのように」開発したものであるかというトレーサビリティ情報を「ソフトウェアタグ」としてソフトウェア製品そのものに添付します.」とのこと。あと、モデル検査、MDA、アサーションの研究をしているようだ。
Nishi Laboratory
電気通信大学 情報理工学部 総合情報学科 経営情報学コース 「ソフトウェア工学(Software Engineering)とは、 「よい」ソフトウェアを生み出すための学問体系です。 西研究室では主に、ソフトウェアテスト、組込みソフトウェア工学、プロジェクトマネジメント などについて研究しています。」とのこと。研究テーマは、「現在扱っている研究テーマ/バグのナレッジマネジメント/バグの状況に応じた適応型テスト設計/ソフトウェア開発における技術者のモチベーションの向上/ソフトウェア開発におけるリスクマネジメント/データフローパステスト法の検証と改良/ミッションクリティカルソフトウェアのためのテスト設計/プロセス改善とTPS/ソフトウェアにおけるすり合わせ開発/Wモデルにおけるテスト設計/サービス・サイエンスなど」とのこと。
豆蔵ソフト工学ラボ
「オブジェクト指向」「モデリング」「プロセス」が中核とのこと。相談したら、OOで、UML描いて、開発手順とか、指導してもえるのか。学生のときは結構勉強して、いいね!と思っていたが、最近はオブジェクト指向興味なくなった。設計の仕方とか、いろんな流派ありすぎて、少し疲れましたのさ。何でもオブジェクト指向でやったら、いいわけでもないよね、きっと。考えてみると、ソフトウェア工学関係のツールって、UMLツールとかって、重たかったり、あんまり使いたいものではないな。プライベートでもインストールしたい!っていう軽さが必要ではないか。って、豆蔵とあまり関係ないことを書いてしまった。
東芝 ソフトウェア技術センター
紹介。
東芝ソフトウェア技術センターは、2015年4月に東芝インダストリアルICTソリューション社の技術開発部門であるIoTテクノロジーセンターの一部門として組織が改編されました。そのため、当ウェブサイトは、2015年11月30日をもちまして閉鎖させていただきました。
なくなったぽい。昔の私の紹介。
先端ソフトウェア基盤技術、ソフトウェア設計・検証技術、ソフトウェア開発管理技術の3本柱。中身を見ても特に特徴は感じられない。けど、ソフトウェア技術は、特に目立たない存在でもいいのかもしれませんね。
東芝レビュー200904にソフトウェアエンジニアリング特集があります。

ソフトウェア工学よみもの

Japanese - The Joel on Software Translation Project
『The Joel on Software』って有名ですよね。まだ読んでない。
Fine Software Writings
ソフトウェア開発に関する文章の翻訳。
ポール・グレアムのエッセイと和訳一覧
Paul Grahamはプログラマだったが、作ったサイトをYahoo!に売却し、ベンチャーキャピタリストになった。プログラマだったら一度そのエッセイを読むと、興味ある人ははまるだろう。大企業のソフトウェア工学と、ベンチャーやスタートアップのソフトウェア工学は違うことに気づく。大企業の人間でも参考になるだろう。
アメリカの大学で受けたソフトウェア工学の授業が実践的ですごかった話 - すてにゃんのガチ勢日記
実践的な授業で、本当の開発の経験のような体験ができるようです。強烈な体験ですね。文章がわかりやすい。
ニュース - [スクープ]特許庁、難航していた基幹系刷新を中止へ:ITpro
特許庁の新情報システム、開発計画から作り直しへ | スラッシュドット・ジャパン IT
特許庁:新システム断念 支出50億円、計画作り直し 東芝子会社に返還請求へ- 毎日jp(毎日新聞)
【ITブラック】特許庁システムにまつわる黒い話が色々ヤバイ - NAVER まとめ
特許庁が発注し、落札した東芝がシステム開発中断で税金54億円が無駄に!裏には黒い話も - NAVER まとめ
Life is beautiful: 特許庁のシステム開発が破綻した本当の理由
公共的なシステム開発のあり方と特許庁システム問題 - novtan別館
特許庁の55億かけて頓挫したプロジェクトの報告書が面白い
まとめはこのあたり。123
Fumi's Travelblog: "費やした55億円、水の泡に 特許庁がシステム開発中断"って一体何だったのか、報告書を読んでみた
IT業界離れ - Wikipedia
こんなwikipediaの項目があるとは。。。しかし、いい記事だ。
IT業界には企業・人材・雇用など様々な面において消長盛衰が著しく不安定な一面がある。2000年代半ばになるとライブドア事件やニイウス コーの経営破綻などを筆頭に、多くのITベンチャー企業・ITソリューション企業で粉飾決算や乱脈経営が露呈したり、ひとたび収益性が悪化すればコスト削減を名目に人材削減を安易に繰り広げるなど、経営陣の派手な言動や浪費とは裏腹のお粗末な企業経営の実態が次々と露見し、少なからぬ企業が経営破綻や撤退・事業譲渡などの形で消えていった。また、末端従業員が置かれているデジタル土方や新3Kと揶揄されるほどに劣悪過酷で労働環境[3]、人海戦術とデスマーチが横行し[4]一向に成熟できないIT業界の人材育成・人材運用のシステム、毎月の様に現れる新製品・新技術に追われ続ける末端スタッフの実情、末端従業員を次々と雇い入れては低賃金で使い潰していく搾取型のビジネスモデル、ITゼネコンとそれを支える下請けブラック企業といった日本特有のIT業界の多重請負構造といった実態が、元従業員の証言やインターネット上の情報などの形で数多く槍玉に挙げられ、求職者や就職活動中の学生の側からも不安視される様になった。これらの結果として、2000年代後半に一時的に景気が回復すると情報処理産業は不人気業種と化し、IT業界は新卒からは忌避され、同様に業界下層で働く若年層や壮年層の労働者も、せめてIT業界ほど不安定・過酷ではない他業種への転職を求めて続々と離職してゆく、「IT業界離れ」の様相が見られる様になった。
プログラマを一生の仕事にできるビジネスモデルで目指す未来のビジョン
よいプレゼン、斬新。「納品しない受託開発」。
業務系エンジニアはどうしていくべきか? - 急がば回れ、選ぶなら近道
エンジニアにコミュニケーション能力を求める愚行。 : ひろゆき@オープンSNS
たしかにエンジニアにコミュニケーション能力を求めるのは、求めすぎかも。エンジニアの論理的、理系的な興味は、コミュニケーションの無いところで、追求されることが多い気がするな。それにしても、ひろゆきは頭がいいなあ、と感心する。
【STARTUP INSIDER 3】卒業生たちが語る、最強の起業家養成システム「Y Combinator」の真実
ソフトウェアで企業するなら参考になるかも。
「大企業に身を置くことが、致命的なリスクになる」nanapiけんすうに訊く![2]│CAREER HACK
常に進化することは大事そうですね。
有能な人材が辞めない職場 - WirelessWire News(ワイヤレスワイヤーニュース)
これは熱い。「開発に関わる人材はどこの会社も欲しがる精鋭ぞろいですが、同社はスタッフの退職率が低いことで有名です。それには秘訣があるのです。この会社、就労環境を極力自由にし、開発者が床でゴロゴロしながら仕事しようが、仕事中にゲームをやろうが、何を食べていようが、どんな服装だろうが、自由にしてるというのです。職場には無料のゲームや食べ物が沢山用意されてます。オフィスのインテリアには莫大なお金をかけて、会社にいたくなるような環境を作り上げます。組織体制は可能な限りフラットにしています。」
Computability and Complexity from a Programming Perspective
紹介。「計算可能性と計算量について、プログラミング言語を基礎に置いて 平易かつ統一的に説明するのに成功している良書。 もちろん、部分計算など、Jonesならではの話題も充実。 (ただし誤植がかなり多いので注意 - 再版でかなり修正されるそうです) 」らしいよ。
人月の神話
遅れているソフトウェアプロジェクトへの要員追加がさらにソフトウェアプロジェクトを遅らせること。
ピープルウェア
「われわれの抱える主要な問題は、そもそも技術的ではなく社会学的なものである」
デスマーチ
ソフトウェア産業における過酷な状況にあるプロジェクトを指す。死の行進、死の行軍。
日本のソフトウェア産業がいつまでもダメな理由(技術評論社)のまとめ
表面的な感じがする。
YAMAGATA Hiroo Official Japanese Page
エリック・レイモンド オープンソースの解剖学四部作の翻訳のPDFがあるよ。「伽藍とバザール」とか。
【悲報】みずほ銀行の次期システム、デスマプロジェクトが破綻か。完成のメドなく4000億円がパー : IT速報
【悲報】みずほのデスマ現場、ガチで監獄並だった。末端は7次受けで時給900円 : IT速報
国内某銀行が勘定系システム再構築の全体プロジェクトマネージャーを130万円で募集中!必須スキルはタフなメンタル : IT速報
ルクルク
池澤あやかさんは女優であると同時にソフトウェア開発者だ。このような才能ある人にプロジェクトにいてほしいと心底思う。きっといないけど。
銀行SEの現在 - novtan別館
実は過剰品質ということはないだろうか。そして、やばいときはやばいらしい。
もちろん、ヤバイ時はヤバイです。でもそれって銀行だからどうこうではないでしょ。銀行システムは先に述べた通り、どうしてもエビデンスの検証とか、テストケースがアホみたいに多いとかがあるため、他のところから来た人がいつもの感覚で見積もってWBS引いたら後で全然足りないことがわかって青ざめる、みたいなトラブルになったりしますけどね。ヤバイの大半は見積の失敗や値引きやユーザの動きが悪くて結果としてみたいな原因がちゃんとあります。ぶっちゃけ自分たちのせいじゃね?
しかし、進歩もしているようだ。
まあ、そういう社会性のあるシステムです。多分、別の業界の人が見たらアホかと思うようなテストの山、紙の山です。銀行システムのテスト工数が削減されない一番大きい理由はエビデンスの検証作業を決しておざなりにしないこと、その結果としてペーパーが増えてしまうことです。
しかし、それは高コスト体質の原因だということはわかっているので、改善をしようという努力はされています。リファクタリングが銀行システムでほぼ有名無実なのは、変更したモジュールのロジックが本当に使われているすべての機能に影響を及ぼさないかを必ず検証しなければならないということにあります。つまり、大量のリグレッションテストが必要な変更はできるだけ避けるということです。
しかし、それでは例えばSOAやらなんやらのコンセプトを導入してシステムを疎にした成果が得られたとはいえません。なので、テストの自動化については真剣に取り組んでいます。結果として、死んだ目をしながら端末を叩くテストフェーズというのは削減されつつあります。
また、テストの内容についても、リスクベースでのテストケース作成の考え方を取り入れつつあります。つまり、「全てを完璧」というのは費用対効果が悪すぎるため、問題が発生する可能性がある箇所を重点的にやりましょうということですね。そんなの常識じゃない?と思う人もいると思いますが、常識ではありませんwww自動化の目的だって、「自動なら全量テストするの簡単だもんね(2回目以降はな!)」ですからね。これ、本当はシステム開発のあり方としては他のほうがおかしいって言っちゃえるかもよ。
IT業界で無事にいたいなら銀行に関わるな
新規開発が出来ると思うな。10年以上経ったシステムのお守りがほとんど。当然コードは見るに堪えない。そのくせ仕事はたくさん来る。ほとんどがバグ修正か機能拡張。そして時間のほとんどはテストで消える。1行修正するだけでも数週間のテストが普通。OSが変わったら一年中テストで潰れる。
ソフト構造がしっかりしてれば、影響範囲が絞れるとか、そういう手法が必要かもしれない。
SEの日常 理想と現実 | ライフハックちゃんねる弐式

ツール

WinMerge
マージソフトとして使っていた。diffのアルゴリズムってよくわからない。
XMind
マインドマップツール。設計とかテストとかに使おうぜ。
OpenProj
プロジェクト管理のMicrosoft Office Projectのクローン。かなり使えそう。参考:フリーソフト「OpenProj」 - GIGAZINE
draw.io
UMLがかけるWebサービス
js-sequence-diagrams by bramp
textでシーケンス図がかける
Happy Hacking Keyboard Professional BT 日本語配列/墨 PD-KB620B
プロならキーボードもこだわろう。私は仕事で使っている。静電容量で省スペース、打鍵感もよい。こちらにもう少し詳しい説明を書いた。

プログラミング言語チュートリアル

プログラミング言語C 第2版 ANSI規格準拠
プログラミング入門なら、この一冊をおすすめすると思う。ただし、計算機の仕組みとプログラミング言語は密接に関わっているんだ。計算機アーキテクチャもわかったほうがいい。次の本、ヘネパタ本をおすすめする。
通勤中でも寝る前でも!iPhoneプログラミングを勉強出来る簡単な方法! | PLUS