第4回 システム屋にとって好都合な「IT人材不足」
経営者にとって、情報システムは頭痛の種になりがちだ。業務に必須だが投資に見合った効果が出るとは限らない。ほかの設備投資に比べて専門的で難解でもある。 野村総合研究所で約20年間勤務した後に、人材派遣大手スタッフサービスのCIO（最高情報責任者）を務め急成長を支えた著者が、ベンダーとユーザー両方の視点から、“システム屋”の思考回路と、上手な付き合い方を説く。 前回（第3回）では、企業の情報システムが目に見えないところでその企業の競争力を左右していることを説明しました。 この情報システムは、誰が発想するのでしょうか。誰が作っているのでしょうか。誰が守っているのでしょうか。ここに“システム屋”と私が勝手に呼ぶ人たちがいます。（第1回もご覧ください） 私もシステム屋の1人です。ITベンダー・システムインテグレーターに勤務している人、製造業・流通業など「ユーザー企業」の情報システム部門・システム子会
ユーザ企業内製は幸福をもたらすか？ - 砂漠の音楽
デブサミ2009１日目のセッション、「使う」と「作る」がつながるシステム開発を聴講してきた。「使う」側のユーザ企業と「作る」側のSIer間のギャップをテーマとしたパネルディスカッションだ。モデレータは平鍋氏、パネラーはSaaS代表の倉貫氏（id:kuranuki）、ユーザ企業代表の千貫氏、SIer代表の橘氏という面々。 システムは使われて初めて価値となるもの。現在のSIは、作る人と使う人が仕様書で分断されていることが多くないでしょうか？これは、SIというビジネス構造の問題かもしれませんし、ソフトウェア開発方法の問題かもしれません。米国では、ユーザ企業が内部にシステム開発部隊を持ち、ユーザ部門とシステム部門が密なコミュニケーションを取るスタイルが多いようです。一方、単純なシステム開発はどんどんオフショアされる傾向にあります。本セッションでは、SIというシステム開発のやり方を、使う側と作る側か
QCDより重要なもの - essence-s
QCD(品質、費用、納期)は指針の一つでしかない。 例えQCDが完璧であっても、結果として大失敗であるきともありえるし、その逆もありあえる。実際にそれらの実例もある。 誰にとって何が成功なのか、あるいは、社会を含んだ全体最適の視点からはなにをもって成功とすべきなのかもう一度、考え直す必要がある。 そもそもITシステムは、業務プロセスを支援するためにある。 業務プロセスは経営ビジョンを推し進めるための戦略をすすめるためにある。 その戦略が成功しなかったらITシステムの価値はない。 QCDしかクリアできないSIerは淘汰されて行くか、システム開発の契約モデルは変わっていかざるおえないだろう。 戦略からくるビジネスレベルのフィードバックが適切にイメージできて、なるべく細かい単位で反映、検証できることが重要なはずだ。
株式会社マジカジャパンの羽生章洋が書いてるブログ:インハウス時代のソフト会社 - livedoor Blog（ブログ）
ここ数年、OSS（オープンソースソフトウェア）関連で講演させていただくときに「インハウス（内製）が復権する時代の到来」ということをお話させて頂いてます。 このような事例があったりします。 ということは、逆に言うと弊社のようなオーダーメイドの業務システムを作っているソフトウェア会社は困ってしまうわけです。自分たちで出来るからお前らイラネ、ってことになってしまいかねません。 では、私たちは本当に無価値になってしまうのかというと、そこはまた違うと考えています。プロとして提供できる価値というものを考えていくことで、生き残っていけると考えています。逆に言うと、従来通りのままで大丈夫などと考えていると厳しい時代であるともいえます。端的に言うと、作る作業と手間に対しての対価を頂くのではない、別の収益構造を模索していく必要があるのでしょう。 そもそも作ること自体に対価をもらうのを前提とするならば、OSSな
メタプログラミングと内製回帰の組み合わせは強力 - Float on the flow
メタプログラミングで生産性が超あがるよ！という話の件。 システム開発を生活の糧としている自分にとって、よくわかる話です。 ただ、実際にメタプログラミングが強く利いてくるのは、 数億〜数十億円規模の大規模プロジェクトじゃなくて、 ユーザ企業内での内製だと思う。 SIerが入る大規模プロジェクトだと、プログラミング以外の要素が 多すぎて、メタプログラミングがもたらすメリットがあまりない。 システム開発工程の中で、ボトルネックはプログラミングではないよ、という。 （要件定義とかコミュニケーションロスが顕在化するのがプログラミング工程で あることが多いから、そう思っちゃうけど） それどころか、デメリットである 「高位ロジックが、高度であればあるほど、最終的に何が起こるのかが、わからなくなってしまう」 （by id:higayasuoさん http://d.hatena.ne.jp/higayasu
「下請けに出していた仕事の内製化でコスト削減」の謎
ネットバブルが弾けてIT業界が不景気だった頃、ITベンダーのコスト削減策でどうしても理解できない話があった。いわく「下請けに出していた仕事を内製化することで、ソフト開発を効率化する」。変な話だ。しゃべった人に聞き返しても、にやっと笑うだけ。そう言えば最近、またそんな話を聞くようになったのだが・・・。 この話、今ではその理屈がよく分かる。だが当時は全く分からなかった。そりゃ、そうでしょう。ユーザー企業から受注したSI案件では、原価を引き下げるために人月単価の安い外注を使うはず。なんで、内製に戻すと効率化（＝原価引き下げ）になるのか。分からない。何かモノ凄い開発支援ツールができたため、オール内製での生産性が画期的に向上したのか・・・いろいろ考えたが、やはり分からなかった。 実はこれ、簡単な理屈だった。不景気になって受注案件が減り始めると、ITベンダーの社内で技術者に余剰が生まれる。彼らに仕事が
システム内製化 (Commutative Weblog)
日経コンピュータの１０月１５日号によると、システム内製化を図る会社が段々出てきたという。もともと、システム外製化が流行ったのは、ＩＴ開発の人員を社内で抱えることが、人件費の点で負担になり、また、熟練した外部ＩＴ企業にアウトソースした方が効率的という意味だったと思う。 それでも、システム内製化が見直されてきたのは、次のような理由による： １．スピード感：システム内製化すると、プログラム・ロジックをよく知る人が社内にいることになる。すると、業務変更のための仕様態様で、プログラムを書き換えるのが容易である。それ以外にも、いちいち見積もりを取ったり、仕様の打ち合わせミーティングしたりという手間がいらないという利点である。このような手間を省けるのでクイックに対応できる、という次第である。 ２．スキルの留保：また、内製化すると、開発者のスキルを社内に蓄積することができる。 ３．社内業務の熟知：同様に、
システム内製化のススメ - GoTheDistance
内製回帰厨としては今回の日経コンピュータの特集は見逃せないので、もちろん買ってみた。 日経コンピュータ 2008年10月15日号 SI関連のエントリでは一貫として内製回帰すべしと言っているので、超間接的に今回の特集に寄与できたと自負しています。僕のブログは数百の企業ドメインからのアクセスがある。もちろん日経さんらしき所からも。というわけで、何かしらのヒントになったかもというかなってくれないかと思っていますw 内製化のメリットとは何か 内製化の最大のメリットは、ビジネスのPDCAを素早く回すことが出来るということに尽きます。これが出来て困る会社は、原則どこにもないでしょう。 今回の特集を読ませて頂いて、内製化のメリットはだいたいこのようなところだと思います。 システム化計画〜実装までのサイクルが早くなる システムのブラックボックス化を避けられる 開発工程での手戻りを少なくすることが出来る 使
システム内製が，日本の国力を底上げする
「最近，システムを自社で内製する企業が増えていない？」 2008年10月15日号の日経コンピュータで特集した「システム内製化 再び！～自社開発を強化する12社の決断」は，編集部内のある記者が発したこの一言が始まりだった。部内の記者や編集委員などから続々と「システム内製」の情報が集まってきた。かく言う筆者も内製回帰への兆しを感じていた。ベンダーの評判を聞いても“要領を得ない”ユーザーに最近連続して出会っていたからだ。例えば，以下のようなやり取りだ。 記者：ベンダーの提示するシステム開発のコストについて，妥当性の判断が難しいとの声を聞きます。どのように判断していますか？ A社：お役に立てなくてすみません。オープン化を機に内製にしました。社内の人件費が開発費で，ベンダーに支払うのはサーバーなどハードウエアの費用のみです。 このように内製に取り組むユーザー企業では，システム部門のプレゼンスが格段に
システム内製化に走るユーザー企業とSaaSの親和性
ユーザー企業で再び情報システムの内製化に向けた取り組みが活発になっているという。実際にここ半年ほどでユーザー企業からそんな話をよく聞くようになった。ところで、その一方でSaaSやクラウド・コンピューティングの流れがある。まるで正反対の動きに見えるが、実は同一線上にある。刺激的、かつ表面的に言うと「SIerを外そう」ということだ。 内製化と言っても、いまさらスクラッチでシステムを組み上げる話ではない。日経コンピュータも特集したが、システム開発の外注化で失われた、業務要求の取りまとめ、要件定義、仕様の確定、プロジェクト管理など本来の情報システム部門の能力を取り戻そうという動きだ。もちろんパッケージ・ソフトの活用を前提に開発も行う。外部のITベンダーを使う場合でも、一括請負を止めて、準委任や派遣で手伝ってもらう。つまり、自己責任でシステムを作りましょうというわけだ。 本来なら、これはもう当たり前
どうせ理系出身者なんていらねえんだよ。
いまさら言ってもしょうがないだろうが、SIerに就職を希望したり内定した人たちに一言いっておきたい。 http://blog.miraclelinux.com/yume/2007/11/post_1ab2.html http://d.hatena.ne.jp/itoyosuke/20071101/1193932945 http://www.atmarkit.co.jp/news/200710/31/ipa.html 元の報道や参加者のブログエントリ見たりすると、ありがち過ぎて泣けるのだ。はっきりいうと、SIerの人事は情報工学科出身者は求めていない。それどころか理系出身者すら求めていない。 口先では求めているというよ。また、現場で最後に「技術的になんとかする」のは理系に期待されることが多いし、実際に期待通りに解決するのは大抵理系だ。しかし評価はされないし感謝もされないよ。とくに給料に反映す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ITシステム内製支援サービス — metametaweb