デスマーチの作り方
http://itpro.nikkeibp.co.jp/article/COLUMN/20060309/232116/
とりあえず，すべての名詞がクラスになると仮定してクラス名だけのクラス図を作成すると図6[拡大表示]のようになる。
名詞抽出法は初心者の練習用がせいぜいだぞ．実用性はほとんどない．
(1)社長クラス，営業員クラス，事務員クラスは，複数の同じ属性を持っている。このことから，これらのクラスは1つのスーパー・クラス＊を継承＊したクラスとして整理できる＊2。ここでスーパー・クラスを「社員クラス」とする。
OOPの世界ではこれは明らかに継承の誤用となる．「設計者」や「UMLモデラー」が開発の足を引っ張る典型的な失敗パターンがこれだ．*1
＊２
【継承】succession
ここでは，クラスの機能を引き継いで他のクラスを作成するようなクラス間の関係を意味する。
専門用語としての「継承」は，普通は"inheritance"です．和英辞典で調べたんじゃあるまいな．*2
だが，図6のクラス図と比べると，クラスの数は11個から6個と少なくなるなど，整理されていることは誰が見ても明らかだろう。
何がどう明らかだというのだろう．これで納得するのは素人だけだ．
クラス数とシステムのシンプルさとの間には相関関係はほとんどない．むしろクラス数を減らす過程で無理な設計になり開発に支障を来すことの方が多いだろう．今回もそういう典型的な失敗パターンの一つだ*3．
プログラマの視点に立ったときに、保守性を高めるためにデザインパターンを活用して設計をする場合、往々にしてクラス数／メソッド数が増える（ステップ数とは相関しない）。クラスを増やすのに抵抗がある場合（例:クラス試験手順書・成績書を作成しなくてはならない）、納期プレッシャーの元ではそれを避けようとする力が働くことになるかもしれない。
保守性、品質について責務を持って開発の中に入って影響力を行使するような体制が必要です。
http://d.hatena.ne.jp/torutk/20060311#p1
特に今回の事例に関しては最初の候補が名詞抽出法で作られた物なので，比較する事自体が論外だ．*4
*1:「設計者」だとか「プロジェクトリーダー」だとかがこういう図を書き始めたら，そしてそれを「設計書」だと主張し始めたら，それがデスマーチ開始のサインだ．別プロジェクトに逃げるか，さもなくば転職することを考えよう．逃げられそうになく，しかも家族がいる場合は，遺していく家族のための生命保険や遺書の準備も検討すべきだ．準備には時間がかかるので，いざという時になってからでは遅いのだ．
*2:UMLだと用語まで違うのかね．というよりUMLにはOOPにおける継承が存在しないだけかな．あれはOOPとは全くなんの関係もない「21世紀のフローチャート」に過ぎないのだから．
*3:これもデスマーチ開始のサインなので，こういう時は上記と同様な対策をお奨めする．
*4:名詞抽出法で作られた「クラス」群は質が悪く，設計として考慮に値しないことが多い．「O(n!)のソートアルゴリズムと比較して３０％性能向上した」として，その性能向上に何の意味があろう．比較するなら平均以上，ソートアルゴリズムなら最低でもO(n log n)以上のものと比較すべきだ．
中国人の日本型開発アプローチに対する本音は？
http://www.atmarkit.co.jp/im/cpm/serial/offshore/16/01.html
うーん．．．．
これって「日本人の日本型開発アプローチに対する本音は？」じゃないのか？
別に中国人だからというわけではなく，まともな神経を持つ者なら日本人でも全く同じ事を考えてる．
多くの中国人技術者は、「出来上がってきたものを見てから修正する」という日本人のやり方に対して、以下のような否定的な見解を持つといいます。
- 日本人は、本来設計に掛けるべき時間と労力を省いている
- 日本人は、想像力や検討する力が欠けている
- 日本では、能力の低い技術者が設計している
参考までに日本人技術者の意見を述べさせてもらうならば，全くその通りです．
『設計者』を騙るのは設計する能力のない者と相場が決まっています．
ここでは、私たち1人1人が持つ、このような「こだわり」や「執着」のことを「コミットメント」といいます。
少なくともゴーン氏が日産で定義したコミットメントとは違うようだ．*1 *2
「拘り」というような精神論よりは，「契約」や「責任範囲と権限の明確化」のようなものが近い．しかもここで重要なのが，コミットメントの主体は担当者本人であって，上から一方的に無理難題ふっかけられる物ではないということ．
同じ中国企業の中でも、日本に対する態度や認識が異なります。こうした背景を知ることは、私たちが中国側の「日本式開発アプローチ」に対する本音を理解するのに欠かすことができません。
そんなもん，日本人でも同じだぞ．
脳のない管理職は現場に丸投げする．丸投げするからには，何に対しても「できます」と答える者に丸投げしておけば責任逃れできるので好まれる．
現場からすると，技術力が無くて何やっても失敗する人は，いかなる結果をも恐れない．失う物がないから何に対してもYESと答えることに抵抗はない．技術力が高く，より困難な物に挑戦する人は失敗を恐れるし，できないものに対してはNOという．
日本のソフトウェア業界では、「お客さまは神様です」という観念が根強く残っています。さらに、大半の日本人技術者は、社内で先輩から「ソフトウェア開発はサービス業である」と教えられてきました。従来、このような考え方が日本の経済発展を支えるうえで大きな役割を果たしてきたことには、疑いの余地がありません。
「顧客第一主義」は良いとしよう．「ソフトウエア開発がサービス業である」のもまあ良いとしよう．それと「日本の経済発展との因果関係」，及び「IT業界の発展への悪影響」については議論の余地が残る．特に後者については，上記の命題はむしろ悪用されることの方が多い．
実現不可能なものや，可能ではあるが現実的な時間やコストでは不可能な物についてさえも，「お客様のため」を口実にして現場に無理難題を押し付けるというのが従来ではまかり通っていなかったか．いや今現在もまかり通っていないか．それは不必要なコストを増大させ，結局は業界のためにもお客様のためにもならない．
- システム開発で修正が入るのは当たり前、やむを得ない
これは事実だ．
そのような修正が不可避であり，そのことも考慮してライフタイム全体でトータルにコストが最小化できるような技術が，OOPでありアジャイル開発だ*3．これに対して大半の日本企業では，現場に無理難題をふっかけてゴリ押しするだけに留まっているのが現状だろう．
- 顧客が直したいと望んでいるのだから、直すべき
それに見合う追加コストを支払う限りの話だ．だが営業の人間に変更コストのことなど分かるまい．
ここは一部事実だな．ただし実際にそれができる者は多くはない．
日本から変更要求が発生したとき、会社の存続と持続的成長にコミットする中国企業の経営層は、「正当な対価を支払ってもらえれば対応すべきだ」と考えるのが一般的です。
本来はそれが正常な思想だ．
対価ももらわずに自腹を切るのは，本来は自社に損失をもたらす裏切り行為に他ならない．
日本式開発アプローチに不満を持つ中国企業では、現場で以下のようなネガティブな思考パターンが支配的だと考えられています。
「仕様変更に対応」→「時間の浪費」→「モチベーション低下」→「生産性低下」→「昇進なし」→「昇給なし」→「離職」→「不安定で未熟な自分」→……と思考が変化していく
対照的に、現場からは「最初からそういう部分（仕様変更部分）をはっきりすればよかったのに、せっかく頑張って作り上げたものを、また変更するのは……」という意見がかなり多かったです。
受注側の立場だと、変更対応に当たった工数を加えて、お客さまが料金を払ってさえいただければ、特に問題がないと思いますが、実際問題として現場のモチベーションコントロールはかなり難しくなります。
．．．．それは中国に限らない．日本でも全く同じだって．
普通は言ってもしょうがないし，言ったら首を切られるから言わないだけ．
そこで、中国人技術者を日本に招聘して、現場の雰囲気を体験させようとする動きが以前にも増して活発化しています。
それって『洗脳』って言わないか？だから
ところが、実際には若い中国人技術者の間で日本出張を歓迎しないムードが広がりつつあることが、最新のインタビュー調査で明らかになりました。彼らは、言葉もままならない状態で日本に行くよりも、本国の快適な環境下でスキル向上を図ることを願っています。
こういう反応をするのも当然だ．私だって日本の現場でありがちな「お上のためなら片道燃料で出撃する」というプロジェクト×や体育会系のノリは大嫌いだからね．
すべての中国人（特に若手プログラマ）が日本式開発アプローチを理解するのは不可能だという前提で中国に発注する。
あんなものは日本人にだって理解できねーよ．
理解できないのを中国人のせいにするのは良くない．ある意味で極めて差別的な発言だ．
世界的に業績を伸ばす多国籍企業（GEやJ＆J）に目を向けると、彼らは国や個人の価値観よりも、企業文化・理念を優先させていることが分かります。
ちなみに「企業文化や理念を優先する」わけではなく，「現地の情勢を見極め，うまく折り合いを付けている」のだと思うが．このような舵取りこそが"management"だ．単なるゴリ押しは"management"ではない．
*1:「コミットメント：コミットメントは、必ず達成しなければならない目標のことです。これは、社員だけでなく、お客さま、株主、サプライヤーなど、すべてのステークホルダーに対する「約束」です。コミットメントを必ず達成することで、実績とともに自信も深まり、モチベーションが高まります。そしてさらに高い目標への挑戦を目指していくという好循環が生まれます。」http://www.nissan-careers.com/recruit/vision/glossary.html#a04
*2:「コミットメントという言葉は訳し方によっては「できる限りのことをする」というあいまいなもので、勝手な解釈も可能なのです。しかし、日産社内での解釈は「未達成の場合は具体的な形で責任をとる」というあいまい性の排除にその取り組みの本気度が表れています。
つまりコミットメントは、目標と達成責任を明確にすることで、社員の挑戦志向、変革志向を高めようとしているのです。このように、トップの変革への強い意志と、社員の主体的な変革への参画と能力の発揮を促すことが、企業改革の大きな梃子として作用するのです。」http://www.nri.co.jp/opinion/r_report/m_word/commitment.html
*3:XPのキーワード"embrace change"とは，本来はこのような思想とそれに付随する技術革新を表している．
*4:「(日本)IBMは資本は１００％外資，社長は現地人」というのが思想らしい．現地で生まれ育ち，現地の考え方を知り，現地の立場で行動することを社長に期待しての処置だろう．
もっとも，一口に多国籍企業だとか外資系だとか言っても，実際には千差万別のようだがね．
日本のITエンジニアは生き残れるのか
http://d.hatena.ne.jp/findup/20060312/1142185013
うちの会社がひたすらに巨大化を目指しているのもほぼ同じような理由からだと思うのだけど、その大手に社員として属していることが良いかというのはまた別の話だと思う。
これは全面的に賛成する．組織をそのままに規模だけを肥大化させれば，生産性は低下し，そのしわ寄せは現場に押し付けられる．企業の規模や売上と，そこに所属する個人の幸福とは何の関係もない．
仮に転職とかを考えたとき結果的に今の会社より「下請け」寄りの会社に入ってしまったら単純に失敗なんだろうなと。
それはそうだろうね．だからと言って，規模が大きいから成功かというとそうでもない．*1
うーん．．．．そんな企業が果たして日本にあるのだろうか．独自性が打ち出せるほど経営センスのある経営者なんてほとんどいない．
自分の売りかぁ、なんだろ。仮に何かあっても、それが自分の会社の外でどれだけ通用するレベルなのかってのが自信無いよな…。そういう意味で「ITスキル標準」が用意されたりしたんだろうけど。
いや．おそらく全く関係ない．
ITスキル標準が目的としているのは，技術者を交換可能な「使い捨て部品」にすることだ．*2
http://d.hatena.ne.jp/JavaBlack/20060305#p1
http://d.hatena.ne.jp/JavaBlack/20060204#p1
http://www007.upp.so-net.ne.jp/kengai/fowler/newMethodology_j.html#A47
そもそもITSSは器用貧乏な人を高く評価し，技術力の高い専門家を低く評価する傾向が極めて強い．このためITSSを導入した企業では高いスキルを持つ専門家が流出し，器用貧乏な「何でもできるけれど，何をやらせても上手くはない」人ばかりが集まる結果になる．*3
