白川克のレビュー一覧

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

題目の通り、システムを作らせる導入側の担当者視点に立って書かれた本。導入側で書かれているが、売り込む側として読んでも参考になる。ここに着目した書籍は他のテーマと比べて少なく、差別化がはかれてる書籍だと感じた

ざっと一通り読んだだけでは理解は少ないので、何度も読み返し、自分の言葉で説明できるようになっておきたい。

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

システムを”作らせる”（ユーザ企業側）目線で書かれた，
システム開発系PJ成功指南所．

かなり割愛して読んだが，後書きにあった最後の一文が痺れた．

"本当は「作らせる人」も、「作る人」もいない。いるのは「プロジェクトを成功させ、会社を良くしたい」ともがく人々だけだ"

ベンダーだろうがユーザだろうが，この信念を持てるかどうか．ベンダーであれば要求の洗い出しや整理などユーザ主体の活動であっても「ユーザの責任範囲なんで」と他人事で見ないこと．ユーザであればシステムのことはわからない（わかるつもりもない）とベンダーに丸投げしないこと．
すなわち，他責にならないことが大事．

相手に多少踏み込み過ぎ？と思われるくらいが丁度いいかもしれない．だって「プロジェクトを成功させ会社をよくする」ためにもがいているんだから．

・PJには100％確実なものは何もない
・ユーザは業務のプロであって要求定義のプロではない．ユーザからシステムへの要求や制約を引き出させるのもエンジニアの仕事
・プロジェクトを停滞させる一番の敵は、厄介な課題、チームや部署を跨いで議論しなければ解決できないような課題


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

他人への説得論法
why → How → What
私たちは世界をかえる〜→その手段は〜→だから◯◯を作った。

一般人はどうしてもwhatから考える。だからストーリーがつまらない。
こんなソリューションを使う(what)→ベンダーに作ってもらおう(how )
工場を◯◯にしたい→◯◯が必要だ→こんなシステムが必要だ

プロジェクトは曖昧さ100%から曖昧さ0％の着地に向かって進む、不確実性が減り具体的になる
→★確実な情報を持ってこい！は傲慢。曖昧さを減らすために対話して意思決定を積み重ねる。

要件定義の難しさ
・検討漏れの発生
・要件を詰め込みすぎる→ビジネスライクに必要性を判断


総論賛成各論反対

良いプロジェクトのゴール
以後の工程で使える価値尺度がはいっている
(現状維持>新規性)
地に足がついている
わかりやすい
whyがこめられている

プロジェクトは初めての活動
→こうすればよかったは必ず出る
→完璧を目指す姿勢そのものが間違っている。

要求定義
→システムを作らせる人のwant
要件定義
→システムを作る人が、システムに必要とされる性能や機能を明確にする作業
設計
→要件を実現するための技術的な方法を決める作業

要求定義作成の難しさ
・網羅的な洗い出しができない
・予算オーバーになるって
・立場によって要求が異なる

★著者の会社の要求定義の定義
"要求定義とは利害関係者の意見をまとめて、実現すること・実現しないことを揺るぐなく定めること"

★ユーザは業務のプロであって要求定義のプロではない
→引き出す、ナビゲートするのもエンジニアの仕事

★全て洗い出す→優先順位をつけてやるやらないを線引きするところまでの客と握る
→スコープ(やる・やらないの線引き )を明確にして、あとになって「これも必要」と言わせない。やらないと分かっていても端折ったり捻じ曲げたりしない。
★網羅的に検討したんだぞという訴求
★恣意的ではなく合理的に選択したんだぞという訴求

コミュニケーション計画

★プロジェクトを停滞させる一番の敵は、厄介な課題、チームや部署を跨いで議論しなければ解決できないような課題

ファンクショナルマトリクス
縦軸に大きな流れやmeceな構成要素
横軸には各行を一段落として分解したもの
セキュリティの例: 対策領域×IDDRR

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

ウォーターフォール型の開発について
進め方、役割などが詳細に書かれており
具体例などもありイメージがつきやすかった

会社のＩＴはエンジニアに任せるな！

