なぜ、システム開発は必ずモメるのか?

49のトラブルから学ぶプロジェクト管理術
未読
日本語
なぜ、システム開発は必ずモメるのか?
なぜ、システム開発は必ずモメるのか?
49のトラブルから学ぶプロジェクト管理術
未読
日本語
なぜ、システム開発は必ずモメるのか?
出版社
日本実業出版社
定価
2,200円(税込)
出版日
2013年10月01日
評点
総合
3.3
明瞭性
3.0
革新性
3.0
応用性
4.0
要約全文を読むには会員登録ログインが必要です
ログイン
本の購入はこちら
書籍情報を見る
本の購入はこちら
おすすめポイント

これまでシステム開発案件に携わったことのある人の多くは、「なぜ、システム開発は必ずモメるのか?」という本書のタイトルに大いに頷くことだろう。システム開発でよく言われる、要件定義と最後の受入テストはユーザの責任、その間の設計からシステムテストまではベンダの責任。本書は、そのようなシステム開発の常識に疑問を呈す説得力のある書である。

そもそも強力な情報システム部門を持つ企業を除いて、多くのユーザ企業ではシステムへの専門的知識は圧倒的に不足している。また、いくら議論を重ねたところで、システムベンダ側は細かい業務については把握し切れていないことが多い。そのような中でお互いの責任を主張し合ったところで、本来必要とされるようなシステムは出来上がらないのである。もちろんベンダの専門性は求められる。しかし、プロジェクトの成功の鍵は、疑問点をすぐに共有し解決するユーザ・ベンダ間のコミュニケーションの緊密さにあるのではなかろうか。本書にはそのように感じさせる「よく見る問題や愚痴」が散りばめられている。

問題が肥大化した際に駆け込まれる、最後の砦となる裁判における判例をアクセントに本書は展開される。判例に詳しい弁護士、お気楽なユーザ、お気楽なベンダ、堅実なベンダ、という登場人物の会話は多くの読者に読みやすく構成されている。専門的な知識を持つ人からすればやや軽い印象もあるが、味わって読めばそこに潜む本質的な課題にはっとするだろう。システムは1行でも間違えると甚大な損害を与えうる特性を持つものであるが故に、関係するプロジェクトメンバー全員が高い意識と注意力を持つべきなのだ。

ライター画像
大賀康史

著者

細川 義洋
東京地方裁判所民事調停委員(IT事件担当)兼IT専門委員、東京高等裁判所IT専門委員。1964年神奈川県生まれ。立教大学経済学部卒業。NECソフト株式会社にて金融業向け情報システムおよびネットワークシステムの開発・運用に従事した後、2005年より2012年まで日本アイ・ビー・エム株式会社にてシステム開発・運用の品質向上を中心に、多くのITベンダおよびITユーザ企業に対するプロセス改善コンサルティング業務を行う。2007年、世界的にも稀有な存在であり、日本国内にも数十名しかいない、IT事件担当の民事調停委員に推薦され着任。現在に至るまで数多くのIT紛争事件の解決に寄与する。それらの経験を元に、オルタナブログで「IT紛争のあれこれ」を連載中。本書が初の著書となる。

本書の要点

  • 要点
    1
    業務知識やシステムへの専門性の双方が求められる要件定義において、ユーザ・ベンダ間の認識の摺り合わせに多くの時間が必要であることを、十分に理解すべきである。
  • 要点
    2
    進捗はWBS等のタスクスケジュールの細分化された一つひとつの作業の「着手」と「完了」で管理する。つまり、完了しか信用してはいけない。
  • 要点
    3
    システムの品質を守る最後の砦は受入テストそのものではなく、テストケースやテストデータのレビューにあると認識すべきだ。

要約

システム開発の前提知識

システム開発工程とプロジェクトマネジメント
36712489/iStock/Thinkstock

本書で語られている課題の多くは、システムの企画やシステムベンダの経験があれば、誰しも思い浮かぶものではなかろうか。それらが対話形式で語られており、気軽に読み進めることができる書となっている。ここではその要点を紹介していきたい。

前提知識として重要となるのが、システム開発手法の基本である「ウォーターフォールモデル」である。古くからある伝統的な手法であるものの、特に大規模システム開発においては、なお主流の考え方だ。

1.要件定義

現行の業務とそれを支援するシステムを分析。改善点と新業務要件を定義して、システム化の範囲・目的・方針を決定。それらを元にシステム化要件を定義。

2.外部設計

要件実現の方式や使用するハードウェア、ソフトウェア、ネットワークなどを定義してシステム構成を明らかにする。

3.内部設計

プログラムの構造およびその間のインターフェースなどをプログラミング可能な状態まで定義。

4.プログラミング

内部設計に従ったプログラムの作成。

5.テスト

プログラム単体のテスト、関連機能を繋ぐ結合テスト、システム全体の機能を検証するシステムテスト、ユーザ側で最終的な検証を行う受入テスト

を行う。

ハイライトでは上記の内、読者の多くであろうユーザ側の視点が重要となる、要件定義、テストに加え、全体のプロジェクトを円滑に運営するためのプロジェクト管理について、起こりがちな問題や裁判事例を中心に紹介する。

【必読ポイント!】要件定義 ~「言った・言わない」と「やる・やらない」~

そもそも要件定義は何を決めるのか
KatarzynaBialasiewicz/iStock/Thinkstock

「もう設計も終わるはずの時期なのに、また要件からやり直し!そのうえ納期は全然延ばしてくれないなんて、お客さんヒドくないですか?」

冒頭の言葉はシステムベンダの経験があれば、多くの方が言ったことのあるセリフだろう。本書ではあまりにも多くのプロジェクトの混乱の原因となる要件確定の遅れから紹介されている。しかし、東京地裁の平成16年3月10日の判決によれば、ユーザの出す要件変更が及ぼすプロジェクトへの影響は、専門家であるベンダでなければ把握できない。要望を受けたときには、メリット・デメリットの検討、追加費用等をユーザに提示することが必要と判断されている。

つまり、ユーザのワガママでは済まされないのである。それを仕組みとするため、定期的に要件変更に関する会議を開くことが提唱されている。ベンダとしては、プロジェクト末期にユーザに泣きついても無駄であり、要件確定当初から毅然とした態度で合理的に接点を見いだす姿勢が求められるのだろう。

要件定義をベンダ任せにするユーザ

「今度のお客さんは『とにかく動くものつくってくれれば』って要件定義も一切お任せで、こっちの思い通りにできるから本当楽チン。」

本当にそうだろうか。著者はそれこそが危険な兆候であるという。

もっと見る
この続きを見るには…
会員登録(7日間無料)

3,000冊以上の要約が楽しめる

会員登録(7日間無料)
Copyright © 2023 Flier Inc. All rights reserved.
一緒に読まれている要約
その言葉だと何も言っていないのと同じです!
その言葉だと何も言っていないのと同じです!
吉岡友治
未読
入門クラウドファンディング
入門クラウドファンディング
山本純子
未読
会社を強くするビッグデータ活用入門
会社を強くするビッグデータ活用入門
網野知博
未読
グローバル・リーダーの流儀
グローバル・リーダーの流儀
森本作也
未読
日本の会社40の弱点
日本の会社40の弱点
小平達也
未読
インサイド・アップル
インサイド・アップル
依田卓巳(訳)アダム・ラシンスキー
未読
「自分で考える力」の授業
「自分で考える力」の授業
狩野みき
未読
休む技術
休む技術
西多昌規
未読
7日間無料でお試し!
法人導入をお考えのお客様