ReadMe

　「ザ・ゴール」から「クリティカルチェーン」まで、「ゆとりの法則」から「熊とワルツを」まで、「知識創造企業」から「ナレッジ・イネーブリング」までをひっくるめて、私なりに、スループット会計と制約理論（TOC）というパラダムシフトから、デスマーチ、アジャイル開発手法、xUnit、または、ピープルウェアという考え方、プロジェクト管理という方法論に考えを広げていきたいと思います。ひょっとすると、という仮説から、ほぼ確実に効果的であろう実践的なものまで、ソフトウェア開発という業種に身を置く立場から、新鮮な情報を発信していきます。

Solution

道具箱の整理 update 2005/11/29: 2005年10月の1ヶ月間かけて書いたブログのまとめである。私自身が普段使っている道具（考え方）をまとめて記述している。プロジェクト運営をする際に何をベースにして考えるのか、逆に私が何を元にしてよい運営を考えていたのかを再考してみた記録。
デブサミ 2005レポート update 2005/11/29: 2005年2月に行われたデブサミだが、アップし忘れていた。レポートにしてはかなり長い感じになっているが、雰囲気を味わって頂くといいと思う。
受託開発の罠 update 2004/12/21: 下請け会社（協力会社）の視点から、最終顧客、SIer（発注元）を観察する。受託開発という開発形態の中で、三者の立場からどうしても悪いウォーターフォールに陥ってしまう点と、できることならば、現状を打開したいということで、SIer（発注元）に期待する点は何かを論じる。
リスクマネージメント（序） update 2004/03/15: 見積もり段階で、リスク項目を洗い出しスケジュールにフィードバックする仕組みを考える。
プロジェクトが完了する確率80%の位置を見定め、最頻点と最悪点を比較してリスクを見込む。
スタッフが選ぶプロジェクト update 2004/02/12: ソフトウェア業界では、プロジェクトマネージャ（PM）がスタッフを選別するという形式が多い。これは、プロジェクトの規模見積もり、金額見積もりをマネージャのみが行うというリスクを持っている。
思考実験的ではあるが、あらかじめプロジェクトの計画や目標を社内で公開して、スタッフを募集するという公募性を考えてみる。実際に、ソフトウェア以外では社内公募制を敷く会社もあるようで、あらかじめ公開しておくことは、複数の目があることによる安全性、スタッフのモチベーションアップに一役買っているのではないだろうか。
効率化を求めないためにデブサミ2003記念: デベロッパーズ・サミット 2003 のトム・デマルコ氏の講演を聴きに行って思った感想。
当時は、「ザ・ゴール」の日本語版が出版されたばかりで、ＴＯＣ理論とゆとりの法則は似たところがあるのではないか？と思っていたのだが、デマルコ氏に質問したところ、きっぱりと否定された。あれから１年経って考え続けてみると、「ＴＯＣ理論の求める効率は、個人の時間を食いつぶしている」という意見がわかるようになってきた。逆説的に「効率を求めない」とし、「ゆとり」を優先させている。
フラッグ管理 (レジュメ): 仕事は目標を持たなければ、単なる作業になってしまう。管理者からみれば、すべてのプログラマは「作業者」に見えてしまうときがある。つまりは、マシンのようにコードを書き、マシンのように試験をこなし、正確なコードを書ければそれでよい、という考え方に陥る。
プロジェクトは生き物で、その場その場に調節していかないとうまくいかない。管理者（マネージャやリーダ）が計画をスタッフに知らせず、状況を知らせず、「兵隊」であることを求めるのは完全な間違いである。
週40時間という見積もり（レジュメ）: 何故、私が「週40時間勤務」にこだわるのか？を図示したもの。一種、ＴＯＣ理論に陥っているところもあるが、週40時間という形で、ゆとりを持たせた形で仕事をしていけば、突発的なトラブルに対して、余裕の時間を潰すことで元の状態に戻すことができる。つまり、初期計画時に「ゆとり」を持たせるのが、プロジェクト成功のひとつの条件である。
ただし、この方法は、個人の余裕（モチベーションや未来への投資）を潰しているので、基本的にはよくない。プロジェクトが遅れそうになったら「再計画」を行うのが正しいフィードバックである。あくまで不確実性のための余裕時間と覚えておく必要がある。
スループット会計とソフトウェア開発工程の関係その１: 「スループット」という言葉にこだわったプロジェクト運営の仕方を論じる。在庫＝コードという形でデスマーチが起きる理由 - ３つの指標（結城浩氏）もあるが、ここでは、コードの欠陥＝不良品による作業のやり直しを減らす、という形で全体最適化を行おうという案である。
ピアレビューという形で、設計やコードレビューを詳細に行うという方法もあるので、あながち間違いではないと思う。
最近は品質向上のためにテスト手法に対する書籍も多いのだが、欠陥を作りこまなければ、テストによる障害発生が少なくなり、障害を修正する時間も減るのは事実だろう。単体／結合テストレベルと受け入れ検査レベルのテストとを区別するほうが正しい。
役割分担型プロジェクト運営: とある社内の大型デスマーチプロジェクトを助けようと作成したものなのだが、意図が通じず失敗に終わった。意図を汲み取ってくれる管理者／プロジェクトマネージャに送る。
それぞれの「責務」を明確にしないと、責任転嫁とボール落ちの連続になってしまう。現在においては、責務はきっちりとした役割分担よりも、インターフェースを含んだ緩やかな重なりを持たせて分担させるとうまくいくことが分かっている。
ここでは、役割分担が明確でないために、それぞれの嗜好（技術や管理）に陥ってしまうパターンを図示している。

