プログラマーの成長を考えないSIerの仮説は間違っている - 達人プログラマーを目指して
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指してのコメントで 熟練者も居ることは理解しているが、開発をする上で熟練者ばかりを集めることはできない。このため初心者側にレベルを合わせざるを得ない。 というコメントをいただきましたけれど、これは実に典型的なSIer（の上司）の考え方ですね。SIerの仮説と呼んでもよいくらいですね。とにかく、この仮説の前提となっているのは プログラマーのスキルレベルは一定で成長しない プログラマーは容易に交換可能なリソースである プログラマーは単純労働者である というモデルです。とにかく、この仮説がはびこっているから、いまだにSIerのフレームワークは「初心者側にレベルを合わせざるを得ない」という思い込みで作られていることが多いのでしょう。 COBOL（の初期の）時代ならまだしも、少なくとも現在の開発環境にお
労働集約型の日本のソフトウェア開発。その問題の根源について
Eiji Sakai @elm200 楠さんのエントリに関連して。昔、@koshian 氏と語ったのだが、日本の IT 重層下請構造で、下請 => 元請というフィードバックが事実上存在しない。現場には実に生々しい有益な情報がたくさんあるんだが、すべて捨てられている。これって製造業の現場主義とは対照的。 2010-06-20 21:48:54 Eiji Sakai @elm200 日本人って IT やってるときと、モノを作ってるときで同じ民族とは思えないんだよな。IT では、プロジェクトの趣旨の徹底とか全体の設計とか、超いい加減で、政治的な理由でコロコロ変わっていくし。モノを作っているときのあの実直さはどこにいったのやら。IT を舐めてるのかな？ 2010-06-20 21:50:40
オフショアと生産性
オフショアと日本のシステム開発企業の生産性について。 価格勝負してもオフショアに勝てる訳もなく（その考えがそもそも違うのですが）、生活コストの高い国では生産性で勝負すべきではないかというお話。
はれ - ほどよくしっかり
今日はお酒はなし。 上司が、「最初からきちんとウォーターフォールでやっていれば」と話していました。何を他人事みたいに言っているのかと。毎月あなたがレビューしているじゃないですか。以前から思っていたんですよ。「こんなレビューやらなくても、うまくいくプロジェクトはうまくいくし、こけるプロジェクトはどうせこける。やるだけ無駄だ」ってね。今日まさにそれが明らかになったわけです。それに答える部下も部下。「そうですねぇきちんとやっておけば良かったですねぇ」ですって。おいおいいったい誰が責任者なんだよ。なんでみんな他人事なんだよ。個人攻撃は良くないけれど、プロ責やプロマネなら、どうしてきちんとウォーターフォールを実践できなかったか、報告書をまとめるくらいのことはしてもいいんじゃない？そんなんじゃいつまでたっても同じことを繰り返すだけだよ。 会社からWEBメールが使えなくなります。理由は、「ウイルスに感染
SIerはいまさら内製化できるのか？ - Sacrificed & Exploited
若い時にプログラムを書こう、必ず人生の豊かさにつながる | 日経 xTECH（クロステック）より 開発者はどこへ消えた ずっと気になっていたのだが、そもそもNTTデータの社員は開発をしているのか。 非常に危機感を持っていて、現状は何しろ内製率が低い。正直にお話すると全部合わせても3割とか3割5分ぐらい。残りは協力会社の方々に手伝ってもらっている。するとどういうことになるか。自分でコーディングしたり、ドキュメントを書いたりするより、コーディングする人たちを管理する仕事になってしまう。 いっぽう増田では、 日本のメーカー終了間近？ もう日本のメーカーのほとんどに、担当者は居ない。 製品のメイン開発者のほとんどが、社内に居ないのだ。 - 俺はプログラマー。 長年、とある組み込みマシンのメインプログラマーだった。詳細仕様、プログラムの細部、それらは全て資料化されているものの、膨大な量と難易度の為、
設計書の非常識1.設計書には詳細な実装方法を書く - Sacrificed & Exploited
SIerの常識：「誰が書いても同じソースコードになるように、詳細な実装方法の記述された設計書を書かなければならない」 プログラマの常識：「誰が書いても同じソースコードになるような設計書は書くだけ無駄、誰が書いても同じ振る舞いをするように、詳細に振る舞いを記述した設計書を書かなければならない。」 プログラムを作るうえで設計書や、仕様書の類は欠かすことができない だが、設計書や仕様書をちゃんと作っているプロジェクトでもよくデスマーチに陥っている。 なぜか？「設計書に記載するべき内容が間違っている」からだ。 （設計が間違っている場合も多々あるが。） 間違ったことをまじめにやっても良い結果は得られない。 「誰が書いても同じコード」は大事なことなのか - yvsu pron. yas 昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、そ
前向きなヒューマンエラー対策をしよう。 - Sacrificed & Exploited
SIerが仕切っている開発現場でありがちなのが、何かミスを犯すと、そのミスを防止するようにすごく手間がかかるチェックが追加されて、開発効率とモチベーションが下がるというダメなパターン。 たとえば、「今年度は申請書(EXCELシート)書いて上司の判子もらわないと svn commit すらできない職場で仕事することになりました。 - SiroKuro Page」とか。 これはプロセスマネジメントでもなんでもない、管理ごっこだ。管理したつもりになって自己満足しているに過ぎない！！ プロセスをマネジメントしたければプロセスを削れ: DESIGN IT! w/LOVE では、次のように述べられている。 プロセスマネジメントにありがちな間違いのひとつに、ミスを減らそうとして、そのチェックをするプロセスを増やしてしまうということがある。 もちろん、すべての場合にそれが間違いというわけではない。 そのチ
ステップ数の非常識2.ステップ数で進捗を管理する - Sacrificed & Exploited
SIerの常識：「毎日記述したステップ数を報告してください。」 こんな寝言を真っ昼間から堂々と言ってくれるSIerが多くて辟易します。 プログラムの実装がどれくらい進んだのかとステップ数には何の相関もありません。 プログラマの常識：「ステップ数なんかクソ食らえ、進捗は通過したテストの件数ではかるべき」 ダメな例その１ 「■週報でステップ数を報告するときの疑問」（1） Java Solution − ＠ITより 既存のコードを見直して書き直した結果、 クラスのステップ数が減った場合、 どのように成果を報告をすればよいのか悩んでいます。 下の場合、成果として報告できるステップ数は幾らになりますか？ 【先週】総ステップ数１０００ステップ 【今週】総ステップ数９００ステップ（先週比：マイナス１００ステップ） 上の【今週】ように上長へ成果報告をしたのですが、 結局何ステップ書いたのか分からないと注意
大手SIerでないとやれない仕事のパイは頭打ちか
日々雑記大手SIerの利益悪化がとどまることを知らない件 - GoTheDistance まぁ、厳しいですねぇ。 今まで比較的安定して要因を提供していたメーカーさんも、減員になったり人月単価が下がったりで人員を入れておく旨みが減ったこと、あと受託案件が減ったり、あっても短納期で作業量の多いハイリスクなものばかり。 社員をそれなりに抱えている会社だと、数人を食べさせるための仕事を取れば良いわけではなくて、数... 大手SIerの利益悪化がとどまることを知らない件 - GoTheDistance まぁ、厳しいですねぇ。 今まで比較的安定して要因を提供していたメーカーさんも、減員になったり人月単価が下がったりで人員を入れておく旨みが減ったこと、あと受託案件が減ったり、あっても短納期で作業量の多いハイリスクなものばかり。 社員をそれなりに抱えている会社だと、数人を食べさせるための仕事を取れば良いわ
PR：経営視点を持って開発していきたい――SIerからGREEへ転職
グリー株式会社 メディア開発部リーダー 山家匠さん（35歳／転職2年目） 【仕事内容】 証券会社向けの基幹系システム開発 → モバイル向けSNSにおける大規模Webアプリケーションの設計・開発 【開発言語】 C、C++、Java → PHP Web業界の中でも、ここ数年、特に目覚ましい成長を遂げているモバイル業界。転職市場においても積極的な採用活動を行う企業が増加中だ。しかし、システム業界出身者など、モバイルサービスの開発経験がないITエンジニアの中には、自分の経験をどう生かせるのか、疑問に感じている人もいるだろう。 今回紹介する山家（やんべ）匠さん（35歳）は現在、国内最大級のモバイルSNS「GREE」を開発・運営している『グリー株式会社』で活躍するITエンジニア。証券会社向けシステムに特化したシステムインテグレータ（SIer）に10年間勤務した後、より幅広い経験を積みたいという思いを抱
今年35歳になるので、エンジニアの35歳定年説というやつについて書くぞ - developer’s delight
エンジニア35歳定年説。IT業界で働く人なら一度は聞いたことがある言葉なのではないかとおもいます。誰が言い出したのか知りませんが、この言葉は非常にタチが悪く、言葉だけが一人歩きしていて多くの人が「35歳くらいになると能力・体力の低下により新しい技術についていけなくなり、引退を余儀なくされる」という解釈をしているようです。しまいには妙な拡大解釈でこのようなエントリまで書かれる状況です。僕の認識をどんぴしゃで書いてくれているエントリがないので、自分の経験を少し書いてみたいとおもいます。僕が「エンジニアは35歳が定年」という言葉を初めて聞いたのは、新卒で就職したソフトウェア開発会社でした。僕が就職したのは、法人顧客のための業務システムを開発している、いわゆるSIをやっている会社でした。ある日、会社の先輩に「この業界、エンジニアで飯を食っていけるのは35歳までだから、よく将来のこと考えておいたほう
株式会社エクスブリッジ (愛知/名古屋でエンタープライズ2.0を推進するWebシステム開発会社)
お客様の売上と利益に貢献できるIT企業を目指す名古屋のベンチャー。ECサイトの構築から運営までトータルにサポートできるIT企業です ビジョン エクスブリッジが取り組んできたこと ホームページ制作 デザイン制作だけでなく、収益につなぐ仕組み作りや販促企画のご提案・実施まで、トータルな支援を行ってきました 業務効率化によるコスト削減を支援 ビジネスの中核となる販売管理や在庫管理、生産管理などを低コストで構築し、業務効率化・収益拡大の支援を行ってきました モバイル系の先進技術にも対応したIT支援 主要３キャリアに対応した携帯サイトの構築、iPhone/Androidなどのモバイル技術に対応したアプリケーションの開発を行ってきました 無料で利用できるOSSによる低コストなIT支援 無料で利用できるオープンソースソフトウェアを徹底的に活用し、劇的に低コストなシステム開発を行ってきました ECにおける
人材教育のワナ (mark-wada blog)
4月は新入社員が入って来て、各企業はその教育に力を入れていることだろう。この新人教育の目的は何なのだろうか？スキルを上げるとか、知識を詰め込むとかいったことではないだろう。何といっても自分の会社の理念や方針、文化風土をたたき込むことなのであろう。 ただ、いまや終身雇用制もくずれようとしている時代に滅私奉公を要求するわけで、最初に入った一社に忠誠を尽くすことが受け入れられるのだろうかと思ってしまう。たしかに急成長した会社が大量の人員を採用するようなケースでは必要かもしれないがどうも違うような気がする。 さらに、ここでちょっと待てよと思ってしまのが、あなたの会社で必要な人材とはと聞かれた経営者が、「自主性をもって一人で何でもやれるような人」なんて答えるように、一方で経営幹部になるような優秀な社員になれということも同時に要求していくわけで、そのことと会社への忠誠とが矛盾しないかということである。
個人事業主の時代 (mark-wada blog)
ちょっと前の「カンブリア宮殿」というTV番組で物語コーポレーションの社長が出演していて、その会社やその人に興味をそそられた。物語コーポレーションというのは、焼肉とかラーメンなどのフード店のフランチャイズ事業をやっている会社である。 何がユニークかというとその店の店長にみな任せるというやり方で、予算、収益、人事などの一切を店長が裁量するのである。だから、経営者と同じである。そして、みな若い。20代で2億円の売り上げの経営をしているのだ。 この個人に委ねてしまうというところが素晴らしい。もちろん、それなりに教育もして、メンターなども置いてサポートもしっかりしているのだが、個人的な信頼関係を築いていることが重要なのだ。その時も放送されていたが、入社式で新入社員ひとり一人に対して、あなたにこういうことを期待するみたいな文章を渡すのである。そこから、「個」の尊重、「信頼」の伝達が始まっているわけであ
プライベートクラウドは、ベンダから主導権を奪還する技術。メインフレームからクラウド化に成功した佐川急便グループのIT戦略
プライベートクラウドは、ベンダから主導権を奪還する技術。メインフレームからクラウド化に成功した佐川急便グループのIT戦略 佐川急便を中心としたSGホールディングスグループは、ベンダや事業ごとに作られサイロ化していた200を超えるITシステムを、クラウドに載せ替えつつ効率化するとに成功しています。 SGホールディングスグループのITを担当しているSGシステム取締役の三原渉氏は、プライベートクラウドを、オープン化によりベンダからITの主導権を取り戻す技術だと位置づけ、コスト削減による戦略投資余力の創出という効果をあげているとのこと。 同グループのクラウド戦略を知ることは、これからプライベートクラウドに取り組もうとしている企業の参考になるはずです。6月30日にフューチャーアーキテクトの主催で行われたイベント「クラウドコンピューティング戦略セミナー」から、三原氏の講演内容をレポートします。 ベンダ
日本のSIerはクラウド普及の逆風なのか？
米国には、日本のSIerのような企業はあまり多くない、という話をしばしば耳にします。「シリコンバレーで奮闘中」というya2kanta氏のブログ余道を愉しむで、7月12日月曜日にポストされた「日本とアメリカのITに関連する違い」というエントリでも、その話題が取り上げられていました。 米国のIT市場の特徴の1つ目として「SIerがいない」ことが挙げられています。 アメリカの企業はシステムの開発／導入／運用を基本的に自社内のエンジニアが行う。日本のようにSIerにアウトソースして、一切を任せるということはない。 もう1つ米国の特徴としては「パッケージ製品を利用する」ことが挙げられています。 米国では、SAPなどのERPツールや、Salesforce などCRM系ツールの導入率が高いようです。よく売れているパッケージ製品というのは、それなりにキチンと考えられて作られているので、導入／利用する事で生
内製開発を考えているSI技術者が知っておくべき内製アンチパターン - aike’s blog
数年前から、ゼネコン的なSIerの業態に構造的な限界を感じ社内のエンジニアによる自社開発（内製）を見直す動きが見られます。自分の場合も少し前にSI企業を辞めて今は内製をしていますし、知り合いの技術者にも何人かそのような転職をした人がいます。しかし、彼らの話を聞くと良いことばかりではないようです。 そんなわけで、今回は内製に潜むアンチパターンをまとめてみました。なお、ここでは一般向けプロダクト開発ではなく、社内向け業務システムの開発を想定しています。 ■そこは異業種ですよ 内製ということは、ほとんどの場合その会社はシステム開発会社ではなく、異業種に転職することになります。そのため想像以上に開発の常識が通じないことにとまどう技術者も多いようです。SIのとき、システム開発に理解がないゆえに無茶を言う顧客にあたった経験があるかと思いますが、自分以外の社員が全員そのような人であるおそれもあります。
SIer が業績悪化しているのに何も変わらない | dTblog
SIer のなかの人は思考が止まってしまっているんでしょうか。 SIer 各社の業績が軒並み悪化しているにも関わらず、現場では新しい提案があるわけでもなく、それならどうやって業績回復のストーリーを実現するつもりなのかと思わされるような話がチラホラ。あとは、現状理解に乏しく需給関係が崩れつつあるにも関わらず、当然の顔で値上げ交渉をしかけてきたりする。バカなのかな、と思うわけです。 まずは状況整理 上場大手 SIer 各社の直近の状況を見てみます。 企業名 売上高 前年比 営業利益 前年比 来期予測 今年比 NTTデータ 1,142,940 100.3% 81,689 82.9% 1,200,000 105.0% 野村総合研究所 338,629 99.2% 40,077 80.6% 350,000 103.4% 伊藤忠テクノソリューションズ 290,391 94.5% 21,569 99.5%
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ご冗談でしょうSIerさん その4 - Sacrificed & Exploited
http://www.systemrenkei.jp/solution/so2_SIer.htm