ユーザがベンダに対し，ベンダが一方的に開発契約を解除したとして，損害賠償を求めたが棄却された事例。 事案の概要 ユーザＸは，ベンダＹに対し，平成14年9月18日に，Ｘの人材派遣業務に必要なシステムとして２つのシステムの開発を委託した（契約金額の合計は840万円）。 その後，Ｙは，9月25日にはソフトウェアの概要仕様を記載したシステム設計書を交付したが，Ｘは内容不十分であるとして記名押印を拒絶したためシステム設計書は確定しなかった。さらに，下請業者が交替するなどして，翌平成15年9月になってプロトタイプを作成するとともに再度ドキュメントを提出したが，Ｘは，やはり記名捺印を拒絶し，確定しなかった。その後もＹからはドキュメントが提出されているが，Ｘはやはり拒絶した。Ｙは，Ｘに対し「弊社は契約書の範囲内で最後まで誠意をもって開発を行います。」などと記載した書面を交付した。結局，平成16年9月になっ

たまにはブログ更新したいから、ついさっき流れてきたエントリに食いついちゃうよー。 ソフトウェア設計とは何か 〜 設計にはプログラミング経験が必要か否か | Social Change! 工程の分断はあり得ません ソフトウエアの設計に実装経験が要るか要らないかというのはそもそも議論にならない。「ソフトウエアの設計＝仕様の設計+コードの設計」なんだから、例えればコインの表と裏。それらは引き離すことは出来ないのに引き離して分業しようとするからよろしくないことが起きてしまうというのが、上記記事の主題かと思います。簡単に言えば。 僕もこの点については「工程の分断」という言葉で何度も書いています。コインの表と裏であるべきものを分断してしまうと、互いのフィードバックを得る術を無くしてしまいます。そうなったら良いことは無い。ここは誰でも納得がいく所でしょう。 仕様を設計するチャンスって超少ないんじゃない？

どうもこんにちは。 Aiming で東京開発グループのゼネラルマネージャをやっている小林です。 8月に mobage と Yahoo! モバゲー で ロードオブナイツ というシミュレーション RPG をリリースさせて頂きました。 そして、先週、 Yahoo! モバゲー版の PC ブラウザ専用デザインをリリースさせて頂きました。 今回リリースしたものは元々 Unity で作られていた iOS アプリ版 Lord of Knights を HTML5 で書きなおしたものです。 （今は Android 版 もあります） HTML のポチポチゲーをネイティブに移植したというのはよく聞く話ですね。 ですが、逆にリッチなネイティブアプリを HTML5 に移植し、かつスマフォブラウザと PC ブラウザで同じものを動かすなんてのは前例が見当たりませんでした。 技術的ハードルが高かったことに加えて期日がタイ

なぜアジャイルなのですか？改めて考察するウォーターフォールとの違いに参加してきました。 ウォーターフォール（以下WF）はよくDisらr・・・アジャイルと比較されます。 私もアジャイル開発を知るまでそうではない開発を経験したことがありますが、おそらくそれらはWF開発をしていたわけではなく、WFのようななにかに過ぎなかったと思います。 だから、ちゃんとしたWFについても勉強したいなーと考えていたのでとてもいい機会になりました。 株式会社ジャムズを経営されている玉牧 陽一さんのご講演のポイントをまとめます。 詳細については下記SlideShareをぜひご覧ください。 なぜアジャイルなのですか？改めて考察するウォーターフォールとの違い WFの原点に関わる流れ 1970年 Managing the Development of Software Systems via Winston Royce W

