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

東京大学から法政大学に移られた玉井哲雄先生のソフトウェア工学のまとまったPDF文書。と思ったら研究室のページがないのでinternet archiveにリンクしました。いいですね。
『ソフトウェア工学の基礎』はよい日本語のソフトウェア工学の教科書だと思います。このPDFは草稿でしょう。この教科書はよくまとまっていると思います。ソフトウェア工学を学ぶなら一冊良い本を持つとよいです。日本語の教科書を一冊選ぶならこの教科書だと思います。基本に忠実であり大御所が執筆しているし格調の高さから言ってもこの本でしょう。
もちろんこの教科書はあくまで基本を抑えるための本です。ソフトウェア開発の問題は未解決な問題が多く発展的な書籍や論文にあたるなり自分で解決策を考案し実践する必要があります。

ソフトウェア工学の教科書。『ソフトウェア工学の基礎』よりはカジュアルです。こちらがとっつきやすい人もいるかもしれません。

わたしの持っているソフトウェア工学の教科書の最新版です。公開スライドがあります。なかなかいい教科書です。英語です。

デマルコの本ですね。『アドレナリンジャンキー』とかデマルコの本は興味ぶかいです。ピープルウェアはソフトウェア開発の肝は人間の待遇であることを指摘しています。そもそもソフトウェア開発にかかりっきりになって、人生をおろそかにしているんじゃないかって思うんですね。ソフトウェア開発ってパズルみたいなところがあっておもしろい。そこが罠でつい熱中して、大事なことより優先しがちです。他に何もない人はそれでいいです。

以下の感想記事もご参考。「ピープルウェア」を読んでブッ刺さった話 - Qiitaと「ピープルウェア」を読んだ - $shibayu36->blog;

ソフトウェアエンジニアが信用されている状況でのソフトウェア工学。エンジニアによる会社だからだな。エンジニアは管理する対象ではないという点がいい。エンジニアが信用されていない会社では軍隊や学校のようにルールでがんじがらめになる。Google re:Work - ガイド: 「効果的なチームとは何か」を知る]なんかも良い公式記事。心理的安全がほしい。

うらやましい。グーグルってソフトウェアエンジニアしかいないのか？そんなことないよな。情報がソフトウェアエンジニアの給料しかない気がする。しかしおいらもソフトウェアエンジニア以外にはなれないと思うから無駄な思考だ。そしてグーグルに入れないだろうから無駄な検討だ。こういった情報が日本の大企業のソフトウェアエンジニアの心を蝕んでいく。力を奪っていく。気をそらす。

Ed Yourdonによる2009年のソフトウェア工学の状況まとめのスライド。日本語訳：ソフトウェア工学で最も大切な10の考え方。オリジナルのURLはnot foundになっていたので削除しました。

以下のように主張している。

従来のソフトウェア工学は、属人性を排除して開発者の能力を均一化しようとしている。この点に置いて、従来のソフトウェア工学は決定的に間違っている。

たしかに属人性を認めて開発者の個性を伸ばすスタンスもありかもしれない。ソフトウェア工学は２０世紀の学問だった。２０世紀は大量生産と大量消費の時代だから均一な労働力を必要とした。だから属人性を排除しようとした。しかし個性や能力差を考慮した開発体制のほうにこれからは進歩するでしょう。能力のない開発者がいる場合まず能力を並に底上げが必要だろう。それは属人性の排除とは違う。

日本のソフトウェア工学が実用レベルでないことの告発。

何が言いたいかというと、今の（少なくとも日本の）ソフトウェア工学って、今のソフトウェア開発現場と相当乖離しているように思うんです。最近のソフトウェア開発現場で採用されてる開発形態・開発プロセスを全く想定していないし、だから実務家が持ってる課題意識を、今のソフトウェア工学の研究者は全く把握できてないし、把握しようともしてない感がすごくあります。
そんでもって、今参加している学会で発表されてる論文、ざっと眺めましたが、申し訳ないけどレベル低いなーと思います。基本的に小粒な研究ばかりだし、発展すれば実務でそのうち役に立ちそう、と思わせる論文がほとんどありません。アカデミックな観点から、新しい領域にチャレンジするようなheavyweightな論文もありません。どこを目指して研究しているのか、さっぱりわからない論文も多々あります。

学会でなくて草の根の勉強会に人が流れていると指摘する。

そういうのもあって、学会への参加者が顕著に減ってるように思います。一方、IT勉強会はどこも大盛況です。
アカデミアの人はもしかすると「エンジニアの参加する勉強会と研究者の集う学会では扱う内容の質が違う」と思ってる人も多いかもしれませんが。
実際のところ、トップカンファレンスで発表された論文の輪講会をやる勉強会とかたくさんありますし、そうじゃなくても、「〇〇で発表された論文を参考に、自分達でこういう工夫をしてみました」なんて発表もしょっちゅう聞きます。ガチガチに最新の論文サーベイして、それに基づいてる発表なんかもあって、結構学術的にもレベル高いですよ。
そもそも、そういう場で発表する人、最近はPhD持ってる人も多いですしね。
要するに今のソフトウェア工学の研究会って、日本のそこかしこで開催されてるIT勉強会に客食われてるんじゃないかと思います。実際、企業人だとそっちの方が面白いしためになるし、と言う気がします。

