ビジネス書の杜　令和

これまで、新社会人むけとか、ＩＴアーキテクト向けなどが出版されていたが、昨年プロジェクトマネジャー向けが出版されたので、読んでみた。見開き２ページで、テーマはおそらく自由設定。この記事の最後にテーマの一覧をつけておくので、見てほしい。僕がどういう読み方をしていたかというと、地下鉄や電車で３０分以上、移動するときに１テーマずつ読むという方法をとっていた。日本の出版者で、「通勤●●」というシリーズをやっているところがあるが、まさにそんな使い方をしていた（ただし、僕は通勤はしていないので、移動中だが）。１２月くらいから読み始めて、やっと読み終えた。

賛成できる意見、賛成できない意見、さまざまである。ただ、賛成できないものも含めて極めて質が高い。出版関係の人であれば、そんなことはムックでやっていると思われる方もいると思うが、こんな質の高いムックはお目にかかったことはないし、ムックに寄稿した経験からいえば、ポリシーが違うように思う。

一番、近いのは、ウェブ中のよいオピニオンを集めて、書籍化したイメージ。今までの本が、プロダクトアウトだとすれば、この本はおそらく、マーケティングインで作ったような本だ。９７のポイントというのは、著者の声であるとともに、市場の声でもあるからだ。この本の作り方を即座に否定しそうな編集者の顔が何人も浮かんでくるが、少なくとも、プロジェクトマネジメントに関してこの本以上のインパクトのある日本人の著作の本というのは２～３冊しか思い浮かばない。そのくらいのインパクトがある。

特に「威厳」と重んじる国・日本では、本にすることによって何となくみんなが信用する傾向がある。たとえば、日経ＢＰのようなメジャーできちんと作り込んだサイトでも、ウェブに書いてあることより、そこらの「つまらない」本に書いてあることの方を信用する人が多い。日経ＢＰのような立派な活動ではないが、僕がネット上の活動を１０年やって得た結論でもある。

ただ、本とは何かというと本来、こういうものだったのだ。知恵を紙に記すことによって、未来に残す、グーテンベルク以降はその知恵をいろいろな人に使ってもらう。

本にするということは、その知恵に価値があるから本にするのだ。ここに、本の威厳の源泉があるわけだが、インターネットの普及以降、このロジックは崩れてきた。価値があろうが、なかろうが、インターネットで自分の意見を届けることができるようになってきた。その前提には、情報の選別は、各自が自己責任で行うという前提が置かれた。ところが、現実にはこれは難しく、そこで出てきた問題が情報選別の問題である。

上にも述べたように、この問題がブランディングだけで片付くとは思えない。

インターネットと共存する本のあり方の一つが、オライリーの提案ではないだろうか。冒頭に述べたように、Oreillyの技術書のインパクトはすごいものだった。いまでこそ、インターネットを探せばどこかに情報があるが（この情報は特定の技術者のものではない！）、インターネットの普及以前に、まったく分からないものがオライリーを読めば何とかなっていたのだ。これはすごいことだ。オライリー本がなければ、インターネットの進歩は５年は遅れていたかもしれない。

このシリーズはひょっとするとインターネット以前の技術解説シリーズが与えたのと同じインパクトをもたらす可能性がある。可能性をいち早く感じたい人は、ぜひ、この本を買って読んでみてほしい。知恵だけを得たい人は、１～２年の間には、翻訳が出ると思うので、それを待つのもいいと思う。

「プロジェクトマネジャーの９７の知恵」

