久しぶりの更新。一度ブログ書くの面倒になると、とことん書くのが面倒になるもんで。 【Web系最高って言うけど本当なの？】SIから転職したエンジニア達に聞いてみた - paiza開発日誌 まあ、いつものPaizaのWebアゲSIer Disの記事なわけなんですが。。。 最近、どうでもよくなって放置していたものの、いろいろ誤認している人が増えていそうなので、改めて問題点指摘しておきますか。ブコメ見るとSIer側の反論も欲しそうだし。 とはいえ、開発環境の話はわきに置いて、別の観点を中心とした内容となります。 イケてる環境のWEB系の労働生産性は、イケてないSIerのたった三割 http://www.soumu.go.jp/johotsusintokei/linkdata/ict_keizai_h28.pdf 上記は総務省が毎年公開している「ICT の経済分析に関する調査 」の資料です。 大体1

ここしばらく仕事にやる気が出ず、シロギス釣りばっかりやっていたら、ブログ更新もすっかり滞ってしまってました。 久しぶりの更新です。 いやー、家計簿アプリ業界、そのうち絶対にヒドい事件がおきると予想します - ツイナビ | ツイッター(Twitter)ガイド 個人で作っているサービスで仕方なくスクレイピングしているならともかく、法人として運営しているサービスなんだしきちんと金融機関に仁義通して金払って企業間連携用のapi利用すりゃいいのに。 2015/07/02 08:58 う～ん、家計簿アプリのチョンボなわけなんですけど、ブコメでは銀行側がミョーなとばっちりを受けておりますね。。。 なんていうか。。。微妙。 「金融機関側がAPIを用意」しても解決しない 金融機関がAPIを用意しないせいで家計簿アプリ側が「乱数表」情報を入力せざるを得ないって意見を結構な数見かけます。 でも、実際金融機関側で

ここ数日「アメリカのプログラマの給料が高い！」という話題が飛び交ってますね。 まあ、給与の話はだれでも気になりますよね。私も気になります。 日本でオフショア開発が普及するとプログラマの給料が上がる仮説 もしかしたら、アメリカのプログラマの給料が高い理由って以前書いた記事に大きく関係するんじゃないかなと思ったので、ちょいとイメージを整理してみようかと。 アメリカの20年前に起きたオフショア活用の拡大と同様の事態が、日本人プログラマ*1の人とお金の動きに与える影響イメージを図示してみます。 かなり適当な絵ですけど。。。 ざっくりと説明すると 国内のプログラマの仕事のうち、日本人プログラマでは採算の合わない仕事がオフショアへ移管。逆に、日本人が必要となる高スキルな仕事でのプログラマが残る。 一部の高収入なプログラマを除き、多数のプログラマは仕事を失う。一部の資金はオフショアの外注費となるが、オフ

日本のIT業界を「SIガラパゴス」と言う前に知っておきたい海外ベンダ事情 - プロマネブログ 前回の記事を書いたあと、うっかりしていたことに気づいたので、追記です。 ユーザ企業とベンダ企業との関係については、他国との比較を色々書いたのですが、多重構造について深堀り書くのを忘れてました。 米国の事情についてもうちょい書きます。 下請構造が崩壊したアメリカ 端的にいうと、米国にも日本と同様の下請構造は過去ありました。 日本と同様に、元請けが大規模な案件を受注し、それを２次３次請けにシステム開発再委託するという構造です。 政府調達元請けの平均60.4％が下請け及び補給品に再投資され、それらのさらに平均83.2％が3次へ再投資、さらにその83.2％が再々投資、と繰り返される事により、初期調達額$369M（元請けのみ）は、上記再投資の構造より算出される係数2.06を乗ずる事により、$759Mと推計さ

最初に、すいません。ただのグチです。 まあ、仕事をしていると嫌なこともあるわけで、腹の中でモヤモヤしているのも健康上良くないので、ここで整理してみようかと。 チームの開発生産性の比較にLOC生産性を使うな 結論はこれなんですけど、もうちょっとだけ。 保守開発なんてやっていると、他システム起因のプロジェクトにチームとして案件支援を行うことがあるのですが、それらを統括するPMO部隊の発言で、ひっくり返りそうになるのがコレ。 「今回は各チームとも生産性を○○KLOC/MM以上にして欲しい」 「オタクのチームは、見積生産性が☓☓KLOC/MMで生産性が悪いんじゃないか」 この手の発言聞くとやる気激減なわけですけど、仕事なので仕方が無い。。。 所謂クソコードが多いプロジェクトの方が生産性がよく見える そもそも、チームの開発生産性を比較するのに、LOC生産性を使うのは問題がおおすぎるのですよ。 保守開

ITエンジニアの価値を貶める『人月商売』の功罪 - paiza開発日誌 うん、まあ、浅い認識ですね。。。 最近、この手のツッコミばかり書いている気がするけど、まあ、他のネタ書こうとして面倒になったので、こちらについて言及。 世の中、WEBサービス以外にも沢山のシステムがあることを理解したほうが良い SIerの作るシステムが、常にエンドユーザーに対して「お金を払ってでも使いたい」というような高い価値を提供できるのだとしたら、自社サービスとして開発を行った方儲かる、という事になります。 この記載からすると、この方の頭には「BtoC」型のWEBサービスしか頭にないことがわかります。人月商売言っているSIerの仕事は、「BtoC」型だけとでも思ってるんでしょうか。。。 例えば、ATM。これ、SIerが作ってますし、エンドユーザはお金を払ってでも使いたいシステムですけど、自社サービスとして開発を行う

