あらすじ
SEじゃないあなたのための
DX推進の教科書！
企業のDX推進でシステムを「作らせる技術」の重要性は増しています。
プログラマーやSEのような専門家だけがシステムについて考えればよいのではなく、「自分では作れなくとも、思い通りのシステムを『作ってもらうノウハウ』」が必須の時代になったということです。
そのためには、
・「こんなシステムがあればいいのに」を構想し、
・「A機能とB機能、どちらを優先すべきか」を判断し、
・これを作るのにいくらまで投資する価値があるか？を見極め、
・作ってくれる人（社内の情報システム部門、または社外の専門ベンダー）を探し出し適切に依頼し、
・構築プロジェクトで沸き起こる様々な課題を解決
していかなければなりません。
本書はシステムに詳しくない業務担当者が、新しいビジネスを立ち上げるために、または既存の業務を改革するために、すべきこと／陥りやすい落とし穴を余すことなく書きます。
著者が20年以上にわたり支援してきた多くのプロジェクトでの事例やエピソードを詰め込んだ、実務家のための教科書です。
感情タグBEST3
Posted by ブクログ
システム開発のプロジェクトにこれから関わる人にとっては分かりやすさ、具体性、網羅性があって教科書として使える。教科書なので今後も必要な部分を何度も読みたい。
Posted by ブクログ
クライアントの人事評価システム導入検討をやることになりそうで、以前、妻が買っていたものを読んでみた。ちゃんとやろうと思うとなかなか大変だ…というのが分かって良かった。話が進んだら、この本を頼りに頑張ろう。
Posted by ブクログ
システムを「作らせる」立場で読んだが、豊富な事例（主に失敗談）を通じてシステム構築にどのように関与さていくかについて知見が深まった。
・Why が最重要で常に立ち返る
・Why→How→Whatの順で進める
あとがきの言葉で、本当はシステムを「作らせる」人も「作る」人もいるわけではなく、システム構築を成功させたい人がいるだけというのが強く印象に残った。
Posted by ブクログ
ざっくり感想、ステークホルダーとのコミュニケーションと情報整理が大事なんだと思いました。経験談も記載があり、リアリティを持って読むことができました。当方ITエンジニアですが、読んでよかったと思いました。
Posted by ブクログ
勤めている会社のシステムがあまりにもアナログで非効率が目立つので「何とかしたい」と思っていた今の自分にズバリ刺さってきた本。副題に「エンジニアではないあなたへ」とあるように、システムを変える・構築するプロジェクトを動かす者が心がけなければならないことが、実務面も含めて説明されている。
技術的なことは難しい（エンジニアに任せるしかない）が、エンジニアという人種やシステム会社の考え方、立ち位置をよくよく理解していないとコミュニケーションギャップにつながり、それが致命的なミスを招く。ビジネス書の類は失敗談はほんの少しで成功談ばかり書く方が多いが、本書は失敗談が半分近く、かなり生々しく人間の心理にまで踏み込んで事例が出されており、かなり参考になる。システム構築とは完璧はありえず、それも織り込んだプロジェクト進行が必要だと理解できた。
極めて専門性の高い分野を「使いこなす」力量と共に、覚悟と調整力、全体を俯瞰する力が問われる。今自分がやろうとしていることのバイブルになり得る一冊だった。
Posted by ブクログ
データアナリスト職です。BI帳票を開発業務として取り組んだ経験がなかったため開発工程を体系的に知るのは初めてでした。
BI帳票を開発業務として取り組むと工程が多くなりスピード感が失われ、ビジネスの期待値に届かない事が多い思いを持っていたのですが、これまでの歴史が積み重ねてきた開発のノウハウがBI帳票開発にも応用することで活きるケースがあると感じました。
例えば、開発機能（帳票）の優先順位を機械的にジャッジすることで既存帳票の現状踏襲を防ぐ。いまある帳票は数値を今まで見れていたからと無批判に作ってしまうことを防ぐ。そうした進め方ややり方もあるという学びがあります。
読んだ上でBI帳票作成の全てが開発工程に当てはめて進めること自体は是々非々で柔軟にやるべきだと思うが（TooMuchな部分があるので）Whyから始めるなど開発工程のスキームがBI帳票作成品質の底上げに繋がると思う
また、こうした本はいかに現場の課題感や失敗の生々しさを表現できるかが鍵だと思います。その中で書籍という形式上どうしても生々しさの表現が難しく目減りしてしまうことが多いが、可能な限り現場や実務の生々しさが伝わるように記載されていて良かった。生々しさを担保するコラムにこそ価値があると感じます。
Posted by ブクログ
Cambridge RAD という、ウォーターフォールとアジャイルの中間的なシステム開発&導入手法について述べた書籍だ。本書の中では特に要求定義のCambridge RAD版である「Scopeフェーズ」のくだりが素晴らしかった。中盤まるまる「社内調整が捗るような要求定義のスプシまとめ」のノウハウに費やされており、(1)｛ビジネスベネフィット, 組織受入体制, 技術的容易性｝の三項目別に優先度｛High, Middle, Low｝を決め、(2) その優先度の総合点に応じて｛優先的にやる（白）, 遅れてやる（灰）, やらないとキッパリ伝える（黒）｝の三色に塗り分け、(3) 社内関係者を説得するために最終的な説得用の表資料をつくりあげる（FM: Functionality Matrix）という手順を伝えてくれる。このpp. 095–196の内容を読めただけでもこの本を手に取った甲斐があった。
その前後には、社内要望を掬い取ること、ベンダを選定してうまく作ってもらうこと、それぞれの過程についてノウハウを開示しているが、それは他の本でも書かれてあることだ（この本でもそれぞれのくだりを丁寧に書いてくれていることは評価するが）。しかし要求定義についてここまでしっかり書いてくれていた本はなかなか見つからなかった。届くべき人に届いて欲しい本だ。
著者の指定姉妹本には『業務改革の教科書』が挙げられており、その本を読んでみたくなった。
惜しい点としては、記載されるExcelの印刷解像度が低すぎること。ここはスクリーンショットをもう少し綺麗にやってほしかった。
Posted by ブクログ
たしかに本書の通りに
・whyhow#whatを明確にして
・関係者を適切に巻き込み
・会社と部署の垣根を超えてワンチームで取り組めば
不毛なプロジェクトを減らせるであろうと思える一冊。
システム開発に関わる人には必読の書と思う。
とくに、ユーザ企業や一時受けになるITベンダ向け。
Posted by ブクログ
職場の上司紹介されたのがきっかけで読みました✨（紹介され嬉しかった）
ちょうど、タイトルに関係するような業務に取り組んでおり、どのように進めるのが最適なのか迷っていたため、読みました(^^♪
今、職場で情報通信の「システム」を使っていない場所は少なく、必ず何かのシステムが職場では動いていると思います。
システム変更や新規導入に関わる際に読むと良いと感じました！
システムを作る側、作ってもらう側、それぞれ必要なことを知ることができ、活かすことができる。そんな1冊でした!(^^)!
Posted by ブクログ
ものすごく役に立つことが書いてある本。
データ移行は大変だよとちゃんと書いてある！
「カネと労力を使っても、使われないシステム、使えないシステムは最悪」は、私も実体験としてあるので、この本の「関係者をいかに巻き込むか」の方法論は本当に助かる。PMBOKかじり程度なりに、私が「使われないシステムは最悪」の信念でやってきたことの答え合わせができた感じ。間違ってなかったし、さらにステージが上げられる。
この内容をシェアしてくれる著者、ありがたい。早速FMは仕事で作ってみたし、今進めているプロジェクトで巻き込まないといけない人たちの顔が浮かんだし、地道にコツコツやらないといけないことへの覚悟ができた。
Posted by ブクログ
作る側も読んだほうがいい本。
特に
・Whyの掘り下げ
・FM（Fanctionality Matrix）作成の進め方
・品質と精度の違い
に関する記述が印象に残った。
各フェーズでまた確認できるよう、手元に置いておきたい本。
コラムや実例についても興味深い内容が多く、他の著作についても読んでみたい。
Posted by ブクログ
世はDXブームだ。ITに対して苦手感があった自分でさえ、本業として関わらざるを得なくなるほどのDXブームである。組織や人によって課題は様々だろうが、新規システム開発を担当することになった人も多いに違いない。「システムなんて誰かが用意してくれたものを使うだけだったのに、作る側の仕事なんて…」という人も多いに違いない。そんな人にこそ本書をお勧めしたい。一通り読むだけで全てが理解できるというわけにはいかないが、システム開発のプロセスを疑似体験することはできるだろう。あまりの大変さに、まずますブルーになってしまうかもしれないが。
Posted by ブクログ
思ったよりボリュームがあり、とりあえずp.94まで心に残ったことをメモ。
・真っ先に具体化すべきことはなにか？
・現時点でどの程度具体化すべきか？
→社内でプロセス化ができいるベンダーほど、意外と意識できてない視点だと思った。プロセスはあってもプロジェクト単位で個々に検討しないとね、というのを改めて本文で指摘された気がした。
・why→how →what
・p.36 システムをどのくらい導入する場合のメリットデメリットをパターンする作業、導入範囲とコストの天秤
→この判断はシステム作る側は判断できないのに、その判断を押し付ける顧客側の多いこと！うんうん唸ってしまった。
・p.55 導入したらビジネスはどう変わるのか、それはなぜ嬉しいのか？
→わかりやすい問いでいいなと思ったのでメモ。
Posted by ブクログ
システムを作る側としても、作らせる側に知って欲しい、やって欲しいことが、実践できるテンプレに落とし込まれていて、とても良い。作る側の会社でも、新人や営業の人に顧客対応で戦力になってもらえるよう実践できるようになって欲しい内容。作らせる側が、作る側をどう見るのかという点でも、この本の評価軸で、作る側の会社として自社はイケてるのかチェックできる。大手SIerには、仕事の型が用意されてるので、この本の内容は社内教育で得られるかも知れないが、そんな余力がないとこなら、まずは最初に実践の型として採用するのも良いような気がする。
Posted by ブクログ
220812
・再読。FMと呼ばれるFMTの効かせ方のイメージがより湧いた。基本的に依頼主がちゃんと動かないと成り立たない系の取組なんだろうか、実務工数どれぐらい用意させてるか気になった。
210817
・この半年で1番良かった。
・いわゆる業務要件の洗い出し×プロジェクト推進のノウハウが詰まっていた。
・自身でやっていることを違うやり方でうまくやっているところ、を知れ、有意義。
・やはり、優先度やカテゴリ分けのようなラベル付が1番難しいと感じる。本書でもcoolという単語に留まっており、言語化できてない箇所。これをちゃんと整理できるかがコンサル力、ということを再認識できた。
・これまでのPJT経験でやってたことも出てきて、良い棚卸しになった
Posted by ブクログ
システムを作らせる技術
A章作る前に知っておくべきこと
・関係者。経営陣、業務部門、PLが作らせる人。IT部門とそれに紐づくベンダーが作る人。
・why？→how？→whatでストーリーを納得させる。例）工場ごとにバラバラな業務を統合し、一つの会社として運営すべき→統合後の業務プロセスはこうあるべき→そのためにこういうシステムを作ろう
・whatから考えるのでなく、whyから考える。
B章プロジェクト全体の進め方
・メンバー間の意識を合わせる（C章）
・今の仕組みを調べる。ここまでがwhy（D章）
・howにあたる3つを行う。ビジョンを明らかに、そこに到達するための施策を練る、施策群をまとめて1つの計画立案（E章）
・どんなシステムが必要か（F〜M章）
・ベンダー選定（N〜R章）
・プロトタイプ検証（S章）
・システム設計やデザイン（T〜W章）
・切替作業（X章）
C章 ゴール(Why)を明らかにする
・良いプロジェクトゴールづくりの4つのコツ
以降の工程で使えるゴールにせよ
地に足のついたゴールにせよ
何のためのプロジェクトかゴールやコンセプトに込めよ
ゴールのわかりやすさにこだわれ
D章 現状の棚卸をする
・今のシステムの棚卸しを、スイムレーンチャートわタスク一覧表、全体システム構成図などなどから把握
E章 将来像(How)を明らかにする
・システムが変わったらどういう絵姿になっているか？という将来像を描く
・変化点を必ず書き出し、メインフローや概要から取り掛かる
F章 システム要求(What)を求めるプロセス
・要求定義はシステムを作らせる人が求めることを明確にすること。要件定義はシステムを作る人が実装すべき機能を明確にすること。
・網羅性がない、予算オーバーになる、立場が違えばシステムに求めるものが違うなどから、要求定義は難しい
・要求定義の成果物。
FM（ファンクショナリティ・マトリクス）H章で。
非機能要求定義書（M章）
キーチャート
G章 機能を洗い出す7つの方法
・要件定義の第一歩はシステムに求めることについて片っ端から要求を書き出す作業。現行フローや業務フローから洗い出すのも良し。
H章 要求をFMにまとめる
・前章で洗い出した項目を整理。グループに分けて並べて…（サイトなども参考に）
I章 要求の詳細をFSに表現する
・先の項目に対して、具体的に書く。FSファンクション・スペック。
・FSに書くこと。実現したいこと、扱う情報、他の機能との関連、バリエーションやイレギュラー
・FSに書かないこと。実装方法、画面イメージ。
J章 優先順位の基準を決める
・FSにおける優先順位はビジネスベネフィット（ビジネス上どれほど価値があるか？）組織受入体制（そのシステムをどれほど使いこなせるか？）、技術的容易性の3点を3段階評価で決める。
→セルごとに色分け
K章 作る機能を決める
・先の優先度が高いレーティングの機能から作る。
L章 FMがシステム構築を成功に導く
M章 機能以外の要求を定義する
・非機能要求おアーキテクチャの議論が必要。
・非機能要求仕様定義ガイドライン参照。
・システムアーキテクチャの３つのポイント。パッケージか手作りか、オンプレかクラウドか、複数システム間の連携
N章 パートナーの1次選定
O章 提案を依頼する
P章 パートナーを決定する
Q章 稼働までに計画を立てる
・ベンダーから全体スケジュールが展開されるが、そのまま採用するわけにはいかない。精査が必要。
マストな期限が守られているか、業務繁忙期とシステム構築のピークは重なっていないか、工程ごとのゴールが明確か、成果物をチェックするマイルストーンはあるか、各領域の整合が取れているか、各フェーズの期間バランスが適切か
・テストも誰がやるのか、何のテストか確認が必要。どの工程でも、どこまでやったら次の工程に進めるのか、工程ごとに確認を
R章 プロジェクトの投資決裁を得る
・費用対効果のシミュレーションを行う。不確実性があるので、数回行いブラッシュアップを
S章 課題を先出しする
・要求定義に相対するユーザー受入テスト。プロトタイプを使ったチェックでBPPと言われる
T章 開発チームの立ち上げ
U章 キーチャート
V章 開発中の関与
W章 データ移行
X章 いよいよ新システムの稼働
Posted by ブクログ
･類書少ないので、参考になった。
･A～Zの章立てが分かりづらい(大きい見出しもあるが、そこは目次になっていない)
･経験と知識が足りないからか、しっくりこない点あり(ユーザー企業に代わっての作らせる側の立場で書かれているからかも)
Posted by ブクログ
あのプロジェクトのときここまで丁寧にこちらからも確認していたらもっと手間減らせたなあ、、
とか、逆にお客さんのあの態度はなかったよなあ、、とか思い浮かんでいった。
これを参考に1からプロジェクトやってみたいな。
Posted by ブクログ
業務側として大きな案件のシステム担当になり、要件定義〜立ち上げまで経験した。利用者への理解活動や開発の手戻り（検討漏れ）に苦労し、正解はなんだろうと思っていたが、本書には正解に繋がるエッセンスが散りばめられていた。
Posted by ブクログ
システムを構築する上で踏むべき手順が、わかりやすく書かれていると感じました。
システム改修の最中にこの本を紹介された際は読む余裕がなく、再雇用後に読むこととなりましたが、これからの業務改革にも使えそうです。
Posted by ブクログ
何らかの業務課題を解決するため、システム開発を外注する場合に必要な一連のアクティビティ（コンセプト設計から運用まで）が掴める。システム開発に取り組むチーム員と読んでおくと、認識を合わせる上で非常に有用だと感じた。
Posted by ブクログ
題目の通り、システムを作らせる導入側の担当者視点に立って書かれた本。導入側で書かれているが、売り込む側として読んでも参考になる。ここに着目した書籍は他のテーマと比べて少なく、差別化がはかれてる書籍だと感じた
ざっと一通り読んだだけでは理解は少ないので、何度も読み返し、自分の言葉で説明できるようになっておきたい。
Posted by ブクログ
システムを”作らせる”（ユーザ企業側）目線で書かれた，
システム開発系PJ成功指南所．
かなり割愛して読んだが，後書きにあった最後の一文が痺れた．
"本当は「作らせる人」も、「作る人」もいない。いるのは「プロジェクトを成功させ、会社を良くしたい」ともがく人々だけだ"
ベンダーだろうがユーザだろうが，この信念を持てるかどうか．ベンダーであれば要求の洗い出しや整理などユーザ主体の活動であっても「ユーザの責任範囲なんで」と他人事で見ないこと．ユーザであればシステムのことはわからない（わかるつもりもない）とベンダーに丸投げしないこと．
すなわち，他責にならないことが大事．
相手に多少踏み込み過ぎ？と思われるくらいが丁度いいかもしれない．だって「プロジェクトを成功させ会社をよくする」ためにもがいているんだから．
・PJには100％確実なものは何もない
・ユーザは業務のプロであって要求定義のプロではない．ユーザからシステムへの要求や制約を引き出させるのもエンジニアの仕事
・プロジェクトを停滞させる一番の敵は、厄介な課題、チームや部署を跨いで議論しなければ解決できないような課題
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
他人への説得論法
why → How → What
私たちは世界をかえる〜→その手段は〜→だから◯◯を作った。
一般人はどうしてもwhatから考える。だからストーリーがつまらない。
こんなソリューションを使う(what)→ベンダーに作ってもらおう(how )
工場を◯◯にしたい→◯◯が必要だ→こんなシステムが必要だ
プロジェクトは曖昧さ100%から曖昧さ0％の着地に向かって進む、不確実性が減り具体的になる
→★確実な情報を持ってこい！は傲慢。曖昧さを減らすために対話して意思決定を積み重ねる。
要件定義の難しさ
・検討漏れの発生
・要件を詰め込みすぎる→ビジネスライクに必要性を判断
総論賛成各論反対
良いプロジェクトのゴール
以後の工程で使える価値尺度がはいっている
(現状維持>新規性)
地に足がついている
わかりやすい
whyがこめられている
プロジェクトは初めての活動
→こうすればよかったは必ず出る
→完璧を目指す姿勢そのものが間違っている。
要求定義
→システムを作らせる人のwant
要件定義
→システムを作る人が、システムに必要とされる性能や機能を明確にする作業
設計
→要件を実現するための技術的な方法を決める作業
要求定義作成の難しさ
・網羅的な洗い出しができない
・予算オーバーになるって
・立場によって要求が異なる
★著者の会社の要求定義の定義
"要求定義とは利害関係者の意見をまとめて、実現すること・実現しないことを揺るぐなく定めること"
★ユーザは業務のプロであって要求定義のプロではない
→引き出す、ナビゲートするのもエンジニアの仕事
★全て洗い出す→優先順位をつけてやるやらないを線引きするところまでの客と握る
→スコープ(やる・やらないの線引き )を明確にして、あとになって「これも必要」と言わせない。やらないと分かっていても端折ったり捻じ曲げたりしない。
★網羅的に検討したんだぞという訴求
★恣意的ではなく合理的に選択したんだぞという訴求
コミュニケーション計画
★プロジェクトを停滞させる一番の敵は、厄介な課題、チームや部署を跨いで議論しなければ解決できないような課題
ファンクショナルマトリクス
縦軸に大きな流れやmeceな構成要素
横軸には各行を一段落として分解したもの
セキュリティの例: 対策領域×IDDRR
Posted by ブクログ
システム外注の経験はないが、興味があったので本書籍を読んだ。タイトルのとおり、システムを作らせるにあたっての方法論が説明されている内容であった。特に、システムを外注で作って自社サービスとして販売するのでなく、社内向けシステムを外注する際の視点で説明されていると思う。そういう経験が来た時に改めて読んでみたいと思った。
Posted by ブクログ
大企業の内製より、中小企業で外注を行うIT担当向け。筆者の会社名が何度も登場した上で、そのノウハウが書かれており、営業をかけられている感じを受けた。
