電子カルテを中核とする病院情報管理システムの開発が失敗した責任を巡り、旭川医科大学とNTT東日本が争っていた訴訟の控訴審判決は一審判決を覆す内容だった。 札幌高等裁判所は2017年8月31日、旭川医大に約14億1500万円を支払うように命じた。2016年3月の一審判決は旭川医大の過失割合が2割、NTT東が同8割として双方に賠償を命じていたが一転、旭川医大に100％の責任があるとした。同医大は2017年9月14日、判決を不服として最高裁に上告した。 なぜ判決が覆ったのか、裁判資料かと判決文から見ていく。旭川医大とNTT東は日経コンピュータの取材に「コメントできない」と回答した。 高裁もユーザーの義務違反を認定 旭川医大は2008年8月に病院情報管理システムの刷新を企画し、要求仕様書を基に入札を実施。NTT東が落札した。日本IBMと共同開発したパッケージソフトをカスタマイズし、6年リースで提供

気になる記事をスクラップできます。保存した記事は、マイページでスマホ、タブレットからでもご確認頂けます。※会員限定 無料会員登録 詳細 ｜ ログイン 電力広域的運営推進機関（広域機関）は2017年6月に、ある報告書をまとめた。全国の電力網の司令塔ともいうべき「広域機関システム」の開発トラブルを総括したものだ。 広域機関は外部の専門家による第三者評価委員会を設置して、報告書を作成。プロジェクトの実態をつまびらかにした。そこには、システム開発を発注した広域機関と、受注した日立製作所の混乱の様子が記されていた。電力小売り全面自由化のスタート時に混乱の火種となった同システムの開発は、希にみる“凄惨”なプロジェクトだった。 システム開発にトラブルは付きものだ。プロジェクトの実態と、広域機関の対策を他山の石としたい。 関係者35人、計70時間のインタビューで実態を明らかに 広域機関システムは、電力の安

株式会社プラムザ 代表取締役社長。システムコンサルタント。1998年に28歳で起業し、現在も現役のシステムエンジニア、コンサルトとして、ものづくりの第一線で活躍しつつ、開発現場のチームとそのリーダーのあり方を研究し続けている。 基本的にほぼ100％、社内のプログラマだけで開発を行っている弊社ではありますが、時折どうしてもリソース不足を起こすことがあります。 特にここ1年ほどは、消費税増税に伴ってシステムをフルリニューアルしようというようなお話が多く慢性的な製造力不足に悩まされております。 そんな時は外注の開発会社さんにお仕事をお願いするのですが、これがまあなかなか難しく、これまで結構失敗を重ねてきました。 今回、不肖わたくしめが「たぶんこれが正解じゃないか？？」という案を考えましたので、ここにご提案します。同業者の方々にとりまして何かヒントになれば幸いにございます。 □外注さんとうまくやる

SEは「顧客の担当者との良好な関係作り」を決して疎かにしてはならない。SEと営業の関係についてはこれまで色々と書いてきたが、SEにとって顧客の担当者との関係は、営業とのそれと同様に極めて重要である。いかにSEが技術に強くとも、両者との関係がぎくしゃくしていると良い仕事ができないからである。 IT業界ではSEの能力を論じる時に、往々に「ITスペシャリスト」とか「PMBOK」とか「〇〇資格」などと技術的側面を重視する傾向にある。だが両者（顧客の担当者、営業）とSEの関係は、それ以前の重要な問題である。IT企業やIPA（情報処理推進機構）や有識者の方々は、資格・スキルを論じる前に、SEと営業、SEと顧客の関係にもっと目を向けるべきだと筆者は思う。そうでないと顧客軽視・ビジネス軽視・技術偏重のSEを増やすだけである。 筆者には、それが今の日本におけるSEの現状のようにも思える。ちょっと言い過ぎかも

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

システムの寿命が延びている。最新の結果では14.6年で、この5年で約1年伸びた。一方、システム構築プロジェクトの成功率は高くはない。500人月以上のプロジェクトでは、40.5％が工期遅延、34.8％が予算超過、26.2％で品質の不満、に遭遇している。IT投資評価についても課題が多い。 ビッグデータやクラウドなど、ITのトレンドは目まぐるしく変わる。一方で、事業の根幹を支えるシステムは、そう簡単にスクラップ＆ビルドできるものでもない。中期的な視点でIT戦略を立案・実行する必要がある。 前回はクラウドやポストPC端末といった新しいITの導入状況について紹介した。今回は視点を、企業の基幹系システムに移し、システムの寿命やシステム構築プロジェクトの成功率、IT投資評価の実態などについて見ていこう。前回同様、日本情報システム・ユーザー協会が実施した最新の調査結果「企業IT動向調査2012」（調査概要

