2008年12月31日水曜日

クリエイト工房納会

12/26(金)にクリエイト工房の納会が行われた。
場所は新川崎オフィス。
寿司や鶏の唐揚げ、スナック菓子、柿ピーなどの簡単なおつまみと、
缶ビールで乾杯。
過去の会社イベントの写真・動画を観ながら、みんなで談笑。

最後は、お決まりのおとおりで、各自が今年の反省と来年への抱負を語った。
経営陣のコメントはさすがに厳しめ。
米国発の金融不安の波はIT業界にもじわじわと押し寄せており、
「今年は何とかなったけど、来年はわからないよー」
とのコメント。

ただ、こういう今まで通りのやり方が通用しない時こそ、アイデア勝負。
2009年は仕事上で遊んでいこうかと思います。
遊びって言うと聞こえが悪いが、要は決められた事以外の新しいことをするって事。
言われたことだけ真面目にやってても、何も改善とか発見とかないと思う(もちろん、言われたことをちゃんとやらないのはまずいが)。
友人とか同僚で仕事できるヤツを見てると、普段から仕事中に色々遊んでて、
その中で新しいやり方・より良いやり方を見つけて、成果に結びつけてる。
だから、来年は真剣に遊ぶ事にします。


2008年12月23日火曜日

失敗失敗

仕事でミスってしまいました。
自分がシステムの仕様を勘違いしており、
「ユーザーさんの使い方は法令に抵触する!」
みたいな指摘をして大騒ぎ。
お客様の上層部まで巻き込む会議になりそうだったのだけど、
結局、問題無いことが発覚。

大変申し訳ありませんでした。。。
お客様からは「問題が無くてよかったです」と言ってもらえたのだが。
自信無くすなあ。。。

一応、指摘をする前に仕様を確認したはずだったんだけど、
確認が不十分だったらしい。
今の仕事に配属されてから1年半が経つけど、わかってるようでわかってないことだらけなんだなあ。
気をつけないと。


Powered by ScribeFire.



PRESIDENTから日経ビジネスに乗り換え

今まで、PRESIDENTを購読していたのだが、日経ビジネスに乗り換えることにした。
PRESIDENTは経営者向けの記事が多くて面白かったのだが、
経営者の年齢層である40代~60代をターゲットにしているためか、
ちょくちょく「おすすめ病院特集」が組まれるのがつらい・・・。
俺は普段病院に行かないから、全然興味無いです。
病院特集の時は、激しく損した気分になる。

と言うことで、日経ビジネスの年間予約購読を申し込んでみた。
日経ビジネスの年間予約購読には、日経ビジネスのオンラインサービスである「NB online PREMIUM」が利用できる。
これは、WEB上で日経ビジネスの最新記事のPDF閲覧や、過去記事検索、記事のスクラップができるというモノ。
なかなか面白そう。
仕事の合間とかに使えそうですな。
NB online PREMIUMの利用登録完了まで数日かかるそうなので、楽しみに待っていよう。





2008年12月8日月曜日

ITサービス業界における“下克上”の勧め

ITサービス業界における“下克上”の勧め:ITpro

「大手SIerの下請けベンダーは、常駐してのシステム保守を通じて業務も知り尽くし、エンドユーザーさんと直接顔を合わせている強みを生かして、ユーザー企業から直で受注してしまおう」
という話し。
この話しは大いに賛成。

というのも、うちの会社「クリエイト工房」は、今でこそ大手ユーザー企業さんと直接契約を結んでお仕事させていただいているが、
創業当初は他ベンダーの下請けとしてユーザー企業さんに常駐して保守サービスをしていたそうな。
ある時、プライムベンダーとユーザー企業さんの契約切れのタイミングで、うちの社長が思いきって
「うちと直接契約結びませんか?ダメなら他の所に行きますけど。」
と言って交渉し、見事直接契約にこぎつけたらしい。

やっぱり、エンドユーザーさんとの信頼関係を築ける会社、
すなわちユーザーの悩みや要望を真摯に受け止めて、
彼らのためになるような提案やシステム構築で商売できる会社が勝てるのだろう。

最近考えていることなのだが、下請けに甘んじているITサービス企業がユーザー企業と直接契約すれば、
ITサービス業界・ユーザー企業ともにメリットがあるのではないだろうか?

なぜなら、プライムベンダーが搾取している中間マージンが不要になるため、
浮いたコストを下請け企業とユーザー企業に分配できるからだ。

