当該システムに必要な技術の調査検討 代替技術との比較検討(実現可能性/技術者の確保/導入コスト/運用コスト/開発効率/保守性/安全性/安定性/将来性/パフォーマンス/セキュリティ/適用事例/ベンダーの信頼度) 実証テスト・リポート 採用技術の承認取得

運用体制。 利用部門、利用担当者、利用権限。 利用可能時間帯。 オペレーションルール。 バッチジョブネット図。 バッチジョブスケジュール。 バッチジョブエラー時オペレーション。 例外オペレーション。 年間予防保守スケジュール。 障害予防策。 障害事…

ハードウェア構成 ソフトウェア構成 ネットワーク構成 機器の配置 障害時のバックアップ機器構成 電源設備 配線 調達計画 導入設置計画

中長期事業計画書。 業務内部資料（業務マニュアル/業務定義書/業務フロー等）。 業務課題一覧。 現行システムがあれば、現行システムの各種資料（出力帳票/操作マニュアル/設計書/仕様書等）。 ヒアリングシート。 アンケート用紙。 打ち合わせ議事録。

必ず文書にすること。 変更の理由や背景が明確であること。 関係者の合意が取れていること。 他の要件との整合性が取れていること。 工数や費用を見積もり、周知すること。 技術的な裏付けを取ること。 優先度と実現する時期を確認すること。 効果を試算する…

ユーザーと話ができない。敬語も使えない。コミュニケーションを取るのが苦手。 文章が書けない。書いても意味がわからない。 設計ができない。設計書が作れない。 コンサルタント気取りで、口は達者だが、教科書的なことしか言えない。具体的な問題解決がで…

要件定義に基づき、システムの目的を明確にすること。 システムの範囲を明確にすること。 システムの前提条件を明確にすること。 システムのハードウェア構成、ソフトウェア構成、ネットワーク構成は、インフラ設計で行う。 サブシステムを洗い出し、アプリ…

プロジェクトメンバーの中には、必ず悩みや不満を持つ者が出てくる。プロジェクトマネージャはそういう人達を見逃してはならない。面談とまではいかなくても、メンバーに声をかけ、ちょっとした話をしながら、様子を窺うことが大事である。解決策が無くても…

昨日、休日出勤した。午前は病院だったので、午後から出社した。納期が迫っているプロジェクトのために否応なく出たが、担当の3人の部下も当然の如く来ていた。というよりも昨夜からいた。昨日着けていたネクタイやシャツを脱ぎ捨て、スーツのズボンもヨレヨ…

システム開発の成否を左右するのは、メンバーの能力と各々のモチベーションの高さである。人数が少なくても、できる人達を集めれば、仕事は進む。できない人達を多数集めても時間を取るばかりで捗らない。教育するという考えもあるが、期間が決められたプロ…

機能 品質 性能 効率 容量 時間 拠点 操作性 拡張性 安全性 費用 体制 運用 保守 リスク セキュリティ ヘルプデスク

項番 部門 部門担当者 業務名 課題 課題分類コード(経営戦略、情報戦略、業務上の問題等) 対応方法 対応方法分類コード(業務プロセス変更、業務廃止、システム変更、新規システム化等) 優先度 実施期限 備考

