本棚登録 : 
感想 : 
- Amazon.co.jp ・本 (388ページ)
- / ISBN・EAN: 9784532323998
作品紹介・あらすじ
SEじゃないあなたのための
DX推進の教科書！
企業のDX推進でシステムを「作らせる技術」の重要性は増しています。
プログラマーやSEのような専門家だけがシステムについて考えればよいのではなく、「自分では作れなくとも、『作ってもらうノウハウ』」が必須の時代になったということです。
そのためには、
・「こんなシステムがあればいいのに」を構想し、
・「A機能とB機能、どちらを優先すべきか」を判断し、
・これを作るのにいくらまで投資する価値があるか？を見極め、
・作ってくれる人（社内の情報システム部門、または社外の専門ベンダー）を探し出し適切に依頼し、
・構築プロジェクトで沸き起こる様々な課題を解決
していかなければなりません。
本書はシステムに詳しくない業務担当者が、新しいビジネスを立ち上げるために、または既存の業務を改革するために、すべきこと／陥りやすい落とし穴を余すことなく書きます。
著者が20年以上にわたり支援してきた多くのプロジェクトでの事例やエピソードを詰め込んだ、実務家のための教科書です。
感想・レビュー・書評
-
良書 業務面から、すぐれた情報システムを構築するためにはどうすればいいのかが、利用者、導入企業の目によって描かれている書です。
システム、業務内容、スキル、進捗状況などなど、見えないづくしのシステム作りを可視化し、評価し、計画を立てるためのノウハウが集約されています。
もっと早く出会いたかったし、プログラマーなど、システム構築に関わる方にとって視野がひろがる内容だとおもいました。システム関連の方に是非ご一読をお勧めします。
過去、システム構築のトラブルに見舞われ、責任を負わされ、大切な友人、知人を自殺や病気で失い、職場から去っていった方も多くありました。
そんな難易度の高い仕事に、利用者目線でものさしを当ててもらっているのが本書だとおもいます。
使う人と作る人との役割や、責任が明確にされていること、各工程で作成される、成果物などが細かく解説されているのもいいと思います。
プロジェクトの成功の秘訣は、情報システムに明確な目的をもつこと、
要求定義は、使う人が主体で用意するもの、作る人はそのための支援をする
要件定義は、使う人と作る人が共同で行うもの
設計以降は、作る人が主体で行うもの
システム構築を８つのカテゴリーに分けて解説をしています
ゴール明確化 Ｃ章
現状調査分析 Ｄ
構想策定 Ｅ
要求定義 Ｆ～Ｍ
パートナ・製品選定 Ｎ～Ｒ
プロト検証 Ｓ
設計・開発・テスト Ｔ～Ｗ
導入 Ｘ
システムの導入は、Ｗｈｙ ⇒ Ｈｏｗ ⇒ Ｗｈａｔ で考えよ
全体をつらぬく重要なドキュメントがでてきます。
それは、ＦＭ：機能一覧
ＦＳ：機能詳細（機能ごとにその概要を記述したドキュメント）
この２つのドキュメントが、プロジェクト全体で活用されています。
データ移行の難易度、費用は想像以上の大きいこと
・現行システムの知識が必要
・新システムの知識が必要
・業務知識が必要
この３つを全てもっている人はどこの会社にもいない
ヘルプデスク、保守、運用については、一部非機能要件の項目にあったぐらいで別の書を参考にされたほうがいいと思います。
目次は、以下です。
Ａ章 作る前に知っておくべきこと
Ｂ章 プロジェクト全体の進め方
Ｃ章 ゴール（Ｗｈｙ）を明らかにする
Ｄ章 現状の棚卸しをする
Ｅ章 将来像（Ｈｏｗ）を明らかにする
Ｆ章 システム要求（Ｗｈａｔ）を決めるプロセス
Ｇ章 機能を洗い出す７つの方法
Ｈ章 要求をＦＭにまとめる
Ｉ章 要求の詳細をＦＳに表現する
Ｊ章 優先順位の基準を決める
Ｋ章 作る機能を決める
Ｌ章 ＦＭがシステム構築を成功に導く
Ｍ章 機能以外の要求を定義する
Ｎ章 パートナーの１次選定
Ｏ章 提案を依頼する
Ｐ章 パートナーを決定する
Ｑ章 稼働までの計画を立てる
Ｒ章 プロジェクトの投資決裁を得る
Ｓ章 課題を先出しする
Ｔ章 開発チームの立ち上げ
Ｕ章 キーチャート
Ｖ章 開発中の関与
Ｗ章 データ移行
Ｘ章 いよいよ新システムの稼働
Ｙ章 （補足）ベンチャーでのシステム構築
Ｚ章 （補足）ＦＭをシステム構築以外に応用する
8
詳細をみるコメント0件をすべて表示 -
職場の上司紹介されたのがきっかけで読みました✨（紹介され嬉しかった）
ちょうど、タイトルに関係するような業務に取り組んでおり、どのように進めるのが最適なのか迷っていたため、読みました(^^♪
今、職場で情報通信の「システム」を使っていない場所は少なく、必ず何かのシステムが職場では動いていると思います。
システム変更や新規導入に関わる際に読むと良いと感じました！
システムを作る側、作ってもらう側、それぞれ必要なことを知ることができ、活かすことができる。そんな1冊でした!(^^)!
2
-
220812
・再読。FMと呼ばれるFMTの効かせ方のイメージがより湧いた。基本的に依頼主がちゃんと動かないと成り立たない系の取組なんだろうか、実務工数どれぐらい用意させてるか気になった。
210817
・この半年で1番良かった。
・いわゆる業務要件の洗い出し×プロジェクト推進のノウハウが詰まっていた。
・自身でやっていることを違うやり方でうまくやっているところ、を知れ、有意義。
・やはり、優先度やカテゴリ分けのようなラベル付が1番難しいと感じる。本書でもcoolという単語に留まっており、言語化できてない箇所。これをちゃんと整理できるかがコンサル力、ということを再認識できた。
・これまでのPJT経験でやってたことも出てきて、良い棚卸しになった
2
-
作る側も読んだほうがいい本。
特に
・Whyの掘り下げ
・FM（Fanctionality Matrix）作成の進め方
・品質と精度の違い
に関する記述が印象に残った。
各フェーズでまた確認できるよう、手元に置いておきたい本。
コラムや実例についても興味深い内容が多く、他の著作についても読んでみたい。
1
-
システムを”作らせる”（ユーザ企業側）目線で書かれた，
システム開発系PJ成功指南所．
かなり割愛して読んだが，後書きにあった最後の一文が痺れた．
"本当は「作らせる人」も、「作る人」もいない。いるのは「プロジェクトを成功させ、会社を良くしたい」ともがく人々だけだ"
ベンダーだろうがユーザだろうが，この信念を持てるかどうか．ベンダーであれば要求の洗い出しや整理などユーザ主体の活動であっても「ユーザの責任範囲なんで」と他人事で見ないこと．ユーザであればシステムのことはわからない（わかるつもりもない）とベンダーに丸投げしないこと．
すなわち，他責にならないことが大事．
相手に多少踏み込み過ぎ？と思われるくらいが丁度いいかもしれない．だって「プロジェクトを成功させ会社をよくする」ためにもがいているんだから．
・PJには100％確実なものは何もない
・ユーザは業務のプロであって要求定義のプロではない．ユーザからシステムへの要求や制約を引き出させるのもエンジニアの仕事
・プロジェクトを停滞させる一番の敵は、厄介な課題、チームや部署を跨いで議論しなければ解決できないような課題
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
他人への説得論法
why → How → What
私たちは世界をかえる〜→その手段は〜→だから◯◯を作った。
一般人はどうしてもwhatから考える。だからストーリーがつまらない。
こんなソリューションを使う(what)→ベンダーに作ってもらおう(how )
工場を◯◯にしたい→◯◯が必要だ→こんなシステムが必要だ
プロジェクトは曖昧さ100%から曖昧さ0％の着地に向かって進む、不確実性が減り具体的になる
→★確実な情報を持ってこい！は傲慢。曖昧さを減らすために対話して意思決定を積み重ねる。
要件定義の難しさ
・検討漏れの発生
・要件を詰め込みすぎる→ビジネスライクに必要性を判断
総論賛成各論反対
良いプロジェクトのゴール
以後の工程で使える価値尺度がはいっている
(現状維持>新規性)
地に足がついている
わかりやすい
whyがこめられている
プロジェクトは初めての活動
→こうすればよかったは必ず出る
→完璧を目指す姿勢そのものが間違っている。
要求定義
→システムを作らせる人のwant
要件定義
→システムを作る人が、システムに必要とされる性能や機能を明確にする作業
設計
→要件を実現するための技術的な方法を決める作業
要求定義作成の難しさ
・網羅的な洗い出しができない
・予算オーバーになるって
・立場によって要求が異なる
★著者の会社の要求定義の定義
"要求定義とは利害関係者の意見をまとめて、実現すること・実現しないことを揺るぐなく定めること"
★ユーザは業務のプロであって要求定義のプロではない
→引き出す、ナビゲートするのもエンジニアの仕事
★全て洗い出す→優先順位をつけてやるやらないを線引きするところまでの客と握る
→スコープ(やる・やらないの線引き )を明確にして、あとになって「これも必要」と言わせない。やらないと分かっていても端折ったり捻じ曲げたりしない。
★網羅的に検討したんだぞという訴求
★恣意的ではなく合理的に選択したんだぞという訴求
コミュニケーション計画
★プロジェクトを停滞させる一番の敵は、厄介な課題、チームや部署を跨いで議論しなければ解決できないような課題
ファンクショナルマトリクス
縦軸に大きな流れやmeceな構成要素
横軸には各行を一段落として分解したもの
セキュリティの例: 対策領域×IDDRR
1
-
【めも】
・興味深い本だが、残念ながら索引が無い。詳細目次で多少は事足りるかも。
・章構成がA～Zで区分けされており、珍しい。
・「ケンブリッジ・テクノロジー・パートナーズ株式会社」は日本のコンサルティング企業の社名らしい。
ケンブリッジ大学と関係があるのか不明（ひょっとすると、ぱっと見「ハーバード……」に見間違えることで有名な「ハーバー・ビジネス・オンライン」のような、虎の威ネーミングなのかもしれない）。
[https://www.ctp.co.jp/company/information/]
[https://ja.wikipedia.org/wiki/%E3%82%B1%E3%83%B3%E3%83%96%E3%83%AA%E3%83%83%E3%82%B8%E3%83%BB%E3%83%86%E3%82%AF%E3%83%8E%E3%83%AD%E3%82%B8%E3%83%BC%E3%83%BB%E3%83%91%E3%83%BC%E3%83%88%E3%83%8A%E3%83%BC%E3%82%BA]
【書誌情報】
『システムを作らせる技術――エンジニアではないあなたへ』
著者：白川克 コンサルタント
著者：濵本佳史 コンサルタント
定価：2,860円（税込）
発売日：2021年07月27日
ISBN：978-4-532-32399-8
並製/A5判/388ページ
形態：書籍 電子書籍
分野：経営、ビジネス実務
［PR文］
企業のDX推進でシステムを「作らせる技術」の重要性は増しています。プログラマーやSEのような専門家だけがシステムについて考えればよいのではなく、「自分では作れなくとも、『作ってもらうノウハウ』」が必須の時代になったということです。
そのためには、
・「こんなシステムがあればいいのに」を構想し、
・「A機能とB機能、どちらを優先すべきか」を判断し、
・これを作るのにいくらまで投資する価値があるか ?
を見極め、
・作ってくれる人(社内の情報システム部門、または社外の専門ベンダー)を探し出し適切に依頼し、
・構築プロジェクトで沸き起こる様々な課題を解決
していかなければなりません。
本書はシステムに詳しくない業務担当者が、新しいビジネスを立ち上げるために、または既存の業務を改革するために、すべきこと／陥りやすい落とし穴を余すことなく書きます。著者が20年以上にわたり支援してきた多くのプロジェクトでの事例やエピソードを詰め込んだ、実務家のための教科書です。
〈https://nikkeibook.nikkeibp.co.jp/item-detail/32399〉
【簡易目次】
はじめに
A章 作る前に知っておくべきこと
B章 プロジェクト全体の進め方
C章 ゴール（Why）を明らかにする
D章 現状の棚卸しをする
E章 将来像（How）を明らかにする
F章 システム要求（What）を決めるプロセス
G章 機能を洗い出す7つの方法
H章 要求をFMにまとめる
I章 要求の詳細をFSに表現する
J章 優先順位の基準を決める
K章 作る機能を決める
L章 FMがシステム構築を成功に導く
M章 機能以外の要求を定義する
N章 パートナーの1次選定
O章 提案を依頼する
P章 パートナーを決定する
Q章 稼動までの計画を立てる
R章 プロジェクトの投資決裁を得る
S章 課題を先出しする
T章 開発チームの立ち上げ
U章 キーチャート
V章 開発中の関与
W章 データ移行
X章 いよいよ新システムの稼動
Y章 〔補足〕ベンチャーでのシステム構築
Z章 〔補足〕FMをシステム構築以外に応用する
おわりに
【詳細目次】
https://contents-memo.hatenablog.com/entry/20221005/1664895600
1
-
書評が結構厳しいが、いい内容だと思った。私は作らせる側と作る側の間のような立場だが、改めてこうまとめてもらうとありがたい。またウォーターフォール世代だが、さすがにアジャイルで開発する内容でもないので、このケンブリッジRADの考え方は大変参考になった。
1
-
たしかに本書の通りに
・whyhow#whatを明確にして
・関係者を適切に巻き込み
・会社と部署の垣根を超えてワンチームで取り組めば
不毛なプロジェクトを減らせるであろうと思える一冊。
システム開発に関わる人には必読の書と思う。
とくに、ユーザ企業や一時受けになるITベンダ向け。
0
-
業務側として大きな案件のシステム担当になり、要件定義〜立ち上げまで経験した。利用者への理解活動や開発の手戻り（検討漏れ）に苦労し、正解はなんだろうと思っていたが、本書には正解に繋がるエッセンスが散りばめられていた。
0
著者プロフィール
白川克の作品
この本を読んでいる人は、こんな本も本棚に登録しています。
