システムを作らせる技術　エンジニアではないあなたへ みんなのレビュー

投稿元：

レビューを見る

220812
・再読。FMと呼ばれるFMTの効かせ方のイメージがより湧いた。基本的に依頼主がちゃんと動かないと成り立たない系の取組なんだろうか、実務工数どれぐらい用意させてるか気になった。

210817
・この半年で1番良かった。
・いわゆる業務要件の洗い出し×プロジェクト推進のノウハウが詰まっていた。
・自身でやっていることを違うやり方でうまくやっているところ、を知れ、有意義。
・やはり、優先度やカテゴリ分けのようなラベル付が1番難しいと感じる。本書でもcoolという単語に留まっており、言語化できてない箇所。これをちゃんと整理できるかがコンサル力、ということを再認識できた。
・これまでのPJT経験でやってたことも出てきて、良い棚卸しになった

投稿元：

レビューを見る

ベンダー目線、全ユーザーに読んで欲しい。システム開発の成功のための前提原則がユーザー企業にまだまだ通じていない、というのが実情。

【感想】
　前、本書と似ている以下の本を読んだ。「情シス・IT担当者[必携] システム発注から導入までを成功させる90の鉄則」この本のamazonレビューに「私が知る限り、日本において、ケンブリッジテクノロジパートナーズに並んで、ユーザー目線に立っているコンサル企業が書いてくれた」というレビューがあった。なんだか業界通の雰囲気を感じて覚えていたのだが、そのケンブリッジテクノロジパートナーズの中の人たちが書いてくれたのが本書である。結論から言って、良い本で、仕事をしながら繰り返し読みたい。
　システム開発導入プロジェクトを進めていると「なんでこんなにしんどいんだろう？」と思うことがある。本書を読むと「あぁ、営業段階の要求定義工程がザルすぎたんだな」とか「あぁ、ユーザー企業側で業務フローは作ってくれなかったなぁ」とか、しんどさの原因のあたりをつけることができる。それが救い。実務上は原因が分かっても、立場上根本的な改善のための行動をとることは難しいものの、「～ができていないからだ」と他責化して、自分の精神安定を守ることには役立つ。そういう意味で、必ずしも、ベストプラクティスが実践できるとは限らなくても、この手の本を読んで「あるべき姿」を勉強しておくことは大事だな、と改めて思った。
　さすが業務コンサルティング企業の人が書いているだけあって、たくさんの表やチャートが登場するが、どれも美しく、シンプルで、MECEである。参考になる。ウチのシステム導入は小規模なので、ここまで全ての武器を使いこなすほどの必要はない案件は多いものの、頭に入れておき、適宜活用したい。図表も多く登場するので「なーんかこういう情報を整理するにはどうすればいいんだっけか」と悩むときには、この本を読めば着想を得られそう。
　

【本書を読みながら気になった記述・コト】
・FMがシステム開発を成功に導く
　・入念な要求定義を基に、「何の機能を開発し、何の機能を開発しないのか」をきっちり討議することが大事。ここのクオリティが後続の開発フェーズに全て影響を与える

■業務分析のための9大フォーマット
・以下、それぞれ、「現行版」「ToBe版」と作成可能
・美しく情報整理、コミュニケーションに活用可能な図表を用いることで、プロジェクトを効率的に進めていくことができる
・基本は表。テーマ、抽象度ごとに分けて作っていく

＊業務系フォーマット
①業務フロー
②アクティビティ一覧

＊システム系フォーマット
③ファンクショナリティ・マトリクス
　・ビジネスベネフィット、技術的容易性、組織受入体制の3観点で評価する
・ToBeの場合は付属してFS：ファンクションスペックを作る
　→書くこと
　　・実現したいこと、扱う情報、他の機能との関連、バリエーションやイレギュラー
　→書かないコト
　　・実装方法、画面イメージ
④システム一覧
⑤インターフェイス一覧
⑥全体システム構成図
⑦システムの主要データ
⑧コード体系

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