非常に読みやすかった。今担当しているプロジェクトのコンサルさん。当社のITにも読ませたいし、自分でもIT食わず嫌いにならずに、会社の成長のために、貢献しようと思った。ITはツール型だけでなく、プラント型ITというものがあり、プロジェクトは外部メンバーだけでは成功しない、という事がよくわかった。

業務改革の教科書－－成功率9割のプロが教える全ノウハウ

業務改革の全体像を分かりやすく解説している。またtipsやアウトプットイメージも役立つものが多く、そのまま使えそうな感じもする。業務改革プロジェクトの辞書的位置づけに出来る本。

業務改革の教科書－－成功率9割のプロが教える全ノウハウ

業務改革プロジェクトの立ち上げ期に重点を置いて、著者の経験によるプロジェクト成功のTipsを紹介している。企業事例や現場で使ったツール、当事者の声が織り込まれている。

ゴールやコンセプトをどのようにひねり出すか？やタイプ別変革の落とし穴、のようなTipsが中心であり、教科書ライクなものではない。例えば、「そもそも論に立ち戻れ！」「業務は流れで聞け！」のように、こういう時はこうすればうまくいく！のノリである。

プロジェクト立ち上げからの経験と照らし合わせながら読むと、色んな失敗が整理される。ふりかえりに使うと良いタイプの書籍。

業務改革の教科書－－成功率9割のプロが教える全ノウハウ

　業務改革（BPR）のプロジェクトを指揮することになったので読んだもの。何か忘れていることはないか、備忘ツールとして有用。
　どれくらい役に立つかは、実際の業務に照らし合わせてみて評価することになる。

会社のＩＴはエンジニアに任せるな！

自社の業務や経営から切り離されたツール型ITと自社の業務や経営と密着あるいはそのものであるプラント型ITに分けて、そのプラントITを構築する際の失敗や高コストなどの問題点を提示しその解決方法をそう簡単にできないことも含めユーザ企業に向けて指南する。ITは会社の武器、伊勢神宮の式年遷都型のシステム開発、費用対効果がわからないことこそ経営判断、全社戦略に先んじてITビジョンを明確に、などが印象に残った。やや自社自慢が鼻につくところもあるが、ユーザ企業の成功はSIerの成功でもある。ここまでユーザ企業を説得するのもかなり難しいですが、一読の価値有りです。

業務改革の教科書－－成功率9割のプロが教える全ノウハウ

☆4:仕事で必要になり再読。タイトルのとおり、読んで、実践して、また読む…という教科書スタイルでお付き合いするのがいい。テクニックも心構えの両方ともスルメを噛むかのように理解できてくる。

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

　システム外注の経験はないが、興味があったので本書籍を読んだ。タイトルのとおり、システムを作らせるにあたっての方法論が説明されている内容であった。特に、システムを外注で作って自社サービスとして販売するのでなく、社内向けシステムを外注する際の視点で説明されていると思う。そういう経験が来た時に改めて読んでみたいと思った。

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

大企業の内製より、中小企業で外注を行うIT担当向け。筆者の会社名が何度も登場した上で、そのノウハウが書かれており、営業をかけられている感じを受けた。

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

本書はシステムを作るエンジニア側ではなく使うユーザー側向けである。思い通りのシステムを構築するために丸投げするのではなく、関係者の巻き込み方と合意を得るプロセスを中心に、豊富な実例とビジュアルで解説。

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

■現状の業務とシステムを棚卸しする９大フォーマット
業務系フォーマット
①現行業務フロー
②現行アクティブティ一覧
システム系フォーマット
③現行ファンクショナリティ・マトリクス
④現行システム一覧
⑤現行インターフェース一覧
⑥現行全体システム一覧
⑦現行システムの主要データ
⑧現行コード体系
共通フォーマット
⑨課題一覧

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

■システム要求の３大障壁
①完璧なリストアップができない
②常に予算オーバーになる
③立場が違えば、システムに求めるものが変わる

■システム構築スケジュールを精査する６つの視点
①MUSTな期限が守られているか
②業務繁忙期とシステム構築のピークは重なっていないか
③工程ごとのゴールが明確か
④成果物をチェックするマイルストーンはあるか
⑤各領域の整合が取れているか
⑥各フェーズの期間バランスが適切か