下請け企業にとっては売り上げアップになるし、ユーザー企業にとっては受けるサービスの質は同じ(サービスを提供してくれる人材は実際にはプライムベンダーではなく下請け企業)なので、コストダウンになる。

もしこれが実現したら、ITサービス業界も賃金が上がるので、労働環境が改善できるかもしれない。
ただし、今までプライムベンダーとして甘い汁を吸っていた大手SIerにとっては困ったことになるだろうが。


Powered by ScribeFire.



2008年11月10日月曜日

休日出勤

日曜にユーザーサポートのために出勤。
自分が常駐しているクレジットカード会社さんでは、基本的には土日は入会審査業務をやってないのだが、
「スピード発券」といって、Webサイトや店頭で申し込めば30分~60分で審査・カード発行するサービスがあり、そのスピード発券の審査業務を行っている。
審査・発券を短時間で完了させなければならないため、システムトラブル時は迅速な対応が求められる。
そのため、我々SEが張り付いているというわけ。

ただ、この日は非常に平和で、トラブルが全く発生しなかった。
※画面の見方について1件質問が来ただけ。
平和なことは良いことだ。

時間がたっぷりあったので、前日までにユーザーさんから来ていた、新システムについての問い合わせの調査をし、メールで回答したり。
追加開発案件の設計について、ユーザーさんに質問メール作成したり。

2008年11月6日木曜日

稼動2日目

稼動2日目。
今日はユーザーからの問い合わせも少なく、平和だなあと思っていたら、
15時頃に基幹システムの調子が悪くなり、急遽業務ストップ。
ニュースにもなっていた模様。
カード会員のカード利用にも影響があったようで、キャッシング利用ができなくなったらしい。
原因や対応状況など、詳しい情報があまり入ってきてないので何とも言えないが、
早く復旧することを祈るばかり。

UFJとか東証など、新システム移行後のトラブルが絶えないけれど、もっと減らせないのかしら。
うまくシステム移行できたところってどうやってるんだろう???

2008年11月5日水曜日

新システム稼働初日

お客様先の新業務システムが無事稼動を迎えた。
昨年の5月から開発に参加してから1年半。
あっという間だった気がするが、感慨に耽ってる暇はない。
これがゴールというわけではなく、むしろこれからがスタートなのだから。
システムは一度動けばよいというわけじゃなく、動き続けるのが重要であって、今後のユーザーさんの業務の変化に対応し続ける必要があるわけで。
すでに2010年貸金業法改正対応の追加開発も動いているし。

そんなわけでスタート初日はトラブルが発生したものの、件数的には比較的穏やかな滑り出し(1件だけ内容が重たかったが)。
システムの運用サポートに携わるのは初めてなので、かなりわくわくしている。
2日目からどうなることやら。

2008年7月21日月曜日

三鷹 魚彩

少し前の話になるが、協力会社のNOJIMAXさんのご実家が、職場近くで飲み屋をやっているそうなので、「じゃあみんなで行ってみよう」ということになり、仕事が終わった後、職場の人間3名でお邪魔させていただいた。

ご実家のお店は「三鷹 魚彩(うおさい)」。
場所は東京都三鷹市下連雀3-26-7サンシロービル1F


大きな地図で見る

ここのお店の売りは、特大シマホッケの開き。
値段も1480円と半端じゃなく高い。
でも興味を惹かれたので注文してみたところ、やっぱりでかい!
その分、肉厚で脂がのっていて、非常に美味かった。

あと、韓国人留学生のバイトの娘がいるのだが、日本語がまだ自由にしゃべれないらしく、一度に2つ以上注文するとパニクってしまう。
なかなかかわいい。

時間の都合で1時間くらいしかいられなかったのが残念。
またみんなで行きたい。



2008年6月26日木曜日

雁屋哲のブログ

自分は美味しんぼの大ファンです。
趣味が料理なのも、美味しんぼの影響です。

また、原作者の雁屋哲先生がコンビニ版「美味しんぼ」に掲載しているコラムが大好きです。
そのコラムでは毎回特定の料理・食材をテーマにしているはずなのですが、冒頭からいきなりテーマとは全く関係ない、独断と偏見に満ちた昔話・近況報告(主に鬱病で苦しい、仕事が辛いなど)が展開されており、非常におもしろいです。残り2分の1ページくらいで「いかん残りが少ない」とか言って、無理矢理テーマに沿った内容に転換してお茶を濁すところなんか、ステキすぎます。

そんな魅力たっぷりのコラムを読みたくて、コンビニ版「美味しんぼ」の新刊をいつも楽しみにしているのですが、雁屋哲先生のブログを発見しました!
教えてくれたのは友人のタカミヤ君
本当にありがとうです。

