なぜ、システム開発は必ずモメるのか?
49のトラブルから学ぶプロジェクト管理術

未 読
なぜ、システム開発は必ずモメるのか?
ジャンル
著者
細川義洋
出版社
日本実業出版社
定価
2,160円
出版日
2013年10月01日
評点(5点満点)
総合
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日の判決によれば、ユーザの出す要件変更が及ぼすプロジェクトへの影響は、専門家であるベンダでなければ把握できない。要望を受けたときには、メリット・デメリットの検討、追加費用等をユーザに提示することが必要と判断されている。

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

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

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

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

要約全文を読むにはシルバー会員またはゴールド会員への登録・ログインが必要です
「本の要約サイト flier(フライヤー)」は、多忙なビジネスパーソンが本の内容を効率的につかむことで、ビジネスに役立つ知識・教養を身につけ、スキルアップに繋げることができます。具体的には、新規事業のアイデア、営業訪問時のトークネタ、ビジネストレンドや業界情報の把握、リーダーシップ・コーチングなどです。
この要約を友達にオススメする
なぜ、システム開発は必ずモメるのか?
未 読
なぜ、システム開発は必ずモメるのか?
ジャンル
生産性・時間管理 テクノロジー・IT
著者
細川義洋
出版社
日本実業出版社
定価
2,160円
出版日
2013年10月01日
本の購入はこちら

related summaries
一緒に読まれている要約

会社を強くするビッグデータ活用入門
会社を強くするビッグデータ活用入門
網野知博
未 読
リンク
グローバル・リーダーの流儀
グローバル・リーダーの流儀
森本作也
未 読
リンク
その言葉だと何も言っていないのと同じです!
その言葉だと何も言っていないのと同じです!
吉岡友治
未 読
リンク
入門クラウドファンディング
入門クラウドファンディング
山本純子
未 読
リンク
日本の会社40の弱点
日本の会社40の弱点
小平達也
未 読
リンク
「自分で考える力」の授業
「自分で考える力」の授業
狩野みき
未 読
リンク
インサイド・アップル
インサイド・アップル
アダム・ラシンスキー 依田卓巳(訳)
未 読
リンク
ビジネスモデル×仕事術
ビジネスモデル×仕事術
細谷功 井上和幸 西本伸行
未 読
リンク
1
神メンタル 「心が強い人」の人生は思い通り
神メンタル 「心が強い人」の人生は思い通り
星渉
未 読
リンク
2
amazon 世界最先端の戦略がわかる
amazon 世界最先端の戦略がわかる
成毛眞
未 読
リンク
3
スモール・スタート あえて小さく始めよう
スモール・スタート あえて小さく始めよう
水代優
未 読
リンク
経済理論の確立を歴史的背景にMIXして書かれた『ECONOMIX』
経済理論の確立を歴史的背景にMIXして書かれた『ECONOMIX』
2017.06.27 update
リンク
事業成功の最強ツール、「KPIマネジメント」の極意とは?
事業成功の最強ツール、「KPIマネジメント」の極意とは?
2018.10.04 update
リンク