Go The Distance

トラブル案件に突っ込まれてる同僚と話をする機会がありました。その中で相当ひどい設計に基づいたコードが書いてあったようです。

トランザクションが開始された後にエラーがあった場合、なんとその後続のトランザクションを実行してしまい、尚且つ後続のトランザクションが正常に成功した場合は、そのトランザクションは正しく実行されると見做す設計らしいのです。

これを聴いた瞬間は「いくらなんでもそれは無いだろう」と思いました。ロールバックが考慮されていないシステムなんてあり得ないよねって。ネタでしょみたいな。でも、やっぱりガチらしいんです。そういうコードが散在してるため、おっそろしい勢いで障害出ている、と。

そしてすぐに、猛烈な殺意がこみ上げてきました。木刀で頭カチ割るぞぐらいの勢いで。システムを作るということをナメてますよ。プロ意識のカケラもありません。怒りを通り越して悲しくなりますね。

こういった愚かな設計によってシステムが構造的な欠陥を抱えてしまうその恐ろしさが、なぜわからないのか。

その欠陥によって実装されるコードの品質により、どれだけの人間が苦しみ、どれだけの人間がこの業界に疲弊して消えて行き、会社にどれだけの赤字がでると思っているのか。

ひとつの愚かなソースコードによって、億単位の赤字に直結するという意識を何故もてないのか。

このブログを読んでくださっているSE志望の学生さんや、新人SEの方。プログラミングには苦しいことも過多あります。だけど全ての基本はプログラミングです。技術力をつけろという真意は、システム上に構造的な欠陥を作り出すんじゃないぞという意味です。是非覚えて置いてください。

ステップ数っててっきり過去の産物なのかと思っていたら、結構現役なのね…orz

 

というのも某案件で、ある会社さんの報告資料にステップ数が見積もりの根拠にあがっていたのを見たからです。Java案件で。私がユーザー企業の立場だったらステップ数出してきた会社には頼みたくはない…。FPの方が全然客観性がある。

ステップ数というのはコメントや空白行を除いた、実際にソースコードを書く行数のことです。この業界では｢ソースのボリューム＝規模」だという考えがあります。

実際にコードを書く量を単純に作業時間と正比例させるっていう考えはどっから来たんだろう？

見積もりはSIerの競争力を示すバロメーター的なものだと思っています。未だにコレだ！という見積もり標準的なものがないことからも(あったらすいません)、見積もりの難しさを物語っています。だからこそ、競争力の差がでる項目なんだろうなと感じています。

リスクの定義って、「将来起こりうることの中で、悪影響を及ぼす可能性があるもの。」じゃないかなーと思っています。良い影響を及ぼすならリスクとは言わないよねぇ、と。悪影響の度合いは色々あるだろうけど、普遍的に言うとこんな感じかなと。

相当単純に考えれば、リスク回避をするためには不確定要素を確定要素に変えればいいと思っています。確定要素、つまり何が起こりうるか予想がつきその根拠が信じられるものだったらそれはもうリスクじゃなくなる、と。恐らくそれ以外リスクがリスクじゃなくなる方法は無いように思えます。

｢熊とワルツを｣という有名な書物では、リスク管理をこのように表現しています。

｢信じる権利があるものだけを信じること。｣

実に言いえて妙だと思います。信じるに足る根拠があるものだけを信じる、と。多分誰もが｢そんなの当たり前だろ」と思われるかと思います。でも問題なのは｢信じるに足る根拠｣が不正確、不明瞭なことが多いことではないでしょうか？

ちょっとでも不透明なら｢それはリスクが･･･。｣と言い出すラインマネージャやPMOにうんざりしている方も多いことでしょう。そんなこといったら始まらん、という性質のことにすら「リスク」という考えを当てはめようとするヒトもいると思います。何をもってリスクではないと判断するのか、というのが腕の見せ所というかリスク管理能力の是非を分けるポイントだなぁと思います。

# 麻雀ってリスク管理のゲームでもあるなぁ。

リスクを回避するキーワードは｢可視化｣じゃないかと思います。見えないことがリスクなんだから、見えるようにすればいいじゃんか、と。見えるようになればいくらでも対処の方法はあるものです。ビビってリスクを分析しなくなったら絶対負け組。麻雀オリてばかりじゃ勝てないのと全く一緒だと思います。現物だけ通してトップ取れるなんて甘すぎ。プロジェクト管理や案件管理も同質のはず。