SIerの会社で、自社用のシステム開発をすることがありますよね。勤務管理のシステムとか。そして、有能な人材はみんな外向けの仕事で出払ってしまって、「残り物の人」で開発して、プロジェクトが失敗しちゃうってケースがよくあるように思います。で、そうやって出来上がってしまったクソシステム、捨てちまえばいいのに無理矢理使うことが世の常だと思います。そうなってしまうのは担当者のメンツを守るためであったり、現場の苦労を上役が理解していないためであったり、といった様々な理由があると思います。ですが、会計的な意味でも「クソシステムをどうしても使わなければならない」という理由があります。説明しましょう。 使わないと損失が明るみに出てしまう 上に書いた「クソシステムを無理矢理使わなければならない会計的な理由」とは、そのクソシステムを使わない場合は「減損処理」をしなければならないということです。 例えば、そのクソ

ソースコードのなかでバグが多いのは、より高頻度に、かつ最近になって集中的に直している部分。これが、グーグルで採用された「バグ予測アルゴリズム」であることを、先月の記事「グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している」で紹介しました。 そのバグ予測アルゴリズムを実装したツール「bugspots」がオープンソースとして公開されています。 gitのレポジトリを分析 bugspotsはRubyで記述されており、gitのレポジトリから履歴を読み込んで分析し、どのモジュールにバグが含まれている確率が高いかを示してくれます。 以下のようにインストールして実行（説明ページから引用）。 $> gem install bugspots $> git bugspots /path/to/repo $> git bugspots . # (in current git directory)

このエントリーは「Software Test ＆ Quality Advent Calendar 2011」における12/18分として書いています。 12/17は @NoriyukiMizuno さんによる 「ソフトウェアテストの勉強会。1年目。」 というエントリでした。 今回は、以前から感じている矛盾について、私なりの考えをまとめたものです。 特に、マネージャーや経営層と呼ばれる人に読んでもらいたいと思っているのですが、このブログの読者層を、考えると、あまり多くはなさそうなので、以下に示す問題について、悩んでいる／苦しんでいるような人から、うまく伝われば良いと思っています。 矛盾する問題 私は、SEPG（Software Engineering Process Group）という役割上、いろいろなソフトウェア開発のプロジェクトや組織に関わってきました。 絶対数で言えば、そんなに多くはない

ソフトウエア・エンジニアリングのリーダーの一人、エド・ヨードンは1992年に、『Decline and Fall of the American Programmer 』を著し、米国のソフトウエア産業の衰退と挫折を警告した。この本を出す少し前まで、彼は「この国が危ない（A Nation at Risk）」というタイトルで講演行脚をしており、同書はそれをまとめたものである。 この本の中で、ヨードンは日本をソフトウエア開発における優等生の一人として挙げ、インドの飛躍を予見している。本が書かれた時点では、インドのＩＴ産業はまだ黎明（れいめい）期にあったが、彼の予想通り、現在は英語圏で質の高いソフトウエア開発力が得られる国として、欧米から頼られる存在になり、ＩＴ立国を目指す他のアジア諸国からお手本と見なされるまでになった。 「この国が危ない」というヨードンの警告に触発されたのか、米国上院の「米国の

「2007年からソーシャルゲームを提供してきたGREEにおける、技術的な側面での失敗と成功の実例を通じて、そのノウハウや必要な技術について解説します。合わせて、それらの経験に基づくGREEから提供していくフレームワークであるGREE Technology Stackについてもご紹介します」ということで、CEDEC2011にて講演された「GREEソーシャルゲーム5年間の技術的失敗と成功の歴史　～GREE Technology Stackのご紹介～」はかなり濃い内容となっており、グリーの開発本部 取締役 執行役員CTO 開発本部長である藤本真樹氏と、同じくグリーの開発本部 インフラ統括部 アプリ基盤チーム リーダーの梶原大輔氏による話が次々と展開されていきました。 注目度も非常に高く、人だらけ。 今回はこの講演を発表の場にいる感覚で読んでもらえるように、当日の発表資料と合わせてまとめてみました

ときどき人からこんなことを言われる。 「〇〇ってソフト、欲しいんだけど高いんだよね〜。もっと機能は絞ってもいいからさ〜、お宅で安いの作ってよ〜。」 こんなとき私の受け答えはいつも歯切れが悪い。 「え、あ、うーん・・・貴重な意見ありがとうございます・・・」 〇〇に入るのは3DCGとか3DCAD関係のソフトで、大抵はン百万というお値段のもの。 こう言われることもある。 「〇〇ってソフト、高いんだよね〜。もっと機能を絞った廉価版を出してくれればいいのにねぇ？」 やっぱり私の受け答えは歯切れが悪い。 「え、ええまあ、そうですね・・・」 廉価版はね、たぶん出ないと思うのですよ。残念ながら。 ソフトウェアというのは、コピーにかかるコストはゼロ。つまり製造コストはゼロ。 当然ですね。 つまり当然ながら、機能を削ったところで製造コストは変わらない。 しかしこの当然のことが、一般的な直観とはズレるところがあ

