イケてる環境のWEB系の労働生産性がイケてないSIerのたった三割しかない件 - プロマネブログ
久しぶりの更新。一度ブログ書くの面倒になると、とことん書くのが面倒になるもんで。 【Web系最高って言うけど本当なの？】SIから転職したエンジニア達に聞いてみた - paiza開発日誌 まあ、いつものPaizaのWebアゲSIer Disの記事なわけなんですが。。。 最近、どうでもよくなって放置していたものの、いろいろ誤認している人が増えていそうなので、改めて問題点指摘しておきますか。ブコメ見るとSIer側の反論も欲しそうだし。 とはいえ、開発環境の話はわきに置いて、別の観点を中心とした内容となります。 イケてる環境のWEB系の労働生産性は、イケてないSIerのたった三割 http://www.soumu.go.jp/johotsusintokei/linkdata/ict_keizai_h28.pdf 上記は総務省が毎年公開している「ICT の経済分析に関する調査 」の資料です。 大体1
バッチ処理のあれこれと、SLA - プロマネブログ
風邪引いてしばらくブログ更新サボってました。 上記記事について、気になったので。ブコメで言及ももらったし。 ウィキペディアのバッチの利点って若干記載が古い 多くのユーザーがコンピュータのリソースを共有できる。 処理をコンピュータのリソースがあまり忙しくない時間帯（多くは夜間、休日）にシフトできる。 人間がついていなくてもコンピュータのリソースが暇にならないように最大限有効活用できる。 高価なコンピュータをフルに活用することで費用対効果の効率向上に寄与する。 バッチ処理 - Wikipedia バッチをリソース目的だけで使うってずいぶん古い話だなあ、と思って編集履歴をたどってみたら、2006年の記載でしたか。 記載をたどってみると分かるんですけど、上記の内容って「メインフレーム」のバッチ処理に対する利点なんですよね。 そういった意味では、現在のバッチの設計とはちょっと概念が違うんじゃないかな
SIerのこと知ったかしている子たちへのツッコミ - プロマネブログ
前回、システム開発でベンダ任せをやめようとした日本、ベンダに任せた米国 - プロマネブログの記事でコメントを頂いたのを思い出したので。 id:sayurin7 paiza開発日誌 2015-01-26 【エンジニア対談】SIer・大手からスタートアップへの転職前に知っておきたい事 でSIerのこと知ったかしている子たちにも何かひとこと、ぜひ あ～、あまりにも酷かったのでブコメでツッコむ気も失せていた記事ですね。。。 まあ、せっかくコメントを頂いたことですし、確かに間違いを指摘するのも大切なことなので、カンタンに。 自分の知らないこと≠存在しないこと ITを後付けするんじゃなくて、ITをベースにして今までに無い事業やビジネスモデルを考えるべきだと思ってました。そういう事やるのって受託ビジネスでは無理だから、やっぱり自分はSIerじゃなくて自社サービスを開発する仕事がしたいと。 ATMも、電子
システム開発でベンダ任せをやめようとした日本、ベンダに任せた米国 - プロマネブログ
う～ん、まあ、相変わらずツッコミドコロがいっぱいあるのだけど、一番肝心なところだけ。 総務省の情報システム調達ガイドラインを読んでないよな もちろん、政府もこうしたことに深刻な問題意識を持っており、民間から政府CIOを起用し、そのスタッフも充実させるなど更なる改革に取り組んでいる。2015年4月からはシステム調達に関する新たなガイドラインも施行する。 (中略) だが、あくまでも「この通りに実施できれば」の話だ。ガイドラインでは、システムを導入する際には利用部門の業務改革を行うことを義務付けている。全く正しいが、この手の業務改革は民間企業で軒並み失敗しており、ハードルはさらに高くなる。業務やITに精通するだけではダメで、ベンダーマネジメントや、利用部門を統制する“ユーザー”マネジメントなどをこなせるIT人材が必要だ。 (中略) そして地方自治体や外郭団体に至っては、その多くがいまだに丸投げ＆
paizaには認識されてないSIerで身につけられる技術 - プロマネブログ
SI⇒Web転向に失敗するエンジニアに共通した【たった１つの特徴】 - paiza開発日誌 SIerがぬるま湯なのか。。。SIerって平均的にはわりかし給料が高いけど、高給ぬるま湯ならホワイト企業ってことで、SIerへ転向進めたほうがいいんじゃないのかな。 2014/11/12 00:41 個別の転職話は正直興味ない話なのでここではおいておくとして。。。 毎度のごとく、SIer disへの誤りを指摘しておきますか。 転向者の割合を求められる水準の高さと勘違いしてはダメでしょ しかしWeb系企業の中途採用におけるSIerから転向者は22.8%であり、決して広き門とは言えない状況です。 ふむふむ。主張としては、WEB業界へ転向する人のうち、22.8％しかいないため、WEB系企業で求められる人材の水準が高い、と言いたいようですが。。。 でも、その直前にはこんなこと記載しているんですよね。。。 逆
プロジェクトマネジメントで大切な一つのこと - プロマネブログ
ほうほうと思って内容見ていたのですが。。。ちょっとだけ。 プロジェクトマネジメントで大切な一つのこと まあ、プロジェクトマネジメント語る上で、スケジュール管理や課題管理など、色々管理しなければならないことがあります。 PMBOKでは、以下の様なことを管理しろとあります。 総合管理 スコープ管理 タイム管理 コスト管理 品質管理 人的資源管理 コミュニケーション管理 リスク管理 調達管理 ステークホルダ管理 教科書的には上記のような管理が大切なのできちんと行いましょう、というのが答えになるんでしょうけど、それだけだとつまらないので。。。 オッサンが考える、プロジェクトマネジメントで一番大切なことは何か、と聞かれればぶっちゃけ「計画」かな、と答えます。 要は、不確定要素がなくやるべきこと明確で、ステークホルダーの誰もが文句を言わないような状態に持ってきて。で、スケジュールも余裕。予算もきちんと
米国IT業界に過去あった多重下請構造、それが破壊された理由 - プロマネブログ
日本のIT業界を「SIガラパゴス」と言う前に知っておきたい海外ベンダ事情 - プロマネブログ 前回の記事を書いたあと、うっかりしていたことに気づいたので、追記です。 ユーザ企業とベンダ企業との関係については、他国との比較を色々書いたのですが、多重構造について深堀り書くのを忘れてました。 米国の事情についてもうちょい書きます。 下請構造が崩壊したアメリカ 端的にいうと、米国にも日本と同様の下請構造は過去ありました。 日本と同様に、元請けが大規模な案件を受注し、それを２次３次請けにシステム開発再委託するという構造です。 政府調達元請けの平均60.4％が下請け及び補給品に再投資され、それらのさらに平均83.2％が3次へ再投資、さらにその83.2％が再々投資、と繰り返される事により、初期調達額$369M（元請けのみ）は、上記再投資の構造より算出される係数2.06を乗ずる事により、$759Mと推計さ
「人月問題」や「多重請負」は「害悪の原因」ではなく結果 - プロマネブログ
記者の眼 - IT業界の人月商売、多重下請けがもたらす45の害毒：ITpro 上記の４５の弊害。どれも微妙に指摘できそうな内容ばかり。。。ちょっとばかり検証してみますか。 害毒として挙げられている事項について検証 ４５の害毒それぞれ微妙に突っ込みどころがあるので、個々解説を書こうと思ったら、半分ぐらい書いた段階で既に５０００文字を突破てしまいました。。。 もうやめやめ。こんな長文誰が読むんだい。 というわけで、代表例を幾つかピックアップして指摘。 因果関係が逆転 １．労働集約型産業のままで知識集約型産業に脱皮できない 逆逆。主力である「受託開発」が労働集約的な仕事だから、労働力に応じた収益となるため人月商売や多重下請が発生するんですよ。害悪、ではなく原因。 他にも、「６．いつまでも手工業、システム開発の工業化が進まない」も同じです。受託開発で、ユーザごとに業務要件、システム要件が違うがため
日本のIT業界を「SIガラパゴス」と言う前に知っておきたい海外ベンダ事情 - プロマネブログ
木村岳史の極言暴論！ - SIガラパゴス、多重下請け構造の終焉の始まり：ITpro クラウドだ、オフショアだ細かい端々の間違いを指摘してたら、自分の書いていた過去記事とほとんどおんなじ内容になってしまったので、たまには趣向を変えて見ようかなと。 ※元記事の問題提起がワンパターン過ぎて。。。 そもそも、日本のSIerってガラパゴスと呼ばれるほど特殊なのか、について。 世界のシステム開発ベンダ IPA 独立行政法人 情報処理推進機構：IT人材育成事業：IT人材白書 世界のベンダ事情を調査した素晴らしいレポートなので一読あれ。 非常に長い内容なので、かいつまんでまとめます。 米国 ウェブサービス企業などのイノベーティブなハイエンドサービスを提供するIT企業は内製化。それ以外の非IT業種で、金融機関、連邦政府などIT部門が強い業種では、マネジメントやIT戦略部門を内製化、開発はベンダ（IBMなど）
フルスタックエンジニアもオフショアに脅かされる未来 - プロマネブログ
35歳定年説より怖いフルスタックエンジニアしか生残れない未来とは - paiza開発日誌 昔々、SIerでもフルスタックという言葉では無かったのですが、「Ｔ型人材」「Π型人材」になれと言われてきた時代がありました。(今も言われているのかな) この言葉が今WEB業界から出てきたことに、感動を禁じえません。 ああ、SIerのオッサンが、昔訓示をうけた姿がここにある。。。 時折、SIerの昔話みたいな話がWEB業界の最新の話として出ることがあるんですが、歴史は繰り返すってことですね。。。 クラウドでインフラ領域に侵食するオフショア さて、話題のフルスタックエンジニアですが、正直日本国内で優位性を保てるのはあと5年じゃあないかな、なんて予想してます。 フルスタックエンジニアの複合スキルで触れられているシステムのインフラ構築ですが、基本は日本人エンジニアが担当することが多いです。 理由はいろいろあり
詳細設計書も問題だけど、それ以上に成果物定義が問題 - プロマネブログ
詳細設計書という名のゴミ | Gm7add9 この手の話題が定期的に上がるわけですけど、毎度同じだよねで終わってしまっては人間進歩しないので、何が問題でどうすればよいのか少し考えてみたく。 詳細設計書は「プログラム説明書」として欲しい。 まあ、元記事も多分業務システムの受託の話の模様なのでSIをターゲットに。 往々にしてSI、特にウォーターフォール開発のプロジェクトの中では、設計書などのドキュメントを多数作成いたします。*1 V字モデル的には、設計から開発に至るまでの間 要件定義書 基本設計書・外部設計書 基本設計書・内部設計書 詳細設計書 プログラム みたいな成果物を作成いたします。 個別の詳細は別のサイトに任せるとして、それぞれ記載する内容を一言で表すと、要件定義書は「スタートとゴール」、外部設計書は「業務とサービスの仕様」、内部設計書は「サービスの構造と機能の分割」となります。 ※た
IT技術者の2014年年収予想を世界主要国と比較してみた - プロマネブログ
給与調査｜外資系・日系グローバル企業への転職ならロバート・ウォルターズ 調べ物していたら面白い資料を見つけました。 この資料は、各国の給与予測調査を行った結果ということで、日本を含めた数カ国の2014年予想年収、2013年の実勢年収を調査したものということです。 この資料にIT技術者の給与についても書いてありました。 ちょっと興味があったので、日本と主要国のPM、SE、PGの給与比較をしてみます。 主要国給与比較結果 ※フランスなど国によってはSEという職種がない場合がありますので、その場合はシステムアーキテクトやビジネスアーキテクトなどで代用してます ※プログラマは言語によって給料に差がある場合があります。比較しやすかったJavaプログラマを使ってます。 ※各国ピンきりの幅が広かったのですが、分布がわからないためピンきりの中間を取ってます。上海は最大値が非常に高かったため、ちょっとイレギ
『細川義洋×山本一郎「なぜ、システム開発は必ずモメるのか？」 』の所感 - プロマネブログ
Developers Summit2014 リポート：ベンダーよ、シェルパの屍を越えていけ ～ 細川義洋×山本一郎「なぜ、システム開発は必ずモメるのか？」 (1/2) - ＠IT 2月14日は仕事が忙しく聞きに行けませんでしたが、サマリレポートだけでも非常に楽しめたので、所感を。 バンバン出てくる実社名。。。大体予想できる会社でしょうけど、聞きたかったなあ。 出てきた内容からの所感を幾つか。 プロマネの仕事はやっぱり政治だ。。。 細川氏は、トラブルを防ぐためには「根回し」が大切だという。ベンダーは、ユーザーが「ちゃんと決めてくれる」かどうか、そして「誰が本当のキモなのか」を見極める眼力が必要だ。キーマンを見付けて、その顔色を見て、泥臭い根回しを続けなければならない。「開発は、きれいな身体ではできないものです」 これも典型的なあるあるですね。 正直、ステークホルダーを如何に上手く調整するか、
コーディング技術にこだわり過ぎるとITエンジニアの地位は向上しない - プロマネブログ
日本のITエンジニアの地位はなぜ低いのか：日経ビジネスオンライン エンジニアの地位向上を図りたい、これは同意ですが、そのための解決策がコーディングスキルですか。。。 エンジニアの地位向上のためには、まず何が問題かをきちんと分析できなければ話になりません。ちょっと考えてみます。 追記) なぜかブコメ欄を見るといろいろコメントが発散してる。。。 下手な日本語で申し訳ないです。 本旨は「プラスアルファが必要って言ってるのに、paizaはコーディングの話だけなんだ～。プラスアルファどこいった」です。 ちなみにJavaの誤記は直しときました ブクマ炎上反省会はこちら 「コーディング技術にこだわり過ぎると～」の反省会 - プロマネブログ IT業界の価値提供の構造 いわゆるSIerをモデルに価値をどのように提供しているのか、考えてみます。 ※まあ、自分の仕事から考えるのが一番カンタンですし。 SIerを
曖昧なプロマネ権限と責任がプロジェクトを炎上に導く - プロマネブログ
炎上プロジェクトの責任はプロマネが９割 - プロマネブログ はてなブックマークのコメントを沢山いただきありがとうございます。ちょっと気になったコメントが有りましたので、考えてみたく。 カネと期限の権限のないプロマネ ＝ プロジェクト推進の専門家プロジェクトリーダ 気になったコメントというのは 与えられた時点で予算や期限が限界を超えていて炎上必至 最初から赤字プロジェクトだった みたいな感じです。 で、ちょっと考えたのですが、オッサンの話の中で呼んでるプロマネとは微妙に役割が違うんですよね。。。 これって炎上プロジェクトの責任はプロマネが９割 - プロマネブログにある通り、PMBOK管理観点のスコープ管理、タイム管理、コスト管理に該当する話で、PMBOK的にはプロマネの管理の範疇の内容です。 にも関わらず、プロマネがそれを制御できない、そういう声が多く現れているわけです。 実は、これら予算や
炎上プロジェクトの責任はプロマネが９割 - プロマネブログ
サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ 前回からの続きです。 以下、３部作の３本目となります。 ウォーターフォール開発とアジャイルの本質 - プロマネブログ サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ 炎上プロジェクトの責任はプロマネが９割 - プロマネブログ 追記)ブコメで誤字の指摘がありましたので、訂正します。。。お恥ずかしい NetPenguinさん、ご指摘ありがとうございます 改めて考えたいプロマネの仕事 プロマネの仕事とは、PMBOKのプロジェクト管理に関する観点をマネジメントする、と言えます。 統合 ・・・ チーム内の意思統一 スコープ ・・・ 目標、成果決定 タイム ・・・ 期限、スケジュール管理 コスト ・・・ 予算、費用管
2014年のSI業界の展望 - プロマネブログ
2014年もいよいよ始まりました。 新年、今年の仕事初めに向けて、SI業界の今後について考えていきたいと思います。 ※オッサンの独断と偏見が混じっているので注意 なお、IT業界ではなくSI業界に限定しているので、WEB業界等その他のIT関連業は除外してます 大手SIerではデスマの災禍に見舞われる 昨年に引き続き、今年も企業のシステム投資欲は高まると想定されてます。 これまでのかなりの期間企業投資が低下していたこともあり、昨年は特に大手のSIer各社の数社は今までジリ貧で減少してきた顧客を取り戻すべく、売上の拡大を行おうと積極的な受注を行ってきてました。 結果、案件数過剰による無理な受注とそれによる開発力低下、費用増大がタタリ、大手SIerでは利益率低下を招く結果になったと考えております。 ※大手SIerで、プロジェクトマネジメントがあまり得意でない会社は特に。 今年のシステム投資欲の需要
「必要なこと」より「excelでやりたいこと」を優先するとシステム構築は失敗する - プロマネブログ
<追記> 追加記事を書きましたhttp://getlife.hateblo.jp/entry/2013/12/07/034949 エクセルでできることができない何百万のシステム・・ 多分現場の人かな。往々にして、システム導入を決定したトップの目的が現場に伝わらず、既存ツールとの差だけが目につくってことはよくあるし。ま、一部業務をexcelで残すみたいに調整すればいいんじゃないかな。 オッサン、こういうシステムネタ好きです。昔高度情報技術者試験を受けた時を思い出すなあ。 大体、仕事やっているとこの手の「今やっている仕事と違う～」だとか、「役員はシステム導入ばっかり言って現場をわかってない」とかそんな揉め事ばかり。 まあ、そういう揉め事を丸め込む納得できるよう調整するのがオッサンの仕事なんですけどね。 本当にやりたいことを見つける システムの要件定義のキモは 必要なこと やりたいこと やらない
「Aしかない」とか極論を言う人の役立たなさ - プロマネブログ
「AともいえるがBともいえる」とか言う人の役立たなさ - Chikirinの日記 いろいろコメントをもらったのですが、はてブコメ欄みると文章がわかりづらいせいで読み違えているなってコメント幾つか見られたので、朱書きで補足追記してます。 普段から極論ばっかり行っているちきりん氏がついに自己弁護？ あまりにもしょうもなかったので、ツッコミをつい入れてしまいました。 さすが、議論の呼び水としての力健在ですな。 「Aだ」「Bだ」ためには問題設定の妥当性が必要 さて、この文章いろいろ突っ込みどころをはらんでますが、最大の問題としては問題設定の不具合を批判者に転嫁している点です。 往々にして議論を行う場合、「Yes」か「No」かの選択を行う場合が多いです。 ＜追記＞言い換えると「A」か「notA」か。 これは議論がスッキリしやすく、答えも出しやすいから。 ところが、「A」か「B」か、という選択の場合、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