そして最後にパンチ。

なので、国内にいるソフトウェア工学の研究者の皆さん、ぜひ、一度ゼロベースで、色々考えてみてほしいんです。 あなたは誰の方を向いて研究してますか？

形が勉強会に変わっているならそれでいいじゃないか。学会なりの形式が衰退したという話か。衰退した形式に従っているだけで損失なんですがね。海外の学会がレベルが高いとすればそれはどういうことだろう。日本発信のソフトウェア工学技術なんてRubyぐらいかな。であれば新規性がないということか。海外技術の輸入と採用ぐらいだったら新規性もないから論文にもならなくて勉強会で十分だよね。この記事はソフトウェア工学への批判ではない。日本のソフトウェア工学のアカデミアに関しての批判だろう。

プログラマやソフト開発、ソフトウェア工学的な状況が歴史の中で描かれてきました。その紹介。というかパロディ。

正攻法でソフトウェア開発力を向上させるリンク集。成長のためには努力と犠牲が必要だ。

古典。デスマーチ - Wikipediaに内容の説明がある。

ヨードンは、その著書『デスマーチ：なぜソフトウエア・プロジェクトは混乱するのか』で、デスマーチの定義を「プロジェクトのパラメータが正常値を50%以上超過したもの」もしくは「公正かつ客観的にプロジェクトのリスク分析（技術的要因の分析、人員の解析、法的分析、政治的要因の分析を含む）をした場合、失敗する確率が50%を超えるもの」としており、具体的には以下のいずれかに該当するものと定めている。

古典。現代的に再定義したほうがよい。
夜２０時以降の残業後に心臓発作による死亡した事例を知っている。デスマーチでは毎日深夜残業になり体力の限界まで働くことになる。体調に異変があってもおかしくない状況だ。睡眠不足や心労は命に関わる。ソフトウェア開発者への影響や体調の変化は不可視だ。ソフトウェア開発プロジェクトの状況の悪化も気づきにくい。デスマーチへの対策はソフトウェア工学の本務のはずだ。

デスマーチのはなしとして有名なもの。スペゲッティプログラムと格闘しながら派遣先の会社の管理力のなさや研究所の無能さなどに翻弄され精神がすり減る模様が描かれている。笑えた。かなりの文章力だ。フィクションかと思えたがこれに近い事実はあったのだろう。いやーソフトウェア開発って怖いですね。

なかなかまともな記事だ。

悪い会社に騙されて入社しないためには「御社は速度重視ですか？品質重視ですか？それとも高速高品質？」と質問をするとよいでしょう。品質重視、高速かつ高品質、あるいは速度重視だけど品質も疎かにはしてないよ、と答えると思います。速度重視と断言されたら逃げた方がよいでしょう

「スタートアップがまともなわけ無いから入るな」【後編】SUGAR・杉谷保幸CTOインタビュー　｜　Geekroid

スタートアップにありがちな混乱状態が大企業でもあれば大企業の開発だって過労になる。

システム要求が不明瞭なまま開発し問題を人員投入で解決しようとしたが失敗したと読める。

ソフトウェア開発が悲惨って話だ。7次受けや８次受けなんて言葉がある。ソフトは外注して開発することもあるが８次受けならば途中の会社は手数料を受取り仕事を横流しするだけだ。伝言ゲームで難易度はあがりコストが大きくなる。ただ、これだけではデスマーチの原因を説明していることにはならない。ただ手数料の抜き取りをしているうちに下請けの賃金が下がり開発者の報酬が下がる。しかし多重請負がデスマーチの原因なのだろうか。

244:非決定性名無しさん 2016/07/05(火) 20:54:57.79 .net/窓のない部屋に鮨詰めにされて/会議用の長机とパイプ椅子で/隣の人の肘があたったり、前の人の足が当たって /便所は長い行列で漏れそうになる/当然毎日終電/助けて

毎日終電ということは作業見積もりがうまくいかなかったか。作業リストがあって終わらせていけばいいのではない。プログラムの構造の問題もあったのだろうか。

開発の発注側の命令系統が権力争いしているという話。そんなパターンもあるのかな。詳細は不明なので納得感は少ない記事だ。権力闘争だからデスマーチになるというのは論理的飛躍がある。もともとのシステムが別れていた。統合が必要だからプログラム構造が複雑になるというのならわかる。ネタとしてはよいが読む価値はないかもしれない。

ひどいソフトウェア開発者はこうなるっていう話。IT速報ってデスマーチ系の記事もけっこう強いな。これきついたんだよね↓こんなはずじゃなかったよー。

8時起床
8時30分家出る
8時50分会社着く
9時始業
18時定時
23時30分終業
24時10分買い物して帰宅
24時20分食事
24時40分入浴
25時30分就寝

こんな感じの毎日

