情シス・IT担当者[必携] システム発注から導入までを成功させる90の鉄則

著者 :
  • 技術評論社
4.05
  • (13)
  • (19)
  • (4)
  • (2)
  • (1)
本棚登録 : 301
感想 : 16
本ページはアフィリエイトプログラムによる収益を得ています
  • Amazon.co.jp ・本 (256ページ)
  • / ISBN・EAN: 9784774189253

感想・レビュー・書評

並び替え
表示形式
表示件数
絞り込み
  • 正しいノウハウを基に進めれば、プロジェクトは回る。
    責任を問われない側で、いかに自分たちの責任について思考できるか。
    いかに「お客さん側」「売る側(企業側)」の立場を乗り越えるか。諦めずに対話し続けることが大事。相手の立場に立った方が、うまくいく

    買ってもらう側に、誠実で穏やかに接することができない企業は、衰退していく。「なぜなら、売る側」の方が、その分野についてはプロだから。

    【感想】
     本文の「はじめに」で一気に引き込まれた。以下の文に、強くひざを打った。
    「多くの成功プロジェクトに関わってきた半面、多くの失敗プロジェクトも見てきました。ベンダーの立場、ユーザー企業の立場、客観的な立場と様々な切り口で失敗を見てきました。そこで初めてわかってきたことがあります。
     『失敗の原因はユーザー企業の力量不足』
     ということです。」
    「今までの失敗事例を振り返ってみると、ベンダーにも問題はありましたが、それ以上にユーザーに問題があることに気づきました。ただ、ユーザーはお金を払う発注者の立場であり、責任を追及されることがないだけなのです。
     何か問題が発生すると、それは全てベンダーの責任とされます。ユーザー側に問題があったとしても、ベンダーに責任転嫁されます。これはユーザー側に「お金を払っているんだから、それぐらいやってくれて当たり前だろう」という発注者マインドが作用しているためです。」

     そう、そうなんだよ。これをユーザー企業の情シスに向けて言っているのはすごくありがたい。この本で「ユーザー側がやるべきことだよ」と言っていることは、いつも、弊社や自分が代わりに行っていることだ。この本に書いてあるレベルのことができているユーザー企業はとても少ないと思う。
     仕事をしながら、「ほんとにそれって、こちらがやって、メリットがでるのか?顧客がやったほうが生産性が高いのではないか?」という気持ちがクリアになった。と同時に、まだまだユーザー企業側のシステム導入リテラシーは低いのが業界の実情なんだな、と思い、複雑である。なかなか、業務システムベンダーの立場からでは、そこまで踏み込んでシステム導入コンサルティングは行えないし、そもそもサービスとして提供していない。あくまで、業務システムを導入することまでをサービスとして行うしかない。すきを見て、この本で学んだ内容をユーザー側に確認する、質問する、ということができればいいと思うが。

    【本書を読みながら気になった記述・コト】
    ・システム導入プロジェクトは企画・人選が重要。企画で失敗しているプロジェクトは成功しない。最初の企画がダメだと、後戻りはできない。 
     「最適な企画書」→「最適な発注要件」→「最適なベンダー」→「最適な設計書」→「最適なシステム」とつながる。
    ・要求機能一覧でブレない自社の基準を作る
    ・RFP未完成でベンダーに声をかけない
     →私はまともなRFPをユーザー企業側から見たことが無い...。
    ・「ベンダーが業務を知らない」というのは、「ベンダーに業務を伝えていない」ということ
    ・パッケージはノンカスタマイズを目指す
     →ほんとそう。ベンダー側からみても、ユーザー企業からみても、カスタマイズは悪いことが多い。ただ、中々「パッケージに併せて業務を変えよう」と理解してくれるところが少ないのだが。
    ・現行帳票は全て廃止するつもりで見直す → 業務改善のチャンス
    ・自社でデータの手加工を前提とした運用設計をしない → 業務にボトルネックを生む要因になる
    *受入テストには4種類ある
     ・機能テスト
     ・システム間連携テスト
     ・シナリオテスト
     ・現新比較テスト
    *発注者のおごりで検収を遅らせてはならない。移行ベンダーから搾取され、Lose-Loseの関係になる
    ・ベンダーによるテスト結果の提出は義務付けする。テスト結果の提出を持って、受入テストの開始とみなす
    ・スクラッチ開発の場合は品質報告書を要求する
    ・業務ユーザーに、システムの導入を納得させ、良いイメージを持たせるのは、ユーザー企業側の仕事


    <ユーザー企業側がつくるべきもの>
    ・RFP
    ・社内役割分担表
    ・要求機能一覧
    ・システム関連図
    ・業務フロー
    ・自社用WBS
    ・自社用課題管理表
    ・業務マニュアル
    ・障害管理表
    ・受入テスト結果
    ・稼働判定表

    バカの壁...自分とは違う意見を取り入れられない状態のこと。人が無意識のうちに「これはこうあるべき」「これが当たり前だ」と思い込んでいる部分

  • ITコンサルの立場で読了。
    普段直接接することの多い、情シス担当者のための本を読んで、相手の立場を理解しようという企画。
    全体通してみると、いやいやそれベンダーの方でやってるしということばかり。こんなに色々する情シスがいたらびっくりするわというレベル。企業の規模とか、情シスへの力の入れ方とかによって違いはあるんですかね。
    まあ、コンサル(といいつつ、SIerとの違いはよく分からない感じ)だから、やって当然かとも思いつつ、今の仕事の役割分担に疑問を抱いた。
    システム企画から運用に載せるところまで網羅的に書かれているので、今の仕事に抜け漏れないかをチェックするのに役立ちそう。

  • ベンダーにまるめこまないようにするという観点で、各種ドキュメントの内容、各開発工程で自社、ベンダー間の役割分担について詳述されており、多いに参考になった。システム開発は部門間の調整能力に代表されるようにコミュニケーションが重要であることも分かった。過去、ベンダーからひどい嫌がらせを受けたこともあり、嫌な記憶を思い出しながらも頑張って読んだ。

  • ITベンダー用の本だが、社内IT部門にも参考になる。
    業務フローが書けないようでは上手く進まない。
    帳票は全て廃止するつもりで。
    パッケージに業務を合わせるつもりで業務見直す。

  • ・1人ITみたいな会社なら必要では

  • 【著作権は必ず自社に帰属させる】
    本文中では、ベンダ打ち切りの際に「著作権はウチにあるので、システムは最初から作りなおしてくれ」と要請される事態を紹介。このケース以外においても、クラウド・サービスにおいても注意が必要。

    【瑕疵担保期間は1年を基準とする】
    決算や年末年始、特定イベントを考慮すると1年必要。民法上も「瑕疵修補期間」も1年と定められている。損害賠償責任期間も同様。

    【見送り機能は丁重に取り扱う】
    検討で見送りとした機能は「要求機能一覧」から削除せずに残し、見送った理由・解決方法を明記する。蒸し返しが発生してしまう。

    【課題管理は進捗を訊くだけでは意味がない】
    停滞の原因は「ネクストアクションが明確でない。」「実は課題をよく理解していない」。⇒PMは訊きに回ってボトルネックを見つけ真の原因を除去する。

    【面従腹背はプロジェクトを転覆させる】
    PMの管理が厳しくなると面従腹背が発生し、プロジェクトは悪循環に陥る。⇒PMは訊きに回ってボトルネックを見つけ真の原因を除去する。

    【障害管理表はボールを止めない】
    「いまボールを誰がもっているのか」。障害を理解し、解決へのストーリー・ステップを描く。



    ※ちなみに2・3週前の東洋経済で特集されていましたが、2019施行予定の改正民法では、「不具合が有る事実を知ったときから1年間」となるようです。http://www.techvan.co.jp/media/quality/civil-code

  • たまたま店頭で見つけて思わず購入してしまいましたが、システムの企画から保守・運用まで企業のIT担当がシステムを導入する際のノウハウとしてはひととおり網羅されているのではないでしょうか。
    RFPの目次構成や業務フローの書き方、受入テストの体制づくりなど、非常に具体的で「痒い所に手が届く」内容となっています。
    システム導入プロジェクトのノウハウ本は巷で多く出回っていますがいずれもベンダー目線のものがほとんどで、いわゆる「情シス」向けのものが少なかっただけに貴重な一冊です。

    企画フェーズでは経営層を巻き込み、要件定義~受入テストではユーザー部門を巻き込む、、、当たり前のことですが、なかなかできないことです。
    またベンダーに任せる部分と何が何でも自社で主導してく部分のメリハリの付け方についても参考になります。ベンダーコントロールでお悩みの方も必読と言えます。

    とは言っても、社内の事情は組織によってマチマチです。本書のとおりに進めたからといって、必ずしもプロジェクトが成功するとは限りません。
    仮にもしプロジェクトが失敗したとしても、その教訓を次のプロジェクトで教訓として活かすことが大事です。そのためのベースという意味でも本書には価値があると思います。

  • システム開発の業務部門として仕事をしているが、やはり要件定義がとても大事だと感じた。業務部門の要件定義(業務フローなど)の仕方をもう少し詳しく書いてくれると、より実務的な本になって、参考にできたと思う。
    全体の流れを知るには良い本だった。

  • 同著者のベンダー選定の本を読んでいて、紹介されていたので手に取った一冊。前に読んだものがベンダー選定に焦点を当てていたことに対し、本書はタイトル通りシステム発注から導入(運用保守)までを記載している。その分粒度はところどころ粗くはあったが、ユーザ企業側でのプロジェクト推進経験がない者としてはなるほどと思うことが多々あった。企画書とRFPの違い、業務フローはRFP前に作っておくこと、RFPは社内合意しておくこと、瑕疵担保責任は1年とすべきだったり、いろいろと気にすべきところがあった。

  • 実際にシステム導入検討をしており、RFPやベンダー評価シートの具体的な作成方法やテンプレが大変参考になりました。とても実用的な一冊です。

