IGINブルネイ/syasudaの日記(MT版)

困りましたねぇ。

最近、↓こんなツッコミを入れられてしまいました。

絶対に受けたくないソフトウェアエンジニアリングの新人教育 ふたたび

http://d.hatena.ne.jp/JavaBlack/20100421/p1#20100421fn2

何も知らないでIT業界に入ってきた初心者が読んで，変な宗教に洗脳されたら可哀想じゃないですか

これはその通りです。洗脳のために一票投じたのが先の日記なわけでして。

自分の頭で考え抜くような人は、非効率で古臭い体制の問題点に気づいて、凡庸な組織になじまなくなり、そこから飛び出してひと儲けしようとする気がします。あるいは新しい管理手法を編み出して組織を変革して本でも書いて一儲けできるんじゃないですかね。

↓突っ込まれた日記はこれです。

当たり前のことが通じないとき

http://d.hatena.ne.jp/syasuda/20100209/1265724849

ついでなので注釈を付けておきます。

例えば、いくら設計レビューの重要性を説いても、レビューをまともにやっていない組織では馬耳東風です。

設計書は書かなくても、レビューはどんな開発プロセスにおいても必要だと思います。なぜ必要かは書きませんが。レビューをやったことがないような組織では、カタチから導入するしかありません。レビューのしかたもレビューの受け方も分からないのですから。そこでいきなりレビューで実装や設計の問題点を指摘したりしたら、『個人攻撃された。』というネガティブな反応が返ってきたりして困るのです。

さて、レビューだけに的を絞った本はいろいろ出ているようです。読んだことはありませんが。

→この本は、日記の中で触れているケーパーズジョーンズさんの資料からも引用されているようです。

おそろしく詳細に設計してあれば、製造とテストは熟練者でなくてもこなせます。

これはデッドラインに出てくる「最終段階インプリメンテーション」の考え方を参照して欲しいです。（ウォーターフォール前提で）下流工程で出るバグを設計でたたき出せば実装以降を短縮できるとかそんな感じの話です。そのまま実践したとしても、設計に工数がかかるので、全体の生産性が驚くほど向上するとは思えませんがね。

個人的な感想ですが、この本に書いてあることは、世の中のソフト屋の過半数が普段やっていることです。*1つまり人間を3,4人連れてきたら、半分はそのやり方を知っているか慣れているということです。それを生かすべきか、無視するべきかどちらが良いかは各自で判断していただくしかありません。

「過半数」というのは根拠はありません。

ただし、いつの世も優れたやり方を実践している人は少数派で、多数派は(優れたやり方をしている人が言うところの)古臭くて間違っている状態にあると思っています。紹介した本に書かれているのは何十年も前からある"古いほう"(と言われている)ことも分かって書いています。

私がこの本を読むべきだと思ったのは、誤ったカウボーイ開発(ただの無秩序状態)を実践して混乱している人たちです。優秀なカウボーイが一人居れば体制や手法なんかいらないです。全てのコードの面倒を見て、すばらしい製品をリリースできるんじゃないですかね。それができずに炎上するだけの現場には処方箋が必要な気がします。

無秩序からいきなりアジャイルへ持っていくのが良いのか、古臭いウォーターフォールの滝つぼへ落としたほうが良いのかは管理ピラミッドの上のほうの人が決めることのような気もします。私のような下々の人間にはこうして一票投じるくらいしかやることはありませんな。