僕には、いろんな人に自慢しまくっている従兄弟がいる。 彼とは1歳違いなので、小さい頃から仲が良かった。例えば、僕が最初に暗記した英文は、"This is a pen"ではなく、"Your name is shit!"なのだが、それは親の仕事の都合でアメリカに行っていた彼から、6歳の時に伝授されたのだ。 現地のガキとの戦闘用語として。 ガリ勉派の僕とは違って彼は勉強が嫌いだったらしく、若い時からフランス料理の世界で修行を重ねた。やがてシェフにのし上がり、今年になってついにオーナーとして自分の店を出した。30代で一国一城の主である。立派だ。 料理人の世界は努力と創造性と技術による、競争の世界である。そこで結果を出してきたことに対して、僕は素直に彼を尊敬している。 ちなみに、彼の料理は滅茶苦茶ウマイ。彼の料理以外で太るのは悔しいから、僕は他のフランス料理屋には行かなくなった。 先日も食べに行った

エンジニアtypeは、各種エンジニアをはじめ「創る人たち」のキャリア形成に役立つ情報を発信する『＠type』のコンテンツです。

はじめに バージョン管理ツールの1つに、Googleでも採用されているPerforceというものがあります。Perforce社は、バージョン管理ツールだけでなく、マージツールも提供しています。今回はPerforce社製の無償のマージツールPerforce Visual Merge Tool (P4Merge)を使ってみました。 Perforce(パフォース)とは Perforce社製の有償のバージョン管理ツールです。Perforceの特徴は、Windowsはもちろんのこと、LinuxやMaxOSでも動作するマルチプラットフォームのサポートやツール自体が軽快で高速に動作することなどが挙げられます。 JavaOneの展示会場に出展していた「Perforce」（パフォース）が目にとまりました。プロプライエタリなソースコード管理ツールです。名前は聞いたことがありましたが、実はどんなものかよく分かっ

SIerがオワコンだったり新人SEが絶望する今日この頃。組織を憂う前に自分が技術者として終らないようにするほうがよっぽど建設的だと思っている。ひとこと「勉強しよう」というのは簡単。それよりも先に、職業倫理について考えてみるのはどうだろう。 職業がプロとして成熟した証の一つは、倫理規定または職業上の行為の水準が存在することである。 ソフトウエア開発プロフェッショナル　第20章 専門的職業の倫理規定（P239） マコネルの会社のエンジニアが最初に学ぶこと コンストラックスは、Code Completeで有名なスティーブ・マコネルの会社である。同社の専門技術者育成プログラムがソフトウエア開発プロフェッショナルに紹介されていて興味深い。英語版は以下からダウンロードできるようだ。 Construx Professional Development for Software Organizations

続きを書きました　→　伝えなければ伝わらないという当たり前の話 ソフトウェア開発に関する相談を受ける中で、どうもソフトウェアというものの特性について誤解をされているな、という思いを持つことがあります。 そうした場合、聞いてみるとプログラミングの経験が無かったり、殆どプログラミングには携わったことがないという方が多いです。 ソフトウェアを開発しようとするならば、ソフトウェアという特性をよく知った上で、プロジェクトは運営した方が良いし、うまくいくはずです。そしてソフトウェアならではの特徴を知るのに、プログラミングの経験はとても重要です。 この記事では、プログラミング経験の無い方が陥ってしまいがちな、ソフトウェア開発にまつわる誤解について考えてみました。 Harry Potter is Ready for Divination / weekbeforenext 誤解：既にあるソフトウェアを流用し

皆さんの現場では、矛盾を抱えながら開発を進めてはいないでしょうか？ 自分たち以外の誰かが決めた、スコープ、期限、コストを守るために、「絶対無理！」と いいながら毎日残業している方もいるのではないかと思います。 ウォータフォールプロセスは、このような矛盾を含んだ開発の代名詞のように語られる こともありますし、その対極の存在としてスクラムなどのアジャイルが語られることが 多いように思います。 私は、開発の矛盾は開発プロセスそのものには直接依存していないと考えています。 アジャイルも開発の矛盾を解消することを目的としているわけではありません。 しかし、組織の構造と開発プロセスの組み合わせが影響する場合はあるのではないかと考えています。 ヒエラルキーを持った組織とウォータフォールプロセスの組み合わせにおいては、 スコープ、期限、コストなどのコミットメントを上位に対して守らなければならない プレッシ

