SI屋さんとSIと、直近の課題について。 - 急がば回れ、選ぶなら近道
某セッションでちょっとしゃべったことをつらつらと。SIの現状と近い将来について思うところをまとめておきます。自分自身の立ち位置も確認していくという意味で。 結論的にいうと、SI自体は必要とされていますが、SI屋さんのビジネスモデルは成立しないという状況になるので、旧来の「SI屋さんの方法」ではうまくいきません。なので、別のやり方でSIをどうやっていくか？という議論が必要になりますね、という話です。 まずSI事業は人月稼働で商売をしています。スタート地点はそうではなかったのですが、一旦大きな人数を抱えると、食わせる必要があるため、より大きな仕事を取る羽目になります。要は稼働させる事、それ自体が目的になります。稼働を維持させる事で、収入を確保する事ができ、確保された収入で稼働のための人員を維持できる。そもそもそういう循環をベースに組織の目的が、「結果として」形成されてしまっています。 副作用と
Javaはアプリケーション開発言語として行き詰まっている、とアナリスト
「Javaによるビジネスアプリケーションの開発は複雑すぎる。開発チームはJavaからの逃避を検討すべきだ」という内容のレポート「Java Is A Dead-End For Enterprise App Development」（Javaはエンタープライズアプリケーション開発に行き詰まっている）を調査会社フォレスターのアナリストMike Gualtieri氏がブログで公開しています。 Gualtieri氏は、Javaはビジネスアプリケーションの開発言語として確固たる地位を築いており、COBOLが消え去らないのと同じように急に消え去ったりはしないけれど、Java以外の選択肢を検討した方がよいとしています。 ビジネス要件が変わり、プレゼンテーションレイヤで失敗した Javaが行き詰まっているというGualtieri氏のおもな理由をピックアップしてみましょう。 ビジネスの要件が変わってきた 変化
知るだけで天地の差が出る、テスト仕様書の必須項目＆表現方法
テスト仕様書で絶対に必要な項目リスト テスト仕様書に記述すべきものとして、以下の事項があります。 テストを実施した環境 実施するテストの内容 テストを実施するためのシステムの操作手順 テストの実行結果 個々のテスト項目を識別するための番号や記号（通し番号など） テストを実施した年月日 テストを実行した担当者 障害報告票番号（発生した障害の詳細を開発グループに報告する帳票の識別番号） まずはテスト環境について明記する テスト仕様書の先頭には、「テストを実施した環境」を記述します。ここでは、ハードウェア環境やソフトウェア環境、ネットワーク環境など、「どのような環境でテストを行ったか」を説明します。 ただし、テストを実施した環境を記述するだけでは十分ではありません。「顧客にとって必要な情報は何か」を考えるのです。ここで必要なのは、「要件定義書で規定した環境」との関係が分かることです。 なぜなら、
見積もり・発注 - 技術情報Wiki
発注／調達 † 値切ってはいけない 2009.3.6 確かに，プロジェクトには予算が決められており，その予算の枠内でやり遂げる必要がある。どうしても予算と見積もり金額が合わない場合には，入念に価格交渉を行い，発注者と受注者の双方が金額の妥当性について合意した上で確定させるべきなのだ。 そのためには，PMは出てきた見積もりを査定する能力が必要であり，かつ高い折衝能力が必要である。 はじめてのRFP 2008.2.4 調達用語 RFP,SLCP,SPAとか ＲＦＰ（Request For Proposal：提案依頼書） ＳＬＣＰ−ＪＣＰ９８：Software Life Cycle Process - Japan Common Frame 1998 ＳＰＡ（Software Process Assessment）
「ソフトウェアの部品化」が失敗する理由 ― ＠IT
経済産業省のとある外郭団体の委員をしている方と話をしていたら「我が国のソフトウェア産業を改革するためには、ソフトウェアの部品化を推進しなければならない」と話していた。うーん……ソフトウェアの部品化かぁ……。正直、頭をよぎったのは1980年代後半に国内のソフトウェア部品の集積を目指して立ち上げられたが、失敗した「Σ（シグマ）プロジェクト」だ。 Σプロジェクトから20年の歳月を経て同じコンセプトが出現するには理由がある。日本の輸出を支えている製造業で、製品におけるソフトウェアの比重が高まるに伴って、業界全体がソフトウェア・エンジニアの不足および、ソフトウェア関連の障害の多発に悩まされているからである。 外注先企業が作ったソフトウェア障害に悩まされている製造業の視点から見れば「なぜ、ソフトウェアはこんなにトラブルが出るのか？ 部品化して、それぞれの部品の品質チェックをもっと厳しくし、その上で再利
最適な工期は「投入人月の立方根の2.4倍」、JUASが調査 ― ＠IT
2007/07/05 日本情報システム・ユーザー協会（JUAS）は7月5日、ユーザー企業102社の357プロジェクトを調査した「ソフトウェアメトリックス調査2007」を発表した。システム開発の企画、開発計画に始まり、保守や運用管理まで実態を調査した内容で、企業情報システムの実態を伝える。調査結果からは“デスマーチ”となるプロジェクトの実態も浮かび上がった。 デスマーチ化するプロジェクトの条件の1つは工期の設定が不適切であることだろう。調査から導き出された標準開発工期は「投入人月の立方根の2.4倍」。調査対象のプロジェクトの全体工数と全体工期をグラフ化し、回帰直線によって求めた。この計算によれば1000人月のプロジェクトの場合は24カ月の工期を設定するのが標準的といえる。事情によってこの標準工期よりも短い工期しか取れない場合は、その短縮率を計算して対策を採るべきとJUASは提言。だが、「（短
ウノウラボ Unoh Labs: オープンソース戦略により、無償で使えるようになった負荷テストツール
こんにちは！ やまもと＠テスト番長です。 ウノウラボのコメント欄まで熟読されている慧眼な方は既にお気づきかもしれませんが、WebLOADという商用の負荷テストツールがオープンソース化され、無料で利用出来るようになりました。 http://www.webload.org/ 以前自分が書いた WEBアプリのテストに必須なツール7種のエントリにsaltysonicさんがコメントで教えてくださいました。ありがとうございました！ souceforge.net を探してみたところ、見つかりました。 WebLOAD 早速触ってみていますが、さすがに元商用だけあって多機能なようです。 関連記事も探してみたところ、以下のものが見つかりました。 http://news.earthweb.com/ent-news/article.php/3670176 http://www.testingreflec
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
実践的アプローチに基づく要求仕様の発注者ビュー検討会 - NTTデータ