システムを作らせる技術　エンジニアではないあなたへ (日本経済新聞出版) [Kindle]

著者 : 白川克 濵本佳史

• 日経BP (2021年7月22日発売)

感想・レビュー・書評

[ツァラトゥストラさんの感想 · 2024年4月7日]

システム開発に携わる人が押さえておきたいノウハウがたくさん詰まっているし読みやすい。要件通り開発すればOKというIT側の考えや、依頼さえすればいいだろうという「作らせる」側の甘い認識では、よいシステムはできあがらない。

[yukiさんの感想 · 2024年4月2日]

読み始めてから、最近読んだ「ファシリテーション型業務改革」と同じコンサルティング会社の書籍であることに気付いたが、それと比べるとやや落差が（作りもやや適当な感じが）。
システム開発の本当にハードな意思決定、例えば、開発のコストベネフィットをどう定量的に算出するか？重大なイシューが生じたときのgo/no-goをどうするか？にはほぼ触れていないのが残念だった。

[読書好きなあおちゃんさんの感想 · 2024年3月30日]

システムが業務を変える具体例や、不確実性コーンへの対応が参考になった。他は一般的な内容

[とぅーさんの感想 · 2024年3月1日]

システムを「作らせる」技術。というタイトルに惹かれた。
図書館で予約をして借りたため、手元に届くまで本の分厚さを知らず、手に取ると中々の分厚さでかなりの読み応えである。かなりの分厚さであるが、開発の流れに沿って書いてあり、頭が整理された状態で読み進められるため、意外とサクサクと読める。「作らせる」とあえてワードを使っているそうだが、これはシステム等をITベンダーに発注する側の立場（=作らせる）として書かれたもので、そういった本は少ないだろう。日本では特に下請けと発注元という構図が多いため、「作らせる」側がなんとなく偉そうに感じる。ただし、この本では、そういった立場や考え方ではプロジェクトがうまく進まないことを事例とともに書いてある。ラグビー日本代表でもキーワードとなっていた、「One Team」が結局大事であるとのこと。（あえてこのワードを使うが）「作らせる」側がプロジェクトに積極的に関わっていき、業務プロセスの洗い出しや、ファンクショナリティマトリクス（FM）の作成等、プロジェクトの要件定義の段階から、「作らせる」側と「作る」側さらには「使う」側のすべての方面での協力無しにプロジェクトの成功はなし得ない大事さが語られている。特に痛感したのが、途中で問題が山積し、「システム自体を作ること。」がどこかゴールになってしまい、「作らせる」側が一方的に「作る」側へ要求を押し付け、本来、システムを利用して業務の効率化や生産性向上に繋げるという当初の目的が曖昧になってしまう。ということがよくある。という話が身に染みた。プロジェクトを進めていくともう後戻りができない状態になってしまい、完成させることに集中してしまう。ということはよくある話だろう。

[じーしょさんの感想 · 2024年2月19日]

奥田さんより紹介してもらった。2024/2/19

[能戸淳（じゅんじゅん）さんの感想 · 2024年2月18日]

直截的なタイトルからしてわかりやすい、そして非常に中身が濃い本だった。
とりわけ事例を扱ったコラムが著者の体験が詰まっている感じだった。特に間接部門というお金を生む出みださないセクションが予算を確保するあるべきアプローチにも触れていたので良かったね。

[bamboohouseさんの感想 · 2023年11月17日]

システム開発が上手くいかない理由について、踏み込んで書かれている本。長いので1回読んだだけでは理解できないが、何度も読み返す価値がある本。

[dsadaiさんの感想 · 2023年7月8日]

技術的な話というよりは、こんなコミュニケーションをとらないとだめだよ、というような内容で少し狙いと違っていた。

[zhizeさんの感想 · 2023年6月4日]

・ベンダーにシステムを発注する企業の担当者が、いかにプロジェクトを進めていくか？という本。「なるほど」と何度も首肯しながら読んだ。
・どっちかと言うと、技術的な知識の乏しいベンダー側の営業とかPMが、自社の開発プロジェクトの中でSEやPGと付き合っていく方法論みたいのを期待してたので、実はちょっと狙いが違った。
・ただ、裏表の話になってて、発注側の提案意図を理解できれば、受注側はそこをターゲットに対応することで、意思疎通の齟齬が起きにくい筈。自社の今の体制を顧みて、気付きも少なからずあった。

[soloelfinさんの感想 · 2022年12月19日]

システムを作る場合も、誰かに説明する場合と同様、「Why⇒How⇒What」の順番で考え、Whyから語るのが良い、（ゴールデンサークル）という。
私がシステム化を考えるときに一番やりたいのは「システムをテコにして業務を変える」項の「パターン④ データの一元管理」。「人がシステムの間を繋い」でいる状況を、「システムが人の間をつなぐ」に変えたい。

本書で一番参考になったのはFM（ファンクショナリティ・マトリクス）/FS（ファンクション・スペック）の項と、FM/FSから作る機能を選択する評価基準の部分。「作る機能だけでなく作らない機能もFM/FSに入れる」「FMを作る際に人を巻き込む」「組織受入態勢を評価基準にする」というのは常に頭に置いておきたい。

