プロジェクト管理

■内容

■プロジェクト

• プロジェクトとは、「目的・目標」があり，「期間」と「予算」が設定されており，時間とお金を効率的に使いながら意志決定をして目標を達成する業務単位」です。

• たとえば、引越しをするプロジェクトを考えます。

   引越しプロジェクト
       業者選択 
       公共機関への届け出 
       梱包作業 
       引越
       生活用品購入
       引越通知ハガキ作成 
  

• プロジェクトを構成する作業すべてをタスクと呼び，階層構造を持たせます。

■WBS

• プロジェクトを機能や構造などの一定の考え方に基づいて，階層的に分解し構造化したものです。

• WBS(ワーク・ブレークダウン・ストラクチャー， Work Breakdown Structure)の手法は，階層を用いて，大まかな作業の流れを描き，その作業をさらに細分化するというのが基本です。

• たとえば、上記「引越しプロジェクト」の「公共機関への届け出」をタスクに分けます。

   引越しプロジェクト
       業者選択 
       公共機関への届け出 
           電話局への移転手続き 
           ガスの移転手続き 
           電気の移転手続き 
           郵便局への移転届
           金融機関への住所変更 
           ...
       梱包作業 
       引越
       生活用品購入
       引越通知ハガキ作成 
  

■進捗管理

• 進捗管理の目的は，開発計画に基づく作業の進行状態を把握し，もし問題点があればタイムリーに把握し，処置することです．

• このため、つぎの 2 つを把握する必要があります。
  • 進捗率: プロジェクトが全体のどの程度の位置にいるのか
  • 完了予測: このまま進んで納期に間に合うのか、間に合わないとするとどの程度遅れているのか

• 複数の人間が参加するシステム開発プロジェクトでは，ひとりひとりの作業遅れが他の人に影響し，さらには全体の遅れにもつながっていきます．そのため，各工程(工程終了報告書)，月単位(月報)，週単位(週報)の3段階で進捗状況を報告するのが一般的です．

• プロジェクト・リーダーは，これらの報告を受けて適切な指示を出します．進捗管理はプロジェクトのひとりひとりが支えていることを忘れてはなりません．

■ガントチャート

• ガントチャートは，第１次世界大戦での複雑な兵たん調達諸業務間の段取り・調整の効率を高めるために生まれた管理手法です．

• ガントチャートは，スケジュール管理などでもっともよく使われる表現方法で，作業期間を横棒の長さで表現したグラフです．線表とかバーチャートとも呼ばれています．

• 一般にガントチャートとは横方向にカレンダーを持ち，棒グラフ形式でスケジュールの期間を表現します．

  

  図　ガントチャート

• 作成も簡単で，進捗状況を把握しやすく，しかも見やすいという利点があります．

• 欠点としては、つぎのような項目があります。
  • 仕事間の関係がつかみにくい
  • 管理の重点・問題点がはっきりしない
  • 書き直すのが大変
  • 中途変更や将来予測がむずかしい

■PERT 理論

• PERTとはProgram(Project) Evaluation And Review Techniqueの略称で，米国の軍事研究開発用に考案され，その後，製品の研究開発，ソフトウェア開発，システム導入プログラム，販売計画，工場の工程管理，マーケティング・プログラム，宣伝広告プログラムなど，米国を中心として様々な業種／業務で広く利用されるようになった汎用的な計画管理の手法です．

• PERTはガントチャートなどの棒グラフ形式でスケジュールを表現するバーチャート形式ではなく，ネットワーク方式のスケジュール管理手法です．

• PERTはネットワーク方式なので，ガントチャートと比べると個々の作業の進捗が見づらいという部分があり，そのため，PERTで組み立てられた計画をガントチャートで表わすことが多いです．

• また，手書きでPERT図を作成するには時間がかかるという欠点もあります．

• しかし，ネットワーク方式なので，仕事の相互関係と順序を明らかにしやすく，また進行中に遅れが発生したりした場合，その後の日程予測がしやすいという利点があります．

• PERT図には，アロー型（表示）とフロー型（表示）の2種類が代表的です．

  
  

  図　PERT図(アロー型)

