サーキット・シティ：戦略なきIT投資の“罪と罰”
http://www.ciojp.com/contents/?id=00002832;t=42
だが、先進的な機能やサービスの提供基盤となっていたこのPOSシステムも時代の波には勝てず、度重なるカスタマイズによって複雑化するとともに陳腐化してしまった。そして、しまいには頻繁にクラッシュを繰り返すようになり、それによってレジに行列ができるといった状況も珍しくなかった。さらに、システムの運用管理にも多大な手間とコストがかかるようになっていた。(中略)
POSシステムだけでなく、当時の同社のシステムの中には、もはや開発者を見つけられないような古いコードで書かれたものがたくさんあった。
うーん，ありがちな話だね．こういう苦労は洋の東西を問わないようだ．異なるのは失敗から学習するかしないかという点だな．
業績が落ち込み始めると、ほぼすべてのITプロジェクトが見直しや延期の対象になり、長期的な効果を見込んだプロジェクトについては、投資自体が凍結されてしまった
そうそう．一度品質が下がると悪循環に入って，あとは坂道を転げ落ちるように品質は悪化の一途を辿る．一度その段階にはいると，それ以上転げ落ちないようにするだけでも必死だ．だから品質については常に先手を打つことが極めて重要になる．*1
いずれにしろ、以上紹介した同社の経験からは、企業が生き残っていくうえでは、明確なビジョン、焦点を絞り込んだ経営戦略、リーダーシップが重要だということを学ぶことができる。
うーん．．．．
これは望み薄だな．経営戦略もリーダーシップもなしで突き進み，当たって砕けるのが日本的経営の特徴の一つだぞ．
*1:「割れたガラス」や「腐ったリンゴ」に喩えられる．たった一枚でも割れたガラスを放置しておくと，「もう一枚くらい割っても誰も気にしないよな．」という心理が働いて2枚目のガラスが割られる．そして3枚，4枚と次々にガラスを割る速度は加速し，最後には全部のガラスが割られてしまうというもの．技術者が品質に拘るのは，別に伊達や酔狂，趣味や美学じゃなく，そうしない限りはまともに動く物が作れないという現実的な判断のためなのです．
無能な上司の心配事
http://satoshi.blogs.com/life/2006/03/post_8.html#comment-15223017
コメント欄より．
気にしているのはリスクだと思います。
気にするだけなら馬鹿でもできる．
若くて高度な技術力を持ったエンジニアは、たしかに何も言わなくても何でもソツ無くやってくれてありがたい反面、
いくら優秀でも何も言われなければ何もできませんよ．
「早くしろ，そういうことは 早く言え．」
という川柳にある通り，コミュニケーションスキルに欠ける上司はお荷物以外の何物でもない．
じゃあその人（たち）が途中でごっそり居なくなったら（病気になってぶっ倒れたら、もっと待遇の良い会社に引き抜かれたら）どうなるのか？その開発プロジェクトは一気に危機的な状況に陥るかもしれませんね。
それは多重下請け構造とは何の関係もない議論だ．確かに少数精鋭の開発で，その少数のコアメンバーが抜けると危機的状況になるのは事実だが，多重下請け構造はその解決策にはなっていない．*1
多重下請け構造においては誰も抜けなくてもプロジェクトは危機的状況に陥るし，引き抜かれなくても多くの人間が抜けているし，その結果さらに輪をかけて危機的状況に陥っている．人を追加すればそれでうまくいくというのも『幻想』に過ぎない．*2
結局こういう議論が出てくるのは，現実が分かってない人間が開発を論じているせいなのだろう．人数を増やせば増やしたこと自体が大きなリスクになる．設計と実装を分離すれば，分離したことが致命的なリスクになる．その致命的リスクをカバーするために要員の追加が必要になり，追加した要員自体がまたリスクを増大させる．こうして多重下請け構造や設計と実装の分業ははリスクを雪だるま式に増大させることになる．
そうして増大したリスクは一部の中心メンバーの負担となり，その中心メンバーに万が一のことがあれば*3，プロジェクトは一気に危機的状況に陥る．またそういう命がけの仕事であることが分かっているので，そういう修羅場からは有能な人から辞めていき，現場の技術力低下を促進する．現場の技術力が下がればなお一層リスクは増大する．あとは悪循環．
実際には多重下請け構造はリスクを増やしこそすれ，減らすことはない．しかし開発の現場を知らない素人マネージャーはそういうリスクを理解する能力がないため，今日も同じ失敗を繰り返していることだろう．*4
品質はどうでしょう？開発の全工程を少数精鋭固定メンバで実施すると、仕様から設計に落とし込む際に、プログラムコーディングの都合の良いように仕様を解釈したり、考慮漏れが発生しやすくなるというリスクがあります。
これもウソだ．*5
上の記述は仕様が完璧であることを前提にしているが，仕様が完璧であるなど誰が決めた？単に都合の良いように仕様を曲解すればそれはバグだが，しかし実際には仕様自体が曖昧だったり，仕様自体に洩れや抜けがあることの方が多いだろう．だいたい良い仕様書を書くのはプログラムを開発するよりも時間がかかるものなのだ．開発経験も満足にない設計者が短期間で作る設計書やら仕様書やらが使い物になるわけがない．
「設計書を書くコスト」と「設計書を解読するコスト」と「設計書のミスを修正するコスト(設計者の失敗の尻拭いをするコスト)」などがそのまま１００％（以上）の無駄になる．「設計者などいない方がマシ」というのはこういうことだ．*6
つまり、昨今の多様化、複雑化した要求仕様から設計して、製造して、試験するという一連の作業をそこそこの生産性で品質よくトータルに実施するというのを、「上司たち」はオーバーワークじゃないかと思うわけです。
それは多重下請け構造とそれに伴うウォーターフォールモデルの致命的欠陥を示しているに過ぎない．システムが複雑化すればするほど，多重下請け構造とウォーターフォールが致命的なボトルネックとなっているのだ．
それと「設計した人が製造もやった方が良い」というのは別問題だと思っています。
プログラミングは「製造」ではない．
まずいのは、新人から上級マネージャまたは上級エンジニアに至るまでのキャリアパスが曖昧になっていて、各段階での育成方法が確立していない、下手をすると議論すらされていないという状況下で、多くの人が不況にもがき、解決に向けて投資もままならない・・・という現状に不安を感じているということじゃないでしょうか。
論点がズレている．
開発者が上級マネージャになるわけじゃない．上級エンジニアは今の日本企業じゃほとんど幻想．キャリアパスが『曖昧』なのではなく『存在しない』のが問題とされているのだ．
*1:この議論は，その昔にあった経営リスクを回避するための「経営多角化」の議論と似ているな．その昔は一つの分野に重点を置きすぎると，その商売がダメになったときのリスクが大きくなるので複数の分野に幅広く展開した方が有利だと，まことしやかに語られていた．でも実際には複数の分野に手を広げても，それぞれの分野でNo2,No3になるのがやっとということの方が多くなってきた．これは国際化もその一因かもしれない．しかもNo1とNo2以下では収益率が大きく違うことが多く，複数分野でNo2以下に甘んじるよりも，一つの分野に全経営資源を集中してNo1を取った方が良いというのが，最近の傾向だと理解している．IBMのHDDやThinkpadの売却などがその例の一つ．逆に「総合」なんとかという感じの手広くやっている所は，苦しい戦いを強いられている．もちろん米国産牛肉の輸入禁止で大打撃を受けた「吉野屋の牛丼」のようなリスクもあるが，だからと言って「経営多角化」はその解決策にはならない．
*4:１＋１＝２は算数では正解だ．開発では１００＋１００＝２００にはならない．１００＋１００＝１００のこともあるし，１００＋１００＝５０のこともある．
*5:自称『設計者』などだけが，そのような主張をしているだけ．
*6:感覚的にいうと，こんな感じ．
合計で1億円の予算があるとします．設計書の作成に3千万を使いました．設計書の解読と書き直しに3千万使いました．3千万使って実装しました．最終段階まで来ると設計書に矛盾があり，設計書通りに実装しようとしてもそのままでは実現できないことが判明しました．そこから1千万使って設計書の矛盾を修正しました．4千万使って実装をやり直しました．それからテストとデバッグを行いました．
さて最初に作られた設計書の適性価格はいくらでしょうか？
RTLを知らない半導体設計者
http://satoshi.blogs.com/life/2006/03/post_8.html#comment-15173457
RTL(Register Transfer Level)設計をしたことがない人間が旨い仕様なんか作れる分けないのに、無意味に分業し、しかも、RTLやSystemCによる「テスト」を軽視。何度も繰り返しが起こり、かえって工数を増やしてます。仕様検証を人手、しかも基本的には机上／目視チェックのみでなんとかしようという考え方。複雑な規格に対応するんでなければこんなやり方でもうまくいくのかもしれませんが。
どうも異常なほどに(日本の)ソフトウエア業界の持つ病状と似ている．
実は背後で同じ組織が暗躍しているとか？
ひょっとして，無謀にもUMLを使ってたりするのかなあ．．．．
試しに検索してみるとこんなものが．
ソフトウェア分野では業界標準となりつつあるUML*1によるオブジェクト指向手法*2をシステムLSI設計に適用した事例について*3、その有効性や今後の課題についてご講演頂いた。
同フォーラムは，もともとソフトウエアの仕様策定向けに開発されたUMLをハードウエア向けに拡張することで，システムやSOC全体の仕様策定に使えるようにすることを目指す。そのために，(1)UML記述の再利用性や流通性を上げるため，UMLのモデリングにガイドラインを設ける，(2)並列動作や構造，時間といったハードウエア特有の要素を記述するための拡張を行う。
http://techon.nikkeibp.co.jp/members/01db/200211/1010399/
．．．．もし本当なら，これは最悪な設計手法なんじゃなかろうか．*4
LSI設計は，文字通りにハードウエアに密着した部分だ．アセンブラよりも，なおハードウエアに近い部分にある．UMLはソフトウエアの世界でも親和性の悪さから鬼門となっているのに，それをハードウエア設計に使うなど正気とは思えない．
そもそもUMLの弱点に「並列処理にむかない」というのがある．しかし，悲しいことにハードウエアレベルでは，様々な並列処理のオンパレードなんだよね．さらには発熱や時間遅れやその他諸々のアナログ的な処理も必要となるだろう．UMLに表現できるとは思えないし，UMLを使うメリットが有るとも思えない．
UMLは，グラフィカルな表記法なため「人が見てわかりやすい」が，コンピュータ上で実行可能でない。
これもウソだな．UMLは決して人が見て分かりやすいものではない．
条件分岐やループが入ると特にそうだ．並列処理に至っては満足に表現することさえできない．