■良い開発チームを作る９原則
１．ユーザーが参加し続ける
２．保守をにらむ
３．エキスパートとのつながり
４．OneTeamにする
５．WhyやHowをきちんと伝える
６．言葉と進め方は明確に
７．ストレートに意見を言い合う
８．プロジェクトルームはできれば１つ
９．学び合う

■キーチャート７選
①ステータスマトリクス
②ステータス×操作可否
③機能×利用者権限
④BOMごとの管理情報
⑤採算管理における集計対象
⑥承認プロセスのキーチャート
⑦受注チャネルのバリエーション



2026/6/7
F章　システム要求 (What) を決めるプロセス

この章のレッスン
・システムを作る上で重要となるシステム要求定義の流れを理解する
・システム要求をまとめる上で難しい点を把握し、「なぜこのプロセス・成果物ならうまくいくか」がわかるようになる

　これまでのフェーズでプロジェクトのWhyとHowが固まったので、ようやくWhat、つまり「どんなシステムを作るのか」を決める Scope フェーズを開始できる。一般的には要求定義、要件定義などと呼ばれる工程だ。 この章は要求定義の最初の章として、全体を俯瞰するための3点を説明する。

・要求定義とはなにか? (言葉の整理など)
・要求定義はなぜ難しいのか?
・要求定義(特に機能要求定義)のステップ

システム要求、要件、そして設計
　要求定義と要件定義という言葉は一般に、「誰がその作業の主体か」に着目して、以下のように使い分けられる。そして設計はそれらに続く工程た。

要求定義
　システムを作らせる人が、「システムはこんな風であってほしい」と、 システムに求めることを明確にする作業。システムに詳しくない人が定義するので、システム的な厳密性、網羅性には欠ける。

要件定義
　システムを作る人が、システムに必要とされる性能や実装すべき機能などを明確にする作業。システムが果たすべき機能はすべて要件定義書に書かれるべきなので、例えば「どういうケースでエラー表示をするか?」の一覧表を作るプロジェクトもある。


設計
　システムを作る人が、要件を実現する技術的な方法を決める作業。例えば「この機能は○○というソリューションを使う」 「データ構造はこうする」といった具合だ。ユーザーから目に見える画面レイアウトなどを固める設計を「外部設計」、目に見えない内部ロジックを考える「内部設計」 に分ける場合もある。
　イメージしにくいと思うので、まずは住宅の例に当てはめてみよう。
要求
・キッチンは明るい方がいい
・トイレは2ついらない
・風通しの良さが重要
要件
・キッチンは2階に
・トイレは階段の下に作る。したがって天井は低くなる
・階段の上に、常時開けておける小さい窓を作る
設計
・実際の設計図
　こう整理して書くと当たり前に見えるのだが、要求は家に住む人にしか言えない。トイレが2つあることが書斎よりも重要、という人も中にはいるだろう。どっちが正しいという話ではない。何を重視するか? という価値観で決めることだ。
　そして要件は住む人と建築のプロとの共同作業になる。「キッチンは絶対に2階がいいんです!」と主張する施主もいるだろうし、「2階のキッチンは明るくて良いものですよ」とプロが提案し、それに施主が賛同する場合もあるだろう。
　また、プロからの要件の提案を受けることで、施主が自覚していなかった要求が浮かび上がることもある。例えば「キッチンを2階にすると、子ども部屋に行くのにキッチンを通らない。思春期になったら親子の会話が減りそうでイヤ!」という具合だ。
　それに対して、設計は完全にプロの領域だ。キッチンを2階に設置することで、水回りの配管をどう巡らせるべきか? といったことは専門家でなければわからない。それらを全て踏まえた上でベストな設計図を書く際に、中途半端に素人が口を出すとかえって悪くなるものだ。
　ここで描いた施主とプロの建築家の関係は、そのままシステムを作らせる人と作る人の関係になぞらえることができる。要求/要件/設計それぞれについてシステム構築での例をあげると、
要求
・契約条件は同じ顧客との間では頻繁には変更されない。だから受注の際には条件を都度入力したくない
・上司は部下の職務経歴を自由に参照できるようにしたい
要件
・契約条件は契約マスターに登録する。受注の際には契約マスターから条件を自動で受注画面に表示することで、都度入力する手間を省 <
・上司が職務経歴を参照できる「部下」とは、同じ組織に属し、かつ職位が自分より低い社員のこと
設計
・受注データは契約データとリンクを張り、受注画面に条件を自動で表示できるようにする。ただし受注画面で条件を変更することもできる
・組織マスターの管理職情報と社員マスターの職位情報をプログラムが読み取り、参照権限を自動でコントロールする
といった感じになる。
　設計について中途半端に素人が口を出すとかえって悪くなるのも、住宅と同じである。例えば「職務経歴を自由に参照できるように」を実装する方法は、何通りかあるかもしれない。その場合はITエンジニアが技術的なメリット/デメリットを踏まえてベストな方法を選ぶべきだ。ユーザーが良かれと思って「組織マスターの管理職情報を使え」と言うと、ITエンジニアは「使わなければならない」と捉え、足かせになってしまう。

