学習メモ：日経SYSTEMS 【2012年9月号】
日経SYSTEMS 【2012年9月号】
特集は、「プロジェクトの失った時間を取り戻せ」「IT現場のiPad活用術」「パッチ適用 7つの掟」
とりあえず気になったポイントだけ明記する。
(1) バッファーの活用
(2) メンバーの追加投入（クラッシング）
(3) 作業の並行化（ファストトラッキング）
(4) スケジュールの引き直し
(1) バッファーの活用
・バッファーを全ての工程で用意する事は難しい。
・バッファーを用意する工程をピックアップする。（A.タイムバッファー）
→要件定義の後、基本設計の後、システムテストの前後といった「合意形成」待ちで遅延が発生しそうな所を重点的に。
・B.タスクバッファー
→並行化可能な作業を敢えて直列に配置し、遅延発生時に平行化する事で挽回する。
・C.スコープバッファー
→継ぎの開発に回してよい機能をユーザと合意しておく。最悪の場合、ここから作業を中止し、遅延箇所にメンバーを配置する。
・D.リソースバッファー
→一人で担当出来る作業にもう一人割り当てておく、遅延発生時に一人を遅延箇所に配置する。
＜ドキュメンタリー＞
・スキーム：作業に期限を設けないという
→パーキンソンの法則と学生シンドロームにより、このスキームを適応。
パーキンソンの法則：人は与えられたリソースを全て使い尽くす。
学生シンドローム：期限が近づいてようやく人は動く。
→期限を設けない代わりに後何日で完了する見込みかを報告させ、
PMは作業完了率とバッファー消化率を日々トレースした。
＜活用例＞
・TOC（theory of constraints）
→基本的なコンセプトは、「生産工程の中にはボトルネックとなる工程があり、それが全体のスループット（生産量）を決定する。
最適生産のためには工程全体のスケジュールをボトルネック工程の能力に合わせる必要があり、
生産性向上のためにはボトルネック工程を重点的に改善すべきだ」というものである。
（＠IT情報マネジメント用語事典：http://www.atmarkit.co.jp/aig/04biz/toc.html）
→TOCでは、2種類のバッファーを活用する。「タイム」、「キャパシティ」
タイム：ここの作業に含まれるタイムバッファーをプロジェクトやフェーズの最後に集約する。
キャパシティ：全メンバーの作業量を能力ギリギリにするのではなく、能力の低いメンバーの作業量が少ないアンバランスな状態を認める。
→結論としてはいかにボトルネックを解消するかに着目したアプローチなので、そこを意識しておけば良い。
(2) メンバーの追加（クラッシング：Crashing）
→追加リソースの投入によって納期を短縮すること
（プロジェクトマネジメント用語｜トーマツイノベーション株式会社：http://www.ti.tohmatsu.co.jp/study/project/words/crashing.html）
→習熟期間を短くする「ガイド」中身
・「プロジェクトの概要」
→プロジェクトの全体像を把握する為の資料。プロジェクトの目的やスケジュール主要課題の認識と解決へのプロセスなどを示す。
・「ユーザ企業概要」
→業績、中期経営計画、主要製品情報といったユーザ企業に関する情報も整理
・「プロジェクトルール」
→勤務時間や勤怠連絡方法、服務規律、ネットワーク接続方法、会議室予約方法
トイレの位置、自動販売機、喫煙所といった快適に過ごすための情報も提供。
(3) 作業の並行化（ファストトラッキング）
→作業を同時並行で行うことにより納期を短縮すること
（プロジェクトマネジメント用語｜トーマツイノベーション株式会社：http://www.ti.tohmatsu.co.jp/study/project/words/fasttracking.html）
→作業の並行化は容易ではない。
→フェーズを跨った作業の並行化はリスクしかない。
→各フェーズの成果物が完成する前に次のフェーズに入れば、手戻りは必須。
→独立性の高いサブシステムや機能単位での平行化はリスクは低い。
→性能設計と運用設計といった互いに干渉し合わない非機能要件に関する開発作業もリスクは低い。
＜活用例＞
・五月雨の並行化
→１．結合テストが可能な単位で機能をまとめて、その範囲で並行化を実施する。
→なぜなら：一部の機能だけ作業が進んでも結合テストの段階でプログラムが揃わないと試験が出来ないから。
→２．共通機能や問題が起こりそうな機能を先行する。
→なぜなら：共通機能が先に完成していないとインタフェース仕様が分からず、他の機能の設計・開発がし難い。
→なぜなら：問題が起こりそうな機能を開発すると課題が洗い出され、後続作業のヒントが得られる。
→３．同じメンバーが１つのフェーズを一貫して担当する。
→なぜなら：一人の人が複数の機能に跨って基本設計を実施すれば整合性は取り易い。
→４．分割した機能間で同期・調整する作業を設ける。
→なぜなら：五月雨の並行化を実施すると、機能間で仕様や実装方式の不整合が発生するリスクが高まる。
＜設計から結合テストのフェーズを並行化＞
設計A→実装A→単体テストA→結合テストA
設計B→実装B→単体テストB→結合テストB
設計C→実装C→単体テストC→結合テストC→同期・調整
＜ベテランを活かす＞
・ベテランの作業こそ並行化すべきだ。
・ベテランの負荷を軽減させる為に、ベテランが実施する上級作業と非上級作業に分解し、
一般メンバーが実施出来る観点は消化する必要がある。
(4) スケジュールの引き直し
・スケジュールの遅延要因は下記が挙げられる。
→１．要件（仕様）が未確定な事による調整工数の増加
→２．開発環境の整備不良（パッケージや機材の調達遅延、ツールの整備不良、サーバ、クライアントPC不足）
→３．メンバー不足又はスキル不足
→４．ステークホルダー間のコミュニケーション不足による手戻り
→５．作業項目漏れによる追加作業の発生
→６．作業期間の見積りミス →意外に多い。
→なぜなら：ユーザから提示されたマスタスケジュールに対して按分したスケジュールを作成する場合があるから。
