日本のITエンジニアの地位はなぜ低いのか：日経ビジネスオンライン
日本になぜグーグルのような会社ができないのか――。 古くはマイクロソフト、最近ではグーグル、フェイスブックなど、アメリカではテクノロジーに強みを持つ企業が多数登場している。日本でも、LINEなどの世界的に影響を与える会社が登場しつつあるとはいえ、アメリカに比べれば圧倒的に数が少ない。 この理由として、日本人は新しいことにチャレンジしたがらない、ベンチャーキャピタルなどの投資環境が整っていない、前例主義や過去の実績を重視するのでベンチャー企業の製品やサービスを敬遠しがち、などがよく挙げられる。 だが、「日本ではエンジニアが評価されない」ことが、大きな阻害要因になっているのではないかと、ギノの片山良平CEOは指摘する。 ギノは、ITエンジニア（システムエンジニア）に実際にプログラム（コード）を書いてもらって技術を評価するサービス「paiza」（パイザ）を昨年10月に開始したベンチャー企業。これ
「SIガラパゴス」を育んだIT部門の罪
日本のIT産業は、世界に類を見ないユニークなエコシステム（生態系）をつくり上げた。大手SIerを頂点とする多重下請け構造のピラミッドから成るITサービス業のことだ。日本だけで独自進化し一大産業として繁栄した。私はこれを「SIガラパゴス」と呼ぶ（関連記事：日本だけ！「SIガラパゴス」に明日はあるか）。 極めて便利な存在であるため、ユーザー企業はこの生態系を育んだ。その結果、日本企業のIT活用は今や欧米企業に比べ周回遅れで、新興国の企業にも追い抜かれようとしている。 米国のITベンダーの日本法人社長は、本社の幹部から「なぜ日本にはITサービス会社があんなにたくさんあるのか」とよく聞かれるそうだ。米国にもアクセンチュアやEDSのような企業は存在するが、数は限られているからだ。そして回答に苦慮する。 「日本のユーザー企業は独自仕様のシステムを作りたがるのに、その開発を外部委託することが多いから」。
【書評】なぜ、システム開発は必ずモメるのか？ 49のトラブルから学ぶプロジェクト管理術 - GoTheDistance
日本実業出版社の今野様より献本御礼。 なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術 作者: 細川義洋出版社/メーカー: 日本実業出版社発売日: 2013/09/27メディア: 単行本（ソフトカバー）この商品を含むブログ (2件) を見る 東京地方裁判所でIT事件担当の調停委員を努めておられる細川氏が、ご自身の経験をまとめてシステム開発のモメるポイントを整理し「人の振り見て我が振り直せ」を啓蒙する位置づけの図書になっております。 こう書いてしまうと非常に堅苦しいですが、モメるポイントをわかりやすく伝えるために「IT事例に詳しい美人弁護士に相談する」というカジュアルな設定になっています。塔子さんがその弁護士役で、厳しい指摘がコンビネーションブローのように続いており、爽快感がありました。 一部、本書の会話内容をご紹介します 彩音 「もう設計も終わる時期なのに、ま
SIer を再び人気職種にするためには、これだけ変えればいい - ジャスミンソフト日記
私が就職活動を行っていた20年前、SE は花形職業の一つでした。しかし今は 3K として敬遠されるようになり、力のあるプログラマーは SIer を避けるという状況となっています。 この業界で骨をうずめようと考えている身にとって、なぜ今日のような状況になったのかという原因を探ることは責務と感じます。また、これを解決するために自身（と会社）のエネルギーを注ぎたいと思っています。 まず次の二点は、私が同業の方と話をしていて、よく話題になる事項です。 人月制度に代わる見積手法が確立されていないこと。人月による見積が妥当なのはコンサルタントなど、上流設計の一部のみ。例えば製造で1,000人月という数字は、根拠があってないようなもの。 階層構造によるコミュニケーションストレスの存在。階層構造の下部に位置するSE/プログラマが仕様の矛盾に気付いても、直接確認することができない。また、お客様との接点がない
マイナンバーのシステム設計に関する入札2件 | スラド IT
共通番号(マイナンバー)制度のシステム設計に関する入札が2件、官報に公示されているのを見つけた。 国税庁長官官房：「社会保障・税番号制度」導入に伴う法人番号システムの設計及びアプリケーション開発等作業の請負(平成25年8月15日、官報号外政府調達第153号、p.1-p.2)国税庁長官官房：「社会保障・税番号制度」導入に伴う共通番号管理システムに係る設計・開発(平成25年8月15日、官報号外政府調達第153号、p.2) 一見してわかる通り、国税庁が7月1日におこなった意見招請2件が(/.J記事)、早くも入札に漕ぎつけたということだ。法人番号に関しては、内閣官房から8月9日に「事業主における番号の利用例」が公表されており、今回の入札と連動したものだろう。ただ、総務省が6月26日におこなった意見招請1件は、まだ入札に漕ぎつけていないようで、今後の動向が注目される。
もしSIerのエンジニアがジョブズのスピーチを聞いたら（１） - Wadit Blog.
最近、いわゆるSIerと呼ばれる業態がヤバそうだという話が聞こえてくる。富士通の3万人のSE職の転換とかが話題になった。おそらくどこのSIerも相当の危機感を抱いているのちがいない。従って、そこで働いているエンジニアのかたがたもこれからの行く末に悩んでおられると思う。 そこでちょっと旧聞に属する話で恐縮なのですが、いくつかのブログ記事についてコメントしておきたいと思う。流しておけばいいのだが、どうも根本的なところで勘違いしているようで気になっていたのであえて取り上げておくことにする。まずは、GoTheDistanceさんの「「SIerでのキャリアパスを考える｣というイベントに登壇しました」というエントリーで（別に個人的にどうのというのではなく一般論として取り上げてみたのである、湯本君ゴメン）、そこでのプレゼン資料を公開され、その解説が書いてある。 最初の問題提起として、「僕が常々問題にして
人月を超えるエンジニアリングの未来 - GoTheDistance
ご無沙汰してしまっているmark-wadaさんより問題提起を頂いたので、最近話題になった「超高速開発」と絡めて書いていきます。 もしSIerのエンジニアがジョブズのスピーチを聞いたら（１） - Wadit Blog. もしSIerのエンジニアがジョブズのスピーチを聞いたら（２） - Wadit Blog. もしSIerのエンジニアがジョブズのスピーチを聞いたら（３） - Wadit Blog. もしSIerのエンジニアがジョブズのスピーチを聞いたら（４） - Wadit Blog. 僕のエントリに対する和田さんのご指摘をまとめると、ソフトウェアを作るにあたっては上流と下流の断絶があるのはマイナスなのは理解できるし、コードを書く時にはその断絶があると望むものを作ることは出来ないのも確か。だが、システムを作る時にはそもそもレイヤーをもう１つ上に上げるべき。スクラッチでコードを書く必然性など無い
ITを活用できる組織を増やす為に必要なこと - GoTheDistance
Publickeyさんで特許庁の基幹システム問題が取り上げられています。今回の件はどう考えても特許庁の体制が根本的な原因なので、TSOLが50人を1300人に増やしたことを槍玉に挙げても不毛だなと思っております。 特許庁の基幹システム失敗の背景にある、日本におけるITプロジェクトの実態 － Publickey この辺のITのメディアの言説は大抵「なぜXXXプロジェクトは失敗したか」的なざっくりとした問題提起なのですが、失敗にも色んなケースがありますので、本来はそれらを因数分解して細部を議論しなければ教訓は得難い。後に残るものは、ワイドショーレベルの非生産的な言説をみのもんたが茶化すぐらいの微妙な空気ですか。こういう言説がIT業界のイメージダウンに繋がっていることを認識してもらいたいものです。Publickeyさんみたいに、生産的な言説が増えていかないといけない。そういうITのメディアを作っ
特許庁の基幹システム失敗の背景にある、日本におけるITプロジェクトの実態
今週月曜日に公開した記事「特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩本順三氏の述懐」は、記事に対して数多くのブックマークやツイートが行われ、大きな反響をいただきました。 その萩本氏から「問題提起だけで終わるのではなく、こうあるべきだという提案もしたい」、という依頼をいただいたので、記事にいただいた反響への返答という意味も込めて、萩本氏の提案についても掲載したいと思います。 以下からは萩本氏の文章となります。 これまでのIT業界の慣習を捨て去り、あるべき姿へ 僕が日記（注：記事の元になったFacebookへの書き込み）を書いたのは、二度とこのような案件が出ないよう本質的な問題提起をしようと思ったからです。 それが僕の責任だと思いました。 本質的問題を提起したつもりですが、しかし本当に理解していただいたのかというのが心配でもあり、また理解していただいたとしても、今後何
プログラマ35歳定年説、定年後の未来 - GoTheDistance
株式会社クラステクノロジー代表の四倉氏の連載コラム「第151回」が、とても興味深いのでご紹介します。 【第151回】35歳定年説の真実-株式会社クラステクノロジー 詳しい内容は上記コラムをご覧頂きたく。 プログラマ35歳定年説とは 上記の四倉氏によれば、プログラマ35歳定年説とは｢1Step,1Stepの生産性に比例するので、長い間労働すれば高いアウトプットが出せ収入が増える。体力が下り坂になってきて徹夜や残業ができなくなるのが、大体35歳前後。体力低下と共に収入も下り坂。それに限界を感じてIT業界去ってしまう｣ということのようです。これをプログラマと呼ぶのかとか、ステップ数(笑)という憤りもあるでしょうが、｢ステップ数と売上が比例するため、いっぱいコードを書けば収入が増える｣という理屈は腑に落ちました。是非の問題ではなく、確かにその理屈なら体力勝負という表現も理解できる。 そして、この理
【告知】12/18に＠ITの特集｢SIerの未来、エンジニアの未来｣で記事が公開されます。 - GoTheDistance
2009年、SIerの現状を俯瞰する − ＠IT自分戦略研究所 今週の金曜日です。テーマは得意の｢内製化｣です。生々しい経験を可能な限り詰め込んでみました。 ああ、僕も出世したな・・・！こんなところに記事を書けるようになるなんて・・・！ この前セブンアンドアイさんが内製したECサイトで個人情報ダダ漏れというニュースがあり、僕のこの記事を出すタイミングでやってくれるなーと思いつつ内製派の私としては(´･ω･`)ｼｮﾎﾞｰﾝなわけでございますが、これは内製・外注以前の問題なのではと思います。組織的な問題でしょう。外注しても同様の問題を発見し解決できる組織的なサポートが無いなら、おなじことなので。内製の場合は適切に的確な技術やツールを選ばないと痛い目見ますよ、という暗示になってくれてありがたいぐらいに考えています。 しかし、社内に閉じたシステムなら自分達が痛い思いするだけで済みますが、外部公開し
【不況】 IT業界がヤバい エンジニア「マジで仕事がない。」 : よろしい、ならばクリークだ -2chまとめ-
2009年07月28日03:42 【不況】 IT業界がヤバい エンジニア「マジで仕事がない。」 カテゴリN速民の井戸端会議 1 名前： 姫カンムリシャジン(関西地方)[sage] 投稿日：2009/07/27(月) 19:05:00.26 ID:fjqg106g ?PLT(12000) ポイント特典 IT業界っていっても非常に大きくて、ネットワークからユーザサポート、システム開発とあるわけだけど、 その中でシステム開発、とくに業務アプリ開発業界のうごきを1エンジニアの目から見てみる。 現状を端的にいえば、「非常に厳しい」ものとなっている。 日本の業務アプリ開発は長い間、客が提示する案件を大手SIが受注し、 それを大手SIの子会社と外部協力会社（派遣会社）から派遣された技術者がくみ上げていた。 ところが08年のサブプライム、リーマンショック以降、客が案件を提示しなくなった。 それがもろにでた
システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出
受託開発はプロフェショナル・サービスの領域になる - GoTheDistance
メディアに乗るとなんでも釣りっぽく思えてしまう汚れた僕ですが、本件については数年前からとっくに曲がり角に来ていると思っています。 受注するだけの製品販売や顧客の言うがままに作るSI（システムインテグレーション）、委託されるだけのアウトソーシング、報告書を作成するだけのコンサルティング─。IT業界に染みついた「受託体質」は、ビジネスモデルの転換期を迎えているユーザー企業のシステム構築・維持にとって、むしろ足かせになっているのかもしれない。 乱反射 - 曲がり角にきた受託体質のIT業界 顧客は共同で事業創造を望んでいる：ITpro こちらの記事で使われている｢受託体質｣の意味は｢要件はお任せしますので、労働力だけ提供しますという役務提供型のサービス｣という文脈のようです。それって単なる御用聞きだから、ビジネスモデルの改善・革新を求めているユーザー企業と足並み揃うわけがないよね、という趣旨だと解
大半のSIerが3次下請け禁止
コンピュータメーカーや大手SIerなどによる、再々委託禁止の動きはごく当たり前のものになってきた。 既に富士通や伊藤忠テクノソリューションズ（CTC）、CSKシステムズ、新日鉄ソリューションズ（NSSOL）などの大手から中堅SIerまでが、3次の下請けを禁じる「再々委託禁止」の規則を導入（表1）。今回の取材で回答を得られなかったが、取引関係のある複数の企業によると、日立製作所も同様の方針である。 NTTデータと野村総合研究所（NRI）、NECは、現在のところ多重下請けを一律には制限していない。ただし、協力会社が外注を活用する場合は必ず報告と許諾を求めるなどして、下請けの管理を強化している。 再々委託禁止より厳しい外注制限を課すケースも出ている。キーウエアソリューションズやシーエーシー（CAC）は2次への業務委託も禁じるようにしたのだ。また、ある中小SIerは「最近、日本IBMの2次下請けと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
長文日記
Domain Expired