記事要約

プロジェクトは、正式に開始する以前に行う適合的な交渉がなければ始まる前から命運が尽きる。
プロジェクトを馬鹿げた空想ではなく現実のものとするのは、計画ではなく計画作業プロセス。
計画作業プロセスを実施するのに堪えない管理チームがいることこそが、リスク管理における最大のリスクである。

書籍情報

Amazonリンクで出典と代えさせていただきます。

記事を書いた意図

ワインバーグの本にはよく練習問題がありますが、ワークショップ形式でやることを想定
して作られています。できれば３人以上で実施することが好ましいです。

しかし現状ではワインバーグのマネジメントに関するワークショップは少ないため、
一人でやるしかありません。そこで仲間を探すためにこの記事を書いています。

同じくワークショップ形式で問題をやってみたいという方は、
ぜひ仲間に入れてください！

練習問題の本文は、改行を変更した箇所もありますが、文章は完全に引用しております。
※　問題解説は筆者の解釈です。本には書かれていません。

構成

章末の「練習問題」を解き、解説に本文の情報を入れて補足しています。
本の概要に関しては、記事の末尾に補足情報として載せています。

本章の練習問題

問題１

読者のプロジェクトのどの部分がありのままに報告されていないのかを知っているか？　読者の文化のどの部分が、読者あるいは従業員がそれを正直に報告するのを妨げているか？　このテーマについてプロジェクトの他のメンバーと議論するのを何が妨げているか？

自分の回答

現在の自分の所属するプロジェクトについて回答する。

ありのままに報告されていないのはスケジュールだ。
元請けが顧客に対して、終わってない案件を「終わった」と言ってしまった。

なぜ？

この案件は、運用自動化ツール作成案件ということで参画した。
自動化ツール作成案件、というのは間違っていないが、自身は少し勘違いをしていた。ソフトウェア開発として、きちんとした開発モデル（ウォーターフォール、工程管理、レビュー、など）に基づいているプロセスだと思っていた。

しかし実態は違った。
元請けはシステム運用部隊を主軸としており、この運用部隊のルーチンワークを利便化するために運用が作ったツールの数が多くなってきたので、元請けが運用部隊とは別に開発部隊を導入したのがこのプロジェクトの始まりだったのだ。
というわけで、ソフトウェア開発というよりも「便利ツール開発」という感覚が強い。要件定義も無ければ設計工程もレビューも、受け入れも、検収も無い。

だから、「終わった」と顧客に言ってもバレない。
本当の目的は運用を効率化することであるため、ツールができたかどうかを顧客は意識しない。顧客が出した運用スケジュールを元請けが守れさえすれば良いという考え方なのだ。

自身は元請けから更に3社仲介したSES契約でここに来ている。
他のチームメンバーも同じだ。だから帰属意識が弱い。
スケジュールが厳しいので目の前の作業に追われ、残業が続いて冷静な判断能力が無くなっている。
議論するよりも目の前の作業を終わらせることが重要だと思われている。議論など無意味だと思っている。自分は単なる作業員だ。そんな議論は余所でやってくれと。
スケジュールを絶対のものとして受け入れ、スケジュールが無茶苦茶だとすら思えないようになってしまっている。
これは中々の重傷である。

問題解説

この章では、恐怖の文化について考えるためのものなのかも知れない。

(p.347)

恐怖の文化は、良い要件プロセスに背く暗黙の共謀を生み出す。この問題はそのままでは経営層の変革なしには解決できない。

とあるように、暗黙の共謀というのが何なのかを言語化する。

問題２

この章の各原則やヒントが、製品開発プロジェクト同様、組織変革プロジェクトにもどのように応用できるか議論せよ。

自分の回答

「馴らし巡行」を行うことで、小規模な範囲で改善を実施し、それを徐々に範囲を大きくして実施する。

問題解説

議論はできないので、自分の考えを述べた。

馴らし巡行とは、短い期間でプロセスを一通りシミュレーションしてみることだ。
1日でも、1週間でもいいが、モックを使って一通り業務をしてみるだとか、
アジャイルでスプリントしてみるだとか、とにかく「一通り」経験することで、プロジェクト管理に必要な情報が一通りそろう。これを組織改善にも応用する。

問題３

管理者が部下に次のように言うことが組織内慣行であるとする。「わたしは君たちが自分で思っているよりも優秀なのを知っている；だからわたしは、君たちのスケジュールを短縮しコミットメントを増加させ、チャレンジで指導するためにその目標を拡張する」。このアプローチはどんな条件の下でその設定目標を達成するか？　どんな条件の下で、不信、でっちあげによる見積り、不正確な進捗報告への環境を生み出すか？

自分の回答

成功条件
失敗条件
- 管理者にカリスマ性がない
  - デスマ真っ最中の現場にコージーコーナーのシュークリームを持ってくる程度で、現場のメンバーを労えていると勘違いしているようなマネージャーでは話にならない。自身のクビを賭けて現場のスケジュールを改善しなければならない。
- インセンティブが大したことない
- 現場のエンジニアが、チャレンジする価値のある魅力的な仕事だと感じられない
- 管理者が親会社の部長で、逆らえない

問題解説

本章 p.348 に以下のようにある。

プロジェクト開始時の交渉を恐怖と威嚇の雰囲気のなかで行うとき、プロジェクト要員は万事に「同意」しながら同時に逃げ道を探すことになる。同じ力学（ダイナミックス）は、管理者が進捗状況を点検するために立ち寄るたびごとに繰り返される

おそらく管理者のほうでは威嚇するつもりは無くても、親会社の部長に現場の派遣作業員が逆らえる筈はないので、正直に「間に合いません」とは言えない。権力構造というのは結構、本人でも気づかないものだ。

補足）本の概要

ソフトウェア開発における品質と生産性向上のための環境をどう作るかについて書かれたもの。

全４巻のシリーズ構成となっており、この本は４巻目。

前３巻までで解説した管理ツールとしての考え方を用いて、
組織に健全なエンジニアリングマネジメント（本では工学管理と称していた）を将来にわたり継続できるようにするための方法を述べている。