お客さん先での新人配属

常駐先のお客さんは、今日が新人の配属日。同じフロアの別グループで、新人の女の子達が恥ずかしそうにしながら、自己紹介と今後の意気込みを社員一同の前で話していた。

初々しくて良いねえ。

新人は全部で4人いたのだが、全員女性。さすが社員の半分以上が女性というだけのことはある。IT業界では考えられない。お客さんはクレジットカード会社だが、女性が多いのは業界の特質というわけではなく、会社の風土によるものらしい。「女性が働きやすい会社ランキング」の上位にランクインする位だから、設備や制度に気を配っているのだろう。

組織にとって男女比率のバランスが取れているのは大変望ましいと思う。男性ばっかりとか女性ばっかりでは、組織全体として考え方が偏ってしまい、柔軟性に欠けることになる。だから、日本IBMなどでは、新卒採用時は意図的に男女半々、文系理系半々にしているのだと聞いたことがある。

それに、共同作業をする時は、色々な考え方の持ち主が知恵を出し合った方が、結果的に良いアイデアが多く出る。実際、自分が前の会社で新人研修を受けていた頃、いくつかの班に分かれてブレーンストーミングをやったのだが、一番多くのアイデアを出した班は、男女の人数比が一番バランスの良かった班だった。

ちなみに、うちの会社は新卒が3名で全員男。人財採用部長が新卒採用で一生懸命がんばっているが、女性採用には難航している模様。うちの会社も組織全体の柔軟性を持つためにも、女性が働きやすい環境を作っていきたいね。

お客さん先から何か盗めるものがあるかしら？

工事進行基準でIT業界が痛い目を見る日

IT業界が工事進行基準導入を自衛のための言い訳（お客さんの機能追加要望を突っぱねたり、仕様変更として追加開発費用を要求するなど）にするのでは？
というところまでが前回のお話。
でもまあ、これ自体は悪い事では無い。開発終盤になっての機能追加要望なんて、システム屋からすれば
「今更そんなこと言うなんて勘弁してよ。そういう要望は最初っから言ってよ。」
という話だし、当初の予定には無かった追加作業に対しては、しっかり代金を頂戴するのが商売としては正しいからだ。

だがしかし、工事進行基準を単なる言い訳として利用することで、逆にIT業界にとって都合の悪い展開になる可能性があるのではないだろうか。
それは「費用見積や作業進捗が明確になることで、ダンピングが発生する」という可能性だ。

そもそも、お客さんの機能追加要望を断ったり、追加費用を取ったりする事は、お客さん側からすれば
「何で機能追加できないの？本当にそんなにお金がかかるの？」
という疑問を抱くだろう。
さらに突っ込めば
「システム屋の言うことは妥当なのだろうか？」
と考えるはずだ。
だが、お客さん側がこの疑問に対して
「システム屋の言ってることがおかしいじゃないか！」
と突っかかってくる事は、現実には少ないのではないだろうか。
なぜなら、お客さんはシステム開発の事はあまりよくわからないからだ（SIerと張り合えるだけの知識・技術を持ったシステム部門を持っているユーザー企業って、それほど多くないだろう）。
結局、システム屋に言いくるめられて、釈然としない気持ちを抱いたままその場は終わってしまうのだろう。

だが、もしここでお客さん側に「機能追加可否や追加費用の妥当性」を判断できるだけの力が備わっているとしたらどうなるだろう？
システム屋が機能追加を安い費用で請け負わされるケースが増える事は当然だが、そもそも最初の開発費用見積から妥当性を細かく調べられ、コストを削られてしまうのではないだろうか。
そうなると、システム屋としては開発原価を切り詰めるため、人件費削減に走るだろう。それは下請け会社を叩いて搾り取る事で実現されるのかもしれない（ただでさえ安く買いたたかれているというのに・・・）。

この「お客さん側が力をつけることによって、開発側がダンピングに追い込まれる」という話、建設業界で実際に起きている事なのだそうな。
ここ1～2年、マンション建築が盛んに行われているにも関わらず、建設業界は利益率が激減しているらしい（2004年→2008年で、大手ゼネコン4社の売上総利益率が8%→5％に下落）。じゃあいったい誰がマンション建築ラッシュの恩恵を受けているのかというと、発注者である不動産会社だそうで、その秘訣は「CM方式」の導入にあるのだそうな。

「CM」とは「Construction Management」の略で、工事発注者の立場で施工業者の選定、予算・スケジュール・品質管理などを行うコンサルティングサービスのこと。
日本では、建設プロジェクトをゼネコンが一括請け負いするのが普通だが、欧米では発注者がCM会社と別途契約し、CM会社に建設会社をチェックさせるのが一般的らしい。
この欧米のCM会社が、98年汐留再開発の際にCM業務を受注したのをきっかけに、不動産会社がCM方式に着目。近年のマンション建築においてCM方式を導入することで、建設コストを削らせることによって、不動産会社が利益を拡大しているのだそうな。

IT業界の開発プロジェクトでは、未だ建設業界のような状況にはなっていないが、CM方式を持ち込んでくるコンサル会社は出てくるかもしれないし、それによってお客さん側が発注力をつけてくるかもしれない。
何より、「工事進行基準導入により、費用見積・進捗管理を厳密にする」というのは、開発プロジェクトの内容をガラス張りにすることであり、CM方式によるコスト叩きには格好の材料なのだ。
そういう旨味を見逃さない人間は必ずいるはずだ。