■システム開発にあたってのフォーマット
＊キーチャート
・ステータスマトリクス
・ステータス×操作可否
・機能×利用者権限
・部品表ごとの管理表
・採算管理における集計対象
・受注チャネルのバリエーション
・全ての要求機能を実装することはしない方が良い　
　→予算・スケジュール面に悪いインパクトが必ず出る。最小限の開発工数で最大の効果が出る機能のみを実装するべき。システム導入にあたって、業務を変えることもきちんと念頭に置いてもらう。開発工数ばかりかかって、業務上大したメリットが出ない、という要求も必ずある
・FMの作成、決定、共有の制度がプロジェクトの成否を分ける
　→プロジェクトが進んだ後での、追加要求や、話の混乱の防止
　　→コミュニケーションツールとして威力を発揮

■並行稼働には2種類ある
A)バトンタッチ型並行稼働
B)業務テスト型並行稼働
　→Aは大変なので、Bで行う事もある

投稿元：

レビューを見る

仕事の業務を改善したい、新しい事業を生み出したい、と思ったとき、システムを作る必要がある。その場合、「システムを作る技術」と「システムを作らせる技術」のどちらかが必要になる。本書はシステム会社等にシステムを作ってもらうために、システム会社に何かを依頼する職場のIT担当者のような人を対象として、システムのゴール設定、現状分析、システム要求のまとめかたなどを書いている。システム構築の順番に章が並んでいるので、イメージしやすい。ところどころに出てくる業務フロー、課題一覧、FMシートという要求の洗い出し表の例がある。システム更新などの際、手もとに置いておきたい。

投稿元：

レビューを見る

「作る人」「作らせる人」が同じ土俵にあがり、なるべく共通の言葉を使って相手を理解し対話することが大事なうえに、組み合ってもどちらかが土俵から転がり落ちることのないように押したり引いたりしているところや、ときには客席から座布団を投げられる光景が思い浮かびました。最後はお互いに感謝の気持ちを持って土俵を降りることが良い結果なのだと思います。

投稿元：

レビューを見る

本書未読。「反常識の業務改革ドキュメント　プロジェクトファシリテーション」の感想を書きたかった。☆4つ。ドキュメンタリーで、ケンブリッジコンサルティングと古河電工の人事BPRの担当者2人の共著。ドキュメンタリーで共感しながら読んだ。ITプロジェクトのあるあるで非常に面白かった。何でブクログに出てこないんだろう？

投稿元：

レビューを見る

書評が結構厳しいが、いい内容だと思った。私は作らせる側と作る側の間のような立場だが、改めてこうまとめてもらうとありがたい。またウォーターフォール世代だが、さすがにアジャイルで開発する内容でもないので、このケンブリッジRADの考え方は大変参考になった。

投稿元：

レビューを見る

企業のビジネスに対し大きなメリットをもたらすITシステムを作るには、技術力の高いベンダーだけでは不十分である、という認識を持つことができた。

要素技術に詳しい、プロジェクトマネジメントスキルが高い、システム化対象業務に詳しい、などそれぞれの知見が共有されてはじめてよいシステム作りが進んでいく。
今後は、自分がどの要素を保持してプロジェクトに参画するのか認識して取り組んでいきたいところ。

得られるものの多い良本と感じた。
一方で、一読して全習得は無理だとも思ったので、プロジェクトに参画するときのリファレンスとして逐一使っていきたい。

投稿元：

レビューを見る

冒頭に、「システムを作らせるという言い方がエラそうな件」というコラムがあって、著者がタイトルにさんざん悩んだことが書いてある。結果、大いに誤解をうけるのを覚悟であえてこのタイトルにしたという。
「作ってもらう」だと長いし卑屈だし、「ともに作る」だと読者ターゲットがぼやけるし引っ掛かりがない。確かに。正確には「システムを作らしむる技術」だろうか・・・ちょっと辛気臭いか。

経営、業務、IT部門・・発注する側が心得るべきこと、プロジェクトに貢献すべきこと、やるべきことがとても具体的にオープンに説かれている。コラムも軽妙ながら実感がこもっていて膝を打つものばかり。
相当なボリュームだがおそらく軽量紙が使われており携行や読みやすさにも配慮されている。ケンブリッジ社の宣伝本というレベルでは全然ない、制作に熱量のこもった本だと思う。
注文住宅建築のアナロジーが何度か出てくるが、確かにそうだ。この本に書かれているエッセンスは、必ずしもシステム発注だけでなく人生で大きなプロジェクトオーナーになるときに役に立つだろう。
難を言えば、この本を読んだだけでやれる気になってしまうことである・・・

