ITエンジニア向け情報館

プロジェクトマネジメント

スケジュールマネジメント（進捗管理）

タスクスケジュールに余裕を持たせる

勤務時間のすべてが、業務に費やされていることはない。
メールを書く時間、会議に出る時間など、与えられている業務以外の業務をこなす時間があるはずである。
他、突発的な作業が入ることも十分考えられる。

そのような事情もあるため、タスクのスケジュールは、余裕を持たせて組むのがよい。
たとえば1日8時間勤務であれば、「作業に携われるのは1日6時間」などと見積もったうえで、プロジェクトのタスクスケジューリングを行うのがよい。
また、この余裕が、スケジュール遅延時のバッファとしても役立てることができる。

進捗管理とは

計画通りに進んでいるかを確認
遅延を未然に防ぐ、最小限にとどめる
計画の妥当性を検証する
計画に無理があれば、再計画
遅延を取り戻すための対策を検討、実施する

スケジュールの実現性

最初からスケジュールの実現性が低いと、簡単に予定していたスケジュールから進捗が乖離してしまう。担当者も「最初からできるわけがない」と思うようになるため、スケジュールに沿って作業をしなくなり、目先のことをできるだけこなそうという作業管理になってしまう。

正確な進捗管理

タスクを細分化し、未完了(進捗0%)と完了(進捗100%)だけにする。進捗の状況が白黒はっきりするやり方。

進捗率を20%刻みで報告させる。それ以下の刻みで報告させると、作業が進んでいなくても1%や5%高めて進展しているように見せかけるようなことができてしまうため。

課題管理

課題管理表の書き方で注意する点。

課題に対する担当者は、複数にせず一人にする。
複数名にすると、担当者間で責任が不明確になることがあるため、避ける。
課題の対応期限は、必ず明確にする。
2月中、可能な限り早く、などの表現は用いない。
状況や対応策が不明になっている課題は、それらを早急に洗い出し、管理票に記入する。
リアルタイムな状況確認を実現する。
たとえば、定例会議の場でPMが課題を聞き出しているだけでは、リアルタイムな把握にはならない。
また、PMが聞いて回らないといけない状況では、やはりリアルタイムの把握は困難。
改善方法として、たとえば、ポータルやファイルサーバーで課題管理表を一元管理し、メンバーは随時記入するように習慣づけさせる。メンバーが自立的に課題の記入/閲覧/アクションを実施し、その結果が他のメンバーやPMにも随時理解できる状況を構築することが重要。

外部委託管理

自社の規約やルールを徹底する

品質とスケジュールの管理に関して、外部委託先と共通認識を確立すること。
外部委託先が管理ルールを確立していればそれを活用するのもよいが、確立されていないようなら自社の規約やルールを理解してもらい、順守してもらう。
自社の品質に対する考え方が外部委託先に浸透していないのであれば、自社が要求する品質レベルを達成することは困難である。

外部委託先の評価

今後より良いプロジェクト運営を検討するため、また相互の信頼関係を深めるため、外部委託先を評価する。
評価ポイントとしては、以下のものがある。

品質、コスト、スケジュールについて計画と実績を比較する
発生した問題の内容把握と解決時期、解決方法の適切性
契約と照らし合わせた運用の適切さ

変更管理

提示した書面・資料の内容を変更するなら、理由を説明すべき

今回は「発注者に提示した資料の内容を、受注者が変更するなら、その理由を説明する必要がある」という点について書きます。

システム開発の現場では、発注者と受注者がいます。
発注者と受注者が異なる会社であることもあれば、同じ社内にいる別の人という場合もあるでしょう。
この違いを問わず、システム開発を依頼する側と、請け負う側とでやり取りする書面についてのお話です。

システム開発の現場では、様々な資料・書面が交わされます。
発注書、見積書、要件定義書、設計書、などなど。

これから開発していくシステムの内容を決めたりしていくうえで、これらの書面のやり取りはとても重要な意味を持ちます。
ただ、一度相手方に渡した書面の内容を変更する場合もあるでしょう。しかし、だまって書き換えるのはNGです。変更の理由を相手に伝えて、納得してもらう必要があります。

例えば、記述の内容が間違っていた場合。
書き換えた本人は間違いを訂正したつもりだったかもしれません。
でも相手方は、何も連絡なく勝手に別の内容にすり替えられた、と悪い印象を持つかもしれません。