リスクはビビるもんじゃありません。ビビったら終わっちゃうし、何もできなくなる。リスクと利益は表裏一体です。昔から言うじゃないですか？「ローリスクローリターン、ハイリスクハイリターン。」って。

リスクを裏返してビジネスチャンスに育て上げる、そんなことができたらすっげぇ楽しいはずです。私はそういうシビれる仕事をしたいと思っています。

この見解は的を得ていると思われます。下記引用します。

「世の中のオープン技術で開発をしている会社は、

・Java + Oracleを主流とする会社
・Perl + MySQL、PHP + MySQLを主流とする会社

と、完全に二層に分かれてるなと思っている。」

全くその通りだと思いました。ホントに断絶感じますもん。

明確な理由は分からないが、この断絶を肌で感じています。よい悪いとかではなくて、正に「断絶」があるように感じてならない。私がいる会社はJava+Oracle圏の会社ですし、ウチの会社では｢perl｣という言葉が出たことすらないレベルです。

# perl圏からしたら信じられないかも…。でも事実。

なんでこんなことになってしまったのか。その理由を個人的に最もうなずける説明をしてくれていたのがこちらのエントリの下記記述。

「一方のSIの世界、オープン・システムでの開発の世界ではしばしば、まるでスタンダードがない技術分野のオープンでもない技術を抜きには「やってられない」ことがあります。

つまりSI案件には、開発元によるAPIや開発環境の提供に頼らざるを得ない部分が大きい一面があります。そして、こうしたサポート対象になりやすいのが、Java/C++/COMオブジェクトだという現状があります。」

業務システムはレガシーなものも多いんです。特に金融や流通業のお客さんのは。コンソール立ち上げて文字列をカタカタ打つことで動かすようなホストマシンがバリバリ現役で動いています。実際に某小売店での運用の現場を目の当たりにしたことがあります。操作方法がさっぱりわからなかった…。

そのホストマシンと会話したり、金融系システムで大量データが飛んできて２フェーズコミットなどのトランザクション管理がマストなったりするシステムで、尚且つオープン系技術を使うとなると、Java等でないと機能要件を満たせません。

また、「業務システム」は多くの場合商用パッケージを使っています。その商用パッケージを通すためにはJavaでないとサポートされないとか、そういったことが過多あります。

またWEBアプリを作るインフラでベンダーサポートがある製品は、殆ど全てJavaベースの製品かMicrosoftの製品です。J2EEか.NETかどっちかになります。サポートできないオープンソース製品を使うと、全ての責任はSIerにかかってきますので、ベンダーサポートのないシステム環境でシステムを作ること自体があり得ません。

もうココまでくると、文化の違いですね。

また、Java圏とPerl&php圏では対象となるお客さんが全く違います。前者はB2Bメイン、後者はB2Cメインが多いなぁと感じます。

Java圏の人間が作ったシステムがインターネット上にドドンと公開されるなんてことは殆どないと思います。業務向けシステムは殆どイントラネットで使われるものだからです。基幹システムをインターネットに公開している会社など見たことが無いし、Java圏では基幹システムなどの企業内で使われるシステム構築が９０％です。

作ったシステムが一般の目に触れる頻度が非常に少なく、エリアが狭く深いのがJaca + Oracle圏の世界です。業務知識などいらんから、オレは｢はてな」やmixiのようなサービスを作りたいんだ、っていう方はperl&php圏に行かれるべきです。両サービスとAmazonは、全てある共通言語でできています。perlです。

この断絶は文化的な背景が大きい。良い悪いではなくルールが違う、と。

うーん、何かこの断絶を埋めるようなキラーコンテンツがあればもっとこの業界面白くなる気がしてならない。考えてみよ。

XPJUG(eXtreme Programming Japan User Group)会長である倉貫氏のエントリからTB。ディフェンシブであることが様々な弊害を巻き起こしているという警笛を鳴らしています。

倉貫氏によるディフェンシブの定義は以下のようになっています。

「開発途上のリスクを計画上の時点でなるべく潰し、開発側に発生する利益分を減らさないような開発の進め方」