• この図で，○印を“ノード”（Node），あるいは“イベント”（Event）と呼びます． 矢印が出るところが作業を開始する点であり，矢印の先が作業を終了する点であり，両方を兼ねている場合，前の作業が終了しないと次の作業が始まらないということになります．ネットワークが仕事のつながりを表す以上，ひとつの仕事の開始と終了を明らかにして，つぎの仕事がどこから始まるのかをはっきりさせなければなりません． 図の○印は，○で囲まれた数字でも表わします．（この場合は，先行ノード，後続ノードと呼ばれます）

• あるアクティビティが他のアクティビティの開始日に影響を与えるような場合に，ノード番号を管理することでその影響を反映させスケジュールを変更する為に用いられる番号です． アクティビティAが終了しないと，アクティビティCとアクティビティDが開始できないなどというときに，

      アクティビティA：先行ノード＝1／後続ノード＝2
      アクティビティC：先行ノード＝2／後続ノード＝4
      アクティビティD：先行ノード＝2／後続ノード＝5
  

  というふうに，「Aの後続ノード番号＝C・Dの先行ノード番号」にします．

  
  

  図　PERT図(アロー型)

• フロー型のPERT図は，フロー・ダイアグラムとかプレシーデンス型，サークル・ノーテイションとも呼ばれます．

• フロー型は，あまりアロー型と変わらないようですが，表現方法はまったく異なります．

• フロー型では，アクティビティ（タスク）自体を記号（丸印や箱型）で表わし，その記号の中にアクティビティ名が書込まれます（その中に所要日数や開始予定日を書込む場合もあります）．

• アロー型では矢印自体がアクティビティを表わしていましたが，フロー型では，矢印は他の作業との順序関係を表わしているだけで，時間的な意味を持ちません．したがって，ダミーという考え方もありません．このように作業を矢印ではなく記号で表現することで作業間の関係が判りやすくなっています．

• PERTが日本に紹介された当初はアロー型がほとんどでしたが，適応できる業種が増えて，パソコンで処理できるようになった現在，フロー型が一般的になっています．

■ゆとり時間とクリティカル・パス

• 下図の例で，タスクB-タスクFの作業ライン（太い線）は，所要日数の合計が8日となっており，A-C-(D1)-Eライン（5日）よりも3日分，A-D-Eライン（6日）よりも2日分，それぞれ多くかかることになっています．このB-Fラインで作業に遅れが出ると，その後に続くGというタスクの開始が遅れ，プロジェクト全体の遅れに繋がります．

• このように，あるタスクが遅れるとプロジェクト全体の進捗に支障をきたすような作業の流れをクリティカル・パスとよび，PERT図では太い線で表わされます．

  
  

  図　ゆとり時間とクリティカル・パス

• これに対し，クリティカル・パス以外の流れの中では作業に余裕があるものもでてきます．この余裕を表わすのが，ゆとり時間です．

• 上記のA-D-Eラインは，クリティカル・パスに対して2日のゆとり時間があります．

• また，A-C-(D1)-Eラインは，クリティカル・パスに対して2日のゆとり時間があり，さらにA-D-Eラインに対しても1日のゆとり時間があります．

• ゆとり時間の取り方には，最優先で作業を行い，ゆとり時間を作業の後にとる方法と，作業をスケジュールの遅れない範囲でぎりぎりまで着手しない方法があります．

• 納期が決まっていない場合にはゆとり時間を前にとりますが，納期が与えられていれば逆に最優先で着手するようにゆとり時間を後にとることが可能です．

• クリティカル・パスがどういう流れで，それに対してゆとりのあるアクティビティがどのくらいあって，どの手順を変更すれば無駄なゆとり時間をなくし，時間短縮を行えるかを検討することができるわけです．

■品質管理

• 情報システムの普及は，トラブルがおきると，社会生活に重大な影響を及ぼすことを意味します．システムの品質は，ただ単に誤りが少ない・壊れないというものだけではなく，いろいろな要素を含んでいます．しかし，システムの要素がソフトウェアである以上，基本は個々のプログラムの正確性です．

• ソフトウェアの品質を高めるため，プログラムのテスト段階では，見つけたエラーの累積数を管理します．開発工程が正しく管理されている場合，このエラー累積数は，図のような曲線を描き，テスト開始後時間がたつと，累積数が収束していきます．この曲線を信頼度成長曲線(バスタブ曲線)とよびます．

  
  

  図　信頼度成長曲線

