富士通 経営方針説明会

どこかで聞いたような話だ．

10月の下方修正の時点で、ソフト・サービス事業で約150億円のマイナスが出ることがわかったのに続き、1月にはこれが300億円、さらに、最終的には570億円と大変な額の狂いが生じた。最大の要因は、SIの不採算プロジェクトの損失であり、これが400億円にのぼった。また、官公庁関連の工事関連で170億円程度の損失が出た。2001年から2003年前半までの富士通が苦しい時に、必死になって受注した案件が不採算案件となっている」とした。

　こうした不採算案件は、135件にのぼっているが、そのうち22件で全体の80%近い損失を占めており、しかも、2003年下期までの受注が99%を占めたという。
http://pc.watch.impress.co.jp/docs/2005/0525/fujitsu.htm

必死になって「出血大サービス」で採った案件が首を絞めたと．

不採算案件の多くは2001年から2003年に作業を開始している。黒川氏は「個人プレーによる営業が多く、案件の取り方（見積もり）が甘かった」と話す。案件を精査しないまま受注してしまい、しかも「営業やSEが『顧客との交渉によって収支を改善できる』と言ったために様子を見ていた」（黒川氏）ために、結果として傷を広げる形となった。2005年3月期は、同社のSEのうち、33％が不採算案件に携わっていたという。「優秀な社員ほど不採算案件に回す必要があり、新規案件に対して機会損失を招いていた」（黒川氏）
http://japan.cnet.com/news/biz/story/0,2000050156,20083867,00.htm

SIにおいては営業にかかる責任は極めて重いということだろう．営業は見積もりや価格交渉に関わるが，この段階で見積もりミスが生じていると開発現場でどれだけ頑張ろうとも成功はおぼつかない．そういう意味ではプロジェクトの成否の半分は営業が担っていると言っても過言ではない．だから営業は営業本来の「売り込み」の技術以外に，技術的な知識も非常に高いレベルで求められる．*1

「優秀な社員ほど不採算案件に回す必要があり、新規案件に対して機会損失を招いていた」は笑えないな．不採算案件≒デスマーチ*2を抱えている企業ならどこにでもある話だけに．

とはいえ「社員が働かないから赤字なんだ！」などと全社員を敵に回すような暴言を吐いていたころよりは格段にマシになったと考えて良いのだろう．原因が曖昧で責任不在な状況では同じ失敗を何度でも繰り返す．状況と原因を明らかにすることで，次の対策も打てるようになるし改善もできる．

*1:全ての営業が技術知識も持っているとは限らないだろう．とはいえ，もし「出血大サービス」で案件を取ってくると，その結果本当に血を吐くのは開発現場になる．そういう出血大サービスを安売りする営業が一人でもいると会社にとって大きな損失を産むだけでなく，開発と営業との根強い対立の火種にもなりかねない．

*2:帳簿の上では単なる「不採算案件」の一言で済まされることだが，現場ではそれを成功させるべく死にものぐるいの努力が繰り広げられている．「社員が働かないから赤字」なのではなく「社員が死ぬほど働いても赤字」なのだ．これは通常は「デスマーチ」とよばれる状態にあたる．まるで(悪い意味で)「プロジェクト×」の世界だ．

「Javaパフォーマンスチューニング 第5回 メモリ・リークの発見」

http://www.atmarkit.co.jp/fjava/rensai3/devedge05/devedge05_1.html
毎度のことだが，これをメモリリークと呼ぶのは間違いだと思う．

メモリリーク：既にそのインスタンスへの参照がなくなり，到達可能(reachable)で無くなったオブジェクトの領域が永久に解放されなくなる現象．

これに対しJavaで起こるのは，

そのインスタンスへの参照が残っており，到達可能であるオブジェクトの領域が永久に開放されなくなる現象．

である．これは肥大化と呼ばれる現象の一種で*1，通常はメモリリークとは呼ばない．
メモリリークは「死んだオブジェクト」がメモリを消費し続ける現象であるのに対し，『肥大化』は「生きているオブジェクト」がメモリを消費し続ける現象だ．生きているオブジェクトが解放されないのはごくごく当たり前のことだ．

これも何度か言っていることだが

GCは『プログラマーが今後二度と使わないつもりのオブジェクト』を解放するものではない．『二度と使われないことが保証されているオブジェクト』を解放する物だ．

二度と使われないことが保証されているということは即ち到達不可能であるということであり，それを「死んだオブジェクト」と呼ぶ．プログラマーが二度と使わないつもりでも到達可能なオブジェクトは，GC的には全て「生きているオブジェクト」と見なされる*2．メモリリークとは「死んだオブジェクト」がメモリを占有し続ける現象のことを指し，これはJavaのようにGCのある言語では発生しない．

ちなみにいわゆる「null参照クリア」は，一部のオブジェクトで必要になることもあるが，あまり好ましいコーディングスタイルではない*3．（少なくともJavaでは）null参照クリアよりは参照変数のスコープを小さくすることが推奨されている．

*1:それほど特殊な現象ではないため，これだけを区別する名称はおそらくない．これと同じことはどんな言語でもどんな環境でも起こりうる．

*2:このあたりはGCの基本的な性質になる．到達不可能なオブジェクトはいずれ必要に応じて回収されるが，その全てが即時回収されるとは限らない．また到達可能なオブジェクトについては，それが回収されることは絶対にない．もし到達可能なオブジェクトまで回収されるれば，アプリの正常な動作は保証されなくなる．これは即ちGCのバグである．

*3:null参照クリアは必ずしも必要ががない上に，記述漏れが発生しやすい．パフォーマンス的にも若干不利になる事が多い．少なくとも早くはならない．