タグ

プログラマのビジネスに関するholyppのブックマーク (4)

  • テストは誰が書くのか - 未来のいつか/hyoshiokの日記

    昨日のエントリの補足的なもの。id:hyoshiok:20100612#p1 テストは誰が書くのか。もちろんコードを書いた人が書く。コードは誰が書くのか。設計をした人が書く。誰が設計をするのか。要求を分析した人がする。このように一つの機能について一人が責任を持って行うのがベストプラクティスになっている。 ところが、日のソフトウェア産業の8割以上は受託開発と言われているが、そのような現場では誰かが一貫してすべての工程に責任を持つということは普通行われていない。工程を上流下流とわけ、いわゆる一次受けと呼ばれる大手SIベンダーが要求分析をし、その下に設計実装する下請け、孫請けを持つという多重構造になる。 要求分析をして、仕様にまとめるわけであるが、実装のコスト(実装のしやすやしにくさ、実装工数の大きさ)はほとんど考慮されない。契約文書として、これこれを実装することみたいなものがあらかじめ取り交

    テストは誰が書くのか - 未来のいつか/hyoshiokの日記
  • 大手SIer(インド)の収益向上がとどまることを知らない件 - Thoughts and Notes from CA

    "大手SIerの利益悪化がとどまることを知らない件"で紹介されている表をちょっと拝借し、営業利益率を加えてみた。 社名 売上高(億円) 営業利益(億円) 営業利益率 2007 年度 2008 年度 2009 年度 2007 年度 2008 年度 2009 年度 2007 年度 2008 年度 2009 年度 NTTデータ 10,449 11,390 11,429 898 985 816 9% 9% 7% 大塚商会 4,694 4,671 4,271 300 270 160 6% 6% 4% 野村総合研究所 3,279 3,412 3,386 481 497 400 15% 15% 12% ITホールディングス 3,224 3,383 3,148 199 237 159 6% 7% 5% 伊藤忠テクノソリューションズ 3,192 3,072 2,903 250 216 215 8% 7% 7

    大手SIer(インド)の収益向上がとどまることを知らない件 - Thoughts and Notes from CA
  • スマートフォン勉強会に参加して:ベンチャー社長で技術者で:エンジニアライフ

    わけあってiPhoneを持つことになったのだが、持つなら何かソフトを開発したいな、ということで「スマートフォン勉強会」に参加させてもらいました。 気がつけば最年長。そうか、自分では若いつもりだったけれどそんな歳になったんだな~。何ともアウェーな感じであった……。しかし、アウェーなりに得るものはあって、一番分かったことというのが、何のことはない「システム屋さん」と「ソフト屋さん」の感覚の違いというものでした。 勉強会のお話で、「スムーススクロールをタッチスクリーンで実現するのに、結局は標準コントロールなどではうまくできず、ゴリゴリとネイティブコードで書きました」ってなお話がありました。オヤジのわたしは、DOSでもそういえば「何とかアニメーションを!」とか考えていたことはあったな~、同じような計算をしながらゲームを書いてたな(いや、わたし自身はゲームは作らずソースを眺めていただけですけど)。

    スマートフォン勉強会に参加して:ベンチャー社長で技術者で:エンジニアライフ
    holypp
    holypp 2010/05/19
    人月を1/5にすることならできるでしょう。それによってパフォーマンスは落ちるかもしれませんが、それが致命的かどうかは作る人の思いだけ。ただし1/5の期間で物を作れても、SIerなら大抵は良しと言われない現実。
  • ユメのチカラ: 開発工程を別々に担当してはいけない

    古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。 特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。 よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。 ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。 一度固定した文書は次のフェーズで変更

    holypp
    holypp 2010/05/11
    キーワードだけ。心に刻んでいつか壊す。>上流、人月単価、ドキュメントは冗長に、製造の責任ではない、ゼネコン、実力より所属、業界にとってエンジニアの使い捨ては百害、工程の分離は悪。
  • 1