相手にとって有利になるような書き換えの場合も、問題になる場合があります。
例えば受注側が見積額をあとで下げたり、開発期間を短縮する、などの場合。
受注側がどうしても受注したくて、意図的に値段を下げる場合もあるでしょう。
でも相手方に予告なく金額を下げてしまうと、発注側に「金額を書き間違えているようだが、金額を間違える会社ってそもそも大丈夫か？」「金額が下がるのはありがたいが、最初の見積もりはぼったくり料金なのか？」などと思われる場合もあります。

具体的な例を挙げましたが、これに限った話ではありません。
書面の勝手な書き換えは、相手に不信感を与えてしまうことがありますから、やはり丁寧に変更内容を説明するべきだと思います。

固すぎる発想かもしれませんが、一度出した書面を書き換える場合は、契約書を書き換える場合と同じくらい丁寧な手続きを取ったほうがよい、という考えを持ってもよいと思います。

「発注者に提示した資料の内容を、受注者が変更するなら、その理由を説明する必要がある」と書きましたが、発注者と受注者を入れえた場合でも同じことが言えます。やはり資料の変更においては、黙ってやるべきではなくて、相手方に理由を説明する必要があると考えるべきでしょう。

プロジェクトマネジメント術

プロジェクトの開始時のポイント（キックオフミーティング）

プロジェクト開始時には、キックオフミーティングなどで、プロジェクトメンバー全員の意識合わせを行うことが重要です。
例えば、次のことを行うとよいです。

プロジェクトの目的、目標の共有
体制や各メンバーの役割分担の共有
プロジェクトの進め方やルールの共有

それにより、作業がすぐに開始できるよう体制を整えられます。
各メンバーがやらされ感を持つこともなくなり、前向きに自信を持って作業に取り掛ってくれるようになります。

また、プロジェクトの遅延を全員で防ぐための意識を持たせるため、以下のような活動も行うとよいです。

プロジェクトスケジュールの共有
開始時点で分かっている懸念事項や課題の確認

以上の観点を考慮し、円滑なプロジェクト進行のため、キックオフミーティングの時に以下のものを準備しておくとよいです。

プロジェクト計画書
目的、目標、マイルストーンを明確にする。
プロジェクト体制表・体制図
プロジェクト体制を確立し、誰が何を担当するかを明確にする。
プロジェクトに関するステークホルダーの確認する。
課題管理表、リスク管理表
問題点があれば、あらかじめメンバー同士で共有する。
予算計画書
プロジェクト開始後の収支計画、予算管理を行うために使う。

プロジェクトのコストオーバー

多くの原因は、計画段階でコストを過小に見積もったことによる。
コストオーバーの原因には次のような場合が見受けられる。

小型プロジェクトの感覚で、大型プロジェクトの見積もりを行った場合

大型プロジェクトは小型プロジェクトよりも開発生産性が低下してしまうためである。大型プロジェクトには、小型プロジェクトにはないさまざまな問題があり、そのノウハウも蓄積が必要であることを理解すべき。

リーダーやマネージャに指導力がない場合

チームメンバーをリードできないと、進捗が遅れたり、課題を解決できなかったりと、問題山積みになり、解決がおぼつかなくなる。

メンバーのスキルが十分に備わっていない場合

プロジェクトで必要となるスキルをしっかりリストアップし、要員の確保や教育をスムーズに行う。特殊な技能を必要とするプロジェクトであれば、その要員が確保できているかどうかが大きなポイントとなる。

設計が不十分な場合

業務設計が不十分だと、手戻りが多く発生し、無駄な工数を生みやすい。システムが見たり触れたりする段階になって、顧客が使い物にならないと感じるなどすれば、プロジェクトの大きな巻き戻しは避けられない。

「かもしれない」を意識するマネージメント

PMやステークホルダーの懸念に対して、「まあ何とかなるだろう」と考えるのではなく、「何かよくない結果を招くかもしれない」と考え、早期に対応をしておく。
結果として、リスクの早期発見、影響の低減につながる。

プロジェクト終了時の振り返り

プロジェクト終了時の注意点

プロジェクトの成功点と失敗点をメンバー間で共有する。
プロジェクトで得た知識と経験を、組織の財産に変える。
単なる褒め合い、自画自賛で終わらないように。

なあなあで終わることが多いのですが、しっかりとした「締め」をすることが大切。

振り返りで記録しておくべきこと

以下の内容を振り返ることで、暗黙知を形式知にする効果があります。

プロジェクトの実績

実際にかかった期間、工数、コストが、当初の計画と比べてどうだったかを記載します。このデータが、以後のプロジェクトでの見積り精度向上に貢献することになります。