デスマーチを避ける方法は一つではない。いろんな失敗を全てしなかったときだけ、デスマーチは避けられるのではないか？

「コミュニケーションの肝は勇気を持って“なあなあ”をやめること」はいいこと言ってるみたい。最後に「重要なのはPMBOKに肉付けすること」p

冷静な記事。見積もりなおして、必要ない機能は捨てる。これだけでうまくいくかは疑問だ。見積もりは難しい。これで解決するなら、最初から見積もり、デスマーチにならないはず。

ニコニコのほうが、wikipediaよりリアルな説明だ

そういう組織は、人が内部から壊れていく。鬱になったり、病気になったりする。まあ、発展性のない業務に長時間据えられて、強いストレスに晒されながら安い給料で働くわけだからねえ。一個一個のデスマーチは、マーチである限り終わりはあるわけだけど、デスマーチは仕事の様態ではなく企業の仕事のとり方に起因するから、その業界や企業や経営者の考えが変わらない限りチェーン状に無限連鎖になってる。

たしかに、仕事のとり方が重要だ。例えば、仕事量が未定のまま、仕事を受けるとか、見積もりが甘ければ、慢性的なデスマーチになるだろう。

レコード一個の追加が大変って、プログラムもうよくわからんことになってるでしょ！

USDMによる仕様記述の本。知り合いからきいたところ、内容はよい。しかし著者の本は難読とのこと。内容紹介によると以下。

好評既刊の改訂第2版。開発の根本であり工程すべてに関わってくる「要求の仕様化」について、その重要性からじっくりと解説。「要求」とは何か「仕様」とは何かという本質から説き、仕様書作りの考え方や表現方法を具体的に提示します。第1版では、要求を表現する際に「振る舞い」に注目し、分割・階層化により振る舞いの範囲を狭くして仕様漏れをなくしていく方法を提唱しました。第2版ではその方法論をさらに深め、上位要求の表現や分割・階層化したときの下位層の要求を表現する際に「動詞」を意識する視点を全面的に打ち出しています。

適用例。UMLのユースケースもそうだが、フォーマットを決めることは、それぞれの設計者が記法をばらばらに考える手間を省ける。これは実に大きい。

内容紹介より。

ロングセラー『[入門+実践]要求を仕様化する技術・表現する技術』の著者が渾身の力で放つ第2弾がいよいよ登場! 開発現場のほとんどはいわゆる「派生開発」です。そしてトラブルが頻発する「派生開発」の現状を改善するために、著者自身が現場で長く培ってきた方法論をまとめあげました。この派生開発プロセスにより、確実にプロジェクトを成功させることができます。本書でその真髄に触れ、「派生開発」のあり方を探求し失敗のない「派生開発」を目指してください。現場で抱える問題の解決に必ず役立つ、「定番」となる一冊です。

内容（「BOOK」データベースより）

いつまで「派生開発」で疲労し続けますか?派生開発にはそれに適したプロセスがある!合理的なプロセスと成果物で構成された「XDDP」でデスマーチから脱却を!確実に派生開発プロジェクトを成功させる実践的方法論の登場。

XDDPという派生開発プロセスをまとめ上げたのがすごい。プロセスと成果物の流れを定義するPFD(プロセスフローダイアグラム)や改造内容と改造部位トレーサビリティマトリックスという記法を利用する。

仕様を記述する言語の一つ。

Z言語 (ぜっどげんご) は、Z記法 (ぜっどきほう) ともいい、形式仕様記述言語であり、コンピュータシステムの記述とモデリングを行うために使われる。 ZはZF集合論から名前をとって命名された。

数学的記法で定義される。集合で定義したいときに使える。

これも仕様記述言語。

Z言語に比較して抽象化レベルが低く、単なる形式仕様記述というよりもコードへの詳細化に重きを置いている。そのため、B で書かれた仕様はZ言語の場合よりも実装が容易である。

Bメソッドの解説書。とっつきやすいだろう。Bメソッドの特徴は、仕様から実装へ段階的に詳細かしていく点です。

ホーア論理、Z、VDM等、全体感がうすく分かる感じの入門書かな。未読。

Event-BはBメソッドをもとにした言語で、並行性やリアクティブ性に対応したようです。

UMLは設計記法の統一規格。設計記法がバラバラなプロジェクトだと、図の意味の説明に時間がかかる。また、設計者も表現の仕方の検討に時間がかかる。しかも、既に先人に考えれた記法があるのだから、それを学び利用すれば、随分楽になる。
独習シリーズは、厚いが、よくまとまっている感じがする。この『独習UML』と『独習C++』がよい。

丁寧なチュートリアルがある。

悪い点は、人の思考を表現するほどの表現力が無い点、いい点は、表現力を犠牲にして、わかりやすい点。ダメだと言っても、設計書がないより、全くマシだよな。

UML図の説明あり。オージス総研による、http://www.agilemodeling.com/の翻訳のようだ。ページの対応関係が不明。