ここで重要なのは「開発側に発生する利益分を減らさない」という下りです。この利益分の考え方、いわばビジネスモデルがディフェンシブの元凶となっていると私は考えています。

そのビジネスモデルとは、「人月計上によるコスト積み上げ型モデル」です。このモデルの大きな特徴は、

① 受注額からの減点方式
② 資産価値ではなくコスト＋αの見積もり方式
③ コストの質が固定費のためリスキー

この３点です。①から見ていきましょう。

SIerの利益の出し方は減点方式になっています。減点方式とは倉貫氏の指摘にもあるように、

「決められた金額の中でどれだけ安く作り上げることで利益を出す構造」

という構造のことです。

つまりスタート時の資金が100とすると、時の経過と共に段々と100が目減りしていく構造のことです。このモデルは途中で収益回復の機会はありませんので、分母であるコストの圧縮以外儲けが増える構造などありません。

次に②について。「コスト＋α」というのは、システムの値段がその価値で決まるものではなくこんだけお金かかったんでそれに色つけたよ、という値段で決まるということです。簡略化して言えば、

「値段＝単価(売値)×要員数×期間」

となります。あとはライセンスとかハード費用とか雑費とかそんなの。

SI業界においてコストの圧縮方法は大別して３つです。これ以外にあるのかな？？

１．工数の短縮
２．単価の低減
３．人数の削減

上記のような単純な掛け算でシステムの値段が基本的に決まる構造なので、掛け算の要素となっている項目が小さくなればいいだけの話なのです。

工数を短縮するには、一番時間とカネがかかる製造部分の期間を短くするのが効果的です。開発生産性を向上してあるべき形で期間を短縮するのが望ましいのですが、実際にはテスト期間を圧縮することが多いです。製造とテストをパラで走らせるとか。

ヒューザーが鉄を減らしてコストを浮かすなら、この業界はテストを減らしてコストを浮かすのです。そんなものです。

単価の低減といえば流行真っ盛りのオフショア。もう金銭感覚の基準が違う。机上の計算では日本の何分の１のコストでできることでしょう。また、国内で地方の売値が安いところに出すローカルオフショアなどというものもあるようです。

が、あんまり上手く言ったという話は当社でも他社さんでも聞きません。これから徐々に成功事例が出てくるでしょう。個人的には楽観視しています。

単価は基本的にスキルによって決まるものだと思っていますが、往々にして年齢序列です。給与分のコスト見込んだ売値になるからだと思っています。単価だけ高いけどマネジメントができない中年SEが多くいるとそれだけで利益を圧迫します。非原価部門にディスパッチしてる会社も多々あるようです。あーうっとおしいｗ

人数の削減はやりたくてもできない会社が多いでしょう。自社に使用できるソフトウェア資産がどれだけあるのか。「この部分の要員はxxシステムで作ったaa.jarでカバーできるね。」なんていう資産ベースのSIやっている会社がどれほどあるのか。

人間に頼らないでシステム開発ができるなら、SIerとしては最強のビジネスモデルになるとは思いますが、しばらくは要員計画でヒーヒー言うでしょう。大きなブレイクスルーがあるとは到底思えない。私がよく言っている作らないSIビジネスへの転換は早い者勝ちだと思うのだが…。どうなのかしら、弊社は。

話をコスト圧縮に戻しましょう。

これら３点の各要素は毎月かかる固定費になるので、これを削るということは期間分だけマイナスが生まれやすくなり、原価比率があがります。原価比率があがるとその分儲けは減ってくるので、何か大きな案件で爆死すると他のたくさーんの優良プロジェクトの儲けを吹き飛ばしてくれるわけです。とばっちりとはこのことです。多かれ少なかれシステム屋さんでこういう経験をされたヒトは相当いるはず。

また問題なのが、肝心要の「見積もり金額」がかなり不確定な部分があるということです。始まる前から負けているわけです。

弊社のみならず同業他社さんでも「当初の見積もりが甘すぎてやってもうた」という話は日常茶飯事。億単位の案件がトラブルになるともう大変です。

何よりもトラブルを起こしてはいけないため、どーやってもディフェンシブにならざるを得ません。儲け方がそうなってしまっているからです。こうなるとお鉢が回ってきた案件の運にも左右されます。

「見積もり金額でよーいドンの世界だと、プロジェクトの成功は能力や付加価値よりも運が重要な要素になってしまいがち」

