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

細川義洋【著】

• 販売会社／発売会社: 日本実業出版社
• 発売年月日: 2013/09/28
• JAN: 9784534051158

商品レビュー

2019/10/22

池袋のジュンク堂で気になりかなり前に買った。
キャラクターとのやり取りを通して、システム開発の難しさを学べる。理想ではあるが、分かりやすく為になる。
何箇所か絵に誤植があった。

・・・・・・
■要件定義
要件定義と契約が結びついてないと
ユーザー「自分たちの希望を全て叶えてくれるはず」
ベンダー「費用と期間でできるところまでやる」
って争いになり泥仕合になる
→大事なことは要件と契約書をちゃんと繋げておくこと
→でも要件は開発中に変わるから、契約書の別紙にしておいた方が良い

IT紛争って、お互いの責任分担のモレやちょっとした理解不足、確認不足が原因のものが多い

業務プロセスから業務要件におとしても
例外プロセスが抜ける可能性があるから注意
→オペレータから学ぶ

■テスト
システムの品質を守る最後の砦は、受け入れテストではなく、それに向けたテストケースやテストデータのレビューだと思ってる。
→要件定義直後とテスト直前に行う

ベンダのテストは網羅的でしっかりしてるけど、セキュリティや時間の都合で実データを使わずに行うことが多いから、想定外のデータへの漏れが見つかることがある

テスト計画書
・体制、要員
・テストに必要な資源
・使用ツールと仕様と使用法
・進捗把握方法
・開始、完了基準
・テストデータの準備
・結果の検証方法、明確、妥当
・前提条件、環境
・テスト計画に影響するような大きな設計変更がないか
・十分なロングラン、耐久テスト
・リグレッションを計画したか
・パフォーマンスを計画したか
・ストレステスト（入力量、処理量、処理時間）
・見やすさ、使いやすさ
・ユーザとベンダの役割分担、協力事項
・テストデータ・本番データの管理方法は明確か

■プロ管
→リスク管理こそプロ管で最も重要
プロジェクト管理はベンダの責任
リスクの抽出や対応策の検討らユーザがやる
→ガイドしてあげるのはベンダ

・進捗は着手と完了で管理する
→記述、コードレビュー、後修正、単体テストと修正

PMの上司の役割
→体調管理や、PMの能力を図ること
→→足りなければ新規参画者をつけたり、指導したりする
→継続的にやる
→1日一度は会話する時間を取る

破綻したプロジェクトほど、苦しいため
「この会議だけは無事におわりますように」と目先だけ考えがち
目的は、安く早くうまくやり、企業の生産性向上や、コスト低減を実現すること
→プロジェクト中、ユーザーに笑顔でいてもらうことじゃない

・ステアリングコミッティ
→双方トップの会議
→スケジュール変更、中止、再開などを決める権限を持っている

・思考の継続性
→その人しかやれない仕事はその人にやってもらう

SPI =ev/pv
→一以下なら遅延、一以上なら前倒し

ユーザーは綺麗なプログラムが欲しくて
多額の投資をするわけじゃない
システムによってもたらされる経営的なメリットを求めているのよ。

世界初のコンピュータ
→諸説あるが
→ENIAC 1946年間
→アメリカの陸軍の大砲の弾道計算のために設計された
→プログラムを組み替えることでさまざまな計算ができた

最初の自動車
→1769年にフランスで作られた
→フランス陸軍の技術大尉キュニョー
→時速約3キロしか出なかったらしい笑

外字
→元々コンピュータに登録されていない特別な文字

・錦の御旗
→戊辰戦争の際薩長軍が、自分たちこそ官軍であると示すために、朝廷に頼んで作らせてもらったものが有名。
→精神的な効果が大きく、旧幕府軍は大いに動揺したと言われる

2018/04/07

裁判での判決をもとに、トラブルになる前に対応すべき事例が記載されている。49の事例があるがそれぞれ独立しているため、読みやすい一方で繋がりがないといった印象。

2017/12/31

大抵のシステム開発プロジェクトは、
上手くいったと言っていながら品質、コスト、納期の
いずれかを達成できずに終了している。

また、プロジェクトを進めていくにあたり、
問題が出ることはやむをえないことだが、
そもそもソフトウェアが無形の成果物であるため、
何が問題でどれくらい影響があるのかを説明しにくい。

よって、システム開発プロジェクトは、
何らかの形で揉めることが多い。

本書は、それぞれの工程における事例をベースに
まとめられており、その揉め事に対する対策案を
書いてくれているので分かりやすいし参考になった。

すべての揉め事を無くすことは難しいと思うが、
少しでも揉め事が起きないよう施策を打っていきたい。

【勉強になったこと】
・要件変更要望があった際は、
　必ずメリット・デメリットを提示すること。

・要件定義工程では、ベンダは積極的に
　ユーザの決めること、調べることを支援すること。
　ユーザは技術的な仕様まで抑えているわけではなく、
　システム要件として実現不可能な内容も要件として
　取り込まれてしまいかねない。

・優秀な管理者は、問題を早期発見し、
　上手く損切りしながら最終的に組織に利益を
　もたらす。

・プロジェクト管理の責任はベンダにあると考えて
　ユーザを支援していくこと。

・一般的に6カ月のプロジェクトで10日遅れた場合、
　メンバーの努力だけでは解消することは出来ない
　と言われている。

・品質改善とは、優秀な人の生産性向上ではなく、
　9割の普通の人でも品質改善出来るようにすること。
　全体として生産性が上がる施策を打つこと。

・プロジェクト管理費用や要件変更に必要な費用は、
　プロジェクト全体の2～3割必要。
　ここは値引きしてはいけない部分。