プロマネ1年目の教科書 今の仕事と未来を変える 13のルール
新米プロジェクトマネージャが身につけておかなければならない様々なスキルを、ラノベ風のストーリー仕立てでわかりやすく解説したプロマネの入門書です。先行きが不透明な開発業界において、プロマネを経験することは、あなたにとって貴重なスキルを手に入れるチャンスになります。本書では、倒産間近の中堅システム開発会社を舞台に、プロマネ1年目の主人公が「怒り出すクライアント」「責任逃れのメンバー」「納期短縮」「逃げ出す外注」「突然の仕様変更」などのトラブルを乗り越え、一人前のプロマネに成長していく姿を描きながら、ベテランエンジニアも知っておきたい、プロジェクトを成功に導くためのポイントをあわせて解説しています。
【サポートはこちら】→https://www.shuwasystem.co.jp/support/7980html/4129.html
【サポートはこちら】→https://www.shuwasystem.co.jp/support/7980html/4129.html
【プロローグ】
プロジェクトDの破綻
第1章
1-1 プロジェクトの各工程で、プロマネのやるべきことを把握する
プロマネは、責任感の薄い中間管理職なのか？
開発プロセスの基本
主な開発手法
各工程でのプロマネの役割
ルール01
1-2 プロジェクトを黒字にする裏技を身につける
プロジェクトAがキックオフ！
プロマネは下をこき使い、上に強く文句を言えるのか？
ルール02
1-3 クライアントからの予算の引き出し方と、決済の流れを理解する
決まらない要件
隠れた問題を引きずり出す！
担当窓口との折衝
プロジェクトが成功しても、失敗してもキャリアに繋がる
プログラムの出来が悪くてもゼニカネは取れる？
ルール03
1-4 業務に良いインパクトを与えるシステムを納品する
SEが勝手に開発要件を変更する
SEと新人女性PGがもめる
プロマネとSE
メンバーのスキルや人間性を把握する
プロジェクトへの参加スケジュールを把握する
ルール04
コラム プロマネのキャリアプラン ?コンサルタント?
1-5 クライアントに「決めさせる」テクニック
カットオーバー後のトラブルへの対応
パフォーマンス対処会議
パフォーマンスの改善と現場の意向の違い
クライアントの業界の常識は「世間」の非常識
既存システムで問題のあった業務は新システムでも問題を起こす
無人でも処理を行う
ルール05
第2章
2-1 要件が決まらない時は、視点を変えて情報を集める
大きなプロジェクトを受注シタゾ
要件が固まらない
最凶の女性スタッフ
業務を改善する思考を持つ人と話を詰めよう
ヒアリングしきれない業務の詳細はシミュレーションで突き止めよう
既存システムのイレギュラー処理をどこまで吸収するか？
ルール06
2-2 爆弾を隠すユーザーたちを見つける
社内の常識は非常識
集団で責任逃れ
発言力の強い人の逃げ場を用意しておく
要求定義で爆弾を隠すユーザーたち
コアユーザーだけではわからない
システムとしてはイレギュラーでも定常の業務
ルール07
コラム プロマネのキャリアプラン ?コンサルタント?
2-3 予算のバッファを把握して、引き際を明示する
売上至上主義に踊らされる
神様、仏様、クレーマー様
経営者は、現場の細かい事情には無頓着
どこまでをリスクとして予算に含めるか？
どこまでならやり直しができるか？
本番テストの盲点
ルール08
2-4 イレギュラー処理のシステム化の判断は、業務の理解から始まる
追加プロジェクトを受ける
尽きない要望
すべてを否定する
クライアントの環境がどうすればもっと良くなるのかを考える
必要なトレーニングとマニュアル
今後増えるイレギュラー処理とその定例化
別システムによる別運用を切り出すタイミング
ルール09
コラム システムを短納期で納める ?便利な開発ツール
第3章
3-1 必要な情報を引き出すために駆け引きする
人員が足りない！
一人で巨大プロジェクトに立ち向かう
二次請けのリスク回避
プロマネの度量
プロマネは口が立たないとダメか？
プロマネは何もしないからこそ儲かる？
工数の算出の落とし穴
どこまでをリスクとして予算に含めるか？
ルール10
3-2 ディープな情報は取捨選択して使う
役者は揃ったゾ！
誰も業務要件がわからない
真のキーマン
クライアント先の「お客様」は意外と協力的
修正要件のルール
仕様の変更にどこまで耐えられる計画にするか
ルール11
コラム ソフトウェアの品質を高める ?バグ管理ツール
3-3 自分の常識でプランを決めつけない
納期を1ヵ月縮めろ
逃げる外注先
健次、告白されそうになる
ボトルネック回避のシナリオ
「慣らし」のシステム運用ができない場合の準備
クライアントの業務を優先しながら、システムの不具合に対応する
最も融通が利かないのは間接ユーザー
ルール12
3-4 想定しないことが起きることを想定する
HHTがない!!!
奇跡の出荷
誰が責任を取るのか？
それでも起きる、想定していない事態
責任がクライアントサイドと開発サイドとどちらにあったのかの切り分け
契約通りの費用が必ずしも請求できるとは限らない、値引きのポイント
ルール13
【エンディング】
圭華、アメリカに発つ
プロジェクトDの破綻
第1章
1-1 プロジェクトの各工程で、プロマネのやるべきことを把握する
プロマネは、責任感の薄い中間管理職なのか？
開発プロセスの基本
主な開発手法
各工程でのプロマネの役割
ルール01
1-2 プロジェクトを黒字にする裏技を身につける
プロジェクトAがキックオフ！
プロマネは下をこき使い、上に強く文句を言えるのか？
ルール02
1-3 クライアントからの予算の引き出し方と、決済の流れを理解する
決まらない要件
隠れた問題を引きずり出す！
担当窓口との折衝
プロジェクトが成功しても、失敗してもキャリアに繋がる
プログラムの出来が悪くてもゼニカネは取れる？
ルール03
1-4 業務に良いインパクトを与えるシステムを納品する
SEが勝手に開発要件を変更する
SEと新人女性PGがもめる
プロマネとSE
メンバーのスキルや人間性を把握する
プロジェクトへの参加スケジュールを把握する
ルール04
コラム プロマネのキャリアプラン ?コンサルタント?
1-5 クライアントに「決めさせる」テクニック
カットオーバー後のトラブルへの対応
パフォーマンス対処会議
パフォーマンスの改善と現場の意向の違い
クライアントの業界の常識は「世間」の非常識
既存システムで問題のあった業務は新システムでも問題を起こす
無人でも処理を行う
ルール05
第2章
2-1 要件が決まらない時は、視点を変えて情報を集める
大きなプロジェクトを受注シタゾ
要件が固まらない
最凶の女性スタッフ
業務を改善する思考を持つ人と話を詰めよう
ヒアリングしきれない業務の詳細はシミュレーションで突き止めよう
既存システムのイレギュラー処理をどこまで吸収するか？
ルール06
2-2 爆弾を隠すユーザーたちを見つける
社内の常識は非常識
集団で責任逃れ
発言力の強い人の逃げ場を用意しておく
要求定義で爆弾を隠すユーザーたち
コアユーザーだけではわからない
システムとしてはイレギュラーでも定常の業務
ルール07
コラム プロマネのキャリアプラン ?コンサルタント?
2-3 予算のバッファを把握して、引き際を明示する
売上至上主義に踊らされる
神様、仏様、クレーマー様
経営者は、現場の細かい事情には無頓着
どこまでをリスクとして予算に含めるか？
どこまでならやり直しができるか？
本番テストの盲点
ルール08
2-4 イレギュラー処理のシステム化の判断は、業務の理解から始まる
追加プロジェクトを受ける
尽きない要望
すべてを否定する
クライアントの環境がどうすればもっと良くなるのかを考える
必要なトレーニングとマニュアル
今後増えるイレギュラー処理とその定例化
別システムによる別運用を切り出すタイミング
ルール09
コラム システムを短納期で納める ?便利な開発ツール
第3章
3-1 必要な情報を引き出すために駆け引きする
人員が足りない！
一人で巨大プロジェクトに立ち向かう
二次請けのリスク回避
プロマネの度量
プロマネは口が立たないとダメか？
プロマネは何もしないからこそ儲かる？
工数の算出の落とし穴
どこまでをリスクとして予算に含めるか？
ルール10
3-2 ディープな情報は取捨選択して使う
役者は揃ったゾ！
誰も業務要件がわからない
真のキーマン
クライアント先の「お客様」は意外と協力的
修正要件のルール
仕様の変更にどこまで耐えられる計画にするか
ルール11
コラム ソフトウェアの品質を高める ?バグ管理ツール
3-3 自分の常識でプランを決めつけない
納期を1ヵ月縮めろ
逃げる外注先
健次、告白されそうになる
ボトルネック回避のシナリオ
「慣らし」のシステム運用ができない場合の準備
クライアントの業務を優先しながら、システムの不具合に対応する
最も融通が利かないのは間接ユーザー
ルール12
3-4 想定しないことが起きることを想定する
HHTがない!!!
奇跡の出荷
誰が責任を取るのか？
それでも起きる、想定していない事態
責任がクライアントサイドと開発サイドとどちらにあったのかの切り分け
契約通りの費用が必ずしも請求できるとは限らない、値引きのポイント
ルール13
【エンディング】
圭華、アメリカに発つ