GoF本として有名。オブジェクト指向やるなら、これを抑えておくとよい。でも難しい。オブジェクト指向って秘伝の技術みたいになる嫌いがあるが、それは他の技術でも同じか。各種流派の独特な言葉に惑わされないことが重要と思う。オブジェクトはインターフェースつきのデータに過ぎないと思う。それはそれで重要なことだが。

GoF本は難しいので、結城浩の入門はこちらがおすすめ。

『なぜオブジェクト指向はだめなのか？』なぜ、オブジェクト指向がポピュラーなのか。理由を挙げている。「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

コーディングは仕事で初めて実践的な経験を得られるが、それでは効率がわるい。また師匠や同僚のアドバイスはその人独自のものである。本書では、実際の例を見ながら、効率よく実践的なノウハウが得られる。

意図のわからないコードは本当に読むのに苦労する。捨ててしまったほうがいい場合もある。そんな不良資産のソフトウェアを作らないための指南書。

リファクタリングとはプログラムの外部から観察できる振る舞いを変化させず、内部を改善することだ。本書は、リファクタリングの基本的文献。

スパゲティプログラムは、設計と実装のどちらを失敗しても発生するだろう。それだけ起こりやすい現象だ。危険性の一つの指標としては構造の質を上げてもいいだろう。しかし、保守性の低いプログラムはスパゲティプログラムだけではない。見た目は良さそうだが、保守性の低いプログラムは存在する。例えば、変数の用途が不明なものなど。そもそも大規模なプログラムはそれだけで、保守は困難になる。スパゲティプログラムは初歩的な問題だが、さらに一見大丈夫なプログラムの保守も課題がある。

テスト計画とかなんでもマインドマップでやろうという感じです。テスト初心者にはまあいいのかな。レビューが大事だという趣旨。

C0網羅（命令網羅），C1網羅（分岐網羅），C2網羅（条件網羅）の解説図。定義がいろいろ異なるが。

テストカバレッジの基準、Modified Condition/Decision Coverage (MC/DC)。 ソフトウェア品質技術の開発と適用に日本語の説明がある。

MCDCの詳しい説明あり。CATS。

ペアワイズテストのツールがいっぱい載ってます。MicrosoftのPictも。

ＨＡＴＳＴ法、これもペアワイズテスト技法のひとつかな。本買って、勉強したけど、理解できてない。ペアワイズテストについては、All-pairs testing - Wikipediaをみてください。日本語ない。

「Testers have the right to sample the process and document inputs, and to reject inputs of poor quality.」が気に入りました。

まじめにテストを考えるときに、時間はかかるけど、参考になるスライドとかがある。

こちらは、テストの基本的な説明へのリンクがたくさんありますね。

ゴールドラットによるCCPMの本。CCPMはTOCという問題解決手法をプロジェクト管理に応用した。商品説明から引用する。

ベストセラー『ザ・ゴール』に続くゴールドラット博士によるシリーズ待望の4作目。テーマはTOCによるプロジェクトマネジメントである。
本書でも一連の作品と同様に、既存の手法が通じない経営問題に直面する主人公がTOCに出あい劇的な成果をあげるという、「コストワールド」から「スループットワールド」への転換を興味深く描き出している。その「世界」を体験させてくれる大きな役割を果たすのが、定番の小説スタイルといえよう。
ストーリーは、大学のエグゼクティブMBAのクラスを舞台に繰り広げられる。主人公の教授と、各業界から現行のプロジェクトの納期短縮といった使命を帯びて集まったプロジェクト・リーダーらが、議論を戦わせながら現実的なソリューションを求めていく。
プロジェクトの問題点はここで総ざらいされる。納期直前まで作業を始めない「学生症候群」、結局は無駄になる「セーフティー（時間的余裕）」、あるいはクリティカルパス以外の作業の開始時期、プロジェクトの評価基準などだ。TOCはそれらを見事に解決するが、同時に、クリティカルパスの変化やマルチタスク（掛け持ち作業）による人的リソース不足といった実行段階の問題を解く新たな視点も要請する。それが「クリティカルチェーン」である。

カスタマーレビューから引用。

「なぜ、プロジェクトは予定通りに進まないのか？」
この副題に興味をそそられないビジネスマンはいないだろう。ルーティーンの仕事は徐々に外部委託されたり、パートの仕事となっている。残された正社員の仕事に占めるプロジェクトの割合は確実に増えている。
本書では、・所要時間が大幅に伸びてしまう「掛け持ち作業」・必要以上に見積もられる「セーフティ」・時間があっても、ギリギリまで何もしない「学生症候群」を上げている。

TOCは、問題構造を明らかにし、根本原因への施策を打つ。施策の副作用にも、手を打つ。よく考えられた手法だ。CCPMに応用すると、鮮やかな解決手法が求められた。

今のプロジェクトは、開発に焦って、外注人員を追加しまっくている。記念にこの本を貼っておこう。2016/06/16
Wikipediaのまとめが詳しいな。人月の神話 - Wikipedia　いいことを言っている。

ソフトウェア・プロジェクトに人員を追加すると、全体として必要となる労力が、次の3つの点で増加する。すなわち、再配置そのものに費やされる労力とそれによる作業の中断、新しい人員の教育、追加の相互連絡である。

