« なつかしきターボシリーズ | トップページ | Linux入りのThinkPad!? »

2006年8月10日 (木)

流儀も変化の時期かもしれない

顧客が違うと、ITサービスの仕事の“流儀”もこんなに違う

大変感慨深い記事でした。
「これじゃ主要顧客を見極めないと企業分析を誤るなあ、と認識を新たにした。」いやまったくその通りだと思います。

ほんと、金融・公共系と製造・流通系のITサービスってのは全然違いますね。現場にいるときはまるっきり「世界」が違うなあくらいに思ってたんですが、なるほど「流儀」が違うというのはいい言葉ですね。これからはそう言うことにします。

ボクはサラリーマン時代にSEとして両方の属性の現場を経験しました。金融はちゃんとタッチしたことがないですけどね。公共はけっこう長くやってました。

この記事の著者がおっしゃるように、公共系の場合はシステムの予算規模がデカく、ほとんど一任の状態です。経営的にはおいしい仕事ですよね。ITバブル時代にはITに寄った公共事業がたくさんあって儲かったもんですが、それが一段落すると、公共事業も予算枠の狭い細かい案件が多くなったり、1円入札なんかがあったりして開発要因が満足に確保できない中でむりやりシステムつくったりする悲惨な状態になりました。

営業もなんとか公共事業の担当とのつながりを保ちたくてあり得ない価格でシステム取って来る。もちろんそのあおりは開発現場が食らうわけですね。ちょうどこの時期に開発リーダーとかやってたんで、何度もプロジェクトマネージャーにキレた覚えがあります。

一方、製造・流通系は記事にある如く、結局お客の御用聞きみたいな商売でしたね。印象に残ってるのは「業務ノウハウに専門性が乏しいSEが甘い要件定義を行った案件は、片っ端から不採算となる。致命的な巨額の赤字案件はなくても、不採算案件の数が多いから、火消しに追われることになった。 」まさしくこれでした。新規開発以外は火消しばかりやってた気がします。お客さんにギャンギャン怒られてるマネージャーを尻目に明け方まで修正作業とかね。

製造・流通の開発現場にいて、不思議に思っていたことは、公共系に比べて設計書などの資料があまりまとまってなかったこと。これは、単に関わったベンダーの性質だったのかもしれませんが、なべて設計書等に時間をかけることがなかったように思います。あと、システムなんかでもモジュールの共通化やコード規約の標準化などがあまり意識されていなかったことも思い出にあります。これも記事にあるような「雑多な案件を受けるから専門的な業務ノウハウは蓄積しにくい。 」ということに関連するんでしょうか。

こうあらためて比べてみると、双方で共通するノウハウってのはおどろくほど少ないように思います。同じシステム開発なのに考えないといけないポイントがまったく違います。そのポイントってのは開発環境とかプログラミング言語とかじゃなくて、主にお客さん側の事情なんですよね。抑えておくポイントは、お客さんの仕事の内容であり、考え方であり、もっと ぶっちゃけると、喜びどころと怒りどころなんですよね。

記事は「2008年以降の事業イメージがなかなか見えてこない。」と言って締めてますが、たしかに現状のような開発業の体制では未来が見えないですよね。しかしシステム開発業を広い視野で捉えた場合、そうでもないと思います。

開発の現場では、当時はパッケージ開発が主流だったのに対し現在はアプリケーションフレームワークなどが充実し、適切な技術があれば迅速でバグの少ないシステムが開発可能になりました。さらに、取引先の企業などでもシステム部門等が設けられるようになり、取引先のIT知識のレベルが向上し、要求が具体的専門的になってきているので、開発ベンダーからすると会話がしやすい環境になってきていると思います。

こういう時代の変化を捉えて顧客対応なり開発プロセスなりを刷新して新たな事業モデルを作っていくことができれば、次世代のITサービスのやり方が生まれるでしょう。

具体的にどうやるかって?
それを言ったら商売になりまへんので(笑)

|

« なつかしきターボシリーズ | トップページ | Linux入りのThinkPad!? »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/125677/2993452

この記事へのトラックバック一覧です: 流儀も変化の時期かもしれない:

« なつかしきターボシリーズ | トップページ | Linux入りのThinkPad!? »