細川義洋のレビュー一覧

会社のシステム変更の勉強のため購入。

ベンダー、ユーザー、両方に通じる内容なので役に立った。
基本的な知識、心構えなど。

要件定義過程において必要なポイントをストーリー形式で解説。先回りしてのリスク管理とリスクをユーザーとベンダで共有できる仕組みが必要。ベンダ側の注意点として気をつけなければいけないのは、合意なく成果物の開発に着手すること。成果物は随時合意することが重要。ユーザーのPJ目的に照らして、本件を超えた全社的...続きを読むな目標を頭に入れつつ会話をすることが+αに繋がるか。

導入企業側からITシステム構築プロジェクトのマネジメントのトラブルになりがちなところをストーリー仕立てで紹介した本。
入門書としては悪くない。実際の判例にも触れて、どのようなトラブルが起きうるか紹介している。顧客とのやり取りに慣れてない人だと得るものが多そう。
以下、参考になった点。
業務フローには...続きを読む業務を行う上で懸念事項や疑問点も書き込む。業務フロー図に、現状の問題点だけじゃなくて、自分たちのいいところとか残したい業務も書いて貼っておく。

小説仕立てで読みやすい。Sl業界の知識が薄くてもすんなり読める。
ストーリーに陳腐な部分もあり、そこに気を取られてしまうこともあったが・・・。
各章の始まりと終わりにポイントがまとまられており、その部分で理解が深まる。
システム開発が実際どうやって進んでいくのか？というイメージも持てる。
逆にエ...続きを読むンジニアの方が読むには物足りないのではないかと思う。

全体を読んでの感想としては、システム開発は関係者全員が我が事感を持って分け隔てなく意見を言い合って進めましょう、ということだと思う。
それを行う上で、目指すべき姿、改善しなければならない点、どうやって進めていくかという計画やアクションにおけるプロトコルを事前にしっかり決めておくことが大事なのだと感じた。

小難しい要件定義に関する本かと思っていたら、物語調で大変読みやすい。
システムを外注するというのは、決してシステム部門だけに降りかかってくる話ではないので、知っておいて損はないです。
分厚くみえますが物語調なのでサクッと読める。おすすめ。

生産管理システム構築の過程でシステム構築のポイントを整理したくて読んでみた書籍。
小説風のストーリー仕立ては、それほど面白くないが、要件定義のポイント整理やベンダとの向き合い方、リスク管理など各章のまとめページは、今後のシステム構築で迷ったときの立ち返るポイントリストとして使えるものだと感じた。

システムを外部のベンダーさんと一緒に開発したことは何度か経験あるけども、
外注をしておまかせすれば、思った通りに夢を叶えてくれるわけではない。
注文した側も、きちんと責任と役割を分担して進めていかないと、いけないんだよね。

これって、システムに限らず人にものを頼むときもそうだと思う。
丸投げして、...続きを読むあとでチガーウ！と言われても、頼んだ方の責任も大きいよね。

　「業務フローに社員の感情を書き込め」にはハッとした。全体最適を考えるとどうしても負荷が増える部門が発生してしまうが、特に経営陣に説明するときに使えると感じた。他にも「ベンダー内のトラブルも言ってもらえるような関係性を構築する」などシステムを外注している情報システム部門担当者は一読しておくと良い。,...続きを読む　当然、ストーリー通りにいかないケースは多数あるが、この本を「基本」とすると良いのではないか。

情報システム構築を発注する側の人間が奮闘する内容でオムニバス形式のストーリ仕立てになっています。（ただしメインの登場人物は同じ）

世の中に出回っている情報で、発注側の視点に立ったときに参考になるものは意外と少ないのが現状です。
本書は、システム企画や構築を外部に発注する経験が少ない人や、経験はある...続きを読むけれどなかなか上手くいかずモヤモヤを抱えている人向けに、システム導入プロジェクトを推進するにあたって重要なポイントが提示されています。
また、発注側だけでなくベンダーが果たすべき義務についても触れており、ベンダー側の人が読んでも得るものは多いと思います。