P18 「システムを作らせる当事者はだれか？」は意外に大きな問題で、ここでのすれ違いがシステム構築を失敗に導いているケースがかなり多い。

P28　不確実性コーン＝時間が進むごとに不確実性が減っていく　「最初はあいまいなことしかわからない」は車を買う時と大きく違う（車の家格で曖昧なのは、せいぜい値引き率が5％か10％か、といった程度だ）だから、システムをつくらせる人であるあなたも、システム構築プロジェクトの本質であるあいまいさに耐えなければならない。

P47　「標準化」は一見合理的で反対しにくいが、そういうきれいすぎる旗印をゴールに掲げると、たいていはタダのお飾りになってしまう。本気で目指していないので、プロジェクトが具体的な検討をする段階に来ると「総論賛成だが各論には反対」が巻き起こり、妥協に妥協を重ねることとなる。それを避けるために、「本当に標準化すべきか？」についてとことん議論する合宿を開くことにした。

P91　何人かで議論しながら作る場合は特に、壁に張り出したアナログのフローが有効だ。pptなどで作り込むと「完成版」として受け取られ、「こんなんじゃあ全然仕事が回らないよ」と反感を食らいやすい。だがアナログだと、あからさまにたたき台に見えるので、積極的に改善意見をもらいやすい。

P100　組織で要求定義するときの難しさ・・①完璧なリストアップができない②常に予算オーバーになる③立場が違えば求めるものが変わる（住宅建築に似ている）∴要求定義とは利害関係者の意見を”まとめて”実現すること／実現しないことを”ゆるぎなく”定めること。

P131　FM（ファンクショナリティマトリクス）のまとめ方・・・FMのセルの粒の大きさを無理に揃えなくてもよい。まずはおおよそ粒度が揃うように、ユーザーにとってわかりやすい粒の大きさでセルを書く。一通り書き終わった後に、あとで議論しやすいようにセルを分割する。

P142　完璧なFMを目指さない。100％完璧なFSはできないだけでなく、目指すべきでもないのだ。
セルの優先順位を決められればOK、開発工数が2倍以上ズレなければ良しとする。

P144　作るものと作らないものとはっきりさせること、つまりプロジェクトの「実行範囲」(scope)を決めることこそがスコープフェーズの目的なのだ。「スコープなんてしゃらくさい言い方ではなく要求定義って呼びましょう」という顧客は多い。だが名前が違うのは中身が違うからだ。譲れない一線もあるのですよ・・

P160　効果があり、簡単に作れ、簡単に使いこなせる機能を真っ先に作る。「効果がある」とはビジネスベネフィットが高いこと。「簡単に作れる」とは技術的容易性が高いこと。「簡単に使いこなせる」は組織受け入れ態勢が高いことだ。

P176　脆弱なコンセンサス＝一応Yesと言ったものの、堅くないのだ。【中略】「あきらめてください」と口で言うより、FMを黒く塗るほうがずっと心理的負荷が低い。FMはコミュニケーション下手なエンジニアを助けるツールでもあるのだ。

P182　FMは要求定義ドキュメントというよりも、プロジェクトを推進するためのコミュニケーションツールなんだ

P223　あるベンダーからの質問やこちらからの回答を、他のベンダーにも知らせるか？・・・（筆者は知らせない派）ベンダーからの質問内容はベンダーのやる気や能力をはかるヒントになる。「○○をFMでは想定していないように見える。意図したものか、想定漏れか」という質問をするベンダーは、今回のプロジェクトでの経験が豊富な確率が高い。

P227　ベンダーが用意したデモシナリオを使うべからず・・・見せたいもの合戦になり同じ土俵で評価できない。そのため、あらかじめ提示したシナリオに沿って、各社同じ流れでデモをしてもらう。しかしデモを準備するのはベンダーにとってかなりの手間になるので、デモシナリオは、しっかり確認したい部分、パッケージごとに差がありそうな部分に絞り込む。

