SES会社を離れて10年、昔を思い返す - orangeitems’s diary
私は10年ほど前まで大きなSES会社にいたのだけど、一つ誤解していたので整理して晒そうと思う。 大きな会社においては、誰にどんな仕事を振るかなんて悩み方はしない。とりあえずいろんな案件を拾うルートを作る。これは直接ユーザー企業から案件を頂くプライムという立場もあるが、私が経験したのは大手SIerからの案件紹介だ。いわゆる二次請けである。大手SIerが取り組む大型プロジェクトに人材を送りお金を頂くという方法だ。基本的に毎月精算で会社にお金が振り込まれるし、請負でもないので完成責任もない。大手SIerならいくつも案件は抱えているので、そこに入り込んでいく。 案件を仕入れるルートを複数持つと、それに対して人が必要になるが、全部を今いる社員でやり切れないときがあるので、外部の協力会社に相談し、その会社の社員を送ってもらう。もちろん大手SIerに再委託の件も話し管理は弊社できちんとやります、なんて調
「AI開発ミステリー ～そして誰も作らなかった～」 とある大手製造業の怖いハナシ (1/5) - ITmedia NEWS
「AI開発ミステリー ～そして誰も作らなかった～」 とある大手製造業の怖いハナシ：マスクド・アナライズのAIベンチャー場外乱闘！（1/5 ページ） ITmedia NEWS読者の皆さん、はじめまして。マスクド・アナライズと申します。自称“AI（人工知能）ベンチャーで働きながら、情報発信するマスクマン”です。 日々、さまざまな企業から相談を受ける立場として、記事を通じてAI開発のリアルな現状をお伝えしたいと思います。AIやIoT、データ分析における華々しい成功事例やプレスリリースとは一線を画し、道理の通らぬ世の中にあえて挑戦する“シュートスタイル”を目指しております。 口火を切ったITmedia NEWSによる取材記事もご参照ください。 「開発の丸投げやめて」 疲弊するAIベンダーの静かな怒りと、依頼主に“最低限”望むこと 今回は「AI開発ミステリー ～そして誰も作らなかった～」と題し、AI
外注丸投げが過ぎると何のノウハウも身につかない問題 | 株式会社アクシア
外注ばかりしていて大企業の社員が劣化しているという記事が昨日出ていました。 残業減らしで外注急増、大企業社員の劣化が止まらない この記事の中では次のような具体例が出てきます。 プログラムを一度も書いたことのないＳＥ。 戦略作成はコンサルタント頼みの経営企画部員。 文章をまったく書かない編集者。 教育制度の企画運営を全部外注する教育担当者。 代理店のインセンティブ（奨励金）プログラムを作るだけの営業本部員。 「プログラムを一度も書いたことのないＳＥ」についてはこの業界の人間として痛いほど実感があります。エンジニアと名乗っていながら技術的なことが何もできない人の問題は度々話題に上がりますね。 他の例については自分の業界ではないので実感はありませんが、「プログラムを一度も書いたことのないＳＥ」の例と同じくらい問題のある事例ということでしょう。 大手SI企業のエンジニアがプログラムを書けない理由
派遣SE時代にはまったく思わなかった、とても大事なこと
派遣SE・プログラマを経てユーザー企業に移り、さらにユーザー企業内でシステム部門から業務部門へと立場が変わった。その過程で様々な人たちに出会った。 派遣SE・プログラマ時代を思い起こせば、「プロフェッショナル」と呼べる人がいた。初めて「この人はプロだな」と思ったのは、熟練のテスターであった。今思えば、フリーのエンジニアだったのだろう。見かけは普通のおじさんだったが、仕事になると確実に結果を出していた。当時私が派遣されていたSIerの管理職も一目置いていた。 仕事を終えた彼の姿を今も思い出すことがある。彼はヘビースモーカーだったようで、会社を出るなり、いつもたばこに火をつけて空に向かって大きく息を吐き出していた。たばこの煙がどこまでも舞い上がるように思えた。一服すると、足元でたばこを消し、両手をポケットに突っ込み、足早に去っていった。今となっては褒められる行為ではないが、私には印象に残ってい
SIはやめておけ
20代の数年間SIで働いた。1年以上前に退職して今は別業界にいる。 今日、Evernoteを整理していたら「退職理由、SIの嫌な点」というメモが発掘された。退職直前のかなりストレスがたまっていた時期に書き殴った文章だった。学生の頃の私は絵を書いたりしていて、ものづくりで暮らしたいな〜などと思って始めたプログラミングが楽しかったので安易に受託開発業を選んでしまったが、その後悔が如実に表れていた。 一部自分でも覚えていない話もあったがコンテンツとしては面白かったし、今でもシステムインテグレーター業界で消耗する若者を減らしたいとは思うので公開してみる。 以下、同メモに加筆・修正したものなのでファンタジーだと思って読んでくれ。 工数至上主義受注した時点で売上がおよそ確定するので、後はその予定工数に収めて納品できれば御の字という考え方。よくある話だが、見積がおかしくても顧客と対等な関係が築けていない
退職者が極めて少なく、ほとんど定時で帰れるシステム開発会社、その秘密とは。
何かと長労働時間、低賃金と騒がれがちなソフト開発であるが、優れた会社も数多くある。100名程度の普通のソフト開発会社であっても ・ほとんど定時で帰宅できる ・有休取得率8割 ・残業代100％支給 ・離職率は5％程度 と、まっとうな企業もそれなりに存在する。 では、いわゆる長時間労働、残業代未払い、高離職率の開発会社、いわゆる「ブラックのIT企業」と、彼らのようなIT企業は何が異なるのだろうか。 私の観察では、そういった会社は、以下において優れている。 1.経営者の営業力・交渉力 経営者および役員の営業力が高い。また、プロジェクトの途中での問題には率先して彼らが自ら顧客と交渉する。 このサポート体制のおかげで、技術者のリーダー陣は安心して仕事をできる。また、リーダー陣は経営陣の問題解決を見て、その方法を学ぶので、問題になるプロジェクトが少ない。 2.高いエンドユーザー率 営業力が高いので、全
ITエンジニア転職の現実：日経ビジネスオンライン
ITエンジニアなら、今後のキャリアを考える上で、「転職」を一度も考えないということはまずないのではないだろうか。それはITエンジニアは、ジョブローテーションを前提とした総合職ではなく、ITエンジニアリングを中心とした専門職であるということにも由来する。ITエンジニアは、企業に就職するという考え方ではなく、「ITエンジニア」という職業に就職するという考え方だからである。そこで今回は現在のITエンジニアの転職マーケットの状況について見ていきたい。 エンジニアの人不足、転職の現状 昨今、特に飲食業界等を中心として人材不足が叫ばれているが、IT業界はかなり以前から常に人不足と言われ続けている業界である。本コラムでも再三指摘しているが、事態は更に深刻な事態となりつつある。2014年9月18日の日経新聞でも「IT分野の派遣『月収100万円』でも集まらず」というような記事（有料会員限定記事）も出ている。
なぜ優秀なITエンジニアを採用、育成できないのか：日経ビジネスオンライン
前回は、「ITビジネスの軸が、コストセンター中心からプロフィットセンター中心に移った」ことを紹介した。今、ITビジネスの潮流は大きな変化の節目を迎えている。そのことがITエンジニアの採用、教育の現場に、主に3つの課題として表れてきている。 課題1：エンジニアが集まらない、既存の求人メディアではエンジニアにリーチできない 課題2：いい人を見分けられない、既存のプロセスでは技術の可視化が難しい 課題3：人が育たない、既存の教育システムでは育成が難しい 今回はこの3点について考察を進めていきたい。 ITエンジニアは人材紹介サービス経由で転職しない 企業の採用における課題1： エンジニアが集まらない、既存の求人メディアではエンジニアにリーチできない 弊社は人材サービスを運営しているため、人事の方から「既存の求人メディアや人材紹介などでは、なかなか優秀なエンジニアにアプローチが出来ない。優秀層にリー
IT業界の『多重下請け構造』は社会悪になりつつある - paiza times
Photo by Jonathan Kos-Read 今回のpaiza開発日誌は片山がお送りします。 SIerについて語られる際にIT業界の「多重下請け構造」についての問題点が良く取り上げられますが、「多重下請け構造」がITエンジニアにとってどのような問題点があるのでしょうか？ その点について今回は少し整理してみようと思います。 ■「多重下請け構造」とは何か 説明するまでもないかもしれませんが、「多重下請け構造」とは、受託システム開発において、発注者から直接仕事を請け負った元請（たいていの場合が大手SIer）が、請けた仕事を切り出して2次請け、3次請け、4次請けと仕事を下ろしていくピラミッド構造の事を言います。 良くある例で言うと、元請は要件定義や概要設計等の上流工程を請負い、開発・実装などの下流工程は2次請けに委託する、というような構造です。2次請けは自社リソースで開発を賄えない場合に3
技術者はアーティストであり、製造業者ではない
世間一般的に言われている「生産性向上のポイント」などをうのみにしてもイノベーションなど起こせるわけがない。自社の提供価値の本質を見極める姿勢が大切だ。 「ものづくりにこだわる限り、イノベーションは生まれない。特に情報産業の中心はソフトウェアであり、それは同じ製品を大量生産するものづくりではなく、一つの作品をつくるアートだから、要求されるスキルが製造業とはまったく違う」―― 本書「イノベーションとは何か」は、タイトル通り、生産性を向上させる上で不可欠とされてきた“イノベーション”の本質を追究した作品である。イノベーションをテーマにした書籍は多数提供されているが、本書の場合、単なる成功事例の紹介ではなく、あらゆる成功事例、失敗事例を分析し、「イノベーションが起こることの必要条件」の抽出を試みている点が特徴だ。 冒頭は、そうして抽出した複数の仮説の中の1つなのだが、その考察において「ソフトウェア
ＳＩ企業が「モデルシステム」を公開しない理由 - 設計者の発言
誰もが参照できる「モデルシステム」がシステム開発業界には必要だ。そんな「知的社会資本」の整備は、この業界が長い間ないがしろにしてきた社会的使命である――私のこの主張に対して非現実的だと言われることがある。曰く、その種のノウハウは開発事業における競争力の源泉みたいなものだから、そんなものを積極的に公開しようとするお人好しな開発企業なんてあるはずがない、と。 モデルシステムは建築業界における「モデルハウス」に相当する。業種別の設計情報やその実装版としてライブラリ化されたもののことを言う。これを叩き台として個別案件が開始されるようになれば、システム開発のスタイルは一変する。なにしろ「作り始める前に完成している」のだから。 そういうリソースをシステム開発企業が積極的に公開するとは私も思っていない。しかしその理由として「システム開発業における競争力の源泉だから公開するはずがない」などと解説されると不
オフェンシブな開発〜「納品しない受託開発」にみるソフトウェア受託開発の未来 | Social Change!
定期的にSI業界が終わったという話が出ますが、本当にそうでしょうか。終わるべきは一括発注・請負のディフェンシブなビジネスモデルです。受託はなくなることはありません。ソフトウェアの開発を、他の業界のアナロジーで考えるのではなく、正面から取り組んだビジネスモデルについて語っています。 ディフェンシブな開発 今から5年前に、SI業界における多くの問題の原因がそのビジネスモデルにあるという「ディフェンシブな開発〜SIビジネスの致命的欠陥」という記事を書きました。SIにおけるビジネスモデルは、発注者とベンダーはあらかじめ決めた金額と要件の中で納品と検収を目指すため、利益を出すためには双方がリスクを取らずに「守り」に入る必要があります。その結果、顧客にとって価値を産むかどうかよりも決められた要件通りに作られることを重視することになってしまいます。人月という単位であらかじめ決めるとなれば、単価の安い下請
日本のSI業界でこそ、専門の技術者の必要性がもっと見直されるべきではないのか？ - 達人プログラマーを目指して
Twitterでフォローさせていただいている@chok12jaさんのつぶやき がきっかけで、外国人の視点から日本のSI業界の問題について分析した面白い英文の記事を見つけました。 How the Japanese IT Industry Destroys Talent | Japan -- Business People Technology | www.japaninc.com [ThinkIT] 第2回：なぜ日本のIT業界ではスーパーSEを育てられないのか (1/4)（New 日本語訳が見つかりました。） 2007年に書かれた記事なのでもう４年も前に書かれたものですが、日頃から私が感じてきた業界の問題点について鋭く批評を加えており、非常に共感する内容が書かれていました。本ブログの主な読者の方々にとっても興味深い内容だと思いますので、ここで簡単に内容について紹介させていただきたいと思います
受託開発に未来はない? - ひがやすを技術ブログ
私は1年以上、エンタープライズの世界(企業向けSIとか)から離れ、ずっとGoogle App Engineをやっています。今は、Google App Engine + Webkitベースのブラウザで動くHTML5を使ったグローバルな新サービスを提供しようとしていて、新規事業立ち上げのために日々奮闘しているので、エンタープライズな世界に戻ってくることは、基本無いでしょう。 私は、受託開発に未来はないと思っているので、自分でサービスを提供する側に回ろうとしているわけです。受託開発に未来はないといっても、文字通り未来はないという意味で、すぐになくなるわけではないし、生きてくために必要な部分も多々あると思います(うちの会社もSIerだし)が、今後は撤退すべきだろうという判断です。 受託開発になぜ未来がないかというと、世の中の動きがかなり速くなっているので、その中で素早くチャンスを捕まえたものが生き
元請SIerがTracのような環境を提供できない３つの理由 - なからなLife
セキュアに公開されたソース管理システムと課題管理システム、つまりhttps接続のcvs/subversionとtrac/redmineを用意してほしい。 （略） 全てのプロジェクトメンバは計画と設計情報に対するアクセス手段を確保すべきだ。 元請け企業が用意すべきもの - @katzchang.contexts 激しく同意。 ツールの種類はともあれ、この手の情報は、 1箇所に集中 版の管理 セキュアなアクセス 誰でも参照できる を実現することよって、関係するすべての人にとって、作業負荷の軽減に寄与するものですから、さっさとやりましょうよ。 導入、周知、初期学習コストだけじゃん。 導入コストなんて、環境構築手順を確立して、場合によっては自動構築スクリプト化すればさくっと終わる話。 導入ノウハウなんて、みなさんいろんなところで公開してくれているわけだし。 初期学習コストなんて、初めて触る人だけの
夢見るSIerと虚構 - GeekFactory
たまには実情を書いてみる。愚痴大会なので読み飛ばしてくだしあ。 SIer の経営方針としては、｢どんなカタチにせよ、生産性を高めるのである｣という方向に行くと思います。生産性を高める要因は２つしかなくて、｢開発プロセスの改善｣と｢ソフト生成の自動化｣です。要するにワンタッチでポンでシステムが出来ればすげぇじゃんっていう発想。でも、そもそも要件定義が終わると全部終わるので、どうにかして改善されたプロセスを最大限に働かせるアジャイル的プロセスへの移行は不可避だと思う。 http://d.hatena.ne.jp/gothedistance/20090723/1248331426 「開発プロセスの改善」はどこのSIerでも施策に挙げていると思いますが、成果を上げているところはあるのですかねぇ。要件定義と開発はまったく別の仕事だから、両者で改善方法はまったく異なるはず。まずは後者のウォーターフォー
プログラミングを単純労働と捉える3つの理由 - GeekFactory
int128殿の会社では、 >プログラミングは誰でもできる、頭を使わない作業 と思う方が多くいるのかしら？ http://d.hatena.ne.jp/int128/20080414/1208181589 うちに限らず、多くの大企業SIerではプログラミングを単純労働と捉えています。その理由は3つあります。 （1）プログラミングは業務をプログラムに落とし込む単純労働 SIの開発手法（の考え方）は30年前から進化していません。業務をプログラムに落とし込む作業は誰がどうやっても同じようになるという思想に基づいています。現在のように高品質なフレームワークやライブラリが溢れる時代では、いかにそれらを組み合わせて作るかが効率化の鍵になります。組織のトップが進化した設計思想を理解しようとしないのは問題です。 30年前の設計思想であれば、プログラミングは業務をプログラムに落とし込む単純労働です。 （2）
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
