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

白川克 / 濵本佳史

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

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

そのためには、

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

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

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

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

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

いかにシステム開発が難しいかを痛切に感じた。正しい考えかたと人を正しく動かしていくことの重要性が身にしみた

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

クライアントの人事評価システム導入検討をやることになりそうで、以前、妻が買っていたものを読んでみた。ちゃんとやろうと思うとなかなか大変だ…というのが分かって良かった。話が進んだら、この本を頼りに頑張ろう。

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

システムを「作らせる」立場で読んだが、豊富な事例（主に失敗談）を通じてシステム構築にどのように関与さていくかについて知見が深まった。
・Why が最重要で常に立ち返る
・Why→How→Whatの順で進める

あとがきの言葉で、本当はシステムを「作らせる」人も「作る」人もいるわけではなく、システム構築を成功させたい人がいるだけというのが強く印象に残った。

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

ざっくり感想、ステークホルダーとのコミュニケーションと情報整理が大事なんだと思いました。経験談も記載があり、リアリティを持って読むことができました。当方ITエンジニアですが、読んでよかったと思いました。

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

勤めている会社のシステムがあまりにもアナログで非効率が目立つので「何とかしたい」と思っていた今の自分にズバリ刺さってきた本。副題に「エンジニアではないあなたへ」とあるように、システムを変える・構築するプロジェクトを動かす者が心がけなければならないことが、実務面も含めて説明されている。

技術的なことは難しい（エンジニアに任せるしかない）が、エンジニアという人種やシステム会社の考え方、立ち位置をよくよく理解していないとコミュニケーションギャップにつながり、それが致命的なミスを招く。ビジネス書の類は失敗談はほんの少しで成功談ばかり書く方が多いが、本書は失敗談が半分近く、かなり生々しく人間の心理にまで踏み込んで事例が出されており、かなり参考になる。システム構築とは完璧はありえず、それも織り込んだプロジェクト進行が必要だと理解できた。

極めて専門性の高い分野を「使いこなす」力量と共に、覚悟と調整力、全体を俯瞰する力が問われる。今自分がやろうとしていることのバイブルになり得る一冊だった。

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

データアナリスト職です。BI帳票を開発業務として取り組んだ経験がなかったため開発工程を体系的に知るのは初めてでした。

BI帳票を開発業務として取り組むと工程が多くなりスピード感が失われ、ビジネスの期待値に届かない事が多い思いを持っていたのですが、これまでの歴史が積み重ねてきた開発のノウハウがBI帳票開発にも応用することで活きるケースがあると感じました。

例えば、開発機能（帳票）の優先順位を機械的にジャッジすることで既存帳票の現状踏襲を防ぐ。いまある帳票は数値を今まで見れていたからと無批判に作ってしまうことを防ぐ。そうした進め方ややり方もあるという学びがあります。

読んだ上でBI帳票作成の全てが開発工程に当てはめて進めること自体は是々非々で柔軟にやるべきだと思うが（TooMuchな部分があるので）Whyから始めるなど開発工程のスキームがBI帳票作成品質の底上げに繋がると思う

また、こうした本はいかに現場の課題感や失敗の生々しさを表現できるかが鍵だと思います。その中で書籍という形式上どうしても生々しさの表現が難しく目減りしてしまうことが多いが、可能な限り現場や実務の生々しさが伝わるように記載されていて良かった。生々しさを担保するコラムにこそ価値があると感じます。

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

Cambridge RAD という、ウォーターフォールとアジャイルの中間的なシステム開発&導入手法について述べた書籍だ。本書の中では特に要求定義のCambridge RAD版である「Scopeフェーズ」のくだりが素晴らしかった。中盤まるまる「社内調整が捗るような要求定義のスプシまとめ」のノウハウに費やされており、(1)｛ビジネスベネフィット, 組織受入体制, 技術的容易性｝の三項目別に優先度｛High, Middle, Low｝を決め、(2) その優先度の総合点に応じて｛優先的にやる（白）, 遅れてやる（灰）, やらないとキッパリ伝える（黒）｝の三色に塗り分け、(3) 社内関係者を説得するために最終的な説得用の表資料をつくりあげる（FM: Functionality Matrix）という手順を伝えてくれる。このpp. 095–196の内容を読めただけでもこの本を手に取った甲斐があった。

その前後には、社内要望を掬い取ること、ベンダを選定してうまく作ってもらうこと、それぞれの過程についてノウハウを開示しているが、それは他の本でも書かれてあることだ（この本でもそれぞれのくだりを丁寧に書いてくれていることは評価するが）。しかし要求定義についてここまでしっかり書いてくれていた本はなかなか見つからなかった。届くべき人に届いて欲しい本だ。

著者の指定姉妹本には『業務改革の教科書』が挙げられており、その本を読んでみたくなった。

惜しい点としては、記載されるExcelの印刷解像度が低すぎること。ここはスクリーンショットをもう少し綺麗にやってほしかった。

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

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

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

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

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

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

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

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