ここ２～３年、業務のスタイルに変化はみられますか？
・人月計算方式の目論見をやめた。
・無茶な顧客は切った。
・「人貸し産業」から、教育など人材投資や自社へのノウハウ蓄積に注力しだした。
・請負案件のみから脱却、自社製品を開発するようになった。
・「納品したら逃げる」を止め（不具合や使い悪さは放任、改修は収益薄いから拒否）
納入先サポート・アフターフォローを厚くするように政策転換した。
・WEB2.0やらゼロデイやらと業界用語で粉飾・不安を煽る虚業スタイルから、
顧客要求第一とする営業・設計スタイルに改めた。
・営業担当と技術担当、連携が強くなった。
・ミドルウエアについて、自社関連製品以外も使えるようになった。
・下請け案件を削減、元請け案件に比重を置くように変わった。
・客先常駐よりも自社内開発を増やしている。
・育児休暇や有給休暇を取りやすくなったり、勤務時間や曜日が自由化したり、勤務スタイルが変わった。
・実残業時間削減。不要な休出は悪。
・アーキテクト(技術)とマネージャ(管理)、地位が以前より対等に。
などなど・・・
もしかして、逆行してます？？
No.3
332
25
20pt
あくまでも私の周囲での話です。他はどうか知りません
現在不況下にあって、案件が激減して、食っていくために
昔は敬遠していたヤバイ案件にも手を出さざる得なくなりました
また、ISO、ISMS、プライバシーマークなどの認証がないと
そもそも顧客に相手をしてもらえなくなり、
毎年の監査とその管理工数も馬鹿になりません
私が主に行っている業務は止まると困る性質のものなので
枯れたものしか使っていませんが、新しい技術のノウハウが蓄積されてきたので
新しい技術(でも最新ではないです)に切り替えようかという話もありますし、
一部のサブシステムは実際に切り替えています。
10年前みたいな徹夜、休日出勤当たり前のような状況は無くなっています
コスト意識が高くなり、プロジェクトが火を吹きそうになると
すぐにケアしてくれるようになりました。
# 案件が無くて人が余っているからできているんですけど．．．
私自身は年齢的なものもあり、最近はプログラムを書いているよりも
色々な報告書やら部下の指導などの管理的な時間が長くなりました
また、不具合に対して昔よりも厳しくなり、修正だけではなく
何故その不具合が起きたのかの原因調査や再発防止策も求められています
うっかり不具合を出すととんでもない稼動が取られるので
皆、不具合を出さないように必死です。
まぁ、それでも人間なので出るときには出てしまうのですが、
２重、３重のチェックを行って不具合が出る確率を下げる努力はしています。
取り留めなく書いてみましたが、
昔と比べてコストと品質が厳しく求められるようになりあまり冒険はできなくなっています。
が、その副作用として品質を高めるためには人間を酷使すべきではないという考えになり
納期間際とか本番トラブル発生時は別として、昔よりも残業はしていません。
いろいろありますが、私はこの変化は歓迎すべきと思っています。
No.1
26620
20pt
なるほど、どうも有り難う御座います。
クラウドやＷｅｂサービスは、参入障壁低めかつ継続した収入源として期待できそうですね。
オリジナル製品の一部分として、自社クラウドを利用するアーキテクチャも面白そうです。
No.3
33225
ここでベストアンサー
20pt
あくまでも私の周囲での話です。他はどうか知りません
現在不況下にあって、案件が激減して、食っていくために
昔は敬遠していたヤバイ案件にも手を出さざる得なくなりました
また、ISO、ISMS、プライバシーマークなどの認証がないと
そもそも顧客に相手をしてもらえなくなり、
毎年の監査とその管理工数も馬鹿になりません
私が主に行っている業務は止まると困る性質のものなので
枯れたものしか使っていませんが、新しい技術のノウハウが蓄積されてきたので
新しい技術(でも最新ではないです)に切り替えようかという話もありますし、
一部のサブシステムは実際に切り替えています。
10年前みたいな徹夜、休日出勤当たり前のような状況は無くなっています
コスト意識が高くなり、プロジェクトが火を吹きそうになると
すぐにケアしてくれるようになりました。
# 案件が無くて人が余っているからできているんですけど．．．
私自身は年齢的なものもあり、最近はプログラムを書いているよりも
色々な報告書やら部下の指導などの管理的な時間が長くなりました
また、不具合に対して昔よりも厳しくなり、修正だけではなく
何故その不具合が起きたのかの原因調査や再発防止策も求められています
うっかり不具合を出すととんでもない稼動が取られるので
皆、不具合を出さないように必死です。
まぁ、それでも人間なので出るときには出てしまうのですが、
２重、３重のチェックを行って不具合が出る確率を下げる努力はしています。
取り留めなく書いてみましたが、
昔と比べてコストと品質が厳しく求められるようになりあまり冒険はできなくなっています。
が、その副作用として品質を高めるためには人間を酷使すべきではないという考えになり
納期間際とか本番トラブル発生時は別として、昔よりも残業はしていません。
いろいろありますが、私はこの変化は歓迎すべきと思っています。
どうも有り難う御座います。
ドンブリ勘定、マンパワー頼り、個人任せ、やっつけ仕事上等、から
高計画性、組織での対応、ノウハウ蓄積型（不具合の要因解析も含めて）への変化は、
私も歓迎すべき変化に思えます。
ＩＳＯやＰマークは、もはやＩＴ業界でも必須ブランドになっていましたか...
No.4
632
20pt
いえいえ、あなたの仰る通りです。
これだけ世の中の進歩が早く、アーキテクトもその対応力が求められる中、重要なのはクライアントの課題に関して、今の最新技術をシステム・プラットフォームとしてどう使い、更に重要なのはそのプラットフォームをどのように運用して、ノウハウを貯めるかです。
最終的には人間が判断します。
そういう意味でもPDCAサイクルを徹底し、トライアンドエラーを繰り返し、ノウハウを貯めて、クライアントに提供することだと思います。
私自身もそうしております。
>顧客要求第一とする営業・設計スタイルに改めた。
と言うのはどうかと思います。と言うのは顧客はその答えを持っていないからです。
重要なのは共有すると言う、パートナーシップの関係を作ることです。
どうも有り難う御座います。
＞顧客はその答えを持っていないからです
これは、SIerにとってつらいところですよね。。
「どんなふうにしたいんですか？」
⇒「いや、よくわかんないんだけど・・・とりあえず便利にしてよ」
みたいな・・・
顧客のほうで課題解決方針や運用ルールががっちり固めていれば、
あとはそれをコンピュータ類に置き換えるだけだから
ＩＴ技術者の皆さんの、大得意中の大得意ではないでしょうか？
下手すると
なぜか経営や利益創出手法まで突っ込んでSIerで設計・面倒みるハメになったり。
そっちで経営コンサルに月数百万払って聞いてくれよ、と言いたくなります。
もしくはうちで経営してやるから会社ごとよこせ！と。(これは言いすぎですね)
営業さんの受注競争の犠牲なのかもしれませんが、
システムインテグレータと業務コンサルとの線引きをしっかりしておくことで、
デスマや暫定リリース後のぐずぐずした延長もだいぶ減らせると思います。
後工程にしわ寄せが集まってくる宿命ですから。
顧客にとっては、枯れたアーキテクチャでも良いので
意図したとおりの動きを確実にすることを期待します。
（俗に金メッキと呼ばれますが、
良かれと思ってつくられた仕様外の機能は、ときにむしろ困ってしまうものです。）
そして、技術者にとっての設計開発は日々の繰り返しの一部であっても
発注者にとってのそれは数年～十数年使いつづけるものであることを
ちょっとアタマのスミに置いて設計・開発して欲しいな、と思います。
（実際そうされている方が殆どだと思います）
そのような意味で、受注プロジェクトを人柱にせず
日々情報収集やノウハウ蓄積に研鑽していただきたいな、
と発注者として思います。
文意が散漫した文書ですみません、日々お疲れ様です。
No.5
10
20pt
メーカーの物流システムの保守をしてます。
うちの会社もBombastusさんの仰るとおり労働基準法改正のため、残業時間管理が厳しくなりました。
またより人件費を削減するため海外へのオフショア（中国、インド）がかなり増加しました。
どうも有り難う御座います。
労働基準法改正
http://www.mhlw.go.jp/topics/2008/12/tp1216-1.html
労働者としては、有難い改正ですね。
(一方で虚偽の記録を強いた場合の罰則がなさそうなので、サビ残させる黒会社は相変わらず野放しかもしれませんね)
オフショア開発が増えましたか・・・語学とお国事情が分かると重宝されますね。
pkb_wn
2010/05/30 16:10:30
362
345
1
1
どうも有り難う御座います。
ドンブリ勘定、マンパワー頼り、個人任せ、やっつけ仕事上等、から
高計画性、組織での対応、ノウハウ蓄積型（不具合の要因解析も含めて）への変化は、
私も歓迎すべき変化に思えます。
ＩＳＯやＰマークは、もはやＩＴ業界でも必須ブランドになっていましたか...