プロジェクトを通した学んだこと

失敗を通して学んだことと、成功を通して学んだことを記載します。発生した問題に対して、どのように回避・対策を行ったかを記載します。

成果物リスト

計画時から変更があったものもすべて記載し、場合によっては中間生成物も記載しておきます。

プロジェクトの総評

システム開発の観点と、プロジェクト管理の観点で分けて評価します。
プロジェクト計画時に策定した評価項目について、評価を記載します。

今後の課題

今後類似のプロジェクトがあった場合に意識しておくべき点などを、まとめて記載しておきます。

品質マネジメント

品質の定義

PMBOKでの品質の定義は以下の通り。

指定された仕様に対する適合：プロジェクトはあらかじめ明示した仕様の成果物を製造しなければならない。
使用目的に合致した成果物の提供：提供する青果物やサービスは、顧客の真のニーズを満たすものでなければならない

デスマーチ

デスマーチの回避

参考：デスマーチを回避するのに大事な“3つのこと”

プロジェクトマネジメントで重要となってくる点として、「スコープの管理」「リスクを事前に把握する」「コミュニケーション管理」の3点を挙げた。
頻繁に実施することで工数は増えるが、仕様書の漏れやバグを早い段階で減らせるため、プロジェクト全体で見れば工数を削減でき、納期やコストを管理しやすくなるからだ。

デスマーチの発生原因

デスマーチは、技術やソフトウェア工学によって改善されるものではなく、よりよいプロジェクトマネジメントによって改善されるものです。
様々なソフトの見積もり技術により、開発期間や工数をかなり正確に予測することができるようになりました。しかし、そうして算出された期間や工数は、「競争が激しいから開発期間をもっと短くせよ」というような圧力により「改ざん」されてしまう。
結果、デスマーチになってしまう。

オフショア開発の心構え

オフショア開発のポイント

オフショア先での人月コストは安いが、生産性も60%程度と思っておいたほうがよい（これより低い生産性に落ちることも多々ある）
日本人と比較して、文化の違いや解釈の違いが生まれやすく、コミュニケーションや作業のロスが発生しやすい。
また、オフショア先のメンバーに対して教育を行う工数も必要となるためである。

日本からオフショア先に出す技術情報は、法律に基づく輸出手続きの対象となる。
いつ、だれから誰に、何を、どのような手段で、何の目的で情報を開示したかを、記録する必要がある。
この事務処理にも工数がかかる点に注意すること。

オフショア開発先の選定

オフショア開発先の選定にあたり、小規模なトライアル開発を実施したり、プロジェクト中の様々な出来事を想定した課題に対する回答をもらうのも有効な方法。
その評価にあたっては、以下のポイントをもとに評価するとよい。

品質管理
再発防止のために、バグの傾向分析と傾向ごとの対策を実施しようとしているか。
対策の効果に対する評価と改善策について実施しているか。
プロセス管理
再発防止のために、開発プロセスなどの見直しを行うか。
進捗管理
納期順守のための対応をどうとるのか
コスト
費用管理が妥当かどうか。

ブリッジSEに必要な要素

オフショア先との橋渡し役となるブリッジSEとして日本人を採用する場合、次の要素が重要である。

オフショア先の国に好意的である
オフショア開発に前向きである
プロジェクトマネジメントのリーダー経験がある

仕様作成上の注意点

オフショア先では、仕様書の行間を読んで解釈することを期待してはならない。
いわば完璧な仕様書を用意し、オフショア先に提示する必要がある。
言葉では誤解が生まれる余地があるため、図や表、数式、サンプルコードなども活用するとよい。
用語の意味をほぼ完全に統一したり、条件分岐がある場合には全パターンを網羅的に明記する、また異常系処理の使用も完璧に仕様書にまとめておくことも重要。

しかし最初から完璧な仕様書を作ることは難しい。
完全完璧な仕様を作ろうとすると、仕様策定の過程で通常以上に日本人が工数をかかることになり、オフショアによるコストダウンのメリットを享受できなくなることもある。
なので、ある1つの仕様だけ、見本として完璧な仕様を記述しておいて、オフショア先ではそれにならって作業をしてもらうという、オフショア先での水平展開も実施するとよい。

開発途中でも仕様書の変更は発生しうる、技術力がある人にもミスが発生するという想定のもとテストをしっかり行う、仕様書に書かれていないことは想像せず必ず確認する、といった点をオフショア先の社員にも理解してもらう。
仕様書の不備があれば真摯に完成させる態度で、オフショア先に接すれば、関係は悪化しない。

