松原友夫のレビュー一覧
-
-
-
-
Posted by ブクログ
ソフトウェアは人間関係ビジネス。ITのプロジェクトで発生する問題は主に技術的なものより社会学的なもの(ピープルウェア)。オフィスで感情を刺激する最大要因は自尊心を傷つけられること。その自尊心は大抵アウトプットの量より質に結び付けられる。出荷拒否権限。開放型オフィスへの(筆者の)ヘイト。フロー状態を途切れさせない。ホーンブロワーの考えは、現代では公然と言えば袋叩きに遭うだろうが、個人的には現実に即していると思う。自信のない権威主義体制では服装や髪型に至るまで統制され、会社としての価値創造力は失われていく。最良のイノベーションでも成果を出すには反抗的リーダーシップが必要。イノベーター自身が偉大なリーダーである必要はないが、誰かがその役回りを担う。勤務時間の分割はギアチェンジに要する時間も増え、結果集中を要する設計・開発作業の進捗が割を食うが、こうした問題は往々にしてエンジニアが自分の能力不足が原因と思ってしまう。全体を通してめちゃくちゃ斬新なことを言ってるわけではなく、ずれてはいないが多くは著者の経験則ベースで根拠や出典が少なく、いまいち刺さらなかった。
-
Posted by ブクログ
PMP資格更新に向けて読みました。
個人メモ用にですが、ざっくり要約すると下記の感じかと思いました。
・デスマーチプロジェクトは多種多様あるが、結局無理な納期やスケジュールのプロジェクト
・デスマーチプロジェクトに対する最も効果的な対処はトリアージする事
・もちろん状況によるが、新しいツールや手法を導入するより使い慣れたツールや手法をうまく活用する方が効果的
・デスマーチプロジェクトはどれだけ時代が進んでも無くならない
少しクセがある文章のため、所々流し読みした箇所もあります。読書の時間がとれず細切れに読んでいたため理解しきれていないと感じる箇所もままありました。できるのであればしっかりと時間を確保した上でまとめて読む方が向いている本かなと思います。
また時間がしっかり取れるタイミングでじっくりと理解しながら読みたいと思いました。
-
Posted by ブクログ
トリアージしよう。もっとも大切な要求、課題から手を付ける
【感想】
「デスマーチ」をキーワードにして、プロジェクトマネジメントのよもやま話をしていく本。主張は基本的なプロジェクトマネジメント原則と大差が無いかも。ソフトウェア開発プロジェクトの難しさを理解するために読むとよさそう。書き方はエッセイ的で、メッセージが掴みづらい。既にPMの知見が無いと、難しい。単純にシステム開発プロジェクトについて理解するなら、「システムを作らせる技術」の方が分かりやすい。各章ごとの「まとめ」を読んでから、本文を読んだ方が理解しやすい。勉強のために読むなら、読んだうえで自分で抽象化を試みた方が良さそう。
【本書を読みながら考えたこと、気になったこと】
問いを立てて読んだ方が良さそうな本。
■なぜ、デスマーチが起こってしまうのか
・正確に作業量を見積もることが難しい。見積もりより作業量が増えても、納期は後ろに伸びない
・時間的、資金的、人的な余裕がない。ソフトウェア開発プロジェクトはビジネスであり、より安く、早いサービスが求められる。市場競争の結果、コンペを勝ち取る際には、他社より少ない予算（人員）、より早いスケジュールでの計画実現を提示できたベンダーが、ソフトウェア開発プロジェクトを受託できる。結果的に、いつもギリギリの状態でプロジェクトはスタートする
・失敗が隠される。過去にソフトウェア開発プロジェクトでの失敗があっても、企業は体裁を守るために、できる限りその事実を隠そうとする
■デスマーチに巻き込まれたら、どうすればよいか
・トリアージする。優先順位をつけて、対応する。全ての問題に対応しなければ、何もかもうまくいかない、ということはない
●１章 はじめに
・デスマーチプロジェクトとは、プロジェクトのパラメータが50％以上超過している物
・通常であれ二人月かかるところを一人月でやろうとしている等
・デスマーチは、教育効果が大きい
・プロジェクトの作業量、難易度を正確に見積もるのが難しい。予想より多くの課題、作業が発生し、デスマーチとなる
●２章 政治
・ソフトウェア開発プロジェクトは、様々な立場の人の思惑に左右される
・顧客、プロジェクトマネージャー、出資者、顧客上層部等
●３章 交渉
・納期、人的リソースについて交渉しよう
・時には、PMとして、会社上層部に反旗し、プロジェクトメンバーを守ろう
・「見積もりが難しいのは、見積もりを現状と将来をベースにした最善の予測を」と解釈するため。これが、上層部においては、『厳守すべき値』に変わってしまう」
→見積もりは常に最悪を想定して行いたいな
●４章 デスマーチプロジェクトの人々
・残業時間が多すぎると、途中から生産性は低下し始める
・プロジェクトの成功には、優秀な人、チームとして機能すること、働きやすい職場環境が必要だ
●５章 デスマーチ・プロセス
・この本で一番大事な言葉「トリアージ」
・「80/20の法則」に従う。いくつかの項目は、永遠に実装されない。それを目指す。全てに手をつけていては、デスマーチプロジェクトは終えられない
・システムの要求項目は「must」「should 」「could」に分けよう。そそて、mustから手をつけよう
・要求管理をしよう
・そこそこ使えるソフトウェアができれば、それでいい
●６章 プロセスのダイナミックス
・もっとも生産性の高い人から辞めていく。好条件の求人など、いくらでも来る
・プロジェクト上で大切にする人や仕事の取り扱い方の考え方を、チームに共有しよう
●７章 クリティカルチェーンと制約条件の理論
・プロジェクトのボトルネック、クリティカルパスは確認して仕事を進めよう
●８章 時間の管理
・無駄なミーティングはするな
・利害関係者の意見が対立する → 承認が遅れることによって、スケジュールが遅れることを文書化して提示せよ
・緊急で重要度の高い仕事、緊急でないが重要な仕事をしよう。緊急だが重要でない仕事（電話応対）などに対応する機会を減らそう
●９章 進捗の管理と制御
・リスク、問題を整理し、管理し、評価し、対応方法を決めよう
・問題が多いデスマーチプロジェクトではなおさらだ。
・社内のプロジェクト後に、評価をしよう。同じ過ちは繰り返さないようにしよう
●１０章 デスマーチのためのツールと技術
・便利なツールは利用しよう。作業を標準化し、効率化しよう
●１１章 シュミレーションと「戦争ゲーム」
？メッセージが理解できなかった -
Posted by ブクログ
エンジニア、さらに言えばプログラマの働き方に対する本。プログラマはどう働くべきか、周囲は彼らを活用させるためにどうすればいいのかを説明している。
ものすごく簡単に言えば、互いにコミュニケーションが取れる状態をチーム内に構築する、周囲（マネージャなど）は彼らの邪魔になることはしない（邪魔になること:電話を掛けたり電話対応させたり集中力が途切れるようなこと）などが挙げられている。それと似たようなことが実例とともに繰り返し述べられているのがこの本の主な内容である。実際にはプログラマが成長する際の学習環境についてなども含まれている。
さて、そうするとプログラマが勝手気ままに周囲に対してふるまえるかのように読めてしまうが、そうではなくここでいうプログラマはそれぞれ第一線で活躍できるような技量を持った存在のことであり、ぴよぴよのプログラマが好き勝手に要求していいわけではない。そんなひよこが成長できるような学習環境も提供するのが環境の責務であると述べているのは先述の通りだが、どちらかというとやはり自身で作業・責務の最適な姿が見えるプロフェッショナルなプログラマを対象としている。
そしてそれは書末にある「自由電子」という語に集約される。よい軍隊のように前線で各個人が高い能力でもって判断・連携する組織的な活動というイメージがぴったりあう。 -
-
-
-
-
-
-
-
Posted by ブクログ
ネタバレ「デスマーチは常態」。うん。
お客さんから、いやむしろ経営者から、大げさに言うと半分の予算で！半分の人数で！半分の納期で！に「期待している」という言葉を添えて任される。
新しい技術、手法を取り入れてみる。誰もやったことない。つまりみんな新人と同じ。遅延する理由がたくさん。
だから圧倒的に時間が足りない。
勉強になったのは、Mustdo、shoulddo、coulddo＋20:80の法則からの気づき。あるシステムを構築するときに本当に必要で核となる機能は全体の20%。だから、アジャイルとかで徐々にお客にリリースしていけば、うまくいけば残りの80％を省略できるかもしれない。ま、ウォーターフォールでは無理ですな。
こういう手法で納期を守りつつ、お客さんの顔色（懐）を見ながら徐々に機能を縮小するのが、生き残るために必要なのかなって思いますた。 -
-
-
-
-