MyBooks

　私(増田智明)の著作です。以降続々刊行、の予定。

	書名	著者名
	Visual Basic逆引き大全 500の極意Ver.6.0対応	池谷京子, 木村祐樹, 増田智明, プロジェクトA
	Visual C#.NET逆引き大全 500の極意	池谷京子, 増田智明
	Visual C#.NETではじめるWebプログラミング	増田智明
	C/C++実践プログラミングリファレンス	増田智明
	ひと目でわかるMS Visual C++.NETアプリケーション開発入門	増田智明

ReferenceBooks

　このWEBページ(MyMy-MyCompany)を創るためのネタ本。

	書名	著者（訳者）
	ワインバーグのシステム思考法ソフトウェア文化を創る〈1〉	G.M.ワインバーグ（大野徇郎）
	ワインバーグのシステム洞察法ソフトウェア文化を創る〈2〉	G.M.ワインバーグ（大野徇郎）
	ワインバーグのシステム行動法ソフトウェア文化を創る (3)	G.M.ワインバーグ（大野徇郎）
	ワインバーグのシステム変革法ソフトウェア文化を創る (4)	G.M.ワインバーグ（大野徇郎）
	スーパーエンジニアへの道―技術リーダーシップの人間学	G.M. ワインバーグ（木村泉）
	コンサルタントの秘密―技術アドバイスの人間学	G.M.ワインバーグ（木村泉）
	パタン・ランゲージ―環境設計の手引	クリストファー・アレグザンダー（平田翰那）
	職人学	小関智弘
	ナレッジ・イネーブリング―知識創造企業への五つの実践	ゲオルク・フォンクロー, 野中郁次郎, 一條和生
	熊とワルツを - リスクを愉しむプロジェクト管理	トム・デマルコ, ティモシー・リスター（伊豆原弓）
	知識創造企業	野中郁次郎, 竹内弘高, 梅本勝博
	ザ・ゴール ― 企業の究極の目的とは何か	エリヤフゴールドラット（三本木亮）
	ザ・ゴール 2 ― 思考プロセス	エリヤフゴールドラット（三本木亮）
	チェンジ・ザ・ルール！	エリヤフ・ゴールドラット（三本木亮）
	クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?	E・ゴールドラット（三本木亮）
	ピープルウエア第2版－ヤル気こそプロジェクト成功の鍵	トム・デマルコ, ティモシー・リスター（松原友夫, 山浦恒央）
	ゆとりの法則－誰も書かなかったプロジェクト管理の誤解	トム・デマルコ（伊豆原弓）
	XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法	ケントベック（長瀬嘉秀, 飯塚麻理香, 永田渉）
	人月の神話―狼人間を撃つ銀の弾はない	Jr.,フレデリック・P. ブルックス（滝沢徹, 富沢昇, 牧野祐子）
	アジャイルソフトウェア開発	アリスター・コーバーン（株式会社テクノロジックアート）
	アジャイルソフトウェア開発スクラム	ケンシュエイバー, マイクビードル, テクノロジックアート（長瀬嘉秀, 今野睦, スクラムエバンジェリストグループ）
	Software people―ソフトウェア開発を成功に導くための情報誌 (Vol.2)	Java Press WEB+DB Press編集部
	Software people―ソフトウェア開発を成功に導くための情報誌 (Vol.3)	Java Press WEB+DB Press編集部
	コンピュータは、むずかしすぎて使えない!	アランクーパー（山形浩生）
	デスマーチ―なぜソフトウエア・プロジェクトは混乱するのか	エドワード・ヨードン
	入門から応用へ行動科学の展開―人的資源の活用	ポールハーシィ, デューイ・E. ジョンソン, ケネス・H. ブランチャード（山本成二, 山本あづさ）

ReadMe

Solution

MyBooks

ReferenceBooks

Links