白川克のレビュー一覧
-
Posted by ブクログ
「そもそも、なぜプロジェクトは失敗するのか？」
この根本的な問いに対して、著者が提示する「人はやったことがないものをプロジェクトと呼ぶから」という言葉に、深く膝を打ちました。不確実な初挑戦である以上、プロジェクトは本質的に「失敗しやすい性質」を持っています。最初から失敗する前提に立ち、いかにその確率を減らしていくかの指南書として、極めて示唆に富む一冊です。
本書に挙げられている55の罠は、どれも現場経験者なら「あるある」と胃が痛くなるものばかりです。しかし、これらすべてを完璧に回避しようとするのは非現実的です。また、個々の罠は原因と結果で複雑に連動しているため、できるだけ原因と思われる罠にアプローチすべきです。
例えば私の場合は、現場の変革推進において特に致命傷となりやすい「重要な20%（11個の罠）」を抽出して深掘りしてみました。
03 脆弱なゴール 04 理想論で突き進む 08 過去の失敗に向き合わない 10 業務メンバー不足 12 他社事例から学ばない 18 メンバーが皆ひとごと 19 野蛮さ不足 24 業務部門とIT部門の相互不信 25 リーダーシップ不足 26 上流を端折る 49 コンフリクトを避ける
自身が推進役（変革リーダー：PL）であり、自責として考えると最も刺さるのが「25 リーダーシップ不足」です。本書ではリーダーに求められる素養として「ビジョン構想力」「業務やITの知識」「的確な洞察力」「軋轢に動じない胆力」「皆をまとめる人望」が挙げられています。しかし、これらを1人の人間がすべて兼ね備えるのは、まさに「スーパーマン」を求めるようなものです。だからこそ、1人のリーダー像に依存せず、不足する役割を相互に補完し合えるチームビルディング（PLとPM/PMOの機能分担など）が不可欠であると痛感させられます。
また、特に他にない視点でありながら芯を食ってると感じたのが「19 野蛮さ不足」と「49 コンフリクトを避ける」です。単なるカイゼンではなく「変革」を成し遂げようとするとき、周囲と軋轢が生まれるのは必然です。いい顔をして摩擦を恐れ、意思決定を先延ばしにするのではなく、大義のために誰かが「地雷を踏みに行く」覚悟や、多少の強引さ（野蛮さ）を持って突き進む姿勢が求められます。
罠の多くが「上流・超上流」の構想・計画フェーズに集中している点も納得感があります。もちろん、プロジェクトのフェーズが進むにつれて注視すべき罠の重み付けは変わっていくでしょう。
プロジェクトとは、どこまでいっても泥臭く、青臭い人間ドラマです。罠だらけの荒野を進むすべてのリーダーにとって、本書を片手に泥臭く、そして青臭く罠を回避しながら前進するための必携の書としてお勧めします。 -
Posted by ブクログ
プロジェクトの立ち上げ・計画段階で成否が決まる、そのフェーズにおいてどういったポイントを外さずに進めるべきか、逆にすべきでないこと、どういった人を押さえておくべきかなどが具体的な過去事例をベースに書かれていて参考になる。
具体例も書かれつつ、要点が明確に書かれているため実践する時に思い出しやすいのも良い。例えば、課題調査のポイントとして①それはどの程度発生し、②なぜ起こり、③なぜ正せないのか？が挙げられており、実際に現場ヒアリングなどで活かすことができた。この結果、改革の方向性として提示されていたECRSの原則（Eliminate, Combine, Rearrange, Simplify）も非常に有益だと感じた。 -
-
-
-
-
-
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 導入したらビジネスはどう変わるのか、それはなぜ嬉しいのか？
→わかりやすい問いでいいなと思ったのでメモ。
-
-