早速読んでみました。
2008年6月25日は「美味しんぼの登場人物 中松警部」です。
蕎麦っ食いの中松警部がテーマです。
でも案の定、冒頭から3分の2は「全共闘時代の学生運動」の話であり、最後にちょろっと中松警部の名前が出てきます。

こりゃあ毎朝の通勤時間の読み物としては最高だ。
毎日が楽しみで仕方ないね。

2008年6月24日火曜日

BS・SS交流会

6月20日(金)に、会社の事業部間交流会に参加してきた。

クリエイト工房には主に2つの事業部があり、高性能DB開発・組み込み開発などの高度技術開発に携わる「戦略ソリューション事業部(略してSS)」と、クレジットカード会社の社内システムの開発・運用に携わる「ビジネスソリューション事業部(略してBS)」から成っている。
2つの事業部は、業務内容も違えば勤務地もまったく異なるため、月1回の社員会でも無ければ、普段互いに顔を合わせることが無い。
そのため、「もう少し顔を合わせる機会を作ろう」という声が挙がり、各事業部のマネージャー・上級SEが集まって交流会をやってみることになった。

集まった人数は7名。
30歳前半が中心で非常に若い。
こういった若い人間が中心になって会社を動かしていけるというのは、うちの会社のいいところなのだろう。

第1回目は手探り状態であり、まずは互いのプロジェクト内容を話し合うところから始まった。
クリエイト工房の元副社長は以前から
「SSとBSが協力して新しいビジネスに結びつけろ」
という檄を飛ばしていたのだが、やはり互いが何をやっているのか、強み・弱みは何かを理解しなければ相乗効果は得られまい。
そういう意味で今回は互いを理解する良い機会であり、有意義だったと思う。

SSの事業内容は、同じ会社にいながらあまりよく知らなかったのだが、聞いてみるとなかなか面白そう。
SSの主要取引先の1つに「株式会社高速屋」というソフトハウスがあるのだが、そこの高性能DBの事をもう少し知りたくなった。
お客さんに売り込むにしても、製品のメリット・デメリットを理解した上で、価値のある使い方を提案できなければいかんからね。
製品に関する技術的に突っ込んだ話は「機密情報」という事であまり詳しくは教えてはもらえないらしいが、大まかな話を聞いた感じでは企業における業務ログの統計分析とかに使えそうな。

交流会1回目の感触がそこそこ良かったので、今後も定期的に実施することになった。
次回は互いのプロジェクト内容を資料を持ち寄って説明する。
何かおもしろい動きにつなげていければと思うのだが、はてさてどうなる事やら。

2008年6月22日日曜日

テクニカルエンジニア(情報セキュリティ)に合格

4月に受験した情報処理技術者試験の「テクニカルエンジニア(情報セキュリティ)」の合格証書が届いた。
試験直前の2~3月はプロジェクトのテスト工程で大忙しだったので、勉強時間が取れず苦労したが、合格できて良かった。

情報セキュリティの資格を取ろうとしたきっかけは、前の会社でのソフトウェア開発においてセキュリティ対策の開発に関わったこと。
その経験で感じた情報セキュリティの魅力は下記の通り。
  • 高度で幅広い知識・技術力が要求されるのでおもしろい
  • 設計段階から考慮すべき重要事項
  • 個人情報保護が重視されているため、疎かにできない


いずれ、このスキルを生かした仕事をしてみたいです。

2008年5月19日月曜日

若手を枯らす「バイキン上司」が繁殖中!|『うつ』のち、晴れ 鬱からの再生ストーリー|ダイヤモンド・オンライン

「パワハラ上司が原因で若手が鬱になり、退職に追い込まれる」という記事。

パワハラ上司ってそんなにいっぱいいるのかしら?自分は今の会社・お客さん先・前の会社含めて、そんなに多くないという印象。 100人に1~2人くらい。ただ、確かにパワハラ上司はいるし、実際1人いるだけで破壊的に職場の雰囲気を悪くする。

前の会社でジャイアンみたいな部長がいて、気に入った部下は徹底的にかわいがるのだが、一旦へそを曲げると、やることなすことけなして怒鳴ってくる。非常に鬱陶しい。バリバリ仕事して、結果出してる人なら目をつぶらない事も無いのだが、タバコ部屋に入り浸ったり、会社のPCでバックギャモンやってたり、IMで女性の派遣さんに夜のお誘いしてたり。