ただし、仕様書修正によって発生するオフショア側の工数は、別途請求される可能性がある。このような費用をあらかじめ見積もっておくことも重要である。
また、オフショア側が仕様変更を受け入れてくれたら、きちんと感謝の意を示すことが大切である。
これをしなかったために、オフショア先との関係が悪化する場合もある。

日本の常識が通じないケース

給与・報酬の妥当性

中国の場合、社員同士で給料の額を見せ合うことがよくある。同等の仕事をしているのに他人より低い給料だとわかると、その理由を求めて詰め寄ってくることもある。その理由を明確に答えられない場合、その社員はそれを理由として辞めてしまうこともある。

同じ仕事を続けたがらない

同じ仕事を同じオフショア先に繰り返し発注することで、次第に作業効率も上がり、コスト面でも費用対効果が上がってくる。
しかし、オフショア先の社員は、同じ仕事が続いてしまうと、それ以上の知識やスキルが向上しないと判断して仕事を辞めてしまう場合がある。
その対策として、オフショア先の社員同士で業務をローテーションさせたり、全く同じでなくても関連する他の業務も発注するなどの方法がある。

日本人から見れば勝手な行動のように見える点

勝手な機能追加をしたうえで、その費用を請求してくる（仕様書を超えたアイデアを考え発揮すると、評価される文化がある国もある）

オフショア先の都合で勝手にスケジュールを変更する（自分流のスタイルでいくつかの仕事を平行して遂行する、という考え方をもつ国もある）

言葉の意味の違い

「大丈夫」という言葉の意味する点は、国内外で違う。
日本での「大丈夫」は、ほぼ完ぺきです、100%のできあがりです、という意味でつかわれる。しかし外国人が使う場合は、ある一部分は理解した、明確に示された点においては問題ない、という意味であることもある。

「以上」「以下」「未満」「～から～まで」などの表現は、その数を含むのかどうかで解釈が分かれてしまうことがある。より正確に伝えるためにも、数式（ｘ>=３）などのように表現し、誤解が生まれないような表現にすることを心がけること。

以上を踏まえた対応法

事前に開発標準や業務ルールを策定し、定期的にチェックする。
もし守られていなければ、わかりやすく対応方法を指導する根気も大切である。

オフショア開発のマネジメントが思うようにいかず、仕事に対するモチベーションが下がってしまう場合もある。
オフショア開発のリスクを前もって理解し、プロジェクトメンバーや時にはプロジェクト外のバックアップ体制をとるのも有効である。

オフショア開発では、オフショア先とのコミュニケーション能力と、プロジェクトマネジメント能力がより要求される。その実践経験を事前に十分積んでおくことも重要である。

コスト見積もり

オフショア開発のコスト見積もりにおいては、下記のコスト（工数）も必要に応じて見積もるべきである。

ブリッジSEのコスト
オフショア先への出張費用
オフショア先の開発環境の構築・設置費用
オフショア先への教育に関する、作業コスト
法律に基づく輸出管理にかかるコスト
仕様書の整備、メンテナンス費用（オフショア先で作成したドキュメントを、日本側で再構成しなければならない場合もある）
日本側での品質管理にかかるコスト
オフショア先にわかりやすく説明するために必要な、資料やサンプルの作成に必要なコスト
オフショア開発をバックアップする組織にかかるコスト

見積もりのチェックポイント

開発規模見積もりのチェックポイント

要件を明確にしているか。
規模を測定する方法は明確になっているか。
RFP（提案依頼書）を入手しているか。
RFPの内容に過剰な期待はないか（確かな実現可能性があるか）
RFPに記載されている納期に実現性はあるか。
類似案件の規模に関するデータがあるか。
システム化する範囲は明確か。
画面イメージがわかるものを入手したか。
画面のおまかな種類と数は明確か。
帳票の大まかな種類と数は明確か。
バッチ処理の大まかな種類と数は明確か。
データベースの大まかなデータ項目と参照/更新の分類は明確か。
他システムとのインターフェースの種類と数は明確か。保守開発の場合、影響を受ける機能は明確か。
保守開発の場合、変更になるデータ項目は明確か。
作成するドキュメントの種類と数は明確か。
開発言語、プラットフォームは明確か。
利用するパッケージソフト、フレームワーク、ソフトウェア部品は明確か。
システムに要求されるレスポンスタイムは明確か。
システムに要求されるスループットは明確か。
システムに要求される可用性は明確か。
システムに要求されるセキュリティレベルは明確か。
処理すべきトランザクションの種類と量は明確か。
バックアップの方法は明確か。
見積もり結果の妥当性を評価する指標はあるか。
見積もり結果をレビューする方法と体制は明確か。

