第４５回目「実践プロジェクトマネジメント」（岡村正司著）（その３：全５回）
サブタイトルが「危機を乗り越える２５の決断」とある様に、著者がプロジェクト経験でえた次の世代に伝えたいノウハウを２５の瞬間に整理されたものです。プロジェクトを推進するにあたっての問題点と確認すべき事項、判断基準が記載されています。PMには是非一読することを勧めます。
今回も学ぶべきことが多いので、フォトリーディングからは少しずれてしまいますが、５回に分けて進めていきます。
なお、記載事項は各章で著者が表でまとめている事項について記載するともに、考察していきたいと思います（具体的な対策については、本書を参照してください。ためになること、気付かせてくれることがどの章にもあると言えます）。
この本に興味があれば→
１回目：１．支援契約と請負契約の判断、２．開発規模見積りの判断、３．マスタースケジュールの判断、４．ソフトウェア・エンジニアリング選択のリスク判断、５．開発環境構築の判断、
２回目：６．要件定義遅延時の判断、７．プロジェクトメンバーの入れ替え、８．外部設計の品質リスクへの対応、９．コスト・オーバーラン発生の兆候,１０．PMSを利用したマネジメントが破綻した時、
３回目：１１．大量取引処理の設計と課題への対応、１２．EVMが破綻した時、１３．拡張性設計とコスト・マネジメントの対立、１４．プログラムの品質悪化の兆候、１５．データベース設計の難しさと対応策
４回目：１６．本番稼動機器および基盤システム決定の時、１７．SLAが守れない兆候が出た時、１８．予定通りのサービスインを決定する時、１９．追加開発受け入れ時の判断、２０．サービスイン遅延判断
５回目：２１．納品処理のトラブル判断、２２．プロジェクトを終了させる判断、２３．プロジェクト中断を言い渡された時、２４．対応するリスク、放置するリスク、２５．プロジェクトを成功に導くための判断、考察
１１．大量取引処理の設計と課題への対応
- 大型プロジェクトの土台、制御系システムを構築する
- 大量取引処理で発生しやすい問題と対応策
１２．EVMが破綻した時
- マネジメント力によってEVMの利用法は変わる
- 集計に工数をかけてはならない
- EVMで見積もり精度を高めるべき
１３．拡張性設計とコスト・マネジメントの対立
- 拡張性の確保にコストをかけるべき
- アーキテクチャの優劣でシステムの拡張性の大半は決まってしまう
- アーキテクチャ・バイオレーション：アーキテクチャの質が劣っている場合、ひどい場合は、事実上そのシステム寿命の終わりを意味することになる
- 要求を越えた機能（金メッキ）は無駄である以上に有害
- どのグレードでもユーザに合致すれば最適なシステム→グレードが低いから悪いシステムというわけでない
- 拡張性を確保するための原則：「設計思想は広く構え、実装は着実に」
- 新システム開発を始める時期：「先が見わたせるタイミングで開発せよ」
１４．プログラムの品質悪化の兆候
- マネジャはプログラムの品質悪化の兆候を見逃すな
- プログラム品質に対して、PMはプロジェクト推進方針を持たなければならない
- プログラムはそれほど仕様変更に耐えられるものではない
- プログラム品質悪化の兆候と対応策
- ①大量の仕様変更が特定のプログラムで発生→追加仕様を受け入れた後のプログラム構造を評価
- ②開発基準が守られていない→チームで最初に開発したプログラムを開発標準チームが徹底チェック
- ③プログラム構造図を作成せずにプログラムを開発→プログラム構造を整理する体制を構築
- ④エンティティを定義せずにプログラムを開発→PJで扱うデータの単位を整理する体制を構築
- ⑤データベースのCALLINGシーケンスの定義がない→プログラムをテストし、データベースのCALLINGシーケンスを確認
- ⑥プログラムが当初目標の処理性能を出せない→設計不良の場合はプログラム修整を推進、DB設計不良の場合はDB設計のスペシャリストを投入
- 最初のプログラムで開発方針を徹底できたなら、その後に作成されるプログラムの品質は飛躍的に向上する
１５．データベース設計の難しさと対応策
- データベース設計が最重要 能力の高い要員を確保せよ
- 技術面で最も重要なのがデータベース設計
- データベース設計者には、業務設計と異なる技術が要求される、-物理データベース設計の分野は高度な技術が含まれる→データベース設計のスペシャリストを確保できればプロジェクトは成功に近づく
気付きと考察
今回対象とした１０〜１５章にかけては、性能、回線効率、ＤＢ設計を含む品質面について記載されているように思える。
性能と拡張性を最初に設定し、設計思想、アーキテクチャを構築・徹底していかないと、取り返しのつかないことになる。
性能に関するところで設計をミスってしまうと、場合によっては根本から設計のやり直しに陥る可能性がある。性能に関する点は、必ず押さえてから設計に入ること。また、性能は論理的に計算した数値を出すのも勿論であるが、ある程度実測しておくべきである。特に、回線効率やＤＢ検索時間は、単独ではなく最大負荷も考慮した上で論理値を求めること。例えば、回線効率については、情報処理試験で出てくるＭ／Ｍ／１だけを考慮していると痛い目に会う。必ず、無負荷状態、平均負荷状態、最高負荷状態を計算しておくこと。
ＤＢ設計についても、本書で述べられている通り、これが間違っているとまともなデータ処理ができなくなる。３層スキーマの理解、正規化は常識であるが、業務設計を元に拡張性、検索性能を踏まえてＤＢ設計を時間を掛けて行う。また、アプリケーションもＤＢの変更に影響を受けないように、３層構造にする（特にＷｅｂ関連）。アプリケーション自体の組み方も変にＳＱＬ文を入れ子にしすぎると、性能がでなくなる。つまり、コーディングによるところも大きい。ＤＢ検索については、検索のトレースを取り最適化されているかを確認する(キーにヒットしているか等)。データ量の増大に伴い性能が落ちないかについても検証しておく。データ量が少ないと検索が早いのは当然であり、想定しているＭＡＸのデータ量での検索時間を検証しておかないと、本稼動に入って暫くすると遅くて使えないということにもなりかねない。
プログラムのコーディングについては、保守することを意識したものにする。また、本書でも述べられいる様に、方針にあっているかを必ず検証する。別の人がそのプログラムを修正する可能性もあり、プロジェクトメンバーの誰がみても見やすいプログラムにする必要がある。
ツールからみると、テスト検証については、WinRunner、LoadRunner（いずれもMercury）、ソースコードの品質保証には、QAC（Progamming Research Ltd）、テストデバッグとしては、DevPartner(COMPUWARE)などを使い効率化を図ってみるのも一方法である。ツールを使う場合は、ツールの習得期間を考慮した上で、実施するに当たっての費用対効果を算出しておくこと。
このブログが少しは役立ったと思われれば人気blogランキングをクリックして頂ければＨＡＰＰＹです（＾o^)