エンジニアtypeは、各種エンジニアをはじめ「創る人たち」のキャリア形成に役立つ情報を発信する『＠type』のコンテンツです。

プロジェクト管理は決して精密な科学ではないが、これにソフトウェア開発が持つ予測が難しいという性質と組み合わせられると、大きな悲劇のレシピが生まれる。わたしは、ソフトウェア開発プロジェクトに取り組んでいるプロジェクトマネージャーがよく犯す過ちを数多く見てきた。それらの過ちの一部はソフトウェア開発に限ったことではないが、この文脈では特に頻繁に起こり、ダメージも大きい。 1．「人数を増やせばよい」という誤解 Fred Brooks氏は同氏の有名な言葉の中で、よくあるプロジェクト管理の間違いについて「ある女性が9カ月に1人子どもを産めるからといって、9人の女性がいれば1カ月に1人の子どもを産めるわけではない」と表現している。そして、この間違いは今でも頻繁に見られる。ある問題に多くの人間を割り当てれば、その問題は早く解決するという考え方だ。残念ながら、これは正しくない。 プロジェクトに人を1人投入す

エンジニアtypeは、各種エンジニアをはじめ「創る人たち」のキャリア形成に役立つ情報を発信する『＠type』のコンテンツです。

アジャイル開発を実践して「納品のないサービス型の受託開発」というユニークなSI事業を展開するソニックガーデン。アジャイル開発については、2011年末ぐらいから大手のITベンダーも本腰を入れて取り組みつつあるようだ。ソニックガーデンで社長を務める倉貫義人氏に、アジャイル開発の意義とどのようなシステムに向くかを聞いた。 確かに最近、SIerによるアジャイル開発の取り組みをよく聞く。ユーザー企業においても、基幹システムに適用するなどの事例があるようだ。 アジャイル開発が話題に上ることが増えているものの、そもそも何を解決するものなのかわかって話している人が少なすぎると感じている。バズワード化しているアジャイルに経営者が注目してシステム部門に投げ、やってみようとなるケースもあるようだ。こうしたケースでは、「解決策から問題を考える」というように、思考の順番が逆転しているのではないか。 本来であれば、「

ここ最近の「アジャイル」という言葉の使われ方に違和感を感じています。 年々システム開発のプロジェクトは、短納期化と低コスト化の流れが進んでおり、それによってリスクが増して且つ利益の出にくい状況になりつつあり、多くのシステム開発を請け負うシステムインテグレータは様々な取り組みを進めています。 そして、その一つとして期待されているのが「速い・安い」を実現する「アジャイル開発」だと言うわけです。もはや、まるでファストフードです。 大手システムインテグレータが集まってアジャイル検定を始めるようです。一部引用します。 アジャイル検定の本格運用に向けた、アジャイルソフトウエア開発技術者検定試験準備委員会を設立 近年、ソフトウエア開発では、厳しい経済不況などの影響を受け、ユーザーの要件を確実に、高品質に、より短期間で提供することが求められています。このような環境の下で、注目されているのがアジャイル開発手

受託がいいとか、悪いとか罠だとかいう議論がある。 ぼくはそんな単純な議論ではないと思う。 いい受託と悪い受託がある。 ポイントはたった４つだ。 難しくない。全部そろってる必要もない。 ただ、ひとつも揃ってない案件はやる必要もない。 (1)時間を犠牲にするほど単価がいいか？ (2)お金以外で得られるノウハウ・スキル・実績はなにかあるか？ (3)価格の決定権のあるキーマンとのパスがあるか？ (4)担当者がトラブルメイカーでないか? 長期的に最も大事なのは(2)だ。ぼくはネットのことを何も知らないで、ネットの仕事を請けた。元々組み込みエンジニアだったからだ。最初なんか、phpもSQL触ったこともないのにイントラwebの仕事を請け、java触ったことないのにiアプリの仕事を取ってきていたし、SEOの仕事を取ってきた帰り道に本屋でSEO入門の本を買ってたくらいだった。おかげで、超短期的にそのノウハウ