多くの方面において増加する遅延が蓄積して、全体として大幅な遅延という結果になってしまう。細かい粒度でのそれぞれのマイルストーンごとに継続的に注意することが、各水準の管理 (マネジメント) では必要である。

未読。

未読。Caper Jonesは名前をきいたことがある。興味あり。

著者は日本ファンクションポイントユーザ会会長。ファンクションポイント法のユーザ会があったのは知らなかった。

IPA研究員倉持俊之によるまとめ。よくまとまっている。

SPINA3CH 自律改善メソッド。初めて聞きましたよ！この成果。ガイドブックのPDFがダウンロード可能。SECによるプロセス改善の書籍もあるようです。有料。

ソフトウェア開発プロセス改善のフレームワーク。CMMI等の理想プロセスへ持っていくことの限界に対する体系的な回答のようです。問題点を開発者が挙げて解決範囲と解決策を策定する。定期的に振り返りをする。日本語で体系的なプロセス改善は他に知らない。問題構造図はTOC的なのかな。ファシリテーターが重要らしい。
ぱっとみ、いろんな体系を寄せ集めたスピリチュアルにも見える。それでいいんだよな。取り組みとして素晴らしさを感じる。熱意がくるぜ。洗練したらさらに素晴らしいだろうね。

同僚に薦められ読んだらすごくよかった。監訳者あとがきを引用。

従来、製品としてのソフトウェアを輸入することはあっても、ソフトウェアの開発を海外で行うというのはまれであった。しかし本書でも繰り返されているように、IT 技術のすさまじい進歩による通信コストの低下、インドや中国といった新興国の技術レベルの上昇などといった理由から、人件費の安い海外でソフトウェア開発を行う「オフショアリング」が活発になってきている。日本においても、製造業の生産拠点が海外に移転する「産業の空洞化」がマスコミなどで報道されたが、IT 業界でも同じことが起きているといえよう。
そうした状況にあって、プログラマは、予算やスケジュール、限られたチームメンバーなど、さまざまな制約の中でソフトウェアを開発しなければならない。スケジュールを守るために長時間作業を行うのはよくあることだ。その一方で、IT技術の進歩によって自分の技術や知識が時代遅れになるのではないかという不安にさらされている。
このようなさまざまな問題に、プログラマはどうやって対処すればいいのだろうか? 残念ながら、劇的に解決する特効薬は存在しない。ただ、本書にはオフショア開発者とのコミュニケーションのヒントや、プログラマがキャリアを積み重ねる上でのヒントがたくさん含まれている。現役のプログラマはもとより、プログラマ志望の方や、オフショア開発者を日本からマネジメントしなければならない立場にあるマネージャの方にも大いに参考になったはずだ。本書が皆様のお役に立てば、監訳者としても幸いである。

再読したい。

これはいい記事。だいたい、プログラマが優秀でなくていいはずがない。
下も同じような指摘。考えてみると、派遣プログラマとか請け負いプログラマは、いいプログラムを書こうとするだろうか。最低限のプログラムを書いて、早く家に帰りたいというのが本音ではないか。長期的な信頼関係なくして、いいものを作りたいと思えるか？また、プログラマをすぐ変えるようでは、引継ぎの問題がある。プログラムは簡単に引き継げないだろう。自分が書いたプログラムでさえ、数ヵ月後に理解が難しくなるのだから。プログラマは簡単には交換できない。

教科書的なソフトウェア工学から進んで、日本のソフトウェア開発の問題点について分析した良書。

PDFの最後の部分。以下の部分が秀逸。

「プログラマ予備軍を大量採用したメーカ子会社に対しメーカ本体は仕事を発注せざるを得ず，その結果自分は管理業務と称する雑務を行いプログラミングの現場から遠ざかった．子会社は地元取引先に発注し，やはり管理業務に専念することとなり，結局メーカのプログラマはプログラムを開発しなくなり，実力がどんどん低下してしまったのが空洞化の原因である．こうして出来の悪い人間の作ったプログラムから無尽蔵に発生するバグの管理を出来の良い人間が行うというパラドックスが日常となった．」

プログラムって製品の大事な部分であり、難しいにもかかわらず、外注するってのがまず間違いな気がする。ソフト工学の取り組みって、プログラマがだめなのに、それに目をつむって何か改善するパターンがある気がするけど、結局、実力（設計力とか実装力とか）がないと、だめな気がするよね。

これもいいことを言っている。
「自らバリバリとソフトウェアを開発したことがないメーカーの正社員が仕様書を書き、実際の開発は子会社や関連会社に任せる上に、その子会社においても実際のコーディングは派遣社員が行うというゼネコン型ソフトウェア開発。これでは、本社から送られて来たレシピどおりにパートの人たちが料理をしているファミレスと同じだ。
一流シェフたちが腕を競う高級レストランのように、シリコンバレーのトップクラスのソフトウェア・エンジニアたちが、自ら仕様を決めながら魂を込めたコーディングをしているアップル。圧倒的な差がつくのは当然だ。」

非常に重要なことを言っている。