システムインテグレータ（SI）のビジネスは大きく以下のような流れで進みます。 集客 営業 要件定義 製造 検収・請求 フォローアップ 集客 どんなビジネスでも同じですが、まずは見込み客を集めます。システム開発に興味を持ったお客様を探しアポイントを取ります。よく使われる手法に商品・サービスの説明をするテレアポ、割引を謳ったDM、自社の推す技術のセミナー、役員が個人的に懇意にしている既存顧客の紹介があります。会社の規模やブランドにマッチした手法を選ぶ必要がありますが、会社が成長にするにつれ手法を変えていかなければいけないのが難しいところです。 営業 アポイントの取れたお客様に顧客に直接、自社の提供するサービス、商品の説明を行います。また会社の紹介も同時に行います。お客様がある程度の金額を掛けてソフトウェア開発を行いたいと意思表示をされた場合に次の段階に入ります。そこで現状の課題を聞き出します。

注文住宅を建てるときのお値段。 もちろんピン・キリありますが、 まぁ普通レベルで坪60万円として、 建坪 33坪 ( 110m2 ) の家を建てると、 ざっと 2000万円です。 ところで、 2000万のうち、 設計費用は幾らぐらいでしょう? だいたいの標準としては、 設計士 29人・日くらい掛かり、 100～150万円といったところなんだそうです。 ※ 参考: 辻建設一級建築士事務所 - 標準業務人・日数 ※ 実際には、 それでは高いと言われるのでしょうか、 一括請負の見積書の場合はそれよりかなり低い内訳金額が提示されることが多いようです。 ちなみに、 今の家を建てたとき、 たしか 50万円だったと記憶してます。 さて、 ソフトウェア開発のお値段。 業務用のアプリケーションをゼロから開発すると、10画面くらいのもので、 1500万円くらいです。 「へぇ～、 十数画面くらいのアプリと、 家

東京証券取引所の新株式売買システムの刷新という大規模な開発プロジェクトの背景と、成功要因を、東証の担当者自身が説明したプレゼンテーションを記事にした「客が本気にならないといいシステムができない。東証arrowhead成功の鍵とは ～ Innovation Sprint 2011」は公開から3日後の現在、過去1週間でもっとも読まれた記事の第1位になっており、たくさんの反響をいただきました。 客が本気にならないといいシステムができない。東証arrowhead成功の鍵とは ～ Innovation Sprint 2011 － Publickey 記事で取り上げたarrowheadの開発は巨大なウォーターフォール型のプロジェクトであり、その成功の鍵として主に挙げられていたのは次のようなことでした。 関係者全員での危機意識の共有 発注者責任の明確化 上流工程完璧主義 しかしこの成功の鍵には、語られな

客が本気にならないといいシステムができない。東証arrowhead成功の鍵とは ～ Innovation Sprint 2011 2010年から東京証券取引所で稼働を始めた新しい株式売買システムのarrowhead（アローヘッド）は、高速化が進む世界の証券取引所の中でも世界トップレベルのレスポンスを達成したと伝えられています。 そのarrowheadのプロジェクトはどのように運営されていたのか、そしてトラブルなくシステムが稼働した成功の背景に何があったのでしょうか？ 1月14日に都内で行われたイベント「Innovation Sprint 2011」で、東証側のシステム構築担当者だった宇治浩明氏が講演を行いました。 世界の高速化競争とトラブルによる危機感が背景に 東京証券取引所 株式売買システム部長 宇治浩明氏。1年前に投入した東証の新しい株式売買システム「arrowhead」は、それ以前に

私自身は10年以上も前（JDK1.1の頃）にSJC-Pの認定を取って以来、Javaプログラミング関連の認定試験は受けていないのですが、昨日たまたまネットを検索して、SJC-Pとは別にJavaプログラミング能力認定試験という試験が存在していることを知りました。結構メジャーな認定試験のようですので、現役のJavaプログラマーやJavaプログラマーを目指している学生さんで、今後受験に向けて勉強されている方々も多くいらっしゃるのではないかと思います。 試験は難易度に応じて3級から1級までランクが分かれており、2級まではJava言語の知識に関する筆記試験ですが1級の試験では実際のプログラムの修正を行う能力が実技試験として課せられます。試験範囲は以下で公開されています。 Javaプログラミング能力認定試験（試験範囲） 私は（自分で言うのも変ですが）、Javaプログラミングについてはこの道15年近くのキ

統計や実証を通してソフトウェア工学を研究していく、それが「エンピリカルソフトウェア工学」（Empirical Software Engineering、実証的ソフトウェア工学）です。「第一回エンピリカルソフトウェア工学研究会」が、12月10日に都内で開催されました。 基調講演では、マイクロソフトリサーチで研究をしているDr. Thomas Zimmermann氏が登壇。開発組織の構造がソフトウェアにどう影響するのか、バグ報告書やバグ報告者と修正されるバグの優先順位の関係、そしてエンピリカルソフトウェア工学という「データ指向のソフトウェア工学」を、どのようにソフトウェア開発における意志決定に役立ていくのか、といった内容の講演でした。 開発組織の構造がソフトウェア品質に及ぼす影響は？ マイクロソフトリサーチのDr. Thomas Zimmermann氏。 今日はいくつかのテーマについて紹介した