「元請けにこだわる理由」の「いいがかり」についてひとこといっておくか - ひがやすを技術ブログ
自社のバックオフィスの方が、外注先に対してどんな立ち居振る舞いをしているのかご存じですか？ 自社と外注先との間の契約がどのようになっているのかご存じですか？ それを目の当たりにしても同じことを言い続けられる自信はありますか？ そういうことはスーツの仕事とレッテルを貼って見て見ぬ振りをしてませんか？ それでいて業界を変えたいなどといいますか？ 業界を変えたいっていってるところから、おいらのことを言ってるとして話を進めるよ。 バックオフィス(この文脈では調達のことかな)の方が、外注先に対してどんな立ち居振る舞いをしているのかは、正直良くわかりません。転職したことがないので、他の会社のことは良くわからないけど、弊社の場合は、調達と外注先が価格や条件の交渉する場に、案件側の人間は立ち入ることはないためです。必要だといわれたらもちろん同席するけどね。 新規取引をさせていただくときの最初の顔合わせに同
NTTデータとの決闘シリーズ第二幕 - ひがやすを技術ブログ
昨日は、NTTデータとの決闘シリーズ第二幕。戦闘服には、かりゆしウェアを選びました。 今回は、データの顧客であるユーザ企業からも参加していただきました。この人はKさんと呼ぶことにします。Kさんは、現在Seasar2(SAStruts, S2JDBC)を使って、プログラミングファースト開発を実践されている先進的なユーザです。BtoCのサイトを作っていると考えてください。 プログラミングファースト開発の詳細はこちら。 http://d.hatena.ne.jp/higayasuo/20080501/1209636051 http://d.hatena.ne.jp/higayasuo/20080721/1216607451 最初のテーマは「品質」。データとしては、 テストコードのカバレッジやバグ密度などで品質を確保しようとしている。 でも、品質に問題があるプロジェクトも残念ながら存在する。 品質
ガラパゴス、ガラパゴスってうざいんだけど - ひがやすを技術ブログ
ガラパゴス諸島では、外界から遮断された環境で生物が独自の進化を遂げた。これになぞらえて、国内市場に安住して世界に通じる製品やサービスを生み出せなくなった日本のＩＴ業界を「ガラパゴス化」と呼び懸念する声が2007年ごろから広がりだした。ケータイ先進国といわれながら海外市場からの撤退を余儀なくされた携帯端末業界や、国内企業頼みのシステム開発業界などがその例で、最近はＩＴ業界内でも「ガラパゴス化」問題が議論されるようになっている。 単純に世界に通じていれば良いというもんでもないでしょう。ある分野で負けずに勝ち残っていればそれでいいんじゃないの。 ガラパゴス、ガラパゴスって本当にうざったい。 別に国内に留まれっていってるわけではないですよ。国内に向いたサービスもあれば、世界共通でやったほうがいいサービスもある。海外に出ないから一律悪いみたいな固定概念は、おかしいんじゃないのということです。 フレー
開発生産性が低い方が収入が多いって変だよね - ひがやすを技術ブログ
開発生産性が低い方が収入が多い（人月がかかるほどお金がとれる）というビジネスモデルを根底から覆す可能性があります。開発生産性をあげればあげるほど収入が減ってきます。SIビジネスが立ち行かなくなる方向に向かうのです。 実際の現場では、開発生産性が低くて、人月がかかるほうが売上が増えるというのは、紛れもない事実です。大手SIerの開発手法が、生産性よりも失敗しないことを重視するのは、この事実が原因なのは間違いありません。失敗せずに多くの工数をかけたほうが売上が増えるのです。 だから、ソースコードと一対一に対応するような無駄なドキュメントを「誰が書いても同じようなソースコードにするため」なんて理由で書かせるのです。 詳しくは「誰が書いても同じコード」は大事なことなのかのエントリを参照してください。 営業は、売上で評価されることが多いので、営業の力が強いところは、売上至上主義に走りがちです。でも、
深い業務知識が必要なのは案件の提案者と要件定義者 - ひがやすを技術ブログ
SIerが必要としているのは業務知識だという都市伝説のエントリで、誤解されたのは、「SIerは深い業務知識が不要だ」というふうに私が主張していると思われたことですね。 誤解されるのは、もちろん、私の書き方が悪かったせいなので、続きを書きます。 SIerで深い業務知識が必要とされる人がいます。案件の提案者と要件定義者です。営業がお客様のところから案件を持ってくると、その案件に関する深い業務知識を持っている人がアサインされ、提案書と見積りを作ります。この役割の人は、深い業務知識が必要です。 無事に案件が獲得できたとしましょう。お客様のところにいって要件をつめるのですが、このときのメンバも深い業務知識が必要です。しかし、全員が深い業務知識を持っていなくても大丈夫。全体の半分弱くらいのメンバが深い業務知識を持っていれば大丈夫だと思います。案件の難易度にもよりますが、一人が業務を深く理解していれば大
SIerが必要としているのは業務知識だという都市伝説 - ひがやすを blog
SI業界が開発するシステムの目的は何か？ それがつまり「業務知識」というやつで、金融や保険だったり、証券取引、財務会計、生産管理、物流・在庫管理、販売管理だったりするのだ。それぞれ必要とされる知識は非常に多い。普通の新入社員がOJTで身につけようと思ったら数年かかってもおかしくないだろう。 金融(ディラーが使うようなポジション計算をするフロントシステム、リスク計算をするようなミドルオフィス、勘定系のバックオフィス)、流通、輸出入、製薬など、いろんな業務をやってきたおいらが通りますよ。 確かに金融は業務知識がないと歯が立たない。でも、自分の経験した限りでは、それ以外の業務は、案件が始まってから勉強しても十分間に合います。 一週間以内の勉強で、お客様のところにいってシステムの仕様を話し合うことはできるようになります。もちろん、この道何年って人にはかないませんよ。でも、仕様を決める分には困らない
NTTデータと真昼の対決 - ひがやすを技術ブログ
昨日、NTTデータに「お前は最近、NTTデータに批判的でけしからん」ということで、呼び出されました。もちろん、「批判的でけしからん」というのは冗談ですが、私が、NTTデータを嫌っていると思っているデータ関係者は、実際多いようです。 データの偉い人の発言に対して、それはちょっとおかしいんじゃないのといったことはありますが、データを嫌いといったことはもちろんないはず。 データの社員の中に根強くある(と思う)「プログラミングがあまりできない人でも何とかなるように、ガチガチにルールやツールで縛る。できる人はスキルを発揮できなくなるかもしれないけど、それはしょうがない。」という考えは、個人的には好きじゃないけど。大規模なプロジェクトをまかされるSIerとして、そう思う気持ちは良くわかるんだけどね。 話し合いの中で、私が言ったのは、できる開発者が力を発揮できるように、体力勝負になってしまうような縛りは
iPhoneは老害リトマス試験 - ひがやすを技術ブログ
この老害リトマス試験は、スーツな人もギークな人もスイーツな人も受けて欲しい。自分の老害危険度がわかるはず。 老害とは、「状況の変化を認識できず、古い考えを押し通し、回りに迷惑をかけること」。 詳しくはこちら。 SI業界の老害が若手と下請けを蝕む理由 日本版iPhoneのニュースを見たとき、あなたはどう思っただろうか。 「ぜひ欲しい」と思ったあなた。正常な反応だけど、「でも、それだけ?」 日本でiPhoneがどれくらい売れるのかを予想してもあまり意味がない。だって、神様でもない限り先のことはわからないんだから。 でも、これだけはいえる。 「iPhoneは新しいアプリケーションプラットフォームになる」 新たなアプリケーションプラットフォームの立ち上がりに参加できるなんてすごい幸運だ。スーツな人なら、新しいビジネスを考え付けば、大もうけできるかもしれない。 ギークな人なら、このわくわくするテクノ
SI業界の老害が若手と下請けを蝕む理由 - ひがやすを技術ブログ
10年間泥のように働いて花が咲きましたのぶくまのコメントにこういうのがありました。 経営層がプログラムの品質を度が越えたほどに軽視する理由の 一つが説明されてます。目から鱗です。意外とみんな知らないようなので、「SI業界の経営層の考えが古い理由」をきちんと説明したいと思います。 汎用機あるいはオフコンの時代は、COBOLやRPGなど(他にもありますが私が経験したものをあげています)の言語が使われていました。 昔の言語は、誰が書いても同じようなコードになると思われていました。もっというと、コピペしてちょっと書き換えるという開発スタイルが多かったのです。もちろん現場によって開発スタイルは違うと思いますが、コピペが横行してたんじゃないかなぁ。 コピペでの開発なら、そりゃ誰が書いても同じようなコードになるよね。 再利用性、保守性より「最初にとりあえず動かすこと」が重要視された。コピペでちょろっと変
ITゼネコンをぶっつぶせ - ひがやすを技術ブログ
日本Javaユーザグループ主催で、クロスコミュニティカンファレンス(CCC)が、4/30日に行なわれます。その中で私も「ITゼネコンをぶっつぶせ」というテーマでBOFをやるので、興味のある方はぜひおいでください。 http://www.java-users.jp/contents/events/ccc2008spring/sessions.html#BOF1 BOFなんで、わきあいあいと「ITゼネコンをいかにしてぶっつぶすのか」について、ディスカッションできれば良いなと思っています。 BOFの中で、「Programming First Development」という開発手法を披露します。これがITゼネコンをつぶす秘策なんですよ。直ぐにつぶすことはできないと思うけど、そのきっかけにしたいなと思っています。 「Programming First Development」の考えは、うちの会社のト
浜口さんに贈るSI業界を良くする方法 - ひがやすを技術ブログ
浜口さんの言葉には、ブクマや突っ込みを生み出す何かがありますね。 したがってシステムの大規模化は、必然的に想像以上のコストアップと信頼性リスクの増大を招くものであるとの認識が必要になる。 きました。想像以上のコストアップだそうです。 そんな浜口さんに贈ります。今よりコストダウンさせて、SI業界を良くする方法。 例えば、誰が書いても同じコードにするために、プログラム設計書(内部設計書)を今、書かせているとしたら、そんな無駄なものはやめたほうがいいと思う。 プログラム設計書は、自然言語で書きます。プログラムは、プログラミング言語で書きます。どっちの言語が、プログラムを書くのに適しているかといえば、誰が考えても、プログラミング言語ですよね。 いきなりプログラミングはできない人もいるから、プログラム設計書が必要だという人もいるかもしれませんが、それは、間違っていると断言しましょう。 いきなりプログ
そろろろRailsについて本音を書いてみるか - ひがやすを blog
最近の大田さん@mixiのところで、Rubyについて考察する機会があったのと、よういちろうの考えと同じことを思っていたので、たまには本音で書いてみる。 Railsで、最も良いところは、テストの雛形も自動的に作ってくれて、テストの敷居を下げてくれてるところだと思う。なのに、それについて触れる人があまりにも少ないような気がする。一応、私は、1年半以上、はてなのキーワード検索で毎日Railsについては調べているので、はてなでRailsについて書いている人の記事はたいてい見ています。 理由は、いくつか考えられますが、私の読みだと、テストが当たり前の人にとっては、当たり前すぎてわざわざ書く意味がないし、そうではない多くの人にとっては、ほとんどテストは書いていないんじゃないかな。 実は、テストを書くのは結構工数かかるんですよ。スクリプト言語は、コンパイラがミスを教えてくれることはないので、Javaと比
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