紹介記事では「何故上司がパワハラを働くのか?」の理由について「上司自身が酬われていないから」という主張をしている。まあ、一理あるのかもしれない。お客さん先の新人研修で「何故上司が部下を褒めないのか、上司に理由をアンケートした結果」の話があったそうで、アンケート結果の第1位は「部下が上司を褒めてくれないから」だったそうな。いじらしいなあ。

でも確かに上司の良いところは尊敬して、それを態度なり行動なりに表した方が良いのだろう。自分自身も気をつけてみよう。

前の会社の上司達も、我々部下に尊敬されたり褒めてもらいたかったのかしら。ちとかわいそうかも。

若手を枯らす「バイキン上司」が繁殖中!|『うつ』のち、晴れ 鬱からの再生ストーリー|ダイヤモンド・オンライン



2008年5月18日日曜日

公共事業をやめて強くなったゼネコン:NBonline(日経ビジネス オンライン)

「付加価値や提案力が生かしづらく価格競争に陥りがちな分野(公共事業)から撤退して、利益率を向上させた」という中堅ゼネコン「矢作建設工業」の紹介記事。
官公庁の公共工事や民間のマンション建設などの大規模工事案件は、通常は競争入札による発注形式が取られる。競争入札になると価格競争に陥りがちになり、受注できたとしても利益率の低いプロジェクトになってしまう。そのため、競争入札による受注ではなく特命で受注を受ける事が利益率向上につながる。
特命で受注を受けるためには、建設業者の設計力や提案力がものを言う。しかし、公共工事案件は官公庁と契約した別の設計業者がすでに設計を行っており、建設業者側には設計力・提案力を発揮する余地は無いらしい。
そこで、矢作建設工業がとった戦略は以下の通り。
  • 設計業務の人員増強による設計力強化
  • 設計力・提案力が生かせない公共事業から撤退し、民間事業や自前の不動産開発へのシフト
この戦略転換により、矢作建設工業の営業利益率は2004年の4.0%から2008年には5.2%に向上。鹿島建設や大林組などの大手ゼネコンの営業利益率が3%未満に低下しているのに比べると、好業績である。もちろん、公共事業から撤退した事による副作用として売上高が2004年の931億円から780億円まで低下したが、営業利益で考えると2004年の37億円から2008年には40億円に増加。高利益の健全な体質になっている。
我々IT業界の1企業でも矢作建設工業を見習うことはできないだろうか?おもしろいと思ったのは大手が必死で受注に走る公共事業から手を引いているところ。ただ、IT業界では必ずしも官公庁案件=利益率が低いというわけでは無いようだ(NTTデータは営業利益率10%。富士通は3%前後で苦悩してるが)。まだまだIT業界は成熟しておらず、差別化が図りやすい土壌だということだろうか?
もう一つ興味を引かれたのは、紹介記事に書いてある「川下」でのビジネス。これは施工後の建物に対して後付で耐震補強をするビジネスなのだが、これが好調らしい。システム開発で言うところの、運用フェーズでの周辺開発ってところか。保守・運用はうちの会社の強みであるし、周辺開発での実績もあるので、強化していくのが面白いかも。
公共事業をやめて強くなったゼネコン:NBonline(日経ビジネス オンライン)

2008年5月17日土曜日

Advanced[es]からブログを書いてみる

自分はケータイとしてAdvanced[es](以下アドエス)を使用している。せっかくフルキーボードが着いているので、アドエスからブログを投稿できないかなーと調べたところ、「MackyBlogPocket」というブログ投稿ツールを発見。
作者のサイトはすでに閉鎖されているのだが、有志がインストールパッケージをアップしてくれているのを見つけ、喜び勇んでインストール。
会社帰りのバスの中で使っております。
うまく投稿できるかな?

お。ちゃんと投稿できている。
と思いきや、追記に失敗。
惜しいなあ。
でも、MovableTypeの投稿画面はアドエスで開くには重すぎるから、結構便利かも。

2008年5月16日金曜日

進化するハードウエアに追いつけない日本のソフト産業 ビジネス-最新ニュース:IT-PLUS

日本のIT業界は、ハードウェアに比べてソフトウェアの価値がまだまだ低く扱われており、ソフトウェア開発のやり方が発展していない」という論評。

この主張には大いに賛成。 日本のIT業界って結局のところ箱(ハードウェア)を作る・売るに偏りすぎていて、その箱を使ってどのようなサービス(ソフトウェア)を提供するのかというあたりがおざなりになっている

