糞システムにしないため、私ができること『はじめよう！ 要件定義』
「なぜ糞システムができあがるか？」の答えは、「一つ前の仕事をしている」に尽きる。 詳しくはリンク先を見てもらうとして、まとめるなら、自分の仕事のインプットが出来てないので、仕方なく前工程の仕事を代行しているうちに、リソースと気力がどんどん失われているからになる。これはプログラマに限らず、SEからPM、テスタや運用を入れても、当てはまる。「何をするのか」が決められない経営層が糞だから、あとはGIGOの法則（Garbage In, Garbage Out）に従う。 では、どうすればよいか？ 「“何をするのか”を決めてもらう」という回答だと、連中と同じ肥溜めに落ちている。なぜなら奴らの“目標”とは、「売上を○％ストレッチする」とか「新規市場を開拓する」といった、現状を裏返した願望にすぎないから。売上アップ／新規開拓のために、どこに注力して、何にリソースを使い、そのために必要な道具（システム）を“
PM（プロジェクトマネージャー）になったら絶対に読むべきおすすめの本6選【要約付き】 | 株式会社LIG(リグ)｜DX支援・システム開発・Web制作
こんにちは。安達です。今年も引き続き、張り切って行きたいと思います。 さて、突然ですがみなさんは「プロジェクトマネージャー」を目指してますか？ もちろん、ひと口にプロジェクトマネージャーと言ってもさまざまな方がいます。 大規模な業務システム構築のプロジェクトもあれば、ECサイトやWebサービス構築プロジェクトもあります。LSIのチップ制御ソフトウェア開発もあれば、スマートフォンのゲームアプリ開発もあります。 ただ、共通して必要とされるスキルが、「プロジェクトマネジメント」だということは、みなさんも意見が一致するのではないでしょうか。 しかしそうはいっても、プロジェクトマネージャーになってから独学でプロジェクトマネジメントをゼロから学ぶのはとても非効率です。もちろん会社でOJTをするなり、体系的なプロジェクトマネジメントのマニュアルがあるならば、さしあたっての問題はないでしょう。 でも、ある
「リーン」について : 「何を作るか」よりも「何を作らない」か - naoyaのはてなダイアリー
2013年に「リーン・スタートアップ」という書籍が出版されて、それからリーン (LEAN) という考え方に注目が集まるようになった。LEAN とは「無駄のない」とか「ぜいにくのない」とかそういう単語らしい。 書籍リーン・スタートアップには「スタートアップやその類が新しい事業を始めるときに普通にやってるとだいたい失敗するから、潜在顧客や顧客からのフィードバックをこまめに集めて軌道修正しながらゴールを見極めるやり方が良い」とか、雑にまとめるとそういうことが書いてる。 仮説を立ててフィードバックをもらって検証するということを短いイテレーションで繰り返す･･･というのを "フィードバックループ" と呼んでいて、それを細かくやる場合、製品を作り込んでからフィードバックをもらうのでは遅いし、例えばペーパープロトタイプをするとかそういう実験的なことで欲しいフィードバックが得られるならそれが一番いい ─
アート・オブ・アプリケーション パフォーマンステスト
世の中に存在するシステムは、多かれ少なかれパフォーマンス上の問題を抱えています。問題の解決には、パフォーマンステストを適切に実施し、ボトルネックを浮き彫りにすることが有効です。本書は、精度の高いパフォーマンステストを求める人のための技術書です。パフォーマンステストの論理的根拠、効果的なテスト構成要素など基礎的なことから、パフォーマンステストのプロセス、結果の解釈、またトランザクション例など発展的な内容まで、パフォーマンステストを包括的に解説します。ミッションクリティカルなソフトウェア開発者、テスター、プロジェクトマネージャ必読の一冊です。 訳者まえがき はじめに 1章 なぜパフォーマンステストをするのか？ 1.1 パフォーマンステストとはなにか：エンドユーザの視点 1.1.1 パフォーマンス計測 1.1.2 パフォーマンス標準 1.1.3 インターネット効果 1.2 劣悪なパフォーマンス：
Team Geek
複数のプログラマが関わる場合、優れたコードを書くだけではプロジェクトは成功しません。全員が最終目標に向かって協力することが重要であり、チームの協力はプロジェクト成功のカギとなります。本書は、Subversionをはじめ、たくさんのフリーソフトウェア開発に関わり、その後Googleでプログラマを経てリーダーを務めるようになった著者が、「エンジニアが他人とうまくやる」コツを紹介するものです。「チームを作る三本柱」や「チーム文化のつくり方」から「有害な人への対処法」までエンジニアの社会性について、楽しい逸話とともに解説します。 目次 推薦の言葉 日本語版まえがき ミッションステートメント 謝辞 はじめに 1章 天才プログラマの神話 1.1 コードを隠して 1.2 天才の神話 1.3 隠したらダメになる 1.4 チームがすべて 1.5 三本柱 1.6 実践 HR T 1.6.1 エゴをなくす 1.
ソフトウェアアーキテクトが知るべき97のこと
ビジネスとプログラム両方の知識と経験が求められるソフトウェアアーキテクト。本書は世界中で活躍するソフトウェアアーキテクトによる97本のエッセイを収録した書籍です。プロジェクトにおいてもっとも重要な事柄とは何か、顧客やチーム、またコーディングやスケジュールなどについて、経験豊かなアーキテクトが自らの体験を踏まえて解説します。ソフトウェアアーキテクトを勇気づけ、新たな気づきをもたらす一冊です。日本語版には、伊藤直也、江島健太郎、小野和俊、榊原彰、鈴木雄介、萩本順三、萩原正義、牧野友紀による11本の書下ろしを収録。 目次 監修者まえがき はじめに 01 システムの要件よりも履歴書の見栄えを優先させてはならない ニティン・ボーワンカー 02 本質的な複雑さは単純に、付随的な複雑さは取り除け ニール・フォード 03 最大の問題は、たぶん技術的なことではない マーク・ラム 04 まずコミュニケーション
プロジェクト・マネジャーが知るべき97のこと
プロジェクトの様々な局面で意思決定を迫られるプロジェクト・マネジャー。本書は世界中で活躍するプロジェクト・マネジャーによる97本のエッセイを収録した書籍です。ソフトウェア開発においてマネジャーに求められることは何か、人とチーム、さらにステークホルダーの管理、プロジェクトプロセスやプロジェクト要求、契約、国際化への対応と地理的に分散したチームの管理などについて、経験豊かなプロジェクト・マネジャーが自らの体験を踏まえて解説します。プロジェクト・マネジャーを勇気づけ、新たな気づきをもたらす一冊です。日本語版には、奥沢薫、神庭弘年、重木昭信、芝尾芳昭、冨永章、初田賢司、林衛による11本の書き下ろしを収録。 目次 監修者まえがき はじめに 01 できるだけ早期にユーザーを巻き込む バービー・デイビス（Barbee Davis） 02 モグラたたき開発を避けよう ベンカト・スブラマニアム（Venkat
【書評】『なぜ、システム開発は必ずモメるのか？ 49のトラブルから学ぶプロジェクト管理術』（細川義洋・著） - やまもといちろうBLOG（ブログ）
【書評】『なぜ、システム開発は必ずモメるのか？ 49のトラブルから学ぶプロジェクト管理術』（細川義洋・著） 読んでいて、実用書なのに涙が止まらない本に巡り会えたので謹んでお奨めさせていただきます。 その名も、『なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術』。何がヤバイって、いちいち掲載されている項目がヤバイ。いきなり「何度も要件を追加してくるユーザ」ですよ。まるで弊社の某顧客ではないですか。 大項目からして「設計」から「プログラミング」、「テスト」とか進む先々にびっしりと地雷が敷き詰められているんだろうなあと悪い汗をかかずにはいられない世界が広がり、最後にはお決まりの「契約」。いやー、読んでいてぞくぞくしますね。特に「仮発注書だけで作業に着手してしまったら？」とか、なんか見透かされているようですよ。まあ、業界的には往々にして起きがちなことを一般論として書い
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp： 目標を突破する 実践プロジェクトマネジメント: 岸良 裕司
Amazon.co.jp: 仕事を100倍楽しくするプロジェクト攻略本: 米光一成: 本
Amazon.co.jp： アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE): Scott Berkun, 村上 雅章: 本
BLOGOS サービス終了のお知らせ