システムを作らせる技術 エンジニアではないあなたへ

白川克 / 濵本佳史

SEじゃないあなたのための
DX推進の教科書！

企業のDX推進でシステムを「作らせる技術」の重要性は増しています。
プログラマーやSEのような専門家だけがシステムについて考えればよいのではなく、「自分では作れなくとも、思い通りのシステムを『作ってもらうノウハウ』」が必須の時代になったということです。

そのためには、

・「こんなシステムがあればいいのに」を構想し、
・「A機能とB機能、どちらを優先すべきか」を判断し、
・これを作るのにいくらまで投資する価値があるか？を見極め、
・作ってくれる人（社内の情報システム部門、または社外の専門ベンダー）を探し出し適切に依頼し、
・構築プロジェクトで沸き起こる様々な課題を解決

していかなければなりません。

本書はシステムに詳しくない業務担当者が、新しいビジネスを立ち上げるために、または既存の業務を改革するために、すべきこと／陥りやすい落とし穴を余すことなく書きます。
著者が20年以上にわたり支援してきた多くのプロジェクトでの事例やエピソードを詰め込んだ、実務家のための教科書です。

• カテゴリ: ビジネス・実用
• ジャンル: ビジネス・経済 / ビジネススキル
• 出版社: 日経BP
• 掲載誌・レーベル: 日本経済新聞出版
• ページ数: 388ページ
• 電子版発売日: 2021年07月27日
• コンテンツ形式: EPUB
• サイズ(目安): 37MB

[ブクログ · ★★★★★]

たしかに本書の通りに
・whyhow#whatを明確にして
・関係者を適切に巻き込み
・会社と部署の垣根を超えてワンチームで取り組めば
不毛なプロジェクトを減らせるであろうと思える一冊。
システム開発に関わる人には必読の書と思う。
とくに、ユーザ企業や一時受けになるITベンダ向け。

[ブクログ · ★★★★★]