テスト仕様書を作成する時、下記のような標準テスト項目を参照するとテスト項目の漏れを少なくすることができる。 範囲チェック(日付、時間、長さ、重さ、量、金額等) 属性チェック(英数字、英字、数字、カナ文字、全角文字、特殊文字) 桁数チェック(文字数…

設計書レビュー指摘項目数 仕様変更追加件数 機能数とテスト項目数 単体テスト終了後バグ発生件数 結合テスト終了後バグ発生件数 総合テスト終了後バグ発生件数 性能目標達成率 本番稼動後バグ発生件数

WBSの作業項目件数と完了件数 課題発生件数と解決件数 機能要件の件数 プログラム設計書の作成件数 プログラム製造件数 プログラムの実装機能件数 テストケースの件数と消化件数 バグ発生件数と解決件数

要求された機能の実現度。 性能目標の達成度。 本番稼動後の障害発生頻度。 システムの稼動率。 業務処理時間短縮目標の達成度。 業務コスト削減目標の達成度。 システム運用コスト削減目標の達成度 セキュリティポリシーの達成度。 キャパシティプランの達…

システム開発で忘れられがちなものは、 運用保守 移行 ユーザー教育 である。どうしてもメインである設計と開発に目が行くので、ある程度プロジェクトが進んでから、誰かが騒ぎ出して慌てることが多い。運用によっては、システムの作りを大きく変えなければ…

概要 目的 対象業務 範囲 前提条件 納期 機能 アーキテクチュア 性能目標 品質目標 必要な技術 組織体制 要員の配置 体制図 組織の役割 責任範囲 予算 費用対効果 調達計画 RFPの作成 ベンダーの選定 協力会社の選定 マスタスケジュール

世の中には、見積もりが甘かったせいで、赤字になったプロジェクトは山ほどある。どうすれば、見積もり精度は良くなるのだろうか。正解は知らないが、日頃心がけていることを挙げると次のようになる。 ・要件定義ができていない場合はお断りする。要件定義作…

プロジェクトを推進する中で、QCDのどれを優先させるべきか判断しなければならない局面が必ずある。QCDとは品質(Quality)、コスト(Cost)、納期(Delivery)、のことである。例えば、開発途中でどうしても機能(品質)を増やしたいということであれば、コストも増…

ユーザ要件が出てきた時に確認すべきこと。 ・課題は何か。 ・その課題は何時まで続くのか。 ・その課題は何時までに解決しなければならないのか。 ・その課題を解決するとどのような効果が見込めるか。 ・その課題は主にどこの部署の誰が担当しているのか。…

プロジェクトを円滑に推進するために、コミュニケーションルールを設定する。 ・悪い報告を叱らない。 ・嘘をつかない。 ・推測でものを言わない。事実を言う。 ・異論があればその場で言う。言わなければ合意したものと見なす。 ・個人攻撃をしない。犯人探…

何か意志決定する時はリーダーが勝手に決めるのではなく、メンバーの意見を参考にして決めるべきである。どんなに優れたリーダーであっても、いつも正しい判断ができるとは限らない。適切な意志決定をするためにも、メンバーから意見を聞いて情報を集めるべ…

モチベーションの高いメンバーと共に仕事をするととても楽しい。どんなに困難な問題があっても解決できるような気がする。仲間意識が強く、まるで自分達が選ばれた人間のように生き生きとしている。そんなメンバーがプロジェクトチームを組めば、間違いなく…

人は自分の価値観に合ったことをする時が最も力を発揮しやすい。その人が何に重きを置いているのかによって、仕事のさせ方が変わってくる。人それぞれ価値観は異なるが、大きくは次のように分類できるのではないだろうか。 ・知識や技術を得たい。 ・地位や…

ユーザの要件定義が済んだら、それを実現するために行うべき作業を漏れなく洗い出す。さらに洗い出した作業を実現可能な大きさになるまで細分化する。これを構造化したものがWBSである。WBSがないと、プロジェクト全体にかかる工数が見積もれない。それに伴…

システム開発のプロジェクトを進める上で必要な会議体を列挙してみる。 ・プロジェクト発足(キックオフ)会 ・要件確認会議 ・仕様確認会議 ・ユーザ進捗報告会 ・内部進捗会議 ・ユーザレビュー会 ・内部レビュー会 ・サブシステム間仕様調整会議 ・課題解決…

要件定義がプロジェクトの成否の鍵を握ると何度も書いてきた。要件定義はユーザ中心の仕事になるので、彼らにその能力がどれだけあるかによって変わってくる。その不確定要素を無くすには、こちらが業務分析やシステム分析等を含めた要件定義以上の工程に関…

要件(要求)定義はユーザの仕事である。システム化したいことを明確に定義し、開発者に漏れなく伝えなければならない。開発者はシステムに関する専門知識でユーザの要件定義作業を支援することはできるが、どの業務をどのようにシステム化したいのかというこ…

まずは業務経歴書の裏付け確認から。 ・過去に携わった業務の説明(最近のものから)。 ・各プロジェクトの期間。 ・各プロジェクトの規模(総工数、在籍時の人数等)。 ・各プロジェクトにおける立場、役割。 ・各プロジェクトで担当した工程(設計、プログラミ…