なぜ、システム開発は必ずモメるのか？ の商品レビュー

細川義洋【著】

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割必要。
　ここは値引きしてはいけない部分。

2017/06/06

2017年6月6日読了。IT開発にまつわる過去の訴訟・調停の例などを引きつつ、IT開発においてユーザ・ベンダそれぞれがやるべき業務の範囲・責任などをストーリー仕立てで読み解いていく本。そっけない装丁とマーケティング狙いじみたタイトルと、素っ頓狂なキャラがやり取りを繰り広げる中身とのギャップがすごいが、自分の仕事に大いに関わる内容でもあり、当事者だけに内容は非常にグッとくる。「ユーザがやってくれない・決めてくれないからしょうがない」というだけのベンダであればいらないし、裁判になった時に「専門性を有したベンダとして果たすべき責務を果たしていない」と判断される可能性も大ということなのだな…。目的を定め、計画を立て、関係者の合意を得て、実行して問題の兆候を見つけ解決し、ユーザに満足してもらい会社として利益を得る、とこれらは全てPMPにある内容であり、PMが当然やるべきことなのだが…難しいよな、日々努力が必要や。

2020/12/30

興味本位で買ってみたけど登場人物の会話で展開していくのでとても読みやすくて良かった!!!

自分は要件定義、プロジェクト管理、契約関連、プロマネが行うことなどは、「言われてみれば行ってたかもれないけどあまり意識してなかった」ことばかりでためになった。

CASE44での彩音と一郎の会話の中の、
一郎「自分の管理で人より早く危険を発見したり、その対策が奏功してプロジェクトが成功するのは傍目で見るより面白く達成感もある」
の言葉が、いいね（＾◇＾）
希望が湧く。笑

-------------------------------
・定期的に要件変更に関する会議を開く
・実際の業務に当てはめてのシュミレーション、他の接続システムの担当者との確認などをしてくださいと促すのも仕事
・本当に今やらなきゃいけないこととそうでないことを色分けして前者だけを決めれば要件定義工程は完了
・プロジェクト管理の価値をユーザに認めてもらう
・プロマネの上司はプロマネの心身と健康に気を遣う
・ユーザーの意欲を維持するために会議で催し物を実施する
・ユーザーや上司の顔色を見ながら「頑張ります」はその場しのぎでしかない
・開発順はプログラミング視点からだけではなく業務上必要な機能や使用頻度も考慮して決める
・トラブル改修の順序は損得を計算してから
・組織的な品質改善の仕組み向上は、「優秀な人」ではなく「普通の人」の生産性をあげるため
・テストケースレビューは要件定義後とテスト直前とで２度行うとよい
・プロマネは言葉を鵜のみにせず周囲の状況や気持ちを察する
・プロマネはメンバの前でも身なりに気を遣う（くたびれてるように見えないように）

2016/04/17

20160417
受注を受けてから納品するまでの流れとプロジェクトマネージャに要求されるスキルを理解するのに適した本だった。
参考資料も目を通す。

2016/01/11

システム開発現場のあるある。プロジェクトの揉めるポイントについて原因と対策をまとめている。具体的なストーリー仕立てになっており読み物としても面白い。

2018/11/25

素晴らしい内容だった。
どのページも重要で、ピックアップが出来ないぐらい。
定期的に読むべき本である

2015/07/11

事例を用いた解説で理解しやすい。1つのトピックが4ページと短く、会話形式で読みやすいので読んでいて面白い。ベンダ側・ユーザ側、元請け・下請けと相対する立場でそれぞれ気をつけること、押さえておくべきチェックポイントが参考になる。システム開発をするうえで手元に置いておいて何度も読み返したい本。

2015/05/27

良書です。会話形式で、システム開発の課題、解決策、判例について解説されています。
自身で学ぶためにも良いと思いますが、誰かに教えるための参考書としても、使える本です。
（登場人物同士のやりとりで無駄な内容もあります。そこだけ残念かも。）