全16件中 1 - 10件を表示

著者プロフィール

田村 昇平(たむら しょうへい)
情シスコンサルティング株式会社 代表取締役。
ITプロジェクトを推進するIT部門、情報システム部門を支援する情シスコンサルタント。支援したIT部門は20社以上、プロジェクト数は60以上に及ぶ。
ITベンダー側で10年、ユーザー企業側で13年のITプロジェクト経験を経て、プロジェクトの全工程に精通した。その経験をもとに業界初のノウハウ集「システム発注から導入までを成功させる90の鉄則」を上梓、好評を得る。同書は多くのIT部門で研修教材にもなっている。
プロジェクトの膨大な課題を悶絶しながらさばいていくうちに、失敗する原因は上流工程にあるとの結論にたどり着く。そのため、「ファネル選定」などの超上流ノウハウを深化させ、IT部門にインストールするようになる。「IT部門が会社を強くする」という信念のもと、IT部門の現場で日々奮闘している。

「2022年 『御社のシステム発注は、なぜ「ベンダー選び」で失敗するのか』 で使われていた紹介文から引用しています。」

田村昇平の作品

この本を読んでいる人は、こんな本も本棚に登録しています。

有効な左矢印 無効な左矢印
リンダ グラット...
デールカーネギ...
有効な右矢印 無効な右矢印
  • 話題の本に出会えて、蔵書管理を手軽にできる!ブクログのアプリ AppStoreからダウンロード GooglePlayで手に入れよう
ツイートする
×