本書でも提案されているが、FMのフォーマットや考え方は、システムの要求定義以外に活かせると思うので、活用していきたい。
—-
■要求定義
「システムに求めること」について片っ端から
書き出す（発散→収束モデル）

—-
プロジェクト全体の進め方
①Concept Framing（ゴール明確化）
②Assesment（現状調査/分析）
③Business Model（構想策定）
④Scope（要求定義）
⑤PEW（製品選定/ベンダー選定）
⑥BPP（プロトタイプ検証）
⑦Design（設計）〜Deployment（開発）
⑧Rollout（稼働）

—-
現状の棚卸しをする
現状の業務とシステムを棚下ろす9大フォーマット
①現行業務フロー
②現行アクティビティ一覧
③現行ファンクショナリティ・マトリクス
④現行いステム一覧
⑤現行インターフェース一覧
⑥現行全体システム構成ず
⑦現行システムの主要データ
⑧現行コード体系
⑨課題一覧

—-
現状の業務とシステムを棚卸しする9大フォーマット
業務系フォーマット
①現行業務フロー（スイムレーンチャート）
②現行アクティビティ一覧

システム系フォーマット
③現行ファンクショナリティ・マトリクス（FM）
④現行システム一覧
⑤現行インターフェース一覧
⑥現行全体システム構成図
⑦現行システムの主要データ
⑧現行コード体系

共通フォーマット
⑨課題一覧

—-
将来業務フローには変更点を図示する
・なぜ必要か
・何を変えるか
・何がよくなるか

—-
将来業務フローを作成する6つのテクニック
①変化点を必ず書き出す
②まずはアナログで作る
③フォーマットを決める
④メインフローが先、イレギュラーが後
⑤詳細はとりあえず脇に置く
⑥一人で作らず、人を巻き込む

—-
システムをテコにして業務を変える
パターン① 電子化によるペーパーレス
パターン② デバイス配布による「どこでも電子化」
パターン③ 発生時点入力
パターン④ データの一元管理
パターン⑤ 人間では煩雑過ぎることをシステムで管理

—-
業務フロー作成のテクニック6箇条
①変化点を必ず書き出す
②まずはアナログで作る
③フォーマットを決める
④メインフローが先、イレギュラーが後
⑤詳細はとりあえず脇に置く
⑥1人で作らず、人を巻き込む

—-
FM作成の5つのステップ
機能要求定義のステップ
①：機能洗い出し
②：FM作成
③：機能詳細の記述
④：優先順位基準の決定
⑤：優先順位の決定

—-
機能を洗い出す7つの方法：基本編
①現行システムから洗い出す
②標準テンプレートから洗い出す
③業務フローから洗い出す
④ソリューションや入門書で抜け漏れをチェックする

機能を洗い出す7つの方法：応用編
⑤ビジネスの文脈を捉え、将来への布石を打つ
⑥新規ビジネスモデルから導き出す
⑦シーズ×シーンマトリクスを使う

—-
FMにまとめる基本ステップ
ステップ1：機能をセルに整理する
ステップ2：セルをグループに分ける
ステップ3：セルとグループを並べる

—-
FSに書くこと4つ、書かないこと2つ
■FSに書くこと4つ
①実現したいこと
②扱う情報
③他の機能との関連
④バリエーションやイレギュラー
■FSに書かないこと2つ
①実装方法
②画面イメージ

—-
優先順位決定のため3つの基準を3段階評価
・FM/FS各セル個別の議論の前に、評価基準をまず決める。
・それぞれの基準ごとに、3段階（High/Medium/Low）で評価する。
■効果
・ビジネスベネフィット
　ー売上向上
　ー原価削減
　ープロジェクトゴールへの貢献 など
■コスト
・組織受入態勢
　機能を使いこなせるか？
　ー対外調整が困難
　ー増員が必要
　ートレーニングが必要
・技術的容易性
　作るのは難しくはないか？
　ー技術的に成熟しているか
　−システム構築工数

—-
作る機能を決める
「効果があり、簡単に作れ、簡単に使いこなせる機能を真っ先に作る。それよりも優先順位が落ちる機能は後から作る。もっと優先順位が低い機能は作らない」

---
グラウンドルール
・積極的に参加する
・思ったことはすかさず言う。不安やモヤモヤを溜めない
・年次は一切気にせず、即応答。コミュニケーションを！フリーズ禁止！
・一総合職として会社全体のあるべき姿を考える
・時間厳守
・個人情報は取扱いに注意
・言葉の定義を丁寧に
・自分の予定は予定表に入れましょう。予定表の開示も忘れずに
・Have Fun！

著者プロフィール

ケンブリッジ・テクノロジー・パートナーズ ディレクター
1972年横浜生まれ。96年一橋大学経済学部卒業。中堅ソフトハウスでシステム開発を経験後、2000年ケンブリッジに転職。以来、IT投資計画策定、人事、会計、販売管理、顧客管理、ワークスタイル改革、全社戦略立案など、幅広い分野のプロジェクトに参加。

「2023年 『社員ファーストの経営』 で使われていた紹介文から引用しています。」