と倉貫氏がおっしゃられている通りです。たまたま優秀なヤツが入ったから回ったとか、土日でカバーして回したっていう案件めっちゃ多いと思います。

プライムで請けた会社は一気に全ての機能を見積もってよーいドンでSIの開発モデルは動くので、いくら天才的なPMでも必要なコストの半分しかなかったらトラブルになるに決まっています。無理なものは無理です。できないものはできません(´ー`)yー~~~

③は②と絡んでますね。MECEになってないかもｗ

固定費の比率がでかいということは、ある一定の体力がないとできないってことです。

損益分岐点を越えてくると収益が高くなってきますが、こえるまでの原価比率が高いので体力のある大規模な会社じゃないとでかい案件とれないってことです。倉貫さんが指摘しているのはそういうことだと思っています。

単価には売値と原価があって、原価ってのはそう簡単に低減できるもんじゃありません。原価１００万のヒトがある日突然「お前今日から４０万」っていうわけにはいかないし。

以上のことを踏まえると、いかにコストベースの見積もり手法が脆弱なものか、よくお分かりになると思います。現場では足を出さないよう日々ディフェンシブな開発をせざるを得ないSEが多くいると思うのです。

ここまでのことを踏まえると、

「システムを必要としている企業であれば、もはや、SIerなどに頼むのではなく自社で優秀なプログラマーを雇用して、そこで開発をした方が良い」

「本当に優秀なエンジニアは、SI業界など去って、IT企業に行った方が良いんじゃないかと思ってる。」

というのはこの業界の禁句じゃないかと思うんですがｗｗｗｗ

つまり、それほどまでに耳の痛い御指摘だということです。

人間が揃いさえすれば外に出す必要などないと。同じ予算かけるならノウハウもたまるし自社の技術力や運用力も当然上がるインソースのスタイルに変えればいいんじゃないということだと思います。私もそう思います。コストと考えず投資と考えるならば。

アウトソースを考える思考の根幹は、「アウトソース対象となっている事業や業務はコスト」という認識があるからでしょう。優秀な人材をアウトソースしたいなんていう話は聞いたことが無い。なぜか？それは投資に他ならないからです。

最近では単価低減圧力が非常に厳しくなっています。SIビジネスは遣ろうと思えば誰でもできる参入障壁の低いビジネスなので、海外の競合とも戦わなくてはならない時代に入りました。もうコスト積み上げではインドや中国には勝てません。英語というハンデもあります。インソース化の流れが加速する可能性も否定できません。

そんな中で今までとは全く違うSIerこそが求められていると信じてやみません。

長文におつきあい頂きありがとうございました。m(_ _)m

ちょっと古いんですが、2005年の10月にＩＴProがITエンジニアを対象とするスキル／キャリア実態調査の中間結果 を出していました。その冒頭に書いてあったこの言葉にドキっとしました。

｢ITエンジニアがプロジェクト・マネジャーになりたいと思うのは，生き残るための選択肢という側面が強いのではないか」

正直、20％ぐらいこういった気持ちをもっています。

80％は自分が頭になってプロジェクトをドライブしたいという欲望からきているのですが、その理由としてＰＭ経験がないと市場価値の高い人間にはなれないのではないか、いつまでも開発現場でコーディングばかりを担当していては仕事を作り出せるSEには到底なれないのではないか、そういった思いが自分の中にあります。一番は好き勝手やりたいという単純な理由ですが。

まぁでも、現実には一匹狼的な技術畑のフリーエンジニアの方も多くおられます。マネジメントが求められないのでそんなに高い単価では売れないと思いますが、中間マージンがなければ月収70万ぐらいいくんじゃないでしょうか？最新動向が常に変わる変化の激しい分野においては、卓越した技術力だけで喰っていけるものだなと実感として思います。

ＩＴ技術の進歩の速さに開発現場や運用現場がついていけているかといえば、間違いなくNoです。

ドッグイヤーとはよく言ったもので、Javaの世界では1年も立つと新しいプロダクトや設計思想がどんどんやってきます。特にApache　Jakartaのプロダクトの開発スピードはとんでもない速さなので雑誌や何かで常にチェックしていないとドンドンおいていかれます。「あのライブラリ使えばこんなことがすぐできるのに」みたいなことはApache Jakartaの十八番です。

DIは昨年大ブレイクしたし、2006年はDIベースの設計思想がますます市民権を得ることになると思われるので、POJOベースの開発スタイルが主流になっていくのかなと個人的には見ています。EJB3.0に結構期待しています。

しかしこういったJavaの最新動向は常に海の向こうからやってきます。メリケンからですな。技術系雑誌の購読をされているヒトも何人かいますが、やっぱり言葉の壁が大きいと思います。私が知っているフリーのエンジニアでJavaが強いヒトは、英語の読解が苦でないヒトが多いです。英語になると、Java関連のブログのポータルサイトがあったりします。英語のサイトはフォント小さくて辛いんですよ、読むのが・・・。

Javaエンジニアについては自社で育てるよりも、外部からできる人を半年ぐらい雇って徹底的に若手に教え込んでもらうというスタイルがこれから増えていくんじゃないかと思っています。

話がそれました。

PMでなければIT業界で食えないなんてことは絶対にあり得ません。SIを生業にしている会社がある以上、テクニカルスペシャリストの需要はなくなることはありません。ただ、経営層としてはシステムを作る監督としてウチの人間を出して後は基本的にパートナーさんを使ってマネジメントしろという姿勢も変わらないと思います。

この業界で生き残るために最も需要があるのがPMである、というのは間違いないところかなと思います。

富士通のSIに関するトラブルが相次いでいます。

◆名証ダウン

    名証システム障害、原因は外注先オペレータの“操作ミス”

◆東証ダウン

    東証ダウン、運用体制の不備が根本原因

◆ジェイコム

    みずほ証券、誤って大量の売り注文

◆JTBたびたびバンク誤引き落とし

    システム障害により7350万円を誤って引き落とし

4連発で同じ会社のSI案件がトラぶったという報道は初めてだと思います。

期末 or 来期の中間の富士通の決算が非常に楽しみな状態になっています。これでジェイコム or 東証関連で損害賠償なんて記事が踊り始めたら、富士通の株価の急落は鉄板で、黒川社長は引責辞任するかもしれません。

秋草体制になってから通算で5000億以上の赤字を叩き出し、21世紀に入ってから全くいい所がない富士通。SI案件がトラぶってしまうのは、富士通内部の技術力の低下が激しいと言うことに他ならないと思います。このままズルズルと堕ちていってしまうと3年後ぐらいに倒産危機を迎えているかもしれません。

故池田敏男氏を擁し国内ハードウェア市場で大きなプレゼンスを得た富士通ですが、あまりにも池田氏に頼りすぎた、池田氏を中心にビジネスをやりすぎた感が否めません。組織力を高めていくという視点は乏しかったようです。

# ちょっと富士通の決算書みてみよっと。

言うは易く、行うは難し。

今日のテーマはそれです。題材はマンパワーからの脱却ということでお願いします。

SIビジネス、ここではシステム開発ということにします。システム開発は基本的に労働集約型産業になってしまっています。つまり、家を建てるのと一緒で大工を集めることから全てが始まるということ。労働力がベースになっているビジネスモデルです。（labor base industryってワケです）

案件が失注 or 辞退する多くの理由が「大工が揃わない」ということです。リソースがうまくマッチングできないということですね。様々なパッケージやソフトウェアや技術はあれど、そいつらを組み合わせるとなると、どうしても手組みで組まないといけない部分が発します。スクラッチってヤツね。

この状態を改善する最適解の１つは下記のようなものじゃないかと。

「案件が失注する主な要因がヒューマンリソース不足に起因するなら、その部分をコンポーネント化した自社資産などで補うことができればいいじゃないか！」

過去ログで書いた「作らないSIビジネス」 と内容がかぶっちゃうんですが、要員という属人的な変数で仕事が取れる or 取れないが左右されるのはビジネスとしてどうなのだ、と思うわけです。

また自社資産を有効活用し生産性を挙げることができれば、工数（＝コスト）的にも競争優位に立てますし、手組みで組む部分が減るのでその分リスクヘッジができます。この業界の格言ですが、「作らなければバグは生まれない」わけです。

SIビジネスは取り扱う事業領域が大変横並びになりやすいビジネスのため、勝負を決めるのはオペレーションか圧倒的なヒューマンリソースによるものだと思います。ただ、後者に期待するのは経営としてどうかと思うので、やはりオペレーションの品質向上に力を挙げるべきであると思います。それにヒューマンリソースに頼るのは絶対に限界があります。弊社のラインマネジャークラスも気がついているでしょうが、常識として考えられちゃってるので思考停止してない？、って思いますｗ

昨今、BIG５（NTT、IBM、日立、NEC、富士通）のトラブル案件が目立ってきました。特に富士通さんですが。私がいる会社はBIG5の企業ではないのですが、もしも体力のある大手が本気で作らないSIerになって品質上げて成果出されたら、スケールメリットが働いてうちの会社仕事なくなるんじゃないかと本気で心配してます。

ここまで状況として見えているわけです。

が、分析するのは楽なんですよね。痛みを伴わないから。ちょっとくさーい所みるぐらいですから。だけど、組織として実行するとなった時にやればいいとわかっているけど、やれない」組織が星の数ほどあるのはなんでなんだろうか、と。

そんなことを考えた夜でした。

SOAを語るときに出てくるキーワードがあります。ESB(Enterprise Service Bus)ってヤツです。

過去ログ でも軽く説明しましたが、SOAを行うためには異なるシステムを統一的なメッセージ仕様に基づいて会話することが必須になります。

簡略化しちゃうと、「異なるシステム＝日本人やフランス人」だと仮定するとわかりやすい。内部的には日本語やフランス語や英語をしゃべる、と。システムも人間も、日本語と英語が入り乱れちゃ会話になりません。どちらかが譲歩して言葉を統一するか、英語のような標準的な公用語を採用する必要があります。

その公用語を解析して各システムに教えてあげるのがESBだと思って頂ければ。

# 内部的には色々サポートしないといけないことは多くあります。

で、このESBという概念。IBM、Oracle、SAP、Microsoft社などが各々の独自の仕様で勝手に組み始めているのが実情です。業界に標準的な仕様が決定していないからというのもあるのですが、Javaが流行りだした時と同様のスケベ心 が働いている気がします。

ただ全く同じアウトプットなのにフォーマット(仕様)が違うのは、この業界の悪癖だと思います。

Javaの動作環境というのも結構複雑です。SunMicroSystemsというJavaの生みの親が出しているSunJavaだけでなく、IBMが出している「IBMJava」なるものがあるんです。WebSphereというIBMがリリースしているAPサーバー製品は須らくIBMJavaが採用されています。

おんなじJavaなのにベンダーが違うと微妙に動かなかったりするんですよ。初めてこの事実を知った時に腹たちました。IBMJavaにどれほどの意味があるんだこの野郎って心境でしたねぇ。

ちなみにIEのJava実行環境もSunJavaとIBMJavaを選んだりする場合があります。VMもMicrosoftVMとSunのVMがあったような気がします。同じアウトプットで仕様が違うぞこの野郎、と。

SIerではいろんな意味での技術の標準化が叫ばれて久しいですが、ソフトウェアベンダーからしたら乗換えコストの低い製品を出すのはかなり抵抗があるんでしょう。この認識のズレを克服しないと、いつまでたっても「同じようなことを意味しているのに微妙に意味が違う横文字言葉」や、「同じ技術を使っているのに製品仕様が違うため統合にはコストがかかる」なんてことはなくならないのかもしれないと、ちょい飛躍気味に考えてしまいました。

NECが無料IP電話ソフトであるSkypeを使用したサポートサービスを試験的に開始しました。

NECがサポート窓口でSkypeを試験運用，個人向けPCへの標準搭載も

このブログでも前のブログでもよく書いていましたが、コールセンターのIP電話化はかなり面白いんじゃないかと思っています。フリーダイヤルがいらなくなりますし、上手く活用すればIPセントレックスによるコストメリットも得られます。従来のコールセンターの開設にはかなりコストがかかります。

# 通話料は無料だが、タダより高いものはないってことですな。ランニングコストﾌｫｰ。

ISP(特にSo-netあたり)もこの試みに葉乗ってくるんじゃないかなと思ってます。Vaioの現行モデルはSkypeが標準で入っているし。パソコンなどのハードのサポートだけじゃなく、サービスメニューなどの問い合わせ窓口もＩP電話対応すべきだと思います。