濵本佳史のレビュー一覧

たしかに本書の通りに
・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割型を占める。

なぜ作るのか。...続きを読む
なにを作るのか。
どうやって作るのか。

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

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

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

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

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

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

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

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

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

システムを作る側としても、作らせる側に知って欲しい、やって欲しいことが、実践できるテンプレに落とし込まれていて、とても良い。作る側の会社でも、新人や営業の人に顧客対応で戦力になってもらえるよう実践できるようになって欲しい内容。作らせる側が、作る側をどう見るのかという点でも、この本の評価軸で、作る側の...続きを読む会社として自社はイケてるのかチェックできる。大手SIerには、仕事の型が用意されてるので、この本の内容は社内教育で得られるかも知れないが、そんな余力がないとこなら、まずは最初に実践の型として採用するのも良いような気がする。

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

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

業務側として大きな案件のシステム担当になり、要件定義〜立ち上げまで経験した。利用者への理解活動や開発の手戻り（検討漏れ）に苦労し、正解はなんだろうと思っていたが、本書には正解に繋がるエッセンスが散りばめられていた。

システムを構築する上で踏むべき手順が、わかりやすく書かれていると感じました。
システム改修の最中にこの本を紹介された際は読む余裕がなく、再雇用後に読むこととなりましたが、これからの業務改革にも使えそうです。

何らかの業務課題を解決するため、システム開発を外注する場合に必要な一連のアクティビティ（コンセプト設計から運用まで）が掴める。システム開発に取り組むチーム員と読んでおくと、認識を合わせる上で非常に有用だと感じた。

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

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

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

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

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

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

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

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


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

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

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

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

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


総論賛成各論反対

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

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

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

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

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

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

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

コミュニケーション計画

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

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