投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
「業務フローに社員の感情を書き込め」にはハッとした。全体最適を考えるとどうしても負荷が増える部門が発生してしまうが、特に経営陣に説明するときに使えると感じた。他にも「ベンダー内のトラブルも言ってもらえるような関係性を構築する」などシステムを外注している情報システム部門担当者は一読しておくと良い。, 当然、ストーリー通りにいかないケースは多数あるが、この本を「基本」とすると良いのではないか。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
システムを外部のベンダーさんと一緒に開発したことは何度か経験あるけども、
外注をしておまかせすれば、思った通りに夢を叶えてくれるわけではない。
注文した側も、きちんと責任と役割を分担して進めていかないと、いけないんだよね。
これって、システムに限らず人にものを頼むときもそうだと思う。
丸投げして、あとでチガーウ!と言われても、頼んだ方の責任も大きいよね。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
業務要件定義:新しくシステムを導入して、どんな業務を実現するのかを決める作業
システム要件定義:業務要件定義書に書いたことを実現するために、システムが持つべき機能を書き出す作業
いずれも発注者が行う作業
特に業務要件定義は、発注者自身が全面的にリードしないといけない。社外ベンダには分からないことが多いため
業務要件定義書を書くより前にやらないといけないこと、社内全体の業務を俯瞰して、全体最適の視点から、業務の問題点や新しいシステムが実現することで改善される点、全社的なメリットなどがひと目でわかる資料を作成すること。
業務フロー図を作成すること。業務フロー図には、さまざまなメモ書きをしていかないと、最終的には役に立たないシステムになる
機能要件:システムができること・できないことを具体的に明らかにする作業。この不備はトラブルの原因のワースト1
まずは現状のながれ、As- Isと、その問題点を明らかにして、それを解決する業務の姿、T o-Beを書く、2つの業務フロー図並べて見ることで、業務のプロセスや組織をどう変えるのか、そしてどの業務をシステム化すべきかが初めて明らかになる
業務を行う上での懸念事項や疑問点も書く
業務フロー図の段階でシステム化する範囲を決めてしまうと、本当はシステム化すべきではない業務を範囲に入れてしまったり、逆にシステム化すべき部分が未検討になる
その他は使わない
システム化するのは、効果が明確に説明できるところだけ
システム化する範囲は、本当にそこをコンピュータでやるべきか、何度も考えて決める
会社は各部門が有機的につながってこそ機能するということが、この1枚の図でよくわかる
社員やお客様さんがどんなふうに喜ぶのか、ちゃんとイメージして作ったか
自社の最大の強みにもっとこだわる
大事なことは社長かはも言うべき
サイトを使う人全員の立場になりきって、喜びとか苛立ちとかの感情を含めて全部共有しないと、本当に役に立つサービスを作ることはできない
業務フロー図には目的を書き込んでおく
懸念と理想も出来る限り書いておく
第1章まとめ
・システムを導入する目的を忘れないように書き留めておく
・業務フロー図には、懸念事項や課題とモレなく書き込む
・システムを導入して誰が喜び、誰が困るのかも書き込む
・システム化の範囲は、効果が明確に説明できる部分に限る
・システム担当者自身が、業務をどのように改善するかという「意識」を持つ
・システム担当者となったからには、自分の思いは隅に置いて、改善の推進者になりきる
要件定義で最低限確認すべきチェックリスト
134p135p
フィーリングマップ
139p
第2章まとめ
・システム担当者にはシステム化する対象業務の知識が必要
・発注者側の責任で頓挫したプロジェクトの賠償責任は発注者にある
・システム担当者がモチベーションを上げるにば、経営者の視点でシステム導入の意味や目的を考えてみるとよい
プロジェクト管理には、全体の工数の10%程��を見込んでおくべき
176〜179p
第3章まとめ
・ベンダの示すプロジェクト管理項目と管理工数が十分かを見極める
・信頼できるベンダは、自社内リスクも含めて、ユーザーと共有する
・要件の変更や追加を、ただ承諾するベンダにはプロジェクト管理義務違反の恐れがある
・ベンダの示すリスクを、まずは傾聴する
第4章まとめ
・システム担当者は、往々にしてエンドユーザーの協力が得られず孤立する
・エンドユーザーにヒアリングするときには、最低限の業務知識を得ておくこと
・難解なIT専門用語を使わない
・相手が忙しい中、時間を割いてくれていることに感謝する
・システム担当者が他部門と調整するときには、その上司がフォローと支援をする
・エンドユーザーの協力を得るには、システム開発の意義や目的について、経営トップからのメッセージングを繰り返す
・経営陣は、システム開発も社員全員の本業であるという意識づけとしくみの改革をすること
264〜269p
第5章まとめ
・ベンダにリスクを開示させるために、発注者側は真摯に聞く姿勢を忘れない
・ベンダのリスクもプロジェクトのリスクと同じように、発注者側が知るべきことと認識する
・ベンダのリスクは発注者側から引っ張り出す
・定量的なプロジェクト状況やスキル評価、工数の妥当性のほか、プロジェクトに合わせて設定した評価軸でベンダのリスクを評価する
287p
第6章まとめ
・期限までに要件を決めきれないことは日常茶飯事
・要件定義工程完了前に、「今後、どうすべきか?」を改めて話し合う、チェックポイント会議を開く
・ベンダへの質問に遠慮は不要。
技術でも業務でもどんどん聞くべき。
そうすることで、ベンダ側の知識が醸成されることもある
・たとえパッケージソフトを使うときでも、どうしてもこだわりたい自社の長所は捨てずに入れ込む
・発注者とベンダは、お互いに「自分たちのほうが損している」と思う程度がちょうどいい
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
生産管理システム構築の過程でシステム構築のポイントを整理したくて読んでみた書籍。
小説風のストーリー仕立ては、それほど面白くないが、要件定義のポイント整理やベンダとの向き合い方、リスク管理など各章のまとめページは、今後のシステム構築で迷ったときの立ち返るポイントリストとして使えるものだと感じた。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
タイトル通り・小説風 流し読み.
自責思想・「7・3で自分たちがちょっとやってやってるんだ」くらいの意気込みが大事.
関係者のフィーリング,キャリアパスまで考慮する
見えないリスクにアンテナを張る(時間,リスク源との距離,影響のブレ幅)
しかしこれを読んでいると仕事を感じて嫌になる.オフではなく勤務中に読ませてくれ,という気になる.
あと物語の茶番部分はうーん...という感じ.とっつきやすさを与えてくれているだけよしとする.
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
小難しい要件定義に関する本かと思っていたら、物語調で大変読みやすい。
システムを外注するというのは、決してシステム部門だけに降りかかってくる話ではないので、知っておいて損はないです。
分厚くみえますが物語調なのでサクッと読める。おすすめ。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
前書きの後急に登場人物紹介されて漫画展開が始まってビビったと思ったら、最後までラノベだった…
まとめは各章の終わりにあるけど、例としてのラノベ部分かほとんど。
ラノベなラノベらしいタイトルにして欲しい…
このタイトルでラノベ読むと、
システムを外注するときはベンダーには不躾で敬語なし、試すために恫喝してもおけ、って言ってるみたいだ。
途中からまとめだけ読んだ。
前職で何度か経験したいくつかの、ベンダーの情報統制と監視だけ一丁前で情熱と真心を感じない業務システムたちを思い出した。
一番大事なのは発注側と受注側の信頼関係だと思うが、そういう話はあんまりなく、後書きまでラノベのまま終わった。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
小説仕立てで読みやすい。Sl業界の知識が薄くてもすんなり読める。
ストーリーに陳腐な部分もあり、そこに気を取られてしまうこともあったが・・・。
各章の始まりと終わりにポイントがまとまられており、その部分で理解が深まる。
システム開発が実際どうやって進んでいくのか?というイメージも持てる。
逆にエンジニアの方が読むには物足りないのではないかと思う。
全体を読んでの感想としては、システム開発は関係者全員が我が事感を持って分け隔てなく意見を言い合って進めましょう、ということだと思う。
それを行う上で、目指すべき姿、改善しなければならない点、どうやって進めていくかという計画やアクションにおけるプロトコルを事前にしっかり決めておくことが大事なのだと感じた。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
導入企業側からITシステム構築プロジェクトのマネジメントのトラブルになりがちなところをストーリー仕立てで紹介した本。
入門書としては悪くない。実際の判例にも触れて、どのようなトラブルが起きうるか紹介している。顧客とのやり取りに慣れてない人だと得るものが多そう。
以下、参考になった点。
業務フローには業務を行う上で懸念事項や疑問点も書き込む。業務フロー図に、現状の問題点だけじゃなくて、自分たちのいいところとか残したい業務も書いて貼っておく。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
めっちゃ面白い。プロマネの仕事やりたくなる。業務ベースで起こりうる問題をストーリー仕立てで提示していて読みやすい。
71/100
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
要件定義過程において必要なポイントをストーリー形式で解説。先回りしてのリスク管理とリスクをユーザーとベンダで共有できる仕組みが必要。ベンダ側の注意点として気をつけなければいけないのは、合意なく成果物の開発に着手すること。成果物は随時合意することが重要。ユーザーのPJ目的に照らして、本件を超えた全社的な目標を頭に入れつつ会話をすることが+αに繋がるか。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
・要件定義
要件定義は業務要件定義(発注者作)とシステム要件定義(ベンダー作)がある。
業務要件定義とは、、
アズイズトゥービーを描くことで、どんな嬉しさがあるか?どんな懸念があるか?本当にやりたいことが実現できそうか?を整理する。★
システム化を考えるのはこれらの整理ができたあと。費用対効果が明確に得られる部分のみに絞る。範囲はあとから決める。
システム要件定義とは、、
機能要件、非機能要件を書くこと。
・スタートでは、2つ確認する。
①社内合意のために、社内関係者の感情と期待、懸念を整理すること。+②要件の必要性、十分性をチェックすること。
②は、要件定義で確認すべきことは、プロジェクトの目的と合っているか?目的を達成できる要素が過不足なく揃っているか?
・プロジェクト管理は、進捗管理、課題管理、リスク管理をすること。変更を振り返りできるようにする。スケジュールや要望が変わってヤバいと思った時点で追加提案する。
・
・
・・・・・・・・・・
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
本書は自分の会社や組織にシステムを導入しようとしている、システム担当者やプロジェクトマネージャーに向けて書かれています。小説のようなストーリー仕立てで、営業から新しいシステム作成の担当に抜擢された主人公と、外部のコンサルタントが協力して問題を解決していく中で何が大事なことなのかを学んでいけます。ストーリー自体は面白かったですし、著者が言いたい「システムの開発は、発注者とベンダの協業であるという」こともよく分かりました。システム企画に初めて関わる私のような立場であれば、最初の本としてはオススメだと思います。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
日頃のベンダー管理がうまくできていないと感じていたので、業務改善の参考にしたいと読んでみた。
ストーリーは置いておいて、物語仕立てなので、それぞれの立場でどう考えており、どんなことに気を付ければ良いかが、分かりやすく学べた。
特に自社内のリスクも含めて、ユーザーと共有することについて、考えさせられた。
言っても意味がないし、聞いてもらえないだろうと諦めてしまったことを思い出した。
このように、教科書に載っていないような、他人の失敗を疑似体験できる良い本だと感じた。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
ストーリー仕立てで、システム導入時の注意点が学べる本。
いまだに世間ではシステム導入は博打であり、当たるも八卦、当たらぬも八卦といった風潮が見られる。
しかし実際はベンダ側にknowledgeが蓄積されつつも、肝心の導入企業側の理解が高まっておらず、いまだに下請けを扱うかのような高慢な態度でシステム導入を進める結果、失敗しているケースが多い。
本書で書かれているような、業務フローの作成方法、そもそもの業務理解、ベンダ選定やその後のリスク管理、ベンダとの連携、社内協力、情報漏洩への対処、などを理解しておけば、大きな失敗は防げるのではなかろうか。