イケてる環境の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人材が必要だ。 (中略) そして地方自治体や外郭団体に至っては、その多くがいまだに丸投げ＆
恐怖のPM募集要項にダメ出しする - プロマネブログ
国内銀行勘定系システム再構築プロジェクト全体PM募集 PM/PMOの案件ご紹介 | 【BIG DATA NAVI-ビッグデータナビ】 | ネタだと思いたいんですけどねえ。一応求人として問い合わせ先もあるってことはマジなのだろうか。 ただのネタと信じたいのだけど。。。 必要スキルの日本語が怪しく、実際のとこのニーズがよくわからないのですが、グッと意訳して「大手ベンダに過去所属し、多数のパートナーベンダの関わる高難易度プロジェクト(1万MM以上くらい？)の案件で火消しPMとしての遂行経験がある人、ユーザ企業側PMとして募集」ぐらいの意味かなあ。 それなりにマッチングしているけど、関わりたくない。。。 まあ、とりあえずダメ出ししておきます。 ダメな点１ ： 業務内容があいまい クライアント側PMは良いとして、どのくらいの権限がもらえるのだろうか？火消しを行うのであれば、極端な話要件の切り捨て、次
バグとプロスペクト理論 - プロマネブログ
直接は関係ないんですけど、これ読んで思い出したので。 バグとプロスペクト理論 長期的に利用されるシステムやソフトウェアって、殆どの場合何らかの改修開発が行われるわけですよね。 で、修正するとバグも発生することがあるわけですが、改修開発の場合「新機能バグ」と「デグレバグ」がおきます。 新機能バグは、改修で新たに追加しようとした機能で発生したバグ。要は、追加機能が目標の機能を達成していない場合のバグ。 デグレバグは、改修してない既存の機能で発生したバグ。まあ、変更してない部分で思わぬトラブルを引き起こしたパターン。 バグはいずれにせよ顧客満足度を下げるものですけど、どちらのほうがユーザの不満を高めるかというとデグレバグの方が高めると思ってます。 プロスペクト理論 - Wikipedia 理由は上記の図の様なプロスペクト理論がバグにも適応されるから。 プロスペクト理論は「損失回避バイアス」。 同
2014年年初の業界動向予想の振り返り - プロマネブログ
自分の予想に対しての振り返りを行ってみようかと。 消費税増税の影響は想像より大きかった 大手SIerではデスマの災禍に見舞われる 中小SIerでは大手の競争激化に巻き込まれデスマが拡大する 2013年からの傾向から、2014年は死ぬほど忙しいんじゃないかと予想していたのですが、実際のところ「そこそこ」忙しいって感じで幕を閉じそうです。 原因は、消費税増税かな。 想定より景気への影響が悪いと感じたB2Cのユーザ企業は、今後の景気の行き先で不安を感じたため投資意欲が一気にブレーキが掛かった。その煽りを受けて、SIerに依頼される投資案件がぐっと絞られた感触があります。 なので、現在の開発パワーでは破綻するんじゃないの？と予想していた感も若干あったのですが、実際はトントンといった感じでデスマが多発するような事態とはならなかった感じですね。 ※とはいえ、ユーザ企業の種類によっては消費税に対する受け
システムは「人間」が使うということを甘く見るべからず - プロマネブログ
極言暴論スペシャル！ - SI亡国論（その2）- 日本企業のイノベーションを20年遅れにした罪：ITpro 前回*1に引き続き。 「日経」記者のSIerビジネス知識の欠如 ITProはいちおう日経系列なので、そこで働く記者も一般レベルのビジネス知識を持っているかと思いたいのですが。。。 例えばERP導入。本来なら可能な限りノンカスタマイズで導入したほうがユーザー企業の経営に資するのだが、IT部門は事業部門の個別要求に抗せず、アドオンの量を膨らませてしまう。そしてITベンダーにとっては、そのほうが開発量が増えて儲かる。しかも、その後の保守も膨大なものになり、それを請け負うことでさらに儲けることができた。 スクラッチで開発したシステムなら、なおのことだ。 上記文章。これを日経記者が書いちゃうのか。。。これでよくITビジネスを語れるなあ。 うちもそうだけど、大体のSIer、特に元請やっているよう
IT関連メディア亡国論 - プロマネブログ
極言暴論スペシャル！ - SI亡国論（その4）- 日本の成長に向けITベンダーの9割は要らない：ITpro 過去２回に渡り、SI亡国論と言いつつ、適切な問題設定を行っておらず論理展開に問題があることを指摘しました。 世界の中での日本のITサービスの評価 - プロマネブログ システムは「人間」が使うということを甘く見るべからず - プロマネブログ 元の記事は４回に分かれてますが、そろそろ書くのも飽きてきたので最後の指摘を書いておこうかと。 今回の記事は過去分の記事とほとんど重複しているので、４回目だけに記載されている内容についてだけ突っ込んでおきます。 ※正直、重複だらけの文章なので４回に分けたのって意味があるのかと思うぐらい水増しした文章なのですが。。。いいのか。 「マーケティングができないITベンダ」という言葉に見るビジネスの理解度 「後追い」から「御用聞き」への転換 ・・・ マーケティ
日本でオフショア開発が普及するとプログラマの給料が上がる仮説 - プロマネブログ
ここ数日「アメリカのプログラマの給料が高い！」という話題が飛び交ってますね。 まあ、給与の話はだれでも気になりますよね。私も気になります。 日本でオフショア開発が普及するとプログラマの給料が上がる仮説 もしかしたら、アメリカのプログラマの給料が高い理由って以前書いた記事に大きく関係するんじゃないかなと思ったので、ちょいとイメージを整理してみようかと。 アメリカの20年前に起きたオフショア活用の拡大と同様の事態が、日本人プログラマ*1の人とお金の動きに与える影響イメージを図示してみます。 かなり適当な絵ですけど。。。 ざっくりと説明すると 国内のプログラマの仕事のうち、日本人プログラマでは採算の合わない仕事がオフショアへ移管。逆に、日本人が必要となる高スキルな仕事でのプログラマが残る。 一部の高収入なプログラマを除き、多数のプログラマは仕事を失う。一部の資金はオフショアの外注費となるが、オフ
銀行決済24時間化が2018年となる理由をちょっとだけ推測 - プロマネブログ
銀行振り込み｢1時間だけ｣延長…ご冗談を！ | 夏野剛のググっても絶対出ないハナシ | 東洋経済オンライン | 新世代リーダーのためのビジネスサイト 銀行は専門じゃあないので、内容は不確かなところもありますがご了承を。 2018年まで改修が必要となる理由は政治じゃないかな この夏野氏。2018年まで銀行24時間決済が実現しないのを憤っているご様子ですが、正直銀行のせいじゃあないと思うんだけどなあ。 今、銀行系のシステムでは「金融一体課税(2016年1月完了)」「みずほ銀行のシステム更改(2016年後半頃完了)」「マイナンバー制度(2016年～2017年順次完了)」って形で、かなりの規模のシステム改修が動いている形となります。 上記を見ての通り、既に2017年までシステム改修スケジュールが埋まっている状態なんですよね。 しかも、政府主導の制度案件がかなり多く占めてます。 このような状況で、例
paizaには認識されてないSIerで身につけられる技術 - プロマネブログ
SI⇒Web転向に失敗するエンジニアに共通した【たった１つの特徴】 - paiza開発日誌 SIerがぬるま湯なのか。。。SIerって平均的にはわりかし給料が高いけど、高給ぬるま湯ならホワイト企業ってことで、SIerへ転向進めたほうがいいんじゃないのかな。 2014/11/12 00:41 個別の転職話は正直興味ない話なのでここではおいておくとして。。。 毎度のごとく、SIer disへの誤りを指摘しておきますか。 転向者の割合を求められる水準の高さと勘違いしてはダメでしょ しかしWeb系企業の中途採用におけるSIerから転向者は22.8%であり、決して広き門とは言えない状況です。 ふむふむ。主張としては、WEB業界へ転向する人のうち、22.8％しかいないため、WEB系企業で求められる人材の水準が高い、と言いたいようですが。。。 でも、その直前にはこんなこと記載しているんですよね。。。 逆
プロジェクトマネジメントで大切な一つのこと - プロマネブログ
ほうほうと思って内容見ていたのですが。。。ちょっとだけ。 プロジェクトマネジメントで大切な一つのこと まあ、プロジェクトマネジメント語る上で、スケジュール管理や課題管理など、色々管理しなければならないことがあります。 PMBOKでは、以下の様なことを管理しろとあります。 総合管理 スコープ管理 タイム管理 コスト管理 品質管理 人的資源管理 コミュニケーション管理 リスク管理 調達管理 ステークホルダ管理 教科書的には上記のような管理が大切なのできちんと行いましょう、というのが答えになるんでしょうけど、それだけだとつまらないので。。。 オッサンが考える、プロジェクトマネジメントで一番大切なことは何か、と聞かれればぶっちゃけ「計画」かな、と答えます。 要は、不確定要素がなくやるべきこと明確で、ステークホルダーの誰もが文句を言わないような状態に持ってきて。で、スケジュールも余裕。予算もきちんと
指摘密度だけでレビュー品質をチェックするPMOは仕事をサボっているも同然 - プロマネブログ
ひと通り笑ったので。。。 用語統一厨は結構重要な指摘 用語統一厨 「"お問い合わせ"は"お問合せ"と表記することに決まってるので」 元増田ではクソレビューアに「用語統一厨 」が挙げられているわけですが、結構この指摘って重要なんですよね。 というのも、オフショアとの開発やっていると、用語一つ一つが認識相違の致命傷となることがよくあるから。 オフショア側の人間ってやっぱり日本語に慣れてないこともあるので、用語がバラバラの設計書を渡したりすると、日本人からすれば同じ意味と把握できるような単語でも、別の読みや言葉として認識したりする場合もあったり。 オフショア開発で痛い目にあった、という人の話を聞くと、用語の統一や表記の統一みたいな、日本人からすると些細な部分できちんとコミュニケーションをとれてない場合があります。 でも、これってドキュメントを上手く解釈してくれるよう読み手に甘えている部分でもある
40歳年収が高い会社ランキング（IT関連業界抽出版） - プロマネブログ
最新版！「40歳年収が高い会社｣トップ300 | ランキング | 東洋経済オンライン | 新世代リーダーのためのビジネスサイト 持株会社が含まれてたり、従業員数が入ってなかったりするのでイマイチぴんとこなかったので、IT業界を中心に抽出してみました。 分析に入る前に 抽出条件としては以下のとおりです。 東洋経済オンラインに掲載された1～300位の企業 情報通信業、及びサービス業でWEBサービスを中心に行っている企業 持株会社は除く(やっぱり知りたいのは一般従業員の給与ですし) 情報通信業でも、メディア、広告代理店は除く(非IT業界) 個人的な趣味でキャリアは除く 非情報通信業でのシステムインテグレータやっている会社で知っている会社は入れておく とまあ、個人の趣味バリバリのランキングですね。 40歳年収を中心にしたランキングということで、平均年齢が著しく乖離している平均年齢の若い企業は、平均
プロマネの価値を発揮できる場所 - プロマネブログ
存在しているだけで役に立つもの : タイム・コンサルタントの日誌から 最近、PMBOKの再勉強していたらすっかりブログの更新を怠ってました。 ちょっと前に読んだ記事ですけど、自分なりの考えを書きたいなって思ってたんですよね。 元記事はプラントの話でソフトウェア開発とは若干違うのですが、感じるところがあったのでちょっとだけ。 プロジェクトは順調で在り続けられるのか 最初から最後まで順調な仕事では、プロジェクト・マネジメントなんて、ほとんど何もすることがないはずなのだ コレは全く疑うことがないことで、順調な局面はプロマネのすることなど何もないです。言い方を変えれば、順調な局面に抑えることができなければプロマネの忙しさはうなぎのぼりであり、ときとして過労死寸前の生活が当たり前という過酷な状況となることもしばしばです。 システム開発の現場では、何もしなくても最初から最後まで順調で在り続けられるとい
「価値創造契約」は対価の設定が問題では無いだろうか - プロマネブログ
俺の価値創造契約 from Fumihiko Kinoshita 俺の価値創造契約 以前、「納品のない受託開発」って厳しいのではみたいな記事*1を書いた都合上、上記スライドについてもコメントしておきたいな、と思います。 永和さんは新しい契約を掲げたものの、顧客獲得につながらなかったとあります。その敗因についてです。 最大のミス ユーザ企業の望む「所有から利用」の意味の取り違い 最近のシステム業界、日本も欧米でも、ITOやBPOといったシステムアウトソーシングが活況だったりして所有から利用がトレンドなのは正しいです。 ただし、ユーザが求めているのって別にシステムを所有しないことではないんですよね。 よく言われることとして、 費用明細の明確化 無駄払いの無い必要に応じた従量課金 → 固定費の削減 と言った感じで、要はコストが明確となり、無駄なコストを払ってないことがクリアになることが重要なんで
米国IT業界に過去あった多重下請構造、それが破壊された理由 - プロマネブログ
日本のIT業界を「SIガラパゴス」と言う前に知っておきたい海外ベンダ事情 - プロマネブログ 前回の記事を書いたあと、うっかりしていたことに気づいたので、追記です。 ユーザ企業とベンダ企業との関係については、他国との比較を色々書いたのですが、多重構造について深堀り書くのを忘れてました。 米国の事情についてもうちょい書きます。 下請構造が崩壊したアメリカ 端的にいうと、米国にも日本と同様の下請構造は過去ありました。 日本と同様に、元請けが大規模な案件を受注し、それを２次３次請けにシステム開発再委託するという構造です。 政府調達元請けの平均60.4％が下請け及び補給品に再投資され、それらのさらに平均83.2％が3次へ再投資、さらにその83.2％が再々投資、と繰り返される事により、初期調達額$369M（元請けのみ）は、上記再投資の構造より算出される係数2.06を乗ずる事により、$759Mと推計さ
excel業務管理ツールの使いどころ - プロマネブログ
エクセルをデータベースとして使うには、こうすればいいと思うのだけど、なぜ誰もやらないのかな？ - Excel 職人のつぶやき いや～、面白かったです。 excelで業務ツール作る例は結構ありますけど、ここまで徹底しているのは昨今見かけなかったので興味深く見てましたね。さすがのexcel職人さんですね。 業務規模とexcelツール 昔似たような記事*1でも触れてましたが、excelって本格的な業務システムを導入するまでの簡易な業務ツールとして利用すること結構あるんですよね。 個人的な経験ですけど、ある程度の規模まではexcelツールで業務がまかなえる反面、ある程度の規模となるとexcelの業務ツールではおっつかなくなり、本格的な基幹システムが必要になる事例をよく見かけます。 大まかには excelツール ： 1～数名程度の人がデータを管理し、他の人は参照する業務 スタンドアロンの部門基幹シス
LOC生産性でチームの開発能力を評価してほしくない - プロマネブログ
最初に、すいません。ただのグチです。 まあ、仕事をしていると嫌なこともあるわけで、腹の中でモヤモヤしているのも健康上良くないので、ここで整理してみようかと。 チームの開発生産性の比較にLOC生産性を使うな 結論はこれなんですけど、もうちょっとだけ。 保守開発なんてやっていると、他システム起因のプロジェクトにチームとして案件支援を行うことがあるのですが、それらを統括するPMO部隊の発言で、ひっくり返りそうになるのがコレ。 「今回は各チームとも生産性を○○KLOC/MM以上にして欲しい」 「オタクのチームは、見積生産性が☓☓KLOC/MMで生産性が悪いんじゃないか」 この手の発言聞くとやる気激減なわけですけど、仕事なので仕方が無い。。。 所謂クソコードが多いプロジェクトの方が生産性がよく見える そもそも、チームの開発生産性を比較するのに、LOC生産性を使うのは問題がおおすぎるのですよ。 保守開
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
