ユーザ要件が決まっていないのに請負契約を結ぶのは請負側にとって非常に危険である。要件が決まっていないということは開発の範囲も決まっていないということである。開発規模の見積もりそのものができないし、見積もったとしてもいくら増えるのか見当もつ…

不確定要素の多い段階で設計書やプロトタイプを作らなければならないときがある。それを上司やユーザがレビューすると、必ずああだこうだと修正を言いつけられる。そういう状況で100%の力を出し切るのは愚の骨頂だ。こちらの思い違いで一からやり直しという…

プロジェクトに入って来た新しいメンバーに教えるべきことをマニュアル化しておこう。 就業時間 昼休み時間 昼食の場所 休憩時間 最終退出の仕方 残業申請の仕方 休日出勤申請の仕方 基本的なマナー 施設の使い方 席の場所 会議体 電話の使い方 連絡方法 月…

プロジェクトが進んでいるかどうかは予定していた成果物の完成度で判断すべきだ。進捗会議でメンバーから各自の作業状況を聞くのは当然だが、鵜呑みは禁物である。設計書やプログラムソース等の成果物を実際に見るまで信じてはならない。設計書はレビューで…

プロジェクトが佳境になると残業や休日出勤が増えてくる。睡眠時間が不足し、疲労が溜まる。そんな状態で良い仕事はできない。疲れていると物事を深く考えることができなくなり、間違いを犯しやすくなる。仕事の効率が悪くなるので、いくら忙しくても休ませ…

プロジェクトの真っ最中でも夏期休暇くらいは取らないとメンバーの士気が下がってしまう。ソフトウェア開発の業界では会社が休みの日程を指定する例は少なく、大抵は決まった日数の範囲で業務調整しながら休みを取らせるケースが多い。となると、プロジェク…

システム開発において成果物を管理することを構成管理という。成果物には設計書やプログラムソース等がある。成果物は常に最新で、かつ全体が整合性の取れた状態に維持されていなければならない。よって、成果物がいつ誰によって作成され、更新されたのかを…

仕様変更、仕様追加の依頼を受ける時は変更依頼書等の文書でやりとりすべきである。決して口頭でやりとりしてはならない。その依頼文書を受け取ったとしてもSEの判断で対応してはならない。然るべき会議で検討し、プロジェクトマネージャがどのように対応す…

設計というのは、答えがひとつだけとは限らないので、あれこれと悩み、時間がかかる作業である。しかし、設計方針を先に立てておけば、ある程度の枠組の中で設計することになるので、それほど悩まずに設計を進めることができる。プロジェクト全体で使う言葉…

システム開発を行う時は将来のことも考えてできる限り汎用性を持たせた構造設計をすべきである。そのシステム特有の機能を追加する前の状態を保存しておけば、別のシステムに流用できる。部品化しておけば、さらに用途は広がるだろう。実績のある資産を再利…

プロジェクトは生き物である。過去に成功したからといって、次に成功するとは限らない。ユーザが変わるとプロジェクトも変わる。ユーザが変わらなくても、要件やこちらの体制が変われば、同じことが言える。プロジェクトマネージャはプロジェクトマネジメン…

ユーザから要件定義が上がって来たら、ユーザの現場を見学させてもらおう。事前に質問や確認事項を整理しておき、見学の時に聞けるように準備しておくとよい。その理由は、 ユーザ業務の理解を深めるため。 ユーザ要件の背景を知るため。 ユーザが抱えている…

プロジェクトがめでたく終了したら、プロジェクトを評価しよう。 納期は守れたか。 品質は目標水準を達成したか。 期待していた性能が出ているか。 費用は予算以内に収められたか。 利益は出たか。 初頭に立てた目標を達成したか。 修得した技術は何か。 プ…

プロジェクトを始める前に目標を立てよう。それはプロジェクトチーム全体の目標であったり、各メンバーの目標であったりする。ユーザにも立ててもらおう。目標を立てれば、プロジェクトの向かう方向が明確になる。各々がプロジェクトを通して何を得るか、迷…

