- 第1章 プロジェクトが失敗する時
- 第2章 プロジェクト体制
- 第3章 仕様調整上の基本ポイント
- 第4章 仕様調整上のフェーズ毎ポイント
- 第5章 仕様調整以外の重要ポイント
- 第6章 プロジェクトの人的要素
- 第7章 人間性の考慮
第1章 プロジェクトが失敗する時
テーマ１ 業務系システムの特徴
テーマ２ 失敗プロジェクトの特徴
- プロジェクトリーダーが不適格
- 協力ベンダとの協調関係がうまくいっていない
- チーム間連携がうまくいっていない
- 仕様調整でのトラブル
- データ移行やシステム切替でのトラブル
ベテランSEの目（１）
-
お客様は「業務用語」、ベンダは「システム用語」を使って話すため、勘違いが発生する。
- → 用語定義集を必ず作る。
第2章 プロジェクト体制
テーマ３ プロジェクトリーダ
-
プロジェクトリーダの最も重要な役割のひとつ
→ 共通認識の醸成- プロジェクトの進め方や、進行上のポイントおよびリスク をメンバに十分に理解させる。
- ↑ プロジェクト期間中、継続して行うべき。
-
日頃、自分が主張している行動指針などを自分自身が実行できるかが、
自分の指示通りにメンバを動かせるかどうかの決め手となる。
- 自ら見本を示す → 信頼度UP → 指導効果UP
- 見本を示さない → 信頼度DOWN → 指導効果DOWN
- 下から上への報告 ←問題が大きくなってからでないと上がってこない。
- プロジェクトリーダは、自ら積極的に情報収集しなければならない。
- 情報収集は、いろいろな側面・人々から行う。同じ事象でも、捉える人によって感じ方が違うから。
- メンバ個々人のパフォーマンスや稼働状況を把握しながら、プロジェクトチーム全体で、求められる稼働を満たすよう調整していく。
- 全体の予算を意識しながら、稼働調整しなければならない。
- 上級技術者を引っ張ってこれる政治力が必要。
- 間違いや勘違いは必ずあるものだと認識する。
- 考えられうる失敗のイメージを洗い出しておく。
- 予め失敗のイメージをいろいろと考えておくと、その事前予防策や事後対応策を用意することができ、 実際のトラブルを防止もしくは最小限に抑えることができる。
- プロジェクトリーダは、 普段はなるべく良い人を意識的に演じるか、 カリスマ的存在になるよう努力しなければならない。
- そういう人でなければ、メンバは精神論を受け付けない。
テーマ４ プロジェクトメンバ
- メンバに必要な心構え： 課題や問題に関しても自発的に行動する。
- 問題があることが問題なのではなく、問題を解決しようとしないことが問題。
- 各メンバの役割はプロジェクト開始時には明確になっているが、 プロジェクトが進んでいくに従って、必ず役割として漏れている部分がでてくる。
-
些細な漏れは、メンバ間で柔軟に対応する必要がある。（リーダーによる役割見直しではなく）
- メンバは、常日頃から明示的に与えられた役割だけでなく、全体を見ておき、漏れを発見できるように心掛ける。
- 自分の責任は、他の人に仕事を依頼した時点で終わるのでなく、依頼した仕事が完結する時点まである。
テーマ５ ベンダ（外注先，アライアンス先）
-
プロジェクトメンバ全員が同じルール・同じ気持ちで行動できる方が、体制としては強い。
異なる部門、異なる企業間であっても、同じように行動できるよう心掛ける。
- ベンダ選定： ベンダに支払うことができる費用に予め基準を設けておく。 基準があることで、色々な要素を比較して検討することができるようになる。
- 実績が合っても、そのベンダがどの位置付けで入っていたかで話は大きく変わる。
-
求められる能力・期間・体制・役割分担などを正確に伝えておく。
これら条件に関する意識統一ができていないと、ベンダとの間でトラブルに。 - ベンダ担当者やベンダ幹部との日頃の情報交換は大切。
-
自分自身の経験が述べられなければ、その人は、頭は切れるが経験は浅い自分物である可能性が高い。
理論だけでなく具体的な話ができる人材を。
「昔同じような案件をやりましたが、その時はこうでしたね。今回は、通常の場合と違って、ここが課題となるでしょう。」
テーマ６ お客様
-
お客様自身の作業、またはお客様の協力が必要な作業
……これらがボトルネックになることも。- システム化方針検討
- 現場業務ヒアリング
- データ移行
- 運用試験
- ユーザトレーニング
ベテランSEの目（２）
- プロジェクト・マネジャーは、タイムリーに決断することが肝要。
-
間違っていても大きくかけ離れるているケースは、まれ。
指示が遅れたことによる損失のほうが大きいことも。
先手必勝！。
熟考している間にも、問題はどんどん大きくなるし、交渉相手からさらなる要求が出てくる。
|
プロジェクト・マネジャーの心得 （プロジェクト成否の鍵は、プロジェクト・マネジャーの振る舞いにある） |
|---|
| 責任をとること |
| 他人のせいにしないこと |
| 決断すること |
| 人・物・金・情報を握っていること |
| 自信をもつこと |
| 動じないこと |
| 相手の立場がわかること |
| 余裕があること |
| 現場を見ること |
| 弱音を吐かないこと |
| 孤独である |
| 遣り甲斐のある仕事である |
- 担当者の報告だけで、判断を下してはいけない。担当者は自分の範囲しか見えていない。
|
＜決断のよりどころ＝自信＞ 自信はどこから生まれてくるか |
|---|
| KKD（経験・勘・度胸） |
| 技術力 |
| 人間好き 豊富な人脈 |
| 迫力 人を納得させられる |
| 自力で解決できる |
| 現場を良く知っている |
| 重み付け 優先順位 取捨選択 |
| 自分の言葉で言える |
第3章 仕様調整上の基本ポイント
テーマ７ 実現可能性の担保
- 仕様の「幹」の部分に関してイメージを確立する。
- パッケージシステムなら、システム思想を把握する。
テーマ８ 仕様漏れの防止
- 必要な仕様は、フローを追いかけることで確認する。
- それ単体で存在しているのではなく、一連の企業活動の中に組み入れられている。
- データの発生から消滅までがスムーズに流れているかを確認する。
- INPUTを洗い出すことで、漏れていた業務を洗い出すことができる。
- 業務改革と言っても、ほとんどの仕様は現行の焼き直しとなる。
- 類似する企業の業務フローを参考にする。
テーマ９ 仕様の収束
- お客様とプロジェクトメンバ双方に、「仕様」＝「費用」の認識を定着させる。
- 「仕様によって開発費用が変わる」という認識。
- プロジェクト開始時に、さらに開始後も、仕様によって開発費用が変わるということを理解してもらう努力をする。
-
それぞれ費用の付いた選択肢を提示し、お客様に選んでもらう。←極めて有効的な方法
- 開発者が色々と検討した過程を感じることができるとともに、 お客様自身が選択したという事実が開発者への不信感を払拭してくれる。
-
要求仕様に優先順位を付ける。
- お客様は感覚で話をすることが多い。
- お客様が客観的に判断できるよう、具体的数値や具体的ケースを持ち出して話をする。
-
取捨選択の基準
- 重要性
- 頻度
- 実施者
- 影響範囲
- 許容作業時間
- 代替案の可能性
-
安易に仕様変更を受け付けない。
- 自分にとって一見簡単そうに見えても、全体から見た仕様や開発期間を再度確認する。
テーマ10 サーバのパフォーマンス
- サーバーのパフォーマンスの判定材料：最大処理能力とディスク容量
- よくある失敗例：例外処理やエラー処理が膨らむ。
-
チューニング
- ひとつひとつのプログラムを軽くする。
- データベースのチューニング。
- 山積みを山崩し。ある処理を夜間にまわす。
- 中間ファイルの消し忘れ。
テーマ11 お客様の運用可能性
- 【NG】不都合な仕様をお客様に十分説明しないまま、仕様を確定してしまう。
- システム都合で変わってしまう部分がトラブルのタネとなる。
ベテランSEの目（３）
-
システム要件が肥大化しプロジェクトがストップ
→ 半分くらいにスリム化
|
シンプルなシステムを心掛けること （いくら欲張っても、最後は、削らないと動かない。） |
| 【悪いケース】公倍数、皆の意見を包含したもの。 |
| 【良いケース】公約数、皆の意見の共通部分、かつ、経営方針に合致したもの。 |
第4章 仕様調整上のフェーズ毎ポイント
テーマ12 プロジェクト開始前まで
-
単にやるかやらないかの話をするのではなく…
- システムで行うか運用で対応するか
- 仕様をいくつかの将来ステップに分ける。
テーマ13 現状分析から仕様検討まで
- 方法論は基本的な指針を示しているのに過ぎず、メンバの作業レベルにまで定着させるには時間が掛かる。
- きちんとした運用がメンバ全員に浸透しなければ意味がない。
-
メンバが勝手に、これは他のチームに関係がないと決め込んで、情報の共有化をしない風潮。
とくに、基盤チームとアプリチーム間。
テーマ14 仕様確定（仕様凍結）
-
仕様確定は、
- 開発者が作業の拠り所とする設計図を確定するための行為。
- プロジェクトのスケジュールの根拠となる行為。
-
仕様確定は、
- システム開発会社のためだけでなく、
お客様のためにも、必要なことである。
- システム開発会社のためだけでなく、
-
以上のことを、
-
システム開発会社メンバ
お客様メンバ
の療法が深く認識しておく必要がある。
-
システム開発会社メンバ
-
仕様変更のリスクを、先に説明しておけば、トラブルが発生しても納得してもらいやすい。
後になっての説明は、言い訳と思われる。
テーマ15 設定開発から試験，初期運用まで
-
開発が進んだ後に、仕様検討時の間違いが発見されることは、あって当然。
- お客様だけでなく、開発者側からも間違いは発生する。
- 大事なのは、お客様の要望をはね付けることではなく、お客様と認識を共有化すること。
-
後工程で仕様変更を受け入れるときの注意
-
仕様の「幹」と「枝葉」を意識すること。
- 万が一「幹」を変更する場合は、運用開始日をずらすことも検討。
-
関連する仕様を調整すること。
- 関連しそうなチームにも声を掛ける。
- 残された時間を意識すること。
-
仕様の「幹」と「枝葉」を意識すること。
-
運行開始後の仕様変更
- 多少使い勝手が悪くても、基本的に仕様変更は行わない。
- お客様の使い勝手が良くなるメリットよりも、システムが動かなくなるデメリットの方が、はるかに大きい。
ベテランSEの目（４）
- ユーザは気づいていないが、機能の大幅増加は、システムの性能や品質を大きく劣化させている。
- 失敗するシステム構築の場合、増加機能数は当初の要件定義の数倍まで膨れ上がる。
- ところが、増加機能の大多数は石ばかりで、玉はほんの数えるだけしかない。
- 機能が200個増えたとしたら、玉は５個くらい。
第5章 仕様調整以外の重要ポイント
テーマ16 スケジュール管理
- スケジュールの大半はSEの稼働時間で決まる。
-
予定どおりに進まないリスクはたくさんある
→ 体制を立て直すと同時に、スケジュールを調整し、プロジェクトがうまく進むように見直しを掛ける。 -
ひとりの上級SEのノウハウは、１０名の初級SEがいても補えない。
ノウハウの不足は、そのノウハウを有する人材以外に、穴を埋められない。
ノウハウ不足を稼働で補おうとすると、ノウハウを補完できないだけでなく、 増えた認印に対する調整稼働が増え、逆に進捗に悪影響を及ぼす。 -
安易なスケジュール見直し
- スケジュールは、プロジェクトメンバ全員の行動計画であるため、 これへの信頼がなくなってしまうと、プロジェクトはうまく進まなくなる。
- 計画変更の度に、リーダーの信頼はなくなっていく。
- メンバの士気が低下する。
- 最初からある程度の余裕を持っておくことが大切。
テーマ17 データ移行
- 長年の運用のため、既存システムには、何らかのゴミデータや重複データが存在することが多い。
- すべてのデータを人間が目で判断することはできない。プログラムを利用して効率的にチェックする仕組みが必要。
- 実データを利用した運用試験も。
- 一度データ移行を行った後、運用開始直前に、もう一度、差分のデータを移行する必要がある。単純なミスが意外に多い。
- データ移行作業は、お客様作業であるため、これがボトルネックとなり、プロジェクトが止まることがある。
- データ移行の重要性をお客様に説明。データ項目の意識合わせ。進捗の把握。お客様の抱える課題を把握。
テーマ18 システム切替
-
統合試験や運用試験で出たバグや運用ミス
↓
一覧表を作成する
↓
運用開始直後のトラブルはほとんど、この一覧表で解決される。 -
コンティンジェンシープラン
- 予定どおりに物事が進まなかった場合でも、さまざまな対応策を考えておき、お客様の業務がなんっとか回せる仕組みを考える。
ベテランSEの目（５）
- 進捗管理 ＝ 定量的な管理 ＋ 定性的な管理
-
定性的な管理のチェクポイント
- 定例の週次進捗会議で、毎週同じ報告をしている。（サブリーダはメンバの作業をつかんでいない。）
- 問題点の報告が毎回書いていない。（問題意識が低い。）
-
メンバも、サブリーダも、プロジェクト管理者も、同じレベル（視点）の管理をしている。
プロジェクト管理者 全体 今月と来月 サブリーダー グループ 今週と来週 メンバ 個人 日々
第6章 プロジェクトの人的要素
テーマ19 キーマンの把握
- キーマン ＝ 仕様調整や開発の中心人物。チームのムードメーカーでもある。
- チームリーダとキーマンが同一人物でない場合、チームリーダにだけ目を向けていては、実態が把握できない。
-
キーマンへの質問
- 【仕様・進捗】「ちょっと、君のやっている部分の仕様を、一通り説明してくれないか？」（突然にかつドキュメントなしで）
- 【コンセンサス範囲】「それを、お客様およびプロジェクトメンバの誰と決めたのか？」
- 【責任範囲】「それで、君が今考えている自分の責任範囲は、どこまでか？」
テーマ20 問題児の扱い
-
問題児の特性
- 与えられてた役割以外は、全く無関心。
- 自分のミスには甘いが、他人のミスは絶対に許さない。
- 全体が大変な場合でも、自分だけが苦労していると信じている。
- 自分の信念を頑なに信じ、他人の意見を聞き入れようとしない。
- 期限や約束事について、極めてルーズ。
- ↑ これらに自覚がない。
-
その人の人格全体を見る。
背景をよく把握し、プロジェクト上のポジションを変えてやる。
継続的に指摘指導する。
テーマ21 意味のある会議
-
意味のない会議
- 仕様のレビュー会なのに、内容でなく誤字脱字のみが指摘される。
- レビュー資料自体を、事前に何度もレビューする。
- キーマンや決定権者が出席しておらず、結局何も決められない。
- 形式上のリーダだけが集められ、本質的な話が全くできない。
- 堂々巡りで、決断を下す人物がいない。
- 問題や課題だけが述べられ、過問題解決への行動が示されない。
- 無駄に人数が多く、声の大きい人だけが意見を言っている。
-
限られた時間で、問題把握、対策立案、結果確認を行う。
形式よりも本質を重視して、会議を運営する。 -
結論が出ないまま放っておいては、プロジェクトは前に進んでいかない。
リーダの決断により、方針を決めてしまうべき。
十分に話し合っても、選択肢を選べない場合は、どちらを選んでも、それほど結論に違いはないことが多い。情報がなくて結論が出ないもの → 情報を集める方針を決定 情報は十分あるが決めきれないもの → 選択肢の中から方針を決定 -
何でも自分で抱え込んでしまうリーダ
「プロジェクトリーダは完璧であれ！」という強迫観念。 ↑↓ギャップ 完璧な人間はいない。人間には能力限界や得意不得意がある。 -
能力限界を補う仕組み ＝ ブレーンストーミング
- 未知な分野でも、メンバ全員の英知を集めれば、それなりに妥当な方針を立てることができる。
- メンバ全員で考えるため、得られた結果に対して、コンセンサスがすでに形成されており、行動に移しやすい。
- 参加メンバの士気を高める効果もある。
-
能力限界を補う仕組み ＝ ブレーンストーミング
ベテランSEの目（６）
-
動かないシステムの建て直し
- プロジェクト管理者を交代（完投型でなくてもいい。）
- 状況理解・・・仮設を組み立てる。素早い状況報告と対策方針説明で、安心感を与える。
-
本来の対策・・・機能カット、人と金をつぎ込む、スケジュールを延期する
→「機能カット」がもっとも効果的。
第7章 人間性の考慮
テーマ22 能力の最大限発揮
- プロジェクトの目標とメンバ個人の目標とのすり合わせが、動機の強弱を決める。
- 達成感がないままプロジェクトが進む場合、メンバの士気低下は避けられない。
- メンバに仕事を与える際は、仕事を短い期間で割り、その期間ごとに小さな課題を設ける。
テーマ23 失敗の可能性
-
失敗する可能性があるという認識は、トラブル発生時の対応だけでなく、普段の行動も変える。
- 議事録や設計書などをきちんと残そうとするし、積極的にレビュー会を利用し、ミスの発見に努める。
-
失敗は日頃の行動パターンから発生するものであるため、気を付けていても、そう簡単にはなくならない。
- 類似の失敗が他にないか、繰り返し失敗しないためにはどうするか等の対策を立てる。
-
メンバを頭ごなしに怒る → メンバの士気低下 → プロジェクト全体に悪影響
- メンバは既に罪悪感を感じている。
- どうすれば２度と同じ失敗をさせないかを考えることが重要。
テーマ24 人間の限界
- プロジェクトの士気低下を、単なるやる気のなさと捉えない。
-
やる気を高める要因と下げる要因とは全く別物
士気を
下げる
要因職場環境（自分ではどうにもならない部分）などへの不満（被害者意識）
「稼働が大変なのに、人員補給してくれない」
「営業が、できないことはできないと、お客様に言えないので、仕事が増えていく」親身になってメンバのことを考えてあげる。
他の人が、自分のために一生懸命動いてくれたということが分かると、被害者意識が薄れ、不平不満も弱まる。
士気を
上げる
要因仕事自体のやり甲斐。
テーマ25 孤独なプロジェクトリーダ
- 孤独に耐えるだけの信念・哲学が必要。
ベテランSEの目（７）
-
完璧な仕様書は記述できない。
- 解決するには、会議や打ち合わせなど、コミュニケーションを多く摂る以外にない。
- 良好なコミュニケーションを築くには、相手の価値観を知ることが重要。
付録
付録１ コミュニケーションスキルの重要性
-
コミュニケーションスキルの構造
- リーダーシップ
- ディスカッション
- ネゴシエーション
- ドキュメンテーション
- プレゼンテーション
付録２ プロジェクト管理標準化の意義と動向
付録３ プロジェクトマネージャスキル標準