• 品質で注意しなければならないのは後戻りコストです．つまり，下流工程にまで開発が進んでしまった後で発見された上流工程の誤りは，修正するのに大変な労力が必要です．

  
  図 ウォーターフォール・モデルとテスト

• 古い言葉ですが「品質は工程で作り込め」という言葉があります．各工程での確実な作業がよい品質を生みます．

■エラー拡大モデル

図　エラー拡大モデル(レビューなし)

---




図　エラー拡大モデル(レビューあり)

■レビュー

• レビューは，おもに設計審査(design review)に対応し，提案された設計を公式に審査し，設計上の問題を指摘する過程です．対象は設計だけでなくテストの妥当性を評価するレビューもあります．

• レビューの特徴はテストと比較し開発局面の前半で実施することができ，是正コストの面で優れています．

• レビューの目的はつぎのとおりです。
  • エラーの発見と修復にかかる全体費用の低減
  • プロジェクトの早い時点でのエラー発見
  • プロジェクトの知識についてのコミュニケーション

■レビューの方法

• ウォークスルー
  • レビュー対象の手続きに対して，いくつかのテスト・ケースを用意し，机上で手続きをシミュレートして妥当性を確認します．

• インスペクション
  • 目的を決め，資料を事前に配布し，モデレーター(責任者)のもとで一堂に会してレビューします．

• プロトタイピング
  • 目的とするソフトウェアに対して，画面の一部やサンプル・プログラムを用意し，実際に動かしてレビューします．

• ラウンドロビン
  • レビューに参加したメンバーが持ち回りで責任者を務めながら，全体としてレビューを進めます．

• シミュレーション
  • システムのシミュレーション・モデルを設定し，数学的近似値を用いて実際の動きを評価します．

■ウォークスルー

• ウォークスルーの目的はつぎのとおりです。
  • システムの品質向上
  • 新人プログラマーへの教育の場の提供
• ウォークスルーの特色はつぎのとおりです。
  • 少人数グループ
  • 開発担当者による参加者の選択
  • 参加者への事前資料の配布と事前検討
  • 短時間ミーティング
  • 管理者の不参加
  • エラー検出に焦点，解決策は事後に
  • 参加者の連帯責任

■ウォークスルーの実際

• してはいけない 4 つの行為
  • 管理者（マネージャー）を参加させてはいけない
    • 管理者は，レビューには役にたちません．まして，だれかが誤りを見つけたときには，マイナス査定をする可能性もあり，だれも発言できなくなります．
    
    
  • あらさがしをしてはいけない
    • 参加者は，明らかな誤りを見つけるのではなく，根本的な誤りを見つけるようにしなくてはなりません． 参加者は代案を出すだけにとどめます．最終的な選択権や決定権は発表者（その設計をした人，あるいはコードを書いた人）にあります．
    
    
  • 長時間続けてはいけない
    • ウォークスルーの時間は30分以内にします． 短い時間で，断片ではなく全体を追いかけることが肝要です．そのためには，必要な資料は事前に配布し，参加者はその資料をよく読んでおく必要があります．
    
    
  • すべてをやろうとしてはいけない
    • つぎのような点に絞ってウォークスルーを実施します．
      • 設計された全体の構造
      • 重要で困難な設計箇所
      • 複雑なロジックを実現しているコード

• ウォークスルーはつぎの 3 つの手順によります。
  • 事前準備
  • ウォークスルー
  • 事後処理

• 事前準備
  • 開発担当者が自分の成果物を作成した直後に，ウォークスルーを招集します．
  • ウォークスルーへの参加者は開発担当者が選びます．人数は2〜6人で，評価できる能力のある人にします．
  • 招集状は開発担当者が作成し，参加者にウォークスルーの少なくとも2日前に配布します．
  • 招集状に実際に検討する資料を添付します．参加者はウォークスルー前にそれを検討しておきます．
  • 管理者の参加は遠慮してもらいます．

• ウォークスルー
  • 参加者の中から進行係，書記をひとりずつ選びます．
  • 進行係は，時間の管理を行い，議論が個人的なものにならないように気を配ります．
  • 書記は，議論の結果出てきた問題点，エラー等を文書化します．
  • ウォークスルーの最初に，必要ならば，製品の概要を開発担当者が説明します．
  • テスト・データが用意されているときは，それに関する説明をデータ作成者がします．
  • ウォークスルーは，エラーを見つけることに集中します．エラーが見つかったときや，問題点が発生したときは，書記がそれを文書化します．
  • 小さなエラー（綴りミスなど）は議論の対象にせず，検討資料に赤字で指示し，ウォークスルーの終了時に開発担当者に渡します．