P233　ベンダー選定にあたっては、とにかく手段を選ばずすでに使っている人と話をするべきだ。【中略】弱点を聞き出すと少しがっかりするが、選定時点で弱点を把握しそれでも腹をくくって選んだほうが後悔しなくて済む。これは厳しいシステム構築プロジェクトをやり切るためには案外大切なことだ。

P255　各工程の途中で、作りかけの成果物を見せてもらう日をあらかじめ決めておく。これをマイルストーンと呼んでいる。【中略】マイルストーンチェックをしていると、それでは説明のつかない事態にしばしば遭遇する。「そもそも全く進捗していない」「でき上ったはずの仕様書10枚の品質がボロボロ」こういう事態を早く見つけ、早く手を打つしかない。

P295　BPP（プロトタイピング）に出席する人の心構え・・・プロセス全体の確認を優先する（細かいことに目が行かないよう、確認ポイントやFM/FSを手元に準備しておくとよい）。動かないことにいちいち目くじらを立てない。課題が見つかったら喜ぶ。

P302　よい開発チーム　ユーザーが参加し続ける・保守担当に参加してもらう

P305　請負契約をやめフェーズごとの準委任契約にする・自ら率先して「プロジェクト最適��を言い続ける

P327　ITベンダーは品質など気にしていない！・・・定義にもよるのだが、「品質」と「精度」は別の概念である。
精度：システムが正しく動くか　品質：システムが良いか

P336　システム構築プロジェクトでデータ移行は全工数の35％を占めるという。別のアンケート調査では、データ移行でトラブルが生じたかという問いに8割のプロジェクトマネージャがyesと答えた。

P344　現行システムと新システム双方の知識に加え、業務知識も必要になる。だがそんな人はいない。そこで「移行ファシリテーター」を任命する。

P345　なぜデータ移行の大変さがぴんと来ないか・・・作ることの大変さvs引っ越しの大変さの比率を考えたとき、引っ越し側がこんなに大変なことって世の中にめったにない、だからうまく想像ができない、という仮説。【中略】大企業で使うオーダーメイドシステムの移行は、世の中の引っ越し的な作業の中でも例外的に大変なのだ。工数の4割と来た時いくらなんでもそりゃ過大見積でしょう、と思ってしまう。こういう錯覚の檻から理性で脱出するのは極めて困難だ。

P370　ウォーターフォール開発、アジャイル開発、その中間・・・住宅に例えると、ウォーターフォールの場合は完成引き渡しまでは済めない、アジャイルで作ると、今日は台所ができたからさっそく料理をして試した、トイレはまだできてないから公園に行くといったイメージ。アジャイルの弱点は全体コントロールが難しい。また全体が密接に結びついている複雑なロジックの塊のシステムはあまりアジャイル向きではない。

P381　なぜこんなややこしいことになっているかというと、世の中には「俺がほしいシステムをアイツらに作らせればいいんだ」と思っている人々が厳然として存在しているからです。皮肉なことにそういう人々がいくら金を払っても「システムを作らせる」という態度のままでは、システムをうまく作ってもらえない(これはシステム構築プロジェクトに潜む最大のパラドックスかもしれない。）

投稿元：

レビューを見る

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

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

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

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

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

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

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

投稿元：

レビューを見る

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

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

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

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

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

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

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

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

投稿元：

レビューを見る

開発を依頼する側に立ってなかなか苦戦していたので、これを読んで、発注側がやるべき姿、作る側の人の立場などがクリアになった。

投稿元：

レビューを見る

半分まではシステム作成を依頼する側に立った視点での概念論。非常にわかりやすく、納得出来る。後半に進むに従い、業務の流れに沿い、具体的な話になる。そこそこページ数あるので、まとめがあるとありがたい。

投稿元：

レビューを見る

システム導入しようとしているユーザー企業の関係者全員に読んでほしい。
導入前の準備段階で読んでほしい。
心構えをもってプロジェクトに参加してほしい。