神国日本に特需の神風、暗雲も「技術の雲」も一掃か
『神国日本に特需の神風、暗雲も「技術の雲」も一掃か』という題名を見て「別のサイトの記事が間違ってITproに載ったのではないか」と心配した読者がおられるかもしれない。本文冒頭ではあるが、題名について補足する。 「特需」とは、既存の基幹情報システムの見直しによってSE（システムズエンジニア）が足りなくなっている状況を指す。「技術の雲」とはクラウドコンピューティングである。 諸事情で取材をしない状態が続いていたが、事情が少し変わり5月に入って久しぶりに取材らしきことができた。以前から抱えていた宿題をようやく進めて「できました」とか、「1年半前に相談した案件を進めてよいでしょうか」と報告に行ったためで正式な取材ではない。 それでも旧知のIT企業経営者や業界通にお目にかかると、本題の前後に雑談をすることになる。久しぶりに人と話ができて実に楽しかったと書きたいが、数人と続けて雑談するうちに何とも複雑
971人の回答から見えたIT業界の悲しい組織風土の現実、半数が「同僚のことをよく知らない」
ある程度は予想された結果とはいえ、これほど深刻な状況だったとは──。そう言わざるを得ない衝撃的な回答の数々だった。 日経情報ストラテジーとITproが2013年2月に共同で実施した、IT業界における組織風土改革についてのアンケートの集計結果である。 このアンケートは、ITproのウェブサイトと、日経情報ストラテジーが2月22日に都内で開催した有料セミナー会場の両方で実施した。内容は同じものである（実施したアンケートのページはこちら：助けて！組織風土改革にすがるIT業界、既にアンケートは終了）。 6つの質問と自由意見に対し、合計で971件もの回答をいただいた。まずはこの場でご協力いただけたことに、お礼を言いたい。本当にありがとうございました。 回答はITproで883件、セミナー会場で88件の有効数が集まった。ITproでのアンケート期間は2月5日から同19日までである。 対象はITproの
アジャイルの取り組みが大きく遅れている
アジャイル開発が盛んな米国に対して、日本では依然としてウォーターフォールモデルによる開発が大半だといわれている。実際に、日本はアジャイルの取り組みが米国のほか英国、ブラジルなどと比べても遅れを取っていることが調査結果からも明らかになった。 情報処理推進機構（IPA）が2012年6月に公開した「非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査」によると、米国や英国では非ウォーターフォール型開発の普及度が高く、逆に日本や中国では低い（図1）。ここで、非ウォーターフォール型開発とはアジャイル開発など、短いサイクルで反復的に開発を進める手法のことである。 アジャイル開発の普及が進まないと、激しさを増す市場や社会環境の変化に日本のITが対応しにくくなる恐れがある。IPAの柏木雅之氏（技術本部 ソフトウェア・エンジニアリング・センター エンタプライズ系プロジェクト 研究員）は、「アジャ
業務系SEの末路的なお話でして - 急がば回れ、選ぶなら近道
某DevLoveというところで話をしろ、ということでありましたので、いろいろ話をして来ました。 http://devlove.doorkeeper.jp/events/1733 まとめはこちら http://togetter.com/li/387189 あと、しんやさんの詳細なブログがこちら http://d.hatena.ne.jp/absj31/20121009/1349795347 スライドはこちら http://www.slideshare.net/okachimachi/devlove1 以下、ちょっと自分なりにまとめを。 ■自分なりにどう話したか 自分の仕事的にはHadoopとAsakusaでの課題解決が現在の本業です。ただ、Asakusaの位置づけとして、SIのための道具立てという側面が強く、また結果として会社も直接・間接にSIにはかかわっているので、割と現状の問題も意識して
業務プログラマーはこの先生きのこれるのか - novtan別館
SIerはなくなると言われて久しいです。僕もそれは間も無くやってくる現実だと思います。少なくとも、従来型のSIという仕事自体はなくならないけど、そのやり方は大きく変わると思っています。いくらクラウドだSaaSだなんだといっても業務要件を自動で書いてくれるわけではなく、何が正しいかの判断もしてくれません。今までにもまして、何を組み合わせてどう作るかを考える必要がでてくるし(従来であればスクラッチで作ります！ってのが出来たものもそんな金かけるなんてアホかと言われる世界です)、そうなるとエンジニアは広範な知識と経験を持って勝負しなければなりませんね。 しかし、いわゆる上流の工程が今にもまして重要になる反面では、下流の仕事が減っています。コアロジックさえ設計書に書いておけば、それ以外は自動生成されてテストしするだけだしテストも自動化されてるよ〜なんてことになるといわゆる大量な作業をもくもくとこなす
『SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道-』に参加してきた #devlove - Diary of absj31
SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道- - DevLOVE 2012/10/09 SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道 - DevLOVE #devlove - Togetter 講師及びその講師の方が話されるテーマも相俟って、募集後即定員が埋まる盛況振り。自分もタイミングを逸しキャンセル待ちで登録していたのですが、晴れてキャンセル待ち繰り上がりで参加資格を得る事が出来たのでこの日参加して来ました。 会場はマイクロソフト品川本社セミナールーム。今回はいつにもまして参加者も著名な方が多数参加。注目度の高さがここでも伺えます。 papandaさんの今回のイベント開催に至る経緯として以下の様なコメントが最初にあり、間髪入れずに本編へGOです。 ブログを読んでいて、書かれている事が仕事に対して危機感を持つ内容だった。 こういった内容を書かれる方のお話を聞いてみたい。
ソフトを他人に作らせる日本、自分で作る米国：日経ビジネスオンライン
物事に大きな影響を与える前提なのに案外知られていない。その一つがコンピュータソフトウエア投資とソフト開発技術者の所属先に関する日米の差である。 日本企業は自社で利用するソフトのほとんどをIT（情報技術）企業に開発させているのに対し、米国企業はソフトを内製する比率が高い。 日本のソフト開発技術者の大半はIT企業に所属するが、米国のソフト開発技術者の大半はIT企業ではなく一般企業に所属している。 上記二つの文は同じことを言っている。日本企業は社内にソフト開発技術者をあまり抱えていないためIT企業に外注するが、米国企業は社内にソフト開発技術者がおり内製できる。 「ほとんど」「高い」「大半」では曖昧なので数字を補足する。米国商務省経済分析局の数字によると、2010年の米国民間企業におけるソフトウエア投資の内訳は、内製（自社開発）が37.3％、外注（他社委託）が34.2％、パッケージソフト購入が28
そろそろ潮時? - Kazzz's diary
何時からだろうか、職業プログラマとして生業を全うしたいと思いながら仕事をしていたのだが、今の職場ではもうそれを許してはくれなさそうだ。 許してくれないというよりは正確には「認めて貰えない」と言った方が良いだろうか。 仕事で経験を積む、企業で歳を重ねる、そうすると自分の相対的な原価って奴が上がる。 この原価ってのがやっかいで、自分が企業の中でどれだけをコストを発生させているかを見る物差しとなるのだ。コストは簡単に言えば人件費、つまり給料だ。※ 以降、この原価という物差しが自分の仕事全てについて回るようになった。 あなたがプログラムを書くのではコストに合わない。もっとコストに見合った仕事をしないと評価できないと言われるようになる。 頑張って経験を重ねて良い仕事が出来るようになったのに、あんたに仕事させると会社が損をするということなのだ。 この時世だ。別に高い給料をくれとは言わない。普通に暮らせ
IT業界の「人月」暴落の原因ってなに？：「走れ！プロジェクトマネージャー！」：オルタナティブ・ブログ
愛機MacBook AirのUSBの調子が少しばかり悪いので、アップルストア銀座に業務以外で行けるという嬉しい金曜日を迎えた大木です。（あ、これも業務と言えば業務？） 最近なんとなく聴いているポッドキャストが減ってきた気がしたので、iTunesで新しいポッドキャストを探していたら「りんごは踊る、されど並ばず」というポッドキャストが！登場されている方々は、なんとトマト屋さんとか、よーよーさんとか、僕が聴いているポッドキャスターの皆さんが登場しておられます。じゃあ聴いてみるかと気楽にダウンロード。最初から一気にダウンロードして、移動時などに順番に聴いていました。その第6回（緊急企画）で知ったのが、スラッシュドット・ジャパンの「ITエンジニア派遣の「人月0円セール」が行われている？」という記事でした。 内容を読んでみると、正直言ってさほど新しい話ではありません。「新入社員を教育もしないでお客様先
SI屋さんとSIと、直近の課題について。 - 急がば回れ、選ぶなら近道
某セッションでちょっとしゃべったことをつらつらと。SIの現状と近い将来について思うところをまとめておきます。自分自身の立ち位置も確認していくという意味で。 結論的にいうと、SI自体は必要とされていますが、SI屋さんのビジネスモデルは成立しないという状況になるので、旧来の「SI屋さんの方法」ではうまくいきません。なので、別のやり方でSIをどうやっていくか？という議論が必要になりますね、という話です。 まずSI事業は人月稼働で商売をしています。スタート地点はそうではなかったのですが、一旦大きな人数を抱えると、食わせる必要があるため、より大きな仕事を取る羽目になります。要は稼働させる事、それ自体が目的になります。稼働を維持させる事で、収入を確保する事ができ、確保された収入で稼働のための人員を維持できる。そもそもそういう循環をベースに組織の目的が、「結果として」形成されてしまっています。 副作用と
さようなら、ダメなシステム屋
毎週月曜日、『ダメな“システム屋”で終わりますか？』の新着記事を楽しみにしていた読者はとても多かったのではないか。2010年9月から始まったこの連載には、ITpro史上最大級のアクセスが集まった。「そうだ！その通りだ！」というたくさんの共感の声が上がった一方で、「まずい、それは自分のことではないか…」と身震いする読者も少なくなかっただろう。 そんな大人気連載が、惜しまれながらも昨年末で完結した。今回の週末スペシャルでは、全66回の中から特にインパクトのあったアクセスベスト20の記事を紹介する。「読み逃した記事があった」「感銘を受けたあの記事をもう1度読んでみたい」といった方々は、この機会にぜひ読み直してみてほしい。 第1位～第10位 優秀な人が非常時にダメになる理由 報・連・相を振りかざすダメ上司 頭を使うことを知らない「横展開おじさん」 そんなものは「挑戦」と呼べない 優秀な部下ほど損を
技術者はアーティストであり、製造業者ではない
世間一般的に言われている「生産性向上のポイント」などをうのみにしてもイノベーションなど起こせるわけがない。自社の提供価値の本質を見極める姿勢が大切だ。 「ものづくりにこだわる限り、イノベーションは生まれない。特に情報産業の中心はソフトウェアであり、それは同じ製品を大量生産するものづくりではなく、一つの作品をつくるアートだから、要求されるスキルが製造業とはまったく違う」―― 本書「イノベーションとは何か」は、タイトル通り、生産性を向上させる上で不可欠とされてきた“イノベーション”の本質を追究した作品である。イノベーションをテーマにした書籍は多数提供されているが、本書の場合、単なる成功事例の紹介ではなく、あらゆる成功事例、失敗事例を分析し、「イノベーションが起こることの必要条件」の抽出を試みている点が特徴だ。 冒頭は、そうして抽出した複数の仮説の中の1つなのだが、その考察において「ソフトウェア
ＳＩ企業が「モデルシステム」を公開しない理由 - 設計者の発言
誰もが参照できる「モデルシステム」がシステム開発業界には必要だ。そんな「知的社会資本」の整備は、この業界が長い間ないがしろにしてきた社会的使命である――私のこの主張に対して非現実的だと言われることがある。曰く、その種のノウハウは開発事業における競争力の源泉みたいなものだから、そんなものを積極的に公開しようとするお人好しな開発企業なんてあるはずがない、と。 モデルシステムは建築業界における「モデルハウス」に相当する。業種別の設計情報やその実装版としてライブラリ化されたもののことを言う。これを叩き台として個別案件が開始されるようになれば、システム開発のスタイルは一変する。なにしろ「作り始める前に完成している」のだから。 そういうリソースをシステム開発企業が積極的に公開するとは私も思っていない。しかしその理由として「システム開発業における競争力の源泉だから公開するはずがない」などと解説されると不
IT産業には民族誌が必要だ 2011-11-08 - 未来のいつか/hyoshiokの日記
先日からContinuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automationの読書会をしているというのは、日記にも書いた。*1 本日は第3章Continuous Integration（継続的インテグレーション）だ。早瀬さんが2号館のカフェテリアでやろうというので、近所のコンビニでビールとつまみを買いこんで参加した。（うひひ） コンビニ袋にビールとポップコーンを突っ込んでカフェテリアに登場したところ、目ざとくビールを発見され、「おっビール」と言われるのだが、「えっビールじゃないんですか」と返す。早瀬さんもわたしのビールにつられてドリンクとつまみをコンビニに買出しに行った。 そんなこんなで、飲みながら第3章は始まったのであるが、その前にわたしのヨタ話を披露した。 Conti
日中で「元請け・下請け」の関係が逆転する日 中国企業が日本のシステム開発会社に触手 | JBpress (ジェイビープレス)
先日、当社の取引先の営業担当者から1本の電話があった。内容は、「中国の大手システム開発会社が、日本のシステム開発会社（なるべく独立系）を買いたがっている。複数社まとめて買収してもかまわない。ただし、技術者が必ず残るようにしてほしい」と言うのである。当社も含めて検討してもらえないか、という話だった。 何と失礼なことかと思う反面、停滞化している日本のシステム開発業界には一筋の光のようにも思えた。 念のため、私の属しているシステム開発関連の社長会に打診してみたところ、相当数の反応があった。予想以上の会社の社長が、「もっと詳しく話を聞きたい」と言ってきたのである。 どの社長も、日本でシステム開発会社を運営することの難しさをいやというほど知っている。今後の日本経済の復興を懸念して、中国企業による買収に興味を示したのだろうか。なんとも複雑な気持ちになった。 中国での開発案件で成功した日本企業は極めて少
IT業界における「技術力」の意味するものは、日進月歩の勢いで変化しているということを理解してほしい - 達人プログラマーを目指して
前回のエントリー日本の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年に書かれた記事なのでもう４年も前に書かれたものですが、日頃から私が感じてきた業界の問題点について鋭く批評を加えており、非常に共感する内容が書かれていました。本ブログの主な読者の方々にとっても興味深い内容だと思いますので、ここで簡単に内容について紹介させていただきたいと思います
SI業界からはさっさと抜けだしたほうがいい - ひがやすを技術ブログ
SI業界（日本）のJavaプログラマーにはオブジェクト指向より忍耐力が求められている？ - 達人プログラマーを目指して http://d.hatena.ne.jp/ryoasai/20110109/1294581985 をうけて自分の考えを書いておきます。 二年前なら、自分もどうしたらSI業界をよく出来るか真剣に考えていたし、NTTデータの人達と実際に話し合いもしています。 NTTデータとの真昼の対決シリーズ http://d.hatena.ne.jp/higayasuo/20080612/1213241779 http://d.hatena.ne.jp/higayasuo/20080828/1219901392 でも、ソーシャル、クラウド、スマフォの時代になって、考えが変わりました。 今は、世の中の動きがかなり速くなっているので、その中で素早くチャンスを捕まえたものだけが生き残ります。受
プログラマーの成長を考えないSIerの仮説は間違っている - 達人プログラマーを目指して
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指してのコメントで 熟練者も居ることは理解しているが、開発をする上で熟練者ばかりを集めることはできない。このため初心者側にレベルを合わせざるを得ない。 というコメントをいただきましたけれど、これは実に典型的なSIer（の上司）の考え方ですね。SIerの仮説と呼んでもよいくらいですね。とにかく、この仮説の前提となっているのは プログラマーのスキルレベルは一定で成長しない プログラマーは容易に交換可能なリソースである プログラマーは単純労働者である というモデルです。とにかく、この仮説がはびこっているから、いまだにSIerのフレームワークは「初心者側にレベルを合わせざるを得ない」という思い込みで作られていることが多いのでしょう。 COBOL（の初期の）時代ならまだしも、少なくとも現在の開発環境にお
日本のソフトウェアが世界で通用しないまとめ。 - このブログは証明できない。
WEB+DB PRESSで中島聡さんの記事を読んで気になったので、ゆるく調べてみました。日本のソフトウェアがダメなんじゃなくて、アメリカがひとり勝ちしてるだけじゃないのか。他の国はどうなのか。ということを気にしながら。無理やり1行でまとめてますが、すべて私の主観なので、筆者の主張と一致するとは限りません。あと、記事についたブコメもあわせて読むといいかもしれません。 まずは、WEB+DB PRESSに掲載されている中島聡さんの記事。 第3回 なぜ日本のソフトウェアが世界で通用しないのか：Software is Beautiful｜gihyo.jp … 技術評論社 日本のソフトウェア業界は、ITゼネコンビジネスモデルである。また、ソフトウェアエンジニアの境遇が悪すぎる。 やっぱり日本がダメという論調で、日本だけがダメなのか疑問です。 この記事を受けての意見。 日本のソフトウェアが世界で通用しな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