• 事後処理
  • 問題点記述用紙はコピーを取り，参加者に配布します．
  • 問題点に対する解決は，ウォークスルー後 2 日以内とし，簡単に文書化（問題点記述用紙）し，参加者に配布します．
  • ウォークスルーで重大な問題点が発生したときは，製品の作り直しの時間を与え，もう一度ウォークスルーをやり直します．
  • 問題点がすべて解決したとき，上記文書を参加者に回覧し，サインをもらった後，管理者に提出します．
  • 報告書には，エラーの数，誰が見つけたかなどは書きません．

■インスペクション

• インスペクションは，モデレーター(責任者)のもとに行うシステムの検討のことです．

• レビュー対象のエラーの発見を第一目的とし，モデレーターが会議を主催します．あらかじめ限定されている問題点を開発者4-5人を収集して短時間で検討するレビューです．

• すべての局面で適用できます．
• インスペクションの効果としてはつぎの項目があります。
  • プロジェクトの品質を定量的に把握
  • 正確性，反復性，制御性を導く公式
  • 局面化の完了基準の明確化
  • エラーの検出，解明，責任のメカニズム提供
  • 独立のモデレーターによる高品質な検証の保証
  • 履歴データにより将来のエラー発生を避ける

• インスぺクションとウォークスルーの違いはつぎのとおりです。

  比較項目	インスぺクション	ウォークスルー
  公式なモデレーターの訓練	YES	NO
  明確な参加者の役割	YES	NO
  主導者	モデレーター	作成者
  エラー発見用チェックリストの使用	YES	NO
  修正ミスを減少するためのフォローアップ	YES	NO
  詳細なエラー状況をプログラマーにフィードバックし，将来のエラーを少なくする	YES	付帯的に実施
  結果の分析により，インスぺクション効果を改善	YES	NO

■システム運用

• システム開発終了で情報処理技術者の仕事が終わったと考えるのは早計です．なぜなら，その後，利用者がシステムを利用するために，日常的にシステムを維持管理または改良する仕事があります．これをシステム運用といいます．

• 一般的に，システム運用は情報システム部門が行い，仕事内容はつぎのとおりです．
  • システムのオペレーション
  • システム機器の管理
  • データの管理
  • プログラムの管理
  • 運用要員の管理と育成
  • ネットワークの運用管理
  • 安全対策と機密の保護
  • システム・コストの管理
  • システムの維持・改良と保守

■保守

• 保守作業とは，簡単にいえばシステムの修正作業です．保守作業は一般につぎの3種類があります．

  • 修正保守作業
    利用者からの指摘でバグが発見された場合の修正作業のことで，優先度が最も高いので早急に対処する必要があります．システムが稼働した直後に発生する可能性が高いといわれています．

  • 変更保守作業
    外部環境の変化(税金計算方式の変更，年号の変更，金利の変更など)に対して行われます．

  • 改良保守作業
    利用者からの処理追加要求，操作性の向上要求，さらにはシステム機能の追加要求などに対処して行われます．一般に最も多くの労力を必要とします．

• 近年では，システムのライフ・サイクルの中に占める保守にかかる費用の割合いは，時間とともに増えるのが一般的で，40〜80%に達するといわれています．また，保守作業の内訳は約80%が変更・改良保守で，修正保守が約20%程度といわれています．このように保守作業は決して軽視してはならない重要な仕事です．

■補足

■チーム

• よいチームの特徴
  • 目的意識と帰属意識
  • 自立的問題解決
  • 適切な意思決定
  • 協調とよい競争
  • プロセスが明確
  • 学習と成長の優先

• わるいチームの特徴
  • 目的達成意欲がない
  • 問題の方針、無関心
  • コントロールされた意思決定
  • 攻撃と防御
  • プロセスが不明確（暗黙的）
  • 失敗回復の最優先

■セッション・ルール

• 相手の話を聞く
• 相手の立場を理解し、話を中断しない
• 集中して考える
• 簡潔に、適語表現する
• 一時点で一テーマを討議
• 論点を明確にし、自分で意思決定する
• 全員の合意を作る
• 対案がなければ賛成する

■参考 URL