SIerが必要としているのは業務知識だという都市伝説 - ひがやすを blog
SI業界が開発するシステムの目的は何か？ それがつまり「業務知識」というやつで、金融や保険だったり、証券取引、財務会計、生産管理、物流・在庫管理、販売管理だったりするのだ。それぞれ必要とされる知識は非常に多い。普通の新入社員がOJTで身につけようと思ったら数年かかってもおかしくないだろう。 金融(ディラーが使うようなポジション計算をするフロントシステム、リスク計算をするようなミドルオフィス、勘定系のバックオフィス)、流通、輸出入、製薬など、いろんな業務をやってきたおいらが通りますよ。 確かに金融は業務知識がないと歯が立たない。でも、自分の経験した限りでは、それ以外の業務は、案件が始まってから勉強しても十分間に合います。 一週間以内の勉強で、お客様のところにいってシステムの仕様を話し合うことはできるようになります。もちろん、この道何年って人にはかないませんよ。でも、仕様を決める分には困らない
IT産業を呪縛する 「変われない日本」 - モジログ
ITproの高橋信頼記者より、先日の私のエントリ（「雇用規制撤廃と減税で日本経済は再生する」）を紹介したとの連絡をいただき、さっそく読んだ。 ITpro - 学生とIT業界トップの公開対談で胸を衝かれたこと---IT産業を呪縛する“変われない日本” http://itpro.nikkeibp.co.jp/article/COLUMN/20080530/305172/ ここしばらくIT系ブログやソーシャルブックマークなどで大きな話題になっていた、IPAX2008での対談イベント（関連記事は末尾を参照）をふりかえりつつ、そこにあらわれたIT業界の問題点が分析されている。 まず、IT業界のダメっぷりを示すこのエピソードが面白い。 ＜昔、「行き詰ったプロジェクトを立て直す」というテーマで取材したときに、ある大手システム・インテグレータで聞いた話だ。そのインテグレータで、火を噴いたあるプロジェクトを
NTTデータと真昼の対決 - ひがやすを技術ブログ
昨日、NTTデータに「お前は最近、NTTデータに批判的でけしからん」ということで、呼び出されました。もちろん、「批判的でけしからん」というのは冗談ですが、私が、NTTデータを嫌っていると思っているデータ関係者は、実際多いようです。 データの偉い人の発言に対して、それはちょっとおかしいんじゃないのといったことはありますが、データを嫌いといったことはもちろんないはず。 データの社員の中に根強くある(と思う)「プログラミングがあまりできない人でも何とかなるように、ガチガチにルールやツールで縛る。できる人はスキルを発揮できなくなるかもしれないけど、それはしょうがない。」という考えは、個人的には好きじゃないけど。大規模なプロジェクトをまかされるSIerとして、そう思う気持ちは良くわかるんだけどね。 話し合いの中で、私が言ったのは、できる開発者が力を発揮できるように、体力勝負になってしまうような縛りは
人月を超えるということ
人月というのは文字通り働いた時間に応じて請求が行われるというもの。ブルーカラー的な労働をしている限りは人月で働くことは正当なわけです。 「作らない」という視点 人月を超えるためには時間に関係なく圧倒的な成果を挙げる方法を見つけなくてはいけません。でも、圧倒的に生産性をあげるという視点ではだめ。生産性を上げているというのは、あるプロセスの作業効率をあげて時間を短くしているに過ぎないので時間給の罠からは逃げられない。ありがちな話として3ヶ月かかるAさんよりも、2人月でできるBさんのほうが実入りが少ない。 では、どうするかというと「作らない」という視点になる必要性があります。作らないというのどういうことかというと「作ったものをいかに使いまわせすか」か「いかに他人に作ってもらうか」ということです。 作ったものをいかに使いまわせすか＝レバレッジを効かす 使いまわすというのはレバレッジ（てこ）を効
浜口さんに贈るSI業界を良くする方法 - ひがやすを技術ブログ
浜口さんの言葉には、ブクマや突っ込みを生み出す何かがありますね。 したがってシステムの大規模化は、必然的に想像以上のコストアップと信頼性リスクの増大を招くものであるとの認識が必要になる。 きました。想像以上のコストアップだそうです。 そんな浜口さんに贈ります。今よりコストダウンさせて、SI業界を良くする方法。 例えば、誰が書いても同じコードにするために、プログラム設計書(内部設計書)を今、書かせているとしたら、そんな無駄なものはやめたほうがいいと思う。 プログラム設計書は、自然言語で書きます。プログラムは、プログラミング言語で書きます。どっちの言語が、プログラムを書くのに適しているかといえば、誰が考えても、プログラミング言語ですよね。 いきなりプログラミングはできない人もいるから、プログラム設計書が必要だという人もいるかもしれませんが、それは、間違っていると断言しましょう。 いきなりプログ
受託からサービスへの移行に必要なこと。
よくwebの受託をメインにやっている会社さんが、儲からないという理由でサービスに行きたいとの話を聞く。 しかし結構、難しいですよね、と、ついつい言ってしまう。 理由のコアは、下記エントリーに書いてあった。 「中毒性」ある受託開発がソフトウェアベンチャーの躍進を阻む １．受託開発では「技術」が蓄積しない ２．受託開発では「人材」が蓄積しない ３．受託開発では「資金」が蓄積しない 技術が蓄積されないのは自社の役割や案件次第では？と思うこと以外は、結構同意だ。 （受託は、自社では実現できない案件に関われることなどが魅力で、そこに技術やノウハウ習得のチャンスは転がっていると思うし。） 一番重要なのは、キャッシュフローが安定しないところではないだろうか。 サービスと受託の大きな違いは、 「受託は技術を売る仕事」 「サービスは、文字通りサービスを売る仕事」 である。 サービスは、お客様がつくと継続的に
大企業にありがちな問題。委託開発の甘い罠・・・
このところ、「大規模サービスを展開する企業が陥るジレンマ」 や 「本当に技術が必要とされる現場にgeekがいない」 で興味深い話が語られています。賛同する部分も多くあります。 さて、とある企業に勤める僕なのですが、最近手がけている仕事のやり方が非常に気にくわない部分がありまして、グチっぽいかもしれませんが思うところを記事にしてみました。他の企業の方々はどうなのかなぁ〜と思いまして。 それは、外注（開発の請負や業務委託等）って本当に必要なの？ってことです。特に大企業にありがちだと思います。 金融系や通信系といった真にミッションクリティカルな基幹系システムにおいては、その業界に特化した基盤やルールってのがあって、その専門的知識を有するソフトウェアベンダーへ開発を業務委託するってのは当然かと考えています。もっともソフトウェア業界で働く知り合いからは悲鳴しか聞こえてきませんが・・・。 僕が問題とし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
