サンプル例に見る機能仕様書の基本的な書き方＆読みやすくする7つのテクニック：プロジェクト成功確率向上の近道とは？（2）（1/3 ページ） ITシステム開発の問題点の一つであるコミュニケーションの失敗。本連載では、これを防ぐ方法としてお勧めしたい3つのドキュメントを紹介していく。今回は、Joelの機能仕様書を日本人向けにカスタマイズされたものを例に、機能仕様書の基本的な書き方、読みやすくする7つのテクニック、仕様書作成ツールは何を使うべきか、誰が書くべきかなども解説します。 連載目次 連載の第1回の前回「ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門」では、ITシステム開発がビジネスに貢献していくためには、まずは開発の成功が出発点になること、そしてITシステム開発におけるコミュニケーションの重要性、そしてコミュニケーションにおけるドキュメントの重要性について説

連載目次 ユーザーが義務を果たすためにはベンダーの支援が必要？ 本連載は主としてITベンダー向けに書いており、取り上げる紛争事例もどちらかといえばベンダーに厳しい結果が出たものが多い。そのせいか読者の皆さまから寄せられる意見の中には「裁判所はユーザーの責任をどのように考えているのか、開発側に負担が寄り過ぎてはないか」といったものも散見される。 しかしもちろん、判決の中にはユーザーの協力義務を厳しく問うものも多く、必要な時期までに要件定義を行わないユーザーや、仕様の確定に必要な情報をタイムリーに提供しないユーザーにこそプロジェクト失敗の責任があるとするものも少なくない。裁判所が、特にユーザー寄りというわけではないというのが、数多くの判例を調査しての私の実感だ。 ただし、ここで考慮に入れなければならないのはユーザー企業のスキルと経験である。システム導入におけるユーザーが負うべき責任についての裁

検収後に発覚した不具合の補修責任はどこまであるのか（前編）：「訴えてやる！」の前に読む IT訴訟 徹底解説（4）（1/2 ページ） 連載目次 今回は「稼働後に検出した不具合を理由に、ユーザーがいったんは検収したシステムの支払いを拒んだ事件」と、そこから得られる知見を解説しよう。 請負契約によるシステム開発において、検収まで行った発注者が受注者との契約を解除し費用の支払いを拒むという例は、ユーザーとベンダーがシステムの完成をめぐって争うことの多いIT業界においても決して多いことではない。 しかし、この判決は、システム導入の目的と要件の関係やその検証、および導入後のベンダーの不具合対応などについて、多くの論点を提供してくれる。今後に役立つ知見を残してくれるものであることから、今回の題材として取り上げることとした。 請負契約において、ベンダーが「ユーザーと交わした約束をしっかりと果たした」と言え

全消しで大量のお邪魔仕様が発生、相手に大ダメージを与えます。次回は「サイバースペース」です。 →他の用語解説も読んでみる ■「結合テスト」：おすすめ記事・超まとめ 「バグ数には興味ないのだよ」――顧客が喜ぶテスト仕様書とは？（＠IT 自分戦略研究所 2010年7月） システムのテストには、単体テスト、結合テスト、システムテスト、運用テストなどがあります。それぞれのテストは開発工程に対応しています JUnitとEclipseを使って学ぶ、“テスト”の常識（＠IT Test & Tools 2009年7月） 何となくテスト項目を作成して実施するのでは、作成したWebアプリの品質が低かったり、開発コストが高くなったりと後々、後悔することになります テスト自動化の3つの目的とROIの必要性、定義（＠IT Test & Tools 2014年6月） 自動テストを導入する目的は何でしょうか？ テスト実

ベンダーはどこまでプロジェクト管理義務を負うべきか：「訴えてやる！」の前に読む IT訴訟 徹底解説（3）（1/2 ページ） プロジェクトを円滑に推進し完遂するために、ベンダーはどのような活動を行う義務があるのか。ある裁判の判決を例に取り、IT専門調停委員が解説する。 連載目次 今回は、平成16年3月10日の東京地方裁判所の判決を解説する。IT法務について述べている数多くの論文や記事の他、筆者の著書でも何度も取り上げている判決だが、システム開発におけるユーザーとベンダーの役割分担についての考え方を裁判所が明確に示し、特に「ベンダーのプロジェクト管理義務とは、どのようなものであるか」を定義付けた重要な判決であることから取り上げることとした。 事件の概要 システム開発において、プロジェクトを円滑に推進し完遂するために、ベンダーはどのような活動を行う義務があるのか、について考えてみたい。まずは、事