開発工数見積もりのチェックポイント

どの工数をどの技法で算出するかは明確か。
要件定義～テストなど、対象の工程は明確か。
各工程の作業内容を具体的にイメージできるか。
ウォーターフォール型、スパイラル型など、開発プロセスは明確か。
適用する製品、技術は明確か
開発方法と役割分担は明確か。
システムテストの方法と役割分担は明確か。
運用テストの方法と役割分担は明確か。
移行の方法と役割分担は明確か。
マニュアル作成の方法と役割分担は明確か。
レビューの方法と回数、参加人数は明確か。
品質保証の方法と体制は明確か。
マネジメントの体制と方法は明確か。
技術支援の方法と体制は明確か。
開発以外の付帯作業の工数は明確か。
開発用PCやネットワークなどの開発環境は明確か。
プロジェクトに参加するメンバーの候補は明確か。
参加するメンバーの経験、スキル、知識は明確か。
利用する製品や技術に関するスキルは十分か。
対象となる業種や業務のスキルや知識は十分か。
関連部門やステークホルダーの数や特徴は明確か。
プロジェクトへの利用部門の参加は十分に得られているか。
不明確な機能がある場合、検討する期間を用意できるか。
見積もり結果の妥当性を評価するための指標はあるか。
見積もり結果をレビューする方法や体制は明確か。

コスト見積もりのチェックポイント

職種別の人月単価は明確か。
工数別の人月単価は明確か。
スキル・レベル別の人月単価は明確か。
類似案件の人件費を把握したか。
工程別の大まかな職種別参画割合は明確か。
参加するメンバーの人数の職種や役割は明確か。
メンバーをアサインした際に、他のプロジェクトで要員不足が発生しないか。
類似案件の経費を把握したか。
PCやネットワーク機器、ソフトウェアにかかる費用は明確か。
ノート、プリンタ用紙などの事務用消耗品は明確か。
テスト環境、テストツールの費用は明確か。
拠点間の移動のための交通費、宿泊費の回数は明確か。
電話やネットワーク回線などの通信費は明確か。
類似案件の予備費を把握したか。
納期を順守するための予備の要員数と期間は明確か。
稼働直後にシステムを安定化させるための要員数と期間は明確か。
すでに発生している費用で、見積もりに組み込むものは必要か。
見積もり結果の妥当性を評価するための指標はあるか。
見積もり結果をレビューする方法や体制は明確か。

アジャイル開発

アジャイルとドキュメントの関係

欧米のアジャイル開発現場では、ドキュメントを全く作らない事例がある。
これは、ソースコードを読めばドキュメントの代わりになるようなコードを書ける、熟練したエンジニアが集まっている現場だからである。
一方で、管理の対象としてドキュメントの作成が必須の場合は、アジャイルといえどもドキュメントの作成は必要である。

PMO

「PMOの存在意義を見える化しよう！」という記事です。
http://www.atmarkit.co.jp/im/cpm/serial/pmo/01/01.html

PMOはどのくらいプロジェクトの成功に貢献したのか、といわれると、確かに説明が難しいですね。

納品に関するトラブルと、その対応方法

成果物の品質が確保できず、納品するに値しない状態の場合

納期やカットオーバー日程を延期する。改めて納期を再設定し、それに向けてプロジェクトマネジメントを継続する。

納品物の大部分の品質は確保できているが、一部に問題がある場合

当初の予定日にて、機能限定にてカットオーバーする。カットオーバーした部分飲みを納品し、残りはあとから納品するという、多段階納品で対応する。

システムはカットオーバーしたが、ドキュメントなどが間に合わないまたは品質が確保できず納品できない場合

ドキュメントなどは、後日納品する。システム機能を優先してカットオーバー日程に納品できると見込める場合は、ドキュメントなどの作成作業は後回しにすることも検討する。

PMには業務知識が重要

PMが業務知識を持っている場合とそうでない場合とで、プロジェクトの進み具合に大きく差が出ます。
業務知識がないと、要件定義で難航しやすく、またプロジェクトメンバーに要件の伝え漏れも発生しやすくなります。
業務知識をしっかり身に着ける姿勢が重要です。業務知識が足りないと思ったら、積極的に学ぶ姿勢がPMには欠かせません。