弁護士・情報処理安全確保支援士 石田 優一 ２０２０年４月１日の民法改正で、システム開発者が開発したシステムに脆弱性があった場合のユーザーに対する法的責任が改められました。改正前よりも長期間にわたって責任追及を受けるおそれがあることから、システム開発者は、これまでよりも一層、システムの脆弱性に対する法的責任について理解し、適切な対策を行う必要があります。今回のコラムでは、弁護士と情報処理安全確保支援士（登録情報セキュリティスペシャリスト）の双方の視点で、民法の最新情報を踏まえた解説をいたします。 目次 第１章 はじめに 第２章 民法改正で何が変わったのか １ 民法改正前の瑕疵担保責任 ２ 民法改正後の契約不適合責任 ３ 民法改正で変わったことのポイントは？ 第３章 システムの脆弱性に対する契約不適合責任 １ 民法改正で変わったこと ２ システムの脆弱性が契約不適合に該当する場合とは ３ シ
ソフトウェアエンジニアのメンサー・デュラコビッチ氏が、ソフトウェアエンジニアを目指す学生に向けて、ソフトウェア開発の仕事に就く上で重要なアドバイス10点を自身のブログにまとめています。 10 hard-to-swallow truths they won't tell you about software engineer job https://www.mensurdurakovic.com/hard-to-swallow-truths-they-wont-tell-you-about-software-engineer-job/ ◆01：大学は仕事に必要な準備をしてくれない デュラコビッチ氏は就職に向けて大学がやってくれることを「プールに入る前に泳ぎ方を説明し、動きを覚えさせて試問まで行った上で水には決して触れさえず、5年後、泳げるという免許証を発行したのち、突然生徒をプールの中に蹴落
契約書にも民法にも書かれていませんが、「義務」なので履行してください：「訴えてやる！」の前に読む IT訴訟 徹底解説（106）（1/3 ページ） 担当者の急逝によって所在が分からなくなったソースコードを引き渡せとせまられたベンダー。契約書に記載されていない納品物を渡す義務は果たしてあるのだろうか――。 連載目次 契約に存在する「見えない義務」 仕事の契約には契約書が存在する。契約書に記載された条項を守らなければ、契約を解除されたり受け取るべき費用を減額されたりすることがあり得る。では契約書の内容を順守してさえいればいいのかというと、そういうわけでもないのがソフトウェア開発だ。 例えば、納入したソフトウェアに不具合が見つかれば修補しなければならないという「契約不適合責任」などは、契約書に規定していなくとも受注者が負うべき責任として民法の条文に書かれている。契約書というものは本来、受注者と発注
答えが分からないものを模索しながら作り続ける世界に我々は突入した。和田卓人氏による「組織に自動テストを根付かせる戦略」（その1）。ソフトウェア品質シンポジウム2022 9月22日と23日の2日間、一般財団法人日本科学技術連盟主催のイベント「ソフトウェア品質シンポジウム2022」がオンラインで開催され、その企画セッションとして行われた和田卓人氏による講演「組織に自動テストを書く文化を根付かせる戦略（2022秋版）が行われました。 講演で、企業の業績はソフトウェアの開発能力に左右されるようになってきていること、その開発能力を高める上で重要なのがコードの「テスト容易性」や「デプロイ独立性」であると和田氏は指摘。その上で、それを実現させるような「自動テストを書く文化」をどうすれば組織に根付かせることができるのか、講演の後半ではこの本質的な議論へと踏み込みます。 本記事は、2時間におよぶこの講演をダ
日本時間の2/14の朝、Apple から一つのメールが届いた。 ベッドの中で寝ぼけながら読んでいて、一気に眠気が吹っ飛んだ。2/27 より2ファクタ認証が必須になるという内容が書かれていた。これは大きな問題になるぞ…！と思ってツイートした。 おいおい、Apple Developer Programのログインに「2ファクタ認証」必須化だと？これはマジ勘弁してほしい。 他のところみたくTOTPとかならどんどんやってほしいけど、Appleさんの「2ファクタ認証」は「iCloudログイン済の信頼済Appleデバイス」必須なのがヤバい。— いせ (@iseebi) 2019年2月13日 当初はこいつはマズイと思ったが、いろいろ問い合わせたり、その後出てきた情報を見た限り、杞憂そうだとわかったのでまとめておく。 Apple ID の2ファクタ認証とは いわゆる2要素認証だが、対応するのは 当該のApp
こんにちは、株式会社Pentagonの山本です。 先日「WebサイトをWebViewを使ってスマホアプリ化したい」というお問い合わせがありました。しかし、Webサイトを単にWebViewでスマホアプリ化するだけでは、Appleの審査に落ちる可能性が高いです。 本記事では、なぜWebサイトを単にスマホアプリにするだけではAppleの審査に落ちるのか詳しく解説します。 Webサイトをスマホアプリ化！なぜ審査に落ちるのか？ App Store ガイドラインには、以下のような記載があります。 4.2 最低限の機能性 Appを作成する際は、Webサイトを単に再パッケージしたようなものではなく、優れた機能、コンテンツ、UIを作成するようにしてください。特に便利でも、ユニークでも、「Appらしく」もない場合、そのAppをApp Storeで提供することはできません。Appが継続的に楽しめる何らかの価値、
ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方 作者:Jonathan Rasmusson発売日: 2021/04/26メディア: 単行本（ソフトカバー） はじめに 2021年4月に発売されたこちらの書籍を、翻訳者の角谷さまから献本いただきました。 親しみやすい文体で短くまとまっており、楽しみながらあっという間に読むことができました。 どんな本なのか？ 「Spotifyにおける開発プロセス改善の事例紹介」だと私は感じました。「このやり方をするとユニコーン企業になれるよ」ではなく、「ユニコーン企業と呼ばれるくらい急激に成長する会社はこういう原則を心掛けておかないと成長が止まっちゃうよ」という話かと。とはいえテック企業の強さの源泉はたゆまぬ改善スピードにあり、この本で繰り返し強調されている「技術を一級市民扱いする」「チームを信じて任せる」ことは必須要件とも言えるでし
エンジニアの皆さんは、業務でさまざまな報告書を作成されていることと思います。エンジニアの業務で必要になる報告書は、大きく2種類に分けられます。 1つ目は、書式が決まっていて、定期的に作成する報告書です。定期報告書と呼ぶこともあります。進ちょく報告書や日報、週報、月報などが例として挙げられます。 もう1つは、不定期に発生するイベントについて記述する報告書です。この種の報告書は、書式が決まっていないものです。例としてはトラブル報告書（または障害報告書、問題対応報告書など）や、製品・技術などの調査報告書といったものが挙げられます。 これら2種類のうち、トラブルの種になりやすいのは、後者の「イベントについて記述する報告書」です。今回は、報告書の中でも特に細心の注意を払わなければならない、顧客向けのトラブル報告書（障害報告書、問題対応報告書）を作成するときに注意すべきポイントを説明します。 報告書を
契約書でよくある「損害賠償の額は，委託料の金額を上限とする」といった責任限定条項についてシステム開発取引を念頭に置いて考えてみた。 ※本記事は，【法務系Tips Advent Calendar 2013】の企画のもと，書いたものです。 契約書での書きぶり 例えば，経産省の情報システム・モデル取引・契約書＜第１版＞（平成19年4月）の53条（損害賠償）の2項では，次のように書かれている*1。 前項の損害賠償の累計総額は、債務不履行、法律上の瑕疵担保責任、不当利得、不法行為その他請求原因の如何にかかわらず、帰責事由の原因となった個別契約に定める○○○の金額を限度とする。 書きぶりはそれぞれ多少の違いはあれども，だいたい似たような感じで，契約金額を上限とするというような内容になっている。 契約書の文言上は，双方当事者共に責任が限定されるようになっているが，実際には何か開発作業でトラブったときにベ
ソフトウェアをライセンス販売するのではなく、インターネット経由でユーザーに提供する「SaaS」では月額あるいは年額課金の形がよく取られます。個人の開発者がSaaSでサービスを提供する場合、自分でゼロからサービスを開発することだけでなく、慣れないマーケティング活動を行う必要があり、実際に収益をあげるようになるまでの道のりは想像以上に険しいものです。会社を辞めてスタートアップを立ち上げたJon Yongfookさんはマーケティングを自動化・拡大するためのツール「Bannerbear」を開発・運営しており、収入ゼロで1年間過ごしたものの、その後、月次経常収益(MRR)1万ドル(約100万円)に達したとのことで、そこまでに至った道のりを公開しています。 Here's How I Bootstrapped a SaaS to 10k MRR - Bannerbear https://www.bann
ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第8回は、正しい要求仕様書に向けた第一歩となる「ヒアリング」について具体的な例題を使って解説します。
情報処理推進機構（IPA）は、ユーザー企業が開発ベンダにアジャイル開発手法を用いたシステム開発を発注する際の、契約書の見本などを含む「「アジャイル開発版『情報システム・モデル取引・契約書』（本版）」を公開しました。 本作はスクラムを想定したアジャイル開発を外部委託する際の、契約条項とその解説、および補足資料で構成されたもの。 IPAは本作を作成するにあたり、ユーザー企業とベンダ企業が緊密に協働しながら適切に開発を進めることができるモデル契約となるように、ユーザー企業、ベンダ企業、業界団体、法律専門家の参画を得て検討を重ねたとしています。 契約前チェックリストも 本作の作成に関わったIPAの「DX対応モデル契約見直し検討ワーキンググループは」、ユーザー企業とベンダが契約する前に、以下の2つのことを理解しておくことが必要だと説明します。 ユーザ企業及びベンダ企業が、開発に着手する前にアジャイル
Quoraでの質問に対する回答の翻訳。長らくコンピューターの世界に身を置いている人間からの、ウィットに富んだ回答。 ソフトウェア開発におけるあらゆることは、既に発明されてしまっています。人々は、それを再発見し、あたかも初めて見つけたかのようなフリをしているだけです。あなたがかっこよくて新しいと思ったものはすべて、Smalltalk、HAKMEM(訳注 : MIT AI研究所で書かれた、アルゴリズムや理論などが書かれたメモ。Wikipedia英語版)、Ivan Sutherland(訳注 : Wikipedia日本語版)、Douglas Engelbart(訳注 : Wikipedia日本語版)、初期のIBM、あるいはBell Labsからのコピーでしかありません。 コンパイラーを信じてはいけません。ツールを信じてはいけません。ドキュメントを信じてはいけません。自分のことも信じてはいけません
あるひとりの人がシステムを作ったが故にそのシステムに精通している場合に、最も生産的な開発が行われる。しかしこれは、ひとりの人がシステムの面倒を見ることを超えてシステムが成長する時には矛盾してしまう。 ある状況下において、特定の開発者たちが他の人の10倍生産性が高くなることがあるのはなぜかについて議論してみましょう。 ヒント : 開発者の話ではなく、状況が大きなカギ。 生産性が非常に高いことにウキウキした気分になるのはいつでしょうか。新しい機能が指先からあふれ出てくる時？それは、私たちが関わるツールのことを知り尽くしている時、あるいはもっと決定的に言うと、自分がシステムを変更しつつある時に起こるのです。自分のバックパック、それも自分で詰め込み、そしてひとつひとつの小袋の中まで何年にもわたる旅行を経て調整してきたバックパックの中身を知っているように、システムを知ることです。それぞれのモジュール
はじめに 小室です。2017年も最後の日になりました。 ここ最近は読書によるインプットが少なくなったことによって、文章の質が自ら目を背けたくなる程度に低下していたため、仕事納めから数日はひたすら本を読む生活をしていました。まだまだインプットが足りていないので充電が完了していないのですが、年末恒例になったエントリーを書かないことが自分の中でモヤモヤとして残っていたので、重い腰を上げて文章を書いてみようと思います。 ここ数年は珍しく1つのプロジェクトにつきっきりで設計／実装から運用までを通して担当しています。 *1特に運用を担当するようになって多くを学んだ一年でした。もはや設計・実装者が一人も残っていないアプリケーションのメンテナンス、改修に関わったり、インフラ側とアプリケーション側の狭間を埋めるように動くためにAWSのサービスについて本格的に勉強をしたりするなど、1アプリケーションエンジニア
Yukie Yamaguchi @luckystar___ メイドプログラマー。早期リタイア中←NVIDIAでゲームプラットフォーム、ロボットAIの開発←Microsoft US本社でGameやGame Engineの開発、各種MSのゲームのDev Lead←日本MSでBlueDragon,LostOdyssey,LipsのDevManagerもしてましたょ。Seattle在住 https://t.co/I79wAYD7VT Yukie Yamaguchi @luckystar___ 「New Game」見てみた。けど、これは私の知ってる日本のゲーム開発とは違いすぎる。ゲーム開発といえば、チームが内輪もめで仕事全然進まないとか。スキルが足りないからooさんを外さないといけないとか。ディレクターがクライアントに携帯投げつけるとか、そんなんですよねー。 2016-08-05 01:20:47
太田 良典 BA テクノロジー本部 システムソリューション部 HTML4.01のW3C仕様書を翻訳した「HTML4仕様書邦訳計画補完委員会」の委員を務めた後、2001年にBAに参加。Web技術の分野で幅広い専門性を持ち、セキュリティ分野においては「第二回IPA賞（情報セキュリティ部門）」を受賞。アクセシビリティ分野では、ウェブアクセシビリティ基盤委員会（WAIC）の委員として活動している。著書（共著）に「Dreamweaverプロフェッショナル・スタイル」「デザイニングWebアクセシビリティ」など。 http://www.b-architects.com http://bakera.jp/ http://twitter.com/bakera 伊原 力也 BA ソリューション・デザイン事業部 1999年よりWeb標準に則ったWebサイトの構築業務に従事。2004年にBAに参加。マークアップデ
セマンティック バージョニング 2.0.0 概要 バージョンナンバーは、メジャー.マイナー.パッチ とし、バージョンを上げるには、 APIの変更に互換性のない場合はメジャーバージョンを、 後方互換性があり機能性を追加した場合はマイナーバージョンを、 後方互換性を伴うバグ修正をした場合はパッチバージョンを上げます。 プレリリースやビルドナンバーなどのラベルに関しては、メジャー.マイナー.パッチ の形式を拡張する形で利用することができます。 導入 ソフトウェア・マネージメントの世界には、「依存性地獄」と呼ばれる恐ろしいものがあります。あなたのシステムが大きく成長すればするほど、さまざまなパッケージを組み込めば組み込むほど、自分が地獄の底にいることにいつか気づくでしょう。 多くの依存性を有しているシステムにとって、新しいバージョンがリリースされることは悪夢でしかありません。厳密に依存関係を指定し
ソフトウェア開発者はスケジュールを作りたがらない。大抵はなしですまそうとする。「出来上がったときが完成日さ！」と元気一杯見栄を切ってボスを喜ばせ、活気づいたままどこかにスケジュールは忘れ去られてしまう。 スケジュールがあるとしても、半端なものであることが多い。誰か一人によってしぶしぶ作られて、共有フォルダのどこかに置かれて、忘れ去られる。2年後、キャビネットの底で古びたプリントを見つけた人が反省会に持ってきてネタにするのだ。 「見ろよこれ。Rubyで1から書き直すのを2週間ですます予定だったらしい」 笑えるね。まだその真っ最中ならなおさら。 できることなら、やる価値のあるタスクだけに時間を注ぎたいだろう。しかし、一番やる価値のある仕事を決めるには、どの程度時間がかかるのか知る必要がある。「飛び跳ねる紙クリップ」機能と「金融計算関数を追加」機能のどちらに手をつけるか決めるには、それぞれにかか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