ROI(t) = Δ手動テストに対するテスト自動化の利益 / Δ手動テスト対するテスト自動化のコスト = ΔB(t) / ΔC(t) ΔB(t) = Σ(自動テストによる固定費の削減分)(t) + Σ(n2回手動テストを実施した場合の変動費)(t) - Σ(n1回自動テストを実施した場合の変動費)(t) ΔC(t) = Σ(自動テストによる固定費の増加分)(t) + Σ(自動テストの開発費) - Σ(手動テストの開発費) + Σ(自動テストのメンテナンスコスト) (n1/N) n1 = 自動テストの実行回数 n2 = 手動テストの実行回数 N = メンテナンスが必要になるまでの自動テストの平均実行回数 今回は、この各要素を順に見ていきましょう。 自動テストによる固定費の削減分 「自動テストによる固定費の削減分」から説明します。まず、この「固定費」とは、「テスト計画」「テスト設計」など、「テ

表の「手動テストの運用コスト」「自動テストの開発コスト」「自動テストの運用コスト」は各単位時間当たりのコストと実行時間を積み上げていけば、算出できます。 「欠陥コスト」の扱いが問題 表の「テストで間接的に発生するコスト」で○が付いている「欠陥コスト」は「本番環境での欠陥に対する予想対応コスト」なので、発生する欠陥の頻度や重要度によって異なります。自動化された後の運用コストの値は、同一の「規模」「特性」を持ったソフトウェアからのベンチマークで計ることが多いですが、正確な予想値を見積もるのが困難な場合があります。障害の数がどれだけ減るかは、この「欠陥コスト」をはじめ、さまざまな変動要素が絡むためです。このため、簡易的なテストの運用改善に完結したROI試算では「欠陥コスト」は使用しない場合もあります。 また後述しますが、手動テストを自動化する場合、手動テストを行う人員が、別のアプリケーションのテ

業務アプリはもうこれ以上、進化できないのか？ ―― スマートアグリカルチャーに学ぼう：業務アプリInsider×未来テクノロジ 業務アプリ内の技術を最新に置き換えるだけの作業に疲れた？ これから業務アプリはどう進化させればよいのか？ そんな考えに基づき、農業IT化の手法を聞いてみた。「“攻め”の業務アプリ開発」を始めるための参考にしてみよう。 連載目次 「業務アプリ」と言われて最初に思い浮かぶのは、会計ソフトではないだろうか。「会計」という事務業務に代表される、いわゆる「ホワイトカラー」系の仕事の効率化に対し、これまでの業務アプリは大きく貢献してきた。このおかげでビジネスにより専念できるようになった会社は少なくないだろう。 このような事務作業を効率化するタイプの業務システムは、登場してからすでに何十年もたっている。私が知っている限りでもMS-DOSの時代から業務システムは存在し、現状に近い

ベンダーよ、シェルパの屍を越えていけ ～　細川義洋×山本一郎「なぜ、システム開発は必ずモメるのか？」：Developers Summit 2014 リポート（1/2 ページ） リスペクトなきプロジェクトには死が待っている―― 山本一郎さん（やまもといちろう a.k.a.切込隊長）と、東京地方裁判所 民事調停委員 細川義洋さんによるDevelopers Summit 2014の最終セッションは、雪の寒さとは違う意味で会場を震え上がらせた。 2014年2月14日、関東地方は記録的な大雪に見舞われ、各地で交通機関の混乱が発生した。都内の企業が続々と社員に向けて帰宅勧告を出す中、「Developers Summit 2014」の会場は熱気に包まれていた。 今年14回目を迎えるDevelopers Summitは、「技術者の、技術者による、技術者のためのカンファレンス」で、最前線の技術者による解説や

「あるエンジニア、かく語りき」、第0回では私がなぜこの連載を始めようと思ったのかを書きました。今回から始まる本編では、一介のエンジニアが人生の節目節目で考えたことをつづります。今回は「学生から社会人へ」。私が新卒で働き始めたころの話です。 大学を卒業して就職し、仕事としてソフトウェア開発を行う人間になったことで、大きな認識の変化がありました。今考えると、とても一面的だったりナイーブだったりします。それは大学時代の自分の考えであったり、新卒1年目にたどり着いた（と思っていた）「真理」だったり。それでも学生から社会人になり、また趣味で自分のための開発をしていたのが職業として組織の課題解決のための開発をするようになり、立ち位置が変わった体験は印象深いものでした。 大学生の身分、サラリーマンの身分 会社に入って何カ月かして、自分の意識が変化していることに気が付きました。まず挙げるべきは、計画性につ