プロジェクト管理者の道具箱 トップページ
プロジェクト管理者の道具箱

Tips集

■交渉における考慮点

  1. 無用な対決をしない。
  2. 戦わずして勝つ事を考える。
  3. 交渉に有利な情報を集め、戦略を練る。
  4. 手のうちを見せない。
  5. 焦らない。余裕を持つ。
  6. 交渉の結果、利得は対等である事。
  7. 不利な交渉でも対等になるような条件を付ける。言いなりにならない。
  8. 最後まで諦めずに粘る。
  9. 勝ち過ぎてはいけない。恨みを買う。

■資産を残す

  1. システム開発を行う時は将来の事も考えてできる限り汎用性を持たせた構造設計にする。
  2. そのシステム特有の機能を追加する前の状態を保存し、別のシステムに流用できるようにしておく。
  3. 部品化する事により、全く異なったシステムの開発にも再利用できるようにしておく。
  4. 実績のある資産を再利用する事によって、生産効率は上がり、品質の良いシステムが低コストで構築できる。
  5. 開発言語等の道具類は世間一般に流通しているもので将来性のあるものに絞り込む事。

■証拠を残す

  1. システム開発では発注者と受注者の間で話し合われた事が後で変更になる事がよくある。大抵はどちらかが以前言った事を忘れてしまっている事に原因がある。このような事を避ける為にも議事録などの記録を取るべきである。
  2. 議事録を書くのは面倒な作業であるが、手戻りになるよりもずっと時間の節約になる。
  3. 議事録は、後でトラブルになった時に役立つので、自分の身を守る為にも証拠資料として残すべきである。
  4. 議事録は必ず印刷して相手の承認印をもらう事。
  5. 業務日誌や作業ログは、トラブルの経緯をまとめる時に役立つので、毎日書くよう習慣づけておく。

■チェックリスト

以下の作業においてチェックリストがあれば、作業漏れを減らす事が出来るので、予め用意しておくと良い。

  1. 見積項目
  2. 取引手続き
  3. 要件定義
  4. 作業工程と成果物
  5. 設計項目
  6. レビュー項目
  7. 環境設定
  8. テスト項目
  9. 移行作業
  10. 導入作業

■データセンターの活用

  1. 十分な災害対策や障害対策が必要である。
  2. マシン室の入退出管理等のセキュリティー対策が必要である。
  3. 24時間、365日無停止の運用が必要である。
  4. スキルの高い運用管理が必要である。
  5. 運用コストを下げたい。

■標準化する

  1. 設計する前に設計方針を先に立てておき、その枠組の中で設計できるようにする。
  2. プロジェクト全体で使う言葉を統一し、言葉の取り違えによる手戻りを防止する。
  3. プログラミングにおいてはコーディング規約やネーミング規約を作っておく事により、プログラムの可読性を良くし、品質や保守性を向上させる。
  4. プロジェクトの規模が大きくなればなるほど、メンバーが多くなればなるほど、標準化の重要性は高くなる。

見積の原則

  1. 要件定義ができていない場合はお断りする。要件定義作業支援の為に委任契約を結ぶのであれば、その支援期間の工数を見積もる。
  2. WBSを作り、どんなに小さな作業であっても、考えられる作業を漏れなく挙げ、それぞれの工数を算出する。
  3. 概要設計や基本設計の後で再見積をさせてもらう条件を見積書の中に記載しておく。
  4. 不確定要素が多ければ多いほど、多い目に工数を取り、その理由を理解してもらう。不確定要素が無くなれば、再見積によって工数が減る可能性がある事を説明する。
  5. 機能が実現可能かどうかわからない時は、スキルのある者が技術検証を行う必要がある為、その分の工数も取っておく。
  6. 見積結果をいろいろな立場の人達に検証してもらう。
  7. 高過ぎると思っても、出すのを躊躇ってはいけない。やましい事さえしていなければ、堂々と「かかるものはかかる」と言うべきだ。そこから交渉が始まる。高ければ、要件を減らしてもらおう。
  8. 営業戦略的に価格を下げるよう指示されたら、指示した人に責任を取ってもらう事。

■ユーザ要件が決まっていない時の契約

  1. ユーザ要件が決まっていないのに請負契約を結ぶのは請負側にとって非常に危険である。 要件が決まっていないという事は開発の範囲も決まっていないと言える。 開発規模の見積ができないし、見積もれたとしてもいくら増えるのか見当もつかない。
  2. そういう時は請負契約ではなく、委任契約を結ぶ。役務を提供し、かかった時間でお金を頂く。 期間を決めてユーザと共に要件を定義する。 場合によっては、設計工程まで委任契約にする事も検討する。
  3. 一方、委任契約にすると受注側に完成責任がない為、発注側にとっては不利な契約になる。
  4. 発注側は期待する成果を出させる為の工夫をしなければならない。 成果物を定義し、その完成責任を契約条項に入れておくと良い。 また、定期的に作業報告書を提出させたり、成果物をレビューしたりして、 進捗状況を確認する事により受注側を牽制する効果がある。
  5. 結果の見えにくい仕事をする事になるので、互いに信用のできる相手を選ぶべきである。


Page Views

Update Information: RSS 2.0 (XML)
システム企画
プロジェクト管理
システム開発
システム管理

プロフィール
当サイトについて
サイトマップ
更新履歴
今後の予定
掲示板
QRコード




Creative Commons LicenseLink Free


このページの先頭へ