これに関しては、自信を持って言えるのだが、「どんなに優秀なエンジニアでも、決してプログラムを自分自身で書かずに良い詳細仕様を作ることは出来ない」という絶対的な法則があるのだ。私の知っている優秀なエンジニアは、皆それを知っており自ら実行している。もちろん、彼らはプログラムを書き始める前に大まかな設計をするのだが、十分な経験を積んだエンジニアは、その段階でのものが「仮設計」でしかないことを良く知っている。だから、その段階で詳細設計書を書くような時間の無駄使いはせず、すぐにプログラム（もしくはプロトタイプ）の作成にかかるのである。
実際にプログラムを書き始めて初めて見えてくること、思いつくことが沢山あるので、それを元に柔軟に設計を変更しながらプログラムを書き進めるのである。作っているプログラムが予定通りに動き始めてやっと、設計も完成に近づくのである。（ただし、そんな作り方で作ったプログラムはソースコードが汚くなってしまうケースが多いので、この段階から出来上がったプログラムを、読みやすさ・メンテナンスの高さを重視して大幅に書き直すことを強く薦める。エンジニアによっては、ここで一度作ったプログラムを全部捨ててしまってもう一度全部作り直す人もいるぐらい、この作業は重要だ。）

こちらも重要。

少し誇張した書き方になってしまったかもしれないが、これが私なりの解釈である。SEの役目を、本来の「客が何を欲しがっているか、何を作れば喜んでもらえるかをソフトウェアエンジニアに伝える（要求仕様）」ところにとどめておけばよかったのに、ソフトウェアエンジニアの不足を補うために「どうやって作るか（詳細設計仕様）」という所まで踏み込ませてしまったのが間違いの始まりだったのではないだろうか。そのために、ソフトウェアを作ったことのないSEが詳細仕様を書く→ソフトウェアエンジニアが単なるコーダーになり地位と賃金が下がる→労働環境が悪化する→優秀なエンジニアがやめてしまう→やむなくソフトウェアの基礎を身に付けてない人たちを雇う→ますます良いソフトウェアを作るのが難しくなる、という悪循環に陥ってしまったのではないだろうか。

なかなかおもしろい。

読んでないけど、とりあえず、リンク。

最近、アジャイル気になり始めたし。「アジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。 」ほう。
「アジャイルソフトウェア開発手法の多くは、反復 (イテレーション) と呼ばれる短い期間単位を採用することで、リスクを最小化しようとしている。 1つの反復の期間は、プロジェクトごとに異なるが、1週間から4週間くらいであることが多い。アジャイル開発手法においては、開発対象を多数の小さな機能に分割し、1つの反復 (イテレーション) で1機能を開発する（⇒反復型開発）。」

ソフトの複雑さの尺度。

日本語版の方が情報量が少ない。線形的に独立した経路の数って何だろう？互いに含まれない？

海外に投稿するなら。

日本ソフトウェア科学会

東大から法政大学に移られた。個人のページ。研究室のページとかなくて、さびしい。研究内容はむかし東大のページに書いてあったんんだ。

適応型オブジェクト指向計算モデル(Epsilonモデル，McJavaなど)/分析/設計のためのモデル化技法/形式手法(形式仕様記述，検証，モデル検査など)/ソフトウェア要求工学/オブジェクト進化論，ソフトウェア保守，など

「ソースコードに含まれる「複製（クローン）」を検出するツール CCFinder および一連のクローン分析ツール，ソフトウェア部品検索エンジン SPARS，メトリクス計測フレームワーク MASU，Java プログラムの実行時情報分析ツール Amida 」など。

大阪大学　大学院情報科学研究科　コンピュータサイエンス専攻　ソフトウェア設計学講座　ソフトウェア設計学講座 楠本研究室　「ソフトウェアの高度化、大規模化とこれに伴う開発コストの増大に伴い、ソフトウェア開発において、生産性の向上と品質の確保が重要な課題となっています。そのための有用なアプローチとして、ソフトウェア開発の分野において、他の科学、工学分野と同様に、計測、定量化と評価、そしてフィードバックによる改善という実証的手法（エンピリカルアプローチ）が注目されています。」とのこと。具体的には、「食品流通等におけるトレーサビリティの概念を，ソフトウェアの開発過程に応用することで，「いつ、どこで、誰が、どのように」開発したものであるかというトレーサビリティ情報を「ソフトウェアタグ」としてソフトウェア製品そのものに添付します．」とのこと。あと、モデル検査、ＭＤＡ、アサーションの研究をしているようだ。

電気通信大学 情報理工学部　総合情報学科 経営情報学コース　「ソフトウェア工学(Software Engineering)とは、 「よい」ソフトウェアを生み出すための学問体系です。 西研究室では主に、ソフトウェアテスト、組込みソフトウェア工学、プロジェクトマネジメント などについて研究しています。」とのこと。研究テーマは、「現在扱っている研究テーマ/バグのナレッジマネジメント/バグの状況に応じた適応型テスト設計/ソフトウェア開発における技術者のモチベーションの向上/ソフトウェア開発におけるリスクマネジメント/データフローパステスト法の検証と改良/ミッションクリティカルソフトウェアのためのテスト設計/プロセス改善とTPS/ソフトウェアにおけるすり合わせ開発/Wモデルにおけるテスト設計/サービス・サイエンスなど」とのこと。

