濵本佳史のレビュー一覧
-
Posted by ブクログ
「DXを進めているはずなのに、なぜか手応えが得られない」「現場でいくら足掻いても、全社的な変革に繋がらない」――変革の現場で生じるこの閉塞感の根本原因は、まさに「超上流（構想策定・IT戦略）」にあるのだと、本書を読んで深く腑に落ちました。
多くの企業でDXが形骸化してしまうのは、個別プロジェクトの頑張りが足りないからではなく、全体を貫く戦略と目的が曖昧なまま走り出してしまうからです。本書は、単なるツールの導入論や成功事例の羅列ではありません。「成功するよいIT戦略とは何か」という本質論から、戦略の描き方、そして組織を動かす実行プロセスまでが、膨大な現場の経験値をもとに見事に体系化されています。
特に実務において膝を打ったのが、「ITシステム全体を押さえる9領域」から自社の「急所」を特定するアプローチです。あれもこれもと手を広げるのではなく、他社に大きく劣後している点や全社戦略とのギャップを見極め、突出して問題となっている根本原因（急所）に絞り込んで手を打つ。この優先順位付けとロードマップの描き方は、現場の混乱を防ぎ、迷走を断ち切る強力な羅針盤になります。また、投資対効果を単なるROIだけでなく、事業継続や競争リスク、さらには「感情と共感」まで見据えて捉えている点にも、著者の深いリアリズムが滲み出ています。
そして本書最大の白眉と言えるのが、戦略を実行へ移すための「態勢（身構え）」づくりです。DXはIT部門だけで成し遂げられるものではなく、「経営者」「業務部門」「IT部門」の3者が協調して初めて前進します。本書では、この3者を繋ぐリーダー（PL）の役割や、変革受容曲線に沿ったコミュニケーション設計など、泥臭いヒューマンスキルの重要性が徹底して語られます。「6回伝えて6割伝わる」という心構えや、心理的安全性の構築など、組織が変化を受け入れる態勢をどう整えるかという示唆は、変革に関わる者にとって胃が痛むほどリアルであり、同時に極めて実用的な処方箋です。
「ITを全社の武器にする」とはどういうことか。過去の失敗や現状の課題を客観的に見つめ直し、次の一歩を踏み出す勇気をくれる名著です。変革をリードする立場の方はもちろん、ITと事業の連携に悩む経営層やマネジメント層にも強くお勧めしたい一冊です。 -
-
-
-
-
-
Posted by ブクログ
勤めている会社のシステムがあまりにもアナログで非効率が目立つので「何とかしたい」と思っていた今の自分にズバリ刺さってきた本。副題に「エンジニアではないあなたへ」とあるように、システムを変える・構築するプロジェクトを動かす者が心がけなければならないことが、実務面も含めて説明されている。
技術的なことは難しい（エンジニアに任せるしかない）が、エンジニアという人種やシステム会社の考え方、立ち位置をよくよく理解していないとコミュニケーションギャップにつながり、それが致命的なミスを招く。ビジネス書の類は失敗談はほんの少しで成功談ばかり書く方が多いが、本書は失敗談が半分近く、かなり生々しく人間の心理にまで踏み込んで事例が出されており、かなり参考になる。システム構築とは完璧はありえず、それも織り込んだプロジェクト進行が必要だと理解できた。
極めて専門性の高い分野を「使いこなす」力量と共に、覚悟と調整力、全体を俯瞰する力が問われる。今自分がやろうとしていることのバイブルになり得る一冊だった。 -
Posted by ブクログ
データアナリスト職です。BI帳票を開発業務として取り組んだ経験がなかったため開発工程を体系的に知るのは初めてでした。
BI帳票を開発業務として取り組むと工程が多くなりスピード感が失われ、ビジネスの期待値に届かない事が多い思いを持っていたのですが、これまでの歴史が積み重ねてきた開発のノウハウがBI帳票開発にも応用することで活きるケースがあると感じました。
例えば、開発機能（帳票）の優先順位を機械的にジャッジすることで既存帳票の現状踏襲を防ぐ。いまある帳票は数値を今まで見れていたからと無批判に作ってしまうことを防ぐ。そうした進め方ややり方もあるという学びがあります。
読んだ上でBI帳票作成の全てが開発工程に当てはめて進めること自体は是々非々で柔軟にやるべきだと思うが（TooMuchな部分があるので）Whyから始めるなど開発工程のスキームがBI帳票作成品質の底上げに繋がると思う
また、こうした本はいかに現場の課題感や失敗の生々しさを表現できるかが鍵だと思います。その中で書籍という形式上どうしても生々しさの表現が難しく目減りしてしまうことが多いが、可能な限り現場や実務の生々しさが伝わるように記載されていて良かった。生々しさを担保するコラムにこそ価値があると感じます。 -
Posted by ブクログ
Cambridge RAD という、ウォーターフォールとアジャイルの中間的なシステム開発&導入手法について述べた書籍だ。本書の中では特に要求定義のCambridge RAD版である「Scopeフェーズ」のくだりが素晴らしかった。中盤まるまる「社内調整が捗るような要求定義のスプシまとめ」のノウハウに費やされており、(1)｛ビジネスベネフィット, 組織受入体制, 技術的容易性｝の三項目別に優先度｛High, Middle, Low｝を決め、(2) その優先度の総合点に応じて｛優先的にやる（白）, 遅れてやる（灰）, やらないとキッパリ伝える（黒）｝の三色に塗り分け、(3) 社内関係者を説得するために最終的な説得用の表資料をつくりあげる（FM: Functionality Matrix）という手順を伝えてくれる。このpp. 095–196の内容を読めただけでもこの本を手に取った甲斐があった。
その前後には、社内要望を掬い取ること、ベンダを選定してうまく作ってもらうこと、それぞれの過程についてノウハウを開示しているが、それは他の本でも書かれてあることだ（この本でもそれぞれのくだりを丁寧に書いてくれていることは評価するが）。しかし要求定義についてここまでしっかり書いてくれていた本はなかなか見つからなかった。届くべき人に届いて欲しい本だ。
著者の指定姉妹本には『業務改革の教科書』が挙げられており、その本を読んでみたくなった。
惜しい点としては、記載されるExcelの印刷解像度が低すぎること。ここはスクリーンショットをもう少し綺麗にやってほしかった。 -
-
-
-
Posted by ブクログ
ものすごく役に立つことが書いてある本。
データ移行は大変だよとちゃんと書いてある！
「カネと労力を使っても、使われないシステム、使えないシステムは最悪」は、私も実体験としてあるので、この本の「関係者をいかに巻き込むか」の方法論は本当に助かる。PMBOKかじり程度なりに、私が「使われないシステムは最悪」の信念でやってきたことの答え合わせができた感じ。間違ってなかったし、さらにステージが上げられる。
この内容をシェアしてくれる著者、ありがたい。早速FMは仕事で作ってみたし、今進めているプロジェクトで巻き込まないといけない人たちの顔が浮かんだし、地道にコツコツやらないといけないことへの覚悟ができた。 -
-
-
Posted by ブクログ
思ったよりボリュームがあり、とりあえずp.94まで心に残ったことをメモ。
・真っ先に具体化すべきことはなにか？
・現時点でどの程度具体化すべきか？
→社内でプロセス化ができいるベンダーほど、意外と意識できてない視点だと思った。プロセスはあってもプロジェクト単位で個々に検討しないとね、というのを改めて本文で指摘された気がした。
・why→how →what
・p.36 システムをどのくらい導入する場合のメリットデメリットをパターンする作業、導入範囲とコストの天秤
→この判断はシステム作る側は判断できないのに、その判断を押し付ける顧客側の多いこと！うんうん唸ってしまった。
・p.55 導入したらビジネスはどう変わるのか、それはなぜ嬉しいのか？
→わかりやすい問いでいいなと思ったのでメモ。
-
Posted by ブクログ
「システムを作らせ」ているという事に携わっていると言う意識のある人々、全員にとっての必読書では？
何がどのような形でいつまでに必要なのか。を決めることが何よりも大事。・・・そして何よりも難しい、というか骨が折れるので、なかなか出来ない。
以下、おわりに より引用
"世の中には「オレが欲しいシステムをアイツらに作らせればいいんだ」と思っている人々が厳然として存在しているからです。皮肉なことにそういう人々がいくらカネを払っても、「システムを作らせる」という態度のままでは、システムをうまく作ってもらえない(これはシステム構築プロジェクトに潜む最大のパラドクスかもしれない)。" -
Posted by ブクログ
ネタバレシステムを作らせる技術
A章作る前に知っておくべきこと
・関係者。経営陣、業務部門、PLが作らせる人。IT部門とそれに紐づくベンダーが作る人。
・why？→how？→whatでストーリーを納得させる。例）工場ごとにバラバラな業務を統合し、一つの会社として運営すべき→統合後の業務プロセスはこうあるべき→そのためにこういうシステムを作ろう
・whatから考えるのでなく、whyから考える。
B章プロジェクト全体の進め方
・メンバー間の意識を合わせる（C章）
・今の仕組みを調べる。ここまでがwhy（D章）
・howにあたる3つを行う。ビジョンを明らかに、そこに到達するための施策を練る、施策群をまとめて1つの計画立案（E章）
・どんなシステムが必要か（F〜M章）
・ベンダー選定（N〜R章）
・プロトタイプ検証（S章）
・システム設計やデザイン（T〜W章）
・切替作業（X章）
C章 ゴール(Why)を明らかにする
・良いプロジェクトゴールづくりの4つのコツ
以降の工程で使えるゴールにせよ
地に足のついたゴールにせよ
何のためのプロジェクトかゴールやコンセプトに込めよ
ゴールのわかりやすさにこだわれ
D章 現状の棚卸をする
・今のシステムの棚卸しを、スイムレーンチャートわタスク一覧表、全体システム構成図などなどから把握
E章 将来像(How)を明らかにする
・システムが変わったらどういう絵姿になっているか？という将来像を描く
・変化点を必ず書き出し、メインフローや概要から取り掛かる
F章 システム要求(What)を求めるプロセス
・要求定義はシステムを作らせる人が求めることを明確にすること。要件定義はシステムを作る人が実装すべき機能を明確にすること。
・網羅性がない、予算オーバーになる、立場が違えばシステムに求めるものが違うなどから、要求定義は難しい
・要求定義の成果物。
FM（ファンクショナリティ・マトリクス）H章で。
非機能要求定義書（M章）
キーチャート
G章 機能を洗い出す7つの方法
・要件定義の第一歩はシステムに求めることについて片っ端から要求を書き出す作業。現行フローや業務フローから洗い出すのも良し。
H章 要求をFMにまとめる
・前章で洗い出した項目を整理。グループに分けて並べて…（サイトなども参考に）
I章 要求の詳細をFSに表現する
・先の項目に対して、具体的に書く。FSファンクション・スペック。
・FSに書くこと。実現したいこと、扱う情報、他の機能との関連、バリエーションやイレギュラー
・FSに書かないこと。実装方法、画面イメージ。
J章 優先順位の基準を決める
・FSにおける優先順位はビジネスベネフィット（ビジネス上どれほど価値があるか？）組織受入体制（そのシステムをどれほど使いこなせるか？）、技術的容易性の3点を3段階評価で決める。
→セルごとに色分け
K章 作る機能を決める
・先の優先度が高いレーティングの機能から作る。
L章 FMがシステム構築を成功に導く
M章 機能以外の要求を定義する
・非機能要求おアーキテクチャの議論が必要。
・非機能要求仕様定義ガイドライン参照。
・システムアーキテクチャの３つのポイント。パッケージか手作りか、オンプレかクラウドか、複数システム間の連携
N章 パートナーの1次選定
O章 提案を依頼する
P章 パートナーを決定する
Q章 稼働までに計画を立てる
・ベンダーから全体スケジュールが展開されるが、そのまま採用するわけにはいかない。精査が必要。
マストな期限が守られているか、業務繁忙期とシステム構築のピークは重なっていないか、工程ごとのゴールが明確か、成果物をチェックするマイルストーンはあるか、各領域の整合が取れているか、各フェーズの期間バランスが適切か
・テストも誰がやるのか、何のテストか確認が必要。どの工程でも、どこまでやったら次の工程に進めるのか、工程ごとに確認を
R章 プロジェクトの投資決裁を得る
・費用対効果のシミュレーションを行う。不確実性があるので、数回行いブラッシュアップを
S章 課題を先出しする
・要求定義に相対するユーザー受入テスト。プロトタイプを使ったチェックでBPPと言われる
T章 開発チームの立ち上げ
U章 キーチャート
V章 開発中の関与
W章 データ移行
X章 いよいよ新システムの稼働 -
-