ただ、本書はあくまで要点を紹介しているだけなので、プロジェクトを回すための実務レベルの情報については、それ相応の書籍等をあたることをお勧めします。

業務要件定義：新しくシステムを導入して、どんな業務を実現するのかを決める作業
システム要件定義：業務要件定義書に書いたことを実現するために、システムが持つべき機能を書き出す作業
いずれも発注者が行う作業
特に業務要件定義は、発注者自身が全面的にリードしないといけない。社外ベンダには分からないことが多...続きを読むいため
業務要件定義書を書くより前にやらないといけないこと、社内全体の業務を俯瞰して、全体最適の視点から、業務の問題点や新しいシステムが実現することで改善される点、全社的なメリットなどがひと目でわかる資料を作成すること。
業務フロー図を作成すること。業務フロー図には、さまざまなメモ書きをしていかないと、最終的には役に立たないシステムになる

機能要件：システムができること・できないことを具体的に明らかにする作業。この不備はトラブルの原因のワースト1

まずは現状のながれ、As- Isと、その問題点を明らかにして、それを解決する業務の姿、T o-Beを書く、２つの業務フロー図並べて見ることで、業務のプロセスや組織をどう変えるのか、そしてどの業務をシステム化すべきかが初めて明らかになる

業務を行う上での懸念事項や疑問点も書く
業務フロー図の段階でシステム化する範囲を決めてしまうと、本当はシステム化すべきではない業務を範囲に入れてしまったり、逆にシステム化すべき部分が未検討になる
その他は使わない
システム化するのは、効果が明確に説明できるところだけ
システム化する範囲は、本当にそこをコンピュータでやるべきか、何度も考えて決める
会社は各部門が有機的につながってこそ機能するということが、この1枚の図でよくわかる

社員やお客様さんがどんなふうに喜ぶのか、ちゃんとイメージして作ったか
自社の最大の強みにもっとこだわる
大事なことは社長かはも言うべき
サイトを使う人全員の立場になりきって、喜びとか苛立ちとかの感情を含めて全部共有しないと、本当に役に立つサービスを作ることはできない
業務フロー図には目的を書き込んでおく
懸念と理想も出来る限り書いておく

第1章まとめ
・システムを導入する目的を忘れないように書き留めておく
・業務フロー図には、懸念事項や課題とモレなく書き込む
・システムを導入して誰が喜び、誰が困るのかも書き込む
・システム化の範囲は、効果が明確に説明できる部分に限る
・システム担当者自身が、業務をどのように改善するかという「意識」を持つ
・システム担当者となったからには、自分の思いは隅に置いて、改善の推進者になりきる

要件定義で最低限確認すべきチェックリスト
134p135p
フィーリングマップ
139p

第2章まとめ
・システム担当者にはシステム化する対象業務の知識が必要
・発注者側の責任で頓挫したプロジェクトの賠償責任は発注者にある
・システム担当者がモチベーションを上げるにば、経営者の視点でシステム導入の意味や目的を考えてみるとよい

プロジェクト管理には、全体の工数の10％程度を見込んでおくべき
176〜179p
第3章まとめ
・ベンダの示すプロジェクト管理項目と管理工数が十分かを見極める
・信頼できるベンダは、自社内リスクも含めて、ユーザーと共有する
・要件の変更や追加を、ただ承諾するベンダにはプロジェクト管理義務違反の恐れがある
・ベンダの示すリスクを、まずは傾聴する

第4章まとめ
・システム担当者は、往々にしてエンドユーザーの協力が得られず孤立する
・エンドユーザーにヒアリングするときには、最低限の業務知識を得ておくこと
・難解なIT専門用語を使わない
・相手が忙しい中、時間を割いてくれていることに感謝する
・システム担当者が他部門と調整するときには、その上司がフォローと支援をする
・エンドユーザーの協力を得るには、システム開発の意義や目的について、経営トップからのメッセージングを繰り返す
・経営陣は、システム開発も社員全員の本業であるという意識づけとしくみの改革をすること

