...というか、見出しの一覧。これ見てご興味ある方はお読み下さいませ。生産性の測定について管理者の怒りについて会議を効率よく行うための、たったひとつの冴えたやりかた大事なことが、ずばり書いてある。背中を押したのは「ソフトウェア開発の名著を読む」なんだけど、確かに名著だ。初読は物語を楽しみ、再読、再々読で血肉にすべきだな。延ばし延ばしにしてた一冊を読み始めて「どうして今まで読まなかったんだあぁぁっ」と叫びだすような逸品がある。デマルコは「ピープルウェア」がピカイチと決め付けてた自分が恥ずかしい。「ピープル」がプログラマ・チームリーダーの視点で書いているが、「デッドライン」ではプロジェクトマネージャをテーマとしている。この業界でPMやっている方なら、沢山の気づきが見つかるだろう。いや、気づきだらけといってもいい。マネジメントの4つの本質そのうち、アタマガツンとやられる「気づき」がある。正しい管理の四つの本質がそうだ。簡潔で、痛烈だが、真実だ。チームワークか、あったりまえじゃねーかと思いながら、最後の一文で凍る。ぐぅの音も出やしない。この本質を疎かにしたら、プロジェクト計画書やWBS、ガントチャートはまるで意味をなさない。それらはツールでしかないから。ツールを玩ぶのは"ごっこ"そのもの。ソフトウェア・システムは人が作る。自動化が喧伝されるが、本質は不変だ。次の式が常に成り立つ。人の問題この「人」の中に自分も含めていい。何らかの問題が発生するならば、その原因(の根っこ)には、自分も含めた人が存在する。その解決策(の根っこ)には、やっぱり人がいる。小説じたてでエッセンスが紹介されるのは、制約条件理論の「ザ・ゴール」と一緒。導師(グル)の教えをレクチャーする話ではなく、メンバー同士の会話が問題解決への突破口となっており、気が抜けない。架空の自分をそこに紛れ込ませて、「自分だったらどうするか?」をあれこれ考えるというわけ。「ご教授を賜る」ための読書ではなく、自分の経験・ノウハウを当てはめながら一緒になって悩むことができる。マネジメントおける簡潔で痛切なエッセンス(一部)エッセンスの一部を紹介する。簡潔で、痛切だが、真実だ。戦闘が始まるときには、管理者のほんとうの仕事はもう終わっている変更は、あらゆるプロジェクトの成功のために必要不可欠だ人は安全だとわからないと変更を受け入れない。安全が保証されていないと、リスクを避けようとするどれほど強い脅しをかけても、最初に割当てた時間が足りなければ、やはり仕事は完成しない短期的に生産性を高める方法などない。生産性は、長期的な投資によって向上するリスクを管理することでプロジェクトを管理せよ一日をむだにする方法はいくらでもある...しかし、一日を取り戻す方法は一つもない設計とデバッグに関する恐ろしい事実ただ「気づき」をもらうだけではない。自己の苦い経験を思い出させ、そこからどうすればよかったかを過去に戻って気づかされることもある。『バグがあっちゃいけないってことだ。わかってるじゃないか。『さあ、考えてみろ、あるモジュールの中でバグを見つけた。モジュールの端にあるんだ。たしかに、真ん中へんにも簡単なバグはある。そのモジュールの内部だけのやつだ。そいつらは調べれば簡単にわかる。「そうです、だれでも知ってることです。「なにを見るんですって?」トムキンスはいらだってたずねた『モジュールと、その内部を見るんだ。「でも、設計をレビューするときに、欠陥は取り除くように努力しています。それはもうやっています。「設計はやるにきまってます。設計段階でやってないんだ。設計のときは、チームはドキュメントを作成する。"理念"なんてものをでっちあげて、ファイル・レイアウトなんかを一つ二つ作って、形だけのレビューをやる。連中が考えてるのは、管理者にうるさく言われないために必要なことをやって、早くコーディングに進むことだけだ。最後に、管理者がオーケーを出す。チームは喜んで、いわゆる設計は棚に放り込んで、二度と見ることもない。コーディングの段階になってほんとの設計をやっている。コーディングの最中に、だ。そのころになって、実際のモジュールをどうするか、実際のインタフェースをどうするか決めてるんだ。ここまでなら周知の事実かもしれない。わたし自身、この会話は誰かとしたことがある。この状況でどうすべき『だった』か、つまり、主人公トムキンスがこの後どのように行動したか、そしてその結果は――ご自身でお確かめあれ。結論はできすぎた話かもしれないが、理解はできる。自分がその打ち手を選ぶためには、【勇気】が必要。小説だから書けた話なんだろうが、薄々分かっていたけれど、ひょっとすると――ひょっとしなくても、本当のことなんだろう→「残業時間が増えれば増えるほど、生産性はガタ落ちすること」。ええまぁ、わたしの経験からしても、「昼間は雑務や電話応対で、アタマを使う設計やプログラミングは夜間の仕事」と分けていたから。顧客の電話の相手や、くだらない書類・メールに邪魔されて、昼間は落ち着いて仕事ができない、というのが原因だ。生産性とは、ホントのところ、時間あたりのライン数などではなく、利益をコストで割ったもので計るべきなんだろう。利益は、仕事からの収益や削減できた金額で計ることができるし、コストは全体コスト(退職者の補充・要員の追加に伴う教育費を含む)で算出できる。この観点に立つなら、メンバーの士気をすり減らし、燃え尽きへ追いやる残業は即ち「悪」といえる。「残業時間を増やすこと→より多くの結果を出すこと」が間違いなら、管理者にはすることが無くなってしまうではないか。この質問にはスゴ腕のPMであるベリンダ(ただしホームレス)がこう答える。むずかしいことばかりね。採用、刺激、チームの力学、優秀な人材を保ちつづけること、手法から非効率的な部分を取り除くこと、ミーティングを減らすこと、オーバーヘッドを減らすこと、余分なドキュメンテーションを削減すること」そして、時間外労働に突入しようとするメンバーには、こういういうべき→「家へ帰れ。今から10分以内に電気を消すぞ、本気だからな」ってね。はいっても締め切りが、プレッシャーが、デッドラインが...と反論することは可能だ。本書の題名どおり、勘ドコロを突いているのが次の回答だ。【質問】プレッシャーがプログラマーに与える影響が、6%の生産性向上だけで平坦化してしまうのはなぜですか?【回答】プレッシャーをかけられても思考は速くならないこの一行は10回読んだ。絶対に忘れてはならない一行なり。生産性の測定について「生産性を測定することは不可能だ」←この意見に反発を覚えたことがある。この業界のグルの御発言なので、めったな反論は差し控え、実践で証明してみようと色々試みている。わたしの場合、完全新規のスクラッチなんて無い。以前に似たもの(あるいはプロトタイプ)を作っている。過去の類似プロジェクトから類推できる部分と、新技術を導入したことで不明確な部分とに分け、後者を段階的に係数化して見積もり・管理してきた。リスクテイクしなければならない部分を最初から切り分け、予実の乖離は発見次第、即反映している。FP法の猿真似だが、似たようなプロジェクトを任される限り、かなり精確に出せている。そんなわたしにとって、第12章「プロジェクトの数量化」の以下のくだりでは、強力な味方ができたようで、大いに励みになった。測定単位を気にするな。客観的な尺度ができるまでの間は、主観的な単位を使えばよい考古学的なデータを収集し、これまでに完了しているプロジェクトから生産性を算出する過去のプロジェクトをもとにトレンド・ラインを引き、予想される労力を合成尺度の値の関数として示す予想をたてるべき管理者の怒りについてこれまた陳腐な話題かもしれないが、どこの職場にも必ず一人はいる「怒れる管理者」。高圧的で、嫌味ったらしく、みんなの嫌われもの(本人はそれが"管理者のあるべき姿"だと思い込んでいる)。笑顔やアクビが伝染するように、怒りも伝染する。上の管理者が怒鳴ると、下の管理者も同じような行動をとる。虐待された子どもが自分の子どもを虐待するのと同じだ。本書では怒れる管理者をズバリ「管理者としての能力不足」と断ずるが、それだけではない。ついてこれまたズバリと書いている。それは、恐れているから。仕事場では、恐怖を表に出すことは許されない。何かを吐き出す必要があるとき、たいてい怒りが選ばれる。以下の文章をもっと早く知っていたら、どれだけ(過去の)わたしが救われたことだろう。部下に対して罵倒の行動をとる管理者は、ほとんどの場合、恐いからそうしているのである怒っている人は、恐怖を表に出したくない。怒りが恐怖の表れだと分かってしまったら、怒りを吐き出すこともできなくなるこれは怒っている人の問題は解決できないが、他の人の悩みは軽減できるだろう怒れる管理者の心がよーくわかった。あの人はだからいつも怒ってるんだな、と思うと、少し気持ちが軽くなった(この秘密は今怒鳴られているアイツにも教えてやろう)。会議を効率よく行うための、たったひとつの冴えたやりかた第20章、これは知っていた――というか、何百回もひどい目に遭って、ようやくたどり着いた、たった一つの冴えたやりかた。十年前に知っていたなら、考えたくないほど莫大な時間と労力を節約できていただろう。会議は、重要ではない人物が出席しなくても心配ないように、小さくする必要がある。欠席者が安心するための最も簡単な方法は、議事予定表を発行し、それに厳密に従うことである何百時間も自分の時間を費やして、同じ結論だ。決めます」で始めるを実践している。上記の条件を一つも満たさない会議には出席しない(あるいは退席する)ようにしている。会議のやり方に限らず、他にも、多すぎるメンバーが招く問題や「製品の部品=プロジェクトの構成」からくる問題(第19章)、プロジェクトをめぐる病んだ政治にまきこまれた場合に気をつけねばならぬこと(第21章)などなど、思い当たることばかり。身におぼえのある会話、何度も悩んだことがある問題と対策が【ぜんぶ】書いてある。いちいちヒザを打ってたなら、真っ赤になるね。わたしゃもう若くないので、若い人――20代かな――に読んで欲しい。わたしが自分の時間や労力を浪費してたどり着いたシンプルな真実を、こいつを読むことで先回りして知っておいて欲しい。