1ジョブ5万って普通なんですかね？ まあ、増田記事の内容見るに、動的コンテンツの改修なんだろうけど、正直なこと言うとランサーズの静的コンテンツ作成5000円と比較している段階で、おそらく元増田氏はシステムの構造や内容など把握してないと思われますね。。。 そんな元増田向けの、保守会社からの見積もり妥当性を見極める簡易的な方法を、ベンダ側のプロマネのオッサンより伝えられればと。 類推法を使おう 昔、見積もりに関する記事*1書きましたが、パラメトリック法やWBS法等の見積手法は、システムの構造を熟知し、大体の作業量を理解していないと妥当性のある見積もりを把握することは困難です。 ユーザ企業側の元増田では、ちょっと厳しいかなと。 このようなユーザ企業側の元増田が見積もり妥当性を検証するための方法としては、「類推法」を利用するのが良いでしょう。 類推法ってのは、「過去の対応案件で似たような案件を元に

木村岳史の極言暴論！ - SIガラパゴス、多重下請け構造の終焉の始まり：ITpro クラウドだ、オフショアだ細かい端々の間違いを指摘してたら、自分の書いていた過去記事とほとんどおんなじ内容になってしまったので、たまには趣向を変えて見ようかなと。 ※元記事の問題提起がワンパターン過ぎて。。。 そもそも、日本のSIerってガラパゴスと呼ばれるほど特殊なのか、について。 世界のシステム開発ベンダ IPA 独立行政法人 情報処理推進機構：IT人材育成事業：IT人材白書 世界のベンダ事情を調査した素晴らしいレポートなので一読あれ。 非常に長い内容なので、かいつまんでまとめます。 米国 ウェブサービス企業などのイノベーティブなハイエンドサービスを提供するIT企業は内製化。それ以外の非IT業種で、金融機関、連邦政府などIT部門が強い業種では、マネジメントやIT戦略部門を内製化、開発はベンダ（IBMなど）

事故って凹んだ話 - プロマネブログ 続報で、とりあえず事故後の対応が全て解決したので記録のため。 事故の状況 先月の事故の状況を再掲。 上図青がこちら側。赤が相手側となります。 片側3車線道路の左車線を走っており、前方の信号が赤になったので、前方車両後ろにつけようとしたところ、信号停止中の車を縫って車線横断しようとした車と激突した形となります。 丁度減速していたこともあり、大事には至らなかったものの、急ブレーキがぎりぎり間に合わず衝突してしまった形となります。 こちら側のボンネットと、相手方の左側ドアがぶつかった感じですね。 事故後は、双方の連絡先交換、警察をよんで事故証明を作成、と言った感じとなります。 その後の交渉 事故後はとりあえず、当方の任意保険のコルセンに連絡。相手方の損保会社からも連絡があり、交渉開始。 やっぱり一番気になるのは過失割合だったので、交渉前から事故判例調べたりし

革新的経営問答 - 「インソーシング」に切り替える訳：ITpro ちょっとだけ追記を書きました 「システム内製化でSIerへの～」のほんのちょっとだけ追記 - プロマネブログ 内製開始後、シェアが低下したマネックス フランケン：はい。そして「インソーシング（内製化）」にするということです。必要なシステム、ソフトウエアをマネックスの中で作ってしまう。内製化は2011年から始めて、順々に進めているところです。 元記事にあるように、2011年からシステムの内製化を始めたマネックスですが、その結果はいかがでしょうか。。。 インターネット専業証券は、「インターネットを使ったウェブサービス企業（システム投資以外の営業チャネルが少なく、システムの品質が売上にリニアに影響する）」「システム内製、外注を行っている会社が混在している」「情報が公開されている」と言った点から、システム外注と内製でどのように企業活

詳細設計書という名のゴミ | Gm7add9 この手の話題が定期的に上がるわけですけど、毎度同じだよねで終わってしまっては人間進歩しないので、何が問題でどうすればよいのか少し考えてみたく。 詳細設計書は「プログラム説明書」として欲しい。 まあ、元記事も多分業務システムの受託の話の模様なのでSIをターゲットに。 往々にしてSI、特にウォーターフォール開発のプロジェクトの中では、設計書などのドキュメントを多数作成いたします。*1 V字モデル的には、設計から開発に至るまでの間 要件定義書 基本設計書・外部設計書 基本設計書・内部設計書 詳細設計書 プログラム みたいな成果物を作成いたします。 個別の詳細は別のサイトに任せるとして、それぞれ記載する内容を一言で表すと、要件定義書は「スタートとゴール」、外部設計書は「業務とサービスの仕様」、内部設計書は「サービスの構造と機能の分割」となります。 ※た

日本のITエンジニアの地位はなぜ低いのか：日経ビジネスオンライン エンジニアの地位向上を図りたい、これは同意ですが、そのための解決策がコーディングスキルですか。。。 エンジニアの地位向上のためには、まず何が問題かをきちんと分析できなければ話になりません。ちょっと考えてみます。 追記) なぜかブコメ欄を見るといろいろコメントが発散してる。。。 下手な日本語で申し訳ないです。 本旨は「プラスアルファが必要って言ってるのに、paizaはコーディングの話だけなんだ～。プラスアルファどこいった」です。 ちなみにJavaの誤記は直しときました ブクマ炎上反省会はこちら 「コーディング技術にこだわり過ぎると～」の反省会 - プロマネブログ IT業界の価値提供の構造 いわゆるSIerをモデルに価値をどのように提供しているのか、考えてみます。 ※まあ、自分の仕事から考えるのが一番カンタンですし。 SIerを