発注者によってコストを叩かれて、利益を出せなくなった建設業界では、下請け会社を中心に倒産が相次いでいるらしい。中には経営苦により自殺する経営者もいるのだとか。
我々、日本のIT業界は「ゼネコン体質」とか「労働集約的」など、建設業界と似たものとして論じられる事が多い。
その「お隣」である建設業界のような悲惨な状況にならないために、今後どうしていったらよいか？
考えていきたい。

IT業界への工事進行基準適用について考える

昨年から話題だった「ソフトウェア受託開発への工事進行基準の適用」ですが、
確かにデスマーチ発生率を減らすことになるかもしれない。
ただし、「お客さんを泣かせる」という形で。
「工事進行基準」って詰まるところ
「年度毎の収支を安定して見せることができる」
という会計上のメリットしか無いように思われます。

そもそも工事進行基準だろうが工事完成基準だろうが、
売り上げが毎年計上されるか最後の年に計上されるかの違いでしかなく、
精度の高い見積や正確な進捗管理が必要なことは変わらないし、
納期遅延が契約上許されないことや、機能追加・変更を仕様変更として追加費用を取るかどうかの交渉が都度都度必要になることも、一切変わらないのではないでしょうか？
だったら、何故「工事進行基準導入によって、デスマーチが減る」というような論調が多いのか。
それはITサービス業界の「要件定義ミスを、契約上お客さん責任とすることで、SIerのリスクを軽減したい」という思惑があるからだと思われます。
どういう事かと言いますと、ソフトウェア開発への工事進行基準導入に関して必ず言われていることが、
「工事進行基準が導入されると、精度の高い費用見積・進捗管理が必要になる」
ということなのですが、もう少し深掘りすると
「費用見積もりの精度を高めるためには、要件定義をちゃんとやらなきゃダメです」
となり、さらには
「要件定義はお客さん主体でやるべき作業なので、お客さん責任でやってください。そして、もし完成したシステムに機能上不備があったとしても、 SIerはお客さんの作った要件定義通りに設計・開発しただけなので、我々SIerは悪くないです。お客さんの責任で改修費用を負担してください。」
となるわけです。
「そんな陰謀めいた馬鹿な話が？」
と思うかもしれませんが、あながち間違いとも言えないでしょう。
事実、ITサービス業界では「要件定義をお客さん責任とするよう、契約上明確にしよう」という動きがあります。
例えば某国内SIerでは、１～２年ほど前からお客さんとの契約内容を見直し、
従来の「開発の全工程一括請負契約」から「開発フェーズ毎の個別契約」に移行させようという方針になっています。
具体的には、システム開発契約を下記3契約に分割します。

1. 要件定義フェーズ：準委任契約
2. 設計・開発フェーズ：請負契約
3. 保守・運用フェーズ：請負契約

ここの「準委任契約」「請負契約」についてですが、両者の決定的な違いは
「最終成果物に対する責任の所在」
です。
「請負契約」は受注した側（=SIer）が成果物（=システム）に対して責任を負いますが、
「準委任契約」では発注側（=お客さん）が成果物に対する責任を負うことになります。
つまり要件定義については「SIerはお手伝いをするだけ」という契約です。
もし、上記のような「工事進行基準導入」→「要件定義のお客さん責任化」の流れがうまくいけば、デスマーチ最大の原因である「要件定義ミス」による負担をSIerがかぶる事は無くなるでしょう。
ただし、あくまでも「お客さんが懐を痛める」か「要望をあきらめる」の何れかによって。
SIerにとっては旨い話のようですが、逆に痛い目を見る展開も可能性としてありそうなので、それについて追々書いてみます。

自分のお仕事

現在、自分は某大手クレジットカード会社様の業務部門に常駐する業務SEをやっております。
基本的な業務内容は
「業務システムの運用サポート」
なのですが、
現在はお客様先にて次世代業務システム開発の真っ最中であり、
自分たちは
「ユーザー業務をよく理解しているシステム屋」
という立場によって、次世代業務システムの要件定義や、
システムテスト・運用テストの計画・実施に携わっております。
とは言うものの、自分は今の会社に2007年5月に転職したばかり。
前の会社に新卒で入社して以来、
「システム開発時の性能トラブル対応」や
「Webアプリケーションフレームワークの開発」
といった後方技術支援的な業務ばかりだったので、
クレジットカード業界の事なんてさっぱり知りませんでした。
転職直後は、わからない事が多すぎて
「このままで本当にやっていけるかなあ？」
と不安になり、お客様の主任さんに相談したところ、
「まあ、うちの業務やシステムは複雑で覚えることがいっぱいあるので、1年くらいはかかると思います。大丈夫ですよ。」
と慰められたりもして。
結局、今のお客様先に飛び込んでから10ヶ月が経過しましたが、
まだまだわからないことばかり。
上司やお客様に質問しながら、自分のタスクをこなす毎日です。
それでも、最初に比べたらずいぶんと主体的に判断・行動できるようになったかなあ。
自分もやればできるもんだと、自画自賛。

はじめに

このブログではシステム屋として日々思ったことを書き連ねていくことで、自分自身の振り返りをしたり、他のシステム屋さん達と情報交換するための材料にしたりしようと思います。

目標は2～3日に1回は更新。