ソフトウエア開発を理解しない人々

http://itpro.nikkeibp.co.jp/article/COLUMN/20060327/233447/
またこれか.

品質を向上させる最も基本的な取り組みは,一言でいうと手戻りを減らすことである。

ダウト.

手戻りの少なさは良い開発を測る指標の一つではあるが,絶対的な指標というわけではない.ましてやそれは品質向上の最終目的でもなければ,手段でもない.

手戻りを減らすことによって改善を進め,技術者のモチベーションを高める。モチベーションが高い職場は自ら改善していく。

ダウト.*1

手戻りの削減とモチベーションの因果関係はほとんどない.モチベーションを下げるには「横並び評価」や「年功序列」「成果を測らない『成果主義』」を使えば簡単.

現在,組み込みソフトウエア技術者の大半は,「ハードウエアより低い品質でも仕方がない」と思っていないだろうか?

ソフトウエア開発はハードウエアでいう製造ではなく設計に相当する.*2

ハードウエアの製造における「品質」とハードウエアの設計における「品質」でさえ,同列に比較するには無理がある.ましてやハードウエア製造における「品質」とソフトウエアの設計における「品質」とを比較するのは論外だ.

連日の残業で1カ月の残業時間が200時間を超えていたり,毎日終電で帰ったりというソフトウエア技術者は非常に多い。結果として,心の病が原因で会社を辞めていくエンジニアも多々見受けられる。その割合は,他の業界よりも圧倒的に高いだろう。

その責任は,役に立たない開発プロセス標準やその他の「製造技術」を,手を変え品を変え現場に押し付けてきた者にある.

ソフトウエア開発は製造ではなく設計である.

その事実を直視すれば,ハードウエアの製造技術をソフトウエア開発に適用することが危険であるか想像に難くない.

そうした状況を変えるために,品質や信頼性を高めて手戻り作業を減らし,不必要な仕事を減らしていこう。

そんなことは言うまでもなく分かってる.問題なのはどうやって品質を向上させるかだ.

そこで問題となるのが,ソフトウエアの本質を理解せずハードウエア製造のやり方をごり押しして生産性を低下させる素人の存在だ*3.彼らは全く不適切な手法を,不適切な場面に,不適切なやり方で押し付けてくる.その結果として生産性や品質が低下するのだが,そうなっても彼らはなんの責任もとらない.そして同じ間違いが今も繰り返されている.

デスマーチから抜け出し,高いモチベーションを持った笑顔あふれる開発現場を作っていこう。現場がやる気を出しさえすれば,プロセスの改善や新技術の導入によってチーム内の教育が活発になる。

前半は単なる精神論*4.後半は間違った方針.

後半の方針を徹底すればするほど生産性は低下する.現場が反発するのはそのためだ.

そして予定通りに導入に失敗すると,責任者は前半の理由を使って現場に失敗の責任を押し付ける.

現場が幸せになれば,自然に品質は向上するのだ。

ダウト.世の中そんなに甘くない.

どんな気分であろうとも,最高の品質のために自分の技術を駆使するのがプロだ.もちろん品質が良くなれば気分も良くなるかもしれないが,上は原因と結果を取り違えている.*5

*1:少なくともお金くらいは出してね.

*2:http://www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html

*3:たとえばCMM開発プロセス標準などと呼んでいるものがそれだ.

*4:こういう人によると,愛国心さえあれば竹槍でB29も落とせるんですよね.私には真似できませんね.

*5:努力によって品質が向上しても,上のような寝言をほざく奴にその成果を横取りされたら,はらわたが煮えくりかえるだろうな.

「なんとかManagerクラス」から漂う危険な臭い

http://www.radiumsoftware.com/0603.html#060330
http://c2.com/cgi/wiki?CodeSmell
メモ.

それこそ "Manager" という名前が相応しいかもしれないが,それはひとつのクラスに機能を集約し過ぎている。(中略)いわゆる "code smell"は,他にも幾つか見つけることができる。例えば "Object", "Handler", "Data" などがこれに含まれる。

「getter/setterの多用」というのもありかな.特にUMLモデラーに顕著に見られる.


http://en.wikipedia.org/wiki/Code_smell

  • Inappropriate intimacy - a class that has dependencies on implementation details of another class.
  • Refused bequeath - a class that overrides a method of a base class' such that the contract of the base class is not honored by derived class. See Liskov substitution principle.

あー.見たことあるな.嫌と言うほど.....

おそらく日本ではLiskov substitution principleを理解している人の方が少ない.LSPを知らない継承は継承の誤用以外の何物でもないのだが.