例えば、最近SHARPが発表したスマートフォン(?)である「Ultra Mobile Willcom D4」などが良い例。スマートフォンにあろう事かWindows Vistaを入れちゃった。「PCと同じソフトが動けば、とりあえず便利になるはず」という安直な発想が見え見え。モバイル端末はデスクトップとインターフェース(画面・キーボードサイズ、マウス有無など)が全く異なるのだから、同じソフトウェアでも使い勝手が全く異なる。だから、ソフトの使い勝手を考えれば、インターフェースに応じてソフトも当然異なるべきなのだ。それをやらずにハードウェアでがんばりすぎるから、日本のソフトウェア製品はイマイチなのだろう。

日本ではプログラマーの地位も低いし。上流・下流とか言って分析・設計を贔屓して、実装を肉体労働扱いするから、プログラマー経験無しに業務分析だの概要設計だのしかやったことのないSEが増えるわけですわ。で、そういうSEさん達は実現不可能なシステム設計をして、プロジェクトを破綻させるわけですわ。分析も設計も実装も、単なる役割分担に過ぎないのに。

進化するハードウエアに追いつけない日本のソフト産業 ビジネス-最新ニュース:IT-PLUS



2008年4月25日金曜日

お客さん先での新人配属

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

初々しくて良いねえ。

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

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

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

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

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



2008年4月20日日曜日

工事進行基準で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業界は「ゼネコン体質」とか「労働集約的」など、建設業界と似たものとして論じられる事が多い。
その「お隣」である建設業界のような悲惨な状況にならないために、今後どうしていったらよいか?
考えていきたい。



2008年4月17日木曜日

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

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

そもそも工事進行基準だろうが工事完成基準だろうが、
売り上げが毎年計上されるか最後の年に計上されるかの違いでしかなく、
精度の高い見積や正確な進捗管理が必要なことは変わらないし、
納期遅延が契約上許されないことや、機能追加・変更を仕様変更として追加費用を取るかどうかの交渉が都度都度必要になることも、一切変わらないのではないでしょうか?
だったら、何故「工事進行基準導入によって、デスマーチが減る」というような論調が多いのか。
それはITサービス業界の「要件定義ミスを、契約上お客さん責任とすることで、SIerのリスクを軽減したい」という思惑があるからだと思われます。
どういう事かと言いますと、ソフトウェア開発への工事進行基準導入に関して必ず言われていることが、
「工事進行基準が導入されると、精度の高い費用見積・進捗管理が必要になる」
ということなのですが、もう少し深掘りすると
「費用見積もりの精度を高めるためには、要件定義をちゃんとやらなきゃダメです」
となり、さらには
「要件定義はお客さん主体でやるべき作業なので、お客さん責任でやってください。そして、もし完成したシステムに機能上不備があったとしても、 SIerはお客さんの作った要件定義通りに設計・開発しただけなので、我々SIerは悪くないです。お客さんの責任で改修費用を負担してください。」
となるわけです。
「そんな陰謀めいた馬鹿な話が?」
と思うかもしれませんが、あながち間違いとも言えないでしょう。
事実、ITサービス業界では「要件定義をお客さん責任とするよう、契約上明確にしよう」という動きがあります。
例えば某国内SIerでは、1~2年ほど前からお客さんとの契約内容を見直し、
従来の「開発の全工程一括請負契約」から「開発フェーズ毎の個別契約」に移行させようという方針になっています。
具体的には、システム開発契約を下記3契約に分割します。
  1. 要件定義フェーズ:準委任契約
  2. 設計・開発フェーズ:請負契約
  3. 保守・運用フェーズ:請負契約
ここの「準委任契約」「請負契約」についてですが、両者の決定的な違いは
「最終成果物に対する責任の所在」
です。
「請負契約」は受注した側(=SIer)が成果物(=システム)に対して責任を負いますが、
「準委任契約」では発注側(=お客さん)が成果物に対する責任を負うことになります。
つまり要件定義については「SIerはお手伝いをするだけ」という契約です。
もし、上記のような「工事進行基準導入」→「要件定義のお客さん責任化」の流れがうまくいけば、デスマーチ最大の原因である「要件定義ミス」による負担をSIerがかぶる事は無くなるでしょう。
ただし、あくまでも「お客さんが懐を痛める」か「要望をあきらめる」の何れかによって。
SIerにとっては旨い話のようですが、逆に痛い目を見る展開も可能性としてありそうなので、それについて追々書いてみます。

自分のお仕事

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

2008年4月9日水曜日

はじめに

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

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