・無用な対決をしない。 ・戦わずして勝つことを考える。 ・交渉に有利な情報を集め、戦略を練る。 ・手のうちを見せない。 ・焦らない。余裕を持つ。 ・交渉の結果、利得は対等であること。 ・不利な交渉でも対等になるような条件を付ける。言いなりになら…

人に仕事を依頼するときは必ず期限を切る、もしくはいつまでにできるのかを自ら言わせる。それは相手がユーザであってもである。例えば、ユーザに資料を提供してもらわないと設計や開発が進まないというような状況がある。ユーザの資料提供が遅れると設計や…

何のために外注をするのか目的を明確にすること。 外注する目的は、要員不足の補充、ノウハウの吸収、コストの抑制、等がある。 外注するときは、コストが安くて質の良い協力会社を選ぶ。 外注の実績がない場合は、複数の協力会社から提案を受け、比較検討の…

日経コンピュータ7月11日号に「プロマネ残酷物語」という特集記事が載っていた。確かにプロマネはきつい割に報われない仕事である。若い技術者がプロマネになりたがらないというのは理解できる。人や組織はコンピュータのように思い通りに動いてくれない。そ…

システム開発を受託する場合、運用や保守での利益を見込んで安く受注することがある。他社との競争に勝つためにも赤字覚悟で取りにいくこともある。それでも出費はできるだけ抑えたい。利益を見込んだプロジェクトでも納期遅延や品質不良が原因で赤字になる…

品質低下事後対策について列挙してみた。 ・要件定義が大きく変わった場合、作業を中断し、全体の整合性を確認する。新しい要件が品質に大きく影響を与えるようであれば、今回のプロジェクトの範囲外にするよう交渉する。範囲内にするなら、納期変更や費用追…

品質低下予防策について列挙してみた。 ・要件定義が完了するまで作業を着手しない。 ・仕様変更や仕様追加が発生したら、全体の整合性への影響を調査し、品質が下がる程度をユーザに示す。 ・設計前に技術検証を行い、不確定要素を無くしておく。 ・システ…

品質低下の原因を列挙してみた。 ・要件定義が済んでいないのに設計を始めた。 ・仕様変更や仕様追加を繰り返し、システム全体の整合性が取れなくなった。 ・技術的裏付けがないことをやろうとした。 ・方式設計やインフラ設計、運用設計が不十分だった。 ・…

進捗遅延の事後対策について列挙してみた。 ・納期を調整する。 ・優先度の低い機能を削る、もしくは次期プロジェクトに延期する。 ・増員する。 ・残業、休日出勤を増やす(最低の対応)。 ・心身共にリフレッシュさせる。 ・要件が固まらないのであれば、中…

進捗遅延予防策について列挙してみた。 ・ユーザ要件が固まるまで作業を進めない。それが遅れる場合、納期調整と費用追加の交渉をする。 ・クリティカルパスを重点的に管理する。 ・情報を収集し、遅れの兆候を察知する。 ・進捗会議を定期的に行い、状況を…

進捗遅延の原因を列挙してみた。 ・要件が固まっていない。 ・見積もりが甘かった(過小評価していた)。 ・作業と人の割り当てが適切でなかった。 ・仕様変更による手戻りがあった。 ・仕様追加等で作業が増えた。 ・担当者が病気になったり、怪我をしたりし…

プロジェクト管理の専門用語に品質計画というのがある。品質を計画するとはどういうことなのだろうか？品質は良いに越したことはない。品質を上げるにはコストがかかる。ただし、予算には限度がある。よってどの部分にコストをかけて品質を上げるべきかよく…

システム開発や機器の購入をITベンダーに依頼するとき、RFP(Request For Proposal)という提案依頼書をだす。依頼したいものの概要や目的、範囲、条件、機能、数量、納期、納入場所、支払条件等を記述する。企業によっては提案の期限や様式まで指定することも…

プロジェクトでは事務局や資材調達のチームもなくてはならない存在である。彼/彼女ら裏方の働きがなければ、プロジェクトは前に進まない。進めても後が続かない。SEやプログラマが自分達の仕事に専念できるのも彼/彼女らのお陰である。プロジェクト管理者は…