Chapter 1 : Get Users Involved As Early As Possible
Chapter 2 : Avoid Whack-a-Mole Development
Chapter 3 : A Word Can Make You Miss Your Deadline
Chapter 4 : Make Project Sponsors Write Their Own Requirements
Chapter 5 : Favor the Simple Over the Complex
Chapter 6 : Pay Your Debts
Chapter 7 : Add Talents, Not Skills, to Your Team
Chapter 8 : Keep It Simple, Simon
Chapter 9 : You Aren't Special
Chapter 10 : Scrolling Through Time
Chapter 11 : Save Money on Your Issues
Chapter 12 : How to Spot a Good IT Developer
Chapter 13 : Developer Productivity: Skilled Versus Average
Chapter 14 : Size Matters
Chapter 15 : Document Your Process, Then Make Sure It Is Followed
Chapter 16 : Go Ahead, Throw That Practice Out
Chapter 17 : Requirement Specifications: An Oxymoron
Chapter 18 : Success Is Always Measured in Business Value
Chapter 19 : Don't Skip Vacations for the Project
Chapter 20 : Provide Regular Time to Focus
Chapter 21 : Project Management Is Problem Management
Chapter 22 : Empowering Developers: A Man Named Tim
Chapter 23 : Clever Code Is Hard to Maintain
Chapter 24 : Managing Human Factors in IT Project Management
Chapter 25 : Use a Wiki
Chapter 26 : The Missing Link
Chapter 27 : Estimate, Estimate, Estimate
Chapter 28 : Developers Unite?PMOs Are Advancing
Chapter 29 : Value Results, Not Just Effort
Chapter 30 : Software Failure Is Organizational Failure
Chapter 31 : A Voice from the Other Side
Chapter 32 : Keep Your Perspective
Chapter 33 : How Do You Define "Finished"?
Chapter 34 : The 60/60 Rule
Chapter 35 : We Have Met the Enemy...and He Is Us
Chapter 36 : Work in Cycles
Chapter 37 : To Thine Own Self Be True
Chapter 38 : Meetings Don't Write Code
Chapter 39 : Chart a Course for Change
Chapter 40 : IT Program Management: Shared Vision
Chapter 41 : Planning for Reality
Chapter 42 : The Fallacy of Perfect Execution
Chapter 43 : Introduce a More Agile Communication System
Chapter 44 : Don't Worship a Methodology
Chapter 45 : Don't Throw Spreadsheets at People Issues
Chapter 46 : One Deliverable, One Person
Chapter 47 : The Fallacy of Perfect Knowledge
Chapter 48 : Build Teams to Run Marathons, Not Sprints
Chapter 49 : The Holy Trinity of Project Management
Chapter 50 : Roadmaps: What Have We Done for You Lately?
Chapter 51 : The Importance of the Project Scope Statement
Chapter 52 : Align Vision and Expected Outcome
Chapter 53 : Alice Doesn't Live Here Anymore
Chapter 54 : Avoiding Contract Disputes
Chapter 55 : You Get What You Measure
Chapter 56 : Don't Fall into the "Not Invented Here" Syndrome
Chapter 57 : Favor the Now Over the Soon
Chapter 58 : Speed Is Life; More Is Better
Chapter 59 : Building the Morale on Your Team
Chapter 60 : A Project Depends on Teamwork
Chapter 61 : Serve Your Team
Chapter 62 : The Fallacy of the Big Round Ball
Chapter 63 : Responding to a Crisis
Chapter 64 : Know Your Integration Points
Chapter 65 : Aggressively Promote Communication in Distributed Projects
Chapter 66 : Start with the End in Mind
Chapter 67 : Clear Terms, Long Friendship!
Chapter 68 : The Best Estimators: Those Who Do the Work
Chapter 69 : Communicating Is Key
Chapter 70 : A Project Is the Pursuit of a Solution
Chapter 71 : It's the People, Stupid
Chapter 72 : Documents Are a Means, Not an End
Chapter 73 : Can Earned Value and Velocity Coexist on Reports?
Chapter 74 : Scope Change Happens; Get Used to It
Chapter 75 : Buying Ready-Made Software
Chapter 76 : Project Sponsors?Good, Bad, and Ugly
Chapter 77 : Should You Under-Promise, or Over-Deliver?
Chapter 78 : Every Project Manager Is a Contract Administrator
Chapter 79 : Important, but Not Urgent
Chapter 80 : Teach the Process
Chapter 81 : The Fallacy of Status
Chapter 82 : What Do They Want to Hear, Anyway?
Chapter 83 : Recognize the Value of Team Morale
Chapter 84 : Engage Stakeholders All Through Project Life
Chapter 85 : The Value of Planning
Chapter 86 : Don't Always Be "The Messenger"
Chapter 87 : Effectively Manage the Deliverables
Chapter 88 : We Are Project Managers, Not Superheroes
Chapter 89 : Increase Communication: Hold Frequent, Instant Meetings
Chapter 90 : Flexibility Simplifies Project Management
Chapter 91 : The Web Points the Way, for Now
Chapter 92 : Developers Hate Status Reports, Managers Love Them
Chapter 93 : You Are Not in Control
Chapter 94 : Share the Vision
Chapter 95 : True Success Comes with a Supporting Organization
Chapter 96 : Establish Project Management Governance
Chapter 97 : 9.7 Reasons I Hate Your Website