「オブジェクト指向」「モデリング」「プロセス」が中核とのこと。相談したら、ＯＯで、ＵＭＬ描いて、開発手順とか、指導してもえるのか。学生のときは結構勉強して、いいね！と思っていたが、最近はオブジェクト指向興味なくなった。設計の仕方とか、いろんな流派ありすぎて、少し疲れましたのさ。何でもオブジェクト指向でやったら、いいわけでもないよね、きっと。考えてみると、ソフトウェア工学関係のツールって、ＵＭＬツールとかって、重たかったり、あんまり使いたいものではないな。プライベートでもインストールしたい！っていう軽さが必要ではないか。って、豆蔵とあまり関係ないことを書いてしまった。

残念ながら組織改編で東芝のソフトウェア技術センターはなくなった。上は昔のサイトのバックアップ。

東芝ソフトウェア技術センターは、2015年4月に東芝インダストリアルICTソリューション社の技術開発部門であるIoTテクノロジーセンターの一部門として組織が改編されました。そのため、当ウェブサイトは、2015年11月30日をもちまして閉鎖させていただきました。

なくなったぽい。昔の私の紹介。

先端ソフトウェア基盤技術、ソフトウェア設計・検証技術、ソフトウェア開発管理技術の３本柱。中身を見ても特に特徴は感じられない。けど、ソフトウェア技術は、特に目立たない存在でもいいのかもしれませんね。

http://www.toshiba.co.jp/tech/review/2009/04/index_j.htm 東芝レビュー200904にはソフトウェアエンジニアリング特集があった。

『The Joel on Software』って有名ですよね。まだ読んでない。

ソフトウェア開発に関する文章の翻訳。

Paul Grahamはプログラマだったが、作ったサイトをYahoo!に売却し、ベンチャーキャピタリストになった。プログラマだったら一度そのエッセイを読むと、興味ある人ははまるだろう。大企業のソフトウェア工学と、ベンチャーやスタートアップのソフトウェア工学は違うことに気づく。大企業の人間でも参考になるだろう。

実践的な授業で、本当の開発の経験のような体験ができるようです。強烈な体験ですね。文章がわかりやすい。

まとめはこのあたり。123

こんなwikipediaの項目があるとは。。。しかし、いい記事だ。

IT業界には企業・人材・雇用など様々な面において消長盛衰が著しく不安定な一面がある。2000年代半ばになるとライブドア事件やニイウス コーの経営破綻などを筆頭に、多くのITベンチャー企業・ITソリューション企業で粉飾決算や乱脈経営が露呈したり、ひとたび収益性が悪化すればコスト削減を名目に人材削減を安易に繰り広げるなど、経営陣の派手な言動や浪費とは裏腹のお粗末な企業経営の実態が次々と露見し、少なからぬ企業が経営破綻や撤退・事業譲渡などの形で消えていった。また、末端従業員が置かれているデジタル土方や新3Kと揶揄されるほどに劣悪過酷で労働環境[3]、人海戦術とデスマーチが横行し[4]一向に成熟できないIT業界の人材育成・人材運用のシステム、毎月の様に現れる新製品・新技術に追われ続ける末端スタッフの実情、末端従業員を次々と雇い入れては低賃金で使い潰していく搾取型のビジネスモデル、ITゼネコンとそれを支える下請けブラック企業といった日本特有のIT業界の多重請負構造といった実態が、元従業員の証言やインターネット上の情報などの形で数多く槍玉に挙げられ、求職者や就職活動中の学生の側からも不安視される様になった。これらの結果として、2000年代後半に一時的に景気が回復すると情報処理産業は不人気業種と化し、IT業界は新卒からは忌避され、同様に業界下層で働く若年層や壮年層の労働者も、せめてIT業界ほど不安定・過酷ではない他業種への転職を求めて続々と離職してゆく、「IT業界離れ」の様相が見られる様になった。

よいプレゼン、斬新。「納品しない受託開発」。

たしかにエンジニアにコミュニケーション能力を求めるのは、求めすぎかも。エンジニアの論理的、理系的な興味は、コミュニケーションの無いところで、追求されることが多い気がするな。それにしても、ひろゆきは頭がいいなあ、と感心する。

ソフトウェアで企業するなら参考になるかも。

常に進化することは大事そうですね。

これは熱い。「開発に関わる人材はどこの会社も欲しがる精鋭ぞろいですが、同社はスタッフの退職率が低いことで有名です。それには秘訣があるのです。この会社、就労環境を極力自由にし、開発者が床でゴロゴロしながら仕事しようが、仕事中にゲームをやろうが、何を食べていようが、どんな服装だろうが、自由にしてるというのです。職場には無料のゲームや食べ物が沢山用意されてます。オフィスのインテリアには莫大なお金をかけて、会社にいたくなるような環境を作り上げます。組織体制は可能な限りフラットにしています。」

