並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 27 件 / 27件

新着順 人気順

細川義洋の検索結果1 - 27 件 / 27件

  • GPT-4に感動して社内業務を人工知能に置き換えようとしている取引先への報告にGPT-4を使って15分で終えた話|山本一郎(やまもといちろう)

    人工知能はものすごく進化しているけどジェネレーティブAIって割と嘘を書いてくるよなあって話は文春で書きました。ジェネリックひろゆきというニュアンスのことを書いたのですが、西村博之のほうが酷いという反響が寄せられたのは印象的でした。そんなもんですかね。 で、コロナ明けというのもあって最近は対面での打ち合わせも増えているところ、足を向けた取引先の社長がGPT-4を試しているとかでやけに感動して「これなら社内業務の足らないところを人工知能が補完するだけじゃなくて、ほぼすべてのジョブフローが人工知能に置き換えられるのでは」などと言い始め、やけに買ってるなあと思うわけですよ。 さすがにそれはちょっとなと思って「それができるなら御社が数年前に導入したサイボウズはもっとうまく稼働しているはずですし、私らみたいなサポート役のベンダーも本来は要らないのでは」という話をしたんですが、社長的にはもう一年後にはス

      GPT-4に感動して社内業務を人工知能に置き換えようとしている取引先への報告にGPT-4を使って15分で終えた話|山本一郎(やまもといちろう)
    • 全ベンダーが泣いた!――改正民法のIT業界への影響を徹底解説

      2017年5月に成立し、2020年4月から施行されている改正民法。明治29年の制定から120年ぶりの改正となる本件がIT業界に関連する項目は、主に以下の3つだ。 成果物の「瑕疵(かし)担保責任」という考え方がなくなる 請負契約において、約束した成果物を納めなくても、請負人が支払いを受けられる場合が出てくる 成果物の納品を前提とした準委任契約ができるようになる @IT eBookシリーズ 第98弾『「訴えてやる!」の前に読む IT訴訟 徹底解説 vol.4』は、上記3点の詳細とベンダーが心掛けるべきポイントを、ITトラブルが法的紛争となった事件の和解調停や裁判の補助を長年担当してきた細川義洋氏が詳しく解説する。 もちろん、皆さん大好物のIT訴訟解説も盛りだくさん。「プロジェクトが頓挫したので、18億円請求します」「その要件定義、有償だって言わなかったからタダですよね?」「アジャイルだか何だか

        全ベンダーが泣いた!――改正民法のIT業界への影響を徹底解説
      • 東証が本格的なアジャイル開発に初挑戦、富士通との準委任契約に凝らした工夫

        デジタルトランスフォーメーション(DX)の高まりを受け、企業や行政機関のシステム開発プロジェクトでアジャイル開発の導入が進んでいる。従来のウオーターフォール型ではない開発が増えたことで、ITシステム契約の在り方も変化している。契約面で失敗しないために何にどう気を付けるべきか。事例と専門家の解説からひもとく。 初めての本格アジャイル、準委任型契約で開発 東京証券取引所は2021年2月1日、アジャイル開発の手法を初めて本格的に使った新システムを稼働させた。ETF(上場投資信託)のオンライン取引システムである「CONNEQTOR(コネクター)」だ。機関投資家はCONNEQTOR上で売買したいETFの条件を入力し、マーケットメーカー(値付け業者)に対して価格の提示を依頼する。提示された価格で発注すると、証券会社経由でToSTNeT(東証立会外市場システム)に自動発注される仕組みだ。 稼働後の約5カ

          東証が本格的なアジャイル開発に初挑戦、富士通との準委任契約に凝らした工夫
        • CTOを目指すべき? 転職ニーズから考える、新時代のエンジニア生存戦略 / about IT ITエンジニアのキャリア戦略を考える

          CTOを目指すべき? 転職ニーズから考える、新時代のエンジニア生存戦略 掲載日:2019/05/28 最近耳にすることの多い、CTO(最高技術責任者= Chief Technical Officer)という言葉。転職サイトでも「CTO募集」の求人を見かけることが増えています。将来のキャリアプランとして、CTOというポジションに興味を持っているエンジニアの方も多いのではないでしょうか? なぜ今、CTOのニーズが高まっているのか。その背景をはじめ、CTOになるために必要なスキル、これからの時代に求められるエンジニア像について、政府CIO(情報化統括責任者)補佐官を務める細川義洋さんに詳しくお話を伺いました。 政府CIO補佐官というのは、行政の中でIT技術をどう生かしていくかを考え、推進することが仕事ですから、周りにはCTOのような役割を担っているメンバーがたくさんいますし、またCTOという肩書

          • 基本設計書は納品前ですが、システム作っちゃいました

            連載目次 基本契約と個別契約 今回は「契約論」に関わる紛争の例を紹介したい。 ある程度の規模のシステム開発、特にウオーターフォール型の開発では、その全体を1つの契約で行わない場合が多い。まず、プロジェクトの全体を通して大きな1つの契約を結ぶ。そこには実現すべき機能や費用などの詳細は記述されず、ただ全体としてのシステム開発を行うこと、そして機能や費用、具体的なスケジュールなどは別途契約して決めていくという程度のことが書かれている。これはよく「基本契約」と呼ばれる。 この基本契約の約束に従って作業工程を分割し、その小さな単位ごとに結ばれる契約を「個別契約」という。設計、製造、テスト――といった具合に小さな単位で契約し、検収もその単位で行うというわけだ。 大きなシステム開発の場合は、契約時点では先のことが分からず、作るべきものも費用も曖昧なことが多いので、工程ごとにそれらを決めて検収する方法はあ

              基本設計書は納品前ですが、システム作っちゃいました
            • AndroidはJavaのAPIを無断で利用してもよいのか? Oracle有利の決定にRed HatとIBMが異議

              Red Hatは2020年1月13日(米国時間)、IBMと共同で米国連邦最高裁判所(連邦最高裁)に法廷助言書を提出したと発表した。OracleがGoogleに対して起こした訴訟で連邦巡回区控訴裁判所が下した決定を覆すよう連邦最高裁に求めている。 一連の裁判は10年前の2010年8月に始まった。このときOracleがJavaの特許権と著作権を侵害しているとしてGoogleを提訴している。その後2012年に連邦地裁の判決、2014年に控訴審の判決、2016年に連邦地裁の評決、2018年に控訴審の判決が出ている。2018年の判決ではGoogleがJavaのAPIなどの著作権を侵害していると認めている。 Red Hatは、連邦巡回区控訴裁は著作権保護をソフトウェアインタフェースに誤って拡張したとしている。「これが訂正されないと、連邦巡回区控訴裁の決定がソフトウェアの互換性や相互運用性を損ない、オー

                AndroidはJavaのAPIを無断で利用してもよいのか? Oracle有利の決定にRed HatとIBMが異議
              • お任せしたのですから、契約の範囲外でも対応してください

                お任せしたのですから、契約の範囲外でも対応してください:「訴えてやる!」の前に読む IT訴訟 徹底解説(90)(1/2 ページ) ユーザーが持ち込んだソフトウェアにセキュリティの不備があった。「知らんがな」と言いたいところだが、訴えられてしまったら仕方がない。戦いましょう! 連載目次 ソフトウェアの開発契約には時々、ポテンヒットのような抜け漏れがある。発注者と受注者の役割分担を考える際に一通りの作業を網羅したのに、データ移行やテストデータの作成などをどちらが行うのか判然とせずにもめてしまい、結果、紛争にまでなってしまう例が実は珍しくない。 今回取り上げるのも、セキュリティに関するポテンヒットの例だ。発注者が第三者と契約をして提供を受けたソフトウェアにセキュリティ上の不備があった。受注者はその設定とインストールを請け負ってはいたが、当然、ソフトウェアそのものの品質やセキュリティには責任がない

                  お任せしたのですから、契約の範囲外でも対応してください
                • 製造工程に入ってるけど、やっぱこの機能も追加してくださーい

                  製造工程に入ってるけど、やっぱこの機能も追加してくださーい:「訴えてやる!」の前に読む IT訴訟 徹底解説(91)(1/3 ページ) 連載目次 IT開発を巡る裁判では、システムの要件――ベンダーがどのような機能をどこまで作るのか――についての争いの割合がかなり高い。本連載でも、そうした裁判の例を幾つも解説してきた。 ユーザー企業の「この機能を作ってくれるはずではなかったのか」というクレームに、ベンダーが「そんなことは約束していない」と反論をする。まさにIT訴訟の定番ともいうべきケースだ。アジャイル開発の割合が増えて開発中でもユーザーの要望を取り入れやすくなったといわれる今でも、こうした争いは後を絶たない。 今回取り上げるのも、「システムの要件の範囲」あるいは「契約の範囲」を巡る裁判だ。 簡単に説明すると、要件定義から開発までの全てを単一のベンダーが請負契約で行った。詳細設計中に要件の変更が

                    製造工程に入ってるけど、やっぱこの機能も追加してくださーい
                  • IT訴訟解説筆者が考える「セクシー田中さんドラマ化」問題と破綻プロジェクトの共通点――原因と再発防止案は?

                    IT訴訟解説筆者が考える「セクシー田中さんドラマ化」問題と破綻プロジェクトの共通点――原因と再発防止案は?:「訴えてやる!」の前に読む IT訴訟 徹底解説(115)_特別編(1/4 ページ) IT訴訟事例を例にとり、システム開発にまつわるトラブルの予防と対策法を解説する本連載。今回は特別編として、IT紛争の回避と解決のプロフェッショナルであり、IT小説のクリエーターでもある細川義洋氏が、「セクシー田中さんドラマ化」問題を解説する。 IT訴訟事例を例にとり、システム開発にまつわるトラブルの予防と対策法を解説する本連載。今回は特別編として「セクシー田中さんドラマ化」問題を取り上げる。「セクシー田中さんのドラマ化」を1つのプロジェクトと捉え、出版社&原作者をIT紛争でいうところのユーザー企業、テレビ局&脚本家をベンダーと位置付けてみると、ITプロジェクトの破綻と類似の原因が浮かび上がってくる。

                      IT訴訟解説筆者が考える「セクシー田中さんドラマ化」問題と破綻プロジェクトの共通点――原因と再発防止案は?
                    • 誰か、要件追加を止めてくれ!――「旭川医大の惨劇」徹底解説

                      2008年8月、旭川医科大学は電子カルテを中核とする病院情報管理システムの刷新をNTT東日本に依頼した。 プロジェクトの開始直後から、現場の医師たちによる追加要件が相次ぎ、プロジェクトが混乱した。NTT東日本は、1000近くに上る追加項目のうち、625項目を受け入れた上で、仕様を凍結(もうこれ以上要件の追加、変更は行わないと合意すること)し、納期も延長することになった。 ところが仕様凍結後も現場医師らの要望はやまず、さらに171項目の追加項目が寄せられ、NTT東日本はこのうちの136件の項目を受け入れたが、開発はさらに遅延し、期日通りにシステムを納品できなかった。 NTT東日本は「プロジェクトの失敗は旭川医大が要件の追加、変更を繰り返したことが原因だ」と損害賠償を求め、旭川医大は「NTT東日本が納期を守らず、テスト段階での品質も悪かった」と反論し裁判になった。これが「旭川医大の惨劇」のあら

                        誰か、要件追加を止めてくれ!――「旭川医大の惨劇」徹底解説
                      • セブンペイは氷山の一角!ITオンチ企業が陥るデジタル戦略の落とし穴

                        DOL特別レポート 内外の政治や経済、産業、社会問題に及ぶ幅広いテーマを斬新な視点で分析する、取材レポートおよび識者・専門家による特別寄稿。 バックナンバー一覧 不正利用問題に揺れたセブンペイが、9月末でのサービス終了を発表した。発覚直後の会見では、セキュリティー対策への認識の甘さが露呈したが、これを対岸の火事だと安心してはいられない。あらゆる業種・業態で、デジタル活用にはリスクがつきまとう。かつて東京地方裁判所・東京高等裁判所でIT専門の調停委員を務め、企業におけるデジタル活用やシステム開発の問題に詳しい、経済産業省CIO補佐官の細川義洋氏に“素人”でも気を付けなければならないIT開発の要点を聞いた。(聞き手/ダイヤモンド編集部 笠原里穂) セブンペイの開発ベンダーは 訴えられたら負ける? ――セブンペイの不正利用問題では、同社のセキュリティーへの認識の甘さや対応の遅さなどが浮き彫りにな

                          セブンペイは氷山の一角!ITオンチ企業が陥るデジタル戦略の落とし穴
                        • うまくいってもいかなくても、お金はください

                          うまくいってもいかなくても、お金はください:「訴えてやる!」の前に読む IT訴訟 徹底解説(69)(1/3 ページ) 連載目次 昨今、「レベニューシェア型」という言葉をよく耳にするようになった。 ベンダーは、ユーザー企業のために開発などのサービスを提供しても、その対価としての費用を請求しない。その代わり、発注者が出来上がったサービス(Webサイトなど)を利用して売り上げを上げたら、そのうち何割かを報酬としてもらう、というものだ。「売り上げの1割を報酬とする」場合なら、通信販売サイトで1000万円の売り上げがあれば、その1割の100万円をベンダーの取り分とする、というあんばいだ。 発注者からすれば、売り上げが上がって初めて支払い義務が発生するので、リスクがない。一方のベンダーにしても、提供したサービスが利用されている限りは、お金が入り続ける仕組みなので、それなりに魅力的な形態だ。うまくいけば

                            うまくいってもいかなくても、お金はください
                          • 「パワハラされてリストラされたので、転職サイトに書き込んでやりました」の追い解説

                            「パワハラされてリストラされたので、転職サイトに書き込んでやりました」の追い解説:「訴えてやる!」の前に読む IT訴訟 徹底解説(104)(1/2 ページ) 連載目次 2023年、あけましておめでとうございます。 おかげさまでこの連載も旧年中に100回を超え、読者の皆さまへの感謝の念に耐えない。新年を迎えこの連載が長く続けられるよう、筆者としても精進を欠かさぬよう決意を新たにしているところである。 本連載はそもそも、ITに関わる裁判が実は反面教師として実際の現場に有効な知見を与えてくれるのでは、と思い立って始めたものである。以来、途中で投げ出したくなるとか参考になる裁判例に困るとかいったことは一切なかった。しかし、書き続けるには、それなりに“元気”が必要なことも確かだった。 筆者に元気を与えてくれるのは、やはり読者の皆さまからの反応やコメントである。編集担当に送られるコメントや指摘は筆者で

                              「パワハラされてリストラされたので、転職サイトに書き込んでやりました」の追い解説
                            • 「契約不適合責任」を盛り込んだ契約書作りのポイント、教えます(サンプル付き)

                              「契約不適合責任」を盛り込んだ契約書作りのポイント、教えます(サンプル付き):瑕疵担保責任じゃダメですか?(1/4 ページ) 「ユーザーはどこまでも無限に作業を命じてくるのではないか」「受け入れ試験を真面目にやらないのではないか」――改正民法の「契約不適合責任」にまつわるベンダーの不安にお答えしましょう。 複雑怪奇なIT“業界”を解説する本連載、第1弾はIT業界にまん延する多重下請け構造と偽装請負について、第2弾は多重下請け構造が起こる仕組みについて、第3弾はシステム開発プロジェクトには複数の契約形態が混在することを、第4弾はユーザーはなぜプロジェクトに協力したらがらないのか、第5弾は「案件ガチャ」が起こるメカニズム、第6弾はベンダーの営業が安請け合いする理由、第7弾ではエンジニアの年収が上がらない理由、では第8弾と第9弾では、偽装請負の恐怖、第10弾では、エンジニアが陥りがちな「3つの地

                                「契約不適合責任」を盛り込んだ契約書作りのポイント、教えます(サンプル付き)
                              • DX(デジタル・トランスフォーメーション)って、何?

                                政府CIO補佐官。ITプロセスコンサルタント。 元・東京地方裁判所民事調停委員・IT専門委員、東京高等裁判所IT専門委員。 立教大学経済学部経済学科卒業後、NECソフト株式会社(現NECソリューションイノベータ株式会社)にて金融機関の勘定系システム開発など多くのITプロジェクトに携わる。その後、日本アイ・ビー・エム株式会社にて、システム開発・運用の品質向上を中心に、多くのITベンダと発注者企業に対するプロセス改善とプロジェクトマネジメントのコンサルティング業務を担当。独立後は、プロセス改善やIT紛争の防止に向けたコンサルティングを行なう一方、ITトラブルが法的紛争となった事件の和解調停や裁判の補助を担当する。これまで関わったプロジェクトは70以上。調停委員時代、トラブルを裁判に発展させず解決に導いた確率は9割を超える。システム開発に潜む地雷を知り尽くした「トラブル解決請負人」。2016年よ

                                  DX(デジタル・トランスフォーメーション)って、何?
                                • 社長がアホやからITがでけへん。

                                  政府CIO補佐官。ITプロセスコンサルタント。 元・東京地方裁判所民事調停委員・IT専門委員、東京高等裁判所IT専門委員。 立教大学経済学部経済学科卒業後、NECソフト株式会社(現NECソリューションイノベータ株式会社)にて金融機関の勘定系システム開発など多くのITプロジェクトに携わる。その後、日本アイ・ビー・エム株式会社にて、システム開発・運用の品質向上を中心に、多くのITベンダと発注者企業に対するプロセス改善とプロジェクトマネジメントのコンサルティング業務を担当。独立後は、プロセス改善やIT紛争の防止に向けたコンサルティングを行なう一方、ITトラブルが法的紛争となった事件の和解調停や裁判の補助を担当する。これまで関わったプロジェクトは70以上。調停委員時代、トラブルを裁判に発展させず解決に導いた確率は9割を超える。システム開発に潜む地雷を知り尽くした「トラブル解決請負人」。2016年よ

                                    社長がアホやからITがでけへん。
                                  • 親会社の意向なので開発中止します。もちろんお金も払いません

                                    親会社の意向なので開発中止します。もちろんお金も払いません:「訴えてやる!」の前に読む IT訴訟 徹底解説(68)(4/4 ページ) 関連記事 キックオフ? やってませんよ。あれは単なる“お打ち合わせ”です キックオフもしたし、メンバーも調達したし、作業も着手している。なのにプロジェクト延期だなんて、許せない!――IT訴訟事例を例にとり、システム開発にまつわるトラブルの予防と対策法を解説する人気連載。今回のテーマは「契約前作業」だ 仕様変更にも減額にも応じたのに、契約しないってどういうことですか! 多段階契約にしたがために後方フェーズの契約を取れなかった下請け企業がブチ切れた! 契約内容は都度検討するけれど、契約自体は一気通貫ですよね――IT訴訟事例を例にとり、システム開発にまつわるトラブルの予防と対策法を解説する人気連載。今回は「多段階契約における基本契約の効力」を考える その要件定義、

                                      親会社の意向なので開発中止します。もちろんお金も払いません
                                    • たった1日連絡しなかっただけで契約解除ってどういうことですか!?

                                      たった1日連絡しなかっただけで契約解除ってどういうことですか!?:「訴えてやる!」の前に読む IT訴訟 徹底解説(107)(1/3 ページ) システム開発プロジェクトの途中で認識の齟齬が発生したベンダーとユーザー企業。至急の打ち合わせを求めるユーザー企業にダンマリを決め込んだベンダーは、その後、大変なことになる。 連載目次 ベンダーからの連絡途絶で不信を募らせたユーザー企業 システム開発プロジェクトで進捗(しんちょく)などを巡ってユーザー企業との関係が悪化し、頭にきたベンダーがユーザー企業からの問い合わせや報告依頼を無視したらどうなるだろうか。 1回くらいだったらそれほど大きな問題にはならないかもしれない。しかし、要件の理解齟齬(そご)やプロジェクトの進捗などを巡ってユーザー企業とベンダーとの信頼関係が失われているときに無視されたら、ユーザー企業は大いに憤慨し、一気に契約解除までいってしま

                                        たった1日連絡しなかっただけで契約解除ってどういうことですか!?
                                      • こんなパッケージソフトいらない! だって使えないんだもん!

                                        こんなパッケージソフトいらない! だって使えないんだもん!:「訴えてやる!」の前に読む IT訴訟 徹底解説(83)(1/3 ページ) 連載目次 パッケージ導入には苦労がつきもの パッケージソフトウェアやSaaSが自社の業務にフィットしないという話は珍しいことではない。 人事や給与、販売管理、生産管理のような業務は、どの企業でも似たようなところは多いものの、決済、承認のプロセスや商品の品番、型番の体系が違ったり、生産プロセスが独自であったり、などの違いはよくあることだ。世界中で使われているパッケージやSaaSであっても、それをそのまま受け入れて業務が回る企業の方が少ないのではないだろうか。どんな場合においても、多少のカスタマイズやアドオンを行うか、業務自体を見直すなどの改善が必要なのは、むしろ当たり前のことである。 とはいえ、実際にこれらの導入を行ったエンジニアならお分かりのように、こうした

                                          こんなパッケージソフトいらない! だって使えないんだもん!
                                        • 技術的に不可能でも、セキュリティ対策は万全にしろ!

                                          技術的に不可能でも、セキュリティ対策は万全にしろ!:「訴えてやる!」の前に読む IT訴訟 徹底解説(94)(1/3 ページ) 連載目次 遅ればせながら、新年明けましておめでとうございます。 長引くコロナ禍の中ではあるが、各種業務のIT化やインターネットなどを活用した新企画など、組織のDX(デジタルトランスフォーメーション)推進が加速し、ITに関わる仕事をされている方にはより一層の期待がかかっている。 テレワークでの共同作業や人員確保をはじめとしたさまざまな困難の克服を強いられるなど、日々苦労の絶えない方が多いかと思う。しかしこれを期に日本のDXが世界にキャッチアップし、新しい利益源の開拓やコスト削減などが進むことで、国や自治体、企業その他団体がこれまでにない力と柔軟さを手に入れることも可能かと思う。2022年が皆さまと皆さまの組織にとって、実りある1年となることをお祈り申し上げる。 今回は

                                            技術的に不可能でも、セキュリティ対策は万全にしろ!
                                          • 企業も行政機関も「アジャイル開発」、契約で見過ごせない3つのポイント

                                            DX(デジタルトランスフォーメーション)を追い風に、企業も政府も新しい事業やサービスを提供するためアジャイル開発に注目している。ただアジャイル開発はそれだけで効果を得られる「魔法のつえ」ではない。専門家への取材を基に、企業や行政機関が外部ベンダーに委託してアジャイル開発を進めるとき、契約において重要となる3つのポイントを紹介する。 第1のポイント:定量的で具体的な目的を書く 最も重要なポイントは「契約の目的」である。「将来の新しい業務でどんなメリットを得たいのか、定量的で具体的な目的を契約に書き込む必要がある」。システム開発を巡るユーザー企業と開発ベンダーの紛争に詳しいITコンサルタントで、政府CIO補佐官も務める細川義洋氏はこう強調する。 細川氏は「アジャイル開発では、目的の達成に必要な機能が途中で変わってもよい」と続ける。例えば、EC(電子商取引)サイトを開設している企業が1年後に高齢

                                              企業も行政機関も「アジャイル開発」、契約で見過ごせない3つのポイント
                                            • 派遣は工程表を作っちゃダメなんですか!?

                                              派遣は工程表を作っちゃダメなんですか!?:「訴えてやる!」の前に読む IT訴訟 徹底解説(73)(4/4 ページ) 自分の作業と契約タイプの整合性に注意 しかしこうした判決もある以上、ベンダーの人間は、「自分たちが日々行う作業が、契約のタイプに合致しているのかどうか」を考えながら、作業せねばならない。 請負契約ではないのに、ユーザーから「私たちはよく分からないので、スケジュールを書いてください」と依頼されたら、簡単に受けてはいけない。 「分からないところはアドバイスするので、そちらで書いてほしい」「ミーティングをして一緒に作りましょう」「こちらで作業責任を持つことになるので、契約タイプを考え直してください」などを、ユーザーに対して提言をする必要がある。 スケジュール以外にも、「成果物を明示してほしい」とか、「費用を成果物ベースで計算してほしい」などと依頼をされても、同じように対応する必要が

                                                派遣は工程表を作っちゃダメなんですか!?
                                              • 【大規模接種予約サイト】不具合について考えてみました - 心はいつもどまんなか。by tadashian

                                                こんにちは、そして、こんばんは、ただっしゃん(@tadashian1)です。 当ブログにお立ち寄り頂き、誠にありがとうございます。 ***近所の内科の個人病院では65歳以上のコロナワクチン接種の予約がスムーズ行われてる(高齢化率高いけど田舎なので絶対数が少ない)みたいで少し安心の今日この頃です*** 架空番号で予約可能⁉ 工程を踏んで、設計・開発・製作したのか スムーズにスタートして欲しかった 架空番号で予約可能⁉ 驚きました。 大規模接種予約サイトで架空番号でも予約可能になることに。 日本はまさにコロナワクチン接種が本格的に始まろうしているただ中にあります。これは、そのスタートダッシュからズッコケた格好です。 xtech.nikkei.com 日経クロステック 2021年5月17日付け記事より 防衛省が2021年5月17日に開設した新型コロナウイルスワクチンの大規模接種会場向けの予約サイ

                                                  【大規模接種予約サイト】不具合について考えてみました - 心はいつもどまんなか。by tadashian
                                                • 私のふんどしで相撲を取らないでください

                                                  私のふんどしで相撲を取らないでください:「訴えてやる!」の前に読む IT訴訟 徹底解説(82)(1/3 ページ) 連載目次 他人のデータで商売ができるか? インターネットに公開されている情報を収集し仕事や家庭生活で利用することは、今やすっかり一般的となった。 ネットを少し検索すれば、さまざまな製品、サービスのマーケット情報を即座に見つけられるし、世界中の政府や自治体が「オープンデータ」という潮流の中で自らが保有する各種のデータを無償で提供している。 そのようなサイトから集めたデータを整理したり、市場分析や顧客台帳整理を行ったり、あるいはさらなる分析を加えて有償で不特定多数の人間に提供するようなことも行われている。無論、これらは元データの提供者の許諾があれば問題のない行為だし、読者の中にもこうしたデータ収集と活用をしている方も少なくないのではないかと思う。 では、活用されるデータを公開してい

                                                    私のふんどしで相撲を取らないでください
                                                  • 製造工程に入ってるけど、やっぱこの機能も追加してくださーい

                                                    製造工程に入ってるけど、やっぱこの機能も追加してくださーい:「訴えてやる!」の前に読む IT訴訟 徹底解説(91)(3/3 ページ) 東京地方裁判所 平成31年3月26日判決から(つづき) (本件システム開発はウオーターフォール型であるので)作業の範囲は、直前の工程の成果物により定められることになり、(中略)詳細設計以降の工程については、新要件定義書(中略)に基づいて実施され(中略)不完全な旧要件定義書などに基づいて締結された個別契約によって開発の範囲が画されるものでないのはいうまでもない。 (中略) 被告は、要件定義など請負契約において、これらの業務を定額の代金で一括して請け負ったものである以上、その範囲内にある作業を実施する限度においては、それが当初の想定を上回るものであるとしても、直ちに契約の範囲外のものということはできず、これについて追加代金が発生することにはならないと解する。 裁

                                                      製造工程に入ってるけど、やっぱこの機能も追加してくださーい
                                                    • MoSCoW分析(モスクワ分析)とは何か?その意味と使い方と解説 | Promapedia(プロマペディア)

                                                      MoSCoW分析とは、要件定義の際に使用される分析手法の1つで、要件をMust(対応必須)、Should(対応すべき)、Could(できれば対応)、Won’t(対応不要)という4つの分類で評価し、プロジェクトで対応する要件の優先順位を決める方法です。 MoSCoW分析という名前の"M"、"S"、"C"、"W"はそれぞれ"Must"、"Should"、"Could"、"Won’t"から来ており、発音しやすいように"o"の文字が加えられ、ロシアのモスクワの英語名“Moscow"と同じ綴りにしています。 MoSCoW分析はなぜ必要なのか?ソフトウェア開発などのITプロジェクトでは、発注者やユーザーからいろいろな注文を付けられて、開発側が混乱してしまうことが多々あります。 そうしたプロジェクトのトラブルを防ぐために、このプロジェクトで何を対応するのかを明確にしておく必要がありますが、その際に使われ

                                                        MoSCoW分析(モスクワ分析)とは何か?その意味と使い方と解説 | Promapedia(プロマペディア)
                                                      • 江里口美咲&細川義洋対談「ここがダメだよ、IT業界!」

                                                        江里口美咲&細川義洋対談「ここがダメだよ、IT業界!」:「訴えてやる!」の前に読む IT訴訟 徹底解説 連載100回記念スペシャル(1/5 ページ)

                                                          江里口美咲&細川義洋対談「ここがダメだよ、IT業界!」
                                                        1