職場の上司紹介されたのがきっかけで読みました✨（紹介され嬉しかった）
ちょうど、タイトルに関係するような業務に取り組んでおり、どのように進めるのが最適なのか迷っていたため、読みました(^^♪

今、職場で情報通信の「システム」を使っていない場所は少なく、必ず何かのシステムが職場では動いていると思います。
システム変更や新規導入に関わる際に読むと良いと感じました！

システムを作る側、作ってもらう側、それぞれ必要なことを知ることができ、活かすことができる。そんな1冊でした!(^^)!

[ブクログ · ★★★★★]

ITプロジェクトに携わる人であれば読んでおくべき。
冒頭に書かれている通り、確かに作ってもらう側の本は希少か。

[ブクログ · ★★★★★]

ものすごく役に立つことが書いてある本。
データ移行は大変だよとちゃんと書いてある！

「カネと労力を使っても、使われないシステム、使えないシステムは最悪」は、私も実体験としてあるので、この本の「関係者をいかに巻き込むか」の方法論は本当に助かる。PMBOKかじり程度なりに、私が「使われないシステムは最悪」の信念でやってきたことの答え合わせができた感じ。間違ってなかったし、さらにステージが上げられる。

この内容をシェアしてくれる著者、ありがたい。早速FMは仕事で作ってみたし、今進めているプロジェクトで巻き込まないといけない人たちの顔が浮かんだし、地道にコツコツやらないといけないことへの覚悟ができた。

[ブクログ · ★★★★★]

作る側も読んだほうがいい本。
特に
・Whyの掘り下げ
・FM（Fanctionality Matrix）作成の進め方
・品質と精度の違い
に関する記述が印象に残った。
各フェーズでまた確認できるよう、手元に置いておきたい本。

コラムや実例についても興味深い内容が多く、他の著作についても読んでみたい。

[ブクログ · ★★★★★]

世はDXブームだ。ITに対して苦手感があった自分でさえ、本業として関わらざるを得なくなるほどのDXブームである。組織や人によって課題は様々だろうが、新規システム開発を担当することになった人も多いに違いない。「システムなんて誰かが用意してくれたものを使うだけだったのに、作る側の仕事なんて…」という人も多いに違いない。そんな人にこそ本書をお勧めしたい。一通り読むだけで全てが理解できるというわけにはいかないが、システム開発のプロセスを疑似体験することはできるだろう。あまりの大変さに、まずますブルーになってしまうかもしれないが。

[ブクログ · ★★★★★]

思ったよりボリュームがあり、とりあえずp.94まで心に残ったことをメモ。

・真っ先に具体化すべきことはなにか？
・現時点でどの程度具体化すべきか？
→社内でプロセス化ができいるベンダーほど、意外と意識できてない視点だと思った。プロセスはあってもプロジェクト単位で個々に検討しないとね、というのを改めて本文で指摘された気がした。
・why→how →what
・p.36 システムをどのくらい導入する場合のメリットデメリットをパターンする作業、導入範囲とコストの天秤
→この判断はシステム作る側は判断できないのに、その判断を押し付ける顧客側の多いこと！うんうん唸ってしまった。
・p.55 導入したらビジネスはどう変わるのか、それはなぜ嬉しいのか？
→わかりやすい問いでいいなと思ったのでメモ。

[ブクログ · ★★★★★]

良書　業務面から、すぐれた情報システムを構築するためにはどうすればいいのかが、利用者、導入企業の目によって描かれている書です。
システム、業務内容、スキル、進捗状況などなど、見えないづくしのシステム作りを可視化し、評価し、計画を立てるためのノウハウが集約されています。
もっと早く出会いたかったし、プログラマーなど、システム構築に関わる方にとって視野がひろがる内容だとおもいました。システム関連の方に是非ご一読をお勧めします。
過去、システム構築のトラブルに見舞われ、責任を負わされ、大切な友人、知人を自殺や病気で失い、職場から去っていった方も多くありました。
そんな難易度の高い仕事に、利用者目線でものさしを当ててもらっているのが本書だとおもいます。
使う人と作る人との役割や、責任が明確にされていること、各工程で作成される、成果物などが細かく解説されているのもいいと思います。

プロジェクトの成功の秘訣は、情報システムに明確な目的をもつこと、

要求定義は、使う人が主体で用意するもの、作る人はそのための支援をする
要件定義は、使う人と作る人が共同で行うもの
設計以降は、作る人が主体で行うもの

システム構築を８つのカテゴリーに分けて解説をしています

ゴール明確化　　　　Ｃ章
現状調査分析　　　　Ｄ
構想策定　　　　　　Ｅ
要求定義　　　　　　Ｆ～Ｍ
パートナ・製品選定　Ｎ～Ｒ
プロト検証　　　　　Ｓ
設計・開発・テスト　Ｔ～Ｗ
導入　　　　　　　　Ｘ

システムの導入は、Ｗｈｙ　⇒　Ｈｏｗ　⇒　Ｗｈａｔ　で考えよ
全体をつらぬく重要なドキュメントがでてきます。
それは、ＦＭ：機能一覧
　　　　ＦＳ：機能詳細（機能ごとにその概要を記述したドキュメント）
この２つのドキュメントが、プロジェクト全体で活用されています。

データ移行の難易度、費用は想像以上の大きいこと
・現行システムの知識が必要
・新システムの知識が必要
・業務知識が必要
この３つを全てもっている人はどこの会社にもいない

ヘルプデスク、保守、運用については、一部非機能要件の項目にあったぐらいで別の書を参考にされたほうがいいと思います。


目次は、以下です。

Ａ章　作る前に知っておくべきこと
Ｂ章　プロジェクト全体の進め方
Ｃ章　ゴール（Ｗｈｙ）を明らかにする
Ｄ章　現状の棚卸しをする
Ｅ章　将来像（Ｈｏｗ）を明らかにする
Ｆ章　システム要求（Ｗｈａｔ）を決めるプロセス
Ｇ章　機能を洗い出す７つの方法
Ｈ章　要求をＦＭにまとめる
Ｉ章　要求の詳細をＦＳに表現する
Ｊ章　優先順位の基準を決める
Ｋ章　作る機能を決める
Ｌ章　ＦＭがシステム構築を成功に導く
Ｍ章　機能以外の要求を定義する
Ｎ章　パートナーの１次選定
Ｏ章　提案を依頼する
Ｐ章　パートナーを決定する
Ｑ章　稼働までの計画を立てる
Ｒ章　プロジェクトの投資決裁を得る
Ｓ章　課題を先出しする
Ｔ章　開発チームの立ち上げ
Ｕ章　キーチャート
Ｖ章　開発中の関与
Ｗ章　データ移行
Ｘ章　いよいよ新システムの稼働
Ｙ章　（補足）ベンチャーでのシステム構築
Ｚ章　（補足）ＦＭをシステム構築以外に応用する

[ブクログ · ★★★★★]

「エンジニアではないあなたへ」とありますが、エンジニアこそ読むべき書籍です。

380ページを超える本であり、活字もぎっしりと詰まった書籍ですが、記述内容はごく簡潔に、かつ有益な情報に溢れており、読むのにストレスを感じさせません。

二週間くらいかけて読むつもりが、実質2日で読み終えました。

特筆すべきなのは、要件的に至るまでのデータ整理方法を、事例を交えて説明してある点。
Excelを使ったデータ整理方法（といっても、関数は一切使わない）を実例を交えて説明してあるのですが、ほんとうに今日からでもつかえるような事例ばかりの書籍です。

書籍中にも書かれていますが、エンジニアやPMは、時には細かい詳細設計に走りがちなのですが、それよりももっと大きな枠で要件を定義すべきであること、またそのためにはマトリクス表などを使って丁寧に要件を整理することが大切であることが述べられています。

また、コンサル所属者が著した書籍としては珍しく、とにかく「カタカナ横文字」が少ない点も読みやすさを高めている要点だと思われる。
「このカタカナ、本質的な意味は日本語で何だ？」という余計な思考を挟むことなく読み進めることができるため、著者が訴えたいことに集中して読み進めることができる点もありがたい。

この本の読み進め方ですが、巻末に著者自らあっさりと認めている通り、すべての要件定義を順番にすすめるよりも、全部を読み通したうち、身近な案件に適用できそうなフォーマットを適用するところから始めるのが良いと思われる。

この本にあえて注文をつけるとすれば、コロナ禍により遠隔ミーティングの増加、およびいわゆる「カジュアルコミュニケーション」のような「5分程度のちょっとした雑談」が難しくなった今、この本で訴えている「コミュニケーションを通じた要件の整理」をどのように進めればよいのか、その知見を続編として出してほしいと思っています。

[ブクログ · ★★★★★]

システムを作らせる技術。
作ってもらう側の心構えと、やるべきこと。

システム開発に限らず、
パートナー企業とプロジェクトをするにあたって
有効だろう。

システム開発の本なのに、開発に関わるページは
ごく僅か。全体の1/10以下。
システム開発に入る前までが全体の8割型を占める。

なぜ作るのか。
なにを作るのか。
どうやって作るのか。

全体を定義して、優先度づけロジックをつくり
皆で評価する。
という、当たり前のことを愚直にやることが
いかに大事か。

開発範囲を決める構想の段階でも、
パートナー選定の段階でも、
テストの段階でも。

移行や、稼働後がいかに大事かも
しっかりと書かれている。