紹介。「計算可能性と計算量について、プログラミング言語を基礎に置いて 平易かつ統一的に説明するのに成功している良書。 もちろん、部分計算など、Jonesならではの話題も充実。 （ただし誤植がかなり多いので注意 － 再版でかなり修正されるそうです） 」らしいよ。

遅れているソフトウェアプロジェクトへの要員追加がさらにソフトウェアプロジェクトを遅らせること。

「われわれの抱える主要な問題は、そもそも技術的ではなく社会学的なものである」

ソフトウェア産業における過酷な状況にあるプロジェクトを指す。死の行進、死の行軍。

表面的な感じがする。

エリック・レイモンド　オープンソースの解剖学四部作の翻訳のPDFがあるよ。「伽藍とバザール」とか。

池澤あやかさんは女優であると同時にソフトウェア開発者だ。このような才能ある人にプロジェクトにいてほしいと心底思う。きっといないけど。

実は過剰品質ということはないだろうか。そして、やばいときはやばいらしい。

もちろん、ヤバイ時はヤバイです。でもそれって銀行だからどうこうではないでしょ。銀行システムは先に述べた通り、どうしてもエビデンスの検証とか、テストケースがアホみたいに多いとかがあるため、他のところから来た人がいつもの感覚で見積もってWBS引いたら後で全然足りないことがわかって青ざめる、みたいなトラブルになったりしますけどね。ヤバイの大半は見積の失敗や値引きやユーザの動きが悪くて結果としてみたいな原因がちゃんとあります。ぶっちゃけ自分たちのせいじゃね？

しかし、進歩もしているようだ。

まあ、そういう社会性のあるシステムです。多分、別の業界の人が見たらアホかと思うようなテストの山、紙の山です。銀行システムのテスト工数が削減されない一番大きい理由はエビデンスの検証作業を決しておざなりにしないこと、その結果としてペーパーが増えてしまうことです。
しかし、それは高コスト体質の原因だということはわかっているので、改善をしようという努力はされています。リファクタリングが銀行システムでほぼ有名無実なのは、変更したモジュールのロジックが本当に使われているすべての機能に影響を及ぼさないかを必ず検証しなければならないということにあります。つまり、大量のリグレッションテストが必要な変更はできるだけ避けるということです。
しかし、それでは例えばSOAやらなんやらのコンセプトを導入してシステムを疎にした成果が得られたとはいえません。なので、テストの自動化については真剣に取り組んでいます。結果として、死んだ目をしながら端末を叩くテストフェーズというのは削減されつつあります。
また、テストの内容についても、リスクベースでのテストケース作成の考え方を取り入れつつあります。つまり、「全てを完璧」というのは費用対効pp果が悪すぎるため、問題が発生する可能性がある箇所を重点的にやりましょうということですね。そんなの常識じゃない？と思う人もいると思いますが、常識ではありませんｗｗｗ自動化の目的だって、「自動なら全量テストするの簡単だもんね（2回目以降はな！）」ですからね。これ、本当はシステム開発のあり方としては他のほうがおかしいって言っちゃえるかもよ。

新規開発が出来ると思うな。10年以上経ったシステムのお守りがほとんど。当然コードは見るに堪えない。そのくせ仕事はたくさん来る。ほとんどがバグ修正か機能拡張。そして時間のほとんどはテストで消える。1行修正するだけでも数週間のテストが普通。OSが変わったら一年中テストで潰れる。

ソフト構造がしっかりしてれば、影響範囲が絞れるとか、そういう手法が必要かもしれない。

マージソフト。DFってソフトもあると思います。DFはマージもできたっけ？私はWinMergeを使っています。

マインドマップツール。設計とかテストとかに使おうぜ。たしかJava依存だったっけ。ちょっとそこは好みじゃない。

プロジェクト管理のMicrosoft Office Projectのクローン。かなり使えそう。参考：フリーソフト「OpenProj」 - GIGAZINE

Webベースのバグ管理システム。チケット駆動ってやつですね。ガントチャートも作成できますがあくまでチケットベースなのでビジュアルにガントチャートを編集するには有料プラグインが必要だったと思います。デフォルトではガントチャート管理には向いていないと思います。

シンプルなテキストファイルで UML が書ける、オープンソースのツール。テキストでUMLを作成するツールの本命だ。

UMLもかけるWebサービス

オンラインでGraphvizが使える。画像を出力して保存できる。問題構造図を描くためによいかなと思う。テキスト派閥なんですよ。GUI編集派閥よりはね。

textでシーケンス図がかける

プロならキーボードもこだわろう。私は仕事で使っている。静電容量で省スペース、打鍵感もよい。ブルートゥースならPCから離れても入力できるよ。って、どんなシチュエーションよ。

プログラミング入門なら、この一冊をおすすめすると思う。ただし、計算機の仕組みとプログラミング言語は密接に関わっているんだ。計算機アーキテクチャもわかったほうがいい。次の本、ヘネパタ本をおすすめする。