264〜269p
第5章まとめ
・ベンダにリスクを開示させるために、発注者側は真摯に聞く姿勢を忘れない
・ベンダのリスクもプロジェクトのリスクと同じように、発注者側が知るべきことと認識する
・ベンダのリスクは発注者側から引っ張り出す
・定量的なプロジェクト状況やスキル評価、工数の妥当性のほか、プロジェクトに合わせて設定した評価軸でベンダのリスクを評価する

287p
第6章まとめ
・期限までに要件を決めきれないことは日常茶飯事
・要件定義工程完了前に、「今後、どうすべきか？」を改めて話し合う、チェックポイント会議を開く
・ベンダへの質問に遠慮は不要。
技術でも業務でもどんどん聞くべき。
そうすることで、ベンダ側の知識が醸成されることもある
・たとえパッケージソフトを使うときでも、どうしてもこだわりたい自社の長所は捨てずに入れ込む
・発注者とベンダは、お互いに「自分たちのほうが損している」と思う程度がちょうどいい

前著と同様にITシステムを発注するときのトラブルを物語形式で紹介している本。典型的なケースがいくつか取り上げられている。ITシステムの発注に特有なことも多いが、開発やデザインを外注するときにも該当することが多い。社内では、自分ではりかいできないようなことでも、とにかく金を払って外注すればやってくれる...続きを読む、のような考え方がいまだに多く、相変わらずトラブルが続発している。

「なぜ、システム開発は必ずモメるのか？」の著者と同じということに気づかず、タイトルのみで手に取った。
前回が訴訟ベースで深掘りが浅い部分が多かったが、本書では事例ベースの話で、よりわかりやすかった。APPENDIXの内容は、プロジェクト発足当初に皆で意識合わせしておいた方がよいものが多く、プロジェク...続きを読むトマネージャーを任せられた方が最初に読むにはいいボリューム感の本だと感じた。
ただ、前書と同じく、ラノベ形式でストーリーが進行するので、ベンダーとの契約内容など、もう少し詳しい部分は別の本で補完する方がよさそうである。

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

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

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

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

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

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

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

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

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

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

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

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

システムの発注者側としての注意すべき要点について、網羅的ではないが有用な視点が書かれている。

良い点として、小説仕立てで取っつきやすいという点と、あまり他のこの手の本では書かないようなリスク管理の考え方の話が参考になりそう。

登場人物のITコンサルの女性が現実離れしたキャラクター設定なのはアレだ...続きを読むが(20代の設定には無理がある、あとクライアントにこんな失礼な態度取る奴は普通いない)

フィーリングマップはこの本で初めて知った手法だが、キャッチーで面白そうだと思った。実務で使ってみたい。

基本的なことで、頭ではわかっていることが中心。
ただ、実際は工数の関係やコミニュケーション不足で、できてないことも多い。
発注者、ベンダーで立ち位置は異なっても、プロジェクトを成功させるために、お互い意見を交換して、進めていくことが大切。

Appendixに価値がある。発注者の役割や要件定義のチェックリスト、プロジェクト計画書に盛り込むべき項目に、リスクを洗い出すときのチェックリスト等。

全体的に外注する場合の注意点として、主にリスク管理に重点を置かれている。特に、発注者側のベンダの内部に潜むリスクへの対応の仕方やスタンスは参考にす...続きを読むる価値あり。

ただ、ストーリーはやや冗長でコスパは若干悪い。

例題部分は読み物として物足りなさはあったけど、実用書としては私に土地勘もないので手ごろに役立ちそう。しかしまあシステム関係が地獄になりがちなのはこういう原因があるからなのね。