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

著者 :
  • 日本実業出版社
3.79
  • (41)
  • (49)
  • (45)
  • (6)
  • (5)
本棚登録 : 632
感想 : 62
本ページはアフィリエイトプログラムによる収益を得ています
  • Amazon.co.jp ・本 (270ページ)
  • / ISBN・EAN: 9784534051158

感想・レビュー・書評

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

  • 物語調で進んでいくのでイマイチかと思っていたが、大事なポイントは押さえられている気がして、良かった。
    ただ、物語のせいでやや冗長なので、自分で一度まとめ直したいな、と思う。

  • ■書名

    書名:なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術
    著者:細川 義洋

    ■概要

    実に、およそ7割が失敗するというシステム開発プロジェクト。そ
    の最悪の結末である「IT訴訟」の事例を参考に、トラブルの予防策
    と対処法が学べる1冊です。“IT訴訟専門弁護士・塔子”がトラブル
    を解説するストーリー!
    (From amazon)

    ■感想

    この方の本は2冊目です。
    ITの訴訟調停委員という肩書を持つ方で、ネットの連載も読ませて
    いただいておりますが、日本+ITという特殊な事情が裁判を法律通り
    の結果にさせない感じになっているのがしっかり伝わってきます。

    例えば「検収したら判を押した側がその後全責任を持つ」と考えて
    いる方も多いと思いますが、検収をしても納品したものがあまりに
    実際の業務とかけ離れている場合、業界特殊の常識を満たしていな
    い場合には、納品下側が負ける可能性が高くなります。

    こういうのは、こういう調停に関わらない限り知らない部分だと思い
    ますし、会社の法務関係、弁護士でも知らない部分も多いと思います。

    面白いのは、裁判官は結構実際の業務、業界特有の常識、ITプロジェクト
    特有の契約などを考慮し、判決を下している部分ですね。
    そんなの「当たり前じゃん」と言われれば元も子もないのですが、法律
    一辺倒では無いのが裁判の面白い部分であり、難しい部分でもあります。

    私も裁判に発達した案件に関わっていたので分かりますが、裁判沙汰
    になると、この本にや他の本でも書いてあるように、基本的に信頼関係
    は崩壊しますので、後はごまかし/嘘を言ってないなどもう情報の隠し
    合いになります。
    自分の感覚では、客が偉そう/圧力的であればあるほど最終的に客が損
    すると思います。ベンダは作っているけど、言わなくても良い事(要件に
    入っておらず詳細なプログラムの動きなど)は言いませんから、後でそう
    いう時限爆弾が破裂する可能性が高くなり、その時に困るのは客となります。
    勿論、こういう事ばかりではありませが、こういう事も起こり得ると
    言う事です。

    どの本でも言われていますが、結局、争いを生むのは全てコミュニケー
    ション不足、高圧的な態度によるものです。
    コミュニケーション不足の中には、「当事者意識の不足」も含まれます。

    「言うが易く行うは難し」ですが、もうこれは言ったうえで出来る範囲で
    実際に実施していくしかありません。
    正直に謝れば怒られますが、その後ある程度は許して頂けるはずなのですが
    これをしない会社/プロジェクトの多い事、多い事。
    これは、色々と言い訳して、怒られるのが仕事のはずのPM、責任者
    が仕事をしていないだけです。

    責任者は責任を取るのが仕事でありその代償に大きな金銭を受け取って
    いるはずなんですけどね。

    経験的にですが、謝れないのは大きな会社(ベンダ)の方が多い気がします。
    無駄なプライドがあるのでしょうね。
    謝ろうが、謝らなろうが、結局納品したものがダメなら責任を取らされる
    はずなので、小さい事に拘りすぎている事が多い気がします。
    (こういうのは言っても聞いてもらえないですけどね。)

    ■気になった点

    ・要件変更が無いプロジェクトは無い。

    ・最初に要件変更の会議を開くようにしておく。
     そこで、目的/経営方針に従い、本当に必要な要件か?優先順位
     はどうか?メリット/デメリットを議論する。

    ・その場しのぎで取り繕って問題先送りにする態度こそ不誠実この上ない。

    ・要件について何を決めるべきかの責任はベンダにある。
     その決めるべきことをユーザに説明し、実施させる義務がある。

    ・もめるのも最初の内ならなんとかなると腹をくくる。

    ・結局、ベンダの情報開示意識とユーザの当事者意識が最後はものを
     いう。

    ・安いが一番というユーザとは、付き合いを考えた方がいい。

    ・プロジェクトを完遂する事が優秀な管理者では無い。優秀な管理
     者は問題早めに検知してうまく損切りしながら最終的に組織に利益
     をもたらす。

    ・信頼せよ。されど検証せよ。

    ・こじれたときは、敵の中に味方を見つける。
     お互い完遂したいと思っているのであれば、個人的に腹をわって
     話せば落としどころを見つける事が出来る事が多い。

    ・業界の常識を知らないでベンダが負けた裁判もある。

    ・方針をもとに要件定義の範囲を定義する。

    ・大切なのは内部でも外部でも血の通ったコミュニケーションと
     なる。

    ・ユーザの参加意欲を刺激する方法として、会議で催し物を計画
     する。

    ・個人の視点で見れば早くても、プロジェクト全体としては工数の
     無駄遣いというケースは結構ある。

    ・ユーザは綺麗なプログラムを求めているわけでは無く、システム
     を導入し得られる経営的なメリットをもとめている。

    ・バグは放置せず迅速に修正する。

    ・バグは簡単に直りますと言っても、ユーザは不安である。

    ・後から来た第3者の方が、当事者より冷静で妥当な解決策を見つ
     けやすい。

    ■自分がこの作品のPOPを作るとしたら?(最大5行)

       ITプロジェクト
         裁判

    この2つのキーワードに引っかかる人には読む価値あり!

  • いわゆるべからず集。顧客と折衝するような立場にある人は一読の価値あり。一度読んで終わりではなく、事あるごとに参照したい内容でした。しかし、思った以上に情報ベンダの責任は重いんだな•••

  • この類の本は一般論や理想論に終始しがちだが、本書は改善の具体策も書かれていて実践に向けてのヒントが満載である。「オーダメイドのシステム作りはベンダと顧客との協同作業である」という判決文はまさに金言。
    私はユーザ側のシステム担当者であるから、(ユーザ側の視点に立ちながらも)どこかではベンダとユーザの双方が合意できる落とし所を模索しなければならない。
    そういう意味では、協同作業が出来なくなり、裁判まで行き着いてしまった泥沼プロジェクトに対して、裁判所という第三者がどういう視点でジャッジし、または調停でどういう落とし所に持って行っているかを知ることが重要である。
    本書に書かれていることは、プロジェクトが無益な泥沼陥らない為に、陥る前に引き返せるように、ベンダ側、ユーザ側の双方が知っておくべき基礎知識なのだと感じた。

  • 名著!
    プロジェクト管理云々より最初に、「ベンダはプロフェッショナルなのだから、プロフェッショナルとしてユーザの目的達成に協力しなければいけない」ということに気づかされた。

    例えば、建築家が、お客さんがリビングを広げたいというからと言って、リビングを広げる代わりにトイレをなくして、後で「あれっ、図面見せましたよね」なんて言ってはいけないのだ。

  • 読み物形式で読みやすい

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • ・各種のチェックリストは有用
    ・プロ管費は10%、場合によっては15%。要件定義は1/9、変更管理を合わせると2,3割

  • システム開発
    ビジネス

全62件中 1 - 10件を表示

著者プロフィール

ITコンサルタント、政府CIO補佐官。システム開発・運用の品質向上や企業のIT戦略立案の支援を行いながら著述、講演も行う。現在は、政府CIO補佐官としてデジタルガバメントの推進やIT化による行政改革などに取り組む他、行政におけるAI活用の研究を行っている。

「2018年 『ある日突然AIがあなたの会社に』 で使われていた紹介文から引用しています。」

細川義洋の作品

  • 話題の本に出会えて、蔵書管理を手軽にできる!ブクログのアプリ AppStoreからダウンロード GooglePlayで手に入れよう
ツイートする
×