プログラマの思索

「アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)」は、色んなPM本の中でもベスト3に入ると思っている。
全て目を通したけれど、全て理解できてない。
自分が理解できた文章を中心にメモ書き。

【1】私の一番好きな単語は「How」(どのように)です

「はじめに」の冒頭にこの文章がある。
僕はこのフレーズが好きだ。

IT技術者は、システム化がお仕事であって、コンサルタントでもないし、営業でもないし、経営者でもない。
きちんとした要件定義書があったとしても、それをシステム化するには、設計もプログラミングもサーバー運用技術も必要とする。
それらは、全て「どのように実現するか？」という問題そのもの。
プログラムに落とせない仕様は、Howが突き詰め切れていないだけ。

【2】スケジュールとは確率なり

「アジャイルな見積もりと計画づくり」にも同じフレーズがある。
スケジュールはコミットメントではない。
見積もりはコミットメントではない。
将来を見通した推測に過ぎない。
そう思えば、スケジュールを開発中に保守し続ける意味が腑に落ちる。

【3】優れた見積もりは優れた設計から生み出される

「アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)」には、エンジニアリングにおける優れた見積もりは、優れた情報と優れたエンジニアという二つが揃って初めて生み出されるのです、とも書かれている。

大規模プロジェクトが破綻しやすい理由は、膨大な仕様を、整合性の取れたサブシステムへ分割し切れていないのが殆どではないかと思う。
その根本原因には、モデリング力の不足があると思う。

【4】優れた意思決定が悪い結果をもたらしたとしても、その意思決定を行ったPMが非難されることのないように注意すべきだ

SW開発を一人ではなくチームで行う時、メンバーには役割と責任が明確にされている。
そのチームには、チームを一つの人格と思えるように、チームの代表となるリーダーが必ず存在する。
そのリーダーが優れた技術力や経験を持っていたとしても、その意思決定で失敗する時はある。

失敗よりも重要なことは、復元力があること。

「アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)」には、意思決定前における彼のロジックや思考プロセスがしっかりしていたのであれば、そのロジックと思考プロセスは意思決定後であっても変わらずしっかりしているはずです、とも書かれている。

リーダーには一貫性が重要なのだと思う。

【5】信頼を明確にする。説得は命令よりも強い。

チームが有機的に動くには、メンバーにチームにおける役割を明確にして、その行動を信頼すること。
特にSW開発では、信頼関係が重要だ。
その信頼関係は、その人の性格もあろうが、源泉はその人の技術力にある。
駄目なチームは、メンバー同士に信頼関係がない。
XPでは、ペアプロはメンバー同士の信頼関係を強固にする方向へ発展させる。

リーダーとなるべき人に最も要求される能力はアカウンタビリティ(説明責任)だと思う。
何故そんな作業指示を出すのか、何故彼にそんな役割を期待するのか、ロジカルに、そして彼が納得できるレベルまで説明する責任がある。
駄目なリーダーは、メールや口頭で指示を投げるだけで、信頼関係を基盤にしていない。

【6】ファシリテーション：ものごとを容易に、あるいはさらに容易にする行為のこと

こんな本で、ファシリテーションの定義が出てくるとは驚きだった。

「アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)」には、多くの意思決定が共有され、多くの作業が協調して行われるため、優れた関係を築くことなしにコミュニケーション量を増やしても意味がないのです、とも書かれている。
信頼関係を構築すること、そのインフラがあってコミュニケーションが活性化して、チームも開発プロセスも改善していく。

【7】リーダーはフィードバックプロセスを定義する

駄目なチーム、駄目なプロジェクトには、フィードバックプロセスがない。
同じ失敗を何度も繰り返し、成長が見られない。

プロジェクトファシリテーションが提唱する「ふりかえり」は強力なマネジメントツールだと思う。
ふりかえりによって、メンバーだけでなくチームも学習する。
要件漏れ、仕様漏れ、バグ修正、リリース作業漏れなどの失敗を糧にできる。

チケット駆動開発ならば、イテレーションで開発したモジュールリリース後に「ふりかえり」を行えば、メンバーから有用な意見が出てくるだろう。
アジャイル開発とふりかえりは相性がいいと思う。
理由は、イテレーション単位にリリースするリズムがあるから、ふりかえりをやろうという雰囲気が自然に出てくるから。

【8】優先順位は力なり。PMは優先順位付けマシンとなるべし。

マネジメントとは選択することだ、とどこかの本で読んだことがある。
SW開発のプロジェクトは、五月雨式の仕様変更ですぐに迷走してしまう。

チケット駆動開発で一番重要なスキルは、チケットの取捨選択だ。
わずか２～４週間のイテレーションに入れるチケットはどれか、をいつも考えなければ、すぐにチケットは溢れてしまう。
基本は、優先度の低いチケットは捨てる。
リリースできないシステムは動かないガラクタと同じで無意味。

【9】中盤の戦略～コーディングのパイプラインはバグ修正のパイプラインとなる

「中盤の戦略」「終盤の戦略」という章が僕は好きだ。
まさにプロジェクトマネジメントそのものだと思う。

新規開発中の場合、開発者とテスターがペアになって作業しているだろう。
それが結合テスト、システムテスト、と経てどんどん納期に近づくにつれて、バグも増えてくる。
また仕様変更もあるだろう。

プロジェクト後半の作業も、開発者とテスターが、バグ修正とバグ検証のパイプラインで対応できれば、チーム内の役割を殆ど変えることなく、進められる。

RedmineとTestLinkの両方を運用した場合、まさにバグ修正のパイプラインというワークフローがようやく分かった。

TestLinkのテストケースはテスターがこなす。
テスターは、バグが出たら、テストケースを失敗に更新して、Redmineチケットへバグ登録する。
開発者はRedmineチケットに基づいてバグを直し、解決ステータスにする。
テスターは、TestLink上でチケットの解決ステータスを確認して、再テストし、OKならば、RedmineチケットをCloseし、TestLinkのテストケースも成功へ更新する。

このワークフローに管理者が関わらないことに注意して欲しい。
最終的には、このワークフローを承認する作業は残っているが、管理者は、開発者とテスターが交互にバグ修正とバグ検証をやり取りしている様子を、TestLinkやRedmine上でリアルタイムにモニタリングできる。

【10】終盤の戦略～降下角度に気をつけろ

プロジェクト終盤では、残作業のボリュームと納期までの期間から、降下角度を見極める。
降下角度が急ならば、メンバーに負担をかけさせるため、チームは混乱しやすい。
チームが許容できる降下角度の最大値はやはりある。

「アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)」には、懸案事項はトリアージ、残作業はバグのマネジメントへ移行すべし、とも書かれている。

【11】マネジメントの行動はどれも政治的だ。つまり、マネジメントの行動は、何らかの方法で権力を再配分するか補強するかのいずれかだ。

SW開発も一つのビジネス。
そこには、容認しがたい政治というものも存在する。
SEは、調整と言う名の作業もある。

「アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)」には、政治とはある種の問題解決である、とも書かれている。
この言葉で何となく理解できたような気がした。

「アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)」には他にも良い話がたくさんある。
少しずつ理解していきたい。