システム開発の契約が民法改正で変わる
民法の契約に関する内容が、120年ぶりに改正される。明治時代に制定された法律が現在まで変わらなかったというのも驚きである。当然ビジネス形態やそれを取り巻く環境は大きく変わり、現状に沿った改正がなされることになった。民法は私たちの生活やビジネスに直結するため、大きな影響が予想される。 改正案は2015年に既に通常国会で審議され、2017年度の国会で可決されれば2019年頃に施行される見込みである。施行までに期間が空いているのは、周知に時間がかかり、かつ影響が大きいことを示している。 民法が改正される点は約200項目あり、その中でもIT業界はシステム開発委託契約が大きく変わると見られている。委託契約が多いIT業界においては広範囲で影響を及ぼす可能性があるため、事前にどのようなものか把握し対応する必要があるのである。 ※2016年7月22日に公開した記事ですが、リライト記事に必要な文言等を一部追
20万人月の作業を1人でやる話 〜1万7千年生きたSE〜 - 特別天然記念物
昔々、具体的には約1万7千年前の旧石器時代、大学の情報工学科を卒業して、新卒22歳でSIerに就職した男(以下SE)がいました。 SEはある日、上司に言われました。 「2016年くらいに、銀行で大規模な基幹システムが必要になるらしいから、今から君一人で作り始めて。工数は20万人月ね。」 そういうと、上司はシステム企画構想やそれに伴う提案書、ノートPCを1つSEに渡して、自分は狩りに出かけました。 途方にくれるSE氏、ここから彼の約1万7千年(1万6666年)にも及ぶ、20万人月のシステム開発が始まるのでした。 約1万7千年前 |- 要件定義書を作成着手。 | 周りの人達は狩りをしながら生きている。 | 約1万6千年前 |- 要件定義書の作成が完了する。 | 基本設計に着手する。 | 土器を作り始める人が現れる | 徐々に日本列島が大陸から離れ列島になっていく。 | 約1万4100年前 |-
続・拝啓『変わらない開発現場』を嘆く皆様へ ～ ウォータフォール ＆ アジャイル編～ – とあるコンサルタントのつぶやき
とあるコンサルタントのつぶやき とあるコンサルタントのつぶやき MCS （Microsoft Consulting Services） の某コンサルタントがまったり語るテクノロジのお話です。 ご存知の方も多いと思いますが、ここ最近、うちの会社の歌って踊れる DevOps エバの牛尾さんが、こんなエントリを書かれていました。 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い http://simplearchitect.hatenablog.com/entry/2016/06/20/080807 「自分で人生を決めない」ことが、決定的に業界の進化を遅らせているのかもしれない http://simplearchitect.hatenablog.com/entry/2016/06/24/080049 特に前者は炎上気味でしたが；、二回分のエントリを通して読めば、牛尾さんが言いたい
日本でアジャイルが流行らない理由 - @ledsun blog
ポジション的なもの 個人的に、アジャイルは「（あんまり未来や遠くのことを考えるのをやめて）目の前にある問題を解決しよう」という思想と認識しています。 現実の問題を見ないで「将来、日本と米国のソフトウェア開発技術の差が広がるから、ウォーターフォールをやめてアジャイルをやろう」とか、何を言っているんだ、おまえは？ と、思います。 キーワード「エンタープライズ」が出てきているので、業務システムの話をします。 情けないぞアジャイルコーチ 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログを読みました。 感想を書きます。 サム・グッケンハイマーの一言 サム・グッケンハイマーは、マイクロソフトが、アジャイル、そして DevOps 移行したことに関するソートリーダー の方が 「ウォータフォールは一切メリットがないので止めておきなさい」 といったそうです。まあ、ポジシ
エンジニアのための法律勉強会 #3『判例に学ぶ、納期遅延と瑕疵担保責任についての注意事項』参加メモ
gistfile1.md エンジニアのための法律勉強会 #3『判例に学ぶ、納期遅延と瑕疵担保責任についての注意事項』参加メモ 日時: 2015-04-123 19:15-20:50 講師: 野島 梨恵氏 (東京山王法律事務所) 場所: Co-Edo http://bit.ly/co-edo-2015-04-23-doc 初参加の方が半分くらい みなさんからもいろいろ教えて下さい エンジニアとは考え方が違う 裁判所は何を考えているのか 法律家はどういう思考回路をたどるのか 法律家はシステム開発に関しては素人 弁護士の99%は素人 裁判官はもっと素人 検察官はもっと素人 システム開発に詳しい検察官は見たことがないw 今回の題材 東京地方裁判所平成25年11月12日 平23 (ワ) 28556号 裁判所、弁護士、検察が非常に苦労したということが如実にわかる判決 2年がかりの裁判 判決の原告被告が
ほんとうに便利だった業務で使えるJava SE8新機能（JJUG CCC 2015 Spring）
メリット1: 複数人による共同作業 メリット2: ウェブサービスへのコミット デメリット1: サーバー負荷 デメリット2: コードを共有しない貢献がしにくい
プログラマとして30年以上の経験から得た教訓 | POSTD
私は、プログラマとして30年以上仕事をしてきた中で、学んだことがあります。そのいくつかを以下にご紹介します。もっと挙げることもできますよ。 実物を見せないと、顧客の希望は分からない。 このことは最初の仕事で学びました。顧客は、実物を見るまでは、何が本当に必要なのかがよく分かりません。言葉で長々と説明するよりも、機能検証のためのプロトタイプを提示する方が確実に役立ちます。 十分な時間があれば、あらゆるセキュリティは破られる。 現代社会において、セキュリティを保つことは信じられないほどの難題となっています。プログラマは常に完璧を求められますが、ハッカーは1回でもハッキングができれば成功なのです。 セキュリティが破られた場合、事前にその状況に備えた対策を講じているかどうかで結果が変わってくる。 最終的にセキュリティが破られることを想定する場合、その時に起こることに備えて対策を立てておく必要があり
技術的負債を管理する
1992年にWard Cunningham氏が、技術系ではないステークホルダにこの問題を伝えるために、初めて「技術的負債」というメタファを使いました。品質の低いコードと自動テストによるカバレッジがないことは、財務的負債と比較されます。このようなコードは、開発者だけでなく、すべてのステークホルダが負う財政的な重荷になり、将来的に利息が課される負債になります。元本額は、コードベースを将来簡単に変更できるようにリファクタリングするコストです。利息は、チームがよいコードではなく、汚いコードに取り組まなければならない場合に、将来支払う余分なコストです。 財務的負債とは違い、技術的負債は返済しなくてもよい負債です。時には、返済するのが無駄なこともあります。ある部分のコードを読んだり、変更したりすることはめったにないか、決して起こらないかもしれません。そのため、技術的負債も、どのくらい起きそうかを考慮す
SIerでのキャリアパスを考える勉強会に参加してきた : 小野和俊のブログ
このところ「SIerの今後について」というテーマについて、意見を求められたりディスカッションしたりすることが多く、またエンタープライズ業界に身を置く立場として、売り上げ比・人口比とも業界の大半を占めるSIerが今何に取り組んでいて、今後どのようになっていくのか、というのは私自身関心のあるテーマなので、昨日は「SIerでのキャリアパスを考える」勉強会に参加してきた。 というわけで勉強会の中で印象的だったことや考えたことを書く。 勉強会の前半パートではゆもとさんによるSIerの現状分析、ひがさんによるSIerの中でのキャリア戦略が話題に上り、その中でも特に「上流と下流が工程分断されている」ことが現状のSIerを取り巻く諸問題の元凶、という指摘があった。 この「分断」については、中島聡さんの「ソフトウェアの仕様書は料理のレシピに似ている」というエントリが有名だが、今回の勉強会でのゆもとさんの資料
「無理です、ダメです、できません」＋「仕様です」で済ませないように・・・（追記あり）：田中淳子の”大人の学び”支援隊！：オルタナティブ・ブログ
わが「心の師匠」の一人に元SEの方がいらっしゃって、今、50代半ばの彼が20代のばりばりSEだったころの話。 お客様との打ち合わせで、「こういうことしたいんだけど」と言われると、つい「あ、それ、無理です」と反応し、「こんなことはできるのかな？」と言われれば、「ああ、ダメですねぇ」と答えてしまったのだそうです。 しばらくは辛抱強く相手をしてくださっていたお客様が、とうとうキレて、 「私たちは、コンピュータに関しては素人だ。だから、技術的にできるかどうかなんかわからない。でも、”したい”ことはある。あなたたちSEは、私たちが”したい”ことをどう実現するかを考えるのが仕事ではないのか。”こうすればできる”とか”こういう風に条件を変更できませんか?”とか言ってくれれば、こちらも考える。どういう風に問題解決をするか、共に考えてほしいと思って、こうやって話をしているのだ。 だから、二度と”できない”と
ソフトウェア技術者軽視のシステム開発を続けるのはもう限界かもしれない - 達人プログラマーを目指して
つい先日、富士通がグループで抱える3万人ものSEを再教育して、職務転換を行う計画であるというニュースを知りました。 富士通の3万人SE職務転換大作戦は成功するのか？ - GoTheDistance 一つのシステムを複数の企業などが利用するクラウドサービスがこのまま普及すれば、顧客の要望を聞いて個別システムを作り込むＳＥは仕事がなくなり、余剰人員問題が顕在化するからだ。 クラウドの普及により、オーダーメイドでシステムをゼロから構築する必要がなくなり、そもそも顧客からの要件をまとめてシステムを設計するSEの仕事が不要になったり、基盤を構築、運用するエンジニアが不要になるということは、最近になってよく言われることであり、特に新しいことではありません。もちろん、クラウドの普及によって、これらの伝統的なSEの仕事が少なくなり、人員が余るという議論は間違いではないと思います。 ただし、一方でより本質的
人月計算とExcelとスーツの世界より
俺の住む世界はアイティーとやらに支えられているらしい。 アイティーに関われば、俺の住む世界をさらに素敵なものにしていけるに違いない。していきたい。 そう願って、何も知らなかった文系新卒の俺が金融系のシステム会社に入って、もう一年以上が経つのだ。 昔、お遊びでゲームを作ったことはあった。RPGツクールなんかが好きだった。 だから自分はシステム会社に向いていると思った。 実際、資格取得を勧められて始めた勉強は楽しかった。 浮動小数点数、オートマトン、SQL、スタック、木、論理式。 パズルみたいで楽しかった。コンピュータの中身が理解できて、わくわくした。 楽々と基本情報技術者の資格を手にし、半年後にはほとんど勉強もせずにソフ開も取得した。 研修の課題では同期の誰よりも速く、短く効率のいいソースを仕上げた。 現場に出て、本番機に触った。 ３０年間親会社を支え続ける偉大なシステムの中身を、わくわくし
ソフトウェア開発に本当に必要なものは人手か？ | Social Change!
当たり前のことなんですが、100人月のソフトウェア開発があったとして、100人投入したからといって1ヶ月で出来る訳がないですよね。なのに、そのパラメータは可変だと信じている人がまだまだ多いです。しかも、1人月のバラツキをなくすために生産性の低い方に揃えるなんて馬鹿げています。私はソフトウェア開発で最も重要なパラメータは「期間」だと考えています。かける工数の時間ではなくて、あいた時間も含めての期間です。 SonicGardenでは月額定額のサービス型の受託開発を行っています。その詳しい説明は別の機会にしますが、ポイントは月額定額という点です。月額定額なので、可変できるパラメータは「期間」だけになります。そのポリシーの背景には以下の考え方があります。 ・アジャイル開発のボトルネック ・Publickey「納期を半分にしてくれ、金なら出す」 大規模なソフトウェアを作るには、大人数が必要と考えがち
ここギコ！: なんかプロプライエタリって馬鹿みたいだな
今の仕事はプロプライエタリなソフト中心で組むしかないのだが、なんか端っことはいえオープンソース中心でしばらくやって来た身としては、ほんまに馬鹿馬鹿しいなと思うことがしばしば。 上司なんかがいうには「何か問題があった時にサポートも効かない、サポートを任せる先がないようなオープンソースソフトなんてリスクが高くて使えない」という事だし、別の課長も言うには、「どうしても他のソフトの前提なんかでオープンソースを使わざるを得ないところは、そのソフトに関する不具合なんかの問題はうちで責任取らない旨、客先で明確に示しとかないといけないぞ」とか言われるんだけども。 なんか構成組んでると、プロプライエタリなソフトの方がよっぽどリスクだらけちゃうの？わざわざクソ高い金払うのに、と思えてくる。 まず危ないよなーと思うのが、とりあえず機能を前もって試せない事。 そりゃ試用版とかもあるにはあるが、全ての機能が使
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
"費やした55億円、水の泡に 特許庁がシステム開発中断"って一体何だったのか、報告書を読んでみた
Press Enter■
その一方で、ウォーターフォールの現場にて開発者が出来ること
http://chikura.fprog.com/index.php?UID=1186110219