見積もりと設計の間の高い高い壁 - novtan別館
この元増田は他の業界のものも含めて設計をお願いしたことって多分無いと思うんだよ。 家の場合だったら、普通は設計図と各パーツの詳細見積りで初めて契約だろうが。 見積りの根拠出してくれっていったら、金くれって言われたよ その設計図は増田が事細かに出した要望を元に一から作ったものなの？って話。 つまり、出来合いのものを適当に組み合わせたものには設計料は掛からないし、そうじゃないものには設計料が掛かるってだけの話ですね。 当然だけど、システムの設計もただではない。大まかな流れを示すと以下な感じ。ちょっと適当。 ・発注元に（ちゃんとした）システム部がある場合 要求仕様を作成し、それに基づいた提案をシステム会社に依頼する。この時点で要件がある程度はっきりしている場合、概要設計を元にした詳細見積もりが可能。出来合いのものを流用できるような要件であれば精度は高く、そうでなければ概算部分が生じる（要件定義フ
要件が確定しなかったことにつきベンダに責任がないとされた事例 東京地判平22.7.22（平20ワ16510号） - IT・システム判例メモ
ユーザがベンダに対し，ベンダが一方的に開発契約を解除したとして，損害賠償を求めたが棄却された事例。 事案の概要 ユーザＸは，ベンダＹに対し，平成14年9月18日に，Ｘの人材派遣業務に必要なシステムとして２つのシステムの開発を委託した（契約金額の合計は840万円）。 その後，Ｙは，9月25日にはソフトウェアの概要仕様を記載したシステム設計書を交付したが，Ｘは内容不十分であるとして記名押印を拒絶したためシステム設計書は確定しなかった。さらに，下請業者が交替するなどして，翌平成15年9月になってプロトタイプを作成するとともに再度ドキュメントを提出したが，Ｘは，やはり記名捺印を拒絶し，確定しなかった。その後もＹからはドキュメントが提出されているが，Ｘはやはり拒絶した。Ｙは，Ｘに対し「弊社は契約書の範囲内で最後まで誠意をもって開発を行います。」などと記載した書面を交付した。結局，平成16年9月になっ
AgileTourOsaka2012の感想 #agileto2012 - プログラマの思索
会場の8階の廊下から、箕面温泉や箕面の滝へ向かう道路が見えるので、景色はとても良い。 そんな会場で、50人近くの人達が集まり、講演内容も素晴らしく、熱気があった。 【1】牛尾さんの講演では、プロダクトオーナーの仕事に関するお話。 要求の洗い出しやヒヤリングについて、課題→対策→評価といういわゆる仮説検証スタイルでやっていくのが良いというお話。 要求開発やアジャイルUXの概念も絡めながら、コンサルタントとして必要なテクニックの紹介があって面白かった。 Twitter / akipii: ステークホルダー表を作るか。プロジェクト計画書の客も含めた体制図に似てるかな #agileto2012 Twitter / akipii: ありふれた言葉の裏に牛尾さんの豊富なコンサルタント経験を感じる #agileto2012 【2】藤原さんの講演では、楽天でアジャイルコーチとしてチームの成長に関わったお話
SIで得るものはあるのか？ - 急がば回れ、選ぶなら近道
「SIで得るものはあるのか？」 おそらくここ10年以上、日本各地で自問自答された問いでありまして。かくいう自分もその一人であります。デスマの度に、ここまでやる意味はあるのか？赤字の度に、そこまでやる意味はあったのか？ 思わなかった人はいないはずです。特にここ数年は、見るもの聞くもの、酷いプロジェクトが自分の周りでも多く、「いいから、そのまま回れ右」という行動パターンの機械学習全開です。（遠い目 他方、「構築をやらないと確実に実装力は落ちる」こういう声もあるでしょう。これもまた真実ではあります。特に、SIの中身丸投げモードのスイッチが入りっぱなしで液漏れ寸前なところは、もはや経験不足を通り越して「リバース・プロキシーって何をするんだっけ？」って真顔で聞くPMの方もいらっしゃる状態もありまして。実際にやらないとわからない、ということは普通におきます。特にアーキテクチャやインフラ周りは、そうなっ
SI屋さんとSIと、直近の課題について。 - 急がば回れ、選ぶなら近道
某セッションでちょっとしゃべったことをつらつらと。SIの現状と近い将来について思うところをまとめておきます。自分自身の立ち位置も確認していくという意味で。 結論的にいうと、SI自体は必要とされていますが、SI屋さんのビジネスモデルは成立しないという状況になるので、旧来の「SI屋さんの方法」ではうまくいきません。なので、別のやり方でSIをどうやっていくか？という議論が必要になりますね、という話です。 まずSI事業は人月稼働で商売をしています。スタート地点はそうではなかったのですが、一旦大きな人数を抱えると、食わせる必要があるため、より大きな仕事を取る羽目になります。要は稼働させる事、それ自体が目的になります。稼働を維持させる事で、収入を確保する事ができ、確保された収入で稼働のための人員を維持できる。そもそもそういう循環をベースに組織の目的が、「結果として」形成されてしまっています。 副作用と
IPA討論会の現場が@ITの記事と全然違っている - 矢野勉のはてな日記
雑談, メモ立て続けに自分用メモ兼情報共有用にブログに書いておきます。 ひがさんのブログ経由で知ったのですが、IPAX 2008を見に行ってきたというブログ記事を読むと、@ITでの「「10年は泥のように働け」「無理です」――今年も学生と経営者が討論 − ＠IT」と全然雰囲気が違って見えるんですよ。@ITの記事よりもちゃんと現場の雰囲気を伝えてくれているように思います。正直必読かと。 実際、同じ討論会の記事でも@ITの記事ではなくてITProのほうが記事としてはまともで、プログラマ→エンジニア→PMという時代遅れなキャリアパスを提示した西垣さんにしでも、実際には「未踏でスーパークリエータに認定された技術者が3人Googleに就職したが，それはいいことだと思っている」「IT技術者はやりがいがある仕事か」---学生とIT産業のトップが公開対談：ITproとか天才プログラマのように技術を極めるので
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
