Developers Summit 2009 (2/12)参加メモ（PMセクション中心）

デブサミ2009は初参加でしたが、今回2/12にPM（プロジェクトマネジメント）のセクションを中心にセッションに参加してきましたので、メモをアップしておきます。教科書的な話ではなく、スピーカの実経験に基づく実践的な話を聞くことができ、自分なりの気づきも多かったので有意義だったと思います。
(※2/14追記：各セッション番号）

【12-E-1】品質で失敗しない大規模システムの開発

大規模開発を成功させるために品質管理の側面を中心に事例を紹介。（大規模とは要因500名以上程度を想定）
品質は結果であって原因ではない。
大規模開発の難しさ、品質を｛作り込む｜積み上げる｜検証する｝ことに対するポイントと方策を述べる。
難しさについて
- (1)作り直しができない。後戻りしたくても影響範囲が大きくスケジュールに間に合わない。設計面だけでなく稼働面（作り直ししている間他のモジュールの担当者の稼働が空いてしまう）。環境面（サーバは後工程の試験環境に変更しておりユニット試験に使えるマシンがない）も問題。
- (2)要因の多さ。組織が多階層的になるため、プロジェクト方針や作業内容が細部まで伝わらない。自分の経験からの本音として、なにが欲しいかと問われたら自分と同じ考え方をしてくれるメンバが欲しかった。
品質を作り込む
- (A)各工程での確実な品質確保
  - (A1)工程定義と終了条件
    - 単に作業と成果物を決めるのではなく、段階的に詳細化されている設計仕様の構成を定義。その上で各工程でどこまで作成するかを定義する。
    - 工程の終了条件は次の工程の作業が開始できること。
    - テスト工程が定義が曖昧なことが多いためメンバのスキルに依存しやすい。機能、性能といった観点を分けて定義する。
    - 工程の期間は経験上2ヶ月以内が妥当。大規模開発は工程が長くなりがちで、その過程で少しずつ意識ずれが生じやすい。長い場合は途中に工程定義のずれを補正する機会を設ける。
  - (A2)設計規約
    - 設計規約で思想を統一する。サービスシーケンスで機能間の動作を規定し、その上でDB処理やエラー処理の範囲を決める。
    - よくある設計規約で「精神論」が書いてある。これはNG。規約は何のためにあるか。PMがこれだけは守って欲しいということがかかれているべき。
    - ノウハウや手順を書いただけの分厚い規約は誰も使ってくれない。作業を実施する時に誰がやっても同じ用にできるためのことを書く。
    - 大規模開発においては1人のスーパーSEより数百人のメンバが同じレベルの作業が行えることが重要である。
- (B)AP構成、組織構成の工夫
  - グループ間のミスが多い。グループの数が多いほどエラーが作られやすい。
  - 原因としてよくあるのは仕様の設計不十分、IF版管理の不徹底など。これを是正するだけでは不十分。
  - そもそもミスを発生させない組織構成にする。具体的にはコンポーネント間のインタフェースや依存性を極力押さえる構成とする。
  - そうやって設計したコンポーネント構成にあわせて組織を分割。なるべく一通でみられる範囲を1グループにするとよいが、量と業務のまとまりに注目する。
  - 横串統括組織を作りPMと開発グループの間に配置する。プロジェクト開始の時点から設置。人員は試験規模をふまえて配置。いきなり横串業務はできないので注意。
品質を積み上げる
- 早い段階で最小構成での検証を実施することで性能や方式の検証を行うようにする。
品質を検証する
- 適切なメトリクスを選択する。上流工程はDQ(頁)、下流工程はPG(Step)とすることが多いがこれを分母として採用することに疑問。
- 値のバラツキが多い。例えばStepは人によりコーディング量にバラツキがある。
- 解決方法として工程を通してFPによる測定を提案する。製造・単体試験(UT)はStepとFPを併用するのがよい。
品質管理部門の役割
- ルールや環境を作り導入・徹底する部門であり、バグ票を代行して起票したり品質分析を行う部門ではない。これらを行うのは開発グループである。品管部門は品質改善のためのアクションを一緒に考える。開発グループ間との信頼関係が必要。
- 効果的なアクションとして、次工程着手直後に出たバグや問い合わせに注目。前工程ですりぬけた問題がここで出ている場合がおおい。着手直後は実績をあげようと焦ってしまうがいそがば回れ。
- 水平展開は有効だがモグラたたき。すり抜けを発生させた根底原因をよくみてそこを改善する。
まとめ
- 成功とは、安定したシステムやサービスの提供→顧客のビジネスの成功→メンバの満足感→メンバの成長。
- 段取りをちゃんと定めた開発における成功体験はSEを大きく成長させる。

【12-E-4】「脱エクセル」を実現！統合プロジェクト管理パッケージ「SI Object Browser PM」を利用してIT企業も近代化しよう〜PMBOK管理エリアをすべてカバー。原価比例法、EVM法をWサポートしたプロジェクト管理

パッケージは敬遠する方も多いが、自分はパッケージはノウハウが集約されたものと考えている。パッケージを通じて勉強するのもアリでは。
自分自身ソフトウェアの開発やマネージメントに携わってきた結論としては、「統合システムでなければ現場のプロジェクト管理能力は向上しない」
PMBOKはプロセスを管理する。9つの管理エリアをパッケージで統合。
完成基準と進行基準を並行管理でき、進行基準は「原価比例法」と「EVM法」の両方に対応しており、２つの進行状態を比較しながら安全な進行基準適用が可能。
ERP開発の経験上でも統合するとデータの一元管理や連携といったメリットが大きい。
エクセルでの難しさ、共有されない。オレ流の蔓延
デモ
- PMBOKの5つのプロセス（立上・計画・実行・管理・終結）にタブがマッピング
- スコープ管理は成果物スコープ（何を作るか）、プロジェクトスコープ（どこまで作るか）
- スケジュール管理（ガントチャート）に自動的に反映される。回復工数なども見える化。
- 受注まではスコープベース（工程にどれくらいかかるか）、受注後はリソースベース（どのくらいかかったか）
パッケージ開発にあたり、気をつけたこと
- 現場に嫌がられる（手間が増えるなど）のは避けたい
- 上司が知りたい情報をすぐまとめられるように
本パッケージ導入により見える化が進むので、いままで適当にやってきたプロジェクトはその適当さの実体を数字で突きつけられることになるが、それにより頑張りが出るようになる。

【12-E-5】難易度の高い超短期開発のPM

NTTデータに入社してから20数年金融系のシステムを中心に多数プロジェクトに携わってきた。実践的ノウハウなどをお伝えしたい。
NTTデータのPMの制度として、経験・資格に応じて4段階（アソシエイト/シニア/エグゼクティブ/プリンシパル）スピーカはエグゼクティブである。
短期開発成功にむけたPMのチャレンジとなるポイントは5つ
- (1)タイム、(2)スコープ、(3)統合、(4)品質、(5)コミュニケーション
今回のスコープはSIerにて商用システムを新規構築するプロジェクトと想定する。500人月〜1000人月程度。
メソドロジはミッションクリティカルを想定すると、現実的にはウオータフォールをとらざるを得ない（アジャイルを適用しにくい）
過去経験したプロジェクト概要
- 電子マネーシステム、26000店以上
- システムグランドデザインから携わり、Felica・センタシステム・店舗・おさいふケータイなどほとんど並列で構築。
- 要件定義2006年11月〜1月、設計1〜2月、製造単体2〜3月、結合3〜4月。2007年春にカットオーバ。約半年。
なぜ短期開発が発生するか
- 後天的→何か失敗があった場合など。これは今回のセッションの対象外
- 先天的→最初から短い期間でやらないとイケないことがわかっているもの。顧客の戦略、レギュレーションなど回避できない要因。ここをマネージメント上の工夫で乗り切ることを今回のテーマとしている。
短期開発プロジェクトの難しさ
- 人を増やせばいいものではない、見切り発車必須、必然的な変更の発生。
基本的考え方..やらなくていいものを探す、生産性を向上させる、変化を前提とする。
- ウオータフォールとアジャイルを比較すると、ウオータフォールは変更に弱い。この弱点をアジャイルのいいとこ取りで変更に強くできるように。
(1)タイムマネジメント
- まずPMとして実行可能なスケジュールを組む。このスケジュールのクリティカルパス（特に自分でコントロールが難しい外部要素）がどう影響するかを考える。
- キックオフ時にはメンバ皆でこれなら出きるというものを共有しないとモチベーションにも影響する。
- 雁行線表→すべての工程が直列な状況はありえず、五月雨に次工程に合流する流れになる。工程のexit cliteria（終了条件）を明確化しておくことが重要。
- 計画は立てる。変更が必要となった時にクリティカルパスに影響しないか、なぜ変更しないといけないか、その原因を明確化し対策がとれるのであればある程度の変更は許容されるべきと考える。
- 朝会・夕会がきちんとできているチームはコミュニケーションがとれているためうまく進んでいることが多い。
(2)スコープマネージメント
- 要件定義そのものにそもそも手こずる。顧客との共通プロトコルが必要。
- 要件がきまらない場合、関連者との合議制をやめて「決められる」キーパーソンと「即決」する仕様検討会議を行うテクニックもある。
- SIerサイドからみれば顧客側はシステム部門の人がほとんど、実際はその先にいるユーザ部門との折衝が必要でユーザ部門の時間や調整がとれないケースが多い。こういう場合にも少々強引ではあるがキーパーソンとの直接のやりとりは有効
- 「絶対に決めないといけないもの」「後で変更してもしょうがないもの」をお互いにあわせておく。
- 発想を変えてスコープ自体を可変にするという考え方もある。これをリスクバッファとして持っておく。
(3)統合マネジメント
- Q（品質）C（コスト）D（納期）のうちDが最優先であることを顧客含め意識をあわせる。
- 迅速ない意志決定体制の仕組み作り。開発サイドの体制として、PMの上長を座長としたエグゼクティブ会議を必要に応じて開催。問題･リスクは隠さず報告。対策の即時立案･実行をトップがコミットする。このやり方が協力会社側へ安心感を与えられる。
- 現場の調整機としての「システム全体会議」（進捗会議ではない）も有効。進捗上の阻害要因と意志決定が必要な懸案を中心に議論し方針を決定。
(4)品質マネジメント
- 「いそがば回れ」。やらなくてよいものはやらなくてもいいが、ドキュメント・レビュー・テストはどれも省略できないと考える。
- 品質分析はテストのルーチンに組み込むことで問題の早期発見を行う。
- テストケースは次工程を先取りし、コーダとテスタをペアリングすることで期間短縮・牽制効果を出す。（ただしこの方法は少しお金がかかるかもしれない）
- 短期開発は品質を落とさずに変更を受け入れられるかにつきる。入り口はDQでPGやテストケースに確実にフィードバックさせる。ここは潤沢にリソースをつぎ込むべき。
- NTTデータでの取り組み、品質向上・生産性向上、期間短縮。ツールを入れることについて勉強が必要となるが、楽できる可能性があるならやってみるべき。
(5)コミュニケーションマネジメント
- 柔軟性をもち自立性の高いチームを作る。決められたことをきちんとこなす人大事だがそれだけでは短期開発では足りない。
- 一人一人のコミットメントを引き出す。考えさせる指導の仕方。
- PMのビジョンに共感してもらえること。共感してもらうためにどうすればよいかを考える。
- このプロジェクトが終わったときにどうなっていたいか、また今後どうなりたいかをベースにそうなってもらえるようなアサインを心がける。
- 短期開発は物理的に1カ所で行うべき。肉体的・精神的にもつらいため、オフィスを快適にすることに力を入れる。小さいことのようにみえるが、こういうことがモチベーションには非常に重要。
- 顧客と一緒にいるべきかどうかはケースバイケース。一概には言えない。
- チームは必然的に混成部隊となるためチームワークを短期的に作り上げる必要がある。
- チームワークを作り上げるためには話し合いが必要であるため、意図的にチーム間の分担を曖昧にしておくテクニックがある。これだとチーム間の分担を当事者同士で整理しないといけないためコミュニケーションを誘発できる。かえって混乱するというリスクはあるが、テクニックとしては頭に入れておくとよい。
- 自分達にとって楽になる視点で考えてもらう。
- 突撃命令型リーダは短期開発ではうまく行かない。バランス型。トップに立つものほど前のめりであること。