失敗の全責任はユーザー側に、旭川医大とNTT東の裁判で逆転判決
電子カルテを中核とする病院情報管理システムの開発が失敗した責任を巡り、旭川医科大学とNTT東日本が争っていた訴訟の控訴審判決は一審判決を覆す内容だった。 札幌高等裁判所は2017年8月31日、旭川医大に約14億1500万円を支払うように命じた。2016年3月の一審判決は旭川医大の過失割合が2割、NTT東が同8割として双方に賠償を命じていたが一転、旭川医大に100％の責任があるとした。同医大は2017年9月14日、判決を不服として最高裁に上告した。 なぜ判決が覆ったのか、裁判資料かと判決文から見ていく。旭川医大とNTT東は日経コンピュータの取材に「コメントできない」と回答した。 高裁もユーザーの義務違反を認定 旭川医大は2008年8月に病院情報管理システムの刷新を企画し、要求仕様書を基に入札を実施。NTT東が落札した。日本IBMと共同開発したパッケージソフトをカスタマイズし、6年リースで提供
「ゼルダの伝説 BotW」にバグが少ない理由
素晴らしいオープンワールドゲームならいくらでもある。「The Elder Scrolls V: Skyrim」、「ウィッチャー3 ワイルドハント」、「グランド・セフト・オートV」、「Fallout 4」など、巧妙に作り込まれた膨大なスケールのゲームは特に海外のタイトルが多いように思う。それらと比べても遜色のない国産タイトル「ゼルダの伝説 ブレス オブ ザ ワイルド」（以下、BotW）だが、他のオープンワールドゲームより優れている点があるとすれば、バグの少なさなのではないだろうか。僕はハイラルの世界を150時間以上冒険しているが、バグらしいバグに遭遇したのは片手で数えられる程度の回数しかないのだ。 では、なぜBotWはこんなにもバグが少ないのか。「何年も入念に開発してきたからだ」とか「細かいところを丁寧に作り込む日本人の職人魂が備わっているから」とか、そんな理由でも片付けられそうな気がするが
ソフトウェア開発で学んだが使わなかったもの
開発手法など、一通り学んだが実際に使っていないものは多少なりあると思う。それらについて掘り起こしてみたい。 スクラム開発認定スクラムマスター研修には研修会場ホストという立場で数回立ち会った。認定外の研修も幾つか受講した記憶がある。書籍もそれなりに読み、Scrum Gathering Tokyoなどのコミュニティにも顔を出し、まあそれなりに色々考えて捉えてきた。でも、自分のチームでは使っていない。スクラム開発というアイデアに矛盾があるからだ。 そもそもスクラム開発ではチームの自律的な行動を良しとしており、それに対する”フレームワーク”を提供しているということになっている。イテレーション、バックログ、ふりかえり、デイリーミーティング（いまだに「朝会」って言ってる人いないよね？）、そしてそれらのお作法。誰が言ったかわからないが、それぞれの作者の意図を察するためには「守」が大事らしい。守破離の「守
プログラマをクソコードで殴り続けると死ぬ - megamouthの葬列
ここにクソコードがある。 誰が作ったかはわからぬ。それが、どのような経緯でクソコードとなったのか、 あるいは、最初からクソコードであったのか、それらは全てクソコード自身が知るのみである。 ファーストコンタクト ある日、営業からシステム案件を打診されたので見積もりして欲しい。というメールが来る。 とある企業の既存システムに機能を追加する簡単な案件ですが、なななんとソースや仕様書をご支給いただけます！ と、それはサンタにプレゼントが貰えると信じて疑わぬ子供のような真っ直ぐなメールである。 ソースコードが入った圧縮ファイルを受け取ったプログラマは、早速、コードを読んでみる。 そのシステムが本当にいいコードで書かれているかを判断するには時間がかかるが、 クソコードであるかはおおよそ30分でわかる。 インデントがタブとスペースどちらかに統一されていないとか、フレームワークの誤用があるとか、またはフレ
MarkdownノートアプリInkdropで家賃の半分が賄えるようになりました
4月にInkdropの総売上が10万円を超えた報告をしてから、久々の売上報告です。Inkdropはクローズドソースですが、プロジェクトで得た知見は惜しみなくオープンにしていくつもりです。どんどんやり方パクってください。もし質問などあればコメント欄やTwitterにて受け付けます。 TL;DR驚きの解約率の低さ注文の多い少数派を相手にしすぎないブログを始めたら日本のユーザが増えた1000人のユーザが１人を食わせるモデルを確立したいInkdropはMarkdown好きのためのノートアプリ既にInkdropについてご存知の方は読み飛ばして下さい。 Inkdropはマルチプラットフォームで動作するノートアプリです。今のところmacOS、Windows、Ubuntu、iPhone、Androidに対応しています。 日々の作業記録や議事録、コードスニペットからブログの下書きまで、技術的な事柄を構文ハイ
スピード感のために品質を落とすということはチームの成長を諦めるということ - ネットの海の片隅で
サービスを開発していると、スピードが重視される。 そのこと自体にはまったく問題はなくて正当なことだと思っている。 ユーザーに対して一刻も早く価値を届けるためには必要なことだ。 そもそも、自分がいる Web 界隈ではこの点について異論のあるサービス開発者はあまりいないんじゃないかと思っている。 ただ、それを達成するための方法になると途端に意見が分かれはじめて、人によって重視することが全然違ってくる。 ある人は「スピード感が大事」と言い、ある人は「ちゃんと作ったほうがトータルでは速い」と主張する。 しかし、こういうときに意識される品質と速度についてのトレードオフは、実際には完全なトレードオフではないと思っている。 技術力のある人はある程度急いで作ったとしても一定以上の品質のコードを書くし、意図的に品質を落としたとしても速度はあまり上がらない。 逆に、技術力が高くない人が時間をかけて作ったとして
レガシーコードの触り方 / Working Effectively with Legacy Code
オープンセミナー2017@岡山
HRTの原則 〜ソフトウェア開発はバーでしっとり語り合うように 〜 : 小野和俊のブログ
「HRTの原則」という言葉をご存知だろうか。 これは書籍 Team Geek ―Googleのギークたちはいかにしてチームを作るのか で紹介されている言葉であり、本書ではほぼ一冊すべてをかけてこのHRTの原則とその実践方法とを様々な角度から紹介している。 1. 謙虚(Humility) 2. 尊敬(Respect) 3. 信頼(Trust) の3つの価値が大切にされており、エンジニアとしてもチームや組織、顧客との対話においてこれらの価値を重んじていくことが成功につながる、というものである。 あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ Team Geek p.15 プログラマとして成功するには、最新の言語を覚えたり高速なコードを書いたりするだけではいけない。プログラマは常にチームで仕事をする。君が思っている以上に、チームは個人の生産性や幸福に直接影響するのである。 Team
Panic Blog » ソースコードの盗難について
先週、動画変換ファイルアプリ HandBrake のMac版によってマルウェアに感染との報道がありました。（日本語記事参考: 動画変換ソフト「HandBrake」Mac版にマルウェア感染の危険性 | CNET Japan）2つの配信サーバのうちの片方で、感染したHandBrakeアプリが3日間公開された状態になっており、ダウンロードして起動するとそのコンピュータは攻撃者による遠隔操作が可能な状態になる、というものです。 運が悪く、さらにコンピュータ運にも恵まれず、公開されていた3日の間に感染したHandBrakeをダウンロード、起動したためにプログラマのMacが感染してしまいました。 その結果、どこかの、誰かに、私たちのアプリのソースコードが盗まれました。 続けて、以下の大切な3つについてお知らせします: ・今回の攻撃者がユーザ情報にアクセスした兆候はまったくありませんでした。 ・さらに、
あなたのおっしゃるレビューってどのことかしら？ - Qiita
ソフトウェアのレビュー ソフトウェアの開発において、レビューが品質の確保をするために有効であることは私達は直感的、経験的に理解しています。 人は間違いを犯しますし、間違った本人よりも他人のほうが誤りを見つけ易いものです。 ここまでは、認識を共通できるものでしょう。 しかし、レビューと一言で言った場合に、その実態にかなりのギャップが生じます。 ある人にとっては、気の合う同僚とコーヒーでも飲みながら成果物をチェックしてもらう事かもしれません。 しかし、別の人にとっては会議室で衆目の前で細かい所を吊るし上げられる苦行のことかもしれません。 ある人にとっては、口で簡単に説明するだけかもしれませんし、メールやツールでコメントを書くだけかもしれません。 しかし、別の人にとっては、準備の為に大量の資料を作り、終わった後にも大量の報告書を書く事かもしれません。 プロジェクトを初めて、レビューといった場合、
筋の悪さ | tech - 氾濫原
JS しか書いてないんだなって人は筋悪いものをありがたがっていたりする印象はある。しかし筋悪いものをありがたがるみたいなのはどこにでもいるので、JSがどうとかは直接は関係がないはずではあると思う。JSしか書いてない人とPHPしか書いてない人は似たようなもんで、単に広範囲の知識に興味がないだけな気がする。 それはともかく「これは筋悪そうだな」っていう感覚がどこからくるのかよくわかってないので、現時点で思いつく限り雑にメモしておく。 割の合わなさ 「これは何の問題を解決してるんだろう」と思ってドキュメント読んだりソース読んだりした結果、大したことを解決してなくて、その割に実装量が多いとか学習コストが高いと、筋悪いなあと思う。 フットプリントや学習コストに対して提供されるモノが「割に合わない」のは筋が悪く感じる。 将来性のなさ 「あ、これはただの流行だな」みたいな、5年後には消滅してるなというも
git blameによるSRP（単一責任原則）の定量化 - どこでも見れるメモ帳
はじめに ソースコードを静的解析することでSRP（単一責任原則）を定量的に算出します．*1 svn blameによるSRP算出*2を参考に、git blameによる算出をshで行ってみました． このSRP値が最大のモジュールが王様モジュールに相当します． # 単一責務性の違反指数（SRP） # SRP＝R＋U＋((L/100)－5) # R：修正リビジョンのユニーク数 # U：修正ユーザのユニーク数 # L：モジュールのライン数 function get_SRP() { local target_filepath=$1 echo $(( \ $(git --no-pager blame --line-porcelain $target_filepath | sed -n 's/^summary //p' | sort | uniq -c | sort -rn | wc -l) + \ $(
Pelletkachels | Dé Expert voor jou duurzame Pelletkachel in huis
Pelletkachels waren ooit eenvoudige apparaten voor verwarming, maar ze hebben een opmerkelijke evolutie doorgemaakt sinds hun bescheiden begin in de jaren ’80 van de vorige eeuw. In dit artikel duiken we diep in de geschiedenis van pelletkachel, bespreken we de belangrijkste mijlpalen en ontwikkelingen op het gebied van subsidiemogelijkheden en werpen we een blik op de transformatie tot moderne en
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ジャンプPAINT by MediBang - 無料のイラスト・マンガ制作ツール
https://www.binarynights.com/forklift/
Karabiner-Elements
GitHub - iMasanari/cmd-eikana: Application of macOS which switches Alphabet / Kana by pressing left and right command key alone. Other key remapping is also possible.
“エンジニア35才定年説に挑戦する” 開発チームのマネジメント
植山 類
Chibineko: The simplest test supporting tool