　まとめると、
「要求はお金を払うユーザーが出す。設計はプロのシステム開発者がやる」
　となる。これが大原則だ。「システムを作らせる技術」をテーマとした本書で、要求定義について多くの章を割くのは、作らせる人が主役となる工程だからだ。作らせる技術のうち、要求定義はかなりの割合を占める。「欲しいシステムをもれなく、正確に表現する技術」と言ってもよい。

会社のＩＴはエンジニアに任せるな！

経営者に対する「ITへの投資・経営はこうするんですよ」な本。
昭和な「人工知能を買ってこい！」的な経営者に対してのメッセージな印象で、かなりターゲッティング対象は絞られると感じる。ある程度の若い世代・IT知見のある経営者には通じないだろうし、本の中に出てくる統計資料も出典が書いておらず、「ちゃんとデータはあります」という嘘で説得するための資料に過ぎないとの印象。
逆に言えば、この本の内容でITに疎い高齢経営者のほとんどは説得できるんだろうなぁとも思え、有る種世界の違う人達の価値観を学ぶことができると思った。

業務改革の教科書－－成功率9割のプロが教える全ノウハウ

業務改革するにあたり外せない概念、プロセスを羅列したもの。
具体的な内容も失敗・成功両面で複数示されているのでありがたい。
しかし、この本を読んで何かが解決するわけではない。

業務改革の教科書－－成功率9割のプロが教える全ノウハウ

業務改革をする上で、標準化や一元管理、業務集約、アウトソースは同じレベルの選択肢だと考えていたが、まず標準化する事が大事だと分かった。今抱えている業務は、前からやっていた事を引き継いでいるだけに過ぎない事を認識して現状を分析する事から始めることにしよう。

会社のＩＴはエンジニアに任せるな！

　情報システムの更新はその過半数が失敗する。この根本原因と解決方法を示した実用書である。作者の白川克さんにも何度かお会いしているが本質を見極める力、あるべき姿を思い描く力、それを相手に納得させる力、コンサルタントではなく当事者が問題解決を自ら行えるようにする力などこれまでのコンサルタントのイメージとは全くことなる活動をされていますが、その根本原理を学べる本である。
　自分も何度となく失敗プロジェクトに従事し、火消しとしてそれを救ったりしていたがその要諦を言語化している点で有用である。

業務改革の教科書－－成功率9割のプロが教える全ノウハウ

読みやすい文章であるが、内容が散発することにより全体としては読みにくさを残すという本だと感じました。また書いてある内容も様々なことを網羅しようとする思いから浅く、そして一般的に言われていることであるため、振り返ると大半のことは知っていることであった。そのため、業務改革が定型として行われているかのチェックリスト的に使うとよいのかもしれないと感じました。ただ、逆に初心者には全体像が分かってよいかもしれません。

反常識の業務改革ドキュメント－－プロジェクトファシリテーション［増補新装版］

「ファシリテーション」「業務改革」というキーワードに惹かれた。
ノウハウ本かと思ったら、小説のように進んでいく。
物語として面白い。
成功するプロジェクトであっても危険なことはよく起こるというのが参考になる。

会社のＩＴはエンジニアに任せるな！

ITをツールとプラントに分けて、プラント型に対する筆者の考察が述べられている。会社の基幹となるシステムに対して経営幹部の関わり方の重要性がよく分かる。ただ、この本は入門書のためエンジニアの話を理解